PiPico2 Frequenzzähler

[Christoph M. (mchris)]

Ich will mit dem PiPico2 Frequenzen zählen. Das Ganze soll über die 
Periodendauermessung funktionieren, da ich eine möglichst schnelles 
Update der aktuellen Frequenz benötige.

Mein Testaufbau ist ein Frequenzgenerator mit 100kHz Rechteck an den 
Pin16 des PiPico geführt. So wie es aussieht, entstehen hier Fehler bis 
zu ca. 20%.

#include <Arduino.h>

volatile uint32_t DeltaT = 0;

#define TESTPIN 16

void myISR() {
  static uint64_t last_cycles = 0;
  uint64_t t=rp2040.getCycleCount64();
  DeltaT=t-last_cycles;
  last_cycles = t; 
}

void setup() {
  Serial.begin(115200);
  //while (!Serial) {}
  pinMode(LED_BUILTIN,OUTPUT);
}

void setup1()
{
  pinMode(TESTPIN, INPUT_PULLUP);
  attachInterrupt(digitalPinToInterrupt(TESTPIN), myISR, RISING);
}

void loop() {
  // read last_cycles (simple read; if strict atomicity needed use atomic ops)
  static bool state;
  uint64_t c = DeltaT;//last_cycles;
  uint64_t f = rp2040.f_cpu();               // CPU frequency in Hz
  double ns = (double)c * 1e9 / (double)f;   // cycles -> nanoseconds
  float fmeas=1/(ns*1e-9);
  Serial.println(fmeas);
  delay(20);

}

[Michael P. (mipo)]

Kannst du den Fehler besser beschreiben? Ist für mich nicht klar ob du 
einen jitter hast oder nur falsche Anzeige. Kenne den Pico nicht, aber 
brauchst du unbedingt Variable-Typen inkl. double und print?

[Norbert (der_norbert)]

Christoph M. schrieb:
> Ich will mit dem PiPico2 Frequenzen zählen. Das Ganze soll über die
> Periodendauermessung funktionieren, da ich eine möglichst schnelles
> Update der aktuellen Frequenz benötige.

Wenn es sowohl schnell, als auch genau und ohne CPU Belastung gehen 
soll, dann empfehle ich nachdrücklich den Schwenk auf die PIO.
Der Pico2 läuft (default) mit 150MHz,
dh. damit ist eine Auflösung von 6 2/3ns möglich.
Wer glatte Zahlen mag, bei 200MHz──▶5ns.

[Norbert (der_norbert)]

Michael P. schrieb:
> Kenne den Pico nicht, aber
> brauchst du unbedingt Variable-Typen inkl. double und print?

Der Pico2 hat zwei FPUs, bei float Addition und Multiplikation innerhalb 
eines Taktzyklus, Division innerhalb max. acht (IIRC)
Double braucht mit dem CoPro etwas länger, was aber an der Stelle völlig 
egal ist.

Ich könnte mir vorstellen, dass der ganze multiple Arduiono 
Überbau/Abstraktion einer präzisen Messung nicht unbedingt zuträglich 
ist.

[Christoph M. (mchris)]

Michael P. (mipo)
08.10.2025 07:12
>Kannst du den Fehler besser beschreiben?

Die Anzeige funktioniert ziemlich sicher. Das Diagramm zeigt eher 
Ausreißer als Jitter. Klar, dass es so was bisweilen gibt. Manchmal auch 
durch Übertragungsfehlern. Der Screenshot ist vom Plotter der 
Arduino-IDE und das funktioniert stabil.
Die Ausreißer würde ich eher als Interrupt-Querschläger ansehen. Ich 
hätte da weniger erwartet, weil ich die Zeitmessung mit "setup1" ja auf 
den zweiten Kern des PiPico gelegt habe.

Norbert (der_norbert)
>Wenn es sowohl schnell, als auch genau und ohne CPU Belastung gehen
>soll, dann empfehle ich nachdrücklich den Schwenk auf die PIO.

