Forum: Mikrocontroller und Digitale Elektronik Raspberry Pi Pico: nur als Schulungssystem gut geeignet.


von Tam H. (Firma: Tamoggemon Holding k.s.) (tamhanna)


Angehängte Dateien:

Lesenswert?

von Tam Hanna

Kaum war der Raspberry Pi Pico offiziell am Markt, so gab es Dutzende von Projekten, die bei Journalisten einen Wow-Effekt auslösen. Hier eine kleine Liste von Gründen, warum Sie den Controller nicht in einem kommerziellen Produkt verwenden sollten.

Nähern wir uns der Boeing 717 von der Fronttüre - ganz analog zu McDonnell Douglass letztem Luftfahrzeug gilt auch im Fall des RP2040, dass die Verfügbarkeit schwierig ist. Eine am 21. Januar bei RS Electronics getätigte Bestellung wurde immer noch nicht ausgeliefert – der von der Foundation traditionell bevorzugte Ameisenhandel (Rasppishop) hatte Restposten. Denken Sie daran, dass in der letzten Zeit selbst Unternehmen wie STMicroelectronics immer wieder Probleme hatten, Lieferungen zu erfüllen. Ob bzw. wie die Raspberry Pi Foundation auf eine Order für 25000 Chips reagiert, ist unklar – im Moment ist der Microcontroller im freien Markt noch nicht als Standalone-Chip verfügbar. Dass der Raspberry Pi Pico über keinen DAC verfügt, dürfte bekannt sein. Ärgerlicherweise zieht der ADC erhebliche Eingangsströme. Beim Betrieb einer Multimeter-Testschaltung mit MicroPython floss permanent ein Strom von 0,04 mA, was ob des Schutzwiderstands R3 das Zwischenschalten eines OpAmp-Puffers notwendig machte.

Dass einige andere Peripheriestandards - Stichwort beispielsweise ein CAN-Controller - fehlen, kann in Zukunft für Rewrites der Codebasis sorgen, wenn am Ende doch ein Umstieg auf ein anderes System notwendig wird.

Ohne internen Flashspeicher!

Der RP2040 hat keinen internen Flashspeicher; der Raspberry Pi Pico bringt einen externen Flashchip mit. Dies mag ihn nicht von der Bezeichnung Mikrocontroller disqualifizieren - der Intel 8035 hatte ebenfalls kein Flash - ist allerdings ein zusätzliches Ärgernis. Das Anhängen eines externen Flash-Chips führt dazu, dass das Sichern des hauseigenen geistigen Eigentums wesentlich schwieriger wird - böse Zungen könnten behaupten, dass diese Zwangs-Opensoureisierung der Raspberry Pi Foundation ins Konzept passt. Ein zweischneidiges Feature ist der integrierte Bootloader - er ist lustig, als sich das Gerät wirklich per Drag and Drop programmieren lässt. Andererseits sitzt der Bootloader - laut Datenblatt - in einer „nicht veränderlichen“ Speicherzone, weshalb dort befindliche Fehler auf immer Teil der Solution sind und sie zudem bei Zertifizierung und Co Probleme bekommen könnten. Immerhin ist der RP2040 nicht allzu langsam - ein kleiner Test des Autors mit einem in C gehaltenen Blinkprogramm ergab eine Start-Verzögerung von rund 25ms (siehe Abbildung). Bei Verwendung von MikroPython bekamen wir stattdessen eine Wartezeit von 143 ms, auch hier ein Oszillogramm.

Weil das Oszilloskop schon da ist: Eine kleine Startzeit-Messung Weil das Oszilloskop schon da ist: Eine kleine Startzeit-Messung

MicroPython verlangsamt den Start zusätzlich MicroPython verlangsamt den Start zusätzlich

Im Bereich der GPIO-Pins geht die Raspberry Pi Foundation ebenfalls einen Eigenweg – der RP2040 hat 30 als User GPIO bezeichnete Ausgabepins, die als Entschädigung dafür allerdings über ein Register direkt ansprechbar sind - kein Banking. Ein weiterer Aspekt ist der Zustandsautomat, der - etwas fortgeschrittener als Microchips Configurable Logic Cell - die Erzeugung von „zusätzlicher Intelligenz“ in der GPIO-Engine erlaubt.

Exzellente Dokumentation.

Ein Kritikpunkt am STMicroelectronics-Ökosystem ist das Chaos - da die Raspberry Pi Foundation nur einen einzigen Mikrocontroller ins Rennen schickt, fällt die Dokumentation übersichtlicher aus. Auf der Soll-Seite steht in diesem Bereich allerdings das Fehlen einer vernünftigen IDE - weder Thonny (für Python) noch Visual Studio Code sind nach Meinung des Autors mit einem grafischen Code-Generator wie der STMCubeIDE vergleichbar. Dass die Hardware-Zugriffs-API des Raspberry Pi Pico allerdings „einfach“ ausfallen, sei angemerkt - so kompakt bekommen Sie ein Blink-Programm unter Cube mit Sicherheit nicht hin:

1
#include "pico/stdlib.h"
2
3
int main() {
4
  const uint LED_PIN = 25;
5
  gpio_init(LED_PIN);
6
  gpio_set_dir(LED_PIN, GPIO_OUT);
7
  while (true) {
8
    gpio_put(LED_PIN, 1);
9
    sleep_ms(250);
10
    gpio_put(LED_PIN, 0);
11
    sleep_ms(250);
12
  }
13
}

Ein Lehrsystem!

Nach Meinung des Autors ist der RP2040 nicht als „produktiver“ Mikrocontroller für ein Nicht-Makersystem geeignet - zu viel Ärgernis steht zu wenig Vorteil gegenüber. Andererseits taugt das Gerät für oberflächliche Schulungen - die Möglichkeit, einen preiswerten Raspberry Pi sowohl als JTAG-Debugger als auch als Programmierumgebung zu nutzen, spart Materialkosten. Die dort gewonnenen Ergebnisse lassen sich dann auch auf STM32 und Co. Anwenden. Und ja, eine solide Ausbildung in Assembler auf einem PIC16F wäre vernünftiger - in der Zeit von TL:DR ist allerdings fraglich, ob die Aufmerksamkeitsspanne des durchschnittlichen Kadetten dafür noch ausreicht...


: Verschoben durch Admin
von Joachim B. (jar)


Lesenswert?

