RevolutionPi Simulator

It would be quite handy if we are able to fully test our application code on a simulator that we can make communicated with a project specific environment simulator.

Preparing an environment simulator (such as a pool with a water inlet which fills the pool and motor pump that drains it out) is our concern, obviously. But as the IO modules use a custom kernel drivers, the IO interaction of the modules should be simulated.

IMHO, A qemu image would be nice and IO module bus might be simulated by TCP/IP channel per IO module, so we could "write" our own IO simulations (the environment simulation) easily.

I would suggest we could simply build a "simulation Flag" into the driver so that it stops writing to the process image and does not generate an error condition when it does not find the IO modules during drive reset. Thus you would still have the process image reserved for all read/write operations but would need to write your own code to write inputs into teh porecess image and read outputs in order to make the simulation opreations with these values. How about that? Think we could realize such a solution quite easily.

If I get you correctly, you describe the same process when we write an application on a standard RaspberryPi which uses GPIO where we simulate GPIO somehow, right?

If so, this is absolutely doable, but a complete simulator would be nicer to have, so that:

* We don't have to touch our application code again.
* We could simulate full project environment so we can test a newer version of application code against to.
* We could implement features before getting a real RevolutionPi beforehand. (For example, I would like to implement a dcs-connector before buying a real RevolutionPi set to see if everything goes well with the kernel drivers)

Not exactly I think...
RevPi uses PiControl diver for 3 things:
1) Initializing the IO modules over the piBridge and reporting any error during modul detection and initialization (this would be ignored with simulation flag set)
2) cyclically polling the IO modules and gateway modules over piBridge and exchaning the data with the central process image (different tasks are running for RS485 and Ethernet communication, these tasks would not be started with simulation flag set).
3) serving any external requests (seek, read write and ioctl, these services would run normally) by exchanging the requested data with the central process image.

You application would normally only interact with 3) and may be also with error conditions of 1) but such conditions would be communicated over 3). So Applications would run as normal without IO modules being connected. And things should run close to hardware independence (I would not guarantee such independance as we do have plans to get the cryptochip involved in the IO communication - but in such case one could disable such hw-dependent accesses by setting the simulation flag ).

Your simulation software would need to fake any dependencies of IO process values by cyclically reading output values and writing input values. This part would be totally independent from you application and of course you could write an adaptor which would channel this cyclical data flow over TCP/IP and any external PC working as a IO simulator. But the adapter would need to be installed on your target system in orde to fake the data into / from the central process image. For the application this would be absolutely transparent ecause it could not decide wether the data is exchanged with IO (using 2) ) or if 2) is faked by the adapter and any simulation software. Of course you will need to keep an eye on timing and performance. If you application is time critical your simulation must have the same timing as piControl has (Cycle time, Jitter) which could be critical to establish.

Hope this makes sense...