PiPico PIO programmieren

[Christoph M. (mchris)]

Der einfachste Weg die PIO des PiPico zu benutzen, scheint Micropython 
zu sein:

https://blues.com/blog/raspberry-pi-pico-pio/

Im Beispiel wundert mich die hohe Taktfrequenz von 2kHz, die dann ein 
sichtbares blinken ergibt.

[Norbert (der_norbert)]

Christoph M. schrieb:
> Im Beispiel wundert mich die hohe Taktfrequenz von 2kHz, die dann ein
> sichtbares blinken ergibt.

Die CPU Frequenz kann nur durch maximal 2¹⁶ für die SMs dividiert 
werden.
Ohne hinein geschaut zu haben, wird die sich ergebende Blinkfrequenz auf 
delays ›[n]‹ für 0<=n<=31 in PIOASM zurück zu führen sein.

[Christoph M. (mchris)]

>Ohne hinein geschaut zu haben, wird die sich ergebende Blinkfrequenz auf
>delays ›[n]‹ für 0<=n<=31 in PIOASM zurück zu führen sein.

Was mich an dem Programm etwas wundert, sind die nop(). Die gibt es bei 
den PIO-Befehlen nicht.

[Norbert (der_norbert)]

Christoph M. schrieb:
> Was mich an dem Programm etwas wundert, sind die nop(). Die gibt es bei
> den PIO-Befehlen nicht.

3.3.7. Pseudoinstructions
Currently pioasm provides one pseudoinstruction, as a convenience:
nop
Assembles to mov y, y . "No operation", has no particular side effect, but a useful vehicle for a side-set
operation or an extra delay.

[Christoph M. (mchris)]

>3.3.7. Pseudoinstructions
Hab ich glatt überlesen. Danke.

[Christoph M. (mchris)]

Gibt es die PIO eigentlich als VHDL-Code?

edit: suchen hilft
https://github.com/lawrie/fpga_pio

[Christoph M. (mchris)]

Gibt es einen Grund dafür, dass man in diesem Tone-Beispiel
https://wokwi.com/projects/312236827469677121

die PIO-Frequenz auf 1MHz stellt? Eigentlich müsste es ja besser sein, 
die Frequenz auf Maximum zu stellen, weil dann die Quantisierung der 
Frequenzen am kleinsten ausfällt. Ich könnte mir nur vorstellen, dass 
man bei 1MHz etwas Strom spart.

[Norbert (der_norbert)]

Christoph M. schrieb:
> Gibt es einen Grund dafür, dass man in diesem Tone-Beispiel
> https://wokwi.com/projects/312236827469677121
>
> die PIO-Frequenz auf 1MHz stellt? Eigentlich müsste es ja besser sein,
> die Frequenz auf Maximum zu stellen, weil dann die Quantisierung der
> Frequenzen am kleinsten ausfällt. Ich könnte mir nur vorstellen, dass
> man bei 1MHz etwas Strom spart.

Nö, der Rest läuft ja volle Pulle. Man kann die halbe Periode ja auf 
1µs einstellen.

Das Beispiel hat aber durchaus Arduino Qualität.
* Buzzer direkt an die GPIOs
* Ein wildes Durcheinander von import … und from … import … Statements
* Bei der gewünschten Frequenz muss man wohl die Hälfte ins FIFO 
schütten
* Selbst dann passt sie nicht, da der Overhead nicht berücksichtigt 
wird.

Trotzdem gut geeignet als abschreckendes Beispiel. ;-)

[Christoph M. (mchris)]

Norbert (der_norbert)
>* Bei der gewünschten Frequenz muss man wohl die Hälfte ins FIFO
>schütten

Wieso das?

Da steht doch

    pull(noblock)      
    mov(x, osr)

d.h. da wird nicht auf einen vollen FIFO gewartet sondern der alte Wert 
aus dem OSR koppiert, wenn keine Werte im FIFO sind. Man kann die 
Frequenz also asynchron setzten, wie es am Schluss gemacht wird:

play(500)
time.sleep(1)
play(1000)
time.sleep(1)
play(0)

Siehe Datenblatt

3.4.7.2. Operation  

A nonblocking PULL on an empty FIFO has the same effect as MOV OSR, X. The program can either preload scratch register X with a suitable default, or execute a MOV X, OSR after each PULL NOBLOCK, so that the last valid FIFO word will be recycled
until new data is available.

Mit

for n in range(1,500):
    play(n*5)
    time.sleep(0.01)
play(0)

ergibt sich dann ein asynchron gesetzter Chirp.

