Forum: Mikrocontroller und Digitale Elektronik Raspberry Pi Pico: Mikrocontroller-Board mit Cortex M0+


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Andreas S. (andreas) (Admin) Benutzerseite


Angehängte Dateien:

Lesenswert?

Image:Raspberry-Pi-Pico.jpg

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
  • Programmierbare I/O (PIO) State Machines
  • USB-Massenspeicher-Boot-Modus

Daneben wurden noch einige weitere Boards mit dem RP2040 von Partnerfirmen angekündigt.

Bild: Raspberry Pi Foundation


: Bearbeitet durch Admin
von 100Ω W. (tr0ll) Benutzerseite


Lesenswert?

Heute wurde der Raspberry PI Pico vorgestellt. Der Pi hat die größe von 
einem Arduino Nano. Und als CPU einen RP2040.
https://www.heise.de/news/Raspbery-Pi-Pico-Mikrocontroller-Board-fuer-4-Euro-5030624.html
https://www.raspberrypi.org/blog/raspberry-pi-silicon-pico-now-on-sale/

von Tim  . (cpldcpu)


Lesenswert?

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.

: Bearbeitet durch User
von Frank (Gast)


Lesenswert?

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.

von Tim  . (cpldcpu)


Lesenswert?

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

: Bearbeitet durch User
von Kupfersau (Gast)


Lesenswert?

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.

von Gabriel misst in Gilbert (Gast)


Lesenswert?

Ich find die IO-Pin-Statemachine und den Support von MicroPython neben 
der (üblichen) gcc-toolchain gut.

von Hendrik L. (lbd)


Lesenswert?

Bietet ein ESP32 (mit WiFi etc.) nicht mehr (bei vergleichbarem Preis)?

Welche Gründe sprechn für den Pico ???

Gruesse

von Johannes S. (jojos)


Lesenswert?

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

von Gabriel misst in Gilbert (Gast)


Lesenswert?

Hendrik L. schrieb:
> Bietet ein ESP32 (mit WiFi etc.) nicht mehr (bei vergleichbarem Preis)?
>
> Welche Gründe sprechn für den Pico ???

Geringer Stromverbrauch, läuft mit 1V8, bastel-(Löt)freundlich, ...

https://www.heise.de/news/Raspbery-Pi-Pico-Mikrocontroller-Board-fuer-4-Euro-5030624.html

von Hendrik L. (hlipka)


Lesenswert?

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).

von Gabriel misst in Gilbert (Gast)


Lesenswert?

Johannes S. schrieb:
> Auf jeden Fall ein interessantes Teil, ein Datenblatt gibt es hier:
> https://datasheets.raspberrypi.org/rp2040/rp2040_datasheet.pdf

Umps, 600+ Seiten Datenblatt zu Registern und Modi, fast alles Tabellen, 
endlich mal ein Controller mit richtig fleisch ;-)

von User32 (Gast)


Lesenswert?

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.

von Mw E. (Firma: fritzler-avr.de) (fritzler)


Lesenswert?

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.

von oerks (Gast)


Lesenswert?

Ein M0+ kann nicht mal richtig 32 bit mit 32 bit multiplizieren.

> gibt es in deutlich besser von anderen Herstellern wie ST, NXP usw.

Richtig.

von Tim  . (cpldcpu)


Lesenswert?

Gabriel misst in Gilbert schrieb:
> Umps, 600+ Seiten Datenblatt zu Registern und Modi, fast alles Tabellen,
> endlich mal ein Controller mit richtig fleisch ;-)

Ich biete Dir 544 seiten für ein 30 cent Produkt, da gibts viel mehr 
Seiten fürs Geld.

https://ww1.microchip.com/downloads/en/DeviceDoc/ATtiny202-402-AVR-MCU-with-Core-Independent-Peripherals_and-picoPower-40001969A.pdf

Ist Seiten Datenblatt/Preis eine gute Metrik für die Kosteneffizienz von 
Microcontrollern?

von Mehmet K. (mkmk)


Angehängte Dateien:

Lesenswert?

Was Stromverbrauch anbelangt, habe ich nur etwas zu sleep gefunden. 
Standby scheint es nicht zu haben.

von Andreas B. (bitverdreher)


