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.

[Christoph M. (mchris)]

Norbert schrieb
>Leute! Jetzt aber mal STOPP!

Bist du Amateurfunker? Wie viel Leistung kann den so ein Raspi-Pin 
abstrahlen?

[Norbert (der_norbert)]

Christoph M. schrieb:
> Bist du Amateurfunker? Wie viel Leistung kann den so ein Raspi-Pin
> abstrahlen?

Nein, bin ich nicht. Ich weiß aber auch nicht was da hinten noch alles 
dran hängt.
Und die Flugfunknavigation, Localizer, Glidepath, VOR, … stören, auch 
wenn nur möglicherweise, da ist meine Toleranzschwelle noch nicht einmal 
ein Epsilon über 0.
Das mag damit zusammen hängen, dass man sich da oben recht gerne gerade 
in IMC auf die Geräte verlassen und nicht zu einer Statistik werden 
möchte.

[Christoph M. (mchris)]

Ich versuche, die Länge eines Pulses zu messen, aber es sieht so aus, 
als wenn die PIO das Eingangssignal ignoriert. Nach ca.32 Sekunden läuft 
der Zähler über, dann kommt jeweils ein Wert.
Eigentlich sollte das Programm ganz einfach funktionieren: Auf eine 1/0 
Flanke an PIN16 warten und dann solange zählen, bis der Pegel wieder auf 
1 springt. Es will aber einfach nicht funktionieren. Weis jemand, warum?

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

import rp2
from machine import Pin
import time

######### PROGRAMm funktioniert nicht !!! ####################

@rp2.asm_pio()
def pulse_counter():
    label("start")
    mov(isr,x)
    push()
    wait(1, pin, 0)   
    wait(0, pin, 0)    
    
    label("loop")  
    jmp(pin,"start")
    jmp(x_dec, "loop")
    push()
    
class PulseMeasure:
    def __init__(self, sm_id, pin):
        self.sm = rp2.StateMachine(sm_id, pulse_counter, in_base=pin)
        self.sm.put(0x7FFFFFFF)      # Large initial count
        self.sm.exec("mov(x, osr)")

        self.sm.active(1)        # Start the state machine

    def get_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

        return count #-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)
device = PulseMeasure(0, pin16)

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

[Norbert (der_norbert)]

Christoph M. schrieb:
> self.sm = rp2.StateMachine(sm_id, pulse_counter, in_base=pin)

Wenn du mit PIO-JMP arbeitest, dann auch in der StateMachine 
Instanziierung darauf hinweisen.

#!python
self.sm = rp2.StateMachine(sm_id, pulse_counter, in_base=pin, jmp_pin=pin)

[Christoph M. (mchris)]

>Wenn du mit PIO-JMP arbeitest, dann auch in der StateMachine
>Instanziierung darauf hinweisen.

Danke für den Hinweis. Ohne diesen Hinweis hätte ich wahrscheinlich noch 
eine Woche gesucht ..

Hier mal das aktuelle Programm. Der PIO Assembler ist ziemlich 
gewöhnungsbedürftig.

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

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

# Frequency Measurement
# 1. wait for falling edge
# 2. measure low pulse cycles
# 3. calculate frequency

@rp2.asm_pio()
def lowPulseCount():
    #### START ###
    label("store_result")
    mov(isr,x)          # move counter to ISR
    push()              # store ISR (result) in FIFO
    set(x,0)            # clear counter
    jmp(x_dec,"skip")   # preset counter to 0xffffffff 
    label("skip")       # to avoid overflow at the end of this programm
    # wait for falling edge
    wait(1, pin, 0)   
    wait(0, pin, 0)
    #### LOOP ####
    label("loop")  
    jmp(pin,"store_result")    # [1] leave on rising edge
    jmp(x_dec, "loop")         # [1] dec x
    jmp("loop")                # overflow .. should not be needed
    
    