[Stefan K. (stk)]

Christoph M. schrieb:
> Norbert (der_norbert)
>>* Bei der gewünschten Frequenz muss man wohl die Hälfte ins FIFO
>>schütten
>
> Wieso das?

Weil man sonst etwa die halbe Frequenz erhält.
Der Ersteller des Scripts hat wohl nie geprüft ob die am GPIO 
ausgegebene Frequenz der gewünschten entspricht.
Obwohl, bei einem Piezo-Plättchen, könnte es sich schon nach der 
gewünschten Frequenz anhören.

[Christoph M. (mchris)]

Stefan K. (stk)
17.10.2025 08:37
>Weil man sonst etwa die halbe Frequenz erhält.

Da hast du recht.

Das lässt sich allerdings auch leicht korrigieren.
Mir ging es eher um die Frequenzauflösung.

Wenn die State-Machine mit 1MHz läuft, erhält man für 440HZ

 1e6/double((int32(1e6/440)))
ans = 439.95

Wenn sie mit 10MHz läuft wird das schon genauer:

10e6/double((int32(10e6/440)))
ans = 440.01

[Norbert (der_norbert)]

Stefan K. schrieb:
> Christoph M. schrieb:
>> Norbert (der_norbert)
>>>* Bei der gewünschten Frequenz muss man wohl die Hälfte ins FIFO
>>>schütten
>>
>> Wieso das?
>
> Weil man sonst die halbe Frequenz erhält.
> Der Ersteller des Scripts hat wohl nie geprüft ob die am GPIO
> ausgegebene Frequenz der gewünschten entspricht.
> Obwohl, bei einem Piezo-Plättchen, könnte es sich schon nach der
> gewünschten Frequenz anhören.

Stefan hat's schon richtig beschrieben.

Für eine volle Periode braucht's zwei Polaritätswechsel. Hier findet 
pro PIO Rundlauf nur einer statt, ergo halbe Frequenz.
Richtig wäre es, wenn man die PIO Frequenz auf 2MHz setzen würde, und 
beim sm.put() den erheblichen Offset der restlichen PIOASM Befehle 
subtrahieren würde.
Aber selbst dann wäre es falsch, denn der y_jmp loop braucht eine ›0‹ im 
Register für einen Durchlauf, oder ›n-1‹ für ›n‹ Durchläufe.
Aber das Gute ist, zumindest einige Programmzeilen sind fehlerfrei. ;-)

add1: Und der ›Simulator‹ ist fehlerhaft!

[Norbert (der_norbert)]

Christoph M. schrieb:
> Mir ging es eher um die Frequenzauflösung.

PIO mit vollem CPU Takt laufen lassen.
Alles andere ergibt keinen Sinn.
Im ›put‹ keine ›//‹ Division mit inhärentem round down, sondern:

sm.put(round(machine.freq()/freq/2) - offset)

Die Play Funktion ist ebenfalls fehlerhaft, sie stoppt den Ton bei ›0‹ 
nicht, sondern erzeugt (bei ›0‹) die Periode ca 2³²/F_CPU und bestromt 
den Ausgang für längere Zeit kontinuierlich.

[Christoph M. (mchris)]

Norbert schrieb:
>Die Play Funktion ist ebenfalls fehlerhaft, sie stoppt den Ton bei ›0‹
>nicht, sondern erzeugt (bei ›0‹) die Periode ca 2³²/F_CPU und bestromt
>den Ausgang für längere Zeit kontinuierlich.

Da hast du Recht, das konnte ich auf dem Oszilloskop beobachten. Ich 
vermute, man kann den PiPico direkt in einen UKW-Sender verwandeln, 
einfach in dem man eine Antenne an den Pin hängt.

[Christoph M. (mchris)]

Das nächste Experiment ist das Zählen von Pulsen.

Die State-Machine in diesem Beispiel ist recht einfach, allerdings 
erfolgt die Abfrage des Zählerstandes als "Code Injection" und braucht 
daher extra Zeit. Die Frage ist, ob hier Zählerwerte verloren gehen 
könnten. Ich vermute eher nicht, wenn die zu zählende Frequenz deutlich 
kleiner als die Loopfrequenz der Zustandsmaschine ist.

Das Ziel ist, den Zähler an den Frequenzgenerator von vorher 
anzuschließen. Am einfachsten erscheint es mir, einfach den gleichen Pin 
zu verwenden und die beiten Zustandsmaschinen gleichzeitig laufen zu 
lassen.

import rp2
from machine import Pin
import time

