Der Strom der Nachrichten gewinnt wieder an Geschwindigkeit. Im Jahres-Rechenschaftsbericht von Arduino finden Nutzer verschiedene Informationen darüber, wie die Italiener ihre Plattform weiterentwickeln zu gedenken. Mit dem Femtofox steht derweil ein für Experimente mit Mesh-Netzwerken optimiertes Entwicklerboard am Start. Zu guter Letzt präsentiert Murata einen leitfähigen Stoff, der theoretisch per Spray auf beliebige Formen aufgebracht werden kann.
ARM – Erweiterung für GitHub Copilot allgemein verfügbar
Kurz nachdem Microchip einen hauseigenen AI-Assistenten lanciert hat, kündigt ARM die Finalisierung der hauseigenen Copilot-Erweiterung an.
Raspberry Pi Pico-SDK-Update mit erhöhtem Maximaltakt für den RP2040
Die unter https://github.com/raspberrypi/pico-sdk/releases/tag/2.1.1 im Detail beschriebene Version 2.1.1 ermöglicht das offizielle Nutzen von 200 MHz am RP2040. Ursache dafür ist die – übrigens retrokativ gültige – Zertifikation des Chips für diese schnellere Taktrate:
Zu beachten ist, dass das Update des SDK allein nicht ausreicht, um die höhere Geschwindigkeit nutzen zu können. Im Interesse der Abwärtskompatibilität nutzt das SDK den schnelleren Takt nur auf expliziten Zuruf.
Interessant ist ausserdem, dass sich Raspberry Pi im Rahmen der Ankündigung “weitere Rezertifikationen” vorbehält – es wäre in der Theorie durchaus vorstellbar, dass dies eine Vorankündigung einer Taktsteigerung für den RP2350 darstellt.
Arduino: Open Source-Rechenschaftsbericht mit Informationen zur Zukunft der Plattform
Der alljährliche Open Source-Rechenschaftsbericht steht nun unter der URL https://content.arduino.cc/assets/Arduino%20Open%20Source%20Report%202024%20%281%29.pdf zum Download bereit – er informiert darüber, wie die Interaktion zwischen Arduino und der Open Source-Community verläuft bzw. voranschreitet.
Am Interessantesten ist traditionell die Frage, welche Unternehmen im Bereich der Pflege ihrer Bibliotheken am aktivsten waren. Dieses Jahr präsentieren sich die Ergebnisse wie in den beiden Abbildungen gezeigt.
Bildquelle: Arduino
Die beiden folgenden Abbildungen informieren erstens darüber, welche Open Source-Projekte in besonderem Maße von der Tätigkeit der Arduino-Entwickler profitieren. Die abermalige Erwähnung von Zephyr am Beginn des Berichts beweist zudem abermals, dass man diese Plattform als “Nachfolge” für das von ARM ja eingestellte MBED heranzuziehen gedenkt.
Bildquelle: Arduino
Sonst findet sich in diesem Bericht die übliche Listung neuer Bibliotheken und Boards.
LoRA Alliance – Jahresbericht veröffentlicht
Im Hause LoRA Alliance – es handelt sich dabei um das hinter der Kurzstreckenfunktechnologie stehende Standardisierungsgremium – möchte man mit dem LoRa Alliance 2024 End Of Year Report ebenfalls Aufmerksamkeit ziehen (PDF siehe https://resources.lora-alliance.org/document/lora-alliance-2024-end-of-year-report).
Neben einer Liste von Projekten und Events ist die folgende Auflistung relevant, da sie über die Anzahl der im Feld befindlichen LoRA-Geräte bzw die Anzahl der verkauften Chips informiert:
1
Thecontinuousdevelopmentandevolutionofthestandard
2
havedrivenLoRaWAN’sleadership.Omdiareportedmore
3
than350MendnodeswithLoRaICsand6.9Mgatewayswith
4
LoRaICsdeployedworldwideasofMay2024.Ourmember
5
companies’growthsupportsthis,forexample:
6
...
7
•TheThingsIndustriesconnects2.7milliondevices
8
andisseeing50%year-over-yeargrowth.
Murata MFT – frei formbares leitfähiges Material
Frei formbare und semi-transparente leitfähige Materialien ermöglichen die verschiedensten Experimente. Mit MFT hat Murata nun die Entwicklungsarbeiten an der hauseigenen Variante abgeschlossen, und betont die mehr als konkurrenzfähigen Leistungswerte.
Interessant ist, dass Murata derzeit auch nach Partnern sucht, die mit eigenen Ideen bei der Kommerzialisierung der Technologie helfen können – wer eine Einsatzidee hat, findet die “Meldestelle” unter der als Bildquelle angegebenen URL.
Femtofox – Linux-Einplatinenrechner mit geringem Stromverbrauch und LoRA-Modul
Einplatinenrechner sind in Bezug auf ihren Stromverbrauch nicht Unbedingt effizient. Der bei Tindie erhältliche und mit einem E22-900M30S-Modul ausgestattete Femtofox bezieht seinen Namen aus dem Teil der Spezifikation, die sehr geringen Energieverbrauch verspricht:
Die englische CartoType-Gruppe produziert seit Jahr und Tag einen Kartenrenderer, der von Google Maps und Co unabhängig ist und auch in Embeddedsystemen gut funktioniert. Unter der URL https://cartotype.substack.com/p/february-2025-update findet sich nun die Vorstellung folgender neuer Features:
1
MuchlessRAMisusedwhenloadingmapssidebyside
2
Betteraddresssearching
3
Asynchronousmaploading
Android 16 – Beta mit Channel Sounding-Support verfügbar
TI tritt Civil Infrastructure Platform-Projekt bei
Das von der Namensgebung her etwas unglücklich ausgefallene Civil Infrastructure Platform-Projekt arbeitet seit Jahr und Tag daran, ein Linux mit extrem langer Unterstützungsdauer anzubieten. Die Linux Foundation vermeldet nun, dass Texas Instruments der Initiative beigetreten ist:
> RP2040 has now been certified to run at a system clock of 200Mhz> when using a regulator voltage of at least 1.15 volts.> With this version of the SDK, you can now select a 200Mhz clock> for RP2040 simply by setting SYS_CLK_MHZ=200 via preprocessor define.> The regulator voltage will automatically be raised for you if necessary.
Na da ging ja zügig. Hatte mir vor ca. zwei Jahren eine µPython Funktion
geschrieben, welche das ebenfalls adaptiv macht. Bis hinauf zu 424 MHz.
Tam H. schrieb:> kündigt ARM die Finalisierung der hauseigenen Copilot-Erweiterung an.
Ah, KI ist einfach toll. Eine Frage eingegeben eine bestimmte Berechnung
für Cortex-M4 zu implementieren. Antwort:
> Upon careful analysis and typical cycle estimations, achieving this in just 3
CPU cycles on a Cortex-M4 is highly improbable without very specific architectural
extensions or highly optimized pre-computation. The expected cycle count is
roughly around 11 cycles or more for a practical implementation.
Kann ich eingeben "Ätsch, ich hab das hinbekommen" 🤣
Norbert schrieb:> Na da ging ja zügig. Hatte mir vor ca. zwei Jahren eine µPython Funktion> geschrieben, welche das ebenfalls adaptiv macht. Bis hinauf zu 424 MHz.
Du weißt aber schon, daß das schwer verboten und Du böse bist?
Jetzt bekommst Du einen Zettel mit "Zertifikat, 200 MHz" - mit Stempel.
Schön und praktisch: man macht nichts am Chip selbst, sondern eine Mücke
zum Elefanten. Das ist innovativ!
Moin,
Ich bin alt, meine Beine sind blind, meine Augen sind taub...
Aeeeeh - geht's da beim dem RP2040 Mopped mit neuem Rennvergaser
tatsaechlich um das Dingens, was vor' n paar Jahren auf der Embedded
World (koennte 2022 gewesen sein) sehr grosszuegig verteilt wurde?
IIRC hat/te der doch auch so eine fancy IO-Hardware zum
selbstprogrammieren - die laeuft dann auch entsprechend hurtiger?
Oder ist das irgendein Nachfolgechip oder Nachfolgerevision?
Gruss
WK
Dergute W. schrieb:> Oder ist das irgendein Nachfolgechip oder Nachfolgerevision?
Bestimmt nur alte Chips in neuen Tüten. Andernfalls wären andere
Baustellen wichtiger gewesen.
Dergute W. schrieb:> geht's da beim dem RP2040 Mopped mit neuem Rennvergaser> tatsaechlich um das Dingens, was vor' n paar Jahren auf der Embedded> World (koennte 2022 gewesen sein) sehr grosszuegig verteilt wurde?
So isses. Geht prima mit den alten RP2040 und prima – wenn auch
geringfügig anders – auch mit den RP2350.
China-Klone brauchen etwas mehr Zuwendung, da oftmals lahmarschige
FLASH-Bausteine eingesetzt werden.
Moin,
Merci fuer die Info. Da koennte ich ja mal meinen naechsten
Motiviationsschub dahingehend fokussieren, ob man aus so'm Ding mit
moeglichst wenig Zusatzhardware nicht einen ASI- oder
SD-SDI-Testbildgenerator bauen koennte. (Dafuer ist ein attiny13a doch
definitiv zu lahm).
Gruss
WK
Dergute W. schrieb:> Moin,>> Merci fuer die Info. Da koennte ich ja mal meinen naechsten> Motiviationsschub dahingehend fokussieren, ob man aus so'm Ding mit> moeglichst wenig Zusatzhardware nicht einen ASI- oder> SD-SDI-Testbildgenerator bauen koennte. (Dafuer ist ein attiny13a doch> definitiv zu lahm).>> Gruss> WK
VGA und HDMI geht schon bequem nur mit PIO. Der neue RP2350 hat sogar
eine spezielle Hardware eingebaut HSTX (high-speed serial transmit)
welche einem das Leben diesbezüglich noch einmal einfacher macht.
Norbert schrieb:> VGA und HDMI geht schon bequem nur mit PIO.
Aber nur über einen externen RGB->HDMI Encoder IC oder? RGB Output geht
mit vielen Mikrocontrollern. NXP hat "offene" MPUs mit HDMI Transmitter
integriert, die anzusteuern dürfte aber eine ziemliche Herausforderung
sein (oder man nimmt einfach Linux).
Ob es bei Dir unter normalen Bedingungen an einem Beispiel oder in der
Serie und harten Bedingungen wie hoher Temperatur und Spannung an den
Toleranzgrenzen vom Hersteller garantiert stabil läuft, ist ein
Riesenunterschied...
Tam H. schrieb:> Im Hause LoRA Alliance – es handelt sich dabei um das hinter der> Kurzstreckenfunktechnologie stehende Standardisierungsgremium
Achso, LoRa steht für Low Range. Wieder was gelernt.
Norbert schrieb:> Na da ging ja zügig. Hatte mir vor ca. zwei Jahren eine µPython Funktion> geschrieben, welche das ebenfalls adaptiv macht. Bis hinauf zu 424 MHz.
Man muss doch nur den Befehl nutzen um 250MHz einzustellen:
set_sys_clock_khz(250000, false);
Mike J. schrieb:> Norbert schrieb:>> Na da ging ja zügig. Hatte mir vor ca. zwei Jahren eine µPython Funktion>> geschrieben, welche das ebenfalls adaptiv macht. Bis hinauf zu 424 MHz.>> Man muss doch nur den Befehl nutzen um 250MHz einzustellen:> set_sys_clock_khz(250000, false);
Das mag bis zu deiner gewählten Frequenz noch funktionieren, aber ich
meine mich schemenhaft zu erinnern, dass ich eine knapp 70% darüber
liegende Frequenz erwähnte. Das versuch mal nur mit
›set_sys_clock_khz()‹ ;-)
Da muss man dann vorher noch die Spannung des Kerns erhöhen.
vreg_set_voltage(VREG_VOLTAGE_1_30);
sleep_ms(100);
set_sys_clock_khz(428000, true);
Du nutzt aber offenbar µPython, da ist das sicherlich anders.
Ja, bei dem Flash muss man aufpassen, der kommt da teilweise nicht mehr
mit wenn man mit der Frequenz höher geht.
Mike J. schrieb:> noch die Spannung des Kerns
Siehste, das versuchte ich mit ›adaptiv‹ auszudrücken.
µPy besitzt in der Tat nur eine sehr rudimentäre Möglichkeit an den
Clocks zu schrauben. Da macht man's besser selbst, dafür dann aber
richtig. Im Sinne von richtig richtig.
Norbert schrieb:> Da macht man's besser selbst, dafür dann aber richtig.
Hast du denn die Corespannung auch angepasst oder einfach der Clock
Beine gemacht?
Und wie Uwe schon schrieb, für den Basteltisch mal ganz witzig aber
sonst? Für ein Produkt wohl eher schwierig über die offizielle Taktrate
zu gehen.
Da bei hohen Taktraten Stromsparen nicht von Bedeutung ist, setze ich
bei meinen Spielereien die Core-Spannung immer auf Maximum und die
Taktfrequenz auf 133 oder 150 MHz. Optional kann beim Init ein Pin
abgefragt werden, um die Taktfrequenz bei Bedarf zu verdoppeln. Dabei
hat es nie Probleme gegeben.
Blöd ist es, wenn man mit allzu hoher Taktfrequenz startet, weil dann
der Controller hängen bleibt und auch SWD Zugriffe nicht mehr
funktionieren.
Der FLASH Zugriff hat vom Bootloader schon hinreichend Wartezyklen, daß
dieser nicht übertaktet wird. Bei den ersten übertakteten Programmen
hatte ich diese zunächst ins RAM kopiert und dort laufen lassen. Das ist
aber garnicht notwendig.
Vielleicht hilft dieser Erfahrungswert.
900ss schrieb:> Und wie Uwe schon schrieb, für den Basteltisch mal ganz witzig aber> sonst? Für ein Produkt wohl eher schwierig über die offizielle Taktrate> zu gehen.
Das ist natürlich der Knackpunkt. Nur ist es einfacher, mit höherer
Taktfrequenz zu arbeiten, als beispielsweise den 2. Kern anzuwerfen, der
nervigerweise auch weiterläuft, wenn der 1. Kern gestoppt wird.
In der Arduino IDE kann man per Klick bis zu 300 MHz einstellen. Da habe
ich nie einen Aufschrei gelesen, der das auch nur ansatzweise als
'gefährlich' geschildert hat. Es kommt auf die Anwendung an, ob
Übertakten eine Lösung sein kann.
900ss schrieb:> Hast du denn die Corespannung auch angepasst oder einfach der Clock> Beine gemacht?
ADAPTIV! Für jede Frequenz gibt's die passende Spannung. Und die
ermittelt der Controller für sich selbst. Automagisch. Mit Kennlinie und
passendem Margin.
900ss schrieb:> Für ein Produkt wohl eher schwierig über die offizielle Taktrate> zu gehen.
Kommt auf die Absprachen und Dokumentation an. Ich habe hier, nur zum
Spaß, seit Jahren einen µC mit glatten 400MHz laufen. Im Kasten bei
konstanten 40°C. 24/7. Liefert nebenbei auch gleich mehrere
Referenztakte.
PS. Eigentlich wollte ich sehen wie schnell der kaputt geht. Hatte mit
Tagen oder bestenfalls Wochen gerechnet. Jetzt bin ich gespannt wie
viele Jahre der hält.
Norbert schrieb:> Und die ermittelt der Controller für sich selbst. Automagisch. Mit> Kennlinie und passendem Margin.
Hmm... das verstehe ich gerade nicht, ich habe mich beim RP2040 aber
bisher nicht damit beschäftigt. Er stellt sich selbst die passende
Corespannung ein?
Ich dachte, da muss man selber für sorgen. Weil du automatisch
schreibst.
Norbert schrieb:> Ich habe hier, nur zum Spaß, seit Jahren einen µC mit glatten 400MHz> laufen. Im Kasten bei konstanten 40°C. 24/7. Liefert nebenbei auch> gleich mehrere Referenztakte.
Du hast jetzt ja nicht dabei geschrieben um was für einen Controller es
sich handelt. Bei einem Teensy 4 würde ich auch nicht erwarten dass er
stirbt. ;) Ist es ein RP2040 hätte ich dass bei 400MHz auch nicht soo
schnell erwartet. 40° sind nun nicht so eine hohe Temperatur. Wenn der
Controller jetzt nicht selbst glühend heiß wird.
Norbert schrieb:> Kommt auf die Absprachen und Dokumentation an.
Klar wenn ein Kunde damit einverstanden ist. Aber mir fehlt die
Vorstellung dass es diese Kunden gibt. Wenn dann wohl eher sehr sehr
selten?
Mi N. schrieb:> In der Arduino IDE kann man per Klick bis zu 300 MHz einstellen. Da habe> ich nie einen Aufschrei gelesen
Das bestätigt mir, dass Arduino ein Bastelzeug ist. Würde ich nie als
Referenz ansehen. Auch wenn es im professionellen Bereich verwendet
wird.
Und wenn es jemand reizt, mit der hohen Frequenz zu arbeiten, OK. Für
mich ist das eher: ja könnte man mal machen. Und um selber ein Gefühl
dafür zu kriegen, wie ein RP2040 "übertaktet" läuft, kann ich zu Norbert
rüber schielen ;)
900ss schrieb:> Hmm... das verstehe ich gerade nicht, ich habe mich beim RP2040 aber> bisher nicht damit beschäftigt. Er stellt sich selbst die passende> Corespannung ein?> Ich dachte, da muss man selber für sorgen. Weil du automatisch> schreibst.
Nein,nein. Er (die SDK Funktion) stellt das nicht automatisch ein. Da
hatte ich mich unklar ausgedrückt. Deshalb habe ich ein Programm dafür
geschrieben:
> ermittelt der Controller für sich selbst. Automagisch.> Mit Kennlinie und passendem Margin.
Das sieht dann (in Ausschnitten) so aus:
1
$ make test_cpuspeed | tee test_2040_std.log
2
picorun cpuspeed_2040.py test_cpuspeed.py
3
18.0 MHz 18.0 MHz 0.90 V 63/7/6 vco: 756 MHz
4
20.0 MHz 20.0 MHz 0.90 V 70/7/6 vco: 840 MHz
5
21.0 MHz 21.0 MHz 0.90 V 63/6/6 vco: 756 MHz
6
21.6 MHz 21.6 MHz 0.90 V 63/7/5 vco: 756 MHz
7
22.0 MHz 22.0 MHz 0.90 V 77/7/6 vco: 924 MHz
8
23.0 MHz 23.0 MHz 0.90 V 69/6/6 vco: 828 MHz
9
24.0 MHz 24.0 MHz 0.90 V 98/7/7 vco:1176 MHz
10
…
11
297.6 MHz 297.6 MHz 1.25 V 124/5/1 vco:1488 MHz
12
300.0 MHz 300.0 MHz 1.30 V 125/5/1 vco:1500 MHz
13
302.4 MHz 302.4 MHz 1.30 V 126/5/1 vco:1512 MHz
14
303.0 MHz 303.0 MHz 1.30 V 101/4/1 vco:1212 MHz
15
304.0 MHz 304.0 MHz 1.30 V 76/3/1 vco: 912 MHz
16
304.8 MHz 304.8 MHz 1.30 V 127/5/1 vco:1524 MHz
17
306.0 MHz 306.0 MHz 1.30 V 102/4/1 vco:1224 MHz
18
307.2 MHz 307.2 MHz 1.30 V 128/5/1 vco:1536 MHz
Wenn man nur mit variierter Kernspannung arbeitet.
Beim Chinaklon ist übrigens viel früher Schluss:
1
$ make test_cpuspeed | tee test_2040_china.log
2
picorun cpuspeed_2040.py test_cpuspeed.py
3
18.0 MHz 18.0 MHz 0.90 V 63/7/6 vco: 756 MHz
4
20.0 MHz 20.0 MHz 0.90 V 70/7/6 vco: 840 MHz
5
21.0 MHz 21.0 MHz 0.90 V 63/6/6 vco: 756 MHz
6
…
7
194.4 MHz 194.4 MHz 1.00 V 81/5/1 vco: 972 MHz
8
195.0 MHz 195.0 MHz 1.00 V 130/4/2 vco:1560 MHz
9
196.0 MHz 196.0 MHz 1.00 V 98/6/1 vco:1176 MHz
10
196.5 MHz 196.5 MHz 1.00 V 131/4/2 vco:1572 MHz
Aber das liegt nur an den deutlich schlechteren FLASH Bausteinen. Mit
ein wenig Liebe kommen selbst die über 400MHz.
Norbert schrieb:> Das sieht dann (in Ausschnitten) so aus:
Alles klar, jetzt ist die Welt wieder in Ordnung. :)
Norbert schrieb:> Mit ein wenig Liebe
:)
900ss schrieb:> Das bestätigt mir, dass Arduino ein Bastelzeug ist. Würde ich nie als> Referenz ansehen. Auch wenn es im professionellen Bereich verwendet> wird.
Ich bin kein Arduino Fan, sehe das jedoch nicht so streng. Die IDE
erlaubt die sehr einfache Verwendung von USB und das Programmieren ohne
SWD-Adapter. Das macht kleine Anwendungen einfach - für größere Sachen
ist Arduino eine Katastrophe ;-)
Was man nicht machen darf, ist die vielen LIBs zu verwenden. Man sollte
eigene Routinen schreiben, um zu wissen, was/wie/wo passiert. Bis auf
Kanal 3 vom 64 Bit Timer für USB (1 kHz) ist die Hardware unbenutzt. Die
Interrupt-Vektortabelle liegt zudem im RAM.
Norbert schrieb:> Ich habe hier, nur zum> Spaß, seit Jahren einen µC mit glatten 400MHz laufen.
Sportlich, aber für den Eigenbedarf kann man das machen. Dabei ist der
RP2040 (bislang) Faktor 3 übertaktet. Die Stromaufnahme steigt nicht
wesentlich. Bei STM32 sind mir maximal 30 - 50 % gelungen und die
Controller werden deutlich wärmer.
Mi N. schrieb:> Sportlich, aber für den Eigenbedarf kann man das machen.
Ja, stimmt. War im Grunde genommen eigentlich zur spontanen
Selbstentzündung geplant. Da dachte ich noch die Dinger wären ähnlich
empfindlich wie alte PC-CPUs. Nach einer gewissen Zeit war das Warten
auf Flammen zu langweilig. Seitdem regelt sich das Ding in einem Gehäuse
seine Temperatur auf besagt 40°C und erzeugt nebenbei verdammt gute
Referenztakte. Stromversorgung (weit unter 100mA) über die ständig
laufende Fritz!Box.
Es geht ja nicht nur um den M0, sondern auch um die schnellere
Peripherie. Bei 133 MHz schaffen die PWM-Zähler etwas über 62 MHz
Eingangsfrequenz. Hat man 144 MHz Signale, kann man die mit ca. 300 MHz
Taktfrequenz direkt zählen.
Dies nur als praktisches Beispiel.
Probiert es aus!
Norbert schrieb:> Ja, stimmt. War im Grunde genommen eigentlich zur spontanen> Selbstentzündung geplant.
LOL :) Hat der RP2040 dich enttäuscht ;)
Mi N. schrieb:> Ich bin kein Arduino Fan, sehe das jedoch nicht so streng. Die IDE> erlaubt die sehr einfache Verwendung von USB
Ja um mal eben einen schnellen Test für irgendwas zu machen, nutze ich
es auch manchmal. Aber ernst nehmen kann ich es nicht so richtig.
Mi N. schrieb:> Es geht ja nicht nur um den M0, sondern auch um die schnellere> Peripherie.
Das verdient eine besondere Erwähnung. PIOs bei zig hundert MHz sind
jetzt nicht wirklich schlecht…
Manchmal ist es auch nett für einen Sack voller Berechnungen beiden
cores für 'ne viertel Sekunde eine Ecstasy-Infusion zu verpassen. Danach
können sie ja wieder für den Rest der Sekunde bummeln.
Niklas G. schrieb:> Ist einen Cortex-M0 zu übertakten nicht ein bisschen wie Tuk-Tuk mit> Hayabusa-Motor?
Jetzt haben wir ja zwei M33er…
Ansonsten, wie immer… wenn man's nicht gerade selbst braucht, dann
isses schlecht.
Norbert schrieb:> PIOs bei zig hundert MHz sind jetzt nicht wirklich schlecht…
Ja, das sehe ich auch so. Die Dinger sind wirklich genial. Wundert mich,
dass andere Hersteller das nicht anbieten.
Norbert schrieb:> Ansonsten, wie immer… wenn man's nicht gerade selbst braucht, dann> isses schlecht.
Ich hab nicht gesagt dass irgendwas schlecht ist.
900ss schrieb:> Ja, das sehe ich auch so. Die Dinger sind wirklich genial. Wundert mich,> dass andere Hersteller das nicht anbieten.
Kann man das nicht mit DMA auf GPIO-Ports nachbilden? Oder SDMMC wenn
auf 8bit gestellt? Oder parallelen RGB-Interfaces?
Niklas G. schrieb:> Kann man das nicht mit DMA auf GPIO-Ports nachbilden? Oder SDMMC wenn> auf 8bit gestellt? Oder parallelen RGB-Interfaces?
Wenn man sicher stellt, dass der Arbiter auch wirklich jeden
Glockenschlag präzise verarbeitet und nicht ein anderer DMA dazwischen
funkt. Die PIOs habe FIFOs dafür.
Und man kann seriell zB. 32×1Bit herein schieben und bekommt dann einen
unkritischen DMA Zugriff. Und man kann's acht/zwölf mal parallel laufen
lassen.
> Ja, das sehe ich auch so. Die Dinger sind wirklich genial. Wundert mich,> dass andere Hersteller das nicht anbieten.
Motorola 68332 so ende der 90er, hiess da TPU. Hat sich damals wohl
nicht so recht durchgesetzt weil Entwickler entweder ueberfordert waren,
oder so gut das sie es nicht brauchen. Schwer zu sagen. :-)
Heute hast du dagegen gerne ein Multitastkingsystem oder so einen lahmen
Pythonkram, da ist externe Hardware die ein genaues Timing einhalten
kann schon von groesserem Interesse. Daher denke ich mal das dies mehr
Schule machen wird.
Vanye
Norbert schrieb:> PIOs bei zig hundert MHz sind jetzt nicht wirklich schlecht…
Man braucht sie insbesondere auch, um fehlende (Grund-)Funktionen
nachzubilden.
Norbert schrieb:> Jetzt haben wir ja zwei M33er…
Ich hatte es an anderer Stelle schon mal geschrieben, warum ein RP2xyz
ganz nett ist, aber auch seine Grenzen hat:
Beitrag "Re: "Sicherheit" beim RP2350"900ss schrieb:>> PIOs bei zig hundert MHz sind jetzt nicht wirklich schlecht…>> Ja, das sehe ich auch so. Die Dinger sind wirklich genial. Wundert mich,> dass andere Hersteller das nicht anbieten.
Beim MC68332 gab es die TPU, womit ich aber nie zu tun hatte.
Norbert schrieb:> Wenn man sicher stellt, dass der Arbiter auch wirklich jeden> Glockenschlag präzise verarbeitet und nicht ein anderer DMA dazwischen> funkt.
Mit der Prioritätseinstellung geht das, und DMAs haben oft integrierte
FIFOs (z.B. STM32).
900ss schrieb:> Die Dinger sind wirklich genial. Wundert mich,> dass andere Hersteller das nicht anbieten.
Vielleicht ist es so dass das für viele Anwendungen "gebastelt" ist, und
zum "richtig machen" gibt es dedizierte Peripherie genau für das
konkrete Problem. Was wären konkrete Anwendungen für das PIO die man
nicht auch direkt mit einem Display-Interface, Quad/Octo-SPI,
SRAM-Controller, SDIO/SDMMC o.ä. hinbekommt?
Niklas G. schrieb:> Was wären konkrete Anwendungen für das PIO die man> nicht auch direkt mit einem Display-Interface, Quad/Octo-SPI,> SRAM-Controller, SDIO/SDMMC o.ä. hinbekommt?
Man kann damit z.B. ein DVI/HDMI-Signal erzeugen, um einen Monitor
anzusteuern.
Man kann damit die bizarrsten Protokolle wie z.B. 13-Bit-SPI
implementieren - letztlich, es erlaubt alles, was damit möglich ist,
ohne daß man dafür einen spezialisierten Peripheriecontroller im µC
vorrätig haben muss.
Harald K. schrieb:> Man kann damit z.B. ein DVI/HDMI-Signal erzeugen, um einen Monitor> anzusteuern.
Kann man auch mit einem dedizierten RGB-Interface das viele große
Mikrocontroller oder Anwendungsprozessoren haben.
Harald K. schrieb:> Man kann damit die bizarrsten Protokolle wie z.B. 13-Bit-SPI> implementieren
Bloß wie oft braucht man das... Die allermeisten ICs haben gewöhnliches
8bit-SPI oder I²C...
Harald K. schrieb:> ohne daß man dafür einen spezialisierten Peripheriecontroller im µC> vorrätig haben muss.
Naja, es gibt ja eine gigantische Auswahl an den unterschiedlichsten
Mikrocontrollern, wo man mit großer Wahrscheinlichkeit einen findet der
die gewünschten spezialisierten Peripherieelemente bietet.
Niklas G. schrieb:> Naja, es gibt ja eine gigantische Auswahl an den unterschiedlichsten> Mikrocontrollern, wo man mit großer Wahrscheinlichkeit einen findet der> die gewünschten spezialisierten Peripherieelemente bietet.
Tja, dann nimmt man halt einen davon…
Diese ganze PIO Idee war ja — wie wir jetzt endlich wissen — sowieso
sinnlos. Was die sich nur dabei gedacht haben… ;-)
Niklas G. schrieb:> Kann man auch mit einem dedizierten RGB-Interface das viele große> Mikrocontroller oder Anwendungsprozessoren haben.
Das dedizierte RGB-Interface liefert TMDS-Datenströme? Schön, aber der
dafür nötige "Anwendungsprozessor" ist ein fettes, teures und für viele
nicht verarbeit- oder auch nur kaufbares Teil.
Niklas G. schrieb:> Naja, es gibt ja eine gigantische Auswahl an den unterschiedlichsten> Mikrocontrollern
Klar, und für jede Aufgabe braucht man einen neuen, anderern, für den
man sich schlimmstenfalls schon wieder 'ne neue Toolchain und schon
wieder ein neues, anderes Debuginterface beschaffen muss, ganz abgesehen
davon, daß man diese unterschiedlichsten Controller auch erst mal kaufen
und in eigenn Designs verarbeiten können muss.
Das ist natürlich alles viel, viel besser als ein kleiner, günstiger und
universell verwenbarer Controller.
Logisch.
*Ein Hoch auf die Spezialisierung!*
Harald K. schrieb:> Das dedizierte RGB-Interface liefert TMDS-Datenströme?
Das tut der RP2040 auch nur dank externer Hardware, die in dem bekannten
Beispiel auch stark gehackt und nicht spezifikationskonform ist. Da
kriegt man wohl kaum das Konformitätssiegel für das man zum Verkaufen
braucht. Das ist nichts für kommerzielle Anwendungen. Den digitalen
Datenstrom kann man auch per RGB-Interface ausgeben, ja, aber eben mit
dem selben Ergebnis.
Harald K. schrieb:> Schön, aber der dafür nötige "Anwendungsprozessor" ist ein fettes,> teures und für viele nicht verarbeit- oder auch nur kaufbares Teil.
Für kommerzielle Nutzung kein Problem. Die allermeisten MCUs/MPUs werden
nicht auf Bastler konzipiert. Für Grafikausgabe braucht man sowieso
einiges an Speicher und Rechenleistung, da ist ein kräftiger Prozessor
nicht verkehrt.
Harald K. schrieb:> Klar, und für jede Aufgabe braucht man einen neuen, anderern, für den> man sich schlimmstenfalls schon wieder 'ne neue Toolchain und schon> wieder ein neues, anderes Debuginterface beschaffen muss
Auch kein wirkliches Problem für kommerzielle Nutzung. Davon ab sind
auch die Produktfamilien der einzelnen Hersteller riesig; die über
Tausend (IIRC) verschiedenen STM32 kann man mit der selben Software und
Hardware programmieren. Die herstellereigene IDE ist gratis.
Dritthersteller-Tools unterstützen typischerweise eine ganze Reihe von
Mikrocontroller-Herstellern, da muss man höchstens noch ne extra Lizenz
kaufen wenn man die komplette CPU-Architektur wechselt.
Harald K. schrieb:> daß man diese unterschiedlichsten Controller auch erst mal kaufen und in> eigenn Designs verarbeiten können muss.
Auch keinerlei Problem für Firmen. Bei Digikey kann man sogar privat
eine riesige Auswahl bekommen...
Harald K. schrieb:> Das ist natürlich alles viel, viel besser als ein kleiner, günstiger und> universell verwenbarer Controller
So ist es. Bisher kam kein überzeugender Use Case für PIO, der für ein
verkaufbares, vollwertiges Produkt besser als die dedizierte Hardware
von "klassischen" Controllern wäre.
Niklas G. schrieb:> Das tut der RP2040 auch nur dank externer Hardware, die in dem bekannten> Beispiel auch stark gehackt und nicht spezifikationskonform ist.
Ja, ein paar Serienwiderstände.
Niklas G. schrieb:> Bisher kam kein überzeugender Use Case für PIO, der für ein> verkaufbares, vollwertiges Produkt besser als die dedizierte Hardware> von "klassischen" Controllern wäre.
Vor ein paar Jahren gab es keine 'klassischen' Controller zu kaufen.
Ich brauchte eine Ansteuerung für ein QVGA Display (320 x 240), welches
es auch nicht gab. Nur VGA mit 640 x 480 Pixeln.
Per PIO wurden die ausgegebenen Pixel horizontal verdoppelt und eine
Zeile zweimal nacheinander ausgegeben. Der interne Speicher reichte für
zwei Seiten mit 64 Farben.
Für mich war das eine richtig gute Lösung - nicht nur vollwertig sondern
auch vegan!
Niklas G. schrieb:> Was wären konkrete Anwendungen für das PIO die man nicht auch direkt mit> einem Display-Interface, Quad/Octo-SPI, SRAM-Controller, SDIO/SDMMC o.ä.> hinbekommt?
Serieller Datenbus, sehr hohe Datenrate und hartes Timing mit
proprietären Übertragungsparametern. Kann man nicht kaufen und mit den
PIOs war das einfach zu realisieren. Nein, auch mit SPI nicht zu machen.
Vorher wurde ein zusätzliches FPGA genutzt.
Es gibt immer mal was, wo die PIOs gut sind und man dann kein extra FPGA
braucht. Ist schnell und das Timing ist sehr genau. Eigentlich ein Traum
von Peripherie.
Harald K. schrieb:> Ja, ein paar Serienwiderstände.
Ja, kann man genau so an ein RGB-Interface schnallen.
Norbert schrieb:> Das sieht ziemlich gut aus, für ›stark gehackt‹…
Und das kriegt man zertifiziert? Dann geht das auch mit RGB-Interface
bei gängigen Controllern. Warum verkauft dann überhaupt jemand
HDMI/DVI-Transmitter?
Mi N. schrieb:> Vor ein paar Jahren gab es keine 'klassischen' Controller zu kaufen.
Aber schon lange vor den RP2040.
Mi N. schrieb:> Ich brauchte eine Ansteuerung für ein QVGA Display (320 x 240), welches> es auch nicht gab.
Das geht mit den üblichen RGB-Interfaces schon lange. Erstbestes
Beispiel: STM32F429I-DISC1 . QVGA, 262K Farben, man kann natürlich alle
Pixel individuell ansteuern, man hat genug Speicher und Rechenleistung
um flüssige Animationen darzustellen.
Das Board gibt's schon so lange, dass es ne Mini-USB-Buchse hat... So
etwas sollte der Minimalstandard für GUIs sein - wenn man da heutzutage
noch mit 64 Farben, ruckeligen Animationen und verdoppelten Zeilen
ankommt gehen die Kunden zur Konkurrenz.
900ss schrieb:> Serieller Datenbus, sehr hohe Datenrate und hartes Timing mit> proprietären Übertragungsparametern.
Wo kommt sowas vor? Was ist das für eine Gegenstelle? Wenn das irgendwas
total exotisches ist, lohnt sich das nicht einen Serien-Mikrocontroller
darauf zu optimieren. Für Serienprodukte, die natürlich für die
Mikrocontroller-Hersteller relevant sind, würde man die Gegenstelle auf
Octo-SPI/SDIO/USB/PCIe/Whatever umbauen. Das ist halt die Antwort warum
gängige Mikrocontroller kein PIO haben: Solche Anwendungen zu
unterstützen bringt keine Verkaufszahlen.
900ss schrieb:> Luft- & Raumfahrt
Klingt nicht nach großen Stückzahlen. Hat die Gegenseite auch einen RP?
Oder FPGA?
900ss schrieb:> Ach so, nein der RP2040 war nicht in Flughardware verbaut ;)
Sondern im Kassensystem...? Wie verarbeitet man eigentlich sehr hohe
Datenraten auf einem Cortex-M0?
J. S. schrieb:> PIO spart vermutlich Kosten für zugekaufte IP cores.
Das klingt schon eher nach einer guten Erklärung.
> Bloß wie oft braucht man das... Die allermeisten ICs haben gewöhnliches> 8bit-SPI oder I²C...
1-Wire? Oder die gar lustig blinkenen Leds mit WS2812? Da musst du dir
ja sonst auch schon den Arsch ab programmieren um den Kram mit USART und
DMA nach zu programmieren. Oder einen schnellen Quadraturencoder?
Ich finde es aber interessant das es mal was neues gibt und dann alle
sagen, oeh... wofuer braucht man den das....
Das ist so...hm..deutsch? :-D
Wer es nicht braucht nutzt es halt nicht. In praktisch jeder heutigen
Anwendung sind immer 50% der Peripherie in einem Controller ungenutzt.
Vanye
Vanye R. schrieb:> Wer es nicht braucht nutzt es halt nicht.
Danke. Das spricht mir aus der Seele. Da gibt es, wie ich finde, eine
wirklich gute neue Peripherie und es wird daran rumgenörgelt oder wird
in Frage gestellt. Mein Opa war auch so. Manchen scheint der Blick über
den eigenen Tellerrand hinaus verwehrt zu sein. Danach wird es schwarz
wie die Nacht.
Die Welt findet nicht nur auf dem eigenen Entwicklungstisch statt.
Und es wurden sogar Beispiele genannt. Die natürlich auch in Frage
gestellt wurden. Viele Wege führen nach Rom. Wenn irgendjemand es anders
besser(?) lösen kann, gerne. Machen!
Niklas G. schrieb:> Mi N. schrieb:>> Vor ein paar Jahren gab es keine 'klassischen' Controller zu kaufen.>> Aber schon lange vor den RP2040.
Dann hast Du die Coronazeit wohl auch nicht mitbekommen.
> Mi N. schrieb:>> Ich brauchte eine Ansteuerung für ein QVGA Display (320 x 240), welches>> es auch nicht gab.>> Das geht mit den üblichen RGB-Interfaces schon lange. Erstbestes> Beispiel: STM32F429I-DISC1 . QVGA, 262K Farben, man kann natürlich alle> Pixel individuell ansteuern, man hat genug Speicher und Rechenleistung> um flüssige Animationen darzustellen.
Eben die STM32 waren nicht beschaffbar.
> Das Board gibt's schon so lange, dass es ne Mini-USB-Buchse hat... So> etwas sollte der Minimalstandard für GUIs sein - wenn man da heutzutage> noch mit 64 Farben, ruckeligen Animationen und verdoppelten Zeilen> ankommt gehen die Kunden zur Konkurrenz.
Es hat nichts geruckelt, Du kennst meine Anwendung garnicht. Mein Kunde
'liebt' mich, weil ich kostengerecht entwickeln kann - auch wenn es
Lieferengpässe gibt.
Vor längerer Zeit hatte ich eine Schaltung veröffentlich mit 6502. Es
kam ein Leserbrief: "Das macht man nicht, man nimmt dafür einen 8051".
Dann hatte ich damit noch eine 8-stellige 7-Segmentanzeige multiplext:
"Das macht man nicht, man nimmt dafür einen ICMxyz". Man, war der doof!
Soetwas gibt es heute wohl immer noch, weshalb mir nach der langen Zeit
eine Form von 'Enkeltrick' in den Sinn kommt ;-)
Vanye R. schrieb:> 1-Wire? Oder die gar lustig blinkenen Leds mit WS2812?
Geht das damit, kann man damit das Timing der Bits individuell
einstellen?
Vanye R. schrieb:> Da musst du dir ja sonst auch schon den Arsch ab programmieren um den> Kram mit USART und DMA nach zu programmieren.
Naja das ist ziemlich simpel. Halt nicht besonders elegant.
Vanye R. schrieb:> Oder einen schnellen Quadraturencoder?
Können die Timer vom STM32 und sicherlich vielen anderen nativ
Vanye R. schrieb:> Ich finde es aber interessant das es mal was neues gibt und dann alle> sagen, oeh... wofuer braucht man den das....
Wenn man nicht nach Anwendungen fragt, kann man auch nix damit machen...
900ss schrieb:> und es wird daran rumgenörgelt oder wird in Frage gestellt.
Ich hab überhaupt nicht genörgelt. Ich habe nur nach Anwendungen
gefragt.
Mi N. schrieb:> Dann hast Du die Coronazeit wohl auch nicht mitbekommen.
Der Grund warum andere Controller kein PIO haben ist also Corona? Mit
den ESP32 kann man übrigens auch QVGA-Displays ansteuern und die waren
super lieferbar.
Mi N. schrieb:> Eben die STM32 waren nicht beschaffbar.
Dann ist es mit PIO halt ein Workaround, aber kein wirklicher
spezifischer Use Case.
Mi N. schrieb:> Mein Kunde 'liebt' mich, weil ich kostengerecht entwickeln kann
Heißt es ist ein Serienprodukt, ein Controller mit dedizierter
RGB-Peripherie wäre zu teuer?
Niklas G. schrieb:> Heißt es ist ein Serienprodukt, ein Controller mit dedizierter> RGB-Peripherie wäre zu teuer?
Was hast Du an nicht beschaffbar nicht verstanden?
'Use Case', was ist denn das für ein wording? Du solltest Dein doing
fitten.
:-(
Mi N. schrieb:> Was hast Du an nicht beschaffbar nicht verstanden?
Was hast du an "warum haben andere Controller kein PIO?" nicht
verstanden?
Mi N. schrieb:> Use Case', was ist denn das für ein wording?
Kürzer als Anwendungsfall, letzteres kennt die Autokorrektur nicht mal,
nervig.
> Wenn man nicht nach Anwendungen fragt, kann man auch nix damit machen...
Nein, man sucht nicht nach Problemen wo man im Internet eine Loesung
findet.
Man hat ein Problem und sucht dafuer eine Loesung. Wenn du keine
Probleme hast dann musst du auch nichts suchen.
Vanye
Niklas G. schrieb:> Geht das damit, kann man damit das Timing der Bits individuell> einstellen?
Die Frage zeigt, dass viel Wissen um die Fähigkeiten der PIO fehlt.
Nicht mit beschäftigt, ist OK. Allerdings dann hier den "Besserwisser"
raushängen zu lassen, das ist schon speziell.
Lass es doch einfach dabei, dass es auch hier Leute gibt, die wissen was
sie tun und das Produkt so funktioniert hat, wie der Kunde es wünschte.
Und nicht so:
Niklas G. schrieb:> wenn man da heutzutage noch mit 64 Farben, ruckeligen Animationen und> verdoppelten Zeilen ankommt gehen die Kunden zur Konkurrenz.
Die provokante Frage, wie verarbeitet man mit einem M0 hohe Datenraten?
Das weißt du nicht? Was sind denn konkret hohe Datenraten? Ach, hängt
davon ab? Muss man das vielleicht auch im Kontext sehen? Ach sooo.
900ss schrieb:> Allerdings dann hier den "Besserwisser" raushängen zu lassen, das ist> schon speziell.
Ich habe überhaupt nicht bessergewusst. Lies doch einfach mal was ich
schreibe.
900ss schrieb:> wie verarbeitet man mit einem M0 hohe Datenraten
Wer provokant mit "sehr hohen Datenraten" anfängt darf mit Rückfragen
rechnen.
900ss schrieb:> Was sind denn konkret hohe Datenraten?
Ja, fragt man sich.
Niklas G. schrieb:> Harald K. schrieb:>> Ja, ein paar Serienwiderstände.>> Ja, kann man genau so an ein RGB-Interface schnallen.
Du weißt, was der Unterschied zwischen TMDS und einem üblichen
RGB-Interface ist? Anscheinend nicht.
Ich nehme an, daß Du, als die Microcontroller aufkamen, auch groß getönt
hättest, daß es für die ja gar keine ernstzunehmenden Anwendungen gäbe,
weil sich deren Aufgaben auch mit applikationsspezifischen ICs oder
einer größeren Handvoll Standardbauteile lösen ließen.
Und als so etwas wie PALs, CPLDs etc. aufkamen, hättest Du in die
gleiche Tröte gepustet. Braucht man nicht, geht alles viel besser mit
den üblichen Verdächtigen, Töröö-prust-Tö.
Harald K. schrieb:> Du weißt, was der Unterschied zwischen TMDS und einem üblichen> RGB-Interface ist?
Erläutern ❎️ Beleidigen ✅️ Verkaufen kann man so ein TMDS-Produkt auf
RP2040 Basis trotzdem nicht.
Ich schau mir das hier seit geraumer Zeit an und muss zwangsläufig zu
dem Schluss kommen, dass eine weitere Diskussion — wenn man das denn
unbedingt so nennen will — unnötig erscheint.
Der König vertritt nun einmal die Meinung, dass ›nicht sein kann was
nicht sein darf‹. Und wie wir alle Wissen sind Meinungen heutzutage
Trumpf und Fakten eher nervig.
Harald K. schrieb:> Warum? Weil ein "erlkönig" es nicht für ausreichend umständlich hält?
Lass mal, ist vergeblich. Gibt's halt.
Norbert schrieb:> Und wie wir alle Wissen sind Meinungen heutzutage> Trumpf und Fakten eher nervig.
:)
Niklas G. schrieb:> Das geht mit den üblichen RGB-Interfaces schon lange. Erstbestes> Beispiel: STM32F429I-DISC1 . QVGA, 262K Farben, man kann natürlich alle> Pixel individuell ansteuern, man hat genug Speicher und Rechenleistung> um flüssige Animationen darzustellen.
Kostet 30 Euronen. Und ist auf das Display beschränkt, was ST halt
draufgenagelt hat.
Außerdem gibt's bei praktisch allen Distributoren Warnungen bezüglich
"long lead times".
Und, last but not least: ST neigt dazu, Produkte einfach mal
einzustellen. Manchmal sogar ohne jede Vorwarnzeit, das gilt
insbesondere im Bereich der Demo-Boards. Wenn die z.B. das passende
Display nicht mehr beschaffen können, machen sie einfach den Sack zu und
gut isses. Scheiß auf die Kunden, war ja nur ein (viel zu günstig
verkauftes) Demo-Board. Sollen die halt die nächste Variante kaufen,
natürlich mit abweichendem Display, ggf. sogar nur mit abweichender MCU.
Und natürlich mit abweichendem physischen Layout bezüglich Höhenprofil,
Bohrungen und nötigem Display-Durchbruch.
Das ist insgesamt für deine Kunden in etwa so vertrauenerweckend wie
eine hochgradig gereizte Kobra 20cm vor ihrem Gesicht. Jedenfalls für
all die, die noch selbst denken und recherchieren können...
Ob S. schrieb:> Wenn die z.B. das passende> Display nicht mehr beschaffen können, machen sie einfach den Sack zu und> gut isses.
Was wäre die Alternative?
Ob S. schrieb:> natürlich mit abweichendem Display,
Was wäre die Alternative?
Demoboards werden nicht ohne Grund Demoboards genannt.
Wer diese im produktiven Einsatz verwendet, wird das hoffentlich nur in
Einzelstücken tun.
Ob S. schrieb:> Das ist insgesamt für deine Kunden in etwa so vertrauenerweckend
Was haben Demoboards bei deinen Kunden zu suchen?
> Scheiß auf die Kunden, war ja nur ein (viel zu günstig> verkauftes) Demo-Board.
Demoboards sind dafuer das das sich ein Ingenieur eine Meinung ueber
einen Controller bilden kann um zu entscheiden ob damit eine Entwicklung
gemacht wird oder nicht. Und wenn man sich entscheidet, damit der
Softwerker schonmal etwas hat mit dem er anfangen kann bis die ersten
echten Muster auf dem Tisch liegen.
Wer mit dem Demoboard ernsthaft ein Produkt macht hat etwas gewaltig
nicht verstanden.
Vanye
Arduino F. schrieb:> Was haben Demoboards bei deinen Kunden zu suchen?
Genau das ist die eigentliche Frage. Die einzig zutreffende Antwort ist:
natürlich nix.
Nur scheint das Niklas G. nicht klar zu sein...
Announcement: there is an English version of this forum on 
Thread beobachten
Seitenaufteilung abschalten