class PulseMeasure:
    def __init__(self, sm_id, pin):
        self.sm = rp2.StateMachine(sm_id, lowPulseCount, in_base=pin, jmp_pin=pin)
        self.sm.active(1)        # Start the state machine

    def get_freq(self):
        count = self.sm.get()        # Read count from FIFO
        cyclesPerLoop=2
        sigLowCycles=(0xffffffff-(count & 0xffffffff))*cyclesPerLoop
        if sigLowCycles!=0:
            f=cpufreq()/(2*sigLowCycles)
        else:
            f=None        
        return f
    
    def end(self):
        self.sm.active(0) 

# Read pulse count from pin 16
pin16 = Pin(16, Pin.IN, Pin.PULL_UP)
device = PulseMeasure(0, pin16)

print("cpufreq: ",cpufreq())
for n in range(1,10):
    print( "f=",device.get_freq(),"Hz")
    time.sleep(0.1)

device.end()

Man kann ja z.b. keine Konstanten >31 direkt ins X-Register laden. 
Außerdem scheint der Jump über den Testpin nur auf High-Werte zu 
funktionieren. Aus diesem Grunde habe ich nur die Low-Periode gemessen 
und dann einfach x2 genommen. Das Ergebnis kann man nicht unbedingt als 
genau bezeichnen. Hier mal für 1kHz:

>>> %Run -c $EDITOR_CONTENT
cpufreq:  125000000
f= 1000.032 Hz
f= 1000.032 Hz
f= 1000.032 Hz
f= 1000.032 Hz
f= 1000.032 Hz
f= 1000.032 Hz
f= 1000.032 Hz
f= 1000.032 Hz
f= 1000.032 Hz

Ich vermute, es liegt an der unscharfen Flanke, weil ich den 
Funktionsgenerator mit 3.3kOhm angeschlossen habe.

[Norbert (der_norbert)]

Von:

set(x,0)            # clear counter
jmp(x_dec,"skip")   # preset counter to 0xffffffff 
label("skip")       # to avoid overflow at the end of this programm

In:

#!python
mov (x, invert(null)) # ones-complement

Von:

mov(isr,x)          # move counter to ISR
push()              # store ISR (result) in FIFO

In:

#!python
mov (isr, invert(x))# revert ones-complement
push()              # store ISR (result) in FIFO

Da sparst du Speicher und den späteren Tanz mit 2³².
Der Rest ist Zyklen zählen.

Christoph M. schrieb:
> Ich vermute, es liegt an der unscharfen Flanke, weil ich den
> Funktionsgenerator mit 3.3kOhm angeschlossen habe.

Jaaaa, das ist so'n Ding mit den Vermutungen… ;-)

Wenn du es zunächst erst einmal Zyklen-genau bauen willst, dann 
generiere dir den präzisen Takt auf dem Ding selbst.

[Hugo H. (hugo_hu)]

Norbert schrieb:
> Die Russen hauen schon in weiten Arealen
> die GNSS Navigation kaputt.

Ja, die Kloschüsseln auch! (vermutlich :-) )

[Norbert (der_norbert)]

Hugo H. schrieb:
> Ja, die Kloschüsseln auch! (vermutlich :-) )

Realitätsverweigerer oder Doppelkorn-Liebhaber?

[Hugo H. (hugo_hu)]

Norbert schrieb:
> Hugo H. schrieb:
>> Ja, die Kloschüsseln auch! (vermutlich :-) )
>
> Realitätsverweigerer oder Doppelkorn-Liebhaber?

Weder noch - Mensch mit Verstand :-)

[Norbert (der_norbert)]

Hugo H. schrieb:
> Norbert schrieb:
>> Hugo H. schrieb:
>>> Ja, die Kloschüsseln auch! (vermutlich :-) )
>>
>> Realitätsverweigerer oder Doppelkorn-Liebhaber?
>
> Weder noch - Mensch mit Verstand :-)

