Pi Pico _PIO_

von Tim  . (cpldcpu)
24.01.2021 11:36
>Warum benötigt man dafür die PIO? Je nachdem, über welche Frequenzen wir
>reden, schafft das auch die CPU.

Weil der Chip nur zwei Kerne hat. Anwendungsbeispiel: Mikropython auf 
Kern 1, Echtzeitaudio auf Kern 2 und DAC durch PIO. Schließlich will man 
keine wertvollen Zyklen für einen Peripheribaustein verschwenden.

>Bei der Implementation im PIO wird es wohl eher ein Thema sein, dass es
>keine Möglichkeiten zur Addition gibt. Wahrscheinlich wäre es einfacher,
>die CPU einen Bitstream berechnen zu lassen, den die PIO dann ausgibt.

Das habe ich beim Betrachten des Befehlssatzes auch zuerst gedacht: 
keinerlei Rechenoperationen.

Aber wie beim Design Deiner *MininmalCPU gibt es doch meistens 
Möglichkeiten, die einem nicht sofort ins Auge springen:

https://github.com/raspberrypi/pico-examples/blob/master/pio/addition/addition.pio

Zugegebenermaßen reicht das möglicherweise aus Geschwindigkeitsgründen 
nicht für den Modulator.

*MinimalCPU: https://github.com/cpldcpu/MCPU

Tim  . schrieb:

> Warum benötigt man dafür die PIO? Je nachdem, über welche Frequenzen wir
> reden, schafft das auch die CPU.

Nunja, genau das ist der Punkt: was mache ich, wenn's der MCU-Core halt 
nicht schafft. Oder auch nur, wenn er es zwar schaffen würde, aber 
eigentlich für was anderes benötigt wird, eine Sache, die seinen 
Fähigkeiten weit angemessener ist, nämlich die eigentliche Anwendung...

Und, wie der Zufall so will (ich bezweifele, das es sich um einen Zufall 
handelt ;o), ist das Beispiel mit der Realisierung eines VGA-Displays 
ein sehr schönes Beispiel für genau so etwas.

Das Display ist nur Mittel zum Zweck. Und man kann es realisieren, weil 
es genug Speicher gibt und die PIO-Einheit. Und man hat am Ende immer 
noch zwei M0+-Cores für die eigentliche Anwendung zur Verfügung.

Genau diese Fähigkeit ist sehr attraktiv. Denn in sehr vielen 
Anwendungen will man zwar ein Display mit einer Größe jenseits dessen, 
was mit einem SPI-gesteuerten TFT sinnvoll möglich ist, aber man kann 
für die eigentliche Anwendung sehr gut mit relativ wenig RAM und der 
relativ bescheidener Rechenleistung auskommen.

Bei dem bisher verfügbaren Angebot an µC musste man oft zwingend auf 
Dickschiffe wie M4 oder gar M7 ausweichen (ggf. mit angeflanschtem RAM), 
nur um genug RAM für das Display zu bekommen und eine Hardware, die es 
ansteuern kann. D.h.: man bezahlt für etwas, von dessen Leistung man nur 
einen Bruchteil wirklich benötigt, nur um dieses eine Feature 
realisieren zu können.

Genau auf diese Lücke des Marktes zielt der PasPi Pico (bzw. der 
RP2040). Und ich wage vorherzusagen, dass er erfolgreich sein wird, weil 
es sehr viele alte Designs im Industriebereich gibt, deren 
Funktionalität im Kern erhalten bleiben soll, deren Anmutung und 
Bedienung für den potentiellen Käufer aber modernisiert werden soll.

Nach all dem Lobgehudel muss ich aber auch noch eins sagen: Warum, zum 
Teufel, haben die Typen nicht alle 6 SRAM-Bänke mit 64k ausgestattet? 
Das würde noch eine Displayklasse höher erschließen (ohne Kunstgriffe). 
HIER wurde meiner Meinung nach am falschen Ende gespart.
Kann aber auch sein, dass das sehr wohl bedacht wurde und irgendwann in 
nicht allzu ferner Zukunft noch ein entsprechender Chip folgt. 
Vermutlich sogar aus demselben Prozess, wenn er denn gut eingelaufen ist 
und die Ausbeute hinreichend hoch...

c-hater schrieb:
> Und ich wage vorherzusagen, dass er erfolgreich sein wird, weil
> es sehr viele alte Designs im Industriebereich gibt, deren
> Funktionalität im Kern erhalten bleiben soll, deren Anmutung und
> Bedienung für den potentiellen Käufer aber modernisiert werden soll.

Aber dafür nehme ich doch keinen mini-Elefanten, dem man an allen Ecken 
und Enden das Fliegen beibringen muss. Ein STM32F730 oder H730 kostet 
nur wenig mehr, spart aber jede Menge Entwicklungszeit - gerade im 
industriellen Bereich.

Wie ich es sehe, gibt es ein neues, billiges Spielzeug, und die 'ganze 
gelangweilte Entwicklerwelt' sucht jetzt nach Anwendungen dafür. Zum 
Beispiel VGA: Auch eine schöne Spielerei, aber wo gibt es dafür noch 
passende Monitore? TFT ist angesagt und dafür ist das Timing völlig 
unkritisch. Per DMA braucht es auch kaum CPU-Belastung.

