Zum RP2350 gibt es Neuigkeiten – neben einem Sicherheitswettbewerb (Schema Pwn 2 Own) steht ein Evaluationsboard mit einem Funkmodul ante portas. Intel verkauft seine Anteile an ARM, ARMBian geht in die Stabilisierungsphase des aktuellen Release-Zyklus und Adafruit kündigt ein Stemma-Board mit WCH-Mikrocontroller an. Die DARPA möchte derweil einen automatischen C-zu-Rust-Transpiler entwickeln, um die “Zukunftsfähigkeit” von C-Code sicherzustellen.
Raspberry Pi - Hacke den RP 2350 und gewinne 10 000 US-Dollar.
Im Hause Raspberry Pi scheint man die Sicherheits-Architektur des neuesten Mikrocontrollers sehr ernst zu nehmen. Aufgrund der gerade stattfindenden Hacker-Konferenz Def Con lancierte man den in der Abbildung gezeigte „Angriffs-Wettbewerb“, für dessen Gewinn 10 000 US-Dollar an Preisgeld ausgelobt sind.
Zur Teilnahme muss der P. T. Angreifer nicht unbedingt physikalisch anwesend sein. Es ist auch möglich, ein im Handel erworbenes Pico 2-Board durch einspielen einer speziellen Firmware in eine Zieldarstellungsdrohne zu verwandeln.
Zu beachten ist allerdings, dass diese Modifikation mit irreversiblen Einschränkungen einhergeht. Spezifischerweise ist es nach dem Aktivieren der Sicherheitsarchitektur nie wieder möglich, auf diesem Board die Harzard 3 - RISC-Kerne in Betrieb zu nehmen.
Challenger+ RP2350 WiFi6/BLE5 – Raspberry Pi Pico W 2 von schwedischem Drittanbieter
Im Bereich der Wireless-Varianten des Raspberry Pi Pico setzte man im Hause Raspberry Pi Foundation bisher auf Infineon - warum man nicht auf Espressif-Module setzt, kann wohl nur durch „Compatetive Anxiety“ erklärt sein.
Sei dem wie es sei, bringt der schwedische Anbieter ILabs nun - wie in der Abbildung gezeigt - zusammen, was zusammen gehört.
Kritisch ist an der normalerweise um rund € 25 erhältlichen Platine vor allem, dass man im Hause Raspberry Pi sehr wahrscheinlich abermals auf den Funkmodul von Infineon setzen wird. Dies führt dann zu einer Insellösung.
Infineon AIROC CYW89829 - neuer Bluetooth LE-Mikrocontroller für den Automotivebereich.
Spricht man vom Teufel, so taucht er nur allzu oft auf. Im Fall von Infineon gilt, dass ein neuer Bluetooth LE-Mikrocontroller am Start steht - Spezifischerweise wird die neue Lütte folgendermaßen beschrieben:
Def Con und Raspberry Pi - Palm OS-Entwicklerlegende Grinberg durch Security von Bühne entfernt.
Die „Kombination bzw. Ankündigung“, den RP2350-Sicherheitswettbewerb auf der Devcon stattfinden zu lassen, ist kein Zufall - jeder Teilnehmer bekommt als Namesschild einen „Kleinstcomputer“, der auf einem der Mikrocontroller basiert.
Interessant ist, dass die Entwicklung der dort befindlichen Firmware wohl von der einst aus Palm OS-Zeiten bekannten Programmierer-Legende Dimitry Grinberg vorangetrieben wurde. Aufgrund von „Lizenzstreitigkeiten“ wurde dieser dann von seinem eigenen Vortrag zum Thema entfernt.
ARM, zur Ersten - Intel verkauft seine Aktienanteile
Spätestens nach dem Debakel um Curie, Galileo und Co. war klar, dass der X86-Architektur im Mikrocontroller und MSR-Bereich keine große Zukunft zusteht.
Im Hause Intel konnte man dieses Problem bisher mit einem lachenden und einem weinenden Auge betrachten, da man ob des Besitzens eines durchaus erheblich umfangreichen ARM-Aktienpaket ja doch irgendwie am Erfolg von ARM mitschnitt.
Handelsblatt berichtet nun unter Bezug auf ein SEC-Filing, dass diese Partnerschaft durch Verkauf der Anteile geendet ist:
Das Auch-Inkludieren von RISC/V-Kernen im neuesten Raspberry Pi Pico-Mikrocontroller scheint ARM nicht sonderlich zu stören.
Im aktuellsten an die Entwicklerschaft verschickten Newsletter findet sich die in der Abbildung gezeigte Lobung des Produkts.
Emteria - Abkündigung der alten MDM-Infrastruktur final.
Im Hause der Industrie-Android-Variante Emteria gibt es ebenfalls Neuerungen. In einem heute an die P. T. Nutzerschaft versendeten Newsletter vermeldet man nach folgendem Schema, dass das „alte“ MDM-Interface im Laufe der nächsten Tage den Weg alles irdischen gehen wird:
1
PleasenotethattheoldUI(https://mdm.emteria.com/Home/ListDevices) is now officially deprecated. Due to its limitations, particularly in handling data from different servers accurately, the old UI will be completely removed on December 31st, 2024.
Adafruit - Entwicklerboard auf Basis von WCH CH32V203
Etablierte Mikrocontrollerhersteller dürften die Ankündigung des in der Abbildung gezeigten Produkts ungefähr so verfolgen, wie ein Grillkoch die Installateur eines Burgergrillroboters betrachtet.
Die vor allem wegen ihrer hohen Breitenwirkung relevante Adafruit hat nun angekündigt, eines ihrer Stemma-Boards auf Basis der WCH-Ultra Low Cost-Mikrocontroller anbieten zu wollen. Zum Zeitpunkt der Drucklegung ist das Board um fünf Euro plus Versand erhältlich. Interessant ist, dass in der „Beschreibung“ nach folgendem Schema auf die „Unzureichendheit“ der verwendeten WCH-Hardware hingewiesen wird:
1
However,pleasenotethattheCH32seriesisnotsupportednearly-as-wellasATmega,ESP32,ATSAMD,STM32,orRP2040chipsthathaveastrongcompany-leddevelopmentcommunity.WCHisvery"its a low cost chip, you figure it out"kindofcompany,andwhilethereissomecommunity-leddevelopmentitisstillbestusedbyfolkscomfortablewithhavingtouseMakefiles,clonegitrepositories,editconfigurationfiles,etc.ItdefinitelydoesnotrunCircuitPythonorMicropython,andArduinosupportisveryearly.It'sdefinitelynotgoodforbeginners!
2
---viahttps://www.adafruit.com/product/5996
DARPA TRACTOR – Projekt zur Transpilation von C in RUST
Dass die Rust-Entwicklerschaft im C-Umfeld zu wildern sucht, dürfte für Leser von Mikrocontroller.net nicht überraschend sein. In Zusammenarbeit mit der US-amerikanischen Forschungsbehörde DARPA plant man ein Projekt, das die automatisierte Transpilation von (als schwierig zu wartend angesehenem) C-Code in Rust-Code automatisieren soll:
Das hinter der im Embeddedbereich weit verbreiteten Linuxdistribution Armbian stehende Entwicklerteam informiert seine P. T. Nutzerschaft nun darüber, dass der aktuelle Release-Zyklus im Stabilisierungsbereich angekommen ist. Spezifischerweise soll der Fokus der Maintainer nun vor allem auf der Sicherstellung der Produktqualität liegen:
Wo kommt denn die Begründung "Lizenzstreitigkeiten" her? Im Tweet steht
ja nur, das er nichts genaues wüsste. Und aufgrund der Streitigkeiten er
überlegt die Lizenz zu entziehen.
Keine Ahnung, was Defcon mit seiner Firmware genau macht. Aber er dürfte
mindestens indirekt der Verbreitung auf dem Badge zugestimmt haben. Wer
die Firmware für den Badge entwickelt und ausliefert, kann nicht
nachträglich dann die Lizenz entziehen. Die weitere Verbreitung (damit
ich das hier zu Hause hacken kann) kann er im Zweifelsfall aber
untersagen.
Was ich mich zum Rust transpiling frage: Kann man damit nicht
theoretisch einfach auch C sicherer machen? In (safe) Rust muss man sich
ja einfach alle Gedanken zur Speichersicherheit gemacht haben und der
Compiler beschwert sich, wenn das nicht passiert ist. Also muss der
Transpiler alle Speicherfehler finden, um das in safe Rust zu
Übersetzen. Aber dann könnte man doch auch gleichwertigen C Code
ausspucken oder nicht?
Mathias M. schrieb:> Aber dann könnte man doch auch gleichwertigen C Code> ausspucken oder nicht?
Aber dann hätte man ja keinen Grund für die x-te "sichere" Sprache, die
den Programmierern das Erlernen der Grundlagen abnehmen soll. Und man
hätte keine Sprache, in der altbekannte Dinge mit neuen tollen Namen
("Crate") versehen werden. Und man hätte keine Sprache mit CoC. Weil
gerade auf den es ja heutzutage ankommt.
Das wäre doch total uncool. Nee, das geht also schon mal gar nicht.
Als junger Programmierer muss man alles ablehnen, womit vorangehende
Generationen gearbeitet haben. Denn vorangehende Generationen sind blöd,
senil und rückständig, und nur als junger, dynamischer Mensch mit allen
Pronomen kann man überhaupt vernünftige Programme entwickeln.
Boomer hingegen finden Cobol cool, oder K&R-C.
> Was ich mich zum Rust transpiling frage: Kann man damit nicht> theoretisch einfach auch C sicherer machen?
Natuerlich. Wichtiger, jenseits vom Basteltisch wird keiner
mit K&R von anno Tubak programmieren. Da wird wohl wenigsten
Misra genutzt:
https://de.wikipedia.org/wiki/MISRA-C
Da kann es dir auch schon passieren das du deinen Source
einchecken willst und dann wird dir auf die Finger geklopft.
Und natuerlich sind da auch alle Warnungen an.
Aber wenn man als Fanboy unbedingt was neues mit Fussaufstampfen
durchdruecken will dann vergisst man sowas.
> Das wäre doch total uncool. Nee, das geht also schon mal gar nicht.
Gegen ein paar Neuerungen waer ja auch mal nix zu sagen, aber ich
schon den Eindruck das Rust irgendwie auch eine Glaubenslehre ist.
Vanye
Vanye R. schrieb:> Wichtiger, jenseits vom Basteltisch wird keiner> mit K&R von anno Tubak programmieren.
Das macht hoffentlich auch am Basteltisch niemand, denn K&R-C ist etwas,
was man wirklich ablehnen darf. Mit C89 hingegen kann man auch heute
noch problemlos sichere, wartbare und zuverlässige Programme schreiben.
Hallo,
@ Tam:
Darf man fragen warum es kritisch sein soll wenn auf dem Raspi Board ein
Produkt von Infineon verwendet wird? Das Funkmodul ist doch eine Art
Blackbox mit dem man als Anwender/Programmierer nichts zu tun hat. Man
nutzt es nur. Genauso wie man von einem Standard ESP das Funkmodul nur
verwendet, aber nichts direkt damit zu tun hat. Das Funkmodul auf dem
Raspi kann damit von jeder x beliebigen Firma sein. Zudem hat Raspi
nichts mit ESP zu tun, von daher haben sie freie Auswahl. Zur Frage
zurück. Warum soll es kritisch sein? Vielleicht ist es ja das bessere
Produkt.
Vanye R. schrieb:> Da wird wohl wenigsten> Misra genutzt:
Alleine die Vorstellungen, so etwas wie Misra würde irgend etwas an der
Situation ändern ist schon realtätsfremd.
C ist per Definition und Grundkonzeption eine Sprache, die halt dem
Programmierer alle Freiheiten gibt, auch die mit dem Schuss in den
eigenen Fuss. Daran ändert auch Misra nichts.
Oliver
Oliver S. (oliverso)
20.08.2024 09:46
>C ist per Definition und Grundkonzeption eine Sprache, die halt dem>Programmierer alle Freiheiten gibt, auch die mit dem Schuss in den>eigenen Fuss. Daran ändert auch Misra nichts.
Doch, genau das ändert Misra. Das ist Sinn und Zweck von Misra. Was die
meisten Entwickler nicht mögen: dass Misra genau diese Freiheiten von C
einschränkt.
> Daran ändert auch Misra nichts.
Das bedeutet vermutlich das du den Standard noch nicht gelesen hast und
das er bei dir auch nicht automatisch ueberprueft wird oder?
Vanye
>Das bedeutet vermutlich das du den Standard noch nicht gelesen hast und>das er bei dir auch nicht automatisch ueberprueft wird oder?https://www.absint.com/rulechecker/index.htm
> Und C nicht? 🤣
Nein. C ist einfach ein durchgesetzter von allen genutzter Standard.
Kein guter! Aber ein Standard. Man muss sich Fragen ob seine Nachteile
nicht durch den Vorteil ein Standard zu sein aufgehoben werden.
Vergleich es mit LED-Leuchtmitteln. Sind Gluehbirnen sicher oft
ueberlegen. Kann ich aber nirgends einfach so auswechseln weil es keinen
Standard ist.
So ist es mit jeder neuen Schickimickisprache die gerade durch Dorf
getrieben wird auch. Und das die Rustanbeter fuer alles eigene Woerter
und Verhaltensweisen erfinden muessen hinterlaesst schon etwas von
Zeugen Jehova oder so auf dem Level. Man koennte sagen das Ambiente
stimmt nicht. .-)
Vanye
Vanye R. schrieb:> Nein. C ist einfach ein durchgesetzter von allen genutzter Standard.
Tja, C++ ist auch standardisiert, aber sobald man das einbringt wird C
mit Inbrunst verteidigt...
Niklas G. schrieb:> Tja, C++ ist auch standardisiert, aber sobald man das einbringt wird C> mit Inbrunst verteidigt...
Es ist doch eher so, dass Rust mit Inbrunst verteidigt wird. Und C muss
verteidigt werden gegen Assembler, weil es die Programmierung von von
MCs erleichtert, vor allem wenn man mit verschiedenen zu tun hat.
Was jetzt C++ in diesem Zusammenhang zu suchen hat, weiß ich auch nicht
genau, aber es gibt halt gehäuft Nachrichtenaustausch zwischen Objekten
- wo C++ eben auch seine Vorteile hat. Außerdem kann man ja auch mal was
neues Lernen, und da die Bibliothekswelt in C++ (oder die
Weiterentwicklung) auch top ist (Haskell-Bib-Einträge gab es nur zu
Hype-Zeiten), warum nicht? ;)
Rbx schrieb:> Und C muss> verteidigt werden gegen Assembler, weil es die Programmierung von von> MCs erleichtert, vor allem wenn man mit verschiedenen zu tun hat.
Es ist zwar natürlich wahr, dass C die Portierung zwischen verschiedenen
Architekturen deutlich vereinfachen kann, es ist aber genauso wahr, das
C auf JEDER Architektur zumindest tendenziell weniger effizient ist
als eine Umsetzung in Asm.
Ersteres preisen die C-Gurus natürlich euphorisch an, letzteres sind sie
nicht bereit zuzugeben...
Diese armseligen C-only-Typen sind genauso hirnlos-gläubig wie die
Apologeten aller anderen Sprachen. Oft ist die Ursache nur eine:
Sie können einfach nix anderes, zumindest nicht wirklich.
Leute, die wirklich programmieren können, lachen über diese ganzen
einsprachigen Idioten. Ganz besonders über die, die zwar genug wissen,
um zu merken, dass sie da ein Kompetenz-Defizit haben, aber eben
öffentlich lieber als bedingungslos-gläubiger Apologet eben der Sprache
aufzutreten, die sie halt können.
Armselige hirnlose Dumpfbrammen.
> Tja, C++ ist auch standardisiert, aber sobald man das einbringt wird C> mit Inbrunst verteidigt...
Den Eindruck habe ich nicht! Im Embeddedbereich ist es eher so das C++
leise ignoriert wird. :)
Vermutlich sogar zu recht. C++ waere IMHO die bessere Wahl, aber nur
wenn man einiges im Embeddedbereich bewusst ungenutzt laesst. Das setzt
aber voraus das man diese Sprache gut drauf hat um dann bewusst nur
Teile zu verwenden und da scheint mir C++ zu komplex. So viele Leute die
sagen koennen das sie den Sprachumfang komplett drauf haben scheint es
bei C++ nicht zu geben. Jedenfalls nicht im Embeddedumfeld wo die Leute
ja auch noch andere Faehigkeiten vorweisen muessen.
Aber vielleicht schaffen da ja RP2040 oder RP2350 ein umdenken. Die
breite Ausstreuung von Dualcores fuer jedermann zusammen mit der PIO die
auch komplexe Sachen Timinggenau erlauben wuerden es vermutlich moeglich
machen C++ sagen wir mal lockerer einzusetzen. Und das viele Ram hilft
da auch noch.
Unser heutiges Ueberflussleben ist schon hart. Frueher war alles besser.
:-D
Man man sollte nicht vergessen, die Intention von Sprachen wie Rust oder
Go ist es gute zuverlaessige Programme auch von Leuten aus der
Regionalliga zu bekommen die man entsprechend gering bezahlen kann.
Hinter diesen Sprachen stecken IMHO auch grosse wirtschaftliche
Interessen.
Vanye
Ist Rust die Lösung für alle Probleme? Nö, natürlich nicht.
Aber: Es ist ein Versuch, mit einer neuen Programmiersprache
Anwendungsbereiche abzudecken, die bisher ganz gut von C (und C++)
versorgt wurden, ohne jedoch diesen absoluten Fokus auf maximale
Performance und "der Programmierer wird schon wissen, was er tut" zu
setzen. Das finde ich gut. Im allgemeinen weiß man zwar, was man tut,
aber Fehler oder Unachtsamkeiten passieren auch den besten Leuten und
dann ist man froh über eine Sprache, bei der das nicht direkt zur
Katastrophe führt.
Vanye R. schrieb:> Man man sollte nicht vergessen, die Intention von Sprachen wie Rust oder> Go ist es gute zuverlaessige Programme auch von Leuten aus der> Regionalliga zu bekommen die man entsprechend gering bezahlen kann.> Hinter diesen Sprachen stecken IMHO auch grosse wirtschaftliche> Interessen.
Sieh es mal so: Es gibt nur wenige Leute, die nicht in der
"Regionalliga" arbeiten, du wirst also immer massenweise dieser Leute
bekommen. Aktuell schreiben die murksigen C- und C++-Code, obwohl
genügend Leistung vorhanden wäre, dass man Sprachen benutzen könnte, die
unproblematischer sind. In Zukunft schreiben die hoffentlich murksigen
Rust-Code, bei dem zumindest einige Fehlerklassen nicht mehr auftreten
können, die Software wird also insgesamt besser, trotz gleichbleibender
Qualifikation und Codequalität.
Ob S. schrieb:> es ist aber genauso wahr, das> C auf JEDER Architektur zumindest tendenziell weniger effizient ist> als eine Umsetzung in Asm.
Jetzt riecht es auf einmal ganz besonders streng nach "Moby".
Ob S. schrieb:> Ersteres preisen die C-Gurus natürlich euphorisch an, letzteres sind sie> nicht bereit zuzugeben...
Und lassen dabei gelegentliche Fettnäppchen auch nicht aus. Außerdem
muss man ja auch fragen, wie hoch das technische Interesse wirklich ist,
wenn man sich nicht mit Asm-Code auskennt. ARMs haben nicht viele
Befehle, allerdings ist der Assemblercode auch reichlich stupide. Stört
aber nicht, wenn man mehr wissen will - ein Asm? Pfui, Igitt, Ieebaba,
wegdamit! usw. passt einfach nicht in diesem Zusammenhang. MCs verstehen
heißt doch auch, sich mit der Hardware auseinanderzusetzen. Die
C-Entwickler waren ja auch sehr gut in Asm und konnten sich bei der
BS/OS-Programmierung auf ein Minimum Asm beschränken.
C-Only kann dann auch eigentlich nicht richtig C, weil ein gewisser
Asm-Hintergrund ja irgendwo auch noch die halbe Miete ist.
Aber die richtigen Gurus, die vor beidem nicht zurückschrecken, können
einem regelrecht Angst machen - sofern die nicht immer wieder
beeindrucken. Ist halt nicht nur Asm und C bei denen, sondern auch ein
theoretisch-praktischer Hintergrund, der weit von dem weg ist, was sich
der normaler Mensch überhaupt vorstellen kann.
Früher kamen solche Leute, gerade bei der E-Technik eher aus dem
Asm-Pascal-Bereich.
F. schrieb:> In Zukunft schreiben die hoffentlich murksigen> Rust-Code, bei dem zumindest einige Fehlerklassen nicht mehr auftreten> können, die Software wird also insgesamt besser, trotz gleichbleibender> Qualifikation und Codequalität.
Nützt nichts, wenn man besoffen, aber angeschnallt in den Jägerzaun
brettert und zuletzt von einem Holzpfahl abgestochen wird.
Der Watcom C und Fortran - Compiler, bzw. das Entwicklungskit ist viel
besser, das kann man auch in einem alten Windows auf den USB-Stick
installieren. Offline, in der stillen Kammer, ganz in Ruhe usw.
Bei Rust braucht man ein Linux und Linux Offline ist ja auch irgendwie
schwierig.
Rust werde ich genau dann ernst nehmen, wenn die Community es schafft,
eine funktionierende Offline-Version für Free-DOS anzubieten.
https://www.reddit.com/r/rust/comments/ask2v5/dos_the_final_frontier/
Auf die ständige kognitive Dissonanz-Bereinigung habe ich auch keinen
Bock - das kann man eine Zeit lang amüsant finden, langweilt in letzter
Zeit aber nur noch.
Diese Rust Jünger können sich mal ein Beispiel an FreePascal nehmen -
bevor die einen auf Heiligsprechung machen.
Alte Computer wie z.B. in Museen haben oft nur einen in Pascal
entwickelten Emulator für DOS.
Harald K. schrieb:> Ob S. schrieb:>> es ist aber genauso wahr, das>> C auf JEDER Architektur zumindest tendenziell weniger effizient ist>> als eine Umsetzung in Asm.>> Jetzt riecht es auf einmal ganz besonders streng nach "Moby".
Tippe eher auf c-hater, das einzige Ergebnis einer Googlesuche nach
"Dumpfbramme":
Beitrag "Re: Ltspice: Optimierung vieler Parameter"
Was soll das überhaupt sein, ein unpolierter Stahlklotz?
https://de.wikipedia.org/wiki/Bramme
Rbx schrieb:> F. schrieb:>> In Zukunft schreiben die hoffentlich murksigen>> Rust-Code, bei dem zumindest einige Fehlerklassen nicht mehr auftreten>> können, die Software wird also insgesamt besser, trotz gleichbleibender>> Qualifikation und Codequalität.>> Nützt nichts, wenn man besoffen, aber angeschnallt in den Jägerzaun> brettert und zuletzt von einem Holzpfahl abgestochen wird.
Ich weiß ehrlich nicht, was du mir damit sagen willst.
Ich habe kurz skizziert, warum ich denke, dass eine moderne Sprache, die
die selbe Nische bespielt, in der auch C erfolgreich ist, erstrebenswert
ist, weil dort extrem viel Code benötigt und entwickelt wird und man für
diese Masse an Code nicht die notwendige Anzahl von Leuten mit extrem
guter Qualifikation bekommen kann, da es davon nur sehr wenige gibt.
Eine moderne Sprache könnte hier helfen, einige Klassen mit geringen
Performanceeinbußen (die heute dank üppiger Leistung viel leichter
verschmerzbar sind) leicht vermeidbarer und in der Realität
problematischer Fehler einfach schon zur Entwicklungszeit gar nicht erst
aufkommen zu lassen, was die insgesamte Softwarequalität verbessert. Ob
die Sprache nun Rust sein muss? Mir echt egal, mir geht's da ums
Prinzip.
> Der Watcom C und Fortran - Compiler, bzw. das Entwicklungskit ist viel> besser, das kann man auch in einem alten Windows auf den USB-Stick> installieren. Offline, [...] Rust [...] Linux [...] Free-DOS [...] kognitive
Dissonanz-Bereinigung [...] FreePascal [...] Heiligsprechung [...] Alte Computer
[...] in Museen
Ich weiß ehrlich nicht, was du mir damit sagen willst.
Harald K. schrieb:> Du halluzinierst:
Nö, den Windows-Quark habe ich runtergeschmissen, Rust läuft, und das
fast ungefragt viel schwupptiger und seriöser und zuverlässiger in
Linux.
F. schrieb:> Ich weiß ehrlich nicht, was du mir damit sagen willst.
Das war auch nur ein Test, ob du überhaupt erreichbar bist, das ist
nämlich der übliche Rust-Prediger nicht.
> Sieh es mal so: Es gibt nur wenige Leute, die nicht in der> "Regionalliga" arbeiten, du wirst also immer massenweise dieser Leute> bekommen.
Das ist eine denkbare Betrachtungsweise. Ich wuerde aber nicht so
bezahlt werden wollen. .-)
Vanye
Das scheint hier ja in einen wilden Streit zwischen C, Fortran, Basic,
etc und Rust Fans auszuarten.
Hier einfach ein paar Punkte, die Rust meiner Meinung nach besser macht
als andere Sprachen, das heißt aber nicht dass andere Sprachen irgendwie
schlecht wären oder keine eigenen Vorteile hätten:
- Na klar und oft zitiert: Speichersicherheit. Rust lässt einen
standardmäßig keinen Unsinn machen. Das heißt aber nicht dass man das
nicht kann, dafür gibt es unsafe {}, dann muss man sich halt wie in C
und ASM selbst drum kümmern.
- Die Speichersicherheit erstreckt sich im Embedded-bereich auch auf
Peripherieregister und ganze module. Es ist in safe Rust schlicht
unmöglich einen DMA-Kanal aus versehen zwei mal gleichzeitg zu
verwenden. Jedes Peripheral ist im Grunde einfach ein leeres struct von
dem bei der Initialisierung nur eine einzige Instanz erzeugt wird. Da
das struct aber leer ist, fliegt es bei der Kompilierung raus und hat
keine Performanceauswirkungen. Trotzdem gelten dieselben Regeln wie für
Speicher: Genau eine Besitzer, entweder mehrere readonly Referenzen oder
eine RW Referenz.
- Interrupts: Es ist in Rust weder möglich unsynchronisiert auf globale
Variable zuzugreifen, noch Code zu schreiben, bei dem eine
Interruptunterrechung Probleme machen könnte. Auch kann man nicht
vergessen danach die Interrupts wieder zu aktivieren.
- Speicher: Embedded Rust hat standardmäßig nur .data, .bss und den
Stack. Einen Heap gibt es von alleine nicht. Braucht man aber auch
nicht, man kann problemlos ganze Netzwerkstacks ohne programmieren. Wenn
man doch einen Heap will, gibts das aber auch, für fast jede Architektur
gibt es eine genau dafür spezialisierte Implementierung.
- Performance 1: Durch konsequente Verwendung des Stacks und nur
seltener verwendung von spezialisierten Heap-implementierungen (man kann
sogar mehrere für die jeweilige Anwendung optimierten Heaps verwenden),
kann Rust effizienter sein als standard C malloc()
- Performance 2: Rust hat standardmäßig keine virtual funcation tables
wie C++ (auch hier gilt, wenn man es will bekommt man es trotzdem). Auch
Generics machen keine Probleme, im Gegenteil sie werden gerade im
Embedded bereich viel verwendet.
- Performance 3: Spätestens wenn man in C/C++ ein RTOS braucht, ist Rust
vorne. Statt einem OS mit Kontextwechsel, mehreren Stacks, ... wird
einfach async verwendet. Damit lassen sich extrem einfach Dinge wie
Timeouts umsetzen. Bei Netzwerkstacks unterscheidet sich die API nur
minimal von Netzwerk auf Desktop. Async ist nachweislich schneller als
ein RTOS und erzeugt kleineren Code. Auch async braucht keinen Heap,
alle Größen können statisch berechnet werden.
- Performance 4: In Rust werden fast immer zero-cost abstractions
verwendet, also Abstraktion ja, Overhead nein. Obwohl die API teilweise
genauso high-Level ist wie man es aus der Desktop-Programmierung kennt,
verursacht das keine Performanceeinbußen.
- Stromverbrauch: Da async Rust im Regelfall von Interrupts getrieben
wird, wird der Prozessor während dem Leerlauf im Regelfall automatisch
ohne weitere Konfiguration in den Slep-Mode versetzt. Selbst ohne
besondere Vorkehrungen ist der Stromverbrauch fast Baterie-tauglich.
- Auch in Rust gibt es inline ASM und man kann C-Code einbetten (und das
ganz ohne komplizierte build-scripts)
Ich kann jedem nur mal empfehlen z.B. Embassy (https://embassy.dev/)
auszuprobieren. Umgekehrt habe ich auch schon selbst Projekte mit C und
AVR-ASM umgesetzt. Für ganz kleine Projekte mach ich das auch immer
noch.
Wenn ich demnächst mal Zeit habe werde ich mal einen Artikel im Wiki zum
Thema Embedded Rust schreiben.
Ich würde mir wünschen mehr über solche technischen Unterschiede zu
diskutieren und sich nicht gegenseitig als "Rust-Prediger" zu
beschimpfen oder sich zu beschweren, dass Rust nicht auf DOS läuft.
Genau deswegen hab ich mir die Mühe gemacht diesen Beitrag zu schreiben.
> The TRACTOR program aims to automate the translation of legacy C code to> Rust. The goal is to achieve the same quality and style that a skilled> Rust developer would produce, thereby eliminating the entire class of> memory safety security vulnerabilities present in C programs.
Das ernsthaft jemand glaubt, das währe machbar, unglaublich.
C ist eine formal definierte Sprache. Abgesehen vom UB, ist genau
definiert, was was tut. Würde man das 1:1 in Rust übersetzen, muss man
zwangsläufig auch die selben Bugs weiterhin drin haben, ansonsten ist es
nicht das selbe Programm.
Darum wollen sie wohl LLMs nutzen, und es nicht 1:1 übersetzen. Nur,
wenn man das nicht tut, also das C Programm nachher nicht mehr tun muss,
was der Programmierer hingeschrieben hat, ist effektiv komplett
undefiniert, was es tun wird und tun kann, man hat gar keine formalen
Garantien mehr.
Man kann nicht beides haben. Entweder, die Übersetzung ist formal
gleichwertig (inklusive Fehler), oder was es tut kann nicht mehr vorher
gesagt werden, und Gott weiss was da raus kommt, jedenfalls sicher
nicht, was der ursprüngliche Entwickler geschrieben hat.
Bei Computern gibt es keine Wunder und keine Magie. Auch nicht, wenn man
ein LLM nutzt.
Naja, die Idee ist sicher, über vorhandene Artefakte (Spezifikationen,
Tests, Handbücher, Code, etc.) LLM-gestützt eine Spezifikation zu
erarbeiten und daraus dann LLM-gestützt neuen Code zu erzeugen. Im
Prinzip kann das schon funktionieren und man wird dadurch sicher einige
Fehler los. Nur: Im Prinzip. Wie es in der Realität aussieht, ist eine
andere Frage, das kann ich zu schlecht bewerten, dafür habe ich zu
wenige Erfahrungen damit.
Niklas G. schrieb:> Harald K. schrieb:>> Jetzt riecht es auf einmal ganz besonders streng nach "Moby".>> Tippe eher auf c-hater
Das passt.
Naja, der Kornpichler ist zwar einigermaßen erfahren und auch halbwegs
intelligent, aber halt auch doch kein Überflieger. Sonst hätte er das
locker alleine ermitteln können...
Wollte er aber wohl garnicht. Oder schlimmer: sehr wahrscheinlich weiß
er es längst (ist ja schließlich auch nicht besonders schwer zu
ermitteln). Aber dann hätte ich natürlich argumentativ gleich einen ganz
anderen Hintergrund. Dem wollte er sich wohl nicht aussetzen. Da ist es
für ihn doch deutlich einfacher, mich zum Moby zu deklassieren...
Das Problem bei Moby war: der konnte eben nur Asm. Und das nicht mal
gut. Und genau das ist bei mir anders. Und davor haben Typen wie der
Kornpichler halt Angst. Jörg Wünsch ist genau so einer, überhaupt viele
von der "alten Garde".
Viele von denen habe sich auch mal in Asm versucht, es aber nie zu
besonderer Leistung geschafft. Hauptsächlich übrigens wohl deshalb, weil
sie Asm nur in Anhängseln zu ihren hauptsächlich in C verfassten
Anwendungen benutzt haben. Das ist eben Mist, mit diesem Ansatz kann Asm
nur einen kleinen Teil seiner Vorteile ausspielen. Viele, sehr wirksame
Optimierungen werden allein dadurch unmöglich, dass halt der Code in's
C-ABI passen muss. Jedenfalls, wenn man die Vorteile der Benutzung der
C-Runtime nicht aufgeben will. Oder kann...
Ob S. schrieb:> Und davor haben Typen wie der Kornpichler halt Angst
Gut zu wissen, wenn mir das nächste Mal wer die Brieftasche klauen will
sag ich "ey, ich kann Assembler!".
Boah, dieses konstante Geningel der Rust-Adapten nervt. Scheint so eine
Art vegane Programmiersprache zu sein, mit der man allen auf den Sack
gehen muss.
Jemin K. schrieb:> Boah, dieses konstante Geningel der Rust-Adapten nervt. Scheint so eine> Art vegane Programmiersprache zu sein, mit der man allen auf den Sack> gehen muss.
Das konsequente Beharren der C-Only-Typen nervt. Unfähig, die Vorteile
zu erkennen, die Rust bietet. Das ist was, was sich wirklich über
Assembler erhebt (also eine echte Hochsprache) und nicht nur effektiv
ein lausiger Macro-Assembler mit viel (effektiv überwiegend nutzlosem)
Syntax-Bombast ist.
Daniel A. schrieb:> Man kann nicht beides haben. Entweder, die Übersetzung ist formal> gleichwertig (inklusive Fehler), oder was es tut kann nicht mehr vorher> gesagt werden, und Gott weiss was da raus kommt, jedenfalls sicher> nicht, was der ursprüngliche Entwickler geschrieben hat
Es reicht ja, wenn es "klaren Code" (der offensichtlich keine
Fallstricke enthält) übersetzt und bei "unklarem Code" (mit
Fallstricken) Eingriff fordert. Vielleicht mit alternativen Vorschlägen.
Quasi wie ein gutes Merge-Tool, dass vieles allein schafft aber ab und
zu nachfragt.
Harald K. schrieb:> Und man hätte keine Sprache mit CoC.
Jetzt faselst Du schon zum wiederholten Mal in wenigen Tagen über einen
Code Of Conduct. Offenbar ist es für Dich unerträglich, wenn Menschen
respektvoll miteinander umgehen wollen.
Vanye R. schrieb:>> Und C nicht? 🤣>> Nein.
Doch. Das erkennt man schon an Glaubenskriegen wie diesem.
> C ist einfach ein durchgesetzter von allen genutzter Standard.
Die allermeisten Entwickler nutzen C nur, wenn sie müssen, und zwar...
> Kein guter!
...genau deswegen.
> Aber ein Standard. Man muss sich Fragen ob seine Nachteile> nicht durch den Vorteil ein Standard zu sein aufgehoben werden.
Meine gute Erziehung verhindert, Dir detaillierter zu erklären, was
dieser Standard mich mal kreuzweise kann, solange ich meine Aufgaben
ohne ihn besser, schneller, komfortabler, einfacher und sicherer lösen
kann. C mache ich heute nur noch, wenn mich jemand mit vorgehaltener
Waffe dazu zwingt.
Derartige Aussagen beweisen nur, daß es sehr wohl um einen Glaubenskrieg
geht, und manche Leute sich wegen religiöser Dogmen wie diesem nicht nur
selbst das Leben schwer machen, sondern es auch anderen schwer machen
wollen. Und wer das nicht mitmacht, ist ein Ungläubiger und wird mit
Herabwürdigung bestraft!
> C mache ich heute nur noch, wenn mich jemand mit vorgehaltener> Waffe dazu zwingt.
Dazu braucht es keine Waffe. Das Arbeitsamt reicht. Denn wenn du
im Embeddedbereich arbeiten willst und kein C kannst dann bist
du praktisch arbeitslos.
Vanye
Ein T. schrieb:> Offenbar ist es für Dich unerträglich, wenn Menschen> respektvoll miteinander umgehen wollen.
CoC hat nichts mit respektvollem Umgang miteinander zu tun, sondern tut
nur so. Tatsächlich ist das ein moralinsaures Sprech- und Denkverbot,
ausgedacht von vermeintlich progressiven Personendarstellern aus
vermeintlich liberalen Kreisen in den USA.
Vanye R. schrieb:> Dazu braucht es keine Waffe. Das Arbeitsamt reicht. Denn wenn du> im Embeddedbereich arbeiten willst und kein C kannst dann bist> du praktisch arbeitslos.
Der Witz ist: Erst wenn man wirklich versteht, was C tut, kann man
einschätzen, wie Scheiße C ist.
D.h.: Das Problem, kein C zu können, ist oft überhaupt kein Problem.
Eher das Problem, kein C zu wollen.
Aber klar, für Geld ist man auch mal zu Kompromissen bereit und benutzt
wieder besseren Wissens diesen unnützen Mist. Wenn's so gewollt ist und
bezahlt wird.
Für Geld mache ich vieles Widerwärtige. Sogar Programmierung in C.
Freiwillig aber niemals.
Ob S. schrieb:> Der Witz ist: Erst wenn man wirklich versteht, was C tut, kann man> einschätzen, wie Scheiße C ist.
Bei deinem Geschreibsel fällt mir sofort Folgendes ein:
Wie soll ich wissen was ich denke,
bevor ich lese was ich schreibe.
In diesem Sinne: Lies die Beiträge vor dem Absenden vielleicht erst
einmal durch.
Vanye R. schrieb:>> C mache ich heute nur noch, wenn mich jemand mit vorgehaltener>> Waffe dazu zwingt.>> Dazu braucht es keine Waffe. Das Arbeitsamt reicht.
Arbeitsämter (ich glaube, die heißen jetzt anders) sind nicht mein
Maßstab.
Nebenbei bemerkt, sollen auch gute Python-, Perl-, Ruby-, Rust- und
andere Entwickler ihren Lebensunterhalt ganz gut bestreiten können.
> Denn wenn du> im Embeddedbereich arbeiten willst und kein C kannst dann bist> du praktisch arbeitslos.
Das stimmt, macht C aber trotzdem nicht zu einem eleganten Werkzeug. Und
C zu können, hilft auch außerhalb des Embedded-Umfelds enorm. Wer
bestreitet das?
Man braucht deutlich mehr kryptische Zeichen, die ein Tribut and die
Maschinenlesbarkeit sind.
Und hier steht der Mensch und der einfache Syntax im Focus, die Maschine
in Form des Compilers hat etwas mehr Arbeit:
1
frommachineimportPin
2
fromtimeimportsleep
3
4
BUILT_IN_LED_PIN=25
5
6
led=machine.Pin(BUILT_IN_LED_PIN,machine.Pin.OUT)
7
8
whileTrue:
9
led.high()
10
sleep(0.5)
11
led.low()
12
sleep(0.5)
In der heutigen Zeit ist nicht einzusehen, dass der Mensch mehr Arbeit
in syntaktische Unzulänglichkeiten steckt, wenn es Maschinen besser
können.
Ob S. schrieb:> Der Witz ist: Erst wenn man wirklich versteht, was C tut, kann man> einschätzen, wie Scheiße C ist.
Da Du auch mit Deinem neuen Namen nach wie vor exakt überhaupt keine
Ahnung von C hast, ist Dein Geschreibsel so wie eine Empfehlung des
Papstes über beglückendes Familienleben.
Niklas G. schrieb:> Was wird dir denn verboten zu sagen und zu denken?
Es wird die Bedeutung von etablierten Begriffen verdreht, um ihnen eine
ausschließliche Einzelbedeutung unterzujubeln, und wer sich nicht an
diese Diktion hält (die von jungen antikolonialistischen Soziologen
festgelegt wird), der wird "gecancelt".
Und dann kommt halt sowas dabei raus:
https://blog.fefe.de/?ts=98450c8d
Harald K. schrieb:> Es wird die Bedeutung von etablierten Begriffen verdreht, um ihnen eine> ausschließliche Einzelbedeutung unterzujubeln, und wer sich nicht an> diese Diktion hält (die von jungen antikolonialistischen Soziologen> festgelegt wird), der wird "gecancelt".> Und dann kommt halt sowas dabei raus:
Das war nicht die Frage. Die Frage war, was DIR verboten wird. Was
möchtest DU sagen oder denken, was DU jetzt nicht mehr darfst?
Im verlinkten Artikel wird übrigens nur kritisiert, dass die
Entscheidung geheim getroffen wird, nicht der CoC an sich:
At present, what we have is 'trust me, there’s problems, and we need to
deal with them, but we can’t say anything.' I don’t feel comfortable
with that kind of power being wielded in that much secrecy."
Fefe schreibt:
> Er fand etwas lustig.
Wenn ich schreibe:
"Ich finde es lustig wie du dich bemühst, hier die Performance zu
verbessern"
Ist das voll in Ordnung? Ich finde ja nur was lustig. Genauer geht Fefe
nicht drauf ein, warum wohl...
Niklas G. schrieb:> Das war nicht die Frage.
Das war nicht die Frage, die Du gestellt hast. Das war aber meine
Antwort. Ich muss nicht persönlich von einer Zeitgeisterscheinung
betroffen sein, um sie ablehnen zu dürfen.
Harald K. schrieb:> Das war nicht die Frage, die Du gestellt hast. Das war aber meine> Antwort. Ich muss nicht persönlich von einer Zeitgeisterscheinung> betroffen sein, um sie ablehnen zu dürfen.
Nichtsdestotrotz bleibt es ein bisschen arm, über Ententeiche zu
Gackern, wenn alle Enten und Teiche weit weg sind.
Sheeva P. schrieb:> Nichtsdestotrotz bleibt es ein bisschen arm
Nö, das sehe ich anders. Kritik an Dingen nur noch Menschen
zuzugestehen, die ganz unmittelbar davon betroffen sind, wäre eine
massive Fehlentscheidung.
Denn das wäre äquivalent zu:
Du darfst erst dann ein Produkt in Frage stellen, wenn Du auch wirklich
Krebs davon bekommen hast (und das nachweisen kannst).
Bis dahin wird Dir Dein Arbeitgeber weiterhin schicke Asbestjacken für
die Arbeit am Hochofen zur Verfügung stellen.
Announcement: there is an English version of this forum on 
Thread beobachten
Seitenaufteilung abschalten