Möglich … Unwahrscheinlich.
Verstand würde implizieren, dass man sich mit der momentanen Situation 
um den größeren Bereich ›baltic sea‹ vertraut macht und Informationen 
diesbezüglich sammelt. Und da wir uns über Aviation unterhielten, wäre 
das wohl der maßgebende Bereich. Mit ein wenig Glück fände derjenige 
sogar eine oder mehrere offizielle Webseiten, auf denen dies ständig 
dokumentiert wird.

ad1: Ich mach's noch leichter. Einfach mal ›EASA GPS outage‹ versuchen.

[Hugo H. (hugo_hu)]

Norbert schrieb:
> offizielle Webseiten

Wird da auch über den Osterhasen berichtet? Vermutlich ... :-)

[Norbert (der_norbert)]

Hugo H. schrieb:
> Wird da auch über den Osterhasen berichtet? Vermutlich ... :-)

Hugo, ich finde es interessant, dass es noch Menschen gibt die sich 
selbst so ungeniert in der Öffentlichkeit zum Affen machen.

[Christoph M. (mchris)]

Könnt ihr die Diskussion im "offtopic" weiter führen?

[Norbert (der_norbert)]

Christoph M. schrieb:
> Könnt ihr die Diskussion im "offtopic" weiter führen?

Ist schon an die Administration gemeldet.

[Christoph M. (mchris)]

Norber schrieb:

>Da sparst du Speicher und den späteren Tanz mit 2³².
>Der Rest ist Zyklen zählen.

Super Tipps. Die nehme ich in meine "Knowledge Base" a.k. Hirn auf.

[Christoph M. (mchris)]

So, jetzt sieht's deutlich besser aus, ich bin begeistert :-)

>>> %Run -c $EDITOR_CONTENT
cpufreq:  125000000
f= 1000.0 Hz
f= 1000.0 Hz
f= 1000.0 Hz
f= 1000.0 Hz
f= 1000.0 Hz
f= 1000.0 Hz
f= 1000.0 Hz
f= 1000.0 Hz
f= 1000.0 Hz

Ein wenig von Mi N.(msx) inspiriert:

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

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

# Frequency Measurement
# 1. wait for rising edge
# 2. count high pulse cycles
# 3. count high pulse cycles
# 4. calculate frequency

# inspired from
# Mi N. (msx)
# 08.10.2025 10:21
# https://www.mikrocontroller.net/topic/580836#7948280

@rp2.asm_pio()
def lowPulseCount():
    #### START ###
    label("store_result")

    mov(isr, x)                # store result
    push()

    mov (x, invert(null)) # ones-complement

    # wait for rising edge
    wait(0, pin, 0)   
    wait(1, pin, 0)            
    
    #### count high period ####
    label("isOneLoop")
    
    jmp(x_dec, "xdec1") [1]    # [2] decrement x
    label("xdec1")
    
    jmp(pin, "isOneLoop")      # [1] wait for 0
    
    #### count low period #### 
    label("isZeroLoop")
    
    jmp(x_dec, "xdec")         # decrement x
    label("xdec")
    jmp(pin, "store_result")   # leave when 1
    
    jmp("isZeroLoop")          # 
    
    
class PulseMeasure:
    def __init__(self, sm_id, pin):
        self.sm = rp2.StateMachine(sm_id, lowPulseCount, in_base=pin, jmp_pin=pin)
        self.sm.active(1)        # Start the state machine
        self.old=0    
    
    def get_freq(self):
        count = self.sm.get()        # Read count from FIFO
        cyclesPerLoop=3
        correctionCycles=1
        sigCycles=(0xffffffff-(count & 0xffffffff))*cyclesPerLoop-correctionCycles

        if sigCycles!=0:
            f=cpufreq()/(sigCycles)
        else:
            f=None        
        #f=count
        return f
    
    def end(self):
        self.sm.active(0) 

# Read pulse count from pin 16
pin16 = Pin(16, Pin.IN, Pin.PULL_UP)
device = PulseMeasure(0, pin16)

print("cpufreq: ",cpufreq())
for n in range(1,10):
    print( "f=",device.get_freq(),"Hz")
    time.sleep(0.1)