chris_ schrieb:
> einen Sigma-Delta-Modulator als DAC-Ersatz zu programmieren.

Du meinst wohl ADC? Das mag sicherlich dort interessant sein, wo hohe 
Stückzahlen gebraucht werden. Mag ja sein, daß der RP2040 mal als Chip 
verfügbar sein wird. Aber für UNS ist das doch eher belanglos.
Man müßte mal den Transputer erfinden ;-)

Jack V. schrieb:
> ADC hat er doch?

Stimmt! Dann lasse ich mich mal überraschen.

m.n. schrieb:

> Zum
> Beispiel VGA: Auch eine schöne Spielerei, aber wo gibt es dafür noch
> passende Monitore? TFT ist angesagt und dafür ist das Timing völlig
> unkritisch. Per DMA braucht es auch kaum CPU-Belastung.

Naja, diese PIO-Einheit ist ja gerade dafür gut, DMA und MCU-Aktivitäten 
mit trivialen GPIO-Ausgaben zu verknüpfen. Das funktioniert für die 
Ausgabe an ein paralleles (DPI) LCD genauso, wie für das VGA aus dem 
Beispiel. Bloß, dass man nicht diese DA-Wandler für Arme benötigt, dafür 
aber ein zusätzliches Signal (DE oder HENAB oder wie auch der 
Display-Hersteller es nun gerade tituliert hat). That's the trick.

Mindestens so wichtig aber die Verfügbarkeit von genug internem RAM für 
den Framebuffer.

Der eine Aspekt wird in den bisher verfügbaren µC typisch von einer 
speziellen Einheit erledigt, die halt in den kleinen Teilen mit M0/M0+ 
nicht existiert.

Und der andere Aspekt ist halt die Menge an RAM, die ebenfalls in den 
kleinen Teilen nicht hinreichend ist.

Beides zwingt zu den grossen Schiffen, die aber ansonsten für die 
Anwendung meist völlig überdimensioniert (und zu teuer) sind. Das genau 
ist der Punkt.

> So ganz verstehe ich die Motivation für einen eigenen Controller
> trotzdem nicht.

Sie wollten wohl etwas Arduino-artiges, das mit Python programmiert 
werden kann.

> Beispiel VGA: Auch eine schöne Spielerei, aber wo gibt es dafür noch
> passende Monitore? TFT ist angesagt

Die PIOs sind halt flexible I/O-Blöcke.  Damit kann man VGA-Ausgabe 
machen, genauso gut aber auch TFT oder WS2812 oder I2S oder schnelle 
externe ADCs[1] oder ...  Sowas ist mir lieber als dutzende von festen 
HW-Blöcken.



[1] Bin mal gespannt, wann das erste MiniScope mit 50MS/s auftaucht ;-)

> Evtl. könnte man mit der PIO einen PWM-Ausgang realisieren, der per DMA
> nachgeladen wird?

8 DMA-fähige PWM-Kanäle sind bereits vorhanden - dafür brauchst du 
nichtmal die PIOs.

>Na dann braucht man die PIO in der Tat nicht, um einen DAC zu ersetzen.

Dann musst solltest Du fragen, warum bei Audio-DACs keine PWM eingesetzt 
wird.

> Dann musst solltest Du fragen, warum bei Audio-DACs keine PWM eingesetzt
> wird.

Soviel ich weiß, ist der analoge Audioausgang beim RaspPi 3 und 4 über 
PWM und einen popeligen RC-Filter implementiert ;-)

foobar (Gast)
>> Dann musst solltest Du fragen, warum bei Audio-DACs keine PWM eingesetzt
>> wird.

>Soviel ich weiß, ist der analoge Audioausgang beim RaspPi 3 und 4 über
>PWM und einen popeligen RC-Filter implementiert ;-)

Deshalb hatte schon der Raspberry 1 eine ziemlich schlechte Kritik des 
Audioausgangs in der CT bekommen.

Tim  . (cpldcpu)
>Man sollte natürlich berücksichtigen, dass dass bei einem Digital-IC wie
>dem RP2040 kaum eine brauchbar saubere Versorgungsspannung zu erreichen
>ist. Die 120dB Audio-CODEC lagert man da lieber aus.

Niemand sagt, dass man mit dem Chip eine High-End-Hifi Anlage bauen 
soll, wobei man den Digitalausgang auch an einen separat versorgten 
Treiber anschließen könnte.
Der Parallax Propeller verwendet die Modulatoren für die DACs jedenfals 
ausgiebig und die Verwendung von PWM würde zu Mischprodukten im 
Frequenzbereich führen, wie hier im Forum von Jürgen S. schon mehrfach 
erörtert.

>Nun stellt sich also die Frage, wer es als erster schafft, einen
>Sigma-Delta-Modulator als DAC-Ersatz zu programmieren.

Hier das Ergebnis:

https://github.com/tierneytim/Pico-USB-audio