ich finde es unglücklich daß die 3,5mm Klinke weggefallen ist, daß kein 
normalen HDMI Buchsen verbaut wurden.
Immer wieder Adapterkabel, Kopfhörer an der Klinke nicht möglich, nicht 
mal AV an alte TV oder RF Modulator. Der hätte gut werden können. Selbst 
mit DVI Adapter bekommt man ohne Klinke keinen Ton in ältere Monitore.
Das hätte nicht sein müssen, entweder zu kurz gedacht oder schlicht 
vergessen?
An Schulen wurden viele ältere Monitore mit DVI abgegeben.

: Bearbeitet durch User
von Jack V. (jackv)


Lesenswert?

Mag mir jemand mit einfachen Worten erklären, inwiefern so eine 
Darstellung einer persönlichen Meinung einen Nachrichtenwert hat?

Zumal kein großes Geheimnis draus gemacht wurde, wer Zielgruppe ist, und 
wer nicht.


Joachim B. schrieb:
> ich finde es unglücklich daß die 3,5mm Klinke weggefallen ist, daß kein
> normalen HDMI Buchsen verbaut wurden.

Gibt es denn sonst irgendein Microcontrollerboard mit 
3,5mm-Klinkenanschluss und HDMI-Schnittstelle? Oder verwechselst du da 
was mit den „herkömmlichen“ Raspberry Pi, welche als SBC ausgelegt sind, 
und entsprechende Peripherie mitbringen?

: Bearbeitet durch User
von Thomas W. (goaty)


Lesenswert?

Der chip hat kein flash, das Raspberry Pi Pico board schon.

https://www.raspberrypi.org/documentation/rp2040/getting-started/

: Bearbeitet durch User
von Tam H. (Firma: Tamoggemon Holding k.s.) (tamhanna)


Lesenswert?

Thomas W. schrieb:
> Der chip hat kein flash, das Raspberry Pi Pico board schon.
>
> https://www.raspberrypi.org/documentation/rp2040/getting-started/

Hallo,
habe es klarer formuliert. Danke dir!

lg
Tam

von Tam H. (Firma: Tamoggemon Holding k.s.) (tamhanna)


Lesenswert?

Joachim B. schrieb:
> ich finde es unglücklich daß die 3,5mm Klinke weggefallen ist, daß kein
> normalen HDMI Buchsen verbaut wurden.
> Immer wieder Adapterkabel, Kopfhörer an der Klinke nicht möglich, nicht
> mal AV an alte TV oder RF Modulator. Der hätte gut werden können. Selbst
> mit DVI Adapter bekommt man ohne Klinke keinen Ton in ältere Monitore.
> Das hätte nicht sein müssen, entweder zu kurz gedacht oder schlicht
> vergessen?
> An Schulen wurden viele ältere Monitore mit DVI abgegeben.

Hallo Joachim,
Achtung - du verwechselst RPi Pico und den normalen RPi 4!

Der RPi Pico ist ein reines Mikrocontrollerboard!

lg aus Budapest
th

von Klaus R. (klausro)


Lesenswert?

Tam H. schrieb:
> Achtung - du verwechselst RPi Pico und den normalen RPi 4!

Ne, er verwechselt den RPi Pico mit dem RPi 400 (Tastatur-Pi). Dieser 
hat keine 3,5 mm Klinkenbuchse mehr. Der RPi4 hat eine.
Unabhängig davon hätte ich gerne Stereo Line In/Out OHNE Zusatzboard.
Aber hier hat sich die RPi Foundation wohl final dagegen entschieden...

von Jack V. (jackv)


Lesenswert?

Klaus R. schrieb:
> Unabhängig davon hätte ich gerne Stereo Line In/Out OHNE Zusatzboard.
> Aber hier hat sich die RPi Foundation wohl final dagegen entschieden...

Ich fände ein Stereo Line In/Out bei einem Microcontrollerboard eher 
befremdlich.

von Joachim B. (jar)


Lesenswert?

Tam H. schrieb:
> Hallo Joachim,
> Achtung - du verwechselst RPi Pico und den normalen RPi 4!

stimmt passiert mir immer wieder, wobei der PI400 gut für Schulen 
geeignet wäre und mir die Einschränkungen nicht erklärbar sind, lang 
genug ist er.

von Klaus R. (klausro)


Lesenswert?

Jack V. schrieb:
> Ich fände ein Stereo Line In/Out bei einem Microcontrollerboard eher
> befremdlich.

Ich bezog mich auf den "normalen" RPi, also den RPi4. Ich geben dir 
recht, beim RPi Pico fände ich Line In/Out auch unpassend. Bei potenten 
Cortex-M4 kann aber Line In/Out schon Sinn machen (DSP-Ersatz).

von Rudolf Schenke (Gast)


Lesenswert?

So eine gönnerhafte Kritik hebt sich doch deutlich von der Lobhudelei 
(und deren x-fachen Nachbeten) in den Technischen Medien ab.
Informationsgehalt für mich: Null.

von Tim  . (cpldcpu)


Lesenswert?

Soll das eine Glosse sein? Eine Polemik? Ein sehr aufwändiger 
Trollartikel?

Mir fällt da nun wirklich nichts mehr ein. Um einen neutralen Test 
handelt es sich offensichtlich nicht. Wenn es nur darum geht, die 
Meinung Kund zu tun, hätte man das auch mit weniger Aufwand machen 
können.

von Forist (Gast)


Lesenswert?

Klaus R. schrieb:
> Ich bezog mich auf den "normalen" RPi, also den RPi4.

Was hat der RaspPi4 mit diesem Thread zu tun?

von chris_ (Gast)


Lesenswert?

>Nach Meinung des Autors ist der RP2040 nicht als „produktiver“ >Mikrocontroller 
für ein Nicht-Makersystem geeignet - zu viel Ärgernis steht >zu wenig Vorteil 
gegenüber.

Ich wage mal eine Prognose: Genau wie der RaspberryPi als Makersystem 
zur einfachen Programmierung mit Python geschaffen wurde und dann 
millionenfach im Laufe der Zeit in allen möglichen Anwendungen gelandet 
ist, wird das mit dem RP2040 auch passieren.

Kann man mit einem der STM32 Derivate eigentlich so einen 125MSPs 
Wafeformgenerator basteln? (Mit Overclocking vielleicht 250MSPs)

Beitrag "Re: PiPico Micropython"

von Olaf (Gast)


Lesenswert?

> So eine gönnerhafte Kritik hebt sich doch deutlich von der Lobhudelei

Naja, wirkt etwas inkompetent auf mich.
Ein Beispiel: Prozessoren die ihre Daten in einem externem Flash haben 
sind
ab einer gewissen Leistungsklasse nicht ungewoehnlich. Ich kenne 
mindestens
zwei weitere: (von Ti und Renesas) Grund ist das Flash zu langsam ist 
und Cache wohl auch nicht immer so doll wenn man ueber 100Mhz mit 0Ws 
arbeiten will.

