TheBackShed.com

Forum Index : Microcontroller and PC projects : Memory share with other devices

Posted: 08:07am 25 Apr 2026 Copy link to clipboard	fred777 Regular Member

Hi there,
would it be possible to feed parallel data to a pico running
Memory share client from a non-pico device?
For instance feeding external pixel data into the frame buffer?

Posted: 08:40am 25 Apr 2026 Copy link to clipboard	matherp Guru

In theory - yes. You will need to read into Memory.c on github to understand the synchronisation protocol needed to start the transfer. Briefly it works like this:

Quote Host-Side Synchronisation Protocol
Phase 1 — Clean state (share_prepare_start)
Before anything else the host:

Disables and restarts the PIO state machine, clears its FIFOs
Aborts both DMA channels and waits for the abort to complete
Reinitialises all data pins and the clock pin as plain SIO GPIO inputs with no pulls
This guarantees a known idle bus regardless of any previous share session.

Phase 2 — PIO program and DMA wired up (but not started)
The host builds a 2-instruction PIO TX program in RAM:

instruction 0: out pins, <width> side 0 ← push data nibble/byte, clock LOW
instruction 1: nop side 1 ← hold, clock HIGH
It wraps back to instruction 0 continuously.

Two DMA channels are configured:

Data channel: reads 32-bit words from the MMBasic shared memory block → PIO TX FIFO, paced by the PIO DREQ, transfers count/4 words, then chains to the control channel.
Control channel: resets the data channel's read address back to the start of the block and retriggers it — creating a perpetual loop. Neither channel is started yet.
Phase 3 — Handshake sync (share_host_sync)
This is the rendezvous with the client. All done with plain GPIO (no PIO), so it can block indefinitely and is user-abortable.

Step Host action
1 Set clock pin as output, drive it LOW
2 Set lower half of data pins as outputs, drive the host pattern: 0101 (8-bit) or 01 (4-bit)
3 Set upper half of data pins as inputs
4 Spin in share_wait_loop() reading the upper pins until the client's complementary pattern appears: 1010 / 10
5 Once the client pattern is seen, hold for 1 ms so the client also has time to read the host pattern, then return
The client does the mirror image: it drives the upper half, reads the lower half, and waits for 0101/01. The two sides unblock each other simultaneously.

Phase 4 — Post-sync wait (5 ms)
After returning from sync the host waits 5 ms before touching the pins again. During this window:

The clock pin is still a GPIO output held LOW (SIO function).
The client is switching its pins from SIO mode into PIO receive mode and arming its wait 1 gpio CLK instruction.
The client's PIO will block on "wait for clock HIGH", so the transition is safe as long as the host doesn't release the clock before the client is ready — the 5 ms margin covers this.

Phase 5 — Pin handover to PIO

data pins → GPIO_FUNC_PIO*, direction = output
clock pin → GPIO_FUNC_PIO*, direction = output
The data pins are handed to PIO while the clock is still LOW. The SM is then cleared, restarted, and enabled.

The first instruction the SM executes is out pins side 0, which drives clock LOW and pushes the first data word onto the bus. The client's PIO is waiting for clock HIGH (wait 1 gpio CLK) so it doesn't latch anything until the second instruction (nop side 1) raises the clock.

Phase 6 — DMA triggered, streaming begins

dma_start_channel_mask(1u << SHARE_DMA_CTRL);
The control channel fires immediately, which retriggers the data channel. The data channel starts pumping 32-bit words from the shared memory block into the PIO TX FIFO. PIO pulls words from the FIFO and clocks them out one nibble or byte per clock cycle, looping forever through the block.

Summary timeline

Host: [prepare clean] [build PIO/DMA] [drive 0101, wait for 1010] [hold 1ms] [wait 5ms] [hand pins to PIO] [start DMA]
↑ phase 1 ↑ phase 2 ↑ phase 3 ↓ ↑ phase 4 ↑ phase 5 ↑ phase 6
Client: [drive 1010, wait for 0101] [hold 1ms] [switch to PIO RX] [wait CLK HIGH → latch data]
The key design choice is that the PIO programs contain no startup logic — they are pure streaming state machines. All the "are both sides ready?" negotiation happens in software using plain GPIO, keeping the PIO timing deterministic once streaming starts.

