A Serial to Websockets device

[Koepel]

Feature request: A special device with RX and TX pins that connects to a websocket. A Python3 script could be the websockets server and connect to a serial port on the computer.

If that is possible then a interface to a device (for example a scale with a serial port) can be developed from within Wokwi. It would also be possible to have a real Arduino board communicate with a simulated Arduino board.

[urish]

What if the Serial Monitor RX/TX were available through a web socket? Would that also do the trick?

[Koepel]

A serial duplex communication to the real world would be a dream come true. I hope you don't mind, but my feature request aims higher.

It is the same as connecting a Bluetooth or GPS module to pin 0 and 1 of a Arduino Uno. It works, but then a LCD display should be added to show messages.
Developing a interface to a serial scale depends heavily on the Serial Monitor.
Suppose a real Arduino sends real sensor data to a simulated Arduino. Then I would like to see the data in the Serial Monitor.

[sutaburosu]

I think UART <-> websockets would be very useful. I would definitely look at extending my Python proxy to be bi-directional and less focussed on transporting only LED data.

I think a library such as VSync may be useful. It provides a simple mechanism to sync variables between two sketches. It only supports ints currently.

[urish]

Note: there's now an experimental support for connecting to an actual Serial port. Here's an example:

https://wokwi.com/arduino/projects/306534287811805760

Only works on Chrome / Edge (other browser do not support the Serial API, and it's not very likely to change in the foreseeable future).

You can also use a virtual serial port driver (such as com0com on Windows) to make your Wokwi project speak to another software on your computer (or to a different wokwi sketch)

[urish]

This one got high in the feature list, so it's a good time to start discussing the implementation.

One way would be to extend wokwi-serial-port (mentioned in the previous comment) to support web socket connection in addition to a real serial port, as a configuration option.

For instance, we could add a "url" or a "websocket" attribute that would point at the URL of the web socket. Something along the lines of:

    {
      "id": "serial",
      "type": "wokwi-serial-port",
      "attrs": { "websocket": "ws://localhost:1234", "baud": "115200" }
    }

Then, there's also the question of how we encode the data that goes into the socket. The most straightforward way would probably be to pass the binary data as-is, unmodified. We might need to introduce some buffering, as WebSocket are not stream-oriented. They break down the data into messages, and each message gets a 6 bytes header (client -> server). So sending every byte in a message would add a considerable overload, and might slow down the simulation (if we're running at 115,200, this would mean more than 10,000 messages per second).

[Koepel]

A device (such as the Logic Analyzer) could be connected to SoftwareSerial for example. Is the decoding of the serial signals possible ? What if the option to use multiple Arduino boards is implemented first and the websockets device uses parts of a Arduino Uno for the serial signals ?

The existing implementation of the serial port via the Serial API of the Chrome browser has a few limitations.

The data has to be exactly the same (binary) data of course.

When Serial.println( "Hello World") is used, the Serial.write() calls follow each other very quickly. Buffering with a small timeout should be enough to capture the whole message.
If a message is split into two parts or if messages are combined, that is no problem. It is just a stream of serial data.

[urish]

A device (such as the Logic Analyzer) could be connected to SoftwareSerial for example. Is the decoding of the serial signals possible ? What if the option to use multiple Arduino boards is implemented first and the websockets device uses parts of a Arduino Uno for the serial signals ?

It is possible indeed. You can also redirect the built-in Serial Monitor to different pins, and use SoftwareSerial on these pins. There's a guide explaining how set up the Serial Monitor with ATtiny85 + SoftwareSerial, but you can use the same process for the Arduino as well.

So for that part we're all set.

[yepher]

This would be awesome for me to use the simulator to develop this project I am working on. if you visit that GitHub project do yourself a favor and click on the image with the TV in it (few second youtube video) :)

My vote for the "special device" would be an FTDI (or CH340 etc) board. The USB port would represent the websocket interface. You could start with just defining the websocket encapsulation protocol and let folks implement their translation in their language of choice. Or just lean on one of the many existing solutions like go-serial-websocket. This way the simulator could talk to localhost or some publically accessible webserver with the physical port.

To test you can just connect two actual FTDIs TX->RX and RX-TX boards to your computer and have the serial console running on one and the other is the other one the server drives.

Or.... It would not be all that hard for someone to write the server to provide a virtual serial port so you can connect any old serial console to it to interact from your keyboard.

Nice thing if the reference implementation is implemented in GO there are no other dependencies a user would need on their computer to run the app and it is super easy to provide binary from many different platforms (Windows, Linux, Mac).

Please ignore that I screwed up the wiring to the FTDI interface, it should be TX->RX and RX->TX :)

[yepher]

In case you want to use it I drew up the Ada Fruit FTDI Friend

30mm x 17mm SVG file:
FTDIFriends.svg.zip

The parts are grouped in the SVG so the name in the left panel in this image is the name of the ID in the SVG. This video also demonstrates the proportions to the actual physical board.

Sorry I did not add it as an element and create a PR... I am still coming up to speed on all that..... And I am not sure this is the direction you would want to go. I will be glad to fix all the spacing issues in the drawing if it would actually be useful.