Die Kritik am fehlenden Coprozessor verstehe ich schon garnicht. In den 
meisten Faellen braucht man den gar nicht. Wenn man den in seltenen 
Faellen doch mal braucht dann eher double als float. Und dann reicht 
vielen Leute immer noch die Softwareemulation aus. In der Praxis also 
meistens unerheblich.

Das rumgenoele am Bootmanager den man nicht aendern kann ist geradezu 
absurd. Zum einen ist es quatsch, schliesslich geht es ja beim kauf und 
mehr Funktioanlitaet als seine Firmware reinzubekommen braucht man nicht 
und zum anderen, was glaubt ihr wie die anderen Hersteller das machen 
die ja auch von RS232 oder USB booten? Mit Zauberkraft? :-D

Meine Meinung zum RP2040:
Finde ich durchaus interessant. Dafuer zwei Gruende:

1. Das Konzept der programmierbaren GPIOs, erlaubt interessante neue 
Dinge wo es auf Geschwindigkeit ankommt.

2. Dualprozessorcores kommen nun in der breiten Masse an. Ich bin mal 
sehr gespannt welche Auswirkungen das auf Programmierung und Compiler 
hat. Ich hoffe jedenfalls das die Antwort darauf nicht Python (auspuck) 
ist. .-)

Bin mal gespannt wann der erste ZX-Spektrumemulator mit HDMI ausgang 
darauf laeuft. :-D

Olaf

von PittyJ (Gast)


Lesenswert?

Ich sehe die 'Fehler' nicht so kritisch.
Kein Flash? Haben die meisten FPGAs auch nicht, packt man eben so ein 
Teil dran. Auch die Arm-A Prozessoren haben meist externe Flashes. Und 
da läuft sogar ein Linux drauf.
25 mSec Startzeit. Stört mich jetzt nicht in meinen Projekten.
Can habe ich seit Jahren nicht mehr verwendet. Und nach Problemen mit 
DAC auf PWM-Basis nehmen ich lieber externe Chips über I2C. Da muss man 
nichts mehr glätten.

Ich sehe mehr, dass es eine stabile, einheitliche Platform werden kann, 
auf der viele Applikationen aufsetzen können.


Und zu STM: da habe ich gerade Application Note AN2606 offen, Bootloader 
ihrer Prozessoren. Und da gibt es 15 Serien von STM32 mit bis zu 40 
Unter-Modellen. Da blickt doch keiner mehr durch.

von yakman (Gast)


Lesenswert?

Ich seh das nicht so eng.

Für jeden Controller gibt es einen Einsatzbereich, und es wird 
Anwendungen geben, wo das da passt.
Im Professionellem Umfeld fliegt der sowieso heraus, wenn Dokumentation 
und technische Werte der üblichen Raspberry-PI-Qualität entspricht 
(Maker"qualität").

Ob er für Bastler gegen einen Arduinu duchsetzen kann oder parallel 
existieren kann wird man sehen.
Es ist außerdem Version 1.0. Falls das halbwegs erfolgreich wird, wird 
man vermutlich bald eine Version mit Flash sehen.

Eine Option mehr sehe ich nicht als Schaden an, sondern als 
Bereicherung.

von A. S. (Gast)


Lesenswert?

Der Autor schreibt mit anderen Worten dass der Pico für Maker, zum 
lernen und lehren und für Einzelprojekte gut geeignet und dokumentiert 
ist.

Ergänzt um ein paar Erfahrungen, und dem Rat, vorerst nicht auf den 
reinen Chip zu hoffen und Kinderkrankheiten nicht auszuschließen.

Ja, mich würde auch interessieren, warum der Autor das jetzt um Stil 
eines Zeitschriftenartikels schreibt. Vielleicht als Übung. War ganz ok 
so, passt, schicke ab und nächsten.

von Soso, sagt ein (Gast)


Lesenswert?

Zitat Wikipedia:

"Die Raspberry Pi Foundation hat sich zum Ziel gesetzt, das Studium der 
Informatik und verwandter Themen zu fördern, besonders an Schulen."

Warum sollten sie sich um Details für einen Einsatzbereich kümmern, den 
sie nicht abdecken wollen?

von Mensch (Gast)


Lesenswert?

Hallo

Tam H. schrieb:
> Und ja, eine solide Ausbildung in Assembler auf einem PIC16F wäre
> vernünftiger - in der Zeit von TL:DR ist allerdings fraglich, ob die
> Aufmerksamkeitsspanne des durchschnittlichen Kadetten dafür noch
> ausreicht...

Und du bist natürlich einer der überdurchschnittlicher Kadetten - nein 
natürlich bist du ein heraurragender General um bei der Militärsprache 
zu bleiben...
Deine Meinung (und nicht mehr aber auch nicht weniger ist es) zum 
technischen Teil in allen Ehren - aber dieses überhebliche herabwürdigen 
von der Masse der Lernwilligen (zum lernen gezwungenen) ist eine 
absolute leider aber auch Forenübliche  Frechheit - trauig das sich all 
die anderen auch nur wegeen der technischen Details zu Wort melden.
Resekt vor andern ist in technischen Umfeld wohl tatsächlich Mangelware 
(?!)- da schämt man sich schon wieder fast einen Handwerklichen Beruf im 
E-Technischen Umfeld aktiv auszuüben und privat tiefgehendes Interesse 
an eben den Themen zu haben um den es in diesen Forum geht...

Mensch

von Johannes S. (Gast)


Lesenswert?

Hat ST jetzt Angst um die Weltherrschaft durch einen kleinen Pico?
Erst die Werbung für den U5 und jetzt das Konkurrenz bashing, das ist ja 
wohl nicht nötig.

von Baendiger (Gast)


Lesenswert?

Soso, sagt ein schrieb:
> Warum sollten sie sich um Details für einen Einsatzbereich kümmern, den
> sie nicht abdecken wollen?

Ich Frage mich, ob der Controller wirklich nicht im professionellen 
Bereich eingesetzt werden soll. Das Raspberry Pi Compute Module hat auch 
professionelle Nutzer als Ziel. Es scheint mir schon unwahrscheinlich, 
dass das auch für später nie vorgesehen ist.

Aktuell werden sie nur alle verfügbaren Chips in die Evalboards stecken, 
um den Controller so schnell wie möglich zu verbreiten. Andererseits 
Frage ich mich dann, warum nicht wenigstens Preise für lose Controller 
verfügbar sind.

von Olaf (Gast)


Lesenswert?