Da wäre die Frage, ob es überhaupt mit der hohen Auflösung geht. Auch 
die PIO muss ja ein paar paar Instruktionen durchführen.
Vor allen Dingen scheint mir der Aufwand recht hoch:
Laut

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

soll man den Online-PIO Assembler

https://wokwi.com/tools/pioasm

verwenden.

[Norbert (der_norbert)]

Christoph M. schrieb:
> Da wäre die Frage, ob es überhaupt mit der hohen Auflösung geht. Auch
> die PIO muss ja ein paar paar Instruktionen durchführen.

Zur ersten Frage: Ja, geht es.
Die PIO arbeitet jede Instruktion innerhalb eines Taktzyklus ab.
Zählen braucht eine, springen braucht eine. (Wenn man's sauber macht)

Da man aber zwölf Statemachines zur Verfügung hat, kann man getrost zwei 
davon zeitversetzt das gleiche messen lassen.

Ich selbst habe ganz sicher schon tausende Zeilen PIO-Assembler 
geschrieben (nicht übertrieben) und nicht einmal auf einen 
Online-Gehgips zurück greifen müssen. Zwei Hände voll Instruktionen 
stellen jetzt lernmäßig nicht die Eiger Nordwand in den Schatten (Sorry 
für's Wortspiel)

[Mi N. (msx)]

Christoph M. schrieb:
> So wie es aussieht, entstehen hier Fehler bis zu ca. 20%.

Das wundert nicht, da ohne richtige Synchronisierung von Eingangssignal 
und Referenztakt keine stabile Messungen möglich sind. Entweder 
verwendest Du externe D-FFs oder eine interne PIO + DMA.
Intern habe ich eine Lösung für den RP2040 auch für Arduino-IDE, die 
aber beim PicoPi2 wegen vermutlich wieder veränderter Arduino-Version 
nicht richtig compiliert wird. Beispiele kannst Du hier in der 
Codesammlung finden.

[Yalu X. (yalu) (Moderator)]

Läuft die serielle Kommunikation über USB? Dann unterbrechen oder
blockieren die USB-Interrupts sporadisch deinen GPIO-Interrupt, was dann
zu ungenauen Zeitmessungen führt.

Lässt du die Ausgabe der Ergebnisse über einen UART laufen, sollte das
nicht passieren.

[Christoph M. (mchris)]

Yalu X. (yalu) (Moderator)
08.10.2025 09:38

>Läuft die serielle Kommunikation über USB? Dann unterbrechen oder
>blockieren die USB-Interrupts sporadisch deinen GPIO-Interrupt, was dann
>zu ungenauen Zeitmessungen führt.

Ich habe das Programm noch mal umgeschrieben und Interrupt-frei gemacht. 
Es sind dann keine Ausreißer mehr sichtbar. Das Ganze läuft extra ohne 
alles auf dem zweiten Kern. Aber die maximale Abweichung liegt immer 
noch einiges über der anvisierten Nanosekundenauflösung (siehe Anhang, 
y-Achse: us).

/*
 * Periodendauermessung auf zweitem Kern
 * 
 * Abweichung ca. 0.7us => zu ungenau
 * 
 */
#include <Arduino.h>

volatile uint32_t DeltaT = 0;

#define TESTPIN 16

void setup() {
  Serial.begin(115200);
  pinMode(LED_BUILTIN, OUTPUT);
}

void setup1()
{
  pinMode(TESTPIN, INPUT_PULLUP);
}
void loop1()
{
  while (1)
  {
    static uint32_t oldPin = 0;
    if (gpio_get(TESTPIN) != oldPin)
    {
      static uint64_t last_cycles = 0;
      uint64_t t = rp2040.getCycleCount64();
      DeltaT = t - last_cycles;
      last_cycles = t;
      oldPin = gpio_get(TESTPIN);
    }
  }
}

void loop() {
  static bool state;
  uint64_t c;
  uint64_t f;
  float ns;
  float us;
  float minVal=1e6;
  float maxVal=0;
  f = rp2040.f_cpu();               // CPU frequency in Hz
    
  for (int n = 0; n < 100;n++)
  {
    c = DeltaT;
    ns = (double)c * 1e9 / (double)f;   // cycles -> nanoseconds
    us = ns/1000;
    Serial.println(us); //
    delay(20);
    if(minVal>ns)minVal=ns;
    if(maxVal<ns)maxVal=ns;
  }
  //Serial.println("max[ns]:"+String(maxVal));
  //Serial.println("min[ns]:"+String(minVal));
}

>Intern habe ich eine Lösung für den RP2040 auch für Arduino-IDE, die
>aber beim PicoPi2 wegen vermutlich wieder veränderter Arduino-Version
>nicht richtig compiliert wird.

Ich verwende das Early-Hill-Power Framework, das sollte recht stabil 
sein und besser als das originale Arduino PiPico mit MBed:
https://github.com/earlephilhower/arduino-pico
Dort kann man auch die nativen SDK-Funktionen benutzen (siehe oben im 
Code "gpio_get" statt digitalRead).
Wo genau kann ich deinen RP2040 Code finden?

[Mi N. (msx)]

Christoph M. schrieb:
> Wo genau kann ich deinen RP2040 Code finden?

Hier findest Du die Entwicklungsgeschichte zu meinen RP2040 Schaltungen: 
http://mino-elektronik.de/fmeter/fm_software.htm#bsp_RP2040

Bei der 'Luxusversion' mit TDC gibt es die Ausführungen für IAR-EWARM, 
Segger-IDE und Arduino, die nahezu identisch sind. Die Messungen laufen 
alle über Interrupts im Hintergrund. Das bedingt wegen der standardmäßig 
bei Arduino vorhandenen USB-Schnittstelle auf der einen Seite, daß die 
Interruptvektoren ins RAM gelegt werden müssen. Auf der anderen Seite 
muß die 'RP2040.h' der beiden anderen IDEs für Arduino passen und darf 
nicht mit den dortigen *.h-Dateien kollidieren.

Für Arduino funktionierte das mit IDE V 2.3.2 package "Raspberry Pi Pico 
3.7.0". Bei neueren Versionen sind unverständlicherweise die *.h-Dateien 
geändert/getauscht worden. Mir war es dann zu blöd, diesen Änderungen 
hinterher zu programmieren.

Im Anhang findest Du meine unvollendete Version, die eigentlich noch um 
serielle Befehle und Speicherung von Konstanten im FLASH-Speicher 
ergänzt werden sollte. Zur Datenübertragung wird USB benutzt.
DEF_F1_MESSZEIT (in ms) kannst Du ja auf den benötigten Wert 
verkleinern.
Ich hoffe, daß die Kommentare schon zur Verion passen.

[Yalu X. (yalu) (Moderator)]

Christoph M. schrieb:
> Ich habe das Programm noch mal umgeschrieben und Interrupt-frei gemacht.
> Es sind dann keine Ausreißer mehr sichtbar.

Sehr gut, dann lag es also tatsächlich an den Interrupts.

> Aber die maximale Abweichung liegt immer noch einiges über der
> anvisierten Nanosekundenauflösung

Mit welche Taktfrequenz läuft der Pico2? Glaubst du wirklich, man könne
damit 1ns auflösen?

> (siehe Anhang, y-Achse: us).

Ich habe mal mit großer Anstrengung versucht, die Schwankungsbreite aus
deinem maximal schlecht skalierten Diagramm herauszulesen und komme auf
etwa ±46ns. Das ist besser als ich von einer Lösung mit Arduino ohne PIO
erwartet hätte.

Besser geht es natürlich mit PIOs.

[Norbert (der_norbert)]

Yalu X. schrieb:
> Mit welche Taktfrequenz läuft der Pico2?

150MHz ist Standard.

> Glaubst du wirklich, man könne damit 1ns auflösen?

Nein, das würde 1GHz erfordern.
Bei 200MHz kann man aber schon präzise 5ns auflösen.

[Christoph M. (mchris)]

Norbert (der_norbert)
08.10.2025 11:35
>Pro Schritt 100 Messungen, von 1997cycles … 2003cycles.
>Bei 200MHz: 100150.230 Hz … 99850.230 Hz

Sind das Messungen? Wenn ja, dann sind sie verdächtig: 1 Bit 
Quantisierungsfehler sollte immer drinn sein.

[Christoph M. (mchris)]

Mi N.
>Hier findest Du die Entwicklungsgeschichte zu meinen RP2040 Schaltungen:
>http://mino-elektronik.de/fmeter/fm_software.htm#bsp_RP2040

Danke. Mit DMA, beeindruckend :-)

/*
 PIO0-SM0:
 Zeitzaehlung im x-Register mit SystemCoreClock/PIO_TIME_DIV (=4)
 und Ausgabe des Wertes bei negativer Flanke des Eingangssignals
*/
void init_PIO0(void)
{
// PIO0 aktivieren  
  RESETS_CLR->RESET = RESETS_RESET_pio0_Msk;
  while (!(RESETS->RESET_DONE & RESETS_RESET_pio0_Msk));

// FIN1_PIN f�r SM0 initialisieren
  IO_BANK0->GPIO2_CTRL = IO_BANK0_GPIO0_CTRL_FUNCSEL_sio_0; // GPIO-Eingang
  PADS_BANK0->GPIO2 = PADS_BANK0_GPIO0_IE_Msk |            
//                      PADS_BANK0_GPIO0_PUE_Msk |          // pullup
                      PADS_BANK0_GPIO0_SCHMITT_Msk;         //  + schmitttrigger
  
  PIO0->SM0_PINCTRL |= 1<<PIO0_SM0_PINCTRL_SIDESET_BASE_Pos | 1<<PIO0_SM0_PINCTRL_SET_BASE_Pos;
  PIO0->SM0_EXECCTRL = (31 << PIO0_SM0_EXECCTRL_WRAP_TOP_Pos) | 
                        (0 << PIO0_SM0_EXECCTRL_WRAP_BOTTOM_Pos) |
                        (FIN1_PIN  << PIO0_SM0_EXECCTRL_JMP_PIN_Pos);  // Pin f�r JMP
// ADR0  
  PIO0->INSTR_MEM0 = 0x0241;      // jmp x-- -> ADR1, 2 x delay
// ADR1
  PIO0->INSTR_MEM1 = 0x00c0;      // jmp FIN1_PIN -> ADR0 warten bis '0'
// input-pin 1 -> 0
  PIO0->INSTR_MEM2 = 0x4020;      // mov x->isr, x-Wert ausgeben
// ADR3
  PIO0->INSTR_MEM3 = 0x0044;      // jmp x-- -> ADR4
// ADR4  
  PIO0->INSTR_MEM4 = 0x00c1;      // jmp FIN1_PIN 0-> 1 dann ADR0
  PIO0->INSTR_MEM5 = 0x0103;      // jmp ADR3, 1 x delay
  
  PIO0_SET->SM0_SHIFTCTRL = PIO0_SM0_SHIFTCTRL_FJOIN_RX_Msk | // FIFO = 8
                            PIO0_SM0_SHIFTCTRL_AUTOPUSH_Msk;  // autopush
  PIO0_SET->CTRL = (1 << (PIO0_CTRL_SM_ENABLE_Pos));          // starten
}


// Zeitstempel erzeugen:
// DMA-Wert = Zeitpunkt, DMA-TRANS-COUNT = Ereignisse
// wenn CH0 fertig wird CH10 angestossen, der wiederum CH0 startet
// daher ist keine ISR notwendig
void init_dma_pio0(void)
{
  RESETS_SET->RESET = RESETS_RESET_dma_Msk;   // reset all CHx
  RESETS_CLR->RESET = RESETS_RESET_dma_Msk;
  while (!(RESETS->RESET_DONE & RESETS_RESET_dma_Msk));

// Zaehlen der Ereignisse und lesen des Zeitstempels  
  DMA->CH0_READ_ADDR = (uint32_t) &PIO0->RXF0;
  DMA->CH0_WRITE_ADDR = (uint32_t) &F1_time_stamp;
  DMA->CH0_TRANS_COUNT = DMA_COUNT;
  DMA->CH0_CTRL_TRIG =  DREQ_PIO0_RX0 << DMA_CH0_CTRL_TRIG_TREQ_SEL_Pos |     // PIO0-RX0
                        10 << DMA_CH0_CTRL_TRIG_CHAIN_TO_Pos |  // trigger CH10
                        2 << DMA_CH0_CTRL_TRIG_DATA_SIZE_Pos |  // word
                        DMA_CH0_CTRL_TRIG_EN_Msk;               // enable

// Hilfskanal zum Nachtriggern con CH0  
  DMA->CH10_READ_ADDR = (uint32_t) &dma_dummy;                  // dummy location
  DMA->CH10_WRITE_ADDR = (uint32_t) &dma_dummy;
  DMA->CH10_TRANS_COUNT = 1;                                    // single transfer
  DMA->CH10_CTRL_TRIG =  DREQ_AUTO << DMA_CH0_CTRL_TRIG_TREQ_SEL_Pos | // free running
                        0 << DMA_CH0_CTRL_TRIG_CHAIN_TO_Pos |   // Trigger CH0  
                        2 << DMA_CH0_CTRL_TRIG_DATA_SIZE_Pos |  // word
                        DMA_CH0_CTRL_TRIG_EN_Msk;               // enable
}

[Norbert (der_norbert)]

Sieben mal je 100 Messungen, von 1997 … 2003 Taktzyklen(à 5ns)
Bei 200MHz ergeben sich Frequenzen von 100150.230 Hz … 99850.230 Hz

[Norbert (der_norbert)]

Christoph M. schrieb:
> Sind das Messungen? Wenn ja, dann sind sie verdächtig: 1 Bit
> Quantisierungsfehler sollte immer drinn sein.

Das sind Messungen. Aber auf einem Controller.
PIO1 erzeugt die Frequenz auf GPIO16, PIO0 misst sie auf GPIO17.
Da muss man nicht so eine große Brücke bauen! ;-)

