weAutSys is a runtime for small network enabled and µ-controller based automation modules like weAut_01. weAutSys's version in hand is for Atmel ATmega µ-controllers, that is a Harvard RISC machine.
See the introduction for more details.
As RAM is a precious resource in most µ-controllers it is recommended to confine constant structures, invariant strings and arrays etc. to program or "flash" memory. But alas, albeit designed for hardware / system / core related programming (and in the proximity / as a better substitute for assembler) the C programming language was never made fit to handle memory architecture features like segmentation (Intel) or Harvard (ATmega).
And most C implementations, like the GNU C Compilers and tools (GCC) used here, do not mend these deficiencies. To handle ATmega's Harvard architecture one has to use the ugly helper constructs (<avr/pgmspace.h>) instead of just writing plain C assignments and references. Having to handle ATmega's Harvard architecture with add-ons has side effects to other tools, certain Doxygen problems being one / the least of them.
The second scare resource with low electric power consumption µ-controllers is processing time. Therefore more people than one may believe tend to use Assembler more than C. This might have made sometimes sense in the past. The reasons to make weAutSys with C are:
a) Clever algorithms are the easier to implement the higher the language level.
b) Compiler technology is quite advanced now. GCC for AVR does clever instruction and register usage — sometimes to an astonishing extend and anyway better than a human could provide in Assembler over a whole project.
But b) is, most regrettably, not true in all (algorithmic / syntactic) circumstances. If reading the generated code uncovers a total flop not remediable by changing C constructs the "in line Assembler" is used locally and sparingly. GCC's inline ASM is obstinate and no fun at all to use. On the other hand it fits in or does not break C Compiler optimisations.
So the weAutSys runtime is an almost pure C project.
Modules | |
+ + System services (threading, time keeping, communication) + + | |
+ + Application (layer) support + + | |
+ + Utilities and helpers + + | |
+ + Process I/O and HMI functions + + | |
+ + Low level system services + + | |
+ + Bootloader support + + | |
Defines | |
#define | EEP_SIZE (E2END + 1) |
The EEPROM size in byte. | |
#define | USE_BOOTLOADER USE_BOOTLOADER_PRESET |
Have and use a bootloader. |
#define USE_BOOTLOADER USE_BOOTLOADER_PRESET |
Have and use a bootloader.
This value determines the existence and usage of a bootloader:
0: no bootloader or at least no bootloader integration 1: bootloader area used / bootloader existing 2: bootloader fully integrated: application programme may use all No Read-While-Write (NRWW) flash section functions and constants.
Fully integrated means that all µController resets go through the bootloader and the bootloader will not enter the program (=x00000) without having done all basic initialisations. The latter hence can be omitted from system/application software. Full integration also means that the bootloader may be entered by (CLI) command.