> Ich Frage mich, ob der Controller wirklich nicht im professionellen
> Bereich eingesetzt werden soll.

Naja, da zaehlt vor allem der Einkaufspreis. Und damit meine ich nicht 
das
was ein Teil bei Reichelt kostet. .-)

> Das Raspberry Pi Compute Module hat auch
> professionelle Nutzer als Ziel.

Kann man schwer vergleichen. Im professionellen Bereich wird niemand auf 
die Idee kommen ein Modul einzusetzen weil das viel zu teuer ist. 
Alleine nur die Steckverbinder sind ja teurer wie ein Microcontroller.

Sowas nutzt man eher in der Automatisierungstechnik wo man vielleicht 
auf 1000Geraete im Jahr kommt. Da wuerde es sich niemals lohnen einen 
Linuxrechner zu entwickeln. Aber Mikrocontroller wie einen RP2040 setzt 
man auch da direkt auf ein PCB. Und dann kommt auch da schnell die Frage 
auf was ein Reel kostet.

Das Teil ist IMHO schon eher fuer Bastler, also Modul sowieso. Aber ist 
ja auch okay so.

Olaf

von Peter D. (peda)


Lesenswert?

Ich verstehe das Pico-Bashing nicht.
Preislich ist der doch o.k. und das man keine Platine anfertigen muß, 
ist auch ganz nett.
Das mit dem Bootloader macht man absichtlich so, damit man sich nicht 
versehentlich aussperren kann. Wem das nicht gefällt, der kann doch den 
Default-Bootloader seinen eigenen Custom-Bootloader starten lassen.
Das mit dem ADC sollte man mal überprüfen. Vielleicht ist nur ein 
Buskeeper aktiviert. In der Regel kann man bei Analogeingängen den 
Digitaleingang komplett abschalten.

Tam H. schrieb:
> Und ja, eine solide Ausbildung in Assembler auf einem PIC16F wäre
> vernünftiger

Prust. Sone alte Möhre mit Hardware-Stack, Code-Paging und RAM-Banking, 
echt jetzt?
Möchte nicht wissen, wieviel Generationen schon das PCLATH und RETLW 
verflucht haben, weil verschobener Code plötzlich rumspinnt. Oder nach 
nem Call/Jump die falsche RAM-Bank ausgewählt ist.

von Voyager 2 (Gast)


Lesenswert?

Wenn man Audio mit Klinke braucht, kann man doch sicher ein i2s breakout 
für paar Euro fuffzig rantüteln.
Oder geht das mit dem nicht?

von Uwe D. (monkye)


Lesenswert?

Tam H. schrieb:
> *von Tam Hanna*
> Eine am 21. Januar bei RS Electronics getätigte Bestellung wurde immer
> noch nicht ausgeliefert – der von der Foundation traditionell bevorzugte
> Ameisenhandel (Rasppishop) hatte Restposten.

Da hast Du den falschen Lieferanten gewählt.

> Dass einige andere Peripheriestandards - Stichwort beispielsweise ein
> CAN-Controller - fehlen, kann in Zukunft für Rewrites der Codebasis
> sorgen, wenn am Ende doch ein Umstieg auf ein anderes System notwendig
> wird.
Aha, das bedeutet jetzt genau was? Ist das bei anderen Prozessoren nicht 
so?

> Immerhin ist der RP2040 nicht allzu langsam - ein kleiner Test des
> Autors mit einem in C gehaltenen Blinkprogramm ergab eine
> Start-Verzögerung von rund 25ms (siehe Abbildung).

Wer legt denn fest, was "schnell" oder langsam ist?

> Auf der Soll-Seite steht in diesem Bereich allerdings das Fehlen einer
> vernünftigen IDE - weder Thonny (für Python) noch Visual Studio Code
> sind nach Meinung des Autors mit einem grafischen Code-Generator wie der
> STMCubeIDE vergleichbar.

Ist das "STMCubeIDE" das Beste, der Maßstab? Nimm's mir nicht übel, 
aber so richtig ernstnehmen kann ich das nicht...

> Und ja, eine solide Ausbildung in Assembler auf einem PIC16F wäre
> vernünftiger - in der Zeit von TL:DR ist allerdings fraglich, ob die
> Aufmerksamkeitsspanne des durchschnittlichen Kadetten dafür noch
> ausreicht...

Und beim "STMCubeIDE" zusammen mit STM32 und Co. genügen 15 bebilderte 
Anleitung?

von Frank (Gast)


Lesenswert?

Tam H. schrieb:
> dass das Sichern des hauseigenen geistigen Eigentums wesentlich
> schwieriger wird

Das ist sowieso nie eine gute Idee, weil es Reparaturen unmöglich macht, 
wenn eure Firma irgendwann pleite ist.

von Stefan F. (Gast)


Lesenswert?

Tam H. schrieb:
> warum Sie den Controller nicht in einem kommerziellen Produkt verwenden
> sollten.

Nach meinem Kenntnisstand ist die gesamte Produktpalette der Raspberry 
Pi Foundation ausdrücklich nur für Lehrzwecke und Hobby vorgesehen.

> weder Thonny (für Python) noch Visual Studio Code sind ...
> mit einem grafischen Code-Generator wie der STMCubeIDE vergleichbar.

Das ist auch gut so. Was ST uns da zumutet zaubert mir kein fröhliches 
Lächeln ins Gesicht.

von Stefan F. (Gast)


Lesenswert?

A. S. schrieb:
> Ja, mich würde auch interessieren, warum der Autor das jetzt um Stil
> eines Zeitschriftenartikels schreibt.

Vielleicht war das ursprünglich tatsächlich als Zeitschriftenartikel 
vorgesehen, wurde aber (warum auch immer) doch nicht dort 
veröffentlicht.

von Maxe (Gast)


Lesenswert?

Peter D. schrieb:
> Ich verstehe das Pico-Bashing nicht.

Er wird halt ziemlich gehypt, das verursacht auch Gegenstimmen. Mir 
scheint er auch nicht so interessant, aber wenn er erfolgreich wird, 
schadet das sicher keinem.

von Olaf (Gast)


Lesenswert?

> Er wird halt ziemlich gehypt, das verursacht auch Gegenstimmen.

Naja, ich hab auch erst gedacht, Oh Gott was soll der scheiss, jetzt
macht der Laden auch noch Microcontroller. Das ist ja als wenn Amazon
ausser Buecher auch noch was anderes verkaufen wuerde. :)

Aber wenn man sich das Teil mal vorurteilsfrei anschaut dann finde ich
das aus den oben bereits angefuehrten Gruenden schon interessant.

Das hier schon etwas neues:

https://hackaday.com/2021/02/12/bitbanged-dvi-on-a-raspberry-pi-rp2040-microcontroller/

Bedenke das bis gestern die Leute immer noch Video oder VGA Ausgaenge an 
ihre Mikrocontroller basteln mussten wenn sie einen Monitor anschliessen 
wollten obwohl diese Schnittstellen lange Geschichte sind.
Und ich finde das auch interessant fuer andere Schnittstellen die man 
ueblicherweise nicht in der Hardware findet wie z.B 1-wire oder 
Neopixel. Da musste man sich bisher immer einen fuer abbrechen. Man 
koennte vielleicht auch ein dummes LCD anschliessen das nur 
Zeilen/Spaltentreiber hat. Also z.b das Panel aus einem Notebook.

Olaf

von Martin (Gast)


Lesenswert?

Maxe schrieb:

> Er wird halt ziemlich gehypt, das verursacht auch Gegenstimmen. Mir
> scheint er auch nicht so interessant, aber wenn er erfolgreich wird,
> schadet das sicher keinem.

Das ist eher ein deutsches Ding. Der Deutsche ist voll bis oben hin mit 
Neid. Der gönnt anderen nichts.

von Tam H. (Firma: Tamoggemon Holding k.s.) (tamhanna)


Lesenswert?

Martin schrieb:
> Maxe schrieb:
>
>> Er wird halt ziemlich gehypt, das verursacht auch Gegenstimmen. Mir
>> scheint er auch nicht so interessant, aber wenn er erfolgreich wird,
>> schadet das sicher keinem.
>
> Das ist eher ein deutsches Ding. Der Deutsche ist voll bis oben hin mit
> Neid. Der gönnt anderen nichts.

Nein. Ich habe die Produkte früher selbst verwendet, zum Beispiel als 
Backend für TouchCalc for Firefox OS. Und bin wenig begeistert von.

Der OrangePi bietet ums gleiche Geld z.b. viel mehr Leistung. Und 
Garantie - der eevblog war ja lange Zeit voll von "halbtoten" RPis, die 
TopLoser dort zu Ehren von Farnell verkaufte...

von Tam H. (Firma: Tamoggemon Holding k.s.) (tamhanna)


Lesenswert?

Johannes S. schrieb:
> Hat ST jetzt Angst um die Weltherrschaft durch einen kleinen Pico?
> Erst die Werbung für den U5 und jetzt das Konkurrenz bashing, das ist ja
> wohl nicht nötig.

Hallo,
leider nein. Ich bekomme von SGS nichts. Kein Geld, kein Essen, keine 
Gratischips. Wenn du willst, lege ich dir gerne meine Konten offen.

Nenne mir einen Termin in Budapest und ich lasse dich in die 
E-Banking-Systeme rein. Kein Scherz.

von Tam H. (Firma: Tamoggemon Holding k.s.) (tamhanna)


Lesenswert?

Mensch schrieb:
> Resekt vor andern ist in technischen Umfeld wohl tatsächlich Mangelware
> (?!)- da schämt man sich schon wieder fast einen Handwerklichen Beruf im
> E-Technischen Umfeld aktiv auszuüben und privat tiefgehendes Interesse
> an eben den Themen zu haben um den es in diesen Forum geht...
>
> Mensch

Ich war vor vielen Jahren an einer HTL in Österreich und sah, was dort 
damals rumlief. Und Heute ist es nicht besser...consulte immer wieder 
bei diversen Privatmilizen, und die beklagen sich genauso.

Wenn du dich hier einloggst und irgendeine Meldung liest und 
kommentierst, bist du in einer Elite von, gefühlt, 0.1% der Techniker. 
99.9% surfen in ihrer Freizeit auf "lustigen" Seiten mit Fussball oder 
leicht bekleidetem Entertainment...und das betrifft explizit auch die 
PhDRs, Profs, Dr. Ings und alle anderen "nicht handwerklichen"

Und ja, das muss man sagen dürfen. In China sagen sie es laut und 
deutlich, und schau dir an wie deren Industrie wächst...

von Tam H. (Firma: Tamoggemon Holding k.s.) (tamhanna)


Lesenswert?

Olaf schrieb:
>> So eine gönnerhafte Kritik hebt sich doch deutlich von der Lobhudelei
>
> 2. Dualprozessorcores kommen nun in der breiten Masse an. Ich bin mal
> sehr gespannt welche Auswirkungen das auf Programmierung und Compiler
> hat. Ich hoffe jedenfalls das die Antwort darauf nicht Python (auspuck)
> ist. .-)
>
> Bin mal gespannt wann der erste ZX-Spektrumemulator mit HDMI ausgang
> darauf laeuft. :-D
>
> Olaf

Chip Gracey's Leute hatten mit ihrem Propeller so was ähnliches schon 
ewig - natürlich in kleinerem Rahmen, aber trotzdem. AFAIK gibt es sogar 
mehrkernige PADAUKs (!!!)...auch hier sehe ich also nicht so sehr den 
"first effect".

von Alex D. (daum)


Lesenswert?

Tam H. schrieb:
> Chip Gracey's Leute hatten mit ihrem Propeller so was ähnliches schon
> ewig - natürlich in kleinerem Rahmen, aber trotzdem. AFAIK gibt es sogar
> mehrkernige PADAUKs (!!!)...auch hier sehe ich also nicht so sehr den
> "first effect".

Der Propeller ist eine interessante Architektur, aber ich würde diesen 
nicht mit einem RP2040 vergleichen. Das Programmiermodell des Propellers 
(insb. v1) ist ja, dass ein Kern ein Peripheriegerät darstellen kann und 
andere Kerne rechnen.
Für die Abbildung von Peripherie gibt es beim RP2040 Hardware + die 
PIOs, die aber etwas limitierter sind als ein Propeller Core.

Und einen PADAUK µC mit dem RP2040 zu vergleichen macht auch nicht 
wirklich Sinn, das sind 2 komplett verschiedene Preis und 
Leistungsklassen.

Aber dass Multicore nicht wirklich neu ist im µC Markt stimmt schon, im 
ARM Bereich sind das meist M4 + M0 oder M7 + M4.

von Uwe D. (monkye)


Lesenswert?

Tam H. schrieb:
> Martin schrieb:
>> Maxe schrieb:
>>
>>> Er wird halt ziemlich gehypt, das verursacht auch Gegenstimmen. Mir
>>> scheint er auch nicht so interessant, aber wenn er erfolgreich wird,
>>> schadet das sicher keinem.
> Der OrangePi bietet ums gleiche Geld z.b. viel mehr Leistung. Und
> Garantie - der eevblog war ja lange Zeit voll von "halbtoten" RPis, die
> TopLoser dort zu Ehren von Farnell verkaufte...

Der OrangePi hat ja auch so eine tolle Software Unterstützung. Wo kann 
er denn seine Leistung entfalten - "viel mehr Leistung": Werde doch mal 
konkret.

von Tam H. (Firma: Tamoggemon Holding k.s.) (tamhanna)


Lesenswert?

Alex D. schrieb:
> Tam H. schrieb:
>> Chip Gracey's Leute hatten mit ihrem Propeller so was ähnliches schon
>> ewig - natürlich in kleinerem Rahmen, aber trotzdem. AFAIK gibt es sogar
>> mehrkernige PADAUKs (!!!)...auch hier sehe ich also nicht so sehr den
>> "first effect".
>
> Der Propeller ist eine interessante Architektur, aber ich würde diesen
> nicht mit einem RP2040 vergleichen. Das Programmiermodell des Propellers
> (insb. v1) ist ja, dass ein Kern ein Peripheriegerät darstellen kann und
> andere Kerne rechnen.
> Für die Abbildung von Peripherie gibt es beim RP2040 Hardware + die
> PIOs, die aber etwas limitierter sind als ein Propeller Core.
>
> Und einen PADAUK µC mit dem RP2040 zu vergleichen macht auch nicht
> wirklich Sinn, das sind 2 komplett verschiedene Preis und
> Leistungsklassen.
>
> Aber dass Multicore nicht wirklich neu ist im µC Markt stimmt schon, im
> ARM Bereich sind das meist M4 + M0 oder M7 + M4.

Hallo,
erstmal danke für deine Antwort!

Ja, das stimmt natürlich - der RP2040 ist in dem Bereich schon eine 
Neuerung, mit zwei identischen Cores.

Aber, die Idee ist per se nicht neu. Und meine Frage ist, ob "Schlomo 
Normalprogrammierer" damit zurecht kommt und nicht bald die 
MicroPython-Foren mit Fragen zu Race Conditions bombardiert.

von Olaf (Gast)


Lesenswert?

> Aber dass Multicore nicht wirklich neu ist im µC Markt stimmt schon, im
> ARM Bereich sind das meist M4 + M0 oder M7 + M4.

Ich hab ja auch nicht gesagt das dies neu ist, ich entwickel selber 
gerade was auf einem Tricore. Aber bisher waren das ja eher spezielle 
Controller fuer bestimmte Anwendungen. Jetzt kommt ein Dualcore beim 
Otto Normalbastler an. Das ist schon ein Unterschied. Bisher haben halt 
eine Hand voll Spezialisten sowas in Firmen genutzt, bald werden sich 
10000Maker fragen, hey ich hab ja zwei CPUs da drin, was mach ich 
eigentlich mit der zweiten? Ich bin mal gespannt was draus wird.

Olaf

von Uwe D. (monkye)


Lesenswert?

Tam H. schrieb:
> Alex D. schrieb:
>> Tam H. schrieb:
>>> Chip Gracey's Leute hatten mit ihrem Propeller so was ähnliches schon
>>> ewig - natürlich in kleinerem Rahmen, aber trotzdem. AFAIK gibt es sogar
>>> mehrkernige PADAUKs (!!!)...auch hier sehe ich also nicht so sehr den
>>> "first effect".
>> Aber dass Multicore nicht wirklich neu ist im µC Markt stimmt schon, im
>> ARM Bereich sind das meist M4 + M0 oder M7 + M4.
> Aber, die Idee ist per se nicht neu. Und meine Frage ist, ob "Schlomo
> Normalprogrammierer" damit zurecht kommt und nicht bald die
> MicroPython-Foren mit Fragen zu Race Conditions bombardiert.

Nicht wirklich neu: Das stimmt, hat ja auch keiner behauptet. Nur 
verstehe ich immer noch nicht, warum Du den RP2040 platt redest.
Wieviel mehr an Otto-Normalprogrammierern kommen denn mit dem 
Padauk-oder M4+M0 Multicore zurecht?

Das Teil kostet überschaubar wenig und jeder Bastler kann sofort 
loslegen. Und was er dabei lernt - z.B. mit der PIO oder dem Dual-Core - 
bringt ihn voran.
Die riesige Community wird ein Turbo sein.

Und Niemand hindert Dich noch Andere, die viel bessere Hardware anderer 
Hersteller zu verwenden. Von mir aus auch einen OrangePi...

von Stefan F. (Gast)


Lesenswert?

Dual Core kennen viele Bastler seit dem ESP32, und das ist auch 
sonnenklar, wozu das gut ist. Zumindest wenn man vorher mit dem ESP8266 
auskommen musste.

von Dieter D. (Firma: Hobbytheoretiker) (dieter_1234)


Lesenswert?

Tam H. schrieb:

> im Moment ist der Microcontroller im freien Markt
> noch nicht als Standalone-Chip verfügbar.

Die bestückten Platinen sind so günstig, da kann sich der 
professsionelle Bereich auch etwas auf das Lager legen.

Der Pico ist mehr als Meß- und Steuerknecht konzipiert. Daher kein DAC, 
weil geringe Prio. Aber dafür gibt es eine althergebrachte Lösung mit 
den Digitalausgängen. Abwarten und Teetrinken.

> CAN-Controller - fehlen,

Es wäre genug Speicher und I/O-Ausgänge da, um zweckentfremdet mit CAN 
zu kommunizieren, wenn man wollte oder einem anderen Protokoll.

> bringt einen externen Flashchip mit.

Den kann man wenigstens austauschen, wenn dieser kaputt geflasht wurde.

> Andererseits sitzt der Bootloader - laut Datenblatt - in einer
> „nicht veränderlichen“ Speicherzone,

Es gibt sogar Sicherheitsvorgaben, da soll das erst recht nicht mehr 
veränderlich sein, trotz vielleicht später gefundener Fehler.

> Start-Verzögerung von rund 25ms (siehe Abbildung).

Unterschiedliche Startverzögerung sind nichts ungewöhnliches. Wer keine 
Ahnung hat, wie Compiler (und Interpreter) das Programm letzendlich in 
Maschinencode umsetzt, den wundert das natürlich.
Durfte mittlerweile feststelle, das Elektroingenieure der Energietechnik 
zur Zeit des Diploms hierüber mehr im Studium lernen durften, eher 
mussten, als heutige Informatiker mit Uni-Master-Abschluss.

> Zustandsautomat, der - etwas fortgeschrittener als Microchips
> Configurable Logic Cell - die Erzeugung von „zusätzlicher Intelligenz“
> in der GPIO-Engine erlaubt.

Genau das ist für den sparsamen Steuerknecht.

> ### Exzellente Dokumentation.

Und um sich da nicht zu verzetteln wird nur ein einziger Microcontroller 
ins Rennen geschickt.

> Dass die Hardware-Zugriffs-API des Raspberry Pi Pico allerdings
> „einfach“ ausfallen, sei angemerkt -

Für die Aufgaben als Knecht, soll das auch einfach sein und gegenseitige 
Kontrolle auch ermöglichen.
Eine IDE der anderen professionellen System ist auch erst gewachsen. Da 
lag der TO des Artikels noch in den Windeln.

> ### Ein Lehrsystem!

Das ist die geplante Hauptanwendung. Lehrsystem für den Einstieg.

> als „produktiver“ Mikrocontroller für ein Nicht-Makersystem ...

Sehe ich durchaus möglich für produktive Aufgaben (stellt dabei das 
Zweit- oder Drittsystem), wobei beim Pico mehr der Dual-Use für Lernen 
anvisiert wurde.

> Pi sowohl als JTAG-Debugger als auch als Programmierumgebung zu nutzen,
> spart Materialkosten.

Das stellt für die meisten nutzungswilligen Anfängern bei Profi-Systemen 
ein Handycap dar.

> Die dort gewonnenen Ergebnisse lassen sich dann
> auch auf STM32 und Co. Anwenden.

> Und ja, eine solide Ausbildung in Assembler auf einem PIC16F wäre
> vernünftiger - in der Zeit von TL:DR ist allerdings fraglich, ob die

Eine solide Ausbildung in Assembler wäre beim Pico auch möglich. Es 
müssen sich nur genügend Personen zusammenfinden, die das beginnen und 
interessante Anwendungen damit realisieren.

von Tam H. (Firma: Tamoggemon Holding k.s.) (tamhanna)


Lesenswert?

Zu Allererst danke euch allen für die vielen, vielen Kommentare. Es 
freut mich, hier zu einer kontroversiellen Diskussion beigetragen zu 
haben - leider wäre es mir real bei Zigarren im Labor lieber.
Aber, hier einige Antworten:

Dieter D. schrieb:
> Tam H. schrieb:
>
>> im Moment ist der Microcontroller im freien Markt
>> noch nicht als Standalone-Chip verfügbar.
>
> Die bestückten Platinen sind so günstig, da kann sich der
> professsionelle Bereich auch etwas auf das Lager legen.

Ja schon, aber die Platine ist vergleichsweise groß.

>> bringt einen externen Flashchip mit.
>
> Den kann man wenigstens austauschen, wenn dieser kaputt geflasht wurde.

Macht es aber auch Angreifern leichter.

>> Start-Verzögerung von rund 25ms (siehe Abbildung).
>
> Unterschiedliche Startverzögerung sind nichts ungewöhnliches. Wer keine
> Ahnung hat, wie Compiler (und Interpreter) das Programm letzendlich in
> Maschinencode umsetzt, den wundert das natürlich.
> Durfte mittlerweile feststelle, das Elektroingenieure der Energietechnik
> zur Zeit des Diploms hierüber mehr im Studium lernen durften, eher
> mussten, als heutige Informatiker mit Uni-Master-Abschluss.

Ich meinte rund auf die Messung bezogen. Bootloader allein braucht 25ms, 
MicroPython 145.


>> Die dort gewonnenen Ergebnisse lassen sich dann
>> auch auf STM32 und Co. Anwenden.
>
>> Und ja, eine solide Ausbildung in Assembler auf einem PIC16F wäre
>> vernünftiger - in der Zeit von TL:DR ist allerdings fraglich, ob die
>
> Eine solide Ausbildung in Assembler wäre beim Pico auch möglich. Es
> müssen sich nur genügend Personen zusammenfinden, die das beginnen und
> interessante Anwendungen damit realisieren.

Ja, aber die Architektur ist wesentlich komplizierter. Ich habe hier 
auch das RISC-V Reference Manual und diverse Bücher zu ARM 
Assembly...aber alle auf der "Irgendwann Lesen"-Liste. Den PIC16 kannst 
du hingegen auf einer Mittelstrecke komplett durchdenken...

von Olaf (Gast)


Lesenswert?

> Die bestückten Platinen sind so günstig, da kann sich der
> professsionelle Bereich auch etwas auf das Lager legen.

Ja klar, etwa 5x so teuer wie ein vergleichbarer Mikrocontroller
in Stueckzahlen allein kostet.

> Unterschiedliche Startverzögerung sind nichts ungewöhnliches. Wer keine
> Ahnung hat, wie Compiler (und Interpreter) das Programm letzendlich in
> Maschinencode umsetzt, den wundert das natürlich.

Tut mir leid das so sagen zu muessen, aber deine Einschaetzung ist 
Bullshit.
Die Ladezeiten bei externen Flash im vergleich zu einem normalen 
Microcontroller sind schon vorhanden. Sicherlich oft beherrschbar, aber 
man sollte sich dessen bewusst sein. Bei einem normalen Mikrocontroller 
wird man in us nach dem Reset Portausgaenge initialisiert haben bevor 
dann ein System hochfaehrt. Hier kann das alles erstmal lange rumwackeln 
wenn man darauf nicht achtet! Und es wird Anwendungen geben wo sowas 
nicht brauchbar ist. Ich kenne z.B Anwendungen wo Mikrocontroller nur 
fuer 10ms eingeschaltet werden um jedes einzelne Microampere zu sparen. 
Wenn so ein Controller dann erstmal 25ms bootzeit braucht verdreifacht 
er die Stromaufnahme der Schaltung. Aber klar, fuer Maker mit blinkender 
LED ist das irrelevant.

Olaf

von Stefan F. (Gast)


Lesenswert?

In Zeiten wo Fernseher wieder so langsam starten wie damals Röhrenradios 
frage ich mich schon, wo genau man Mikrocontroller braucht, bei denen es 
auf Millisekunden Startzeit ankommt.

Sicher gibt es Fälle wo das relevant ist, aber das bleiben Sonderfälle.

von Dieter D. (Firma: Hobbytheoretiker) (dieter_1234)


Lesenswert?

Olaf schrieb:
> a klar, etwa 5x so teuer wie ein vergleichbarer Mikrocontroller
> in Stueckzahlen allein kostet.

60x günstiger, als wenn ein Techniker so einen µC auf der Platine 
wechselt.

Olaf schrieb:
> Tut mir leid das so sagen zu muessen, aber deine Einschaetzung ist ...
... auch nicht besser. Im Anschluss finden sich bei Dir aber auch die 
Punkte, was vielleicht nicht so aufgenommen wurde.

Olaf schrieb:
> Die Ladezeiten bei externen Flash im vergleich zu einem normalen
> Microcontroller sind schon vorhanden. ...

Grund dafür ist wie der Compiler das in Maschinencode umsetzt. Die 
Initialisierung ist bei den Programmiersprachen unterschiedlich 
ausgeführt und ergibt stark unterschiedliche Zeiten. Da gibt es noch 
keine Anpassung für den µC. Da muss man warten, bis Jemand eine optimale 
Routine in Assembler geschrieben hat, die die Compiler irgendwann 
verwenden werden.

Olaf schrieb:
> Ich kenne z.B Anwendungen wo Mikrocontroller nur
> fuer 10ms eingeschaltet werden um jedes einzelne Microampere zu sparen.

Kenne ich auch. Solchen Systeme haben gerade auch deshalb so wenig RAM 
und Flash dabei. Für diese speziellen Anwendungen mit so wenigen 
Rechenzeitzyklen wurde der Baustein aber nicht entworfen und optimiert.

: Bearbeitet durch User
von Peter D. (peda)


Lesenswert?

Olaf schrieb:
> Ich kenne z.B Anwendungen wo Mikrocontroller nur
> fuer 10ms eingeschaltet werden um jedes einzelne Microampere zu sparen.

Da bietet sich der Power-Down Mode an, da schaffen viele MCs <1µA.
Das Aufwachen per Interrupt dauert nur wenige CPU-Takte.
Wird allerdings ein Quarz benötigt, braucht das typisch >10ms zum 
Anschwingen.

von Olaf (Gast)


Lesenswert?

> Da bietet sich der Power-Down Mode an, da schaffen viele MCs <1µA.

Aus solche Einwaende hab ich gewartet. :-D
Glaub mir es gibt Gruende warum soetwas nicht geht oder sinnvoll ist.

Olaf

von Stefan F. (Gast)


Lesenswert?

Olaf schrieb:
> Glaub mir es gibt Gruende warum soetwas nicht geht oder sinnvoll ist.

Es gibt auch gründe, warum ein Kofferaum mit 300 Liter zu klein ist oder 
eine Beschleunigung von 0->100 in 8 Sekunden unzureichend ist.

Deswegen fordere ich jetzt aber nicht (wie Tam) dass Autos beide 
Kriterien erfüllen sollen, damit sie für kommerzielle Nutzung taugen. 
Vor allem würde ich diese Forderungen nicht bei einem Kleinstwagen* der 
untersten Preisgruppe stellen.

*= ich hätte beinahe schon "Seifenkiste aus dem Spielwarenladen" 
geschrieben.

von Jack V. (jackv)


Lesenswert?

Olaf schrieb:
> Glaub mir es gibt Gruende warum soetwas nicht geht oder sinnvoll ist.

Keiner hat gesagt, dass der RP2040 oder gar das ganze Picoboard in jedem 
Fall sinnvoll eingesetzt werden, oder andere Sachen ersetzen könne – das 
war nicht mal Designziel, und dafür ist das Ding schon ziemlich 
vielseitig.

Die zentrale Behauptung dieses Threads ist im Threadtitel zu lesen: das 
Ding wäre nur als Schulungssystem einsetzbar, und das auch nur 
oberflächlich, wie im Einangsbeitrag, von jemandem mit zuviel Humor als 
„News“ aufgemacht und geflaggt, konkretisiert wird. Und das ist nunmal 
Kuhkot.

: Bearbeitet durch User
von Joachim (Gast)


Lesenswert?

Olaf schrieb:

> Glaub mir es gibt Gruende warum soetwas nicht geht oder sinnvoll ist.

Es wäre nett, wenn du drei oder vier Gründe nennen würdest.

von Stefan (Gast)


Lesenswert?

Tam H. schrieb:
> Ärgerlicherweise zieht der ADC erhebliche Eingangsströme. Beim Betrieb
> einer Multimeter-Testschaltung mit MicroPython floss permanent ein Strom
> von 0,04 mA

Das scheint mir eher an MicroPython zu liegen als am Controller.

In diesem Thread im MicroPython-Forum wird dazu geraten, den zum ADC 
gehörenden Pin als Eingang zu konfigurieren: 
https://forum.micropython.org/viewtopic.php?f=21&t=9959
Dort steht auch wie man man in Micropython die Pad Configuration 
Register auslesen und verändern kann.

Für Tests habe ich ADC0/GPIO26 an die Mitte eines Spannungsteiles aus 
zwei 30k Widerständen zwischen GND und den 3,3V des Spannungsreglers 
angeschlossen. Es macht einen deutlichen Unterschied ob man den ADC über 
die ADC-Nr.(0) oder über die GPIO-Pin-Nr.(26) anspricht. Nur wenn man 
die GPIO-Pin-Nr. nutzt wird Bit 2 im Pad Configuration Register 
zurückgesetzt und so der Pull-Down deaktiviert.

Ein kurzes Testscript:
1
from machine import Pin, ADC, reset
2
from time import sleep
3
4
@micropython.asm_thumb
5
def regPeek(r0): # Address
6
    mov(r1,r0)
7
    ldr(r0,[r1,0])
8
9
rGPIO26 = 0x4001c06c #Pad control register GPIO26
10
print("rGPIO26:",hex(regPeek(rGPIO26)), "{0:b}".format(regPeek(rGPIO26)), "\n")
11
12
13
adc = ADC(0)        
14
print("ADC(0):", adc.read_u16()>>4)
15
print("rGPIO26:",hex(regPeek(rGPIO26)), "{0:b}".format(regPeek(rGPIO26)), "\n")
16
17
adc = ADC(26)
18
print("ADC(26):", adc.read_u16()>>4)
19
print("rGPIO26:",hex(regPeek(rGPIO26)), "{0:b}".format(regPeek(rGPIO26))) 
20
21
22
sleep(1)
23
reset()

Die Ausgabe dazu:
1
MicroPython v1.14 on 2021-02-05; Raspberry Pi Pico with RP2040
2
3
Type "help()" for more information.
4
>>> %Run -c $EDITOR_CONTENT
5
rGPIO26: 0x16 10110 
6
7
ADC(0): 1285
8
rGPIO26: 0x16 10110 
9
10
ADC(26): 2016
11
rGPIO26: 0x12 10010
12
13
Connection lost (EOF)
14
15
Use Stop/Restart to reconnect.

Bitte 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
Noch kein Account? Hier anmelden.