Posted: 08:51am 25 Apr 2026 Copy link to clipboard	fred777 Regular Member

Thanks for the great explanation!
If I understand this correctly, the clock speed
after the setup is completed doesn’t matter much, right?
Would it matter if the host would only send data
occasionally?

Posted: 08:54am 25 Apr 2026 Copy link to clipboard	matherp Guru

The client runs in a tight DMA/PIO loop waiting on the clock pulses so as long as the host stays in synch it should be OK

Posted: 09:10am 25 Apr 2026 Copy link to clipboard	fred777 Regular Member

Right, I’ll have a go at that. The idea is to feed
the pixels from some stm mcus with attached camera directly into regions on the picomite’s screen buffer.
And also gaining hdmi output along the way.

Posted: 08:38am 08 Jun 2026 Copy link to clipboard	fred777 Regular Member

matherp said In theory - yes. You will need to read into Memory.c

int bus_width; // 4 or 8 data pins

matherp said Step 2
Set lower half of data pins as outputs, drive the host pattern: 0101 (8-bit) or 01 (4-bit)

This suggests that a 4 bit link could also be possible.
But how would I tell MMBasic to use 4 pins only?
I tried only connecting GP0-3 but then get
[31] Memory Share Client 1, 0, GP0, GP10, addr%, 38400
Error : Sync failed - remote end not responding

Posted: 08:52am 08 Jun 2026 Copy link to clipboard	matherp Guru

MEMORY_SHARE_User_Manual.pdf

Posted: 09:07am 08 Jun 2026 Copy link to clipboard	fred777 Regular Member

Thanks, I was looking at an old version of the Manual.

Posted: 08:11am 09 Jun 2026 Copy link to clipboard	PhenixRising Guru

Following with interest

Posted: 04:50pm 10 Jun 2026 Copy link to clipboard	fred777 Regular Member

This is absolutely fantastic.
I hooked up my good old "Black Pill" STM32 board to the Pico2.
Spend an hour or so to get it running and now the STM32 can do HDMI :-)
The random output comes from the STM via the 4 bit Memory Share Link, while the time is displayed by the pico.
And now any MCU can have Bitmapped VGA or HDMI output using the Picomite as external graphics adapter with just 5 (or 9) pins.
Just for fun I'm going to try with a Picaxe and Basic Stamp.

' MMBASIC Picomite
Memory share stop
MODE 3
Dim addr% = MM.Info(writebuff)
Memory Share Client 1, 0, GP0, GP10, addr%, 153000,4
Do
Print @(100,100),Time$;
Loop

' Mikroe Basic for ARM
dim picoclock as sbit at GPIOB_ODR.B0
dim picobyteout as byte at GPIOA_ODR
dim picobytein as byte at GPIOA_IDR
main:
picobyteout = 0
picobytein = 0
' Set B0 as output
GPIO_Digital_Output(@GPIOB_BASE, _GPIO_PINMASK_0)

picobyteout = %00000001 ' Recog token for Pico
picoclock = 0

UART1_Write_Text("Phase1")
GPIO_Digital_Input(@GPIOA_BASE, _GPIO_PINMASK_2 or _GPIO_PINMASK_3)
UART1_Write_Text("2")
GPIO_Digital_Output(@GPIOA_BASE, _GPIO_PINMASK_0 or _GPIO_PINMASK_1)

UART1_Write_Text("3")
do
byte1 = picobytein
loop until byte1 = 9
Delay_ms 1

UART1_Write_Text("4")
GPIO_Digital_Output(@GPIOA_BASE, _GPIO_PINMASK_0 or _GPIO_PINMASK_1 or _GPIO_PINMASK_2 or _GPIO_PINMASK_3)
Delay_ms 5
UART1_Write_Text("56")
picoclock = 1

byte1 = 0

while 1
picobyteout = byte1
picoclock = 0
picoclock = 1
byte1 = rand()

wend

Edited 2026-06-11 02:53 by fred777

Posted: 01:31pm 18 Jun 2026 Copy link to clipboard	fred777 Regular Member

I love the Memory share function!
Memory share 8 bit link between an AVR and Picomite, the avr can write directly into the Picomite's screen memory.
Now even a good old 8 bit MCU can have a VGA/HDMI display without too much fuss :-)

Edited 2026-06-18 23:32 by fred777

To reply to this topic, you need to log in.