 Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me. |
Forum Index : Microcontroller and PC projects : High speed dual PicoMite memory sharing
| Author | Message | ||||
| matherp Guru  Joined: 11/12/2012 Location: United KingdomPosts: 11121 |
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 ' ShareClient.bas - MEMORY SHARE CLIENT test program ' Runs on RP2040 PicoMite VGA (PIO1 available) ' ' Wiring (directly between two Picos): ' Host GP0-GP7 --> Client GP0-GP7 (8 data lines) ' Host GP22 --- Client GP22 (shared clock) ' GND --- GND ' ' Either host or client can be started first - handshake is automatic. MODE 2 Dim addr% = MM.Info(writebuff) Print "MEMORY SHARE CLIENT Test" Print "Shared buffer at address: &h" Hex$(addr%) Print "Buffer size: 38400 bytes (100 integers)" ' Start receiving: PIO 1, SM 0, data GP0, clock GP22, address, 38400 bytes ' Note: client clock pin (GP22) connects to host clock pin (GP22) via wire Memory Share Client 1, 0, GP0, GP22, addr%, 38400 End Host code: ' ShareHost.bas - MEMORY SHARE HOST test program ' Runs on RP2040 PicoMite VGA (PIO1 available) ' ' Wiring (directly between two Picos): ' Host GP0-GP7 --> Client GP0-GP7 (8 data lines) ' Host GP22 --- Client GP22 (shared clock) ' GND --- GND ' ' Either host or client can be started first - handshake is automatic. MODE 2 Dim addr% = MM.Info(writebuff) Print "MEMORY SHARE HOST Test" Print "Shared buffer at address: &h" Hex$(addr%) Print "Buffer size: 38400 bytes" ' Start sharing: PIO 1, SM 0, data GP0, clock GP22, address, 38400 bytes, clk_div 3 Memory Share Host 1, 0, GP0, GP22, addr%, 38400, 3 GUI test lcdpanel End MEMORY_SHARE_User_Manual.pdf Edited 2026-04-01 19:13 by matherp |
||||
Plasmamac Guru Joined: 31/01/2019 Location: GermanyPosts: 608 |
Like the Idea  Plasma |
||||
| bfwolf Senior Member  Joined: 03/01/2025 Location: GermanyPosts: 205 |
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?  |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 11121 |
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. |
||||
| PhenixRising Guru Joined: 07/11/2023 Location: United KingdomPosts: 1807 |
Holy heck  But limited to two devices, right? |
||||
| bfwolf Senior Member Joined: 03/01/2025 Location: GermanyPosts: 205 |
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. |
||||
| mozzie Senior Member Joined: 15/06/2020 Location: AustraliaPosts: 245 |
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. |
||||
| PhenixRising Guru Joined: 07/11/2023 Location: United KingdomPosts: 1807 |
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 |
||||
Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 8713 |
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. Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| PhenixRising Guru Joined: 07/11/2023 Location: United KingdomPosts: 1807 |
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 |
||||
| bfwolf Senior Member Joined: 03/01/2025 Location: GermanyPosts: 205 |
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. |
||||
| PhenixRising Guru Joined: 07/11/2023 Location: United KingdomPosts: 1807 |
 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. |
||||
| bfwolf Senior Member Joined: 03/01/2025 Location: GermanyPosts: 205 |
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) |
||||
 Print this page |
 |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2026 |
