Request for suggestions for the next release

I have collated a list of ideas and suggestions for the next major release of FreeRTOS.  These can be viewed here: http://www.FreeRTOS.org/v3.html 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!

Request for suggestions for the next release

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!

Request for suggestions for the next release

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.

Request for suggestions for the next release

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?

Request for suggestions for the next release

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.

Request for suggestions for the next release

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.

Request for suggestions for the next release

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.

Request for suggestions for the next release

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. :-)

Request for suggestions for the next release

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?

Request for suggestions for the next release

I will have to check this out as I’m not familiar with it. Regards.

Request for suggestions for the next release

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.

Request for suggestions for the next release

Some compromise seems best here.  The projdefs.h and portmacro.h files are definite candidates for combining.  Maybe not queues/semaphores/tasks.

Request for suggestions for the next release

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.

Request for suggestions for the next release

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 …

Request for suggestions for the next release

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!

Request for suggestions for the next release

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.

Request for suggestions for the next release

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.

Request for suggestions for the next release

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++.

Request for suggestions for the next release

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?

Request for suggestions for the next release

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?

Request for suggestions for the next release

I haven’t checked if all ports simply define all port… to their natural counterpart. I do know, however, that going to the standard types would improve readability of the code. So, I’m all fore it.

Request for suggestions for the next release

Yes, I posted this because the code would be easier to read. And one thing less you have to think about when making a port. So if there is a standard for something, I tend to use it. But this is not really important, just you know this could be a good change for coming releases. So far it’s better not to change. Using standard types short, char etc. sounds to me too dangerous.

Request for suggestions for the next release

Here’s an easy one – define a character string constant with the FreeRTOS copyright message and version number.  I’ve got this displayed in my application’s banner, along witih my own copyright and version info, but it’d be nice to have it updated automatically whenever a new version of FreeRTOS is used.

Request for suggestions for the next release

I see the need to free the not-needed stack from main, but I’m a little fuzzy about how turning it into the idle task or another task will free it. Will it re-initialize the stack as that task, or what will specifically free the space already pushed?      –jeffs

Request for suggestions for the next release

The former of your two options. The idea is for the idle task to use the same task as was previously being used by main() – rather than a new piece of memory being allocated for the idle task while the memory used for the main() stack was obsolete. As it happens this is proving to be tricky from a portability point of view.  The new functionality would have to be at the portable layer level making it a larger change than anticipated as each port requires individual work.  My current thinking is that the first 3.x.x release will not have this functionality.  I have made a couple of other changes that reduce the amount of stack required by main() to lessen the waste.  Following this the ports can be changed individually – with the small memory ports being done first as this is where the need is greatest.  This will not result in an API change so will not have compatibility issues (once upgraded to 3.x.x). Regards.

Request for suggestions for the next release

I don’t know if you already use doxygen for documentation. http://www.stack.nl/~dimitri/doxygen If not I would suggest it, as it creates documentation from your source files directly. You could easily create html- hlp- and chm- files to distribute with the source.