device.end()

[Hugo H. (hugo_hu)]

Christoph M. schrieb:
> Ich versuche, die Länge eines Pulses zu messen, aber es sieht so aus,
> als wenn die PIO das Eingangssignal ignoriert. Nach ca.32 Sekunden läuft
> der Zähler über, dann kommt jeweils ein Wert.

Mal etwas Themen-bezogenes. Du Kennst das "Erratum/Errata 9" für den PI 
Pico 2?

https://forums.raspberrypi.com/viewtopic.php?t=375954

Hat mir, trotz externer Pulldown-Beschaltung, sporadisch Fehler bei der 
Auswertung eines Eingangssignals beschert. Ich musste auf den PI Pico 
zurückgreifen. Eine neue Chip-Version des PI Pico 2 (A4) ist als Chip 
schon verfügbar - aber habe ich bisher nicht als Developement-board 
verfügbar gesehen.

[Christoph M. (mchris)]

>Mal etwas Themen-bezogenes. Du Kennst das "Erratum/Errata 9" für den PI
>Pico 2?

Das ist ein guter Hinweis. Für die bisherigen Experimente habe ich einen 
RP20240 benutzt. Heute morgen habe ich mal den selben 
Micropython-Frequenzzähler wie oben ohne Änderung auf einem RP2350 
laufen lassen. Es hat auch funktioniert, nur die Frequenzauflösung war 
etwas besser, weil der RP2 etwas schneller läuft.

Wie man oben sieht, ist der Pin aber als Pull-Up konfiguriert. Auf den 
ersten Blick habe ich keine Ausreißer gesehen.

Durch die Codezeilen

    # wait for rising edge
    wait(0, pin, 0)   
    wait(1, pin, 0)

kann man nur jede zweite Welle messen. Ich mal versucht, diese 
Synchronisation weg zu lassen, aber dann wird die Messung ziemlich 
verrauscht. Das liegt aber wahrscheinlich am langsamen lesen des FIFOs 
durch die Python-Loop, die dann die PIO bremst.

Falls sich deine Beobachtung auch beim Konfiguration als Pull-Up 
bestätigen würde, müsst man man einen Langzeitversuch machen und die 
Daten über ein paar Minuten aufzeichnen.

[Norbert (der_norbert)]

Wenn man den Pin (input) mit weniger als 8kΩ ansteuert, tritt dieser 
Fehler nicht auf. Selbst bei höchsten Frequenzen im 100MHz Bereich kann 
man noch, wie hier, einen 160Ω Widerstand in Serie zwischen input und 
output legen.

Habe das ganze Zeug sowohl auf RP2040 als auch auf RP2350 getestet und 
völlig problemlos laufen.

Der geschilderte Fehler tritt nur bei hochohmiger Ansteuerung auf, wenn 
weniger als ca. 100µA bei low Pegel aus dem input fließen können.

ad1:
Diese Ausgaben der Messungen hier kommen direkt aus dem RP2350:

⋂_⋂_⋂_⋂_⋂_⋂_⋂_⋂_⋂_⋂_⋂_⋂_⋂_⋂_⋂_⋂_⋂_⋂_⋂_⋂_⋂_⋂_⋂_⋂_⋂_⋂_⋂_⋂_⋂_⋂_⋂_⋂_⋂_⋂_⋂_⋂_⋂_⋂_⋂_⋂_⋂_⋂_⋂_⋂_⋂_⋂_⋂_⋂_⋂_⋂_⋂_⋂_⋂_⋂_⋂_⋂_⋂_⋂_⋂_⋂_
100.000000 MHz   (5.0 ns, 5.0 ns)

⋂__⋂__⋂__⋂__⋂__⋂__⋂__⋂__⋂__⋂__⋂__⋂__⋂__⋂__⋂__⋂__⋂__⋂__⋂__⋂__⋂__⋂__⋂__⋂__⋂__⋂__⋂__⋂__⋂__⋂__⋂__⋂__⋂__⋂__⋂__⋂__⋂__⋂__⋂__⋂__
66.666670 MHz   (5.0 ns, 10.0 ns)

