hermarcel wrote on Monday, March 14, 2005:
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.
kreinims wrote on Thursday, March 17, 2005:
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.
n1vg wrote on Thursday, March 17, 2005:
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.
imajeff wrote on Monday, April 04, 2005:
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
rtel wrote on Monday, April 04, 2005:
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.
kreinims wrote on Friday, April 15, 2005:
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.