# PIO program to count pulses on an input pin
@rp2.asm_pio()
def pulse_counter():
    label("loop")
    wait(0, pin, 0)    # Wait for pin to go low
    wait(1, pin, 0)    # Wait for pin to go high (rising edge)
    jmp(x_dec, "loop") # Decrement x and jump to loop (counts pulses)

class PulseCounter:
    def __init__(self, sm_id, pin):
        self.sm = rp2.StateMachine(sm_id, pulse_counter, in_base=pin)
        self.sm.put(0)           # Initialize pulse count to 0
        self.sm.exec("pull()")
        self.sm.exec("mov(x, osr)")
        self.sm.active(1)        # Start the state machine

    def get_pulse_count(self):
        self.sm.exec("mov(isr, x)")  # Move current count into ISR
        self.sm.exec("push()")       # Push ISR to FIFO
        count = self.sm.get()        # Read the count
        # Convert count from decrementing format to positive value
        return -count & 0x7fffffff
    
    def clear_count(self):
        self.sm.exec("set(x, 0)")  
        

# Read pulse count from pin 16

pin16 = Pin(16, Pin.IN, Pin.PULL_UP)
pulse_counter = PulseCounter(0, pin16)

for n in range(1,10):
    print("Pulse count:", pulse_counter.get_pulse_count())
    time.sleep(0.5)

[Norbert (der_norbert)]

Christoph M. schrieb:
> Norbert schrieb:
>>Die Play Funktion ist ebenfalls fehlerhaft, sie stoppt den Ton bei ›0‹
>>nicht, sondern erzeugt (bei ›0‹) die Periode ca 2³²/F_CPU und bestromt
>>den Ausgang für längere Zeit kontinuierlich.
>
> Da hast du Recht, das konnte ich auf dem Oszilloskop beobachten. Ich
> vermute, man kann den PiPico direkt in einen UKW-Sender verwandeln,
> einfach in dem man eine Antenne an den Pin hängt.

Ich würde es zwar so wohl nicht machen, aber angelehnt an das Beispiel…
(Falls ich mich nicht verzählt habe ;-) )

#!/python
# vim: fileencoding=utf-8: ts=4: sw=4: expandtab:
from machine import freq as cpufreq
from rp2 import PIO, StateMachine, asm_pio
from time import sleep_ms

@rp2.asm_pio(sideset_init=PIO.OUT_LOW)
def toggle():
    wrap_target()
    pull(noblock)           # 1     (neue Daten)OSR oder X──▶OSR
    mov (x, osr)            # 1
    mov (y, x).side(1)      # 1
    label("loop1")
    jmp (y_dec, "loop1")    # n+1
    mov (y, x).side(0)[2]   # 3     symmetrisch machen
    label("loop2")
    jmp (y_dec, "loop2")    # n+1
    wrap()

def play(freq):
    if freq:
        # Bei höchster Frequenz nicht negativ werden lassen.
        sm.put(max(0, round(cpufreq()/freq/2) - 4))
        sm.restart()                # Falls ohne warten bei extrem niedriger Frequenz gewünscht
        sm.active(1)
    else:
        sm.active(0)                # Sonst beträgt (bei ›0‹ die Periode ca. 2³¹/F_SM
        sm.exec('nop().side(0)')    # Ausgang auf spezifizierten Pegel bringen

sm = rp2.StateMachine(0, toggle, sideset_base=25) # LED zum Test (Pin() ist hier unnötig)
play(20)
sleep_ms(1000)
play(5)
sleep_ms(1000)
play(0)

[Joachim B. (jar)]

Christoph M. schrieb:
> Ich
> vermute, man kann den PiPico direkt in einen UKW-Sender verwandeln

das konnte schon der erste Raspi, warum soll das auf einem PiPico anders 
sein?
https://tutorials-raspberrypi.de/raspberry-pi-als-radio-sendestation-verwenden/

[Christoph M. (mchris)]

>Ich würde es zwar so wohl nicht machen, aber angelehnt an das Beispiel…

Welchen Tipp hättest du, es besser zu machen?

[Norbert (der_norbert)]

Christoph M. schrieb:
>>Ich würde es zwar so wohl nicht machen, aber angelehnt an das
> Beispiel…
>
> Welchen Tipp hättest du, es besser zu machen?