⋂⋂_⋂⋂_⋂⋂_⋂⋂_⋂⋂_⋂⋂_⋂⋂_⋂⋂_⋂⋂_⋂⋂_⋂⋂_⋂⋂_⋂⋂_⋂⋂_⋂⋂_⋂⋂_⋂⋂_⋂⋂_⋂⋂_⋂⋂_⋂⋂_⋂⋂_⋂⋂_⋂⋂_⋂⋂_⋂⋂_⋂⋂_⋂⋂_⋂⋂_⋂⋂_⋂⋂_⋂⋂_⋂⋂_⋂⋂_⋂⋂_⋂⋂_⋂⋂_⋂⋂_⋂⋂_⋂⋂_
66.666670 MHz   (10.0 ns, 5.0 ns)

⋂⋂__⋂⋂__⋂⋂__⋂⋂__⋂⋂__⋂⋂__⋂⋂__⋂⋂__⋂⋂__⋂⋂__⋂⋂__⋂⋂__⋂⋂__⋂⋂__⋂⋂__⋂⋂__⋂⋂__⋂⋂__⋂⋂__⋂⋂__⋂⋂__⋂⋂__⋂⋂__⋂⋂__⋂⋂__⋂⋂__⋂⋂__⋂⋂__⋂⋂__⋂⋂__
50.000000 MHz   (10.0 ns, 10.0 ns)

[Hugo H. (hugo_hu)]

Christoph M. schrieb:
> Falls sich deine Beobachtung auch beim Konfiguration als Pull-Up
> bestätigen würde, müsst man man einen Langzeitversuch machen und die
> Daten über ein paar Minuten aufzeichnen.

Wäre vielleicht sinnvoll - aber ein Zurück auf den PI Pico tuts auch. 
Anbei ein Bild in welchem ich Taktsignale (gelb) auswerte - und bei 
Erkennen ausgebe (grün). Der Fehler ist sporadisch, aber im Kontext (ich 
werte Signale zur Display-Steuerung aus) mehr als störend.

[Norbert (der_norbert)]

Hugo H. schrieb:
> Der Fehler ist sporadisch, aber im Kontext (ich
> werte Signale zur Display-Steuerung aus) mehr als störend.

In der Richtung wie in der Grafik gezeigt – low to high bleibt aus – 
ist der Fehler aber gar nicht existent.

Die Richtung low to high geht bei korrekter Ansteuerung immer und 
hat mit RP2350-E9 nichts zu tun.

Nur wenn der ›input‹ bereits latched high ist, müssen aus ihm die ca. 
100µA heraus fließen können um ihn wieder low zu bringen.

Das es mit dem RP2040 geht, liegt wohl eher daran, dass bei dessen 
interner Pad Konfiguration und der externen Beschaltung es so gerade 
noch geht.

[Christoph M. (mchris)]

Micropython ist für das Programmieren der PIO unglaublich praktisch, 
weil der Syntax viel einfacher als für C ist.
Um die maximale Geschwindigkeit zu erreichen, ist aber C unvermeidlich.
Mich wundert dass noch keiner einen Konverter geschrieben hat, um 
Micropython PIO-Code in C umzuwandeln so wie es hier gebraucht wird:
https://wokwi.com/tools/pioasm

[Norbert (der_norbert)]

Christoph M. schrieb:
> Um die maximale Geschwindigkeit zu erreichen, ist aber C unvermeidlich.

Wenn man wirklich maximale Geschwindigkeit erreichen will, ist 
Assembler unvermeidlich. Braucht man aber fast nie, genauso wenig wie C.

Ich selbst habe in den letzten Jahren nur eine Handvoll C-module für 
µPy geschrieben. Die waren dann aber auch wirklich ziemlich extrem.
Alles andere kann man durch vernünftige Programmierung abfrühstücken. 
Wenn man sich eingehend mit dem System beschäftigt.

