The incredible GenBoard/VerThree and the under construction VemsFrontier/Boards have incredible potential. To utilize these, advanced handling of data is required

This page is for software developers.

building blocks:




We have all the above, we just need to mix them somehow.

Simple, isn't it? Probably some kind of

Preprocessor might be more powerful than we think. After the

getDog() will be a macro that gives a variable from RAM (lightning fast) in the simplest case, and maybe does some administration. setGiraffe() might just store to RAM, or maybe it pushes onto a communication buffer to be sent to a remote node. It might need to schedule some event if the calculation output was input for scheduling (like the tooth algorithm's input is toothcnt/engine phase and rpm_period; result is if scheduling is needed yes/no and if yes, when).

In any case, the algorithm should NOT hardcode the inputs' and outputs' location.

The (by user) declaration of connections is very important, as that will decide where the input comes from and what needs to be done with the result. (generation of some header files automatically from user declared data)

Utilizing the compiler means the code can be lightning fast, it's just not 100% human written.

The static connections are not too bad. With proper aggregator modules redundant systems can be realized. Eg. a module receives 3 temperature inputs and confidence value for each. It's output is the best-effort data: if some of the input data is missing because of sensor railing or communication failure (confidence=0) or outage, the module cooks from the available data. (=> dynamic behavior even though only static references are used).

The problem with static connections is that serious changes of the system requires reflashing, not just change of configuration-data (interpreted, EEPROM) memory. Well, that's acceptable. With ARM the input-output lookup interpreter can handle more speed.

See also