Multiple MCU Capability

[rcwilcox]

Add capability to simulate multiple MCUs in a single simulation diagram.

Possible Use Cases:

• Prototype multi-processor systems - e.g. Multiple Slave MCUs processing sensor data (DSP algorithms, predictive filters for raw IMU inputs etc.) that would provide preprocessed data back to the Master MCU.
• Simulate H/W not (yet) available as a Wokwi part. e.g. a MAX7219 could be simulated with a MCU board (or a bare bones MCU chip if that were available) to scan and decode LED outputs.

[urish]

This one seems quite popular already, so I'm sharing some thoughts about the implementation challenges:

• Performance - right now, we can a single-core 16MHz AVR MCU simulation usually runs at 100% on modern hardware. RP2040 (at 125MHz) runs at about 33% on my hardware here, which is pretty powerful. Running multiple MCUs simultaneously will drop the performance even further. This can be mitigated by carefully writing the user code - putting the MCU to sleep when idle, or by dropping the MCU speed (e.g. using the clock prescaler on AVR).
• Code - I assume that for most use cases, you want different code to run on each MCU. We need to come up with a way to define several "subprojects" in each project, and associate each to a microcontroller. Any proposals here?

For "Simulate H/W not (yet) available as a Wokwi part" - multiple MCUs is one way to achieve this. Another approach I'm looking at is using Web Assembly (perhaps together with AssemblyScript). It'll be more performant, but comes with its own set of challenges. So perhaps multiple MCUs support can give us a quick win here.

[dommilosz]

We can create option in diagram.json to configure the MCU speed. I think even 20MHz for RP2040 would be enough for most applications and maybe we can go even slower. For the code problem it can be also set in diagram.json as entry point file. Adding directiories could also help. In single MCU system code would be compiled like it is already. If we add more MCUs the ones with other IDs would have to have code in folder mentioning their id.

diagram.json approach

{
      "type": "wokwi-pi-pico",
      "id": "pico",
      "top": -1.33,
      "left": 6.67,
      "attrs": { "env": "arduino-community" },
      "speed": 10000000 (10MHz)
      "code": "sketch.ino" (optional, without it behaves like it is now)
},
{
      "type": "wokwi-pi-pico",
      "id": "pico2",
      "top": -1.33,
      "left": -100.67,
      "attrs": { "env": "arduino-community" },
      "speed": 10000000 (10MHz)
      "code": "sketch2.ino"
}

directories approach (speed still in diagram.json)
1 MCU:

/sketch.ino
....

N MCU:

/sketch.ino (code of the first MCU with id: pico)
/mcu/pico2/sketch.ino (code of MCU with id:pico2)
....

It would be great to have multi MCU simulation. It would greatly increase speed of prototyping various multiple MCU systems. Like testing I2C between MCUs. Compilation time on wokwi is faster than on my pc for rp2040 and also not including time to restart every one of them to bootloader and compile each separately.

[urish]

Thanks for the feedback and suggestions!

Directories probably make more sense, as projects often consist of multiple source files (e.g. the libraries.txt / library manager tab). Some of the projects use Python or non-Android SDKs (like the Pi Pico SDK), so they require different kind of treatment.

As far as slowing down the clock - unfortunately, it is not as simple. The code that is running inside the simulation has also to be aware of the slower clock, otherwise things like delay() will take longer than expected.

In the meanwhile, custom chips (#301) should provide a way to create custom I2C devices (also SPI, UART), so they may be useful for certain scenarios. And they have good performance too.

Great to hear you are happy with the developer experience on Wokwi.com :-)

[dommilosz]

In Arduino IDE there is option to change the clock. Also F_CPU define may help. Other option is to inject code changing cpu speed. In rp2040 you can do it and delays still work fine I think.

[leftCoast]

Leave the project & window as a single , as it is now. Just add a "connector" item that allows you to connect to another project in another browser tab/window. This would cause that other window to be able to run in the background.

The connector would just connect wires.

[urish]

The connector would just connect wires.

It's a creative idea, but "just connecting wires" is unfortunately not feasible. To find the voltage on the wire (high/low), the simulator has to look at everything connected to this wire. Different browser tabs communicating by passing messages, which has high latency (we can get around 100 messages per second, often even less). So the simulation will be very very very slow if it'll have to wait for the two tabs to talk every time it has to figure out the state of the wire (imagine driving an Uno down from 16MHz to 100Hz... that kind of slow)

[leftCoast]

could we just bounce a couple bytes off a server?

[urish]

could we just bounce a couple bytes off a server?

How exactly?

[leftCoast]

How? Err..

The "connector" stores a URL, login, password & ID to its mate from another simulation. It uses this to store any changes on its input pins to that file. Then reads the matching file for changes and stores them locally.

It would probably be slow, yes. But, it would be a start. And it's not limited to 2 processors. Heck, it could be any amount if them on any machine. It might be a fun thing to play around with.

-jim