Nur – im Sinne von ausschließlich – mit µPy geschrieben:
* IRQs pro Sekunde irgendwo im hohen fünf, niedrigen sechs-stelligen 
Bereich.
* Monitoransteuerung inkl. Grafik- und Fensterroutinen.
* Signalerzeugung und Frequenzmessung bis in den drei-stelligen MHz 
Bereich.
* Logic-Analyser 16 Kanäle
* Audio-Signalerkennung und Auswertung

Ich such' mal ein oder zwei Videos heraus.

ad1: Direkt mit dem Clever-Telefon vom Eizo 22" Monitor
Bisschen komprimiert, bei der Originalgröße käme ich hier auf die 
Strafbank.

Die Datei heißt eigentlich µPy4.mp4, ist aber von der Foren-SW verändert 
worden. Abspielbar mit mpv,vlc,mplayer,smplayer

[Vanye R. (vanye_rijan)]

> Wenn man wirklich maximale Geschwindigkeit erreichen will, ist
> Assembler unvermeidlich. Braucht man aber fast nie, genauso wenig wie C.

Du brauchst die hohe Geschwindigkeit zum Beispiel IMMER dann wenn du 
Energieprobleme hast. Es ist ein Unterschied ob deine Kiste 2Monate oder 
2Jahre mit einer Batterie laeuft. Oder auch wenn die Energie begrenzt 
ist wegen Solarzelle oder Feldbus. Oder einfach wenn du kommerziell 
unterwegs bist weil es bedeutet das du mit derselben (preislich) 
Hardware wie die Konkurrenz viel mehr Funktionalitaet hast.

Zum basteln zuhause ist es sicher oft egal! Aber sobald deine Ansprueche 
darueber hinaus gehen ist C/C++ im Embeddedbereich selbstverstaendlich.

Programmierung in Assembler dagegen ist in der Tat sehr exotisch/selten 
geworden. Es ist aber immer noch notwendig es zu koennen damit du bei 
komplexen Problemen auf Assemblerlevel debuggen kannst. Auch nicht jeden 
Tag, aber so 1x im Jahr kommt das vor. Das ist dann manchmal der Tag an 
dem du einen Bugreport an den Compilerhersteller schreiben kannst. Ich 
meine irgendeiner muss ja die Bugs finden oder? :-)

Vanye

[Norbert (der_norbert)]

Vanye R. schrieb:
> Du brauchst die hohe Geschwindigkeit zum Beispiel IMMER dann wenn du
> Energieprobleme hast.

Wer Energieprobleme hat, nutzt ganz sicher keinen Pico (oder nur wenn's 
gar nicht anders geht). Die Dinger sind nun wirklich nicht für 
Batteriebetrieb ausgelegt.

Vanye R. schrieb:
> Programmierung in Assembler dagegen ist in der Tat sehr exotisch/selten
> geworden.

Wenn die ersten drei erlernten Sprachen Maschinencode/Assembler waren, 
dann empfindet man das als völlig natürlich. Natürlich schreibt man 
heute kein komplettes Programm in Assembler, nur die Routinen wo es 
massig Umpf braucht.
Hatte ich erwähnt, das µPy ganz nebenbei einen Assembler eingebaut hat? 
;-)

[Norbert (der_norbert)]

Und so ein Bild auf dem Monitor kann man mit µPy übrigens auch erzeugen.
Wenn man's richtig macht. Ohne Assembler und ohne C übrigens.
Da habe ich viel über Video-Formate gelernt.
Muss man allerdings – wie bei dem gezeigten Video auch – alles, wirklich 
alles, selbst programmieren. Nix Schublade auf und module importieren.

[Vanye R. (vanye_rijan)]

> Wenn die ersten drei erlernten Sprachen Maschinencode/Assembler waren,
> dann empfindet man das als völlig natürlich.