Also 100% synchron.
Aber du hast recht, wenn man etwas Externes messen würde, dann käme 1 
cycle Unschärfe hinzu. (Plus die ppms der beteiligten Quarze)

[Christoph M. (mchris)]

Christoph M. schrieb:
> So wie es aussieht, entstehen hier Fehler bis zu ca. 20%.
von Mi N. (msx)
08.10.2025 09:15
>>Das wundert nicht, da ohne richtige Synchronisierung von Eingangssignal
>>und Referenztakt keine stabile Messungen möglich sind. Entweder
>>verwendest Du externe D-FFs oder eine interne PIO + DMA.

Da ist mir nicht ganz klar, wie du das meinst. Eigentlich sollte der 
Jitter ja nur 1 Taktzyklus betragen. Wie oben gezeigt, schafft das 
Norbert ja mit 5ns Auflösung. Wenn man nicht mit einem synchronisiert, 
sollte das dann +-5ns sein.

[Mi N. (msx)]

Christoph M. schrieb:
> Da ist mir nicht ganz klar, wie du das meinst. Eigentlich sollte der
> Jitter ja nur 1 Taktzyklus betragen.

Ja, aber erst, wenn man auch die Verarbeitung der Ereignisse dem 2. Kern 
überträgt.
Mit "richtiger Synchronisierung" meine ich, daß man synchron zu einem 
Eingangsereignis dessen Zählerstand und auch des Referenzzählers 
einfriert ('capture') und später verarbeiten kann. Das war bei Deiner 
eingangs gezeigten Programmversion ja nicht der Fall. Loop() bei Arduino 
bedeutet, daß noch viele 'unsichtbare' Funktionen ausgeführt werden, die 
zeitlich nicht begrenzt sein müssen. Anders wäre es bei einer 
while()-Schleife, wo nur ISRs dazwischen funken können.

