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.
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" 🤣
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?
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.
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).
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.
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...
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.
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.
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.
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.
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.
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.
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.
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.
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 ;)
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.
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.
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.
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.
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.
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.
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"
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?
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.
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.
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… ;-)
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.
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.
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.
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.
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.
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.
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!
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.
Und das kriegt man zertifiziert? Dann geht das auch mit RGB-Interface bei gängigen Controllern. Warum verkauft dann überhaupt jemand HDMI/DVI-Transmitter?
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.
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.
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.
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!
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.
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 ;-)
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.
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.
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.
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.
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ö.
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.
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...
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.
