Hallo, macht es Sinn für einen 32-Bit Microcontroller in der Industrie die Hilfe von AI beim Programmieren in Anspruch zu nehmen, wenn die Copiloten (GitHub, Claude etc.) keine Infos zu den Datenblättern haben? Wie macht ihr das?
Kannst Du denn programmieren?
wenn die Copiloten...keine Infos zu den Datenblättern haben?
Warum sollten sie das zu den öffentlich zugänglichen RM nicht haben? Nutzt du Controller die ein NDA haben?
für einen 32-Bit Microcontroller in der Industrie die Hilfe von AI beim Programmieren in Anspruch zu nehmen
Ich hab das vor Monaten privat mit einem kostenlosen Copilot für einen I2C Stromsensor ausprobiert. Im Netz hab ich keine HAL für den Sensor gefunden. Anfangs die Register im Header angelegt, schon da hat er kräftig unterstützt. Dann wurde ich mutiger. Mal gesagt er soll die komplette HAL schreiben zum Sensor, ZACK da. Lief bis auf Kleinigkeiten ohne Probleme.
Anderes Beispiel: bei einem vorhandenen Projekt gesagt er soll zum LWIP Webserver noch kurz Websocket dran stricken. Bums, fertig. Kleines Problem über den Debugger gesucht/behoben, ging.
macht es Sinn
Das ist eine ganz eigene (philosophische) Frage. Ich finde es teils ganz praktisch. Es erhöht definitiv die Geschwindigkeit in der man ein Projekt umsetzt. Vielleicht nicht immer. Man muss auch schon eine gewisse Struktur vorgeben. Alles auf einmal ist meiner Meinung nach auch schlecht. Lieber Stück für Stück. Teilweise hat man komplett Pech.
Gast
#8080786
Hallo, macht es Sinn für einen 32-Bit Microcontroller in der Industrie die Hilfe von AI beim Programmieren in Anspruch zu nehmen, wenn die Copiloten (GitHub, Claude etc.) keine Infos zu den Datenblättern haben? Wie macht ihr das?
Mittel- bis langfristig bist du als NI aus dem Rennen,wenn du es nicht machst.Weil andere, die es machen, viel schneller und effizienter(billiger) sind
Mittel- bis langfristig bist du als NI aus dem Rennen,wenn du es nicht machst.
Korrekt. Damit wird man so 5-10x schneller. Ist aktuell aber noch sehr teuer, daher noch nichts fuer kleine Firmen/Projekte.
Vanye
Mittel- bis langfristig bist du als NI aus dem Rennen,wenn du es nicht machst.
Wird sich zeigen. Momentan wird viel über ausufernde Kosten und Folgekosten berichtet.
Gast
#8080848
Wird sich zeigen. Momentan wird viel über ausufernde Kosten und Folgekosten berichtet.
Vogel friss oder stirb
Hans W. schrieb:
Wird sich zeigen. Momentan wird viel über ausufernde Kosten und Folgekosten berichtet.
Vogel friss oder stirb
Giftweizen...
Also friß UND stirb?!
Mittel- bis langfristig bist du als NI aus dem Rennen,wenn du es nicht machst.
Korrekt. Damit wird man so 5-10x schneller. Ist aktuell aber noch sehr teuer, daher noch nichts fuer kleine Firmen/Projekte.
Teuer? Ein Standard Claude Abo kommt so auf 20€ und ermöglicht schon ungemein viel. Das ist doch keine große Summe wenn mein 5k€ Entwickler auch nur eine Stunde im Monat spart. Und die Zeitersparniss ist größer. Viel größer.
Ein Standard Claude Abo kommt so auf 20€ und ermöglicht schon ungemein viel.
Kollidiert allerdings häufig mit dem Datenschutz des Unternehmens. Wer damit arbeitet, veröffentlicht quasi nebenbei das interne Know-How vom Projektverzeichnis.
:
Bearbeitet durch User
Gast
#8080864
Also friß UND stirb?!
So sarkastisch würde ich es nciht sehen. Musk prognostizierte kürzlich, dass in ein paar Jahren keiner mehr arbeiten muss. Aber die NI selber scheint lang-langfristig gegenüber KI kaum Überlebenschancen zu haben.
Claude (Copilot vermutlich genauso) findet alle Datasheets vollautomatisch, muss man nichtmal verlinken.
Es ist z.B. sehr praktisch um Magic Numbers im Code aufzuräumen. Nach einer ausführlichen Debugging-Schlacht hatte ich Mengen von Code im Stil
1 |
|
was natürlich mies ist, mit einer kurzen Anweisung macht Claude daraus
1 |
|
2 |
|
3 |
|
4 |
|
Das als Massen-Bearbeitung in einem komplexeren Projekt ist super, von Hand hätte es ewig gedauert.
Es lässt sich verallgemeinert super als "schlaues Suchen+Ersetzen" nutzen, z.B. "Füge allen Implementationen von AbstractImu::start() einen Parameter uint16_t sampleRate hinzu" oder "Finde alle Klassen die 'final' sein könnten". Oder auch "Mache alle Änderungen des letzten git-Commits rückgängig die sich auf den IMU-Treiber beziehen".
Kollidiert allerdings häufig mit dem Datenschutz des Unternehmens. Wer damit arbeitet, veröffentlicht quasi nebenbei das interne Know-How vom Projektverzeichnis.
Das ist kein Datenschutz sondern Schutz von Geschäftsgeheimnissen.
Gast
#8080866
5-10x schneller
Minimum, langfristig wird der Geschwindigkeitsgewinn viel viel größer sein, Qualitätsgewinn (z.B. Medizintechnik, Diagnose) noch gar nicht erwähnt
Gast
#8080867
Das als Massen-Bearbeitung in einem komplexeren Projekt ist super, von Hand hätte es ewig gedauert.
Nicht nur DAS...
macht es Sinn für einen 32-Bit Microcontroller in der Industrie die Hilfe von AI beim Programmieren in Anspruch zu nehmen, wenn die Copiloten (GitHub, Claude etc.) keine Infos zu den Datenblättern haben ?
Pädagogische Gegenfrage: Braucht es für das Generation von Tests (bspw. Unit-test) für den erstellten (Applications-)Code unbedingt das Datenblatt ?
:
Bearbeitet durch User
Es gibt einen viel effizienteren Weg:
- KI beibringen, Registertabellen aus Datenblaettern in einen Geraetebeschreibungs-Dialekt (bevorzugt XML) umzuwandeln
- Bisschen nachbearbeiten (spezielle Funktionen wie Write one to clear o.ae.)
- Daraus den ganzen Rest wie C-Header, Doku, usw. per Style-Sheet generieren
Auch wenn die JSON-Formate meist in der OpenSource populaerer (da von Hand editierbar) sind: Sie bringen keine vergleichbare Validierung wie das XML-Oekosystem mit.
Der Ansatz laesst sich auch leichter lokal verfolgen, denn ich wuerde auch ungern eine auslaendische KI mit internem Knowhow trainieren wollen.
KI beibringen, Registertabellen aus Datenblaettern in einen Geraetebeschreibungs-Dialekt (bevorzugt XML) umzuwandeln
Du kennst die SVD Files von den Herstellern?
Du kennst die SVD Files von den Herstellern?
Die gibt's doch nur für MCU-Peripherie, nicht für separate Chips wie eben z.B. ein I²C-Accelerometer?
Es gibt einen viel effizienteren Weg:
Wird das wirklich gemacht für externe Peripherie? Hat das effektiv wirklich einen Vorteil? Bei der MCU-Peripherie haben die SVD-Files mindestens den Vorteil dass man im Debugger die Register schön anschauen kann, das geht aber bei externen ICs sowieso nicht so ohne weiteres bzw. könnte unangenehme Nebeneffekte haben.
- KI beibringen, Registertabellen aus Datenblaettern in einen Geraetebeschreibungs-Dialekt (bevorzugt XML) umzuwandeln
Da müsste man nicht viel beibringen, ein Beispiel in XML angeben und ein kurzer Prompt dürfte reichen. Aber der Rest...?
Die gibt's doch nur für MCU-Peripherie, nicht für separate Chips wie eben z.B. ein I²C-Accelerometer?
Das stimmt. Für separate ICs ist mir das auch noch nicht unter gekommen. Cool wäre es aber wenn die Hersteller dazu über gehen würden. Dann könnte man sich die HAL teils generieren lassen. Ganz ohne KI. Einfach mit einem Programm 😄
Der TO hat ja von uC geredet, da kenne ich das.
Cool wäre es aber wenn die Hersteller dazu über gehen würden.
Mir würd's reichen wenn die Dokumentation ansatzweise stimmen würde 🙄 Ich schreib lieber 100 Register-Definitionen selbst als tagelang fluchend zu analysieren was die einzelnen Bits wirklich bewirken...
Dann könnte man sich die HAL teils generieren lassen.
Luxus wär's ja wenn man eine funktionierende HAL/Treiber direkt vom Hersteller bekommen würde, dann bräuchte man gar nichts selber schreiben...
Der TO hat ja von uC geredet, da kenne ich das.
Ja aber da sind die SVD-Files doch gegeben und man muss die Registerdefinitionen nicht aus den Datasheets klauben.
:
Bearbeitet durch User
Wird das wirklich gemacht für externe Peripherie? Hat das effektiv wirklich einen Vorteil? Bei der MCU-Peripherie haben die SVD-Files mindestens den Vorteil dass man im Debugger die Register schön anschauen kann, das geht aber bei externen ICs sowieso nicht so ohne weiteres bzw. könnte unangenehme Nebeneffekte haben.
Wenn es ein Registerprotokoll ist, laesst sich faktisch alles ueber eine virtuelle Adressdekodierung in einer Registerkarte verarzten und in einen sehr duennen HAL-Layer codieren. Z.B. alles im Window "0x08000000" geht auf den i2c, usw. Und ja, es wird sogar ziemlich ausgiebig gemacht. Gleichzeitig wird so u.A. das Silicon (register-Mapping), die C-Treiber wie auch die Registerdokumentation aus der zentralen Beschreibung aktuell gehalten.
Spaetestens dann, wenn man die Geraete konfigurieren und fernsteuern will (a la modbus, CAN, usw.) amortisiert sich das, wenn man nur noch einen Client fuer alle Geraete braucht und nervige Versions-Mismatches nicht mehr auftreten.
Leider gibt's keinen akzeptierten "Standard", nach dem alle wie ein BSDL-File ihre Registermaps ausliefern (Obwohl es durchaus universelle Loesungen gibt). SystemRDL ist in einer gewissen Nische noch einigermassen etabliert, aber just kein XML-Dialekt.
SVD als XML-Dialekt ist wiederum sehr ARM-spezifisch und deckt andere Strukturen nur bedingt ab. Vor >20 Jahren wurde hier etwas einiges entwickelt (Stichwort "netpp/devdesc", auch OpenSource). Deckt auch heute noch die meisten Beduerfnisse ab.
Da müsste man nicht viel beibringen, ein Beispiel in XML angeben und ein kurzer Prompt dürfte reichen. Aber der Rest...?
Eben, der Rest... die restlichen 90% des Jobs sind Verifikation. Damit muss man die KI trainieren, sonst endet sie in klassischen Selbstueberschaetzung.
Und ja, es wird sogar ziemlich ausgiebig gemacht.
Was für IDEs können das? Also:
PC <-USB-> Debugger <-JTAG/SWD-> MCU <-SPI/I²C-> Sensor-IC
Die Register über MCU und Debugger auslesen und in der IDE darstellen?
a la modbus, CAN, usw.
Hmm, DBC-Files etc., aber Einbindung in eine IDE hab ich da auch noch nicht gesehen. Nur in dedizierte Tools à la CANoe, Code-Generierung darf man trotzdem selber klöppeln. Ein sauberes Format ist DBC nicht gerade, und XML schon gar nicht...
(Stichwort "netpp/devdesc", auch OpenSource). Deckt auch heute noch die meisten Beduerfnisse ab.
Auch ziemlich High-Level, damit kann ich keinen Accelerometer-IC ansteuern.
:
Bearbeitet durch User
Mir würd's reichen wenn die Dokumentation ansatzweise stimmen würde
Haha, das hat vermutlich jeder schon mitgemacht. Oder wenn Abläufe die eingehalten werden müssen nicht beschrieben werden 🤷
Luxus wär's ja wenn man eine funktionierende HAL/Treiber direkt vom Hersteller bekommen würde, dann bräuchte man gar nichts selber schreiben...
Klar, das wäre das Beste. Geschäftlich schreiben wir die meist trotzdem selbst. Einfach damit sie den Anforderungen entspricht und meist braucht man auch 90% der Dinge nicht.
Ja aber da sind die SVD-Files doch gegeben und man muss die Registerdefinitionen nicht aus den Datasheets klauben.
Eben. Ich hab ja oben geschrieben dass man eine KI nicht eine XML aus einem DB generieren lassen muss wenn es schon die SVD gibt.
Martin S. schrieb:
KI beibringen, Registertabellen aus Datenblaettern in einen Geraetebeschreibungs-Dialekt (bevorzugt XML) umzuwandeln
Du kennst die SVD Files von den Herstellern?
Geschäftlich schreiben wir die meist trotzdem selbst. Einfach damit sie den Anforderungen entspricht
Da müsste mal wer ausrechnen wie viele Millionen das die Industrie kostet, dass jede Firma ihre eigenen Treiber für die gleichen Komponenten baut. Oder immer wieder die selben Bugs in den Treibern der Hersteller sucht.
Register, Ports usw. stehen in den Header-Files vom Microcontroller HAL, falls heutzutage noch zusätzliche Treiber von Hand geschrieben werden. Jedoch wird für die KI ebenso der Kontext aus dem Hardware Manual sowie die bekannten Probleme benötigt, um z.B. Bitoperationen bzgl. der Byteorder richtig zu machen.
In einem Industrie Projekt müssten der KI alle Infos gegeben werden: Pinbelegungen, Compiler C-Code Erweiterungen, Libraries, Coding Rules, Anforderungen etc. damit ein hochwertiger Code entsteht! Das sind alles Informationen die nicht im Internet stehen bzw. die keine LLM (z.B. Claude) kennt. Dies Infos müssen der KI mitgeteilt werden, was möglich ist.
Zum Thema geistiges Eigentum haben die großen Anbieter ein Enterprise Model für Unternehmen, womit es zwar die "sichere" Möglichkeit zum Verwenden von Daten ohne Antrainieren von LLMs gibt. Jedoch muss das von den Lieferanten erlaubt sein!
Da ich den kontextbasierten KI-Einsatz noch nicht für Embedded-Code aufgesetzt habe, würde mich interessiern, ob das schon jemand macht und sagen kann ob der Aufwand beim Code-Review steigt bzw. sogar im schlimmsten Fall mehr repariert wreden muss?
Ich rede nicht von der Programmierung von Linux oder Web-Applikationen mit OpenSource aus GitHub, sondern meine klassische Microcontroller.
Da müsste mal wer ausrechnen wie viele Millionen das die Industrie koste
Wenn Chef es so will 🤷
Jedoch wird für die KI ebenso der Kontext aus dem Hardware Manual sowie die bekannten Probleme benötigt, um z.B. Bitoperationen bzgl. der Byteorder richtig zu machen.
Das fischt sich Claude vollautomatisch aus dem Internet. Den Namen des Mikrocontrollers anzugeben reicht. Und selbst den findet es meist automatisch aus der Projektdatei.
Pinbelegungen
Sollten sowieso irgendwo zentral stehen, bei den STM32 wird es in die main.h generiert, findet Claude automatisch.
Compiler C-Code Erweiterungen
Claude erkennt den Compiler am Makefile/CMakelists/... und findet die jeweiligen Erweiterungen im Netz, oder daran was im Projekt sonst noch so verwendet wird, z.B. compilerspezifische Attribute à la "attribute(( always_inline ))" etc.
Libraries
Dito, stehen im Makefile.
Coding Rules,
Dito wenn sie im Projekt-README stehen, sonst muss man das Dokument noch verlinken. Wenn man Copilot verwendet hat es vermutlich automatisch Zugriff auf alles in OneDrive/Sharepoint, bei GitLab Duo alles im Wiki. Allerdings passt sich Claude schon von ganz alleine an den allgemeinen Programmierstil im Projekt an.
Anforderungen
Wenn die im Projekt- Readme oder -Agents.md stehen werden sie auch gefunden.
die keine LLM (z.B. Claude) kennt.
Korrekt, daher setzen die LLMs Toolcalls bzw. MCP-Calls ab, wodurch die Agent-Runtime (also z.B. die Claude-Code-Anwendung an sich, oder die Copilot-Extension von VS Code) dann das Projekt durchsucht und die Info liefert. Das LLM sagt z.B. "grep -- -std= Makefile", die Runtime liefert das Ergebnis, und das LLM sieht dass der Compiler mit "-std=c++20" aufgerufen wird und erzeugt entsprechenden Code.
ob das schon jemand macht und
Ja, mit Claude Code Pro. Es ist geradezu schockierend wie selbstständig Claude das Projekt "begreift" und passenden Code erzeugt. Nahezu alle von dir genannten Infos werden vollautomatisch gefunden, sogar auch anhand von Dateinamen (eine Datei namens "MPU6050.c" enthält offensichtlich einen Treiber für die MPU6050), es kompiliert automatisch das Projekt (es findet automatisch heraus wie (C)Make aufgerufen werden muss) um Änderungen zu prüfen und ggf. Fehler zu beheben, es erkennt welche Fehler es selbst gemacht hat und welche vorher schon da waren, es arbeitet von alleine in einem temporären git-Worktree, es erkennt welche custom Tools als Post-Build-Step aufgerufen werden, es liest alle Doxygen-Kommentare und ruft Funktionen automatisch auf, es verwendet vollautomatisch das undokumentierte Custom-RTOS korrekt. Es ist unglaublich gut in "Transferleistung" - wenn irgendwo im Pojekt schon mal was ähnliches gemacht wurde, wird das automatisch als Vorlage genommen (natürlich ohne explizite Anweisung), es übernimmt ganz von alleine den "Projekt-Stil" selbst wenn dieser unüblich ist, es erkennt selbst exotische Design-Patterns und nutzt sie fließend... Man kann Oszilloskop-Screenshots reinreichen und nach Fehlern in Protokollen fragen, Screenshots von GUIs angeben und bekommt blitzschnell einen Nachbau im Toolkit der Wahl, Fotos von handgezeichneten Mock-Ups in fix-und fertige GUIs verwandeln ... Dinge die man Kollegen erst stundenlang erklären müsste macht Claude einfach so, vollautomatisch, ohne explizite Anweisung, ohne Rückfragen.
Der nächste Schritt ist es dem Agenten Zugang zur Hardware zu geben, per USB-Relaiskarte und Webcam oder so, vielleicht zur PC-Steuer-Software fürs Oszilloskop, und natürlich Debugger. Dann kann es Firmware vollautomatisch testen. Hat das hier schon wer ausprobiert?
Es ist wirklich gruslig, mittlerweile kann man eigentlich niemandem mehr raten Informatik oder Ingenieurswissenschaft zu studieren.
Es ist wirklich gruslig, mittlerweile kann man eigentlich niemandem mehr raten Informatik oder Ingenieurswissenschaft zu studieren.
Besser Kettensägentänzer.
Zählt das als Handwerk?
Nur solange bis die Hand noch drann ist, sonst ist es Handwerk ohne Hand.
Ich habe gerade mal ein kleines Tool auf SSE3 erweitert, einfach mal nach SSE3 gegoogled, mit googles Vorschlag von dessen KI begonnen, es nochmal verbessert weil coredump, hat er gleich erkannt woran das lag, aligned variante auch noch umgesetzt, dann kam googles KI noch auf die Idee das auf AVX2 umzustricken, das ganze dann noch just for fun in eine andere Sprache umgewandelt. Ausser Kleinigkeiten gab es keine Problem und ich habe weder noch was mit SSE3 oder AVX2 vorher gemacht, ausser dass ich theoretisch weiss was es ist. Das hat keine 30min gedauert, aus Faulheit nicht mal ne richtige IDE dazu aufgemacht mit der "richtigen" KI darunter. Eigentlich braucht man nicht mal mehr ne IDE, nur noch ein prompt. Das blöde daran ist nur ich habe nach 2h schon wieder die Details vergessen, man lernt absolut nix dazu wenn man das Zeug nutzt. Paar Anweisungen raushauen, grob testen, wenns tut was es soll, Tests generieren, bisserl aufräumen und "schön machen", nächster Task, wieder das selbe. So löst man an einem Tag 10x mehr als vorher aber im Kopf hängen bleibt da gar nix.
:
Bearbeitet durch User
Martin S. schrieb:
Und ja, es wird sogar ziemlich ausgiebig gemacht.
Was für IDEs können das? Also:
PC <-USB-> Debugger <-JTAG/SWD-> MCU <-SPI/I²C-> Sensor-IC
Ich nutze gdb scripte, früher mal Insight oder Eclipse. Für interaktives Konfigurieren macht das aber weniger Sinn als ne einfache Shell, resp. ein asynchron laufender Back-Trace-Kanal, der über JTAG Daten transferiert, ohne die CPU anzuhalten.
Hmm, DBC-Files etc., aber Einbindung in eine IDE hab ich da auch noch nicht gesehen. Nur in dedizierte Tools à la CANoe, Code-Generierung darf man trotzdem selber klöppeln. Ein sauberes Format ist DBC nicht gerade, und XML schon gar nicht...
XML ist für uns als validierender Industriestandard sauber genug. Bei JSON et al gilt schnell mal: Garbage in, garbage out. Will man nicht in komplexer Entwicklung.
Martin S. schrieb:
(Stichwort "netpp/devdesc", auch OpenSource). Deckt auch heute noch die meisten Beduerfnisse ab.
Auch ziemlich High-Level, damit kann ich keinen Accelerometer-IC ansteuern.
Der devdesc XML-Dialekt ist wie SVD, kann nur eim bisschen mehr. Mehr als die Low-Level-Registermap und die generierten Header braucht man zur Ansteuerung eines solchen ICs nicht zwingend. Also: Doch, kannst du.
Ich nutze gdb scripte, früher mal Insight oder Eclipse.
Klingt nicht nach einem ausgefeilten Ökosystem.
aktives Konfigurieren macht das aber weniger Sinn als ne einfache Shell, resp. ein asynchron laufender Back-Trace-Kanal, der über JTAG Daten transferiert, ohne die CPU anzuhalten.
GDB kann doch gar nicht auf das Target zugreifen ohne den Prozess anzuhalten. Und wie stellst du sicher dass der Zugriff durch GDB auf z.B. die SPI-Peripherie nicht der Firmware dazwischen funkt, die ebenfalls per SPI zugreifen will?
XML ist für uns als validierender Industriestandard sauber genug.
Ich meinte: DBC ist kein XML.
Also: Doch, kannst du.
Auch ohne Codesys, in meiner Custom Firmware, die nichts von irgendwelchen Feldbusprotollen weiß?
Ich nutze gdb scripte, früher mal Insight oder Eclipse.
Klingt nicht nach einem ausgefeilten Ökosystem.
Begründung? Meine Begründung: Ich brauche keine Wohlfühl-IDE, eher automatisierte Verifikation.
aktives Konfigurieren macht das aber weniger Sinn als ne einfache Shell, resp. ein asynchron laufender Back-Trace-Kanal, der über JTAG Daten transferiert, ohne die CPU anzuhalten.
GDB kann doch gar nicht auf das Target zugreifen ohne den Prozess anzuhalten. Und wie stellst du sicher dass der Zugriff durch GDB auf z.B. die SPI-Peripherie nicht der Firmware dazwischen funkt, die ebenfalls per SPI zugreifen will?
Doch, im asynchronen Betrieb kann er das. Die "monitor"-Kommandos auf dem gdbproxy (der den JTAG ansteuert) machen den Rest. Ansonsten verbindet man sich altmodisch per telnet mit dem Backtrace-Tunnel auf dem proxy. Der synchrone Zugriff geht nur über Scripting, wo du die breakpoints gezielt setzen musst, damit sie nicht den Ablauf stören.
Also: Doch, kannst du.
Auch ohne Codesys, in meiner Custom Firmware, die nichts von irgendwelchen Feldbusprotollen weiß?
Wozu Codesys? Der Workflow ist so:
- Register/Maps/Devices beschreiben
- Register R/W comm layer per Interface-Typ in typischerweise C schreiben
- Register/Bitfelder als abstrakte Eigenschaften exportieren
- "make" baut alles (FW, gdb-scripte, Doku, etc)
- Testen per Python, a la "pump.Bypass.set(True)"
Für alles interaktive nehmen die Kunden LabVIEW oder pvbrowser. Und je nach Belieben lässt man sich die grundsätzliche Fleissarbeit und Coverage von der KI seiner Wahl erledigen. Und ja, es muss klassisch programmiert werden. Mir hilft da eine IDE nicht bei.
Betr. "KI", funktioniert die Validierung per XML-Oekosystem einwandfrei auch mit einem relativ einfachen Sprachmodell. Das wertvollste an der Sache is eigentlich, dass zügig Inkonsistenzen im Datasheet erkannt werden, oder Reverse-Engineering undokumentierter Registerfunktionen damit erschlagen werden kann.
Begründung? Meine Begründung: Ich brauche keine Wohlfühl-IDE, eher automatisierte Verifikation.
Wenn etwas "ziemlich ausgiebig gemacht" wird würde ich denken dass es da mehr gibt als ein paar InHouse GDB-Scripte.
Doch, im asynchronen Betrieb kann er das. Die "monitor"-Kommandos auf dem gdbproxy (der den JTAG ansteuert) machen den Rest.
Mit welchen GDB-Servern funktioniert das? Mit JLinkGDBServer angeblich gar nicht, mit OpenOCD nur eingeschränkt?
Ansonsten verbindet man sich altmodisch per telnet mit dem Backtrace-Tunnel auf dem proxy.
Was ist ein Backtrace-Tunnel, hat das was mit dem "bt" GDB-Kommando zu tun? Mit Proxy ist der GDB-Server gemeint à la JLinkGDBServerCL.exe ? Dessen telnet-Port ist doch nur für Semihosting gemacht? Wie kann ich da dann XML-Registerdefinitionen anwenden?
Wozu Codesys
Wenn man nach "devdesc" sucht, findet man nur Codesys-spezifisches.
Register/Bitfelder als abstrakte Eigenschaften exportieren
Was ist eine abstrakte Eigenschaft? So was wie "abstract val" in Kotlin?
Von wo nach wo exportieren, in was für ein Format?
"pump.Bypass.set(True)"
Was ist das eine Funktion, aus welcher Library?
pvbrowser
Der Versuch herauszufinden was das ist führt auf eine Seite mit defektem (self-signed) TLS-Zertifikat, und der Zurück-Button von Android-Chrome schließt dann sofort den ganzen Tab inkl. meines bis dato geschriebenen Texts. Joah.
Meine Kunden interessieren sich aber zum Glück nicht für die Register des I²C-Accelerometers. Die haben auch noch nie von I²C gehört. Außerhalb des Industrie-Umfelds ist LabVIEW auch ziemlich unbekannt.
Ich versuche mich mal kurz zu halten, damit es nicht zu weit OT geht.
Martin S. schrieb:
Begründung? Meine Begründung: Ich brauche keine Wohlfühl-IDE, eher automatisierte Verifikation.
Wenn etwas "ziemlich ausgiebig gemacht" wird würde ich denken dass es da mehr gibt als ein paar InHouse GDB-Scripte.
Es gibt halt das gdb-Oekosystem, was man auf seinen Target allenfalls mit Hilfsscripten optimieren muss. Da kochen viele ihre eigene Suppe und die Veröffentlichungen dazu sind mager.
Martin S. schrieb:
Doch, im asynchronen Betrieb kann er das. Die "monitor"-Kommandos auf dem gdbproxy (der den JTAG ansteuert) machen den Rest.
Mit welchen GDB-Servern funktioniert das? Mit JLinkGDBServer angeblich gar nicht, mit OpenOCD nur eingeschränkt?
Der Renode-GDB-Server, und der eigene gdbproxy, den ich für Blackfin/RISC-V/ZPU JTAG-Adaptionen einsetze. Sollte eigentlich mit OpenOCD theoretisch auch gehen, aber davon nehme ich lieber Abstand.
Martin S. schrieb:
Ansonsten verbindet man sich altmodisch per telnet mit dem Backtrace-Tunnel auf dem proxy.
Was ist ein Backtrace-Tunnel, hat das was mit dem "bt" GDB-Kommando zu tun? Mit Proxy ist der GDB-Server gemeint à la JLinkGDBServerCL.exe ? Dessen telnet-Port ist doch nur für Semihosting gemacht? Wie kann ich da dann XML-Registerdefinitionen anwenden?
Also: Start/stop/step geht über den klassischen Debug-TAP bei fast jeder CPU, manche haben aber ein FIFO (andersorten heisst es background telemetry channel), über das Daten im laufenden Betrieb per JTAG ausgetauscht werden können. Darüber lassen sich u.a. per telnet oder virtuellem UART beliebige Protokolle tunneln, z.B. modbus RTU oder eben gleich die Property-Abstraktion per netpp. Oder man spricht mit der shell. Mit der synchronen "bt" gdb-Seite hat das nix am Hut.
Martin S. schrieb:
Wozu Codesys
Wenn man nach "devdesc" sucht, findet man nur Codesys-spezifisches.
Suche "netpp devdesc" (again, nicht netapp). Offenbar hat Codesys eine aehnliche Namensgebung.
Martin S. schrieb:
Register/Bitfelder als abstrakte Eigenschaften exportieren
Was ist eine abstrakte Eigenschaft? So was wie "abstract val" in Kotlin?
Register/Bit: Bit 4 an Addresse 0x20 Property-Abstraktion: "Motor.On". Sozusagen die URL zu einem Access-Token.
Von wo nach wo exportieren, in was für ein Format?
Martin S. schrieb:
"pump.Bypass.set(True)"
Was ist das eine Funktion, aus welcher Library?
Das ist Python (Frontend/PC). Das Gerät kennt seine Eigenschaften (die auf Register-Entities mappen). Also wird es nur noch geöffnet, Eigenschaften abgefragt, dann erfolgt Zugriff. Alles weitere kann dir auch die KI erzählen.
Martin S. schrieb:
pvbrowser
Der Versuch herauszufinden was das ist führt auf eine Seite mit defektem (self-signed) TLS-Zertifikat, und der Zurück-Button von Android-Chrome schließt dann sofort den ganzen Tab inkl. meines bis dato geschriebenen Texts. Joah.
github hilft: https://github.com/pvbrowser/pvb
Meine Kunden interessieren sich aber zum Glück nicht für die Register des I²C-Accelerometers. Die haben auch noch nie von I²C gehört.
Genau. Die wollen irgend ein Ding mit Namen sehen, wie eben "Pump4.Motor.On". Oder im Kontrollpanel einen Schalter mit einer ID.
Außerhalb des Industrie-Umfelds ist LabVIEW auch ziemlich unbekannt.
Unbekannt? Wo fast jede Uni schon damit "grafisch programmiert"?
Claude (Copilot vermutlich genauso) findet alle Datasheets vollautomatisch, muss man nichtmal verlinken.
Sowas finde ich problematisch. Sinnvoll ist es alles local zu machen und genau anzugeben mit welchen Datenblaettern gearbeitet wird. Sonst findest du ploetzlich Code in deinem Projekt fuer einen Timer den deine MCU gar nicht hat.
Gestern habe ich meine lokale KI in einer spassigen Minute auf Deutsch mal gefragt ob Perry Rhodan eine Freundin hat. Antwort (etwas gekuerzt) Ja sicher, sie heisst Atlan.
Auf der einen Seite eine erstaunliche Breite von Wissen in 14GB an Daten, dann wieder geradezu unglaubliche Fehler. (hier vermutlich weil die KI nicht den Unterschied zwischen Freundin(deutch) und friend(english) kennt.
Also extrem effektiv wenn man weiss was man macht, aber sobald einer glaubt ahnunglos bleiben zu koennen wird er schneller Schiffbruch erleiden als er kucken kann.
Ich hab auch mal gefragt ob ich mit einem LM741 einen Kopfhoererverstaerker bauen kann. Sie hat mir abgeraten (Bandbreite, Rauschen, Slewrate, alles korrekt) und einen OP1622 empfohlen. Im ebenfalls gelieferten Schaltplan war dann aber alles verkorkst.
Ich finde es auch etwas beaengstigend wenn eine KI C, C++, Python, Fortran, Lisp, Brainfuck, 6502Assembler, HP48 Object-Forth, usw. kann. Eigentlich wuerde es ja reichen die wuerde nur eine Sprache drauf haben, aber die dann perfekt.
Vanye
p.s: Ja wirklich, ich hab brainfuck gestest. Sie konnte mir ein funktionierendes Hello-World programm liefern!
p.s: Ja wirklich, ich hab brainfuck gestest. Sie konnte mir ein funktionierendes Hello-World programm liefern!
Das finde ich nun weder überraschend noch erstaunlich. Denn das konnte google schon vor 10 (oder 20) Jahren.
:
Bearbeitet durch User
Gestern habe ich meine lokale KI in einer spassigen Minute auf Deutsch mal gefragt ob Perry Rhodan eine Freundin hat. Antwort (etwas gekuerzt) Ja sicher, sie heisst Atlan.
Auf der einen Seite eine erstaunliche Breite von Wissen in 14GB an Daten, dann wieder geradezu unglaubliche Fehler. (hier vermutlich weil die KI nicht den Unterschied zwischen Freundin(deutch) und friend(english) kennt.
Das sagt du nun so einfach. Aber vielleicht liest sich Atlan dieses Jahr einfach mal ganz anders. Man steckt nicht drin (außer evtl. Perry)
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.