[Norbert (der_norbert)]

Mi N. schrieb:
> Christoph M. schrieb:
>> Da ist mir nicht ganz klar, wie du das meinst. Eigentlich sollte der
>> Jitter ja nur 1 Taktzyklus betragen.
>
> Ja, aber erst, wenn man auch die Verarbeitung der Ereignisse dem 2. Kern
> überträgt.

Hmmm.
Ich hab's hier auf einem einzelnen Kern realisiert.

[Mi N. (msx)]

Norbert schrieb:
> Hmmm.
> Ich hab's hier auf einem einzelnen Kern realisiert.

Du bist ja auch Profi und hast keine Arduino-IDE benutzt!

Norbert schrieb:
> PIO1 erzeugt die Frequenz auf GPIO16, PIO0 misst sie auf GPIO17.
> Da muss man nicht so eine große Brücke bauen! ;-)

Damit bekommt man auch Frequenzmessungen auf 20 Stellen stabil :-)

[Norbert (der_norbert)]

Mi N. schrieb:
> Damit bekommt man auch Frequenzmessungen auf 20 Stellen stabil :-)

Klar. Bin aber ein fauler Sack und hatte keine Lust einen Zweiten dran 
zu hängen. ;-)
Es ging aber auch nur um den Jitter, welcher bei dieser Kopplung aus 
verständlichen Gründen ›0‹ ist und bei Fremdfütterung max. 1 cycle 
beträgt.

