Der Raspberry Pi Pico ist ein Breakout-Board für einen von der Raspberry Pi Foundation selbst entwickelten Dual-Core ARM Cortex-M0+ Mikrocontroller, den RP2040. Außer dem Namen hat er damit nicht mehr allzu viel mit anderen Raspberry Pi-Varianten zu tun: der Cortex M0+ ist ein klassischer Mikrocontroller-Kern, auf dem im Gegensatz zu anderen Raspberry-Varianten kein Linux laufen wird. Interessant könnte das Board trotzdem sein, da der Preis mit $4 sehr niedrig ist, und die Ausstattung des Mikrocontrollers durchaus interessant klingt:
Dual-Core Arm Cortex-M0+ @ 133MHz
264KB RAM
30 GPIO-Pins, davon 4 als Analogeingänge nutzbar
2× UARTs, 2× SPI-Controller und 2× I2C-Controller
16× PWM-Kanäle
1× USB-1.1-Controller und PHY, mit Host- und Deviceunterstützung
Gratulation an das RPi Team. Das Produkt sieht sehr gut aus. Und ein
sehr schöner Launch mit einem relevanten Ecosystem. Fehlt nur noch Wifi?
Der Preis ist wahrscheinlich ähnlich wie beim RPi-Zero zu sehen, oder?
Da war es auch nicht leicht, einen für die ursprünglichen 5 USD zu
ergattern.
Edit: Ok, an einem Punkt muss ich jetzt meckern: Wer entwickelt 2021
noch Produkte mit Micro-B USB port? Das hätte nicht sein müssen.
Mir stellen sich da zwei Fragen:
- Das Warum? Boards mit CortexM0 gibts doch wie Sand am Meer. Muss die
RPi Foundation da unbedingt noch eines bringen?
- Der Name. "Raspberry Pi pico". Da denkt doch jeder an einen einen
weiteren Raspi, dabei hat das Teil mit einen Raspberry Pi etwa soviel
gemeinsam wie ein Fahrrad mit einem Düsenflugzeug.
Frank schrieb:> Mir stellen sich da zwei Fragen:>> - Das Warum? Boards mit CortexM0 gibts doch wie Sand am Meer. Muss die> RPi Foundation da unbedingt noch eines bringen?
Weil die RPI Foundation den Marktzugang hat und sich wie jedes
Unternehmen weiter entwickeln will. (Die Antwort wird sicherliche
einigen nicht gefallen).
Ich finde es sieht wie ein guter Ersatz für die Blue Pill aus. Wenn sich
das Ecosystem ähnliche wie beim Rpi entwickelt wäre das nur gut. Ganz so
einfach ist die Entwicklung für STM32 ja doch noch nicht.
> - Der Name. "Raspberry Pi pico". Da denkt doch jeder an einen einen> weiteren Raspi, dabei hat das Teil mit einen Raspberry Pi etwa soviel> gemeinsam wie ein Fahrrad mit einem Düsenflugzeug.
Marketing
Programmable I/O tönt noch spannend und RAM scheint es auch relativ viel
zu haben. Ansonsten ist das Ganze eher langweilig bis enttäuschend.
Am Modul an sich sind die Halblöcher noch interessant, so muss man als
Hobbyfrickler nicht unbedingt Hühnerfutter und USB-Buchsen löten und
kann trotzdem auf THT verzichten.
ich finde es nur Schade das ein M0+ core eingebaut wurde, sind M4 soviel
teurer? Gerade der GCC Compiler optimiert für M0 sehr schlecht, da hat
sich afaik trotz jährlich neuer Versionen wenig getan. Gut, mit seinen
133 MHz macht er das für viele Anwendung mehr als wett.
Auf jeden Fall ein interessantes Teil, ein Datenblatt gibt es hier:
https://datasheets.raspberrypi.org/rp2040/rp2040_datasheet.pdf
Im Datenblatt wird erklärt, wie sich der Produktname zusammensetzt (also
für die MCU selber). Die erste '0' steht für Cortex-M0, es ist also zu
erwarten dass da noch mehr nachkommt (muss ja nicht unbedingt von der Pi
Foundation sein, es gibt ja wohl jetzt schon Boards von anderen
Herstellern).
Insgesamt sieht das aber schon recht leistungsfähig aus, und ist für den
Preis auch konkurrenzfähig (sofern man kein WiFi braucht). Inbesondere
die programmable IO state machines sind cool, da kommen bestimmt noch
coole Ideen rum (es gibt nicht viele Prozessoren in der Größe die VGA in
Hardware machen können wenn man es braucht).
Das einzig interessante an dem Modul ist der Preis.
Alles andere gibt es in deutlich besser von anderen Herstellern wie ST,
NXP usw.
Da hat man auch den Vorteil dass man frei skalieren kann. Hier hat man
nur M0 Kerne und begrenzte I/Os und Peripherie. Bei den anderen kann man
von M0 - M7 skalieren mit beliebig viel Peripherie - ohne die MCU
Familie und Toolchain zu wechseln.
133Mhz und 2 Kerne, aber dann M0+?
Warscheinlich sind das die Auswüchse von ARMs neuer Lizenzpolitik?
Da wird der M0 ja für lau verscherbelt, da wird der M4 zu teuer gewesen
sein fürn eigenen ASIC.
Johannes S. schrieb:> ich finde es nur Schade das ein M0+ core eingebaut wurde
Schade sicherlich, aber siehe mein Text am Postanfang.
Der M0 hat ja kein HW DIV.
Der Raspi hat aber eine:
Interpolator and integer divider peripherals
Das wird interessant das dem Compiler beizubringen.
Das Ding hat übrigens kein Flash sondern ein Bootloader der sich am USB
meldet und das ganze in SRAM schiebt.
Aber QSPI ist anschließbar.
Dafür wäre aber zumindest ein unbestückter Footpint auf dem PCB sehr
freundlich gewesen.
Mehmet K. schrieb:> Was Stromverbrauch anbelangt, habe ich nur etwas zu sleep gefunden.> Standby scheint es nicht zu haben.
Mit diesem Strom laufen andere Controller ja fast mit normalem Takt. :-(
Nee, dann lieber einen Blue- oder Blackpill.
Eine Frage, ich hab mir soeben 4 Stück von denen bestellt und würde
gerne diese Konsole hier https://shop.pimoroni.com/products/picosystem
preiswerter nachbauen. Nun stellt sich mir die Frage ob man den Pico
(gemeinsam mit einem LCD) über einer 3V Knopfzelle betreiben kann?
Tim . schrieb:> Ist Seiten Datenblatt/Preis eine gute Metrik für die Kosteneffizienz von> Microcontrollern?
Wenn Größe Datenblatt proportional zu Funktionsvielfalt Prozessor dann
ja.
Gerade bei Anfänger/Bildungscomputer hatte man mit abgespeckten
varianten. Damit sollte wohl verhindert werden, das der Anfänger
erschlagen wird, das Handbuch dazu dann eine Idiotensicher
Durchklick-anleitung ...
Da lob ich mircontroller mit ordentlich Peripherals, die auch
ausreichend dokumentirt sind um ggf selbst was aufs bit genau zu
stricken. Alles von der GUI vorkauen lassen ist IMHO unbefriedigend.
Wie hier alle auf die Hardware beschränkt sind...
Ich gehe stark davon aus, dass die nicht einfach ein Board raushauen und
sonst nicht mehr viel kommt. Der Erfolg des RPi ist ja sicher nicht die
Hardware, die ist nämlich grottig im Vergleich zur Konkurrenz. Alleine
dass ein Broadcom eingesetzt wurde, ist Anti-Hobby/ Anti-Opensource par
exellence.
Hier wird wie beim Pi vermutlich die Softwareumgebung die grosse Stärke
sein. Mal schauen ob sie so was wie Arduino raus bringen, Arduino darauf
portieren oder sogar nochmals eine Abstraktionsebene höher was
rausbringen.
Mehmet K. schrieb:> Was Stromverbrauch anbelangt, habe ich nur etwas zu sleep> gefunden.
Das sind ja die werte für ne 5V versorgung, lt. Text genügt dem aber
1V8. nicht das bei den Zahlen ein DCDC sich einen kräftigen Schluck aus
der Strompulle genehmigt.
Mich würde auch interessieren, ob der RP2040 chip auch direkt bei
Distributoren verfügbar wird, oder obs den nur auf dem Board und den
Third-party boards gibt. Auf die Schnelle hab ich da nichts gefunden.
Mw E. schrieb:> Aber QSPI ist anschließbar.> Dafür wäre aber zumindest ein unbestückter Footpint auf dem PCB sehr> freundlich gewesen.
Laut Raspi Seite sind da 2MB QSPI Flash drauf
> 264KB of SRAM, and 2MB of on-board Flash memory
Mehmet K. schrieb:> Was Stromverbrauch anbelangt, habe ich nur etwas zu sleep gefunden.> Standby scheint es nicht zu haben.
Das sind aber auch die Werte vom ganzen Board, der Chip selbst braucht
weniger.
Aber 0,4mA im Sleep ist immer noch recht viel im vergleich zu anderen
Mikrocontrollern.
Und laut Seite 628 im Datenblatt kommt er im Run mode auch bei nur gut
10MHz (genau kann man das auf der Grafik nicht erkennen, ca 12Mhz würde
ich schätzen) auf immer noch knapp 5mA bei optimalen Konditionen.
Meme schrieb:> Kann man den Raspberry Pi Pico mit 3V betreiben lassen?
Im Datenblatt vom Raspberry Pi Pico steht:
Pico uses an on-board buck-boost SMPS which is able to generate the
required 3.3 volts (to power RP2040 and external circuitry) from a
wide range of input voltages (~1.8 to 5.5V). This allows
significant flexibility in powering the unit from various sources
such as a single Lithium-Ion cell, or 3 AA cells in series.
Battery chargers can also be very easily integrated with the Pico
powerchain.
Also kann der mit 1,8-5,5V am Eingang (VSYS Pin) laufen
Der Sinn dieses Boards erschließt sich mir nicht im geringsten.
Warum man 2021 einen Microcontroller für Bastelanwendung onhe Flash
produziert ist mir unverständlich. Genauso warum man nur ein USB1.1
Interface verbaut.
So ziemlich jeder Hersteller hat da besseres im Angebot. Exemplarisch
sei mal der STM32H730 erwähnt
(https://www.st.com/content/st_com/en/products/microcontrollers-microprocessors/stm32-32-bit-arm-cortex-mcus/stm32-high-performance-mcus/stm32h7-series/stm32h730-value-line/stm32h730vb.html)
Das ist ne ganz andere Leistungsklasse bei ähnlichem Preis (2.80€ bei
Mouser bei 2500 Stück, d.h. bei größeren Stückzahlen direkt vom
Hersteller vermutlich noch deutlich billiger). Hätten sie den genommen
mit Quarz und USB-C(!)-Anschluss auf ein Board geklatscht und für einen
ähnlichen Preis verkauft wäre das toll gewesen.
Aber gefühlt läuft das bei Raspi immer so. Nachdem der Raspi 4 endlich
mal eine schnelle Anbindung von USB und Ethernet hat lassen sie die
Crypto-Extensions weg und beschränken damit wieder die Performance in
vielen Anwendungen. Mir erschließt sich die Strategie dahinter einfach
nicht.
Mw E. schrieb:> Der M0 hat ja kein HW DIV.> Der Raspi hat aber eine:> Interpolator and integer divider peripherals> Das wird interessant das dem Compiler beizubringen.
Ist ja schon gemacht:
"When enabled, the default divider AEABI support maps C level / and % to
the hardware divider. When building softwareusing the Pico SDK and
using the divider directly, it is important to read the
quotient register last. This ensures thepartial divider state
will be correctly saved and restored by any interrupt code
that uses the divider. You should readthe quotient register
whether you need the value or not."
An anderer Stelle schreiben die folgendes:
"As Cortex-M0+ lacks a floating-point unit, we have commissioned
optimised floating-point functions from Mark Owen, author of the popular
Qfplib libraries; these are substantially faster than their GCC library
equivalents, and are licensed for use on any RP2040-based product."
Irgendwie macht beides zusammen den Eindruck, als hätten die eigentlich
einen Cortex M4 gebraucht, aber aus unbekannten Gründen (finanzielle?)
hat es nur zu einem M0+ gereicht und die fehlenden Features werden jetzt
halbgar ausgebügelt.
R2D2 schrieb:> Warum man 2021 einen Microcontroller für Bastelanwendung onhe Flash> produziert ist mir unverständlich
Zumindest Flash haben sie ja als QSPI Flash am Board mit XIP.
Und wenn ich für eine eigene Platine noch einen kleinen SPI Flash dazu
planen muss, ist das auch nicht besonders schlimm.
Das macht den Chip deutlich kleiner und im ganzen wahrscheinlich
günstiger. Das machen ja auch die ESP8266 und ESP32 so.
Mw E. schrieb:> [...]> Dafür wäre aber zumindest ein unbestückter Footpint auf dem PCB sehr> freundlich gewesen.
Dann hätten sie aber auf ihre Himbeere verzichten müssen :-)
R2D2 schrieb:> Der Sinn dieses Boards erschließt sich mir nicht im geringsten.>> Warum man 2021 einen Microcontroller für Bastelanwendung onhe Flash> produziert ist mir unverständlich. Genauso warum man nur ein USB1.1> Interface verbaut.
Sie haben keinen Microcontroller für Bastelanwendungen rausgebracht,
sondern ein Board. Und das hat Flash.
Ja sogar so viel, dass man ohne optimieren und sachen rausschmeissen ein
ordentliches OS oder einen ganzen Interpreter darauf laufen lassen kann.
Wenn du nur einen super uC zum guten Preis suchst, hast du Pech bei der
Rpi Foundation. War aber beim Raspberry Pi auch schon so, das SoC ist
eine Qual.
Operator S. schrieb:> R2D2 schrieb:>> Der Sinn dieses Boards erschließt sich mir nicht im geringsten.>>>> Warum man 2021 einen Microcontroller für Bastelanwendung onhe Flash>> produziert ist mir unverständlich. Genauso warum man nur ein USB1.1>> Interface verbaut.>> Sie haben keinen Microcontroller für Bastelanwendungen rausgebracht,> sondern ein Board. Und das hat Flash.
Natürlich haben sie einen Microcontroller für Bastelanwendungen
rausgebracht.
Deshalb können ja auch Adafruit, Pimoroni & Co. Bastelboards mit dem
Controller herausbringen.
interessierter schrieb:> Wie sind die Daten des AD-Wandlers?
Steht auch im Datenblatt:
4 channel ADC with internal temperature sensor, 0.5 MSa/s, 12-bit
conversion
> 600+ Seiten Datenblatt zu Registern und Modi
Nach meinen bisherigen Erfahrungen mit den Produkten der
"Foundation", wird das Erratasheet dann wohl 50 Seiten haben.
Da haette ich z.B. zu NXP weitaus mehr Vertrauen.
Ich finde persönlich die "PIO"-Geschichte schon sehr sexy. Sicher ist
das keine Weltneuheit (gibt es ja etwa bei PSoC schon lange) aber die
Transparenz, mit der das durchgezogen wird imponiert mir.
Bei den PSoCs etwa, stößt es mir sehr sauer auf, dass das nur mit deren
IDE programmierbar ist. Bei dem RP2040 hingegen kann man die
State-Machine frei programmieren (als reinen Assembler). Dadurch ist das
teilen von Code ("Libraries") wesentlich einfacher und man kann alles
problemlos per Git verwalten und dokumentieren. State-Machines für I2C,
SPI, I2S und vieles mehr sind schon implementiert und viele weitere
werden sicherlich durch die Community folgen. Ich denke da etwa an
WS2812 oder 1-Wire. Insofern sehe ich für das Board (dessen Controller
es mal leider wieder nicht für Normalsterbliche zu kaufen gibt) eine
durchaus erfolgreiche Zukunft.
Mal von einem anderen Standpunkt betrachtet: Wenn RPF nun anfängt in den
Halbleitermarkt einzusteigen, kann es gut sein, das früher oder später
ein eigener SoC auf den Markt kommt, der vielleicht auch entgegen der
Broadcom Chips offen und frei erhältlich ist. Ein Mikrocontroller kann
daher eine gute Basis sein um die Peripherie zu entwickeln und zu
debuggen, ob da ein Cortex M0 oder ein Cortex A drin werkelt spielt
daher erst mal eine untergeordnete Rolle.
Cihan S. schrieb:> Irgendwie ist bei denen nie was verfügbar oder der Preis verdoppelt> sich.
Also ich habe gerade einige Picos für 4,10€/Stk geordert. Sprich: es ist
verfügbar, und der Preis ist in der angegebenen Größenordnung.
Jack V. schrieb:> Cihan S. schrieb:>> Irgendwie ist bei denen nie was verfügbar oder der Preis verdoppelt>> sich.>> Also ich habe gerade einige Picos für 4,10€/Stk geordert. Sprich: es ist> verfügbar, und der Preis ist in der angegebenen Größenordnung.
Verfügbar ist der pico erst wenn auch versendet wird.
Weis einer wo man Informationen zu der State Maschine herbekommt ?
In Anlehnung an MicroPython (darum geht es hier wohl primär) und dem
passenden Zusatz "Pico" schlage ich den Namen "Raspberry µP" vor. Das
kann man dann interpretieren wie man will und es passt immer irgendwie.
Hut ab für eigenes Silizium, aber wozu?
Ich benutze solche Boards privat und geschäftlich zum evaluieren und
austesten und später kommt dann der Controller auf ein eigenes Board.
Bei QFN-56 mit Exposed Pad und ohne Flash nein danke!
Meine privat gewonnenen STM32 Kenntnisse kann ich gefühlt in jedem
Entwicklungsbüro auch beruflich einsetzen. Ich bleib bei ST sowohl beim
Silizium als auch als Aktionär!
R2D2 schrieb:> Hätten sie den [Anmerkung: STM32H730] genommen> mit Quarz und USB-C(!)-Anschluss auf ein Board geklatscht und für einen> ähnlichen Preis verkauft wäre das toll gewesen.
Dann gäbe es anderes Gemecker: zu wenig Flash, zu wenige Pins
herausgeführt, ...
Aber der RP2040 wird sicherlich ein großer Erfolg. Unteres Mittelmaß
kommt immer gut an ;-)
Marco S. schrieb:> Verfügbar ist der pico erst wenn auch versendet wird.
→ „Ihre Bestellung hat erfolgreich unser Lager mit DHL, Sendungsnummer:
[…] verlassen und sollte in Kürze bei Ihnen eintreffen.”
Marco S. schrieb:> Weis einer wo man Informationen zu der State Maschine herbekommt ?
Das ist im Datenblatt zum Chip eigentlich ziemlich gut beschrieben.
Da gibts eine Beschreibung der State-Machines und der Assembler-Befehle.
Einzig das Side-Set/Delay ist etwas schlechter beschrieben, aber man
kann es imho ausknobeln, vielleicht ist es im Buch auch schöner
beschrieben.
Mehmet K. schrieb:> OptimistPrime schrieb:>> Hut ab für eigenes Silizium>> Die Frage, die ich mir stelle ist die, warum sie nicht gleich was mit> RISC-V gemacht haben.
Das Eco System fuer CortexM ist viel ausgereifter. Und wenn ich das Arm
Lizensierungsprogramm richtig verstehe, kann man fuer M0 mit 0 Euro
starten. Ob das auch fuer M0+ gilt, habe ich nicht herausgelesen.
Mehmet K. schrieb:> OptimistPrime schrieb:>> Hut ab für eigenes Silizium>> Die Frage, die ich mir stelle ist die, warum sie nicht gleich was mit> RISC-V gemacht haben.
Weil RISC-V zu dem Zeitpunkt, als die mit dem rp2040 angefangen haben,
noch nicht ausgereift war. Die haben ja nicht erst vor einem Jahr mit
der Entwicklung begonnen.
Jack V. schrieb:> Marco S. schrieb:>> Verfügbar ist der pico erst wenn auch versendet wird.>> → „Ihre Bestellung hat erfolgreich unser Lager mit DHL, Sendungsnummer:> […] verlassen und sollte in Kürze bei Ihnen eintreffen.”
Ingrid: siehe Anhang. Verfügbarkeit ist also eindeutig gegeben ;)
oerks schrieb:> Nach meinen bisherigen Erfahrungen mit den Produkten der> "Foundation", wird das Erratasheet dann wohl 50 Seiten haben.
Nö. Einfacher Core, stark vereinfachte Peripherie. So ein Ansatz ist
nicht nur einfach zu programmieren, sondern läßt auch das Potential für
Errata stark schrumpfen.
> Da haette ich z.B. zu NXP weitaus mehr Vertrauen.
Naja, Vertrauen kommt gleich nach Glauben, ist im Prinzip sogar genau
dasselbe...
Ich traue niemandem, nichtmal mir selbst. Alle machen Fehler. Trauen tue
ich aber dem Grundsatz, dass geringere Komplexität die Chance
verringert, Fehler zu machen. Auf jeder Ebene, von der Hardware bis zur
Anwendung...
Uwe Bonnes schrieb:> Wo hattest Du bestellt?
Bei BerryBase/Sertronics – bin mir nicht sicher, ob ein Link hier okay
wäre, aber mit den Infos wird man es schon finden.
> [PIO] Ich denke da etwa an WS2812
Im Datenblatt[1] ist ein Beispiel, wie man mit den PIOs das
WS2812-Protokoll implementiert - ist dann DMA-fähig und läuft komplett
im Hintergrund. Weitere Beispiele sind VGA-Output und I2S. Auf YT ist
nen Video, wie sie mit dem Teil einen BBC-Micro emulieren ...
Ich muß schon sagen, dass ich von dem Raspico ziemlich beeindruckt bin -
dürfte dem Arduino ziemlich die Suppe versalzen und auch PJRC (Teensie)
dürfte nicht erfreut sein.
[1] Das was ich bisher von der Doku gesehen hab, sieht übrigens ziemlich
gut aus (naja der Font ist Mist ;-) ). Wird ausführlich beschrieben mit
Beispielen, Fallstricke auf die man achten muss, etc.
Hut ab vor den Entwicklern des uC. Sie haben einfach mal ein wenig
nachgedacht.
Beispiel Timer: 64bit us-Timer, welcher auch noch so auslesbar ist, dass
man mit den Zahlen was anfangen kann. Ich hab gedacht ich lese im Manual
ueber meinen eigenes usTimer.h (nur 32-bit, aber selbes Prinzip). Cool.
Auf 'nem LPC81x muss man den SCT opfern um 32bit us-Timings zu
realisieren, die anderen Timer kann man in die Tonne kloppen - entweder
fehlt der Prescaler oder die 32-bit Breite.
Beispiel PWM: mehrere Slices koennen mit voreinstellbarer
Phasenverschiebung synchron gestartet werden. JA! So geht das. Viele
PWMs und dann auch noch synchronisierbar. Sehr gut.
Beispiel Cores: endlicht mal kein daemlicher Mix aus M4/M0 sondern
GLEICHE cores. Und dann auch noch mit so hoher Taktfrequenz. Angenehm.
Beispiel RAM: was muss ich immer suchen um ein paar kB mehr RAM zu
haben.
Die RP-Entwickler haben's begriffen. RAM muss drauf. Ich persoenlich bin
noch nie an die FLASH-Grenze gestossen, aber immer wieder an die
RAM-Grenze. Liegt vielleicht daran, dass ich meine Programme schreib und
nicht zusammeklicke.
Ich freu mich drauf, mit dem Pico etwas zu machen...
...also vorausgesetzt den gibt's als nacktes Bauteil!!!
Rudolph R. schrieb:> foobar schrieb:>> dürfte dem Arduino ziemlich die Suppe versalzen>> Wie das wenn die von vornherein auf dem Hype-Train mitfahren dürfen?
Die Aussage ist kompletter Unsinn, sonst würde Arduino gegenüber
Hardware Clones vorgehen, im Gegenteil es ist offene Hardware, wenn ich
mich richtig erinnere sind sogar nicht nur die Schaltpläne sondern auch
Layoutdateien frei verfügbar.
Irreführende Werbung, Kundenverarsche, das Ding Raspberry Pi zu nennen.
Und für den Preis in Deutschland wohl nie erhältlich, wenn überhaupt
lieferbar.
Aaron schrieb:> Und für den Preis in Deutschland wohl nie erhältlich, wenn überhaupt> lieferbar.
Brille kaputt? Oben habe ich den Werdegang skizziert: vorgestern für
4,10€/Stück bestellt, heute lagen sie auf dem Tisch. Hab sogar ein Bild
angehängt.
Marc Prager schrieb:> Hut ab vor den Entwicklern des uC. Sie haben einfach mal ein wenig> nachgedacht.
Tja, aber leider haben sie das Erdachte nicht vernünftig umgesetzt.
Beispiele:
- Sie haben gemerkt, dass man einen Hardware-Divider braucht -> also
haben sie einen implementiert.
- Sie haben gemerkt, dass sie für die angedachten Einsatzzwecke
Floatingpoint brauchen -> also haben sie optimierte Bibliotheken
lizensiert, die deutlich schneller sind als die Standard-GCC-Libs.
Ein vernünftiger Entwickler hätte gemerkt, dass für die angedachten
Einsatzzwecke ein M0+ absolut ungeeignet ist und hätte zum M4F
gegriffen. Dann hätte man sich den Quatsch mit dem Divider und den
lizensierten Bibliotheken sparen können.
> Beispiel Cores: endlicht mal kein daemlicher Mix aus M4/M0 sondern> GLEICHE cores. Und dann auch noch mit so hoher Taktfrequenz. Angenehm.
Tja, wie geschrieben, leider die falschen Cores. Daher wäre ein
M4F/M0-Mix besser gewesen als der M0+/M0+.
Vernünftig wäre ein M4F/M4F.
> Beispiel RAM: was muss ich immer suchen um ein paar kB mehr RAM zu> haben.> Die RP-Entwickler haben's begriffen. RAM muss drauf. Ich persoenlich bin> noch nie an die FLASH-Grenze gestossen, aber immer wieder an die> RAM-Grenze. Liegt vielleicht daran, dass ich meine Programme schreib und> nicht zusammeklicke.
Liegt eher daran, dass Du keine Daten wie Grafiken oder Fonts nutzt. Die
fressen nämlich den Flash weg.
Marco S. schrieb:> Was kann der M4F noch mehr als M0+?
Er hätte dann auch noch zusätzlich DSP Befehle.
Offensichtlich war die Lizensierung des M4 wohl zu teuer.
Aber hätt man dann nicht gleich RISC-V nehmen können?
Marco S. schrieb:> Was kann der M4F noch mehr als M0+?
DSP-Erweiterungen, Multiplizieren und Dividieren, Bit-Speicherbereich,
generell ist alles etwas reichlicher ausgestattet, z.B. auch der
VIC/Prioritaeten.
> Liegt eher daran, dass Du keine Daten wie Grafiken oder Fonts nutzt.> Die fressen nämlich den Flash weg.
Fonts nutz ich schon, bloss halt eher kleine (8x8, 6x11 und so).
Grafik, ja, das muss bei mir berechnet werden. Keine Bildchen erlaubt
.-)
Aber z.B. fuer Threads braucht man Stacks = RAM.
Fuer 0-waitstates Ausfuehrung braucht man RAM.
Fuer Framebuffer braucht man RAM
Fuer Netzwerkpuffer braucht man RAM
Alles Sachen, die mit keiner Menge an FLASH wettzumachen sind.
Brauch ich mehr FLASH, haeng ich ein SPI-Flash dran und gut.
Marco S. schrieb:> Ist es eine kostenfrage gewessen.> Sind die Libs preiswerter als die Lizenzgebühren für den M4F?>> Was kann der M4F noch mehr als M0+?
M0+ ist ARMv6-M, M3/4 ist ARMv7-M.
Daher ist der Befehlssatz des M0+ deutlich kleiner und entsprechend die
Programme ineffizienter.
Das gleiche C-Programm (gcc) braucht auf dem M0+ deutlich mehr Zyklen
als auf dem M3/M4.
Hinzu kommen natürlich bei dem M4F zum einen die SIMD-Befehle und
Befehle für Saturierende Arithmetik. Und dann halt die Floating-Point
Befehle.
> Offensichtlich war die Lizensierung des M4 wohl zu teuer.
Nicht vergessen: der M4 braucht gegenüber dem M0 ca den 4-fachen Platz
auf dem Die, bei M4F dürfte es noch mehr sein. Die-Größe geht direkt in
den Preis rein. Btw, laut Heise ist der Die des RP2040 gerade mal 2mm²
groß.
Bei vielen Herstellern fällt die Wahl auf einen M3/4 doch hauptsächlich,
um einen höheren Takt zu bekommen. Der RP2040 hat es hinbekommen, einen
M0+ auf 133MHz zu prügeln - mir reicht das. Ein M0 ist noch gut
überschaubar - mir gefällt die Wahl, insb wenn es dazu führt, einen
kleinen billigen Controller zu bekommen.
Für mich ist das einfach die nächste Generation nach Arduino (Atmega328)
und BluePill (STM32F103). Und mit ihrem (im Vergleich opulent
ausgestattetem) 4€-Board, guter Doku und Software sind sie da auf einem
guten Weg. Bin eh erstaunt, dass es ein europäisches Unternehmen
schafft, in diesem Billigmarkt mit den Chinesen konkurieren zu können.
Fehlt nur noch der Einzelchip in einem bastlerfreundlicheren Gehäuse ;-)
Für mich kam der Chip völlig unerwartet, ich dachte Raspberry hätte mit
dem Zero leistungsmäßig das untere Ende des Portfolios erreicht.
Ich glaube dass der Chip ein Erfolg wird. Er hat gute Doku und geht mit
dem Herstellersupport für microphython und C/C++ über den Durchschnitt
hinaus. Es gibt sogar ein Getting-Started-Buch.
Viel leichter kann man den Einstieg für Anfänger kaum machen. Mit C/C++,
dem PIO-Assembler und der RAM-Ausstattung ist er auch für Profis noch
interressant. Und immer noch billig genug.
Dass es in naher Zukunft Varianten von Adafruit, Sparkfun und Arduino
geben wird (z.B. kleiner, mehr Flash oder mit WLAN) ist ein cleverer
Schachzug. Das gibt mehr Marktdurchdringung für den Chip. Der Pico ist
so nicht nur ein einzelnes uC-Board von einem Hersteller (davon gibts
dutzende), sondern von Tag 1 an ein neues Ökosystem.
Glaubwürdigkeit bei der Ökosystempflege hat Raspberry beim Pi schon
bewiesen.
Der Chip pur in einem bastlerfreundlicheren Package, z.B. TQFP-64, wäre
natürlich schick. Aber ich denke da muss man lange drauf warten, wenn
überhaupt. Der Markt dafür lohnt kaum. Die Maker kommen mit den fertigen
Boards klar, Profis können den QFN-56 verlöten.
Dass es den Chip irgendwann einzeln zu kaufen gibt, davon gehe ich fest
aus. Nur die nächsten Monate geht halt die ganze Produktion an die
Board-Hersteller.
Marc Prager schrieb:> LPC81x muss man den SCT
Deswegen haben die LPC84x für PWM zusätzlich den CTIMER
> RAM muss drauf
Laut RP2040 Datenblatt ist das RAM nicht am Stück sondern in "Bänken"
organisiert. Somit sollte der C-Compiler kein Array anlegen können, dass
größer als eine "Bank" ist.
Wie die Dual Cores auf das RAM synchron zugreifen können - bin ich mal
gespannt.
> Laut RP2040 Datenblatt ist das RAM nicht am Stück sondern in "Bänken"> organisiert. Somit sollte der C-Compiler kein Array anlegen können, dass> größer als eine "Bank" ist.
Die sechs Bänke liegen alle direkt hintereinander, 264kB an einem Stück.
Die letzten 2x4k sind allerdings als per-CPU Memory (aka Stack) gedacht
- da sollte man nicht unbedingt Arrays reinlaufen lassen ...
Was außerhalb des regulären RAM-Bereichs liegt, sind 16k XIP-Cache und
4k USB-Buffer. Falls man die Einheiten nicht braucht und abschaltet,
kann man das auch als normales RAM benutzen.
> Wie die Dual Cores auf das RAM synchron zugreifen können - bin ich mal> gespannt.
Jede Bank hat einen eigenen Bus zur Busmatrix. Solange die Cores auf
unterschiedliche Bänke zugreifen, können sie ohne Verzögerung auf den
Speicher zugreifen. Ansonsten wird arbitriert. Zur Synchronisation bei
Zugriffen auf gemeinsame Daten gibt es 32 Spinlocks.
foobar schrieb:> Jede Bank hat einen eigenen Bus zur Busmatrix. Solange die Cores auf> unterschiedliche Bänke zugreifen, können sie ohne Verzögerung auf den> Speicher zugreifen. Ansonsten wird arbitriert. Zur Synchronisation bei> Zugriffen auf gemeinsame Daten gibt es 32 Spinlocks.
Um die Wahrscheinlichkeit zu verringern, dass die 2 Cores (oder die 2
DMA-Busmaster) gleichzeitig auf die selbe Bank zugreifen wollen gibt es
den Speicher im Adressraum 2 mal: einmal als 4 aufeinanderfolgende
Blöcke und einmal als Stripeset, wo jedes nachfolgende DWord in der
nächsten Bank liegt. Die Busmatrix kann 4 Transfers gleichzeitig (bei
125MHz Takt also bis zu 2GByte/s).
So könnte man in einem Projekt Code schreiben, der explizit Sachen in
eine Bank legt, und die dann aufgabenspezifisch exklusiv nutzt, so wie
es mit den 4k-Bänken als Core-spezifischer Speicher gedacht ist.
Normalerweise wir ein Projekt jedoch das Stripeset nutzen um auch ohne
nachzudenken ein Load-balancing zu haben.
Habe dank dem Circuitpython-Image von Adafruit das Ding sehr komfortabel
zum laufen bekommen!
So macht das Coden dank der main.py auf dem USB-Laufwerk auch Bastlern
wie mir schnell wieder Spaß...
Hallo,
für wenige Euro gibt's die ST Nucleo mit ST V3 Debugger. Und wem ST zu
komplex ist, Cypress Psocs haben super Beispiele und Doku, auch in der
selben Preisklasse.
Ach ja, Arduino, BBC Micro,.... jede Menge super Plattformen.
Sorry, das Ding braucht niemand.
Grüße Seppel
Ich schaetze die wollen einen lock-in fuer die User. Das wird der Grund
sein, warum die einen eigenen MCU entwickelt haben. Dann wird es
schwieriger den MCU und das Board zu kopieren. Dual-Core M0+ ist
wirklich der letzte Rotz. Wer will denn nen M0+ im Dual-Core haben? Die
ganze Dual-Core Komplexitaet und dann fuer so nen Rotz MCU? Kein Big
Little? Die haetten auch mit einem RISC-V gehen koennen. Ne, stattdessen
machen die so etwas.
Philipp B. schrieb:> Wer will denn nen M0+ im Dual-Core haben?
Vielleicht nicht Du. Vielleicht nicht ich. Aber "Every Jack has his
Jill".
Also meiner Meinung die falsche Frage. Deine Frage hingegen, warum die
nicht gleich einen RISC-V genommen haben, hatte ich auch gestellt.
Worauf der berechtigte Hinweis kam, dass ja die Entwicklung eines
solchen Chips nicht von heute auf morgen stattfindet. Anscheinend war
beim Start die Zukunft von RISC-V nicht so eindeutig wie heute.
2 boards zum Rumspielen werde ich mir auf jeden Fall bestellen (und
hoffen, dass ich auch die Zeit zum Spielen finden werde).
Aber ernsthaft mir Gedanken werde ich mir erst machen, wenn die Chips
selbst in Massen zu günstigen Konditionen erhältlich sein werden. Denn
wenn sie auf einem preislichen Niveau wie die STM32G030 daherkommen
sollten, also da haette ich schon ein paar Projekte, wo ich sie
einsetzen würde.
Mehmet K. schrieb:> Also meiner Meinung die falsche Frage. Deine Frage hingegen, warum die> nicht gleich einen RISC-V genommen haben, hatte ich auch gestellt.
Vielleicht sollte man hier auch nicht vergessen, dass sowohl RPi als
auch ARM britische Unternehmen sind, bzw. waren. Warum genau sollten die
RISC-V einsetzen? Der Vorteil liegt vor allem darin, keine
Lizenzgebühren zahlen zu müssen. Da wird man sich mit ARM schon geeinigt
habe.
> Ich schaetze die wollen einen lock-in fuer die User.
Einen gewissen Lock-In hat man immer, sobald man die Peripherie
anspricht. Und da hilft es auch wenig, wenn z.B. STM32 und Kinetis den
gleichen Core verwenden. Außer vielleicht, man baut auf einen
Plattform-übergreifenden HAL.
Da finde ich die PSoC schlimmer, weil man auf die Herstellertools
(PSoC-Creator) angewiesen ist.
Jörg
Dieses Projekt finde ich ziemlich interessant:
https://github.com/Wren6991/picodvi
VGA per Mikrocontroller ist ein alter Hut. DVI ist schon next level...
Der RP2040 erreicht anscheinend auch >250MHz core clock. Da ist es gar
nicht schlimm, dass es nur ein M0+ ist...
Guten Morgen, ich hatte mir vor genau 1 Woche den RPI Pico bestellt.
Keine 2-3 Stunden vor Verkaufsstart. Direkt in den Warenkorb gelegt und
bestellt (bei Funk24.net) und was ist... ich warte seit 1 Woche
vergebens. Jetzt hab ich denen mal eine E-Mail geschickt und man sagte
mir die haben die Lieferung für die RPI Picos noch nicht einmal
erhalten, die kommen erst morgen. Also muss ich noch mal 1 Woche warten.
Aber wie kann es sein das manche hier keinen Tag nach Verkaufsstart
ihren RPi in der Hand halten?
Meine 4 Pico sollen heute kommen. Bestellt bei Welectron via Vorkasse.
Respekt mit dem HDMI.
Das man den auf >250 MHZ übertakten kann ist glaub weil man einen M0+
hat statt M4F der deutlich komplexer ist.
Marco S. schrieb:> Das man den auf >250 MHZ übertakten kann ist glaub weil man einen M0+> hat statt M4F der deutlich komplexer ist.
Es wird halt auch ein 40nm Prozess verwendet. Die einzigen anderen CM0
in 45nm sind m.E. die STM32G0x. Die haben bestimmt auch noch einige
Reserven.
Es würde mich mal interessieren, ob jemand linux darauf portiert.
Möglich ist es ja mit m0+ und nommu. Wäre natürlich ein bisschen Arbeit,
die Treiber für USB, UART und andere zu implementieren. Ich könnte mir
das aber gut mit Kernel XIP und das Dateisystem als readonly wie z.B.
romfs im flash vorstellen.
Meme schrieb:> Aber wie kann es sein das manche hier keinen Tag nach Verkaufsstart> ihren RPi in der Hand halten?
Sie haben drauf geachtet, dass „Autorisierter Reseller“ dransteht, sowie
darauf, dass der Artikel als „lieferbar“ angezeigt wurde :)
Seppel schrieb:> Sorry, das Ding braucht niemand.
Das ganze Internet braucht niemand. Aber ist ein nettes Spielzeug, so
auch das kleine Platinchen. Ist halt, wie so oft, das Gesamtpaket:
Features, Doku, Community, und, nicht zuletzt, Preis. Und: wem’s nicht
gefällt, weil $andereSachen viel toller sind, der kauft’s halt nicht –
gibt ja keinen Zwang. Bleibt mehr für die übrig, die derzeit noch warten
müssen.
Lorenz W. schrieb:> Es würde mich mal interessieren, ob jemand linux darauf portiert.> Möglich ist es ja mit m0+ und nommu. Wäre natürlich ein bisschen Arbeit,> die Treiber für USB, UART und andere zu implementieren. Ich könnte mir> das aber gut mit Kernel XIP und das Dateisystem als readonly wie z.B.> romfs im flash vorstellen.
Moeglich ja, vielleicht. Macht aber sicherlich keinen Spass.
Joerg W. schrieb:> Da finde ich die PSoC schlimmer, weil man auf die Herstellertools> (PSoC-Creator) angewiesen ist.
Der interne (kostenlose) compiler erzeugt Code der recht viel Platz
verbraucht. Mit 8k Byte Flash kommt man mit einem AVR viel weiter als
bei einem PSoC.
Lorenz W. schrieb:> Es würde mich mal interessieren, ob jemand linux darauf portiert.> Möglich ist es ja mit m0+ und nommu. Wäre natürlich ein bisschen Arbeit,> die Treiber für USB, UART und andere zu implementieren. Ich könnte mir> das aber gut mit Kernel XIP und das Dateisystem als readonly wie z.B.> romfs im flash vorstellen.
Der RAM mit 256kb ist doch etwas zu wenig.
Ein paar Megabyte RAM sollte der Prozessor schon haben für uclinux.
Mehmet K. schrieb:> Die Frage, die ich mir stelle ist die, warum sie nicht gleich was mit> RISC-V gemacht haben.
Weil RISC V ein eher bescheidener Core ist? Die ARM Cortex sind deutlich
effizienter.
Guido K. schrieb:> Mehmet K. schrieb:>> Die Frage, die ich mir stelle ist die, warum sie nicht gleich was mit>> RISC-V gemacht haben.>> Weil RISC V ein eher bescheidener Core ist? Die ARM Cortex sind deutlich> effizienter.
RISC-V ist überhaupt gar kein Core, sondern eine ISA (Instruction Set
Architecture). Es gibt bereits jetzt eine große Anzahl unterschiedlicher
Implementationen.
Tim . schrieb:> RISC-V ist überhaupt gar kein Core, sondern eine ISA (Instruction Set> Architecture). Es gibt bereits jetzt eine große Anzahl unterschiedlicher> Implementationen.
Ja, natürlich. Aber der Instructionset ist halt eher mäßig. Einen
Prozessor ohne Flags zu bauen ist ein neuer Tiefstand im
Prozessordesign.
Es gibt immer mal wieder solche komischen Fehlleistungen. Man muss die
aber dann nicht benutzen.
Wenn man keine Ahnung hat?
MIPS hats auch nicht geschadet keine Flags zu haben.
Also ist dein "Tiefstand" schonmal nicht neu.
Bzw haben denn MIPS und RISC-V wirklich keine Flags?
Doch haben sie: ein Vergleichbefehl speichert das Ergebnis eben nicht in
einem globalen Statusregister ab, wos dann nur 4 Bits für alles sind,
sondern das Vergleichsergebnis ist in einem General Purpose Register
abgespeichert.
Guido K. schrieb:> Mehmet K. schrieb:>> Die Frage, die ich mir stelle ist die, warum sie nicht gleich was mit>> RISC-V gemacht haben.>> Weil RISC V ein eher bescheidener Core ist? Die ARM Cortex sind deutlich> effizienter.
Zum Unterschied zwischen ISA und Mikroarchitektur wurde ja schon
geschrieben.
Zur Effizienz nur ein Beispiel (gcc):
Sifive E21 (RISC-V):
1,47 DMIPS/MHz
3,1 CoreMarks/MHz
ARM Cortex M3/M4:
1,25 DMIPS/MHz
2,76 CoreMarks/MHz
Nur ein Beispiel. Gibt auch noch effizientere RISC-V Cores.
von Lorenz W. (lw64)
28.01.2021 12:35
>Es würde mich mal interessieren, ob jemand linux darauf portiert.>Möglich ist es ja mit m0+ und nommu.
Wieso? Er hat doch eine MMU.
> https://github.com/Wren6991/picodvi>> Der RP2040 erreicht anscheinend auch >250MHz core clock.
Für 720p30 ist er gar auf 372MHz gegangen. Die spezifizierten 133MHz
scheinen ziemlich konservativ zu sein ...
> DVI ist schon next level...
Und da er dafür weniger als die Hälfte der Resourcen des µC braucht,
zeigt er ja auch noch dual-Head ;-)
Hier sind noch ein paar andere Spielereien:
https://github.com/Wren6991/PicoDVI/blob/master/software/Readme.md
Z.B.
"Full-resolution VGA RGB565 image viewer. As each raw image is over 600
kB, only a small slice of the image can reside in memory at once, so
images are streamed continuously from flash at 40 MB/s. The TMDS encode
uses around 95% of both cores, [...]"
"Display text with an 8x8px black and white font, displayed at full
resolution (so 80x60 characters at 640x480p 60 Hz, or 160x90 characters
at 720p30). [...] so you can display text over DVI with about 30% of a
core."
>> Es würde mich mal interessieren, ob jemand linux darauf portiert.>> Möglich ist es ja mit m0+ und nommu.
uCLinux gibt als minimale Speichergröße 4MB an, empfohlen wird 16MB.
> Wieso? Er hat doch eine MMU.
Er hat nur eine MPU (Memory Protection Unit), die kann nicht das, was
ein reguläres Linux braucht.
Ich verstehe den Sinn von Linux auf so einem uC nicht! Wozu?
Linux braucht mehr Speicher, hat mehr Overhead, ist dafür eher nicht
echtzeitfähig. Mikrocontroller haben eher weniger Speicher, Code deshalb
eher weniger Overhead, dafür aber Echtzeitfähigkeit.
Das ist doch komplett entgegengesetzt!
Und wenn man wirklich Sachen braucht, die normalerweise ein
Betriebssystem zur Verfügung stellt, z.B. mehrere Tasks, Timer,
Semaphoren und Message-Queues: Dann gibt es Echtzeit-Betriebssysteme!
Kleiner, mit weniger Overhead, gemacht für genau den Anwendungsfall.
> Ich verstehe den Sinn von Linux auf so einem uC nicht!
Ist ja auch Quatsch. Solche Fragen kommen meist von Leuten, die keine
Ahnung haben - deshalb fragen sie ja ;-)
So eine HW ordentlich zu programmieren, ist schon nicht mehr trivial -
insb durch die zwei Cores wird man auf einmal in ein Schwimmbad
geschmissen, in dem viele noch nicht geschwommen haben.
Ich bin mir ziemlich sicher, dass bald ein RTOS portiert wird, das einem
die dreckigen Details abnimmt und eine fachgerechte Basis/Infrastruktur
bereitstellt. Bis dahin nimmt man entweder das MicroPython oder man
macht sich halt dreckig ;-)
Die schiere Anzahl von GPIOs und dahinter liegender Interface-Einheiten,
die Rechenleistung, das Konzept mit dem QSPI Flash - Nun fehlt nur noch
die IDE - oder ich habe sie nur noch nicht gefunden.
Der Cortex M0 ist schnell. Selbst der ADC hier ist ziemlich flott.
Totgeburt - oder wie nennt man so was?
@Raspi: hört auf einen "Raspi" verkaufen zu wollen, der keiner ist.
Für mich gilt Raspi nur dann als Raspi, wenn er Linux kann.
Ansonsten braucht man das Teil nicht.
Raspi kann sich so ein Marketing Gag halt erlauben.
Jack V. schrieb:> Meme schrieb:>> Aber wie kann es sein das manche hier keinen Tag nach Verkaufsstart>> ihren RPi in der Hand halten?>> Sie haben drauf geachtet, dass „Autorisierter Reseller“ dransteht, sowie> darauf, dass der Artikel als „lieferbar“ angezeigt wurde :)
Korrekt. Am Mittwochabend bestellt und heute auf meinem Schreibtisch.
Zum Beispiel: https://www.welectron.com/
Joachim Kröger schrieb:> Nun fehlt nur noch> die IDE - oder ich habe sie nur noch nicht gefunden.
Die empfohlene Entwicklungsumgebung für C wäre VisualStudio Code, für
das MicroPython ist wohl Thonny angedacht. Details finden sich im
„getting started“-PDF.
Jack V. schrieb:> Details finden sich im> „getting started“-PDF.
Naja, für Leute, die es gewohnt sind, nur mit der Arduino-IDE zu
hantieren, stellt sowas schon einen ziemlichen Schock dar. Hoffentlich
stirbt keiner daran...
Man kann sich lange darüber streiten welche Features der IC hätte haben
sollen, aber das was vorhanden ist sieht doch an sich nach nem runden
Allround-Paket aus. Verglichen mit dieser Kombination aus Preis und
Features machen Bluepill und Arduino Nano/Mini/Micro plötzlich keine so
gute Figur mehr. Ich könnte mir gut vorstellen dass der PICO bei
MCU-Anfängern und Hobbyisten extrem beliebt wird.
von Florian S. (vatterger)
>Man kann sich lange darüber streiten welche Features der IC hätte haben>sollen, aber das was vorhanden ist sieht doch an sich nach nem runden>Allround-Paket aus. Verglichen mit dieser Kombination aus Preis und>Features machen Bluepill und Arduino Nano/Mini/Micro plötzlich keine so>gute Figur mehr. Ich könnte mir gut vorstellen dass der PICO bei>MCU-Anfängern und Hobbyisten extrem beliebt wird.
Nicht nur, da heutzutage nicht die Hardware sondern die Software die
meisten Kosten und Aufwände in den Projekte ausmacht.
Der Support und die Software-Resourcen, die beim Pi-Pico entstehen
werden, werden jede andere Platform um Größenordnungen schlagen.
In großvolumigen Stückzahlen wie z.B. in der Automobilindustrie wird der
Prozessor eher nicht eingesetzt werden, da dort ganz andere Faktoren
eine Rolle spielen, aber in mittleren Stückzahlprojekten und kleineren
Firmen sicher. Und zwar weltweit.
Ich könnte mir vorstellen, dass andere Halbleiterhersteller durch das
Konzept inspiriert werden.
Florian S. schrieb:> Ich könnte mir gut vorstellen dass der PICO bei MCU-Anfängern und> Hobbyisten extrem beliebt wird.
Schon allein aus diesem Grund habe ich mir die bestellt.
chris_ schrieb:> Ich könnte mir vorstellen, dass andere Halbleiterhersteller durch das> Konzept inspiriert werden.
es ist wohl eher andersrum, ich kenne keinen anderen Hersteller als ST
der soviel tut um seine Cortex-M an Frau/Mann zu bringen: Unzählige App
Notes für die vielen Peripherie Einheiten, einheitliche Libs wie
SPL/HAL, CubeMX zum µC finden/IO Planen/Konfigurieren/Dokumentieren/Code
generieren/Stromaufnahme kalkulieren/uvm., kostenlose Middleware für
alles Mögliche, mehrere Grafiklibs aufgekauft, mehrere IDE mit sehr
guter STM Unterstützung, direkter Herstellersupport für Arduino und
Mbed,...
Da muss Raspberry als Einsteiger erstmal hinkommen. Durch die
Beschränkung auf (erstmal?) einen µC ist das vielleicht erstmal
übersichtlicher, aber wenn man z.B. CAN in der HW haben möchte, dann ist
der RP2040 ja schon raus. Trotzdem glaube ich auch das die einfachen
Boards z.B. dem Bluepill ordentlich Konkurrenz machen werden.
Johannes S. (jojos)
>chris_ schrieb:>> Ich könnte mir vorstellen, dass andere Halbleiterhersteller durch das>> Konzept inspiriert werden.>es ist wohl eher andersrum, ich kenne keinen anderen Hersteller als ST>der soviel tut um seine Cortex-M an Frau/Mann zu bringen:
Mit Konzept meinte ich eher das Hardware-Konzept als das
Vertriebskonzept.
Beim PiPico werden so viele echte Freaks die Hardwarekombination aus
Dual-Core/Sio/Pio/MPU ausnutzen, dass kein anderer Mikrocontroller
mitkommt.
Ich könnte mir auch vorstellen, dass die Raspberry-Foundation auch schon
einen 16Kern M7 oder 48Kern Risk V mit Speziallogik in der Pipeline hat.
Die etablierten MCU-Hersteller sind vermutlich zu sehr marktorientiert
und zu wenig risikofreudig als dass sie innovativer Ansätze wie den
Propeller2 oder den PiPICO verfolgen würden.
Mich würden die Entwicklungskosten des PiPico interessieren. Nachdem was
ich so kenne, tippe ich mal auf ~10Millionen Euro maximal. Da sich auf
dem Prozessor nur quasi "Standardlogik" befindet und sich der gesamte
Prozessor auf einem FPGA testen lässt tippe ich mal auf 3
Maskendurchläufe bis zum fertigen Produkt.
chris_ schrieb:> Beim PiPico werden so viele echte Freaks die Hardwarekombination aus> Dual-Core/Sio/Pio/MPU ausnutzen, dass kein anderer Mikrocontroller> mitkommt.
Träum weiter...
Das was du unter "echte Freaks" verstehst sind die, die das Machen damit
sie sich mit geschwollener Brust als "echte Freaks" bezeichnen können.
Alle anderen lösen ihre Probleme.
Also ich wüsste kein Projekt was ich in den letzten 30 Jahren realisiert
habe, wo mir sowas wie der RP2040 einen echten Mehrwert gebracht hätte.
Und solange meine jetzige bevorzugte Entwicklungsumgebung zwar alles an
Cortex µCs bedient die RP2040 aber nicht, solange interessiert mich der
Hype nicht die Bohne.
temp schrieb:> Also ich wüsste kein Projekt was ich in den letzten 30 Jahren realisiert> habe, wo mir sowas wie der RP2040 einen echten Mehrwert gebracht hätte.
Das glaube ich dir. Es ist jedoch so, dass du und die anderen
Bastler/Nörgler hier im Thread nicht über das Wissen und das Können
verfügen, um den Raspberry Pico zu beurteilen. Dies ist auch einfach an
deinen und deren Einlassungen abzulesen. Das Gegenteil der
Bastler/Nörgler sind die (siehe oben), die sachlich und fachlich
argumentieren. EOT.
>Träum weiter...>Das was du unter "echte Freaks" verstehst sind die, die das Machen damit>sie sich mit geschwollener Brust als "echte Freaks" bezeichnen können.>Alle anderen lösen ihre Probleme.
Unter Freaks verstehe ich Leute nach Art der Computerfreaks vor 30
Jahren.
Das sind Leute, die mit der Technik spielen, kreativ sind und neue Ideen
entwickeln. Sie unterscheiden sich von den sogenannten
"Wissensarbeitern", denen man konkrete Probleme vorlegt und sie diese
dann mit bekannten Mitteln lösen.
So wie beim Bau eines Hauses Bauarbeiter für das aufsetzten der Steine
benötigt werden, wird in Elektronikbetrieben der Wissensarbeiter
benötigt, um ein entsprechendes Gerät zu entwickeln.
>Also ich wüsste kein Projekt was ich in den letzten 30 Jahren realisiert>habe, wo mir sowas wie der RP2040 einen echten Mehrwert gebracht hätte.>Und solange meine jetzige bevorzugte Entwicklungsumgebung zwar alles an>Cortex µCs bedient die RP2040 aber nicht, solange interessiert mich der>Hype nicht die Bohne.
Du hast zweifelsohne recht, wenn du der Ansicht bist, das
Wissensarbeiter für die konkrete Umsetzung eines Projektauftrags enorm
wichtig sind.
Martin schrieb:> Das Gegenteil der> Bastler/Nörgler sind die (siehe oben), die sachlich und fachlich> argumentieren.
Dann hilf mir mal. Das Datenblatt scheint mir unvollständig.
Ich suche Timer/Counter mit Input Capture Registern und kann sie nicht
finden.
> Ich suche Timer/Counter mit Input Capture Registern und kann sie nicht> finden.
Kapitel 4.5:
"The RP2040 PWM block has 8 identical slices. Each slice can drive two
PWM output signals, or measure the frequency or duty cycle of an input
signal."
m.n. schrieb:> Dann hilf mir mal. Das Datenblatt scheint mir unvollständig.> Ich suche Timer/Counter mit Input Capture Registern und kann sie nicht> finden.
Findest du unter PIO. Musst halt nur das passende Programm schreiben,
was aus einer Unit so einen Timer macht.
Martin schrieb:> Das glaube ich dir. Es ist jedoch so, dass du und die anderen> Bastler/Nörgler hier im Thread nicht über das Wissen und das Können> verfügen, um den Raspberry Pico zu beurteilen. Dies ist auch einfach an> deinen und deren Einlassungen abzulesen. Das Gegenteil der> Bastler/Nörgler sind die (siehe oben), die sachlich und fachlich> argumentieren.
Du hast doch den Schuss nicht gehört. Was soll ich mit dieser Krücke
anfangen, die nicht mal sowas wie CAN an Board hat? Klar braucht man
nicht immer und auch nicht jeder. Man muss auch bei STM nicht immer
einen Controller mit CAN verwenden, aber man kann! Und bleibt damit in
seiner Welt.
So, mal an die die hier so unendlich sachlich und fachlich
argumentieren. Bitte mal um Beispiele für Projekte die mit dem PICO
prima gehen und mit allen anderen Cortexen nur mit Klimmzügen.
Und nochwas, einen guten Entwickler zeichnet auch aus nicht jeder Kuh
hinterher zu laufen die durchs Dorf getrieben wird.
Marius schrieb:> Das sind Leute, die mit der Technik spielen, kreativ sind und neue Ideen> entwickeln.
Was hat das mit Kreativität zu tun einen µC gegen einen anderen zu
Tauschen? Und dann noch gegen so eine kastrierte Krücke. Versuch doch
mal damit eine Motorsteuerung mit FOC zu machen. Und wenn du es
hinkriegst, ist das dann eleganter und besser?
Ne,ne das Ding wird seine Abnehmer finden, wenn es bei Arduino
angekommen ist. Aber dann wird kaum keiner darauf ernsthaft entwickeln,
sondern nur Libs aus dem Netz zusammenstöpseln und hier dumme Fragen
stellen. So wie in der ESP Welt auch.
Aber eine ernsthafte Konkurenz zu bestehenden µCs wird das Ding nie im
Leben werden.
c-hater schrieb:> Findest du unter PIO. Musst halt nur das passende Programm schreiben,> was aus einer Unit so einen Timer macht.
Genau, und einen CAN Controller oder Ethernet kann man damit ganz leicht
auch selbst bauen. Schließlich verschafft uns Corona gerade genügend
Zeit für sowas.
temp schrieb:> So, mal an die die hier so unendlich sachlich und fachlich> argumentieren. Bitte mal um Beispiele für Projekte die mit dem PICO> prima gehen und mit allen anderen Cortexen nur mit Klimmzügen.https://github.com/Wren6991/picodvi
p.s.: Die Diskussion wird zunehmend unsinnig. Für mich sieht der Pico
nach einer sehr gelungenen Entwicklung für den Zielmarkt aus. Weh tun
wird es wahrscheinlich vor allem den AVRs und ESP32s. Um ST muss man
sich keine Sorgen machen. Die Leute, die hier am lautesten schreien sind
vermutlich auch die, die Marketing und Produktmanagement für eine
nutzlose Funktion halten.
temp schrieb:> Was soll ich mit dieser Krücke> anfangen, die nicht mal sowas wie CAN an Board hat?
Wieviele Projekte benötigen denn CAN?
-> Scheinargument
c-hater schrieb:> Findest du unter PIO. Musst halt nur das passende Programm schreiben,> was aus einer Unit so einen Timer macht.
Danke, gut zu wissen, aber wohl nicht anwendungsgerecht oder eher etwas
für setup() und loop() Fans, die nur die richtig Lib finden müssen.
Sicher ist man bei den etablierten besser dran wenn man CAN oder anderes
spezielles braucht. Aber Raspberry hatte schon mit dem Pi Schüler und
Bastler als Zielgruppe, und das war erfolgreich. Ich gehe davon aus das
der Pico ebenfalls primär für die Bastler ist, das ist schon ein
Millionenmarkt. Dann kommen immer noch jeden Monat Studenten in die
Firmen und sagen ‚guck mal, mit dem günstigen RPi geht das auch.‘ Und
diese Strategie funktioniert ja auch bei ST gut.
Der Pico wird auch nicht nur deshalb eingesetzt weil er besonders gut
für ein Projekt geeignet ist, der ist einfach da, billig, Programmierung
ist einfach. So ist es doch beim ESP auch. Jede Woche eine neue
Wetterstation mit ESP und dann die Frage welche Akkus, BMS und
Solarzellen. Wo ein kleiner uC mit zwei AA Zellen viele Jahre läuft. Das
stört die Bastler nicht weil sie die schlechte Lösung mit ihren Mitteln
hinbekommen. Da passt der Pico als Erweiterung rein.
Mw E. schrieb:> Wieviele Projekte benötigen denn CAN?> -> Scheinargument
Nein ist es nicht. Niemand hat Bock, sich ständig in neue/andere
Controller einzuarbeiten. Und wenn ich den PICO zu meinem
Lieblingscontroller mache und dann mal CAN brauche, passiert genau das
gleiche wie beim richtigen Raspi: Man pflanzt einen mcp2515 aus dem
letzten Jahrtausend dran. Fehlt noch ne Lösung für CANFD. Am besten
nimmt man dann einen passenden STM32 zu Hilfe. Oder gleich den STM/NXP
o.ä. für das ganze Projekt...
Tim . schrieb:> https://github.com/Wren6991/picodvi
ja, ist ein schönes Beispiel (für Dinge die die Welt nicht/kaum
braucht). Solche Projekte sind schön. So wie USB per Pin wackeln auf
AVR. Ich ziehe den Hut vor denen die sich das ausdenken, aber eine
massenhaft praktische Bedeutung erlangt das wohl nie.
>> Findest du unter PIO. Musst halt nur das passende Programm schreiben,>> was aus einer Unit so einen Timer macht.>> Danke, gut zu wissen, aber wohl nicht anwendungsgerecht
Kommt drauf an. Mit der PIO hätte man 32-Bit-Counter, evtl
Triggerbedingungen und DMA - bei den PWM-Slices bin ich mir noch nicht
klar, wie da DMA bei Input geht.
Johannes S. schrieb:> Das> stört die Bastler nicht weil sie die schlechte Lösung mit ihren Mitteln> hinbekommen. Da passt der Pico als Erweiterung rein.
Genau. Es bleibt eine Bastelplattform die davon leben wird Libs
zusammenzustöpseln und 10 eigene Zeilen in setup() und loop() zu
schreiben. Daß das einen Markt hat will ich ja nicht in Abrede stellen.
Aber eine ersthafte Konkurenz für STM, NXP, Infinion u.s.w wird es
dauerhaft nicht werden.
temp schrieb:> ja, ist ein schönes Beispiel (für Dinge die die Welt nicht/kaum> braucht). Solche Projekte sind schön.
Ditto. 5€ drauf für einen Pi Zero und man kann was sinnvolles damit
machen.
temp schrieb:> [allerhand Kram]
Weißt du, deine „Argumentation“ mag für dich ja schlüssig sein – nur
scheinst du zu übersehen, dass du nicht der Maßstab von Allem sein
kannst.
Du kommst mit dem klar, was du hast, und für dich ist der Pico zusammen
mit dem RP2040 überflüssig, weil du für dich keine Vorteile darin
siehst. Damit ist überhaupt nix verkehrt – du bist halt nicht Zielgruppe
des Picos.
Ich hingegen bekomme ’n fertiges Board für ’nen fairen Preis, für dessen
Nutzung ich mich nicht bei irgendwem registrieren muss, um die
spezifische IDE zu bekommen, ich mir keinen Programmer kaufen muss, ich
mir nicht die Doku für die ersten Schritte irgendwo zusammensuchen muss,
ich mir keine Sorgen über gefälschte Chips auf den Boards machen muss
(siehe BluePill). Eines, für das es eine Community mit einer ähnlichen
Einstellung, wie ich sie habe, gibt, und dessen enorme Breite an
Möglichkeiten mir auf lange Zeit ausreichen wird. Ich bin halt
Zielgruppe.
Die Frage, die sich mir stellt: hast du Angst vor’m RP2040/Pico, oder
warum versuchst du krampfhaft, den als Schrott hinzustellen, und den
Leuten, die’s gut finden, zu erzählen, dass sie doof wären?
temp schrieb:> Tim . schrieb:>> https://github.com/Wren6991/picodvi>> ja, ist ein schönes Beispiel (für Dinge die die Welt nicht/kaum> braucht).
Es funktioniert ja auch nur mit erheblicher Übertaktung von 133 MHz auf
252 MHz. Das mag nett sein, aber wohl nichts für eine ernsthafte
Anwendung.
temp schrieb:> Tim . schrieb:>> https://github.com/Wren6991/picodvi>> ja, ist ein schönes Beispiel
Es ist ein schönes Beispiel für eine Applikation, die
Bastler/Hacker/Maker interessiert. Leute die einfach Spaß daran haben,
technische Limits zu erkunden und etwas ausprobieren wollen. Leute die
etwas lernen wollen und sich selbst herausfordern. Leute, die einfach
für ein paar Euro ein neues Spielzeug mit einer großen Community, gutem
Support und vielen Gleichgesinnten haben wollen.
Genau das ist der Zielmarkt.
Wie viele Leute schrauben abends privat an einem Aurix herum? Oder einem
Renesas RZ? Die sind in ihrem Zielmarkt auch wichtig. Der ist nur ein
anderer.
temp schrieb:> Aber eine ernsthafte Konkurenz zu bestehenden µCs wird das Ding nie im> Leben werden.
Da hast Du recht und liegst damit verbal auf der Linie von Bill Gates,
dessen Sprüchlein wohl fast jeder kennt: „Niemand braucht mehr als 640
Kilobyte Arbeitsspeicher in seinem PC.“
temp schrieb:> Mw E. schrieb:>> Wieviele Projekte benötigen denn CAN?>> -> Scheinargument>> Nein ist es nicht.
Vielleicht bist Du ja der Entwickler der eine Nische bedient?
Niemand hat Bock, sich ständig in neue/andere
> Controller einzuarbeiten.
Also Du hast keinen Bock, denn „Niemand“ hat hier nicht geschrieben.
Und Dein Bedarf oder Deine Kreativität sind Deine Erwartung, nicht
meine.
Und wenn Du mit der PIO nix anfangen kannst oder willst ist ja in
Ordnung. Aber wie wirbt ein Möbelhaus dessen Möbel angeblich niemand hat
oder braucht? „Entdecke die Möglichkeiten...“
Uwe D. schrieb:> temp schrieb:>> Aber eine ernsthafte Konkurenz zu bestehenden µCs wird das Ding nie im>> Leben werden.>> Da hast Du recht und liegst damit verbal auf der Linie von Bill Gates,> dessen Sprüchlein wohl fast jeder kennt: „Niemand braucht mehr als 640> Kilobyte Arbeitsspeicher in seinem PC.“
Und da jeder diesen Spruch kennt, brauchst du den nicht zu wiederholen.
Und dann nimmst du mal einen Apfel und eine Birne und versuchst mal zu
erkunden ob es da einen Unterschied gibt.
temp schrieb:> Uwe D. schrieb:>> temp schrieb:........>> dessen Sprüchlein wohl fast jeder kennt: „Niemand braucht mehr als 640>> Kilobyte Arbeitsspeicher in seinem PC.“>> Und da jeder diesen Spruch kennt, brauchst du den nicht zu wiederholen.> Und dann nimmst du mal einen Apfel und eine Birne und versuchst mal zu> erkunden ob es da einen Unterschied gibt.
Um in Deinem Stil zu bleiben: Da ja alle Wissen dass Äpfel und Birnen
Obst sind....
Ehrlich gesagt kann ich in Deinen Kopf nicht reinschauen und erkennen,
was Du damit meinst. Und dazu noch mit absolutem Anspruch formuliert.
Deshalb ist Deine Aussage für mich „nur“ eine Verallgemeinerung.
Soviel zu den Äpfel und Birnen.
Jack V. schrieb:> Die Frage, die sich mir stellt: hast du Angst vor’m RP2040/Pico, oder> warum versuchst du krampfhaft, den als Schrott hinzustellen, und den> Leuten, die’s gut finden, zu erzählen, dass sie doof wären?
Umgedreht wird ein Schuh draus, hier wird auf denen herumgehackt die
darin nicht die 5. industrielle Revolution sehen:
Martin schrieb:> Es ist jedoch so, dass du und die anderen> Bastler/Nörgler hier im Thread nicht über das Wissen und das Können> verfügen, um den Raspberry Pico zu beurteilen
Solche Sprüche sind absolut arrogant und können nur von dummen Menschen
kommen.
Warum sollte ich vor dem Ding Angst haben? Meine jetzigen und kommenden
Projekte kriege ich auch ohne diese Weltneuheit hin, und bleibe trotzdem
nicht im Gestern stehen weil andere Hersteller auch nicht schlafen.
Klar, wenn sich einer seine Zeit damit vertreibt Sachen auf dem Ding zu
implementieren die keiner braucht, soll er machen. Dann gehts
vordergründig um Anerkennung oder das Erfolgserlebnis es hingekriegt zu
haben. Ein echter Freak vor dem sich alle verbeugen. Alles Ok. Aber das
ist dann die Nische die der PICO bedient und ist keinesfalls als
Konkurenz zu normalen Cortexen zu sehen.
Ich finde es amüsant wie hier einige Leute gegen solche einfachen
Plattformen wettern. Weil plötzlich Menschen ohne jahrelange Erfahrung
und ohne hunderte Euro für IDE und Programmer auszugeben, ihren
WLAN-Sensor oder andere Spielereien bauen können.
Dabei ist es doch so, daß solche Umgebungen wie der Pico oder Arduino
eher etwas wie Lego sind. Einfach zu nutzen, einfach nachzubauen und
mancher Kreative schafft damit echte Kunstwerke. Trotzdem ist das doch
keine Bedrohung für "echte" Modellbauer.
Zurück zum Thema: ich finde es etwas schade, dass versucht wird eine
Umgebung parallel zu Arduino aufzubauen. Solche Fragmentierung sehe ich
für die Nutzer eher als Nachteil. Außerdem bin ich sicher, die ESPs zum
Beispiel verdanken die große Verbreitung auch der einfachen Integration
in die bestehende Umgebung.
temp schrieb:> mgedreht wird ein Schuh draus, hier wird auf denen herumgehackt die> darin nicht die 5. industrielle Revolution sehen:
Der Beitrag, der von der nächsten industriellen Revolution handelte, war
für mich nicht auffindbar.
temp schrieb:> Warum sollte ich vor dem Ding Angst haben?
Weiß nicht. Warum haust du denn mit dieser Vehemenz drauf, auf dass es
sich ja nicht ausbreiten möge? Vielleicht, weil doch etwas mit
ThomasW schrieb:> Weil plötzlich Menschen ohne jahrelange Erfahrung> und ohne hunderte Euro für IDE und Programmer auszugeben, ihren> WLAN-Sensor oder andere Spielereien bauen können.
zu tun hat?
ThomasW schrieb:> ich finde es etwas schade, dass versucht wird eine> Umgebung parallel zu Arduino aufzubauen. Solche Fragmentierung sehe ich> für die Nutzer eher als Nachteil.
Hm … Einerseits adaptiert Arduino den RP2040 vermutlich sehr bald
(irgendwer hatte dazu schon was verlinkt), auf der anderen Seite hat
Arduino gewisse Nachteile, gerade weil sie durch die weitgehende
Gleichschaltung der spezifischen Plattformen deren
Herausstellungsmerkmale maskieren. Wer mag, dürfte das Ding also recht
bald auch mit Arduino beschicken können, für die anderen gibt’s den
nativen Weg. Wie etwa auch bei den AVRs.
Jack V. schrieb:> Der Beitrag, der von der nächsten industriellen Revolution handelte, war> für mich nicht auffindbar.
Das bezieht sich auf diese Aussage:
chris_ schrieb:> Beim PiPico werden so viele echte Freaks die Hardwarekombination aus> Dual-Core/Sio/Pio/MPU ausnutzen, dass kein anderer Mikrocontroller> mitkommt.
Und was ist es sonst als eine Revolution wenn kein anderer µC mitkommt?
ThomasW schrieb:> Zurück zum Thema: ich finde es etwas schade, dass versucht wird eine> Umgebung parallel zu Arduino aufzubauen. Solche Fragmentierung sehe ich> für die Nutzer eher als Nachteil. Außerdem bin ich sicher, die ESPs zum> Beispiel verdanken die große Verbreitung auch der einfachen Integration> in die bestehende Umgebung.
Spätestens wenn das Ding Arduino kompatibel ist wird es enden wie bei
ESP. Man kann sicher viele schöne Sachen auch ohne Arduino machen, aber
für 99,9% ist ESP und Arduino untrennbar. Das sieht man an den Projekten
auf GitHub. Ich habe ja auch kein Problem damit. Nur den Hype darum kann
ich nicht verstehen.
temp schrieb:> Und was ist es sonst als eine Revolution wenn kein anderer µC mitkommt?
Die richtige Frage wäre gewesen: wie lässt sich da was von „5.
industrielle Revolution“ rauslesen?
Abgesehen davon gibt’s wohl tatsächlich nicht zuviele andere
Microcontroller mit zwei Kernen, oder?
Jack V. schrieb:> Die richtige Frage wäre gewesen: wie lässt sich da was von „5.> industrielle Revolution“ rauslesen?
Was denkst du warum ich das in Hochkommas gesetzt habe? Bestimmt nicht
um diese Worte auf die Goldwage zu legen. Leute gibts...
Was ist an den zwei Kernen eigentlich so genial, dass man darauf herum
reiten muss?
Wer seine Anwendungen nicht auf einem Kern umgesetzt bekommt, der wird
auch mit zwei Kernen schnell an die selben Grenzen kommen. Was ist, wenn
man mehr als zwei Threads ausführen muss? Dann kommt man doch wieder auf
einen Methode zurück, die ebenso auf einem Kern laufen würde.
Stefan ⛄ F. schrieb:> Was ist an den zwei Kernen eigentlich so genial, dass man darauf> herum> reiten muss?>> Wer seine Anwendungen nicht auf einem Kern umgesetzt bekommt, der wird> auch mit zwei Kernen schnell an die selben Grenzen kommen. Was ist, wenn> man mehr als zwei Threads ausführen muss? Dann kommt man doch wieder auf> einen Methode zurück, die ebenso auf einem Kern laufen würde.
Beim RP2040 ist das vielleicht nicht so offensichtlich, aber gerade bei
den Controllern im Funkbereich wie dem ESP8266 oder den einkernigen
NRF-Bluetooth-Controllern ist das ziemlich offensichtlich.
Du weisst doch selber, welche Umstände der ESP8266 manchmal bereitet,
wenn man den Watchdog umgehen muss. Ähnliches gilt für die
NRF-Controller.
Bei zwei Kernen hat man das Problem nicht mehr. Das ist auch der Grund,
warum in letzter Zeit einige Hersteller M4/M0(+)-Controller
herausgebracht haben, auf denen der M0(+) den Funkteil abarbeitet und
der M4 für die eigentliche Applikation zuständig ist.
Ich verstehe den Hickhack hier nicht!
Klar gibt es Controller die CAN haben. Manche sogar mehrere.
Trotzdem verkaufen sich auch Controller ohne.
Es gibt schnellere Mikrocontroller. Und langsamere.
Controller mit mehr Speicher. Und mit weniger.
Flash im Chip oder nicht. Und so weiter.
Für die Wahl ist doch immer das Gesamtpaket entscheidend:
a) konkrete Anforderungen an Schnittstellen, Speicher, Performance, ...
b) Dokumentation
c) Toolchain (Sprachen, Compiler, IDE, ...)
d) Herstellersupport (auch für Toolchain, HAL, Libs, ...)
e) Community-Support, Bibliotheken, ...
f) Kosten für Hardware & Tools
g) und ganz wesentlich: mit was habe ich Erfahrung/kenne ich mich aus?
Wie viel Einarbeitung kostet das? Lohnt sich das für die Zukunft?
vielleicht habe ich noch irgendeinen Punkt vergessen, die Kernaussage
ist aber klar.
Und wenn ich den Raspberry Pico an dieser Skala messe, kommt ein
Ergebnis raus, bei dem ich durchaus Marktpotential sehe.
Konkret:
a) ja, kann kein CAN. Senden wird man man mit den PIOs hingepfuscht
bekommen, aber das wird nie fliegen. Bei der restlichen Hardware gibt
es in allen Dimensionen Controller drüber und drunter. Aber dank Pio
gibt es viel Flexibilität: Wie viele Controller gibt es am Markt, die
z.B. 4 I2C-Ports könnten? Oder 4 UARTs? Gut, das braucht man selten,
aber CAN braucht man auch nicht immer (außer temp).
b) konkurrenzfähig, da gibts schlechtere.
c) Python und C/C++, kein Programmer. Debugging über SWD. Z.B. mit einem
Raspi, d.h. auch ohne Spezialtool.
d) Python und C/C++ vom Hersteller, mit guter Doku. (Getting started,
Beispielcode)
e) wird dank des prominenten Namens vermutlich bald da sein.
f) 4€ für Hardware, Tools kostenlos. Da gibt es für jede Stückzahl
teurere und billigere.
g) Tja. Langjährige Erfahrung hat damit im Moment keiner. Und zumindest
temp sieht die Einarbeitung als nicht lohnend an. Andererseits ist es
ein ARM, also nix völlig esoterisches. Wenn man dann doch mal einen STM
(mit CAN) braucht, wird nicht alles was man gelernt hat entwertet.
Zusammengefasst:
Wenn man engstirnig ist: Absolute Krücke, null Marktchancen!
Für alle anderen: Gutes Gesamtpaket, wird sich millionenfach verkaufen.
Und wie für alle Mikrocontroller gilt: man man viel damit machen, für
manche Probleme braucht man aber einen anderen. Und wenn man sich in
einer anderen Controllerfamilie gut auskennt kommt man vermutlich in der
schneller zum Ziel.
> Was ist an den zwei Kernen eigentlich so genial, dass man darauf herum> reiten muss?
Du hast schon recht, der zweite Kern ist nur dann wirklich nützlich wenn
er mehr machen soll als nur Daten herum zu kopieren, das kann DMA
bereits wunderbar. Ich könnte mir vorstellen, dass man ihn bei Projekten
mit Bildschirmausgabe als Grafik und Sound Co-Prozessor nutzen würde:
Command Buffer in die Warteschlange rein => Pixel- und Soundbuffer
werden vom zweiten Kern gefüllt, während die Logik auf dem ersten Kern
weiter läuft.
Oder ein RTOS drauf laufen lassen und dem User die Option geben da seine
Threads drauf zu knallen ohne groß nachdenken zu müssen, der ESP32 macht
das ja schon standardmäßig so, soweit ich das mitbekommen habe.
Florian S. schrieb:> ch könnte mir vorstellen, dass man ihn bei Projekten> mit Bildschirmausgabe als Grafik und Sound Co-Prozessor nutzen würde
Oder wie "Planloser" schrieb: Bei WLAN/Bluetooth. Doch all das hat
dieser Raspberry Pi Pico nicht.
Sicher ist ein zweiter CPU nicht nutzlos. Nur empfinde ich ihn
ausgerechnet bei diesem Board nicht gerade als das super-duper Feature,
weswegen ich es kaufen würde.
Was mich momentan ein bisschen daran stört, ist die Art und Weise wie
die Programme auf das Board hochgeladen werden. "Maus-Artisten" werden
ihre Freude dran haben, wer wie ich am liebsten alles über die
Kommandozeile macht und automatisiert, ist darüber eher weniger
glücklich.
Das fand ich damals schon beim MBED Board nervig. Da zumindest SWD
vorhanden ist, wird es vielleicht der nächste Kandidat für meinen
Universalprogrammer.
Eine Art "Board-Standard" mit minimaler Zusatzhardware finde ich
eigentlich gut auch wenn der Wildwuchs wohl nicht lange auf sich warten
lassen wird. Bei meinen Projekten mit STM32 habe ich eigentlich jedes
mal Anfragen bekommen, ob das auf Board X läuft oder ob ich es an Board
Y anpassen kann.
Dass jetzt z.B. CAN und Timer mit Capture fehlen, finde ich nicht so
schlimm. Es gibt genügend Anwendungen, die ohne auskommen. Für die
meisten Anwendungen jenseits von Bastelei ist es aber ein No-Go, wenn
(so wie ich es verstanden habe) jegliche Möglichkeiten der Readout- und
Overwrite-Protection fehlen. Beim ESP32 lässt sich der ganze Kram ja
zumindest verschlüsseln.
Jörg
Joerg W. schrieb:> Was mich momentan ein bisschen daran stört, ist die Art und Weise wie> die Programme auf das Board hochgeladen werden. "Maus-Artisten" werden> ihre Freude dran haben, wer wie ich am liebsten alles über die> Kommandozeile macht und automatisiert, ist darüber eher weniger> glücklich.
Hm. Ich bin nun alles Andere, als ein „Mausartist“, und ich finde genau
diesen Punkt einladend – er ist scriptbar.
Auf der anderen Seite kann man das Ding wohl auch via SWD beschicken, so
dass man es gerne auch umständlich haben kann, wenn man das denn lieber
mag ;)
> Was mich momentan ein bisschen daran stört, ist die Art und Weise wie> die Programme auf das Board hochgeladen werden.> [...] über die Kommandozeile macht und automatisiert,
So wie ich das sehe, reicht ein "dd if=file.uf2 of=/dev/sdXX" aus.
Ich habe allerdings den Eindruck, dass man sich vorher selbst darum
kümmern muß, dass er überhaupt in den Bootloader kommt ... muß man wohl
irgendwas in sein Firmware einbauen, damit die den Bootloader startet.
foobar schrieb:
> So wie ich das sehe, reicht ein "dd if=file.uf2 of=/dev/sdXX" aus.
Wohl eher nicht. Wie ich das lese, muss man das Teil mit gedrücktem
BOOTSEL Taster an den Computer anschließen und dann mounten:
- Download the Blink UF2
- Push and hold the BOOTSEL button and plug your Pico into the USB port
of your Raspberry Pi or other computer.
- It will mount as a Mass Storage Device called RPI-RP2.
- Drag and drop the Blink UF2 binary onto the RPI-RP2 volume.
- Pico will reboot, and the on-board LED should start blinking.
also eher:
1
sudo mount /dev/sdc /mnt/picopi
2
cp file.uf2 /mnt/picopi/
3
sync
4
sudo umount /mnt/picopi
Da das Teil nach dem sync rebootet, kann es je nach Timing auch
passieren, dass das umount fehlschlägt und das Board nächstes mal unter
/dev/sdd erscheint. Das ist mir damals beim MBED nicht nur einmal
passiert.
Über SWD wird es sicher etwas langsamer gehen, aber aus meiner Sicht
weniger umständlich.
Jörg
> Wohl eher nicht. Wie ich das lese, muss man das Teil mit gedrücktem> BOOTSEL Taster an den Computer anschließen und dann mounten:
Deshalb schrieb ich ja:
"Ich habe allerdings den Eindruck, dass man sich vorher selbst darum
kümmern muß, dass er überhaupt in den Bootloader kommt ... muß man wohl
irgendwas in sein Firmware einbauen, damit die den Bootloader startet."
Evtl hab ich aber auch was übersehen und man kann Bootloader jederzeit
vom Host triggern.
> also eher:> sudo mount /dev/sdc /mnt/picopi> ...
Wenn du erstmal das /dev/sdX hast, ist das Mounten und Kopieren per
Filesystem unnötig. Du musst ihm nur die UF2-Datei irgendwie schicken
(z.B. per dd), das reicht ihm[1]. Das FAT-FS ist nur dazu da, dass man
das ohne Extratool per Drag-n-Drop machen kann.
[1] Der schaut in jeden Block, den er per Write bekommt (egal für welche
Block-Nummer, die wird ignoriert), ob der Daten einer UF2-Datei enthält.
Wennn ja, wird er als Upload-Block interpretiert, wenn nicht wird er
sang-und-klanglos weggeschmissen. Wenn er alle Blöcke einer UF2-Datei
bekommen und bearbeitet hat (jeder einzelne Block enthält genug Infos,
dass er das feststellen kann), macht er nen Reset. Ansonsten wartet er
einfach weiter auf den nächsten Block.
PS: Ich hab noch keinen Raspico, also noch nicht ausprobiert. Das ist
das, was ich den Sourcen des Bootloaders entnehmen konnte.
Nur zur Info:
> 1 sudo mount /dev/sdc /mnt/picopi> 2 cp file.uf2 /mnt/picopi/> 3 sync> 4 sudo umount /mnt/picopi
Ich hab mir angewöhnt, bei FAT-Wechelmedien, wo ich nur kurz was drauf
machen will, statt solcher Orgien einfach die mtools zu benutzen. Ein
"mcopy files... x:" reicht dann aus.
foobar schrieb:> Wenn du erstmal das /dev/sdX hast, ist das Mounten und Kopieren per> Filesystem unnötig. Du musst ihm nur die UF2-Datei irgendwie schicken> (z.B. per dd), das reicht ihm[1].> […]> PS: Ich hab noch keinen Raspico, also noch nicht ausprobiert.
Wenn sich bis heute abend keiner gefunden hat, kann ich das gerne mal
ausprobieren. Das würd’s ja in der Tat noch etwas einfacher machen.
Zu der anderen Sache: wenn sich der Bootloader im ROM nicht im Betrieb
aufrufen lässt, kann man sicher eine Art „second stage bootloader“
reintun. Wenn’s sowas noch nicht gibt, gibt’s das bestimmt auch bald.
Ansonsten ist es, wie geschrieben, auch möglich, den SWD-Port zum
Beschicken des Picos herzunehmen.
> Zu der anderen Sache: wenn sich der Bootloader im ROM nicht im Betrieb> aufrufen lässt,
Das ROM stellt schon eine Funktion "_reset_to_usb_boot" zur Verfügung.
Allerdings muß dazu das Programm ordentlich laufen, damit es die auch
aufrufen kann. Wenn das Programm abgesemmelt ist ...
Joerg W. schrieb:> Da das Teil nach dem sync rebootet, kann es je nach Timing auch> passieren, dass das umount fehlschlägt und das Board nächstes mal unter> /dev/sdd erscheint.
Einfach mit der "force" Option unmounten.
foobar schrieb:> PS: Ich hab noch keinen Raspico, also noch nicht ausprobiert.
Ingrid: Funktioniert grundsätzlich mit dd direkt auf das Device,
hinterlässt aber durch sein unsauberes Verschwinden wenig hübsche
Logeinträge:
> Funktioniert grundsätzlich mit dd direkt auf das Device,
Fein.
> blk_update_request: I/O error, dev sdb, sector 261881 op 0x0:(READ)
Hmm... das kommt aber nicht vom dd - da versucht jemand anderes von dem
Gerät zu lesen (hohe Blocknummer, letzte Block des Geräts?). Könnte
sein, dass da versucht wird, die Partitiontable zu aktualisieren.
Probier's doch mal mit /dev/sdb1 statt /dev/sdb.
Falls mir jemand ein Pi Pi Board zukommen laesst, wuerde ich versuchen,
den RP2042 ueber SWD in Blackmagic zu implementieren. Wenn er
irgendwann mal irgendwo verfuegbar ist wo ich sowieso bestellen muss,
dann werde ich ihn aber auch selber kaufen.
PS: Warum soll SWD langsamer sein als U2F?
Ist der RP2040 (RPI Pico) ein Von-Neumann Rechner?? Ich kann dazu
nämlich absolut nichts in den Docs finden. Falls nicht, wie würde könnte
man Daten persistent ohne der vorhandenen EEPROM Speichern. Ich danke
schonmal :D
jackv schrieb:
>>/dev/sdb1 statt /dev/sdb.>> Das sieht recht ähnlich aus:> sd 2:0:0:0: [sdb] tag#0 CDB: Read(10) 28 00 00 00 02 09 00 00 f0 00> blk_update_request: I/O error, dev sdb, sector 521 op 0x0:(READ)> usb 1-3.1.4: USB disconnect, device number 10> sd 2:0:0:0: [sdb] tag#0 CDB: Read(10) 28 00 00 00 02 f9 00 00 10 00> blk_update_request: I/O error, dev sdb, sector 761 op 0x0:(READ)
Das sieht nicht mehr nach Partitionstable einlesen aus (read 240 blocks
from 521, read 16 blocks from 761). Irgendwer grätscht da rein - kann
es sein, dass da irgendein Automounter läuft, oder udev irgendwelchen
Mist macht? Solche Fehlermeldungen mag ich nicht ...
Meme schrieb:> Ist der RP2040 (RPI Pico) ein Von-Neumann Rechner?? Ich kann dazu> nämlich absolut nichts in den Docs finden.
Löse dich mal von der Vorstellung der Von-Neumann versus Harvard
Architektur. Diese ist genau so unangemessen geworden, wie die
Rassentrennung bei Menschen.
Denn wie auch bei den Menschen sind die meisten Mikrocontroller weder
das eine noch das andere. Sie enthalten Aspekte von beiden
Architekturen.
Zu jedem Mikrocontroller gibt es Dokument, dass die Architektur der
Busse und des Memory-Mappings beschreibt. Das ist nicht immer das
Datenblatt.
Bei STM32 findest du so etwas z.B. eher im Referenzhandbuch im Kapitel
"System and Memory Overview".
foobar schrieb:> Irgendwer grätscht da rein - kann> es sein, dass da irgendein Automounter läuft, oder udev irgendwelchen> Mist macht? Solche Fehlermeldungen mag ich nicht ...
udev/udisk hatte ich im Verdacht, Automounter läuft hier nicht.
Allerdings fehlen mir in dem Bereich die Kenntnisse, um da effektiv auf
die Suche zu gehen – hab ich mich nie groß mit beschäftigen müssen.
Wenn du Sachen hast, die ich ausprobieren soll, kann ich das aber gerne
tun.
Stefan ⛄ F. schrieb:> Meme schrieb:>> Ist der RP2040 (RPI Pico) ein Von-Neumann Rechner?? Ich kann dazu>> nämlich absolut nichts in den Docs finden.>> Löse dich mal von der Vorstellung der Von-Neumann versus Harvard> Architektur. Diese ist genau so unangemessen geworden, wie die> Rassentrennung bei Menschen.>> Denn wie auch bei den Menschen sind die meisten Mikrocontroller weder> das eine noch das andere. Sie enthalten Aspekte von beiden> Architekturen.>> Zu jedem Mikrocontroller gibt es Dokument, dass die Architektur der> Busse und des Memory-Mappings beschreibt. Das ist nicht immer das> Datenblatt.
Also wie man jetzt auf diesen völlig unangemessenen Vergleich mit Rassen
kommen kann, entzieht sich völlig meiner Kenntnis. Massiver
Schlafmangel?
Was den RP2040 angeht, so steht die Systemarchitektur ganz simpel unter
"Bus Fabric" im Datasheet, da muss man nicht über den STM32
spekulieren... ("eher").
> udev/udisk hatte ich im Verdacht, Automounter läuft hier nicht.> [...]> Wenn du Sachen hast, die ich ausprobieren soll, kann ich das aber> gerne tun.
Das wird über's Forum zu umständlich. Ich werde das rausklamüsern, wenn
ich einen hier habe - dann habe ich auch eine bekannte Testumgebung.
Bzgl Neumann vs Harvard: das einzige, was da heutzutage noch relevant
ist, ist das Programmiermodell bzgl der Adressräume - getrennte bei
Harvard, einer bei von Neumann. Von der Position aus, ist ARM (und
damit der RP2040) eine von-Neumann-Architektur, AVR und PIC sind
Harvard.
Die Implementation ist oft ein Misch-Masch aus beidem; verschiedene
Implementationen der gleichen CPU können vollkommen unterschiedliche
Wege gehen - die schwarz/weiß-Malerei ist eine veraltete Vorstellung.
Sie entstand, als HW eine kostbare Resource und sehr einfach gestrickt
war. Heutzutage hat ein einzelner UART-Block mehr Gatter als eine 6502,
eine x86-CPU wohl mehr Register als der C64 RAM.
> Das hilft mir leider immer noch nicht weiter. Kann sich der Flash> Speicher selbst überschreiben?
Das ist bei der Frage irrelevant. Wenn überhaupt, fragt man, ob die CPU
Code aus dem RAM heraus ausführen kann - wenn sie das nicht kann, ist
das ein Indiz auf eine Harvard-Architektur. Das war's aber auch schon.
So, ich habe jetzt einmal mit dem Teil "gespielt" weil ich ja immer von
allem "neuen" fasziniert bin und ja eventuell etwas für mich dabei ist.
Außerdem ist der Preis für ein M0-Mikrocontrollerboard ja wirklich
absolut gering.
Da ich nicht wirklich ein Freund von Python bin, wollte ich mir das SDK
für C-Programmierung installieren.
Damit fingen da die Probleme an.
Auf einem RaspBerry PI 3 funktionierte das Installieren
(erwartungsgemäß) sofort und einfach, aber ich möchte sicherlich nicht
ein Mikrocontrollerboard mit einem Raspberry Pi programmieren.
Dann wollte ich eine Installation auf einem Slackware-Linux haben und
das lief dann nicht so gut ab (bzw. hat nicht funktioniert).
Also dann den einzigen XUBUNTU-Rechner hergenommen => hat funktioniert.
Die Installation hab ich protokolliert und die Schritte die notwendig
sind auf den Slackware übertragen und dann ging es auch auf Slackware.
Das SDK finde ich nicht so wirklich gelungen und das, was an sich ein
Vorteil seien soll: Übertragen des Microcontrollercodes in das Flash via
dem Massenstorage Device ist nicht so wirklich klasse, weil es (gefühlt)
ewig dauert, bis das Board den Code ausführt (was wohl bedeutet. dass
das eigentliche interne Flashen nicht so wirklich flott ist).
Ich habe jetzt zwar keine Zeit gestoppt, aber selbst ein einfaches
kleines Programm mit einer Größe von knapp über 10 kByte hat gefühlt 1
Minute gedauert bis das auf dem Board angelaufen ist.
Als Ergebnis für mich: Ich werde das Board wohl nicht für eigene
Entwicklungen benutzen.
Schade.
Mal sehen, vllt. gibts ja bald (wie auf Pimoroni bereits zu sehen)
Bastelanleitungen für eine kleine Spielekonsole oder (was mich mehr
interessieren würde) aufgrund des vielen vorhandenen Rams eine schöne
CP/M Emulation darauf.
> Das SDK finde ich nicht so wirklich gelungen
Jo, so ganz begeistert bin ich auch nicht - fängt beim cmake an ...
Ist aber zumindest ne Basis.
Eine Sache, die mir aufgestoßen ist: dadurch, dass Programme bei Offset
256 im Flash anfangen, muß jedes Programm für einen spezifischen
Flash-Baustein gelinkt werden[1]. Sollte bei Offset 4096 (erase size)
anfangen, dann könnte man den bereits vorhanden einfach so lassen wie er
ist.
> Ich habe jetzt zwar keine Zeit gestoppt, aber selbst ein einfaches> kleines Programm mit einer Größe von knapp über 10 kByte hat gefühlt 1> Minute gedauert bis das auf dem Board angelaufen ist.
Kommt mir lang vor - ich hab zwar immer noch keinen, aber in Videos, die
ich gesehen hab, ging das Installieren von Python innerhalb von ein paar
Sekunden.
> ... oder (was mich mehr interessieren würde) aufgrund des vielen> vorhandenen Rams eine schöne CP/M Emulation darauf.
Hehe. Das hatte ich mir als erstes Projekt vorgenommen, wenn ich dann
mal einen hab ;-)
[1] Ich denke, ich hab den Code richtig interpretiert.
Ich schrieb:
> dann könnte man den bereits vorhanden einfach so lassen wie er ist.
Merke gerade, dass das was verloren gegangen ist - ich spreche von dem
stage2-bootloader.
Ralph S. schrieb:> Dann wollte ich eine Installation auf einem Slackware-Linux haben und> das lief dann nicht so gut ab (bzw. hat nicht funktioniert).
Das ist eigentlich vollkommen generisch. Woran hing es denn?
Ralph S. schrieb:> was an sich ein> Vorteil seien soll: Übertragen des Microcontrollercodes in das Flash via> dem Massenstorage Device ist nicht so wirklich klasse, weil es (gefühlt)> ewig dauert, bis das Board den Code ausführt (was wohl bedeutet. dass> das eigentliche interne Flashen nicht so wirklich flott ist).> Ich habe jetzt zwar keine Zeit gestoppt, aber selbst ein einfaches> kleines Programm mit einer Größe von knapp über 10 kByte hat gefühlt 1> Minute gedauert bis das auf dem Board angelaufen ist.
Das liegt eher am Caching. Du könntest es mal mit ›sync‹ versuchen,
danach ist das Ding innerhalb von Millisekunden weg, und das Programm
läuft.
Jack V. schrieb:> Das ist eigentlich vollkommen generisch. Woran hing es denn?
grundsätzlich erst einmal daran, dass Slackware kein "apt-get" kennt.
Also habe ich das Installations-Script händisch nachvollzogen.
Aber wie gesagt, das ging dann eben doch, nachdem ich wußte, was bei
einem XUBUNTU alles "passiert" und habe das dann eben in einzelnen
Schritten von Hand gemacht (wie gesagt, danach gings dann eben auch).
Jack V. schrieb:> Das liegt eher am Caching. Du könntest es mal mit ›sync‹ versuchen,> danach ist das Ding innerhalb von Millisekunden weg, und das Programm> läuft.
Das werde ich heute Abend einmal ausprobieren, mittels >cp< und
anschließendem >sync< ob es dann besser ist.
;-) es ist nicht immer von Vorteil, einer der ersten zu sein, der etwas
neues ausprobiert!
Ralph S. schrieb:> grundsätzlich erst einmal daran, dass Slackware kein "apt-get" kennt.
Ja gut … man sollte das Paketmanagement seiner Distri schon bedienen
können ;)
Unter Arch gibt’s auch kein Debian-Paketmanagement – trotzdem kann ich
mich nicht an Probleme mit der Installation des SDK erinnern. Das habe
ich einfach via ›git‹ von github geholt, wie’s im „Getting Started“-PDF
beschrieben wird.
Ralph S. schrieb:> es ist nicht immer von Vorteil, einer der ersten zu sein, der etwas> neues ausprobiert!
Doch. Man kann dabei viel lernen.
Jack V. schrieb:> ich einfach via ›git‹ von github geholt, wie’s im „Getting Started“-PDF> beschrieben wird.
... das ... habe ich dann auch gemacht! ;-)
(wäre halt schön gewesen, wenn das Script das in "getting-started"
angeboten wird auch auf Nicht-Debian-Systemen gleich funktioniert
hätte).
Jack V. schrieb:> Doch. Man kann dabei viel lernen.
Da kann man nicht nur "viel lernen", da muß man dann wieder "viel"
lernen, bzw. umdenken.
Und hier bin ich nun gezwungen, mich mit dem cmake auseinander zu setzen
(wo ich doch eigentlich nur >make< machen möchte).
Ich werde wohl lernen (mühselig), wie ich das für mich am besten so
hingebogen bekomme, wie es mir am besten liegt.
Ralph S. schrieb:> Und hier bin ich nun gezwungen, mich mit dem cmake auseinander zu setzen> (wo ich doch eigentlich nur >make< machen möchte).
Es verbietet dir ja keiner, deine eigenen Makefiles zu basteln und das
gammelige alte GNU make zu verwenden ;)
Sei mal froh, dass sie nicht mit was gekommen sind, das noch viel mehr
fancy bloat ist …
;-) im Moment bin ich ja auch satt am "basteln" und am evaluieren wie
dieses SDK "tickt".
Allerdings ist im Moment etwas anderes nervig und vllt. hast du ja einen
Tip für mich.
Nachdem nun der Upload in den pico wirklich sehr flott geht (sync war
oben ein gutes Stichwort) habe ich das Problem, dass es mich "ärgert"
für einen Upload den USB-Stecker zu ziehen und mit gedrückter
Bootsel-Taste wieder einzustecken. Für den Moment habe ich mir beholfen
mit einem Miniaturgehäuse, in dem ein 4-Fach Öffnertaster die
USB-Leitungen unterbricht um dann den pico mit gedrückter Bootsel-Taste
neu zu verbinden..
Das geht doch aber bestimmt eleganter und ich glaube sehr, dass ich
irgendwo in der Doku etwas überlesen habe, oder ?
> für einen Upload den USB-Stecker zu ziehen und mit gedrückter> Bootsel-Taste wieder einzustecken.> ...> Das geht doch aber bestimmt eleganter und ich glaube sehr, dass ich> irgendwo in der Doku etwas überlesen habe, oder ?
Ich denke nicht, zumindest hab ich auch noch nichts gefunden.
Was gehen sollte, wäre, einen Reset-Taster zwischen Pin 30 und GND zu
hängen. Wäre allerdings immer noch manuell, nicht vom Host aus.
foobar schrieb:> Was gehen sollte, wäre, einen Reset-Taster zwischen Pin 30 und GND zu> hängen. Wäre allerdings immer noch manuell, nicht vom Host aus.
Nicht zu fassen, die haben sogar den Reset Taster weg gelassen - es gibt
micht einmap Pads zum nachrüsten. So etwas gehört aber an jedes
Entwicklungsboard. Offenbar kam es da auf jeden Cent an. Billig billig
billig. Funktion ist zweitrangig.
Stefan ⛄ F. schrieb:> die haben sogar den Reset Taster weg gelassen
Hat mich auch gewundert, zumal das Gerät ja nach dem Draufkopieren des
Programms nicht mehr in den Massenspeichermodus zum schnellen
Draufschieben der nächsten Version versetzt werden kann, ohne es ab- und
wieder dranzustecken (oder einen Taster in der USB-Versorgungsleitung zu
betätigen). Auf der anderen Seite steht halt eben genau der Preis.
Da sparen wir also 3 Cent am Taster und nehmen im Gegenzug in Kauf, den
USB Stecker zu verhunzen. Was ist wohl am Ende Preisgünstiger?
Und wieso heißt der Reset-Eingang RUN? Wollten die mal etwas anders
machen, als der Rest der Welt?
Ehrlich: Solche Produkte will ich nicht haben.
Ich denke mal, die rudimentäre Ausstattung des Pico-Boards soll den
anderen Herstellern eine Chance geben, "bessere" Boards zu machen - so
bekommt man die mit ins Boot. An dem Board selbst wird Raspberry nichts
verdienen, ist eher was zum anfixen ;-)
Was das Brennen angeht: das ROM dient wohl eher dazu, das Board
überhaupt ans Rennen zu bekommen und initialen Code zu installieren. Es
ist flexibel genug, andere Boot-Mechanismen zu implementieren, z.B.
einen Arduino-ähnlichen Stage3-Bootloader.
Für's Entwickeln scheint Raspberry eher das SWD-Interface vorgesehen zu
haben. Darüber kann man nicht nur debuggen, auch neue Firmware
einspielen, oder, wenn der Chip komplett vermurkst wurde (z.B. keine
Clock mehr), das Teil wieder zum Leben erwecken.
Also: ein fertiges UF2 installieren mittels Boot-Taster, entwickeln per
SWD-Port.
> Für's Entwickeln scheint Raspberry eher das SWD-Interface vorgesehen zu> haben. Darüber kann man nicht nur debuggen, auch neue Firmware> einspielen, oder, wenn der Chip komplett vermurkst wurde (z.B. keine> Clock mehr), das Teil wieder zum Leben erwecken.
Und wer einen zweiten PICO hat, kann den als SWD+UART-Adapter nutzen
(picoprobe). Wieso tut man sich das an mit dem USB Bootloader, wenn doch
SWD an Board ist? Wenn man eine IDE nutzt (Eclipse und VisualStudio Code
werden unterstützt) kann man mit einem Klick via OpenOCD uploaden und
debuggen. Die Ersteinrichtung ist leider etwas nervig, wahrscheinlich
sogar nervig genug, dass viele nicht auf SWD umsteigen obwohl sie auf
lange Sicht viel mehr Spaß damit haben würden. Finde ich etwas schade.
Jack V. schrieb:> Stefan ⛄ F. schrieb:>> Ehrlich: Solche Produkte will ich nicht haben.>> Das ist ganz prima: bleibt mehr für mich :)
Sehe ich genauso, mit dem kostenlosen pyCharm kann man problemlos ein
ganzes Projektverzeichnis für µPyton mit einem Klick (oder Hotkey!)
hochladen und der Softreset wird auch gleich ausgeführt.
chris_ schrieb:> Mich würden die Entwicklungskosten des PiPico interessieren. Nachdem was> ich so kenne, tippe ich mal auf ~10Millionen Euro maximal. Da sich auf> dem Prozessor nur quasi "Standardlogik" befindet und sich der gesamte> Prozessor auf einem FPGA testen lässt tippe ich mal auf 3> Maskendurchläufe bis zum fertigen Produkt.
Genaue Zahlen zu den Kosten werden zwar nicht verraten aber es gab
kürzlich beim AmpHour-Podcast ein Interview mit den Entwicklern und da
wurde unter anderem erwähnt, dass es nur zwei Revisionen bis zum
fertigen RP2040 gab. Die erste hatte noch Flash auf dem Die und dafür
weniger SRAM. Da man aber für Flash einen zusätzlichen Prozessschritt in
der Waferfertigung braucht haben sie den aus Kostengründen rausgeworfen
um ihn durch einen (größeren) SPI-Flash zu ersetzen und die
freigewordene Fläche kurzerhand mit zusätzlichem SRAM vollgestopft.
Der Die hat nur 2mm², so dass aus einem Wafer über 10k Chips
herauskommen. Packaging kostet mehr als der Die selbst.
Wer mehr darüber erfahren möchte hört sich am besten einfach den Podcast
an:
https://theamphour.com/529-embedded-hardware-with-the-raspberry-pi-team/
>Der Die hat nur 2mm², so dass aus einem Wafer über 10k Chips>herauskommen. Packaging kostet mehr als der Die selbst.
Ich habe mir den Podcast mal angehört. Er ist ziemlich lang .. ca. 90
Minuten.
Das mit den 2mm² habe ich verpasst. Das sind ja nur ca. 1.5mm
Kantenlänge und das inclusive der Pads für die Bonddrähte.
Wie ich es oben schon vermutet habe, wird die Stärke in der Software des
PiPico liegen. Sie haben davon gesprochen, einen Core als
USB-Schnittstelle zum debuggen des anderen Cores nutzen zu wollen. Das
ist ziemlich interessant, damit erhält man extrem günstiges Board mit
On-Board Debugger.
Hat jemand einen Link auf die C-Umgebung?
chris_ schrieb:> Sie haben davon gesprochen, einen Core als USB-Schnittstelle zum> debuggen des anderen Cores nutzen zu wollen.
Ja, stimmt, das ist auch noch ein sehr guter Punkt.
chris_ schrieb:> Das mit den 2mm² habe ich verpasst. Das sind ja nur ca. 1.5mm> Kantenlänge und das inclusive der Pads für die Bonddrähte.
Das ist so bei ca. 33:00. Es sind übrigens 20k Dice per Wafer, nicht nur
10k wie ich oben geschrieben hatte.
Raspberry-Pi-Pico.jpg
(230 KB)
