Add I/O simulator


#1

It would be nice to have a way to create virtual switches and leds in the SDL simulator. This will allow to simulate some behavior like pushing external buttons or leds.


#2

this is a little to specific, wen i feel like jonne is working on bigger iseus and fixes to core library
also this wont cover I/O at all just some specific hat emulation (hats that havent been designed yet)

and it wont represent the pins properly anyway since you also need to consider all the interfaces, spi, pwm

id say just wait for the hardware to test these aditions
though if you just want to try more buttons, look into SDL_KeyboardEvent


#3

Multiple requests for this one. Will be done


#4

Awesome!
Obviously precedence goes to issues but I feel I/O sim is something Pokitto will benefit, as it has a native external interface. Even if the simulator will be vary basic, it will stimulate people to experiment with real hardware later.


#5

im not convinced of this, the core api needs allot of work, like sd card stuff and sound


#6

@adekto for sure that have precedence over the simulator stuff. But It’s nice that @jonne is considering the evolution of the software, even if months in future.


#7

This is the reason why I have set up the forum & been to 2 maker faires. The feedback we get is crucial to get everything working & to improve the product.

It is a work in progress, but we have been able to solve all problems so far. I am confident that we will do so in the future as well.


#8

Could we add just some dummy function in simulator to solve compilation problem in simulator for I/O handling like for example DigitalOut() or DigitalIn() ?
This will help developing some hardware iterations without using #directives .
Another side effects will be the ability to compile the examples in the PEX tutorials and allow to test the graphic result.


#9

It’s possible, but it might be quite a bit of effort depending on how much you want to simulate.

If it’s just the standard digital IO pins, mbed::DigitalIn, mbed::DigitalOut, and simulating LEDs, buttons and switches, then that’s probably doable.


#10

Just an empty container will be enough. Even without any GUI simulation, to begin.


#11

I’ve made a start on mocking the mbed API.

https://github.com/Pharap/MbedMimic/tree/wip

I’ll look into it more later.
I have to devise it in such a way that DigitalIn input(EXT0); is valid code,
and also give the similator a way of being able to read the state.
(And possibly even be notified of changes.)


Also I’ll have to check the mbed code licence later to check this isn’t a breach of the licence.


#13

@jonne, would it be possible to redefine P1_19, EXT0 etc for the simulator, or would that interfere with something?

If redefining P1_19 etc wouldn’t interfere with the simulator then I can just cut out the entire gpio_t layer, create a fake PinName class and make all the pins global objects that can be passed to fake DigitalIn/DigitalOut classes in the constructor.

Something like this:
https://github.com/Pharap/MbedMimic/tree/wip-2


Also, (partly aimed at @HomineLudens,)
would the following need to be accurately simulated?

  • Pin connectivity
  • Pin mode
  • Pin direction

#14

Things may escalate quickly. I think no. The main reason to ask an implementation on simulator is to have the same code run in code:blocks and embitz/mbed online.
If future development will introduce some kind of virtual electronic lab (very unprobable I suppose) every should be take in consideration. But as said that’s a little probability that will take a lot of effort.


#15

In that case, as long as it’s legal to redefine the current pin values then my current system in the wip-2 branch just needs to be bolted into place and then it can be used as a back-end for the UI representing the IO.

I started trying to make it even closer to the actual thing, but it turns out there’s at least 3 levels of indirection underneath the DigitalIn/DigitalOut stuff, and I couldn’t be bothered to dig that deep at the moment.