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:
- measured data
- calibration data
- calculated data
- output signal (normally this is calculated data, but used to actuate output)
- administrative data (creates connections among the above)
- counters
operations:
- sampling (ADC) to acquire measured data
- algorithms to turn measured data into calculated data
- output actuation (see users of the interpreter GenBoard/Manual/DigitalOut, like RPM-based actuation)
- sending-receiving over the network
- logging (special case of sending ...)
- administration of metadata (like changing config), special case of receiving
- filtering, aggregation (special case of algorithms)
- other tasks (like LCD; special case of output actuation)
Dependencies:
- what input and output needed for a given alg.
time-related:
- frequency of sampling; info on when it happened
- frequency for how often (when) a result is required
- other condition of starting a specific processing
- priority (when resources are scarce)
- events (serial number of a given event, like fuelcalc, handler2k run, etc..) and followup actions (like log each ignition event and it's associated time and ignadv)
We have all the above, we just need to mix them somehow.
Simple, isn't it? Probably some kind of
- interpreter and
- scheduler is needed
- modeling on PC that helps parametrize and visualize what's happening
- preprocessor
Preprocessor might be more powerful than we think. After the
- user somehow declared what connections he want (assuming these connections are static), the algorithm code might be as simple as
- initializing local variables from getters: uint8_t dog = getDog(); instead of dog = zoo_t.dog;
- at the end of the algorithm the result needs to be sotred like: setGiraffe(...)'
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