Ich hab mal MCS48, MCS51, Z80, ST6, Saturn, ESRH, 6502 und 68k Assembler 
gelernt. Trotzdem wuerde ich nicht sagen das ich heute ARM oder Risc/V 
mal eben gut also sinnvoll in Assembler programmieren kann. Irgendwas 
hinschludern das geht, ja, aber programmieren ist was anderes! Wo man es 
genau drauf hat um wirklich noch besser wie ein Compiler zu sein. Das 
ist nicht mal eben so gemacht. Deshalb ist es ja auch weitestgehend 
ausgestorben.

Vanye

[Mi N. (msx)]

Christoph M. schrieb:
> Micropython ist für das Programmieren der PIO unglaublich praktisch,
> weil der Syntax viel einfacher als für C ist.

Was ich bislang als Code so gesehen habe, scheint mir doch recht 
gewöhnungsbedürftig ;-)
Syntax hin oder her: wenn es schnell gehen soll, muß man genau wissen, 
was man eingibt, und da helfen ein Blatt Papier und eigene Kopfarbeit 
enorm - bei mir zumindest.

Die PIOs habe ich mir mit einer IAR-IDE in C programmiert. Damit kann 
man ganz elegant zur Laufzeit eine PIO starten und stoppen, einzelene 
Befehle von C aus ausführen lassen und beim Debuggen das PIO-Programm 
manuell verändern.
Für größere PIO-Programme könnte man per DMA auch die Befehle aus einer 
Tabelle ausführen lassen oder eine PIO zur Laufzeit umprogrammieren.
Aber gut, wohl etwas speziell das Ganze.

[Christoph M. (mchris)]

Norbert (der_norbert)
>Wenn man wirklich maximale Geschwindigkeit erreichen will, ist
>Assembler unvermeidlich.

Das kann sein, ist aber ein wenig mühselig.

>Braucht man aber fast nie, genauso wenig wie C.

Wenn du mal ein Beispiel willst, bei dem Micropython scheitert:
Beitrag "6502 Emulator PiPico"

[Christoph M. (mchris)]

Ich habe das Frequenzmessprogramm

Beitrag "Re: PiPico PIO programmieren"

mal in die C-Version verwandelt.
Wie zu erwarten, gestaltet sich die Inbetriebnahme schwierig. Es scheint 
kein Wert im FIFO anzukommen.

Hat jemand eine Idee?

#include "fmes.pio.h"           
#include <hardware/gpio.h>
#include <hardware/pio.h>
#include <stdio.h>

#define TESTPIN 16              

// function to translate
#if defined(ARDUINO_ARCH_MBED)
#include <pinDefinitions.h>
static int translate_pin(int pin) {
  return digitalPinToPinName(pin);
}
#else
static int translate_pin(int pin) {
  return pin;
}
#endif

static PIO pio;
static int sm;

static inline void fmes_program_init(PIO pio, uint sm, uint pin)
{
  pio_gpio_init(pio, pin);

  // Set pin direction: input
  pio_sm_set_consecutive_pindirs(pio, sm, pin, 1, false);

  pio_sm_config c = fmes_program_get_default_config(0);
  sm_config_set_in_pins(&c, pin); // for WAIT, IN

  // don't join FIFO's
  sm_config_set_fifo_join(&c, PIO_FIFO_JOIN_NONE);

  // always run at sysclk (125 MHz default)
  sm_config_set_clkdiv(&c, 1.0);

  pio_sm_init(pio, sm, 0, &c);

  // Use SDK function to enable state machine
  pio_sm_set_enabled(pio, sm, true);
}

void setup() {
  Serial.begin(115200);
  //while (!Serial.available());
  //Serial.println("start");
  while (!Serial) {
    delay(10);
  }
  Serial.println("start");

  gpio_init(TESTPIN);                    // Initialize the GPIO pin
  gpio_set_dir(TESTPIN, GPIO_IN);        // Set the TESTPIN as input (standard GPIO)

  // Assign pio to pio0
  pio = pio0;

  // Claim an unused state machine
  sm = pio_claim_unused_sm(pio, true);

  int gpio_pin = translate_pin(TESTPIN);

  pio_add_program(pio, &fmes_program);

  // Initialize PIO program on the claimed state machine
  fmes_program_init(pio, sm, gpio_pin);

  Serial.printf("Using PIO instance %p, state machine %d on pin %d\n", pio, sm, gpio_pin);
}

