Simulation API - Suggestions and Requirements

[pgrawehr]

We have several PRs suggesting the addition of a simulation GPIO Driver to simplify development and testing without actual hardware (see #1827 and #1823). The team has agreed that such a simulation is desirable, but it should include, at least as possible further extensions, simulation components for other hardware interfaces, particularly I2C, SPI or PWM.

Suggested class structure:

namespace Iot.Devices.Simulation
{
    public class SimulationBoard : Board
    {
        // ....
       public override GpioController CreateGpioController()
       {
           return new GpioController(PinNumberingScheme.Logical, new SimulationGpioDriver(NumberOfPinsToSimulate));
       }
    }

    public class SimulationGpioDriver : GpioDriver
    {
    // ....
    }

    public class SimulationI2cBus : I2cBus
    {
    // ...
    }
    // ....
}

To simulate the behavior of the actual hardware, the simulation devices should have a "backend" interface that allows connecting a simulation implementation, either by having events to connect to, such as showcased here, or something like a REST api to connect an external simulation Gui to. That simulation GUI could then simulate the wiring between inputs/outputs or simulate devices on the I2C bus.

Suggestions or improvements?

I do not expect that a first implementation would be able to support all cases, but it shouldn't block further development towards such a scenario.

@HumJ0218 @mcNets

[HumJ0218]

I planed to add a vSPI device after vGPIO. It will provide many CE lines(can be customized) and 2 streams to simulate input and output.

[HumJ0218]

I think vI2C would provide 2 streams too.

[HumJ0218]

But I can't imagine how to simulate the behavior of PWM. My first reaction was that PWM didn't seem very necessary.

[HumJ0218]

REST API may not be suitable for these scenarios with active push data capabilities.

I think it's only necessary to set aside the most basic backend that is closest to the hardware itself. And how to use these interfaces is left to the user implements.

[HumJ0218]

Regarding PWM, before designing simulation, we may think about how to express a device with a PWM input.

Is there any chip that can receive PWM signal input?

[HumJ0218]

vGPIO can respond in real time. But I'm not sure whether vSPI should add a delay in IO operations according to the characteristics of the hardware or ignore this feature to do it directly in real time.

[pgrawehr]

PWM has two main uses: control the brightness of a LED (for instance when used as a LCD backlight) and for controlling servo motors. It's probably not the most important piece to simulate, but shouldn't be forgotten.

I'm basically fine with not having the simulation implementation right now, but I still think the interface should allow the simulation to be as much as possible separate from the actual program under test. You might not want to have the implementation of all simulation hardware in your control application. You're right, REST does not support push messages. Is there a similar protocol that does?

[mcNets]

Hi, whatever interface you add will require a server and a client component. At least for Windows I was thinking to add some kind of config_io.json file describing the signals schema. And then use this file to automatically build for example a UWP/WPF/WinForm client window, or why not a REST API or gRPC service.

[pgrawehr]

@mcNets Yes, that was my idea as well. Ideally, that schema would be created from a frizzing schema, but I do not know whether there are any useful output formats to get a machine-readable signal schema from that. And it might quickly get very complex, we probably don't want to write a full signal simulator.

[mcNets]

@pgrawehr would you mind to have a look at this: Virtual scenario maganagers and tell me what's your opinion?

[pgrawehr]

@mcNets That looks promising. I like that it generates the GUI automatically from a configuration.
I guess it will be possible to add a feature to configure the GUI from some configuration file (json or XML) instead of code?

What I don't like so much about your approach is that it requires the simulator with the gui to be built into the target application. I would rather have the GUI in a separate application that communicates with the target application over some network protocol. The GUI wouldn't even need to run on the same computer (note that WPF is not available on linux-based devices).

This would make it possible to distribute the simulator pre-built and the configuration would be done at runtime.

[mcNets]

@pgrawehr
Right now I'm using this driver in a Uno Platform application that runs on Windows and a modified version of Raspbian.
Check the link: https://youtu.be/Ht-GXsoa5CA
For the separated application what do you have in mind?
Would be acceptable a multiplatform app build for example with Uno or Avalonia?

[pgrawehr]

@pgrawehr Right now I'm using this driver in a Uno Platform application that runs on Windows and a modified version of Raspbian. Check the link: youtu.be/Ht-GXsoa5CA For the separated application what do you have in mind?

I didn't think much of the Gui part actually. I wouldn't care about the technology so much there. More relevant is probably the RPC tool to use, because that will most likely result in a run-time dependency on some library (e.g. gRPC). Do you have experience with RPC libraries?

Would be acceptable a multiplatform app build for example with Uno or Avalonia?

For me, that would be Ok, but the Microsoft guys would probably prefer Maui. I don't know how far it's linux support is at the moment, though. I can ask around.

[mcNets]

There is a separated repo for the linux part of MAUI. I've made some tests with gRPC but it requires a web server at least in Windows, like kestrel o IIS, and I don't know the requirements for Linux. But let me think about it, I'm about to finish my current project at work and I think I'll be able to spare some time for this project.

[pgrawehr]

Sounds good. Of course it would also be possible to use a "bare bone" TCP connection or something, but that's eventually more complex than to use something existing.

[krwq]

ref: #383

[pgrawehr]

From @raffaeler's suggestions on #383:

The goals for this proposal:

• ability to mock all the devices for testing purposes without having to use Moq or similar frameworks
• ability to log the sequence of I/O writes
• ability to create a framework to replay a sequence to simulate a complete I/O handshake without any connected device
• ability to run the application on a host which doesn't have any device connected. For example, this is useful to test the other parts of the application on Windows and later run the real one on the embedded board.