Lesenswert?

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.

: Bearbeitet durch User
von Meme (Gast)


Lesenswert?

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?

von Gabriel misst in Gilbert (Gast)


Lesenswert?

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.

von Operator S. (smkr)


Lesenswert?

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.

von Gabriel misst in Gilbert (Gast)


Lesenswert?

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.

von Alex D. (daum)


Lesenswert?

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.

von Alex D. (daum)


Lesenswert?

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

von Meme (Gast)


Lesenswert?

Kann man den Raspberry Pi Pico mit 3V betreiben lassen?

von Alex D. (daum)


Angehängte Dateien:

Lesenswert?

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.

von Alex D. (daum)


Lesenswert?

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

von Meme (Gast)


Lesenswert?

Vielen Dank für die schnelle Antwort!

von R2D2 (Gast)


Lesenswert?

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.

von Planloser (Gast)


Lesenswert?

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.

von Stefan ⛄ F. (stefanus)


Lesenswert?

Wenn ich "Raspberry Pi" lese, erwarte ich einen kleinen Minicomputer mit 
Linux. Das ist hier nicht der Fall.

von Alex D. (daum)


Lesenswert?

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.

von Pete K. (pete77)


Lesenswert?

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 :-)

: Bearbeitet durch User
von Operator S. (smkr)


Lesenswert?

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.

von Planloser (Gast)


Lesenswert?

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.

von interessierter (Gast)


Lesenswert?

Recht interessant das Board. Ein wenig schade, dass es keinen AD-Wandler 
integriert hat. Oder habe ich das übersehen?

von interessierter (Gast)


Lesenswert?

Ohje ich bin auch dusselig. Da steht ja:30 GPIO-Pins, davon 4 als 
Analogeingänge nutzbar.

Wie sind die Daten des AD-Wandlers?

von Alex D. (daum)


Lesenswert?

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

von Lothar (Gast)


Lesenswert?


von oerks (Gast)


Lesenswert?

> 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.

von Christopher J. (christopher_j23)


Lesenswert?

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.

von René F. (therfd)


Lesenswert?

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.

von Jack V. (jackv)


Lesenswert?

… unabhängig von den Hardwareeigenschaften: mussten sie’s wirklich so 
benennen, dass es sich am besten als „PiPi“ abkürzen lässt?

von Cihan S. (cihan_s)


Lesenswert?

Die können noch soviel vorstellen wie sie wollen.
Irgendwie ist bei denen nie was verfügbar oder der Preis verdoppelt 
sich.

von Jack V. (jackv)


Lesenswert?

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.

von Marco S. (masterof)


Lesenswert?

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 ?

Beitrag #6558528 wurde von einem Moderator gelöscht.
von Stefan ⛄ F. (stefanus)


Lesenswert?

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.

von C. A. Rotwang (Gast)


Lesenswert?


von OptimistPrime (Gast)


Lesenswert?

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!

von m.n. (Gast)


Lesenswert?

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 ;-)

von Jack V. (jackv)


Lesenswert?

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.”

von Tilo R. (joey5337) Benutzerseite


Lesenswert?

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.

von Mehmet K. (mkmk)


Lesenswert?

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.

von Uwe Bonnes (Gast)


Lesenswert?

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.

von BlaBla (Gast)


Angehängte Dateien:

Lesenswert?


von Planloser (Gast)


Lesenswert?

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.

von do-gooder (Gast)


Lesenswert?

Hallo,

Jack V. schrieb:
> … unabhängig von den Hardwareeigenschaften: mussten sie’s wirklich so
> benennen, dass es sich am besten als „PiPi“ abkürzen lässt?

Pipi rulez!
https://de.wikipedia.org/wiki/Pippi_Langstrumpf

von Jack V. (jackv)


Angehängte Dateien:

Lesenswert?

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 ;)

von Uwe Bonnes (Gast)


Lesenswert?

Jack V. schrieb:

> Ingrid: siehe Anhang. Verfügbarkeit ist also eindeutig gegeben ;)

Wo hattest Du bestellt?

von c-hater (Gast)


Lesenswert?

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...

von Jack V. (jackv)


Lesenswert?

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.

von foobar (Gast)


Lesenswert?

