SPI-Slave mit asm_pio + MicroPython auf dem PI PICO

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.

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