[Christoph M. (mchris)]

Mi N. (msx)
16.10.2025 13:36
>Du bist ja auch Profi und hast keine Arduino-IDE benutzt!
Ich denke, er hat MicroPython benutzt.

[Norbert (der_norbert)]

Christoph M. schrieb:
> Mi N. (msx)
> 16.10.2025 13:36
>>Du bist ja auch Profi und hast keine Arduino-IDE benutzt!
> Ich denke, er hat MicroPython benutzt.

Alles bis ein paar hundert MHz und wenige Nanosekunden lässt sich damit 
ja prima handeln.
Und für hundert Zeilen Code wirft man doch keinen C-Compiler an.

[Christoph M. (mchris)]

Norbert schrieb
>Alles bis ein paar hundert MHz und wenige Nanosekunden lässt sich damit
>ja prima handeln.

Ja, den Frequenzzähler von Mi N. hätte man wahrscheinlich auch gut in 
Micropython machen können, vermute ich.

[Norbert (der_norbert)]

Christoph M. schrieb:
> Norbert schrieb
>>Alles bis ein paar hundert MHz und wenige Nanosekunden lässt sich damit
>>ja prima handeln.
>
> Ja, den Frequenzzähler von Mi N. hätte man wahrscheinlich auch gut in
> Micropython machen können, vermute ich.

