https://www.heise.de/news/Raspberry-Pi-Pico-2-mit-Mikrocontroller-RP2350-Staerkere-ARM-Kerne-und-RISC-V-9827575.html Wieso kommt so eine Meldung nicht von Tam? Ich bin überrascht.
Harald K. schrieb: > https://www.heise.de/news/Raspberry-Pi-Pico-2-mit-Mikrocontroller-RP2350-Staerkere-ARM-Kerne-und-RISC-V-9827575.html > > Wieso kommt so eine Meldung nicht von Tam? > > Ich bin überrascht. MiiiTuuu Die RISC-V Kerne hören sich ›gefährlich‹ an. ;-) Wieso sie sich allerdings alternativ nutzen lassen, das erschließt sich mir nicht. Also, ab auf die Suche nach Datenblättern. Hoffentlich haben sie die Kennlinie des ADC ein wenig glatter gebügelt.
Das Datenblatt gibt es hier: https://www.raspberrypi.com/products/rp2350/ Und hier einen Erfahrungsbericht von jemandem, der den Chip vorab testen konnte: https://dmitry.gr/?r=06.%20Thoughts&proj=11.%20RP2350
Das PiPico 2 Board gibt es schon "fast" bei Reichelt: https://www.reichelt.com/raspberry-pi-pico-2-rp235x-cortex-m33-microusb-rasp-pi-pico-2-p383358.html
Was soll eigentlich im Datenblatt "Dual Cortex-M33 or Hazard3 processors at 150 MHz" bedeuten? Ich meine das "or". Bauen die eins von beiden ein, ganz nach Lust und Laune?
OK, ADC ist leicht verbessert. PIOs können nun mehr. DMA hat in Verbindung mit zB. PWM immer noch einen kleinen ›Quirk‹. Anscheinend können zwei ARM, zwei RISC-V, oder ein ARM und ein RISC-V Core nebeneinander arbeiten. Doppelt soviel RAM! TMDS,High-speed serial transmit,Always-On Timer,… Insgesamt scheint's so, als wenn eine Endlos-Schleife nun in unter 5 Minuten abgearbeitet wird. ;-)
" Der RP2350A im QFN60-Gehäuse hat aber 30 GPIO-Kontakte. Er kostet einzeln 80 US-Cent." Wahnsinn. Wie geht sowas? Kann mir mal einer eine Kostenrechung zu dem IC von der Entwicklung bis zum millionenfachen Verkauf aufmachen, damit ich erkennt, wie sowas finanziert werden kann? " Sowohl RP2350A als auch RP2350B gibt es für jeweils 20 Cent mehr auch als RP2354A und RP2354B mit je 2 MByte Flash-Speicher im Gehäuse (Co-packaged Flash)." WAS? SOOOO viel teurer bei 2MB Flash! ;-) "Das Pico-2-Platinchen misst wie beim Vorgänger 5,1 Zentimeter mal 2,1 Zentimeter, ähnlich wie ein Arduino Nano. Es bringt 4 MByte QSPI-Flashspeicher in einem separaten Chip mit, beim Vorgänger waren es 2 MByte. Damit eignen sich RP2350 und Pico 2 für deutlich anspruchsvollere Projekte als RP2040/Pico. " Im Prinzip ja. Aber wieviele der RP2040 und auch bald RP2350 werden ihr Dasein mit LED Blinken und anderen "Herausforderungen" verbringen, die um Größenordnungen unter deren Leistungsfähigkeit liegen?
:
Bearbeitet durch User
Falk B. schrieb: > Im Prinzip ja. Aber wieviele der RP2040 und auch bald RP2350 werden ihr > Dasein mit LED Blinken und anderen "Herausforderungen" verbringen, die > um Größenordnungen unter deren Leistungsfähigkeit liegen? Völlig egal. Bei 1€. Ich wette das nahezu alle µC deutlich unterhalb ihrer maximalen Leistungsfähigkeit eingesetzt werden.
Christoph M. schrieb: > Das PiPico 2 Board gibt es schon "fast" bei Reichelt: Bei TME und Berrybase ebenso und anders als bei Reichelt mit Preis: https://www.tme.eu/de/details/sc1631/raspberry-pi-minicomputers/raspberry-pi/raspberry-pi-pico-2/ https://www.berrybase.de/detail/index/sArticle/14269?src=raspberrypi Laut dem im Heise-Artikel verlinkten Blog-Post von Eben Upton soll es noch vor Jahresende auch ein Pico 2 W Board geben.
> Ich meine das "or". Bauen die eins von beiden ein, > ganz nach Lust und Laune? Es kann wohl nur entweder der eine oder der andere Laufen. Vermutlich Probleme beim laden des Codes aus dem lahmen QSPI Flash. Aber ist eigentlich quatsch. Nichts gegen RiscV. Ich denke langfristig wird das Arms ersetzen. Aber warum sollte man sich in einem Projekt zwei C Compiler antun? Sonst ist da doch aus Sicht des Programmierers kein Unterschied. Die hatten wohl einfach noch Platz auf dem Silizium und wussten nicht was sie da hin machen sollen. :) Vanye
Norbert schrieb: > Falk B. schrieb: >> Im Prinzip ja. Aber wieviele der RP2040 und auch bald RP2350 werden ihr >> Dasein mit LED Blinken und anderen "Herausforderungen" verbringen, die >> um Größenordnungen unter deren Leistungsfähigkeit liegen? > > Völlig egal. Bei 1€. Ja, das stimmt wohl paradoxerweise. > Ich wette das nahezu alle µC deutlich unterhalb ihrer maximalen > Leistungsfähigkeit eingesetzt werden. Das ist auch gar nicht so sehr das Problem, wenn Hardware heute extrem billig und resourcenreich zu haben ist. Aber irgendwann sollte (muss?) man die Materialschlacht eindämmen und mit Resourcen gescheit umgehen. Denn sonst "braucht" der LED-Blinker bald mindestens einen Dual Core Prozessor. Von den deutlich anspruchsvolleren Anwendungen ganz zu schweigen. Schlechte, verschwenderische Software gibt es heute mehr als genug. https://de.wikipedia.org/wiki/Bloatware
> Schlechte, verschwenderische Software gibt es heute mehr als > genug. Endlich mal etwas an dem kein Mangel herrscht. :-) Ich wunder mich auch ueber immer "mehr". Ich meine braucht man wirklich noch mehr Ram? Also ich nicht. Was aber am RP2040 schon bescheiden war das war alles wofuer man Expertise braucht. Also Energie sparen und gute analoge Sachen wie ADCs. Aber das schuettelt man nicht mal eben so aus dem Aermel. Vanye
Harald K. schrieb: > Wieso kommt so eine Meldung nicht von Tam? Tada (und älter als dein Beitrag, oder das Datum ist fake): Beitrag "RP2350 / Raspberry Pi Pico 2 – RISC/V und ARM-Kerne im Wechsel-Dich-Verfahren"
Bedeutet das, daß die Produktion des alten Pi Pico eingestellt wird?
Nein: Product lifetime: Raspberry Pi understands the value to customers of long term availability of product and therefore aims to continue supply for as long as practically possible. We expect RP2040 to remain in production until at least January 2041. https://datasheets.raspberrypi.com/rp2040/rp2040-product-brief.pdf Seite 3
:
Bearbeitet durch User
Rahul D. schrieb: > Harald K. schrieb: >> Wieso kommt so eine Meldung nicht von Tam? > > Tada (und älter als dein Beitrag, oder das Datum ist fake): > Beitrag "RP2350 / Raspberry Pi Pico 2 – RISC/V und ARM-Kerne im > Wechsel-Dich-Verfahren" Haralds Beitrag vom 08.08.2024 17:15 ist einige Stunden alter als Tams Artikel vom 08.08.2024 22:16. Crazy Harry schrieb: > Bedeutet das, daß die Produktion des alten Pi Pico eingestellt wird? Unwahrscheinlich, der Controoller der darauf ist soll noch lange produziert werden: "Obsolescence statement Raspberry Pi understands the value to customers of long term availability of product and therefore aims to continue supply for as long as practically possible. We expect RP2040 to remain in production until at least January 2041." https://www.raspberrypi.com/products/rp2040/specifications/
Stefan K. schrieb: > Haralds Beitrag vom 08.08.2024 17:15 ist einige Stunden alter als Tams > Artikel vom 08.08.2024 22:16. Mist. Es wird in der Übersicht ja nicht das Erstellungsdatum, sondern das des letzten Beitrags angezeigt. ADHS ist großer Mist.
Rahul D. schrieb: > ADHS ist großer Mist. Alles gut, es gibt schlimmeres. Stell' Dir mal vor, Du wärst drauf wie "Moby" oder eine seiner Sockenpuppen. Bist Du nicht, und das ist wirklich gut. Da ist eine kurze Unaufmerksamkeit echt kein Thema, das kann und darf jedem passieren. Im Heise-Forum hat jemand übrigens das hier verlinkt: https://dmitry.gr/?r=06.%20Thoughts&proj=11.%20RP2350 Das ist sehr lesenswert, da beschreibt jemand, der quasi "Beta-Tester" war, die Vorzüge des 2350.
Harald K. schrieb: > Da ist eine kurze Unaufmerksamkeit echt kein Thema, das > kann und darf jedem passieren. > Im Heise-Forum hat jemand übrigens das hier verlinkt: > https://dmitry.gr/?r=06.%20Thoughts&proj=11.%20RP2350 -> Beitrag "Re: Nachfolger des RP2040/Raspberry Pi Pico"
Falk B. schrieb: > eine Kostenrechnung Die Raspi Foundation ist gemeinnützig. Die dürfen sich zwar gigantische Gehälter zahlen, als Organisation aber keine Gewinne machen. Man nimmt also die Gewinne aus dem einen Bereich und steckt sie in den anderen und zahlt keine Einkommensteuer. Hat man dann irgendwann aufgrund der aggressiven Preispolitik einen so großen Markt, das man kaum noch weiß wohin mit dem Geld, firmiert man um und besitzt aus dem Stand ein höchst profitables Unternehmen. Man muss ab da zwar Einkommensteuer bezahlen, ist bis dahin aber steuersubventioniert und mit der geilen PR des gemeinnützigen gewachsen. Und das beste: Auch die Geldgeber dahinter profitieren direkt über die volle Absetzbarkeit ihrer Spenden. Wenn also z.B. Broadcomm denen Sach- und Geldspenden zukommen lässt, sind das zu 100% absetzbare Ausgaben. Im Endeffekt eine sehr kreative Methode ein wirklich großes Geschäft aufzubauen, dem Finanzamt aber weiszumachen es wäre gar kein Geschäft. Letzlich zahlen natürlich alle Bürger dafür. Denn diese Unternehmen nutzen zwar die steuerfinanzierte Infrastruktur der Länder, haben aber eine völlig legale Methode gefunden dafür nicht zu bezahlen. Emotional kann man das unterschiedlich bewerten. Sicherlich ist es von der britischen Regierung durchaus erwünscht ein international renomiertes Halbleiterunternehmen zu haben, nachdem ARM ja nun der japanischen Softbank gehört. Wie viel gutes die wirklich tun kann ich nicht bewerten.
Michael schrieb: > Falk B. schrieb: >> eine Kostenrechnung > > Die Raspi Foundation ist gemeinnützig. > Die dürfen sich zwar gigantische Gehälter zahlen, als Organisation aber > keine Gewinne machen. Das ist alles, aber keine Kostenrechnung. Die enthält nämlich ein paar Zahlen. Zeitaufwand für Chipentwicklung, Kosten Zeitaufwand für Produktionsüberleitung mit allem Drum und Dran, vor allem Test Produktionskosten, Material und Aufwand ...
Norbert schrieb: >> Im Prinzip ja. Aber wieviele der RP2040 und auch bald RP2350 werden ihr >> Dasein mit LED Blinken und anderen "Herausforderungen" verbringen, die >> um Größenordnungen unter deren Leistungsfähigkeit liegen? > > Völlig egal. Bei 1€. > Ich wette das nahezu alle µC deutlich unterhalb ihrer maximalen > Leistungsfähigkeit eingesetzt werden. Noch ein Kommentar dazu. Dieses Übermaß an Ressourcen führt auch dazu, daß die Leute (statistisch) immer fauler und unfähiger werden und immer mehr Ressourcen für ein und das selber Problem benötigen. So wie die autofahrenden, im Übermaß konsumierenden Amis (aber nicht nur die) physisch und psychisch verfetten, so ähnlich läuft es auch mit den Fähigkeiten und der Leistungsbereitschaft von Softwareentwicklern. Ich erwarte sicher NICHT, daß jeder Entwickler wie ein Halbgott aus den 1980er oder 1990er seine Maschine beherrscht und mit Assembler schier unglaubliche Leistungen rauskitzelt. Aber was man nur allzu oft als "Solution" zu Gesicht bekommt, ist einfach nur ein schlechter Witz.
Falk B. schrieb: > Das ist alles, aber keine Kostenrechnung. Bravo. Das hast Du sehr gut erkannt. Ich bin stolz auf Dich. Verstehst Du denn das die Kosten keinerlei Rolle spielen in dem Modell? Man ist gezwungen alle Gewinne wieder für den gewährten Zweck des gemeinnützigen Unternehmens auszugeben. Man muss das nur irgendwie rechtfertigen können das eine eigene MCU dazu zweckdienlich ist. Als gemeinnütziges Unternehmen müsste die Raspi Foundation diese Zahlen eigentlich offenlegen. Du solltest die also selber finden können wenn Du Dich durch deren Geschäftsberichte wühlst.
Falk B. schrieb: > Aber was man nur allzu oft als > "Solution" zu Gesicht bekommt, ist einfach nur ein schlechter Witz. Andererseits ist das, was fähige Leute mit Controllern wie RP2040 oder ESP8266/ESP32 anstellen können, durchaus beeindruckend. Dafür musste man früher eine fette Handvoll zusätzlicher Hardware bereitstellen. Aber auch unterhalb der ganz fetten Controller ist das, was fähige Leute auf die Beine stellen können, beeindruckend. https://github.com/cnlohr/rv003usb Das ist das RISC-V-Äquivalent von V-USB für den WCH CH32V003. Ich sehe hier schon einen Gegenentwurf zum "Ich brauche einen Raspberry Pi 4, um meine drei Lampen im Wohnzimmer zu steuern".
Falk B. schrieb: > Dieses Übermaß an Ressourcen führt auch dazu, > daß die Leute (statistisch) immer fauler und unfähiger werden Jaja. Alles Idioten. Nur das dieses Übermaß an Ressourcen ja nicht mehr Silizium benötigt und viel weniger Strom als die ollen Knechte. Und wenn man nicht mehr Bits zählen muss, baut man eben auch mal einfach geile Features aus Spaß an der Freude, statt sich um quälende Optimierungen zu kümmern. Jede Hochkultur ist aus dem Überfluss entstanden. Wer sich mit Jagen und Sammeln den Tag versaut, meißelt keine Marmor Statuen Mit dem 8051 habe ich LEDs flackern lassen und Texte auf der Seriellen ausgegeben. Was die unfähigen Idioten heutzutage aus einem ESP herauskitzeln und welche Fertigkeiten sie dafür entwickeln mussten, finde ich eigentlich recht beeindruckend. ASM und Taktzyklen zählen können die natürlich nicht mehr. Dafür kann ich kein C++ und Java. Wer hier also der unfähige Idiot ist, ist wohl eher sehr abhängig davon von welcher Seite man das betrachtet.
Harald K. schrieb: > Ich sehe hier schon einen Gegenentwurf zum "Ich brauche einen Raspberry > Pi 4, um meine drei Lampen im Wohnzimmer zu steuern". Nur einen Pi 4? Noch gar keinen Pi 5? ;)
Michael schrieb: > Die Raspi Foundation ist gemeinnützig. und die Aktien der Raspberry Pi Holdings Plc werden seit Mitte Juni an der Börse gehandelt.
Falk B. schrieb: > Denn sonst "braucht" der LED-Blinker bald mindestens einen Dual Core > Prozessor. Das klingt vernünftig. Der eine Core schaltet die LED ein und der andere Core schaltet die LED wieder aus. Wie sollte man das denn anders machen können?!?
Frank M. schrieb: > Falk B. schrieb: >> Denn sonst "braucht" der LED-Blinker bald mindestens einen Dual Core >> Prozessor. > > Das klingt vernünftig. Der eine Core schaltet die LED ein und der andere > Core schaltet die LED wieder aus. Wie sollte man das denn anders machen > können?!? Genau so. Damit beantwortet sich die Frage warum man Mehrkern Controller benötigt. Weil 2 "Schaltaktuatoren" wäre schon etwas dürftig.
Frank M. schrieb: > Das klingt vernünftig. Der eine Core schaltet die LED ein und der andere > Core schaltet die LED wieder aus. Wie sollte man das denn anders machen > können?!? Eine wirklich bodenständige Herangehensweise. Hab's gleich mal probiert.
1 | #!/usr/bin/python
|
2 | # -*- coding: UTF-8 -*-
|
3 | # vim:fileencoding=UTF-8:ts=4
|
4 | |
5 | from machine import Pin |
6 | import _thread |
7 | from time import sleep_ms |
8 | from random import randrange |
9 | |
10 | def on_core_1(led): |
11 | while True: |
12 | led.on() |
13 | sleep_ms(randrange(100,200)) |
14 | |
15 | def on_core_0(): |
16 | led = Pin(25, Pin.OUT) |
17 | _thread.start_new_thread(on_core_1, (led,)) |
18 | while True: |
19 | led.off() |
20 | sleep_ms(randrange(100,200)) |
21 | |
22 | on_core_0() |
Michael schrieb: > Falk B. schrieb: >> Das ist alles, aber keine Kostenrechnung. > Bravo. Das hast Du sehr gut erkannt. > Ich bin stolz auf Dich. > > Verstehst Du denn das die Kosten keinerlei Rolle spielen in dem Modell? Verstehst du, daß das gar nicht die Frage war?
Michael schrieb: > Falk B. schrieb: >> Dieses Übermaß an Ressourcen führt auch dazu, >> daß die Leute (statistisch) immer fauler und unfähiger werden > > Jaja. > Alles Idioten. [ ] Du hast das (statistisch) verstanden > Was die unfähigen Idioten heutzutage aus einem ESP herauskitzeln und > welche Fertigkeiten sie dafür entwickeln mussten, finde ich eigentlich > recht beeindruckend. > ASM und Taktzyklen zählen können die natürlich nicht mehr. Das hat auch keiner gefordert, nicht mal ich. > Wer hier also der unfähige Idiot ist, ist wohl eher sehr abhängig davon > von welcher Seite man das betrachtet. Jaja, wieder mal schön gelabert.
Norbert schrieb: > Hab's gleich mal probiert. Sehr gut. Aber muss da nicht noch ein kleines Delay hinter
1 | _thread.start_new_thread(on_core_1, (led,)) |
damit die nicht gleichzeitig versuchen, den Status der LED zu wechseln? EDIT: Achso, Du benutzt Zufallszahlen. Schade, bis jetzt sah das Blinker-Programm noch einfach aus. ;-)
:
Bearbeitet durch Moderator
> Nur das dieses Übermaß an Ressourcen ja nicht mehr Silizium benötigt und > viel weniger Strom als die ollen Knechte. Wenn man mit einem Grossrechner der 80er vergleicht dann spart so ein RP2040/RP3250 natuerlich gewaltig Energie. Wenn man es mit einer heute ueblichen Standardanwendung vergleicht dann wechselst du bei den RPs einmal im Monat die Batterie oder bei der Konkurrenz einmal in 5Jahren. Oder du baust eine fettere Batterie ein, bist also teurer wie die Konkurrenz. > Und wenn man nicht mehr Bits zählen muss, baut man eben auch mal einfach > geile Features aus Spaß an der Freude, statt sich um quälende > Optimierungen zu kümmern. Ja richtig, erst noch droelfzig Libraries anziehen fuer allen Firlefanz. Keiner durchschaut mehr was da fuer Bugs drin sind, keiner weiss wie leicht das dann zu hacken ist. :-D Ich will nicht alles schlecht reden. Man kann mit mehr Resourcen auch mehr gutes machen. Aber in der Praxis sehe ich mehr Faulheit und Inkompetenz. Deine geilen Features muessen naemlich alle getestet werden. Passiert zu oft nicht.... Vanye
@Vanye R. (vanye_rijan) Kannst Du bitte die Unart unterlassen, immer die Zeile "xxx schrieb:" zu löschen? Ich möchte (und sicherlich noch eine paar andere Leser hier) gerne das Posting, auf das Du dich beziehst, im Kontext lesen. Normalerweise kann man das durch Klick auf die erwähnte Zeile. Du machst das aber unmöglich. Ohne den Kontext nachvollziehen zu können, lese ich dann Deinen Beitrag aber nicht mehr weiter, weils dann zu anstrengend wird, Deinen Gedankengang nachzuvollziehen. Unterstütze bitte Deine Leser beim Lesen Deiner Beiträge. Denk mal drüber nach. Danke.
:
Bearbeitet durch Moderator
Frank M. schrieb: > Norbert schrieb: >> Hab's gleich mal probiert. > > Sehr gut. Aber muss da nicht noch ein kleines Delay > hinter_thread.start_new_thread(on_core_1, (led,)) > damit die nicht gleichzeitig versuchen, den Status der LED zu wechseln? Nö. Core0 startet Core1. Erst einige Mikrosekunden später kommt Core0 dazu wieder auszuschalten. Gleichzeitiger Zugriff könnte auch im weitere Programmverlauf auftreten, wirkt sich aber (in diesem Fall) nicht aus. Wenn man Angst hat (oder wenn's um Daten geht), kann man aber wunderbar über ›_thread.allocate_lock()‹ synchronisieren. Edit: Tippfeuhler
:
Bearbeitet durch User
Norbert schrieb: > Nö. Core0 startet Core1. Erst einige Mikrosekunden später kommt Core0 > dazu wieder auszuschalten. Gleichzeitiger Zugriff könnte auch im weitere > Programmverlauf auftreten, wirkt sich aber (in diesem Fall) nicht aus. > Wenn man Angst hat (oder wenn's um Daten geht), kann man aber wunderbar > über ›_thread.allocate_lock()‹ synchronisieren. Der neue hat zur Synchronisierung der Cores FIFOs, 32 Spinlocks und 2x8 Doorbells in Hardware, im Single-Cycle IO-Subsystem.
Tilo R. schrieb: > Der neue hat zur Synchronisierung der Cores FIFOs, 32 Spinlocks und 2x8 > Doorbells in Hardware, im Single-Cycle IO-Subsystem. FIFOs und Spinlocks hat der RP2040 auch schon. Und genau die werden in µPy genommen. SIO hätte man auch in µPy nehmen können, wollte die Gemeinde aber nicht über Gebühr strapazieren. ;-)
Tilo R. schrieb: > Der neue hat zur Synchronisierung der Cores FIFOs, 32 Spinlocks und 2x8 > Doorbells in Hardware, im Single-Cycle IO-Subsystem. Meinst Du, daß das die zum Blinkenlassen einer LED erforderliche Sicherheit gewährleisten kann?
Norbert schrieb: > FIFOs und Spinlocks hat der RP2040 auch schon. Stimmt, nur die Doorbells sind neu. Harald K. schrieb: > Tilo R. schrieb: >> Der neue hat zur Synchronisierung der Cores FIFOs, 32 Spinlocks und 2x8 >> Doorbells in Hardware, im Single-Cycle IO-Subsystem. > > Meinst Du, daß das die zum Blinkenlassen einer LED erforderliche > Sicherheit gewährleisten kann? Für was braucht man sie denn sonst? :-)
Endlich ein Controller, der all das bietet, was ich nicht brauche ;-) Mir hätte eine Revision des 2040 schon gefallen und diese - wie angesprochen - endlich mit einem ADC der brauchbare 12 Bit liefert. Meinetwegen auch mehr RAM, mehr PIOs, mehr PWM-Kanäle ... Letztere aber auch bitte mit capture-Funktion und für jeden Kanal einen eigenen ISR-Vector und das alles in pinkompatiblem Gehäuse. Aber nein, es muß ein neues Spielzeug sein. Wer es noch nicht gefunden hat, findet hier einige Aspekte zu dem RP2350: https://www.eevblog.com/forum/microcontrollers/possible-click-bait-title-the-raspberry-pi-pico-2-now-has-extra-risc-v-cores/ Ein Nutzer führt die schnelle Verbreitung des 2040 auf den seinerzeit herrschenden Lieferengpass bei anderen Controllern zurück. Das war auch bei mir der Fall. STM konnte nicht liefern und den RP2040 gab es gleich als fertiges, günstiges Board. Aus Neugier / wg. Regenwetters mit dem 2350 zu spielen? Ich weiß nicht. Christoph M. schrieb: > Und hier einen Erfahrungsbericht von jemandem, der den Chip vorab testen > konnte: > > https://dmitry.gr/?r=06.%20Thoughts&proj=11.%20RP2350 Der Schreiber mag den STM32H7 wohl nicht ;-) Vielleicht hat er ja in einigen Punkten Recht. Wenn es ihm reicht, den H7 durch den 2350 zu ersetzen - ich gratuliere. Wenn ich bestimmte Eigenschaften des H7 brauche, dann nehme ich ihn. Soweit mein unbedeutender Senf.
Na ja, im Grunde genommen ist jeder, aber auch wirklich jeder einzelne Controller der letzten Jahrzehnte völlig falsch designed worden. Zumeist dann, wenn er nicht präzise auf die eigenen, sehr speziellen — aber oftmals als universell angesehenen — Vorlieben und Wünsche ausgelegt wurde.
Norbert schrieb: > Na ja, im Grunde genommen ist jeder, aber auch wirklich jeder einzelne > Controller der letzten Jahrzehnte völlig falsch designed worden. Das stimmt nicht und darum geht es mir auch garnicht. Aus meiner Sicht wäre es brauchbarer gewesen, einen verbesserten Nachfolger des RP2040 anzubieten als ziemlich viel umzudrehen inkl. der Kerne. Auf deutsch: zunächst die Hausarbeiten machen. Den halbherzig entworfenen ADC hattest bekanntlich Du selber ins Gespräch gebracht. Vergleiche ich beispielsweise mit STM32 da gibt/gab es unterschiedliche Typen in pinkompatibler Ausführung. Gut, bei den neueren Version gab es unter Umständen kleine Änderungen im pinout, die aber verschmerzbar waren. Heute ist es Hipp (oder Alete), 64 Bits des GPIO in einem Zyklus zu schreiben. Der absolute Wahnsinn! Ein DMA-Kanal, der endlos durchlaufen kann. Völlig irre!
Frank M. schrieb: > Kannst Du bitte die Unart unterlassen Endlich sagst mal ein Moderator...... danke!
Mi N. schrieb: > Das stimmt nicht und darum geht es mir auch garnicht. Mein Beitrag war ja auch mehr ›tongue in cheek‹ gedacht. Aber man hätte tatsächlich das Existierende erst einmal verbessern können. Allerdings wäre oftmals die Kompatibilität als drop-in flöten gegangen (was ich ohnehin bezweifle). Nur mal als ein Beispiel von einigen: PWM-CC Register hätten pro Kanal ein eigenes Register verdient (DMA narrow write Problem). Dennoch bin ich der Überzeugung das sie einen soliden Schachzug gemacht haben. Inklusive des Augenzwinkerns in Richtung Arm. ;-) Und die Chinesen werden in absehbar kurzer Zeit ein 325xB Platinen-Teil mit deutlich mehr herausgeführten Pins bringen.
Norbert schrieb: > Aber man hätte tatsächlich das Existierende erst einmal verbessern > können. Der Meinung bin ich auch. Obwohl der neue sicher ein schönes Spielzeug ist. Aber ob man es wirklich braucht? Sicher nur in Einzelfällen.
Norbert schrieb: > Und die Chinesen werden in absehbar kurzer Zeit ein 325xB Platinen-Teil > mit deutlich mehr herausgeführten Pins bringen. Gibts schon, allerdings bei den Briten: https://shop.pimoroni.com/products/pga2350?variant=42092629229651
Harald K. schrieb: > Norbert schrieb: >> Und die Chinesen werden in absehbar kurzer Zeit ein 325xB Platinen-Teil >> mit deutlich mehr herausgeführten Pins bringen. > > Gibts schon, allerdings bei den Briten: > > https://shop.pimoroni.com/products/pga2350?variant=42092629229651 Da muss ich schmunzeln wenn ich sehe was die vorn und hinten ins Kupfer "gemalt" haben. :-) Nicht die dümmste Idee.
Bezüglich des 1,1 V Schaltreglers und dessen Spule ist auf eevblog eine neue Diskussion entstanden: https://www.eevblog.com/forum/projects/inductor-polarity/ Ich bin gespannt, wie sich das bei den erwarteten Boards auswirkt und wie sich diese in der Praxis verhalten. Bleibt auch die Frage, ob sich die Daten des ADCs tatsächlich verbessert haben, oder die bislang fehlenden Angaben darauf beruhen, daß der Schaltregler "wie Sau" stört. Nach wie vor bin ich der Meinung, daß ein Update des RP2040 zunächst die bessere Lösung gewesen wäre.
DAs ist schon interessant. :-) Das Schaltregler unterschiedlich stoeren wenn man unterschiedliche Spulen dran hat duerfte jedem klar sein. Das sie auch unterschiedlich stoeren wenn man die Bestueckungsrichtung aendert duerfte den meisten klar sein. Allerdings denkt man dabei eher an EMV Abstrahlung. Klingt schon bedenklich wenn der Schaltregler dadurch selber aus dem tritt kommt. Aber es war ja schon immer so das der Feedback am Schaltregler besonders empfindlich auf Stoerungen war und es ist wohl keine Hilfe wenn alles in einer MCU ist. Und fuer einen integrierten ADC ist das sicher auch keine Verbesserung. Vanye
Vanye R. schrieb: > fuer einen integrierten ADC ist das sicher auch keine Verbesserung. Ich vermute stark der ADC war nie im Fokus. 12Bit SAR ADC mit 8,7Bit ENOB, der mangels Vref die Raspi VCC als Ref nimmt, ist doch vom ganzen Konzept für kaum mehr geeignet als den Temperatursensor und mal ein Poti abzufragen. Man muss sich entscheiden ob man schnellen Digitalkram und Schaltregler integrieren will oder gute ADC. Ich denke es ist klar wofür man sich entschieden hat.
Michael schrieb: > 12Bit SAR ADC mit 8,7Bit ENOB Jetzt sollen es immerhin mindestens 9, typisch 9.5 sein (S. 1326, Tabelle 1435)
Mi N. schrieb: > Mir hätte eine Revision des 2040 schon gefallen und diese - wie > angesprochen - endlich mit einem ADC der brauchbare 12 Bit liefert. Nunja, den ADC kann man tatsächlich in der Pfeife rauchen. Das allerdings hat der RP (sowohl der alte als auch der neue) mit vielen anderen µC gemeinsam. Ist halt etwas ungünstig, sehr schnelle Digital-Elektronik und sehr empfindliche Analog-Elektronik auf einen gemeinsamen Die nageln zu wollen. > mehr PWM-Kanäle ... Letztere aber > auch bitte mit capture-Funktion und für jeden Kanal einen eigenen > ISR-Vector Du kannst doch im alten mindestens acht, im neuen sogar zwölf Capture-Einheiten haben. Mindestens, bei ca. 66Mhz Auflösung. Aber Extra-ISR für jeden davon? Wie soll das gehen? Kann nicht gehen, das kann man sich leicht ausrechnen, wenn man weiß, wie lang so ein IRQ-Cycle eines ARM M0+ ist. Deswegen gibt's DMA. Damit passt das. > Ein Nutzer führt die schnelle Verbreitung des 2040 auf den seinerzeit > herrschenden Lieferengpass bei anderen Controllern zurück. Das hat ganz sicher mit dazu beigetragen, das der so schnell tatsächlich in Produkten gelandet ist. > Aus Neugier / wg. Regenwetters mit dem > 2350 zu spielen? Also ich werde das ganz sicher machen, zumindest privat. > Wenn es ihm reicht, den H7 durch den 2350 zu > ersetzen - ich gratuliere. Naja, H7 ist doch 'ne etwas größere Nummer. Wenn es möglich war, den unkompliziert durch einen 2350 zu ersetzen, war er in der Anwendung schlicht deutlich unterfordert. Aber etwas realistischer ist der Wettbewerb mit so ziemlich allem bis hin zur M4-Klasse. Zumindest mittelfristig wird der 2040 und der 2350 den Markt hier über den Preis penetrieren. So viel Resourcen für so wenig Geld, da kann STM einfach nicht mithalten.
Ob S. schrieb: > Du kannst doch im alten mindestens acht, im neuen sogar zwölf > Capture-Einheiten haben. Mindestens, bei ca. 66Mhz Auflösung. Aber > Extra-ISR für jeden davon? Wie soll das gehen? Kann nicht gehen, das > kann man sich leicht ausrechnen, wenn man weiß, wie lang so ein > IRQ-Cycle eines ARM M0+ ist. Deswegen gibt's DMA. Damit passt das. Na das ist ja toll. An den Eingang B lege ich die Zählimpulse, wie die Capture-Signale anzuschließen sind wirst Du mir hoffentlich noch (unentgeltlich) verraten und dann können auf dem RP2040 8 Kanäle gleichzeitig zählen. Da ISR zu viel Zeit verbraucht, werden Deinem Vorschlag folgend die Capture-Werte per DMA nach ASCII gewandelt und über 8 TX-Leitungen ausgegeben. Und das Beste dabei, die 8 x PIO-Kanäle sind noch frei verfügbar. Das nenne ich genial! Christoph M. schrieb: > Was für eine ENOB hat denn ein typischer STM32 (z.B. F303)? Laut Datenblatt bei 25°C, 3,3 V und <= 5 Msps etwa 11. Wäre der ADC beim 2040 nur mit 10 Bit spezifiziert worden, hätte es wenig zu Meckern gegeben. Um Störungen klein zu halten, habe ich beim RP2040 teilweise 3V3 LDO-Regler verwendet. Bei ca. 50 mA akzeptabel nicht sonderlich verlustreich.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.