rtel wrote on Wednesday, March 09, 2005:
I have collated a list of ideas and suggestions for the next major release of FreeRTOS. These can be viewed here:
Please feel free to post your comments and suggestions here. This is your chance to have a say in the next development phase of FreeRTOS!
nobody wrote on Wednesday, March 09, 2005:
portBASE_TYPE:
I love it. Compatibility is not yet an issue for me though.
Turning main() into a task:
I appreciate what you are trying to do. I think it’s a good idea to reclaim the otherwise wasted default stackspace. I, however, also like to design my software as clean as possible. Putting taskcode into main instead of in a well-described function with a meaningfull name makes me hesitate a little. Perhaps it would be nice if the taskcode in main() could be the idle-task. I think this means that the idle-task can only be started after the scheduler has started. I am not sure if this is possible. If it is possible, then a macro that expands into the idletaskcode might be nice to prevent users from making errors here. That way the macro can be put into main() or in prvidleTASK().
The idle-task: if and when:
Looks good, gives one full control over this task.
Look good!
nobody wrote on Wednesday, March 09, 2005:
portBASE_TYPE looks like a gr8 idea to optimise for each platform.
also macro-ing your compiler specific instr. will reduce the nomenclature and simplify things. - rather than having to explain every compilers preprocessor/linker optimisations.
I agree with prev. poster prefering main as idle task.
nobody wrote on Wednesday, March 09, 2005:
I’d suggest expansion of the queue structures using berkeley sys/queue.h would be very funky and useful in a variety of circumstances to optimise inter-task communications and event handling in complex systems
now im dreaming… priority queues?
alunz wrote on Thursday, March 10, 2005:
It all looks good. Given the choice of having main being turned into a task or turning it into the idle task would prefer the first option. Especially if option (4 - If and when…) is implemented.
On a slightly related note, what did you think of the idea of reusing main’s stack as an interrupt only stack? Realise that your time and resources are limited (and its your project - you take it where you want it to go) so supporting that would be a portability nightmare. Having said that, the MSP430 solution that aLUNZ has developed appears to be working well and (so far) seems to be doing what is expected of it. Am probably going to use that in the current project. Would be interested in your comments and if there are any pitfalls that might unexpectedly deliver dental impacts on the gluteus maximus.
hermarcel wrote on Thursday, March 10, 2005:
A way to have a task block forever on a queue would be nice. It would avoid having to write code to check returnstatus and block again if unblocking was caused by a timeout.
rapurvey wrote on Thursday, March 10, 2005:
I also agree with the others as to using main as the idle task.
On the grouping of header files. Cant the common components of FreeRTOS be included in a FreeRTOS.h file and still have the seperate header files for tasks, queues, etc?
Personally I would prefer to be able to look at the includes and see that the source I am currently looking at uses queues, etc just from the header files included.
I always believe that any header file that requires another header file for a definition should include that header file itself, not rely on the user to have the right header file in the right order.
rapurvey wrote on Thursday, March 10, 2005:
On a side note, can the IAR port be slightly changed as well? Or is this just propossed changes for the core?
In the IAR port there is the portmacro.s90 file that includes the interrupt jump table. I think the interrupt jump table should be made project specific while the rest of the file (context macros, etc) should remain in the port. This is because you may have different interrupt sources defined for different projects which will make the whole of the portmacro.s90 file project specific.
Hope that makes sense. 
nobody wrote on Thursday, March 10, 2005:
It looks like the operating system doesn’t accept the interrupt system to be enabled until the StartScheduler() has been issued?
I think it would be a good idea good to be able to keep global MCU Interrupt enabled during boot up. Lets say writing out data on a serial trace port during boot, when the AddTask() has been called first time, the interrupt system is disabled due to the nesting of lock and unlock hasn’t been started proper yet (counter set to 0).
Is there any way to ask/force the FreeRTOS-V2 to reestablish the interrupt mask also during start up?
rtel wrote on Thursday, March 10, 2005:
I will have to check this out as I’m not familiar with it.
Regards.
rtel wrote on Thursday, March 10, 2005:
Ref reusing main stack.
I think this is a good idea - but the implementation would have to be different for each port which may be awkward. It looks like using the main stack for the idle task is the most popular.
If it is the best solution for you then great - this is the good thing with open source.
rtel wrote on Thursday, March 10, 2005:
Some compromise seems best here. The projdefs.h and portmacro.h files are definite candidates for combining. Maybe not queues/semaphores/tasks.
hermarcel wrote on Thursday, March 10, 2005:
I would like to see the definitions that are currently in portmacro.h but are project-dependant (instead of port-specific) be moved into a seperate headerfile.
To get greater control, I would also like to see the portable files (tasks.c, list.c, etc) use freertos.h, too. In my opinion, freertos.h should include the current headers.
rtel wrote on Thursday, March 10, 2005:
I will have to take another look at this but I think that interrupts can already be enabled prior to the kernel being started - provided your application does not try to use the kernel features.
It may be that the demo applications do not enable interrupts, but the kernel itself only disables them within the StartScheduler() function. They also get enabled/disabled during critical regions, but this would not prevent your serial port ISR operating.
To elaborate a bit using your example of the serial port. Serial drivers can be written to not use any kernel features and can therefore be used at any time. However, if your serial port driver uses, for example, cQueueSendFromISR() then the queue you are sending to must or coarse be created first. Also if the send causes a task switch there will be problems but this would only be the case if a task was blocked on the queue and if the kernel was not started how could this be?
One good change at the kernel level would be to initialse the scheduler locking variable to a non zero value - and only set it to zero during the StartScheduler() function - after interrupts have been disabled. This would make it impossible for a context switch to be even attempted prior to the kernel being started. However care would still be required and the actual behaviour would depend on the port.
Just thought of one other thing - pxCurrentTCB would also have to be initialised … this might be a bit tricky. Best not do anything that tries to use the kernel until it has been started.
I will ponder this one some more …
nobody wrote on Thursday, March 10, 2005:
I do understand all details in your replying thanks.
But, take a closer look into the lock and unlock logic. When adding a task you first lock and disable the interrupt later you unlock but dont re-establish the interrupt while the counter is not initialised proper!
rtel wrote on Thursday, March 10, 2005:
Yes - you are right - when using one of the ports with the CriticalNesting variable (not all ports have this). CriticalNesting was initialised to non zero (9999 I think). There was a reason for this … try initialising ucCriticalNesting to zero instead of 9999. I can’t see that it would cause a problem now but would have to step through the code to double check.
If you find a problem it should be something that is different in V3.
n1vg wrote on Friday, March 11, 2005:
How about a way to have the idle task count how much of the time it’s active? Then I’d be able to monitor the processor load.
nobody wrote on Monday, March 14, 2005:
I try compile demo app for LPC_2106_GCC with g++. There was some errors with conversion. I think that will be fine that will be possible compile freeRTOS as C++.
nobody wrote on Monday, March 14, 2005:
I wonder if it’s possible to get rid of the integer type defines,
like portchar etc.
I think these are all defined in stdint.h now?
Is there anybody who’s running into problems with this?
Maybe something like
#ifndef uint8_t
#define uint8_t unsigned char
#endif
in portmacro.h covers this?
rtel wrote on Monday, March 14, 2005:
stdint.h is not included with all the compilers that FreeRTOS uses - although one could be created and included with the source code download.
I was half thinking of ditching the portNNN definitions all together and just using the standard types - short, char, long, etc. The source code does not make any use of int types, and the new portBASE_TYPE will be used a lot, so they are almost obsolete.
However, sod’s law says if I remove the portNNN definitions the next port will require them. Although there is some opposition against the definitions I do not know of any really good arguments against their use.
What problem do you find with them?