SPI-Slave mit asm_pio + MicroPython auf dem PI PICO

[Michael S. (Gast)]

SPI-Slave mit asm_pio + MicroPython auf dem PI PICO

Für den PI PICO und die anderen MicroPython Ports kenne ich für die TWI- 
und die
SPI-Schnittstelle keine Slave-Implementierungen.

Ein TWI-Slave sollte mit den PIO's realisierbar sein - allerdings nicht 
mit MicroPython.

Ein SPI-Slave dagegen kann mit gewissen Einschränkungen ohne aktive 
Unterstützung
durch MicroPython die Kommunikation stemmen.
Die Grenze stellen die Fifos der Statemmachnes dar, die maximal 32 * 8 
Bit speichern können.
Wer mit max. 32 Byte / Übertragung leben kann, für den gibt es hier 
einen Ansatz, den PI PICO als SPI-Slave zu nutzen.

Weitere Beschreibung gibts im der readme.pdf bzw. im Programmcode.

Michael S.

[Michael S. (Gast)]

Der SPI-Slave in der letzten Version kann bis zu 32 Byte übertragen.
Mehr sollte allerdings möglich sein.
Denn beide PIOs verfügen über einen Gesamtspeicher von  8 * 8 Words = 
256 Byte.
Die galt es nun zur Mitarbeit zu bewegen.

Im ersten Schritt wurde der SPI-Slave optimiert, so dass er in eine 
einzige
Statemachine passte:

spi_slave_4.py
Benötigt nur noch 1 Statemachine, kann dafür auch nur max. 4 * 4 Bytes 
übertragen.

spi_slave_8.py
Das ist der "alten" SPI-Slave, aber mit den Optimierungen des 
spi_slave_4.py.
Benötigt 2 Statemachines (getrennt für Receiver und Transmitter) und 
kann bis zu 8 x 4 Bytes übertragen.

spi_slave_16.py
Hier wird versucht, auf bis zu 8 Statemachines den (leicht erweiterten) 
Code
des spi_slave_4.py auszuführen.
Die Statemachines werden jeweils mit einem "zeitlichen" Versatz von 128 
Bit
gestartet, arbeiten also nacheinander und stellen für den Empfang und 
das Senden
bis zu 8 * 4 Words (= 128 Byte) je Übertragungsrichtung bereit.

Das hätte auch fast funktioniert.

Leider zeigte sich bei den Tests, dass, sofern Statemachines auf beiden 
PIO-Blöcken ausgeführt werden, die Statemachines auf dem ersten Block 
den Output-Pin nicht mehr bedienen.
Alles andere funktionierte wie erwartet.

Bug, Feature oder Unkenntnis der Interna ?

Ich habe zumindest keinen Workaround gefunden - und so kann nur 1 
PIO-Block
genutzt werden und anstelle der erwarteten 128 Byte sind nur 64 Byte 
übertragbar.



Wichtig ist in allen Varianten, dass der SPI-Master genau die Anzahl an 
Bytes sendet, die der Slave erwartet / für die er konfiguriert wurde.

Die Decorator "@micropython.native" sind auskommentiert.
Micropython wird mit aktiviertem Decorator zwar etwas schneller, dafür 
wird aber das Debuggen lästig.

Michael S.

[Tim . (cpldcpu)]

Danke! Die Kombination aus Micropython und PIO Assembler wirkt zwar 
irgendwie absurd, aber im Grunde ist es genau die richtige 
Systempartitionierung.

[Michael S. (Gast)]

Hallo,

im letzten Jahr hatte ich mit dem Pi PICO und seinen PIO's 
experimentiert und versucht, einen SPI-Slave zu implmentieren, der die 
Fifos mehrerer Statemachines als schnellen Speicher nutzt und so die 
Performance-Schwächen von Micropython umgeht.

Das war leidlich gelungen, der Programmcode war schrecklich umständlich 
und in der Transferrichtung vom Slave zum Master gab es einige 
Absonderlichkeiten zu berücksichtigen.

Mit DMA-Unterstützung sieht der SPI-Slave nun um Welten einfacher aus.

Es bleibt wieder eine kleine Einschränkung beim Transfer der Daten vom 
Slave zum Master zu beachten::

Sobald der Slave den DMA-Channel zum Senden öffnet, "saugt" er die 
ersten 4 + 1 Bytes in die Fifos ein.
Änderungen an diesen 5 Bytes sind danach nicht mehr (ohne vertretbaren 
Aufwand) möglich.
Hier bringt die Pufferung durch die Fifos tatsächlich auch Nachteile.

Das heißt als Konsequenz:
Entweder ist sichergestellt, dass nach dem Öffnen des DMA-Channels die 
ersten 5 Byte nicht mehr geändert werden müssen - oder der Master muss 
die ersten 5 Bytes einfach als Dummy-Daten betrachten und ignorieren.

Theoretisch könnte man bis zu 4 Slaves auf dem Pi PICO installieren, 
aber wer braucht so etwas ?

Michael S.

07.08.2022