Hello,
Yes - the OS we had was custom and used a non standard fieldbus protocol in the past. The old protocol did not set any requirements on the timing of the device. If the device was busy it only answered to special commands which where handled in an interrupt. Normal communication took place in the main loop where all calculations where performed.
Some time ago it was decided that we need to support additional fieldbus protocols and the project was limited in time and therefore most of the existing code base had to be used. The new protocol had timing requirements and we also needed to support reading values at any time. Therefore I worked on the operating system (C + 68k assembler) and added a preemptive multitasker together with some simple IPC primitives. This parts are finished and therefore at least theoretically available for a new design.
We are now in the need to support more devices in the feature and also have time and resources to rework and create bigger software components. In addition we want to move away from building our own OS ;). Maybe I could have told more about our already existing system but I think it is sometimes necessary to rethink old ideas. And I did not want to bias any of the opinions.
It is not possible that the communication task runs only when the currently calculated data has become stable (which is calculated during automatic measurements) because the calculation takes to long (will also take a lot of time on a fast CPU). Therefore we introduced some buffering to communicate the values from the previous calculation. Of course I was a requirement that both tasks only work on consistent data. Updating is therefore always done in atomic blocks and at well known times.
Right now they are linked as separate modules and do not know anything from each other. The only share a common header file with SHM keys.
But as most people suggested a Message-Passing solutions I think I will go away from the SHM approach and use a message passing system with three tasks where one tasks acts as a coordinator. This matches my requirements, is clear from the design and using a new OS I can use the message passing primitives from there.
Kind regards, Christian