> [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.

von Marc Prager (Gast)


Lesenswert?

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!!!

von Rudolph R. (rudolph)


Lesenswert?

foobar schrieb:
> dürfte dem Arduino ziemlich die Suppe versalzen

Wie das wenn die von vornherein auf dem Hype-Train mitfahren dürfen?

von foobar (Gast)


Lesenswert?


von René F. (therfd)


Lesenswert?

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.

von Aaron (Gast)


Lesenswert?

Irreführende Werbung, Kundenverarsche, das Ding Raspberry Pi zu nennen.
Und für den Preis in Deutschland wohl nie erhältlich, wenn überhaupt 
lieferbar.

von Jack V. (jackv)


Lesenswert?

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.

von Johannes S. (jojos)


Lesenswert?

Aaron schrieb:
> Und für den Preis in Deutschland wohl nie erhältlich, wenn überhaupt
> lieferbar.

https://www.berrybase.de/detail/index/sArticle/7413#

Jack V. schrieb:
> siehe Anhang. Verfügbarkeit ist also eindeutig gegeben ;)

von Jack V. (jackv)


Lesenswert?

Offensichtlich ist die erste Rolle schon leer ;)

Ich bin ziemlich sicher, dass bald wieder welche da sein werden.

von Planloser (Gast)


Lesenswert?

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.

von Marco S. (masterof)


Lesenswert?

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+?

von Mw E. (Firma: fritzler-avr.de) (fritzler)


Lesenswert?

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?

von Marc Prager (Gast)


Lesenswert?

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.

von John Doe (Gast)


Lesenswert?

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.

von foobar (Gast)


Lesenswert?

> 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 ;-)

von Tilo R. (joey5337) Benutzerseite


Lesenswert?

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.

von Lothar (Gast)


Lesenswert?

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.

von foobar (Gast)


Lesenswert?

> 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.

von Tilo R. (joey5337) Benutzerseite


Lesenswert?

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.

von Mike J. (emjey)


Lesenswert?


von chris_ (Gast)


Lesenswert?

Da der PI Pico keinen DA-Wandler hat, wäre es interessant eine 
Sigma-Delta-Modulator mit der PIO bauen zu können.

Beitrag "Pi Pico _PIO_"

von Leander (Gast)


Lesenswert?

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ß...

von Seppel (Gast)


Lesenswert?

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

von Philipp B. (philipp_b993)


Lesenswert?

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.

von Mehmet K. (mkmk)


Lesenswert?

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.

von Tim  . (cpldcpu)


Lesenswert?

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.

von Joerg W. (joergwolfram)


Lesenswert?

> 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

von Tim  . (cpldcpu)


Lesenswert?

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...

: Bearbeitet durch User
von Meme (Gast)


Lesenswert?

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?

von Marco S. (masterof)


Lesenswert?

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.

von Tim  . (cpldcpu)


Lesenswert?

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.

von Lorenz W. (lw64)


Lesenswert?

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.

von Jack V. (jackv)


Lesenswert?

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.

: Bearbeitet durch User
von Philipp B. (philipp_b993)


Lesenswert?

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.

von Mike J. (emjey)


Lesenswert?

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.

von Marco S. (masterof)


Lesenswert?

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.

von Guido K. (Firma: Code Mercenaries GmbH) (thebug)


Lesenswert?

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.

von Tim  . (cpldcpu)


Lesenswert?

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.

von Guido K. (Firma: Code Mercenaries GmbH) (thebug)


Lesenswert?

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.

von Mw E. (Firma: fritzler-avr.de) (fritzler)


Lesenswert?

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.

von S.P. (Gast)


Lesenswert?

Guido K. schrieb:
> 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.

https://en.wikipedia.org/wiki/Status_register#CPU_architectures_without_arithmetic_flags

von Planloser (Gast)


Lesenswert?

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 chris_ (Gast)


Lesenswert?

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.

von foobar (Gast)


Lesenswert?

> 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."

von foobar (Gast)


Lesenswert?

>> 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.

von Tilo R. (joey5337) Benutzerseite


Lesenswert?

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.

von foobar (Gast)


Lesenswert?

> 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 ;-)

von Joachim Kröger (Gast)


Lesenswert?

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.