Noch einfacher und ohne DMA. Das hier ist alles was man braucht:

from array import array
from rp2 import PIO, StateMachine, asm_pio
from machine import freq as cpufreq

[Apollo M. (Firma: @home) (majortom)]

Norbert schrieb:
> from array import array
> from rp2 import PIO, StateMachine, asm_pio
> from machine import freq as cpufreq

Zeig mal bitte noch den Rest, damit ich das mal ausprobieren kann.
Ich bin bekennender MP Fanboy.

[Mi N. (msx)]

Apollo M. schrieb:
> Zeig mal bitte noch den Rest, damit ich das mal ausprobieren kann.

Oh ja! Weihnachten ist ja schon bald ;-)

[Christoph M. (mchris)]

Apollo M. (Firma: @home) (majortom)
17.10.2025 23:11
>Zeig mal bitte noch den Rest, damit ich das mal ausprobieren kann.
>Ich bin bekennender MP Fanboy.

Vielleicht hilft dir das weiter:
https://github.com/intel00000/pi_pico_pio_pwm_frequency_measurement

[Pandur S. (jetztnicht)]

Allenfalls sollte man sich ueberlegen, was man genau will. Falls die 
Messung fuer einen visuellen Zahlen Display gedacht ist, bringen mehr 
wie 3-10 updates pro sekunde nichts. Die kann man nicht ablesen.
Falls man den Wert fuer eine Regelung will genuegt meist die 
Periodendauer in zufaelligen Einheiten, sprich der Zaehlerwert passt.