Hi,
I definitely agree, a good standard library (difficult) or at least some common coding and naming standards is essential for open embedded computing.
This is not is not an easy task, and let me elaborate by giving some examples of what I like/dislike about trying to work with open source tool chains for embedded processors.
-
Overengineered libraries. A lot of small functions doing basically one register assignement each.
-
Naming in header files that is different from the TRM
-
Inconsistent section names and variables in linker scripts
Usually we must study the TRM for a specific target in order to understand how to use the library functions. Then we must learn a set of function names and parameter names that are often understandable and logical, but still different from the names given in the technical documentations. In my experience, after a careful reading of the target documentation it is often easier to write low level asm/C style register assignments than trying to remember the name and calling conventions for the library functions. I use the libraries as example code !! Of course, the end result is that everyone has their own personal firmware library.
– There must exist good target specific header files for all registers and bit constants using the same terminology as the TRM for this target.
We then need a standard for how to define and access memory mapped hardware registers. These headers can be used in low level assignments or in more elaborate firmware functions.
One example I struggle with at the moment is Luminary and ST Cortex-M3 processors. The have different peripherial control registers that must be controlled differently, ok, but accessing the common Cortex-M3 functionality is totally different in the Luminary and the ST examples making it very hard to port code.
- The gcc toolchain gives a lot of flexibility, so we can call the code section that contains startup addresses/interrupt vectors .vector or .isr_vetors or .startup or someting similar without . . And the zero filled data block can be _bss to _ebss or _bss_start to _bss_end or bss_start to bss_end affecting the initialisation file, called statup.S or crt0.s or startup_gcc.c … and the linker script. Freedom is fun but not simple.
Just creating this library is a good thing, but the risk is that we just create another great and slightly different firmware library.
What we need is for the people that has influence on some of these coding styles to agree on common basics. After reading these forums we see that some peole like J. Lynch and Michael Thomas and the Olimex examples , No quality discussion here but these are often used examples. They (can) have a big influence by using similar and/or different coding standards. If we can get ań inluetial group of people, that publish examples that are often used, to agree on style and naming enough to create interoperable initialisation scripts then we are going somewhere.
For instance, in the Linux world this is controlled by the gnu people on the one hand and the kernel maintainers on the other and lets not forget initiatives like LSB, very helpul even if they are not 100% sucesses.
Regards
Magnus