Since single PicoMite firmware is now pretty much complete I though it would be fun to look at connecting PicoMites together. Attached is some experimental firmware for the RP2350 VGA and the RP2040VGA.
To run the code you need to connect two PicoMites together with 9 GPIO lines + GND. I recommend using GP0-GP7 for the data and GP22 for the clock as per the test program below.
Run the host program on one PicoMite and the client on the other. Doesn't matter which order. You will see the GUI TEST pattern running on the host magically appear on the clients VGA display. Note, All this code runs in the background under PIO/DMA control without any processor involvement. To stop and rerun you must first close the background activity using MEMORY SHARE STOP
Note that with two PicoMites running at 252MHz the data trasfer rate is  84 Mbytes/second
Note also: that the client PicoMite is fully usable at the command prompt even though its display is being written by the host.
Finally note: The HOST and CLIENT commands are blocking until the synchonisation has happened. After that everything takes place in the backgound

PicoMiteVGAEXP.zip

Client code


Host code:


MEMORY_SHARE_User_Manual.pdf
Edited 2026-04-01 19:13 by matherp

---

Like the Idea  

Nice feature.. What use-cases did you have in mind? Sharing e.g. the screen-buffer and have "dual-screen" this way? Or 1 Pico for measurements and GUI and an other for networking?

Lots of possibilities. The demo would allow dual screen by exporting a framebuffer over the link and having the local display with something else on it. So far it is just a proof of concept. Getting the synchronisation to work was the challenge.

Holy heck

But limited to two devices, right?

The downside is that you have to "sacrifice" 8+1 GPIOs.

Couldn't this also work with 4+1 GPIOs, like with QSPI?
Perhaps make it selectable as a parameter at the end of 'MEMORY SHARE HOST/CLIENT'?

The data rate is high enough that real-time video transmission would be possible – presumably even with 4 data bits.

Additional question: Can one pico be both HOST and CLIENT simultaneously? Of course, with separate lines! Then duplexing or "daisy-chaining" across multiple picos would be possible.

G'day Peter,
Very interesting idea, the grey matter is already churning with possibilities...

If you are exploring connecting PicoMites together, would you consider the following for less demanding applications?

We have the standard PicoMite with USB, and we have USB PicoMites with a USB host, and the Tiny USB firmware is able to work with CDC. If a serial link was possible across this USB link we could have all the pins of both picomites accessible while we swap data between them.

This also makes dataloggers and keypads / gamepads / CNC possible by just plugging in a USB cable.

This has been on my wish list since the USB firmware was first announced.

Many thanks once again.

Regards,
Lyle.

FWIW, I have always liked the Round-Robin method: Scalable, only two pins, read/write:


High Speed Prop to Prop.zip


BeauNET Test Code.zip

Round-robin works fine but it's asynchronous and therefore inefficient. Efficiency gets even worse as the number of nodes increases. If processor n sends a packet to processor n-1 the packet has to go round the complete loop, yet from n-1 to n it's almost instantaneous. For better efficiency you really need a common clock signal as well as a data line between each node, otherwise the clock has to be extracted from the data stream in real time. Synchronous operation also allows multiple packets on the ring without collisions.

I2C, even though the clock speed may be lower, can sometimes give much faster data transfer as packets go directly to any node on the system, rather than having to be passed round. You do have the collision problem though on multi-master systems.

I was gonna calculate but I always get something wrong  

But the above, on a 20MIPS processor (80MHz, 4 clocks/instruction) achieves 8.42Mb/s.

What would the Pico achieve,do you think?

BASIC command execution granularity, ~5µS?

Only guessing  

  PhenixRising said  

FWIW, I have always liked the Round-Robin method: Scalable, only two pins, read/write: ...

RS485 works well as an interface between two or more computers, and is also very fast (with high bit rates) over long distances. Ethernet 10bast-T uses essentially the same physics for transmission (differential signals) over the line. RS485 can also be multi-master (with token passing or CSMA/CD). Many USARTs support a 9-bit mode, where the parity bit can be used to distinguish between address and data bytes.

  bfwolf said  

RS485 works well as an interface between two or more computers, and is also very fast (with high bit rates) over long distances. Ethernet 10bast-T uses essentially the same physics for transmission (differential signals) over the line. RS485 can also be multi-master (with token passing or CSMA/CD). Many USARTs support a 9-bit mode, where the parity bit can be used to distinguish between address and data bytes.

I have been using 4-wire (full duplex) RS485 for many years. Never had a single glitch, no checksum errors, nothing. Only 230KBAUD over 15 metres, though.

Found an interesting page about RS485:
https://resources.altium.com/p/serial-communications-protocols-rs-485

About max. data rates there:


So over 1000m allowed at 0.230Mbps and 20m at 20Mbps !!!
(If suitable cables are used and correct termination is ensured)

I'm waiting for an excuse to try this  

When I saw the title of Peter's post yesterday, I initially thought it was going to be an April Fools  

Just keep getting suprised (in fact amazed) by what's happening here...

IanT

  IanT said  

Just keep getting suprised (in fact amazed) by what's happening here...

Ditto. Definitely the most exciting development in the MCU world and with documentation that is second to none