von Martin G. (Firma: kamaste.it GmbH) (myg63)


Lesenswert?

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.

von Uwe D. (monkye)


Lesenswert?

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/

von Jack V. (jackv)


Lesenswert?

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.

von c-hater (Gast)


Lesenswert?

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...

von Florian S. (vatterger)


Lesenswert?

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 chris_ (Gast)


Lesenswert?

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.

Beitrag #6568568 wurde von einem Moderator gelöscht.
von Meme (Gast)


Lesenswert?

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.

von Johannes S. (jojos)


Lesenswert?

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.

von chris_ (Gast)


Lesenswert?

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.

von temp (Gast)


Lesenswert?

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.

von Martin (Gast)


Lesenswert?

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.

von Marius (Gast)


Lesenswert?

>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.

von m.n. (Gast)


Lesenswert?

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.

von foobar (Gast)


Lesenswert?

> 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."

von c-hater (Gast)


Lesenswert?

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.

von temp (Gast)


Lesenswert?

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.

von temp (Gast)


Lesenswert?

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.

von Tim  . (cpldcpu)


Lesenswert?

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.

: Bearbeitet durch User
von Mw E. (Firma: fritzler-avr.de) (fritzler)


Lesenswert?

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

von m.n. (Gast)


Lesenswert?

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.

von Johannes S. (jojos)


Lesenswert?

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.

von temp (Gast)


Lesenswert?

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.

von foobar (Gast)


Lesenswert?

>> 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.

von temp (Gast)


Lesenswert?

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.

von Johannes S. (jojos)


Lesenswert?

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.

von Jack V. (jackv)


Lesenswert?

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?

von m.n. (Gast)


Lesenswert?

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.

von Tim  . (cpldcpu)


Lesenswert?

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.

: Bearbeitet durch User
von Uwe D. (monkye)


Lesenswert?

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...“

von temp (Gast)


Lesenswert?

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.

von Uwe D. (monkye)


Lesenswert?

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.

von temp (Gast)


Lesenswert?

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.

von ThomasW (Gast)


Lesenswert?

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.

von Jack V. (jackv)


Lesenswert?

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 AV​Rs.

: Bearbeitet durch User
von temp (Gast)


Lesenswert?

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?

von temp (Gast)


Lesenswert?

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.

von Jack V. (jackv)


Lesenswert?

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?

von temp (Gast)


Lesenswert?

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...

von Stefan ⛄ F. (stefanus)


Lesenswert?

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.

: Bearbeitet durch User
von Jack V. (jackv)


Lesenswert?

Stefan ⛄ F. schrieb:
> Was ist an den zwei Kernen eigentlich so genial, dass man darauf herum
> reiten muss?

Möglichkeit von Nebenläufigkeit?

von Martin (Gast)


Lesenswert?

Stefan ⛄ F. schrieb:

> Was ist an den zwei Kernen eigentlich so genial,

Das steht außer Frage. Befürchte nur, dass du die Antwort nicht 
verstehst :)

von Planloser (Gast)


Lesenswert?

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.

von Tilo R. (joey5337) Benutzerseite


Lesenswert?

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.

von Florian S. (vatterger)


Lesenswert?

> 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.

: Bearbeitet durch User
von Stefan ⛄ F. (stefanus)


Lesenswert?

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.

: Bearbeitet durch User
von Joerg W. (joergwolfram)


Lesenswert?

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

von Jack V. (jackv)


Lesenswert?

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 ;)

von foobar (Gast)


Lesenswert?

> 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.

von Joerg W. (joergwolfram)


Lesenswert?

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

von foobar (Gast)


Lesenswert?

> 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.

von foobar (Gast)


Lesenswert?

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.

von Jack V. (jackv)


Lesenswert?

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.

: Bearbeitet durch User
von foobar (Gast)


Lesenswert?

> 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 ...

von Stefan ⛄ F. (stefanus)


Lesenswert?

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.

von Jack V. (jackv)


Lesenswert?

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:
1
sd 2:0:0:0: [sdb] tag#0 FAILED Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK cmd_age=0s
2
sd 2:0:0:0: [sdb] tag#0 CDB: Read(10) 28 00 00 03 fe f9 00 00 08 00
3
blk_update_request: I/O error, dev sdb, sector 261881 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 0
4
usb 1-3.1.4: USB disconnect, device number 9
5
scsi 2:0:0:0: rejecting I/O to dead device
6
[…]

