What is this crap? It does not even compile!
Indeed that is possible. There are many switches and configuration parameters so there are very many combinations possible and rest assured, i did not even test a small fraction of them. Most of the times when i encounter such an error it is just a typo. Of course, you checked that you included all functions you use, and that you did not misspell a task name? The preprocessor checking code will prevent a compile in most cases that do not make sense. The error may also show up in the core code while your code is to blame.
I compiled the examples, flashed them, they don't work!
Yes, that is perfectly possible and does not indicate that anything is wrong. Probably you followed the wrong procedure. Which registers are used by GCC is not predictable nor is the choice stable. Thus probably your compile resulted in a different set than mine. Per default, optimization is turned off (cfgSysOptimized == cfgFalse), but still there could be offending registers. Thus, first make sure cfgSysOptimized is indeed cfgFalse. Then most checks must be on, increase the stacks and use as many registers as you have ram for. Then compile and run. If the system reports an error (assumed you are on the STK500 with the leds connected to port A), try to resolve it. Usually by increasing the stack or adding more registers to the context. Which registers are used can best be seen by direct inspection. You can make use of the register inspection tool (it generates a main.regs file, but that is not 100% bullet proof). Now, if all is well, you can start decreasing the registers and then the stack size until an error occurs. This is best done with StackSafety set to 2 bytes at least. Now you know the minimal values for stack and registers. Switch of the task checking options and start decreasing the OS stack size. Since demo code is distributed with cfgSysOptimized set to cfgFalse in principle any error should show up, after you have resolved it you may try if you can run with cfgSysOptimized set to true. Most likely you have to adjust those parameters too.
The examples run, but my code size is still bigger!
First of all, the code size can only be identical when everything else is identical, thus
- the same GCC version (4.2.3) as i had, and
- the same chip (attiny861, but 461 and 261 are probably ok), and
- all configuration parameters are identical and
- and all compiler options identical.
Now beware the you have cfgSysGCCstartup set to cfgReplace and activated and the -nostartfiles when linking. Now you should obtain the low values i got. Note that if you switch back from cfgReplace to cfgOverride or cfgKeep you remove the -nostartfiles option again (otherwise the application we probably enter a reset loop)
How do I reduce ram use as much as possible?
Here are several possibilities
- If you still have some flash left consider the inline option (and inline your own code as much as possible too) Code gets larger, but calls tend to get less deep, so less stack is needed.
- Eliminate boolean parameters and work as much as possible with bit masks. GCC generates much more efficient code in general. Also, it may help to compact function parameters into one byte and split them with masks again. I used this technique frequently inside the Femto OS.
- Realize that a design can always be done more efficiently even if you already made it more efficient. From the first (working) version of Femto OS until this first release, i gained a factor two on almost all test applications, just by redesign and without loss of functionality.
My code is still to big, how do i reduce it further?
I see three options here, assuming you already made use of the tips out there on the net how to write efficient code in c. (Test well, not all tips are useful, some are even plain nonsense)
- If possible try to make use of the same register set in every task. If the register use of all tasks is identical the preprocessor can produce shorter code.
- The same holds true for the stack sizes, if all stack sizes are identical, the size itself is replaced by a constant, and is not stored per task in flash.
- Place all code, the Femto OS included, in one file and make everything static. The compiler has now full freedom to optimize. BTW, i have not tried this!
- When you are absolutely confident you code is finished and fully functional, optimize the code generated by GCC by hand. Although GCC does not produce bad code, it is clear a lot can be gained here. Go for the big winners first.
- Rewrite the Femto OS so that it contains less fat. ;-)
Function X does not work but it used to, what happened?
Make sure, if you change anything to optimized code, you increase all stack sizes and activate all checks. A program does not have to crash when it is short of stack, but may behave in any way. I have experienced this countless times, and even knowing this lesson, i still get caught sometimes. Even the most minor change to the code requires a full new optimization cycle! With Femto OS you are living on the edge, be prepared to bleed.
My program runs for a while and than crashes or resets.
Most probably you are short of stack space. If checks are activated that should not go unnoticed but it may happen that the overflow occurs somewhere where no context switch takes place, or there is some other reason why the check does not catch the overflow. Thus, first action is to increase the stack and to incorporate manual checks. Of course, you run with checks activated when developing.
How do i get started on Windows, Linux or Mac?
Getting started on Windows is a piece of cake, just install the Atmel simulator and WinAVR and copy the files. You can also make use of cygwin and subsequently use the "install toolchain script" to install the toolchain. The install srcipt runs for Linux and the MAC alike. In the readme you will find instructions in more detail. On Linux and Mac, the most easy way is to install Eclipse for C++ (CDT) and use my "install workspace script" to generate the examples. It installs everything you need. Then import the projects into your workspace.
I need feature X, can you add it for me?
First ask yourself if it is really an os like feature. If so, you can request me by email to have a look at it. I will certainly not add anything which increases the footprint of the core. Optional code (like the Femto FS) can be added if the area of application is wide enough. In case of paid support, more is possible, but that code will probably not end up in the main codebase.
Are you planning to port this code to device X?
For the near future i plan to remove some of the limitations of the OS wich make use in larger systems difficult. This is the maximum stacksize for example. The maximum number of tasks will not be increased. The same applies for the maximum queue size, the number of priorities, the number of slots and some other parameters.
The first port will probably be to the ATmega2560, just because it is on my shelf. After that, i plan to port the OS to all devices with a avr core which are still in mass production, except probably the xmega's. These devices are so large, other operating systems seem to be more suited. This operation will take at least six months, since this is a spare time project.
Although possible, i don't think it is likely i will port this OS to other architectures. I will be more than happy however to assist anyone who wants to give it a try.
You changed the api again, this is unbearable!
Yes, and probably this will happen some more times in the future. The reason is that i want the api to one logical suite of calls. To that end it may be needed to change the names and calling conventions from time to time. For example, i think the UseBoolReturns has not much added value, so probably it will be gone in the next release.
Contact: info@femtoos.org