TinyAcorn 2.1

Form the very beginning tinyAcorn was designed to be as closed to its bigger brother megaAcorn as possible but in the long turn it turned out wrong.
Needless to say tinyAcorn is intended for small tiny AVR devices of up to 256 bytes of RAM. Code from megaAcorn was squeezed to fit the limited CPU resources but such strategy was quite inadequate.
The new tiny version is designed for small RAM devices and is coded as a different project.It is no longer possible to strip code slices off mega version and fit them into tiny one.

 

SLEEP macro processor.

It is obvious that having a sleep macro utilizing a separate Timer in a CPU with limited resources was quite inadequate.Most of the tiny AVR devices have only 2 timers and occupying both by the system was unacceptable.
It is clear that one timer is needed for the scheduler  but can we get rid of the second one.Yes! it is possible but we will have to assume some drawbacks. I have integrated the SLEEP macro processing in the scheduler which comes at some acceptable in my opinion price.

• Adds overhead to scheduling algorithm - 5 assembler instructions outside a loop(acceptable i think)
• Less precision in the sleep interval - each task sleep is round robin processed unless interrupt or descheduling happens and changes the start task round robin order in schedular.
• Biggest timer interval is smaller due to the fact that scheduler is activated in the realm of the microseconds.
• Sleeping task is given a quantum slice to check if interval has gotten to zero.The verification is NOT done by the scheduler thus preventing loop forever with interrupts disabled in scheduler(rememebr - the scheduler runs in an interrupt handler with all interrups disabled) if all tasks happen to be in SLEEP mode.

Now that Timer tick happens in the realm of the microseconds, how to get a real long sleep interval.The following code snippet demonstrate how a task could achieve longer sleep intervals through a loop enclosing the SLEEP macro.

Even longer intervals are possible if we use 2 byte variable instead of 1 byte one.

 

RAM layout fragmentation and new DEBUG definition.

There is an ongoing effort to make the kernel integrity easier to verify. The easier the verification,the more robust the program is, the higher the gratefulness from the customer....
In order to see how the _REGISTER_TASK macro fragments the RAM memory for each task, i have added an new DEBUG preprocessor definition to enable debug mode.If in DEBUG mode a debug marker of 0xAA will be added at the end of each task stack so that when the program code is simulated the RAM fragments of each task could be seen in Memory->Data window in AVR Studio. When debugging in AVR Studio, stepping through each _REGISTER_TASK macro.

the following memory fragmentation could be observed in Memory window

 

For tiny24(RAM - 128,Stack size for each task - 38), color markers are

• Red circle - marks the start address of the task,saved in the beginning the the tasks stack at device boot.
• Red marker(AA) - marks the end of the tasks stack
• Blue marker - free global RAM memory
• Green markers(from left to right) - current TCB address(LSB),TCB of Task 1,TCB of Task 2,TCB of Task 3,Simple Event structure.

 

Warning.

Needless to say DEBUG mode adds extra code lines to the program so - NEVER forget to comment out the definition during production.