Ist aber auch nicht tragisch, weil das Programm zu dem Zeitpunkt schon 
drauf ist.

von foobar (Gast)


Lesenswert?

> 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.

von Jack V. (jackv)


Lesenswert?

foobar schrieb:
> Probier's doch mal mit /dev/sdb1 statt /dev/sdb.

Das sieht recht ähnlich aus:
1
sd 2:0:0:0: [sdb] Unaligned partial completion (resid=30144, sector_sz=512)
2
sd 2:0:0:0: [sdb] tag#0 CDB: Read(10) 28 00 00 00 02 09 00 00 f0 00
3
sd 2:0:0:0: [sdb] tag#0 FAILED Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK cmd_age=0s
4
sd 2:0:0:0: [sdb] tag#0 CDB: Read(10) 28 00 00 00 02 09 00 00 f0 00
5
blk_update_request: I/O error, dev sdb, sector 521 op 0x0:(READ) flags 0x84700 phys_seg 30 prio class 0
6
usb 1-3.1.4: USB disconnect, device number 10
7
sd 2:0:0:0: [sdb] tag#0 FAILED Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK cmd_age=0s
8
sd 2:0:0:0: [sdb] tag#0 CDB: Read(10) 28 00 00 00 02 f9 00 00 10 00
9
blk_update_request: I/O error, dev sdb, sector 761 op 0x0:(READ) flags 0x80700 phys_seg 2 prio class 0

von Uwe Bonnes (Gast)


Lesenswert?

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?

von Meme (Gast)


Lesenswert?

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

von foobar (Gast)


Lesenswert?

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 ...

von Stefan ⛄ F. (stefanus)


Lesenswert?

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".

von Jack V. (jackv)


Lesenswert?

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.

von Planloser (Gast)


Lesenswert?

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").

von foobar (Gast)


Lesenswert?

> 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.

von Meme (Gast)


Lesenswert?

Das hilft mir leider immer noch nicht weiter. Kann sich der Flash 
Speicher selbst überschreiben?

von Florian S. (vatterger)


Lesenswert?

Ja klar, es gibt sogar schon zu hauf Beispielcode im offiziellen Repo: 
https://github.com/raspberrypi/pico-examples#flash

von Meme (Gast)


Lesenswert?

Danke dir

von foobar (Gast)


Lesenswert?

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.

von Ralph S. (jjflash)


Lesenswert?

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.

von Johannes S. (jojos)


Lesenswert?

und flashen per OOCD? Da scheint es ja auch schon eine config zu geben:
https://github.com/raspberrypi/openocd/blob/rp2040/tcl/target/rp2040.cfg

von foobar (Gast)


Lesenswert?

> 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.

von foobar (Gast)


Lesenswert?

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.

von Jack V. (jackv)


Lesenswert?

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.

von Ralph S. (jjflash)


Lesenswert?

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!

von Jack V. (jackv)


Lesenswert?

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.

: Bearbeitet durch User
von Ralph S. (jjflash)


Lesenswert?

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.

von Jack V. (jackv)


Lesenswert?

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 …

von Ralph S. (jjflash)


Lesenswert?

;-) 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 ?

von foobar (Gast)


Lesenswert?

> 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.

von Stefan ⛄ F. (stefanus)


Lesenswert?

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.

von Jack V. (jackv)


Lesenswert?

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.

von Stefan ⛄ F. (stefanus)


Lesenswert?

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.

: Bearbeitet durch User
von foobar (Gast)


Lesenswert?

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.

von Florian S. (vatterger)


Lesenswert?

> 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.

: Bearbeitet durch User
von Jack V. (jackv)


Lesenswert?

Stefan ⛄ F. schrieb:
> Ehrlich: Solche Produkte will ich nicht haben.

Das ist ganz prima: bleibt mehr für mich :)

von Ralf M. M. (ramime)


Lesenswert?

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.

von Christopher J. (christopher_j23)


Lesenswert?

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/

von chris_ (Gast)


Lesenswert?

>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?

von Christopher J. (christopher_j23)


Lesenswert?

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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.