Kleine Tabelle (2^n Größe) mit gewünschter ›Waveform‹ füllen. Per DMA 
mit Ringsize ›n‹ entweder einen der >=acht PWM slices oder eine der 
>=acht StateMachines mit variablem duty-cycle ansteuern. Klingt 
angenehmer. Aber für ein Rechteck mit duty:50% geht's so auch.
Nebenbei: In meinem offensichtlich zu hastig veröffentlichen Code haben 
sich zwei copy'n'paste Artefakte versteckt. Zeilen 7,30. Die ›rp2.‹ 
können natürlich weg.

[Christoph M. (mchris)]

> In meinem offensichtlich zu hastig veröffentlichen Code haben
> sich zwei copy'n'paste Artefakte versteckt. Zeilen 7,30. Die ›rp2.‹
> können natürlich weg.
Da ist mir nicht klar, was du meinst.

Da ich ein Rechtecksignal brauche, habe ich das Programm mal korrigiert. 
Ich denke, die Zyklenkorrektur muss 6 betragen:

#!/python
# vim: fileencoding=utf-8: ts=4: sw=4: expandtab:

import rp2
from machine import Pin
from rp2 import PIO
import time
from machine import freq as cpufreq

# Define a PIO assembly program that toggles the output pin at a controllable rate
@rp2.asm_pio(out_init=[PIO.OUT_LOW])
def echo():
    wrap_target()              # define the start of the main loop of the PIO program.
    mov(pins, isr)             # [1] Output current ISR value to the pin (initially LOW)
    mov(isr, invert(isr))      # [1] Toggle ISR between 0 and 1 for pin toggling
    pull(noblock)              # [1] Try to pull new data from FIFO (non-blocking)
    mov(x, osr)                # [1] Store new delay count (or reuse old one if no new data)
    mov(y, x)                  # [1] Copy to Y register for countdown
    label("loop")
    jmp(y_dec, "loop")         # [1] Decrement Y until 0 – creates delay
    wrap()                     # Loop back to start

# Create a state machine (0) using the PIO program, output on GPIO16
sm = rp2.StateMachine(0, echo, out_base=Pin(16))

# Activate the state machine (start running)
sm.active(1)

# Function to set the output frequency (tone)
def play(freq):
    if freq:
        # Compute the delay count from CPU frequency and tone frequency
        # cpufreq()/freq/2 is half the period in CPU cycles
        sm.put(max(0, round(cpufreq()/freq/2) - 6))   # Send delay count to PIO program
    else:
        sm.put(0)          # Send 0 to stop toggling
        sm.active(0)       # Deactivate the state machine (silence output)


play(1000)
#time.sleep(5)
#play(0)                    # Stop output after sweep completes

[Norbert (der_norbert)]

Christoph M. schrieb:
> Da ist mir nicht klar, was du meinst.

Nach Bereinigung der imports hatte sich dort mittels copy'n'paste error 
Folgendes verewigt:

@rp2.asm_pio(sideset_init=PIO.OUT_LOW)
sm = rp2.StateMachine(0, toggle, sideset_base=25)

Da ich aber bereits selektiert importiert hatte:

from rp2 import PIO, StateMachine, asm_pio

sollten die Zeilen in:

@asm_pio(sideset_init=PIO.OUT_LOW)
sm = StateMachine(0, toggle, sideset_base=25)

also ohne ›rp2.‹ davor abgeändert werden. Es wird nur deshalb keine 
Exception geworfen, da µPy insgeheim beim Start schon ›machine‹ und 
›rp2‹ automagisch importiert.

Da bei deiner gezeigten Version noch mehrere Varianten importiert 
werden,
also Autoimport rp2, manueller import rp2, selektierter import PIO,usw. 
isses jedoch egal, welche der Arten man benutzt.


Sechs sieht mir auf Anhieb ganz gut aus.
Aber bedenke, nach einem play(0) ist das Ding ohne erneutes sm.active(1) 
tot wie ein Papagei.

Und der erste sm.active(1) nach StateMachine erzeugt etwas 
unkontrolliertes/uninitialisiertes. Erst der erstmalige play() Aufruf 
setzt den Schleifenzähler korrekt.

Noch eins: Wenn der play(0) im ungünstigen Zeitpunkt kommt, dann kann 
der Ausgang mit einer 50:50 Chance auf High bleiben, was man 
möglicherweise nicht wirklich will.

[Stefan K. (stk)]

Christoph M. schrieb:
> Da ich ein Rechtecksignal brauche, habe ich das Programm mal korrigiert.
> Ich denke, die Zyklenkorrektur muss 6 betragen:

So wie das Programm jetzt aussieht passt 6.
Das sieht man mit einem Oszilloskop oder Frequenzzähler sofort, wenn man 
bei play() einen so hohen Wert eingibt, dass sm.put(0) aufgerufen wird.
Bei 125MHz CPU Takt erhält man damit etwa 10,42MHz am GPIO, also 
125MHz/12.
Wenn man die beiden Zeilen
mov(pins, isr)
mov(isr, invert(isr))
durch die eine Zeile
mov(pins, invert(pins))
ersetzt kommt man auf max. 12,5MHz am GPIO.

[Christoph M. (mchris)]

>also ohne ›rp2.‹ davor abgeändert werden. Es wird nur deshalb keine
>Exception geworfen, da µPy insgeheim beim Start schon ›machine‹ und
>›rp2‹ automagisch importiert.

Ah, danke.

Stefan K. (stk)
18.10.2025 10:59
>So wie das Programm jetzt aussieht passt 6.
>Das sieht man mit einem Oszilloskop oder Frequenzzähler sofort, wenn man
>bei play() einen so hohen Wert eingibt, dass sm.put(0) aufgerufen wird.
>Bei 125MHz CPU Takt erhält man damit etwa 10,42MHz am GPIO

Das ist eine gute Idee. Ich hatte das Signal mit einem Frequenzzähler 
bei 1kHz gemessen und es sah erst mal gut aus. Aber an die Grenze zu 
gehen, ist natürlich besser.
Interessant, dass man nur bis ca. 12MHz bei SysClk=150Mhz kommt. Darüber 
hatte ich gar nicht nachgedacht, weil mich eher die Genauigkeit der 
Frequenzen im Audiobereich interessiert haben.
Aber für das weiter oben angedachte Experiment als UKW Sender währen 
natürlich 108MHz interessanter. Ob man wohl die PLL in Mikropython 
schnelle genug für die FM-Modulation umkonfigurieren könnte?

[Norbert (der_norbert)]

Christoph M. schrieb:
> Aber für das weiter oben angedachte Experiment als UKW Sender währen
> natürlich 108MHz interessanter.

Da wäre die Luftfahrt bestimmt begeistert und außer Rand und Band.

Christoph M. schrieb:
> Interessant, dass man nur bis ca. 12MHz bei SysClk=150Mhz kommt.

18.75MHz mit dem weiter oben gezeigten PIO Programm.
Ist aber komplett sinnbefreit, da die Abstufung astronomisch groß wird.
Die maximal mögliche erzeugbare Frequenz beträgt ½·SM_F.
sideset(1)
sideset(0)
in wrap() gewickelt.

[Ob S. (Firma: 1984now) (observer)]

Norbert schrieb:
> Christoph M. schrieb:
>> Aber für das weiter oben angedachte Experiment als UKW Sender währen
>> natürlich 108MHz interessanter.
>
> Da wäre die Luftfahrt bestimmt begeistert und außer Rand und Band.
>
> Christoph M. schrieb:
>> Interessant, dass man nur bis ca. 12MHz bei SysClk=150Mhz kommt.
>
> 18.75MHz mit dem weiter oben gezeigten PIO Programm.
> Ist aber komplett sinnbefreit, da die Abstufung astronomisch groß wird.
> Die maximal mögliche erzeugbare Frequenz beträgt ½·SM_F.
> sideset(1)
> sideset(0)
> in wrap() gewickelt.

Das ist so nicht ganz richtig. Das ist, was man maximal als 
Rechteck-Grundwelle erzeugen kann.

Mit klugen Tricks ist es aber sehr wohl möglich, basierend darauf ein 
(wenn auch ziemlich schmutziges) UKW-FM-Signal zu erzeugen. Man nutzt 
halt aus, dass Rechtecke sehr viele Oberwellen enthalten.

[Christoph M. (mchris)]

>Das ist so nicht ganz richtig. Das ist, was man maximal als
>Rechteck-Grundwelle erzeugen kann.

Es müsste mehr gehen. Einfach die PIO nur den Pin togglen lassen und die 
PIO mit Systemtakt laufen lassen. Dann den Systemtakt auf 216MHz.

[Norbert (der_norbert)]

Christoph M. schrieb:
>>Das ist so nicht ganz richtig. Das ist, was man maximal als
>>Rechteck-Grundwelle erzeugen kann.
>
> Es müsste mehr gehen. Einfach die PIO nur den Pin togglen lassen und die
> PIO mit Systemtakt laufen lassen. Dann den Systemtakt auf 216MHz.

Leute! Jetzt aber mal STOPP! Ihr bewegt euch im Bereich der 
Flugnavigation. Muss das sein? Die Russen hauen schon in weiten Arealen 
die GNSS Navigation kaputt.