static inline int32_t pio_read(PIO pio, uint sm)
{
  int32_t value = -1;
  uint32_t ints;

  uint8_t count = pio_sm_get_rx_fifo_level(pio, sm);

  ints = save_and_disable_interrupts();
  if (count > 0)
    value = pio_sm_get_blocking(pio, sm);
  else value = -1;
  restore_interrupts(ints);

  return value;
}

void loop()
{
  Serial.print("click ");
  int32_t val = pio_read(pio, sm);

  Serial.println(val);

  delay(200);
}

Hier das zugehörige PIO-Programm:

// -------------------------------------------------- //
// This file is autogenerated by pioasm; do not edit! //
// -------------------------------------------------- //

#pragma once

#if !PICO_NO_HARDWARE
#include "hardware/pio.h"
#endif

// ---- //
// fmes //
// ---- //

#define fmes_wrap_target 0
#define fmes_wrap 9

static const uint16_t fmes_program_instructions[] = {
            //     .wrap_target
    0xa0c9, //  0: mov    isr, !x                    
    0x8020, //  1: push   block                      
    0xa02b, //  2: mov    x, !null                   
    0x2020, //  3: wait   0 pin, 0                   
    0x20a0, //  4: wait   1 pin, 0                   
    0x0046, //  5: jmp    x--, 6                     
    0x00c5, //  6: jmp    pin, 5                     
    0x0048, //  7: jmp    x--, 8                     
    0x00c0, //  8: jmp    pin, 0                     
    0x0007, //  9: jmp    7                          
            //     .wrap
};

#if !PICO_NO_HARDWARE
static const struct pio_program fmes_program = {
    .instructions = fmes_program_instructions,
    .length = 10,
    .origin = 0,
};

static inline pio_sm_config fmes_program_get_default_config(uint offset) {
    pio_sm_config c = pio_get_default_sm_config();
    sm_config_set_wrap(&c, offset + fmes_wrap_target, offset + fmes_wrap);
    return c;
}

#endif
[c]

[Norbert (der_norbert)]

Du weißt aber schon, dass es im SDK einen pioasm gibt? ;-)
cmake richtig einbinden.
Das muss man nicht selbst machen…

Edit: Ups, sehe gerade: Arduino

[Christoph M. (mchris)]

>Edit: Ups, sehe gerade: Arduino

Genau .. die zweit einfachste Variante nach Micropython.
Ich verwende das Early-Hill-Power Framework

https://github.com/earlephilhower/arduino-pico

weil es ohne mbed auskommt.

Wie man im Code sieht, kann man die SDK-API benutzen.
Ich habe den angehängten PIO-Code, der dem Micropython-Code entspricht 
mit dem Onlineassembler assemblieren lassen:
https://wokwi.com/tools/pioasm
Leider hängt es noch irgendwo ..

[Christoph M. (mchris)]

Ok, jetzt funktioniert es.
Es war quasi der gleiche Fehler wie schon im anfänglichen 
Micropython-Programm: Es muss der Jump-Pin konfiguriert werden.

[M. G. (t1nk3r)]

Christoph M. schrieb:
> Gibt es die PIO eigentlich als VHDL-Code?

Ein paar ganz kleine Sachen davon sind auch in 
https://github.com/Wren6991/libfpga

[Joachim B. (jar)]

Christoph M. schrieb:
> Ich habe

nicht gelesen!

Wichtige Regeln - erst lesen, dann posten!
    Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

mann mann mann
Angemeldet seit   01.04.2018 09:32
Beiträge   1639

[Christoph M. (mchris)]

Joachim B. (jar)
>nicht gelesen!

[ ] Du hast zum Thema beigetragen.