Der auf dem Pico-Board verbaute RP2040 bietet mit seinen PIO-Einheiten die Möglichkeit, einen 4-fach Quadratur-Dekoder mit hoher Zählrate zu implementieren, sodaß Signaländerungen bis zu 1 x 10^7 Flanken/s erfasst werden können. Ferner kann der Index-Impuls von Weg- oder Drehgebern ausgewertet werden, der den internen Zähler auf 0 oder einen frei wählbaren Vorgabewert setzt. Die Schaltung besteht aus dem fertigen RP2040-Pico-Board, an dessen Eingänge GPIO10 und GPIO11 die beiden Phasen A/B des Gebersignals angeschlossen werden. Der Index-Impuls wird an GPIO12 erwartet und ist beim gezeigten Programm mit '0'-Pegel aktiv. Wird '1'-Pegel benötigt, kann der GPIO-Pin umprogrammiert werden. Sofern die Gebersignale Pegel > 3,3 V liefern, müssen Spannungsteiler oder zumindest Schutzwiderstände in die Signalleitungen eingefügt werden. Das Demoprogramm ist für die Arduino-IDE geschrieben und gibt den aktueller Zählerstand bei Änderung über die USB-Schnittstelle aus. Die .uf2-Datei kann im Boot-Modus ohne Verwendung einer Arduino-IDE direkt auf das Pico-Board geschrieben werden. Das Programm-Modul 'pio_qcnt.c' kann auf andere IDEs übertragen werden. Sollte die Dateiendung aus Gründen der Kompatibilität zu Arduino auf '*.ino' umbenannt werden, muß 'rp2040_arduino.h' verwendet werden, um keine doppelten Definitionen zu erhalten.
:
Bearbeitet durch User
Da würde mich schon interessieren, welche Mechanik in der Lage ist, sich mit 10MHz zu bewegen. Ich hatte mal einen Glasmeßstab für Positionierung im µm Bereich auslesen müssen, da hat ein AT89C51 mit 50kHz Interrupt völlig gereicht.
Peter D. schrieb: > Ich hatte mal einen Glasmeßstab für Positionierung im µm Bereich > auslesen müssen, da hat ein AT89C51 mit 50kHz Interrupt völlig gereicht. Damit gehörst Du nicht zu der Zielgruppe meines Vorschlages. 50 kHz können schon von inkrementalen Kurzhubtastern (beispielsweise Heidenhain MT12, MT25) überschritten werden. Wenn der Zähler zudem das Index-Signal nicht auswerten kann, ist Schluß mit lustig. Optische, inkrementale 'Multiturn'-Drehgeber können locker MHz Signale liefern. Noch einmal zur Verdeutlichung: gezeigt ist ein Quadratur-Dekoder mit PIO1. Der Zähler läuft völlig ohne Interrupt im Hintergrund und der aktuelle Zählerstand ist als Variable 'q_cnt' ohne spezielle Abfragesequenzen direkt verfügbar. Wenn beispielsweise ein Profil erfaßt werden soll, kann 'q_cnt' per Timer und DMA ohne weiteren Softwareeingriff direkt in ein Array geschrieben werden. Bei Bedarf kann ein weiterer Zähler mit PIO0 realisiert werden. Alles zusammen auf einem µC zu 1 Euro oder einem Demo-Board für < 5 Euro. Aber gut, das braucht nicht jeder und ist ja auch nicht schlimm.
Mi N. schrieb: > Der auf dem Pico-Board verbaute RP2040 bietet mit seinen PIO-Einheiten > die Möglichkeit Diese PIOs in dem RP2040 sind eine wirklich leistungsfähige Peripherie. Da lässt sich viel mit machen ohne CPU. Mich wundert das andere Hersteller so etwas nicht mit anbieten. Ich finde eines der besten (wirklichen!) Neuerungen der letzten Jahre in der uc-Welt.
Peter D. schrieb: > Da würde mich schon interessieren, welche Mechanik in der Lage ist, sich > mit 10MHz zu bewegen. Naja. Schon die billigen optischen Drehgeber mit 600 Strichen halten 6000 U/min aus. Das gibt dann 240000 Flanken/Sekunde.
900ss schrieb: > Mich wundert das andere Hersteller so etwas nicht mit anbieten. Andere haben das auch. :-) Mit neueren 8Bit AVRs gehts auch. https://ww1.microchip.com/downloads/en/AppNotes/00002434A.pdf
Veit D. schrieb: > 900ss schrieb: >> Mich wundert das andere Hersteller so etwas nicht mit anbieten. > > Andere haben das auch. :-) Mit neueren 8Bit AVRs gehts auch. > https://ww1.microchip.com/downloads/en/AppNotes/00002434A.pdf Naja... Ich habe auch mit dem Eventsystem und der CCL neuzeitlicher AVR8 schon recht viel gearbeitet. Das ist wirklich oft eine hilfreiche Sache, wenn's in reiner Software eng wird. Aber, was damit möglich ist, reicht natürlich nicht annähernd an die Flexibilität der PIOs eines Pi Pico heran. Von der Geschwindigkeit wollen wir gar nicht erst anfangen zu reden.
Veit D. schrieb: > Andere haben das auch. :-) Mit neueren 8Bit AVRs gehts auch. Na ja, ein wenig haben die AVRs. Aber es reicht bei weitem nicht an die Möglichkeiten der PIO im RP2040 ran. Und die PIO läuft mit 125MHz wenn man möchte.
900ss schrieb: > Und die PIO läuft mit 125MHz wenn > man möchte. Das ist zwar korrekt, aber eine durch und durch konservative Betrachtung. Insbesondere da ich hier schon > 320MHz Systemtakt problemlos laufen hatte. Und die PIOs werden mit demselben Takt versorgt. Warum man sich auf default 125MHz festgelegt hat – die M0+ dual cores können laut Datenblatt ja bereits 133MHz – entzieht sich mir ebenfalls.
Norbert schrieb: > Das ist zwar korrekt, aber eine durch und durch konservative > Betrachtung. Nein. Es ist innerhalb der Spezifikation die du ignorierst. Das ist ein Vorgehen was mir fern liegt. Auch wenn es hier und da funktioniert. Kann man als Sport mal machen....
:
Bearbeitet durch User
900ss schrieb: > Norbert schrieb: >> Das ist zwar korrekt, aber eine durch und durch konservative >> Betrachtung. > > Nein. Es ist innerhalb der Spezifikation die du ignorierst. Das ist ein > Vorgehen was mir fern liegt. Auch wenn es hier und da funktioniert. Kann > man als Sport mal machen.... Siehst du, das ist ja seltsam. Ich dachte immer das die Datenblätter maßgeblich wären. In meinem steht Dual Core M0+ 133MHz. Nix 125MHz.
900ss schrieb: > Nein. Es ist innerhalb der Spezifikation die du ignorierst. Die erlaubt allerdings definitiv 133Mhz. Auch für die PIOs. Die 125Mhz stammen nur aus der default-Konfig der SDKs. Das ist NICHT die Spezifikationsgrenze. Alles über 133MHz hinaus ist aber natürlich jenseits der Spezifikation und damit wirklich mehr oder weniger Glücksspiel.
900ss schrieb: > Na ja, ein wenig haben die AVRs. Aber es reicht bei weitem nicht an die > Möglichkeiten der PIO im RP2040 ran. Auf ersten Blick sieht man es nicht, aber der RP2040 ist insgesamt schon recht clever konzipiert. Gut, man könnte sich hier und da noch andere Möglichkeiten wünschen, muß aber die Kompromisse beim Design verstehen und akzeptieren. Dazu jeder PIO-Befehl in einem Takt - echt schnell. > Und die PIO läuft mit 125MHz wenn man möchte. Auch locker mit 300 MHz wie auch der restliche µC, wenn man die interne 'Kern'-Spannung auf 1,3 V erhöht. Das ist ganz wichtig und kein Glücksspiel! Falls irgendetwas zu langsam läuft, ist noch reichlich Reserve vorhanden. Gut, bei Raumfahrtanwendungen nehme ich ganz brav 133 MHz. Mittlerweile habe ich obiges Programm etwas verändert und auf explizit zwei Kanäle (0 und 1) erweitert. Um Kollisionen mit ggf. anderen Funktionen / Libs zu vermeiden ist Kanal1 zu empfehlen, weil PIO1, die oberen DMA-Kanäle und nun GPIO13-15 verwendet werden. 'Standardanwendungen' werden vermutlich mit GPIO0, PIO0 und DMA_CH0 anfangen ;-) http://mino-elektronik.de/mt12_iic/mt12_iic.htm#qcnt_pico
Hallo, habe jetzt nicht in die Details vom RP2040 geschaut. Takten die I/O wirklich mit vollen CPU Takt? Ist bei ARM-Kernen nicht eher der I/O Teil "abgekoppelt"? Oder trifft das nur bei noch höher getakteten Rechenkernen zu?
Veit D. schrieb: > Takten die I/O > wirklich mit vollen CPU Takt? Yep, tun sie. Da hat sogar mein betagtes 50MHz Scope das Handtuch geworfen. Allerdings nur die ›normale‹ Taktfrequenz getestet. Würde mich aber nicht wundern wenn das noch viel höher ginge. Per SIO direkt von den CPU-Kernen. Per PIO direkt aus der Hardware. Nicht schlecht für'n Euro
:
Bearbeitet durch User
Norbert schrieb: > In meinem steht Dual Core M0+ 133MHz. > Nix 125MHz. Ob S. schrieb: > Die 125Mhz stammen nur aus der default-Konfig der SDKs. Das ist NICHT > die Spezifikationsgrenze. Da haben wir ja zwei richtige Klugscheißer. Zeigt mir mal wo ich geschrieben habe, dass 125MHz die Spezifikations Grenze ist. Und ich bin wirklich beeindruckt dass ihr eine CPU übertakten könnt. Das ist ziemlich cool. Respekt.
:
Bearbeitet durch User
900ss schrieb: > Zeigt mir mal wo ich geschrieben habe, Sag mal, ist dir das nicht peinlich? Erst bist du unfähig deine Gedanken vernünftig darzustellen. Dann gibst du anschließend den Unschuldigen? Na ja, jeder wie er kann…
Norbert schrieb: > Erst bist du unfähig deine Gedanken vernünftig darzustellen. Ich kann nichts dafür, wenn du nicht verstehen kannst.
Norbert schrieb: > Du kannst wirklich gar nichts… gähn..... Ich zeigs dir nur nicht :) Ist gut jetzt, geht hier um was anderes.
900ss schrieb: > Da haben wir ja zwei richtige Klugscheißer. Nur Leute, die Specs lesen können. Offensichtlich im Gegensatz zu dir. Der halt alles, was er weiss (oder glaubt zu wissen) irgendwelchen Standardeinstellungen eines SDKs entnommen hat. > Zeigt mir mal wo ich geschrieben habe, dass 125MHz die Spezifikations > Grenze ist. Hast du nicht explizit, aber implizit. > Und ich bin wirklich beeindruckt dass ihr eine CPU übertakten könnt. Das > ist ziemlich cool. Respekt. Hier schon wieder. Nein, 133MHz sind eben einfach mal spezifikationsgerecht! Wer die nutzt, übertaktet die CPU eben nicht, sondern nutzt sie vollkomen im Rahmen ihrer Spezifikation. Dass du wohl nicht in der Lage dazu bist, deinen Produkten diese Geschwindkeit zu verleihen, zeigt nur eins: Dass du keinerlei ernsthafte Ahnung hast. Sonst wüßtest du erstens, dass das erstens absolut zulässig ist und zweitens wüsstest du auch, wie man's macht... Nixwisser. Das allein ist noch nicht ganz schlimm (selbst du könntest vermutlich dazu lernen). Schlimm wird's erst dadurch, dass du dein Nixwissen zum Axiom erhebst. Das produziert unweigerlich den Widerspruch der Leute, die wirklich was wissen. Die nennst du dann "Klugscheißer". Findest du das nicht selber ziemlich armselig?
Ob S. schrieb: > Hast du nicht explizit, aber implizit Da war nichts implizit, das ist rein deine Interpretation die zuweilen eben daneben liegt. Ob S. schrieb: > Nein, 133MHz sind eben einfach mal spezifikationsgerecht! Wer die > nutzt, übertaktet die CPU eben nicht, sondern nutzt sie vollkomen im > Rahmen ihrer Spezifikation. Habe nirgends geschrieben, dass 133MHz nicht innerhalb der Spezifikation ist. Auch wieder so eine Erfindung. Die z.B. erwâhnten 320MHz nicht. 133MHz ist halt das Maximum laut Datenblatt. Dass mehr gehen kann, hat hat in meinen Augen mit seriösem Design nichts zu tun. Ich haben lediglich erwähnt das die PIOs mit 125MHz laufen können aber nicht dass es das Maximum sei. Ist ja auch ein signifikanter Unterschied zu den erlaubten 133MHz. Meine Güte.... %-/ Bei dem Rest deiner Äußerungen lass ich dich mal in dem Glauben den du hast :) Ist eh chancenlos.... .
:
Bearbeitet durch User
Bei dem verlinkten Programm für zwei Kanäle, hatte ich der Einfachheit halber, die Funktion von PIO1 auf PIO0 kopiert. Das ging schnell, ist aber nicht sonderlich geschickt. Daher zeige ich hier eine Verbessung und Erweiterung auf max. 4 Kanäle, die allesamt mit PIO1_SM0 - SM3 umgesetzt sind. PIO0 bleibt frei verfügbar. http://mino-elektronik.de/progs/RP2040/Pico-qcnt4x.zip Die beiden ersten Kanäle 0 und 1 arbeiten wie zuvor mit jeweils zwei DMA-Kanälen. Kanäle 2 und 3 sind etwas abgemagert, haben keinen INDEX_PIN-Eingang und werden (zur Demonstration) Faktor 10 langsamer betrieben. Das spart jeweils einen Eingangspin und einen DMA-Kanal. Der verwendete DMA-Kanal (CH6 / CH7) wird bei jedem Lesen des Zählerstandes zurückgesetzt, was in der Praxis keine Einschränkung darstellen sollte. Eine Alternative wäre, das Nachtriggern nach 2^32 - 1 Flankenwechseln per ISR zu erledigen.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.