Sming Device Emulation

[mikee47]

Picking up from #1333 I've opened this issue so we can have a discussion about how to develop and test on the Host emulator with real devices. For example:

• UART (RS232, RS485, MODBUS, etc.)
• SPI
• I2C
• Digital I/O
• Analogue I/O

Virtual serial terminals are supported by redirection over network sockets. The code to do this (in Sming/Arch/hostlib/uart_server.cpp) and eventually should be updated to allow use of host serial ports directly. That will allow direct connection of most serial devices.

The emulator should be able to run on devices like the Raspberry PI, with integrated peripherals which could be used. However, it would make more sense to use the actual peripherals on the target device(s), Esp8266 or Esp32. This could be achieved by running a stub program on the device itself which communicates with the emulator via serial or network ports.

The stub needs to include all the timing-sensitive code so that the speed or latency of the host link can be accommodated. Using SPI as an example, we'd handle a transaction like this:

• Buffer up a transaction (begin / read/write / end)
• Serialise the transaction via network/serial
• De-serialise on the target
• Execute the transaction
• Serialise the result back to the host

Basically it's RPC. Specifically, take a look at CORBA.

If we can devise a generic RPC framework for the emulator, the user tasks would be reduced to this:

• Design an abstract interface class
• Implement the class on the target (the 'stub' class) to interact with the hardware
• Implement the class on the host (the 'proxy' class)

In fact, with the right tools we don't have to write the last one at all, it can be compiled directly from the interface class definition. Our framework takes care of marshalling the data over the network/serial connection at both ends.

This would allow us to arbitrarily run some of the code directly on the target hardware, with everything else running under the emulator.

[mikee47]

One further thought about how this might look. Let's say our application contains MySpiDeviceClass to talk to some device or other via SPI. We can't emulate this, so instead we want all calls to that class be executed on the target device.

1. Build the application as a stub:

make SMING_ARCH=Esp8266 STUB_CLASSES="MySpiDeviceClass"

2. Build the application in host mode, tell it which classes are to be proxies:

make SMING_ARCH=Host PROXY_CLASSES="MySpiDeviceClass"

Can dream, can't I?!

[slaff]

Specifically, take a look at CORBA.

I haven't heard about CORBA since my university days and that was long ago :).

Can dream, can't I?!

Go for it ! Overall I like the idea a lot and can volunteer with testing it on Esp8266 devices.

[mikee47]

My experience is actually with Microsoft's (D)COM, but as it's Windows-only won't help us. It has it's own compiler and language for defining interfaces, with a lot of features we don't need. For this I'd prefer to find a way to annotate existing classes to achieve what we need. Our tool then uses existing source code as the definition. Know anything like that?

[mikee47]

This looks interesting https://github.com/EmbeddedRPC/erpc

[slaff]

Let me throw here some more: http://jpa.kapsi.fi/nanopb and some more information how to incorporate it from the PDF slides. You can jump directly to page 17.