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
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
intmain(){
4
constuintLED_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...
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.
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?
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
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...
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.
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.
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).
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.
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.
>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"
> 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
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.
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.
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.
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?
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
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.
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.
> 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
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.
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?
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.
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.
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.
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.
> 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
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.
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...
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.
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...
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".
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.
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.
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.
> 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
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...
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.
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.
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...
> 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
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.
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.
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.
> 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
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.
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.
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:
Weil das Oszilloskop schon da ist: Eine kleine Startzeit-Messung
MicroPython verlangsamt den Start zusätzlich
Thread beobachten
Seitenaufteilung abschalten