I’m a new user to FreeRTOS. I’m working on a new project using at AT90SUB1287. You can see my blog at http://mudplace.org/?cat=3
I have some questions about the file layout and includes. Specifically I’m curious about the #include mechanism and ports.
1. Why require a "FreeRTOSConfig.h"? Or at least allow for an external definition of the values. Say something like:
This way a user can tailor the specifics of the kernel using command-line values, such as -DconfigUSE_PREEMPTION=1, etc. And for those compilers that do not support the -D option, it can fallback to the #include mechanism.
2. Why have portable.h #include one of a variety of files? Instead, why not require the user to provide a portable.h? The user can then copy one of the variety of portmacro.h files over to portable.h, or at least just have a generic #include "portable.h" and make the user point to the appropriate directory (or copy the file) to find the portable.h.
The problem, for me at least, is the relative path includes, such as "…\…\source\owatcom\16bitdos\pc\portmacro.h". This kind of include forces me to compile from the FreeRTOS directory, rather than from any directry I want.
Perhaps something like:
#endif /* PORTABLE_H */
3. Why couple the port.c file so tightly to the hardware? For example, in portable/GCC/ATMega323, the xPortStartScheduler() configures a specific timer for context switching. What if the user wanted a different timer? They would then have to modify the FreeRTOS source itself. Or on the Microblaze port, the code assumes use of the Xilinx provided drivers. What if a user had their own driver for the OPB timer? What if they didn’t use the OPB timer but provided their own? It seems this kind of code is better suited to the demos.
For example, we use ThreadX and uCos at work. In ThreadX, there is a tx_port.h file that defines a minimum of hardware specific items, such as portmacro.h does. It defines the types, has macro definitions for critical sections, etc. We compile ThreadX into a library, independent of the firmware. All we have to provide in the firmware are callbacks to tx_kernel_enter(), tx_application_define(), _tx_timer_interrupt(), etc at link time. Also, all the features are individually selectable through pre-processor defintions (we use -D on the command line to specify what we want).
Also, by compiling into a library, I can only pull in the symbols that are actually needed. Linking the object files with the application directly may pull in symbols that are never called (depends upon the compiler/linker). I personally found a decrease in final exectuable size of nearly 5K by using a library.
In my use of FreeRTOS, I modified portable.h to remove the relative include paths. I then put port.c and portmacro.h in a separate area where I could provide my own backend functions. I then compiled everything and archived it into a library. Now I just compile my code separately and link with the FreeRTOS library. But now I am tempted to copy the FreeRTOS files over, modify the #includes, and them just stick with v4.7.1.
I’m not trying to be pedantic or annoying on this. Just curious about the structure and design decisions. And perhaps suggest some changes.