# Embedded Systems Strategy: RTOS, Hardware Co-Design, and Compliance

**Podcast:** Engineering Kiosk
**Published:** 2026-08-04

## Transcript

Willkommen zu einer neuen Episode vom Engineering Kiosk Podcast.
Heute machen wir einen Ausflug in eine Welt, die für viele von uns irgendwo zwischen Magie, Elektrotechnik und kontrolliertem Wahnsinn liegt.
Zumindest geht es mir so.
Es geht um Real-Time Operating Systems, Embedded Software und die Frage, wie moderne Softwareentwicklung eigentlich aussieht, wenn Speicher knapp ist, Timing alles ist und ein Breakpoint im schlimmsten Fall mehr kaputt macht als hilft.
Zu Gast ist Roland Lezou.
Er entwickelt mit seinem Team Elektrotechnik und Firmware für industrielle Embedded Systems und bringt damit genau die Praxisperspektive mit, die man sich für ein solches Thema wünscht.
Gemeinsam sprechen wir darüber, was Echtzeit eigentlich bedeutet, warum Linux inzwischen auch echtzeitfähig sein kann und wieso ein Fernglas plötzlich ziemlich viel über Softwarearchitektur, Interrupts und harte Deadlines erzählt.
Außerdem schauen wir uns an, wie Embedded Projekte heute wirklich entstehen.
Von PCB-Design über Mikrocontroller, C und Treiber bis hin zum Debugging mit Oszilloskop statt Printline.
Dazu geht es um Testing, Continuous Integration, Update-Fähigkeit, den Cyber Resilience Act und die Frage, warum ein Firmware-Update auf so einem Gerät alles andere als trivial ist.
Wenn du dich also schon mal gefragt hast, ob Embedded Entwicklung einfach Software Engineering in der Steinzeit ist oder vielleicht doch ziemlich modernes Engineering unter härteren Randbedingungen, Dann bist du hier genau richtig.
Wir legen los.
Viel Spaß.
Dieser Podcast läuft unter der Flagge deutschsprachiger Softwareentwicklungspodcast.
In unserer Community kam öfter mal das Thema, könnt ihr auch mal Hardware machen?
Theoretisch könnten wir sagen, geht nicht.
Das Ding hier ist als Softwareengineering-Podcast geflaggt.
Können wir nicht.
Aber wir sind ja agil, flexibel und allem drum und dran.
Deswegen hatten wir vor einiger Zeit eine Podcast-Episode mit André Friesen zum Thema, wie bastelt man eigentlich irgendwie so Home-Automation-Kram mit ESB Home.
wie baut man seine eigene Hardware und wie schwierig ist das eigentlich mit der Software.
Und dann hatten wir die Episode gemacht.
Grandiose Episode, wie man einfach sowas mal nicht baut, beziehungsweise wie man etwas baut, aber mit ganz vielen Failure-Stories.
Und nach der Episode kam der Wolfgang um die Ecke, wenn wir jetzt was zu ESB Home gemacht haben und Hardware, dann können wir das ganze Hardware-Thema doch einfach mal weitermachen.
Wie sieht es denn mal bei dir aus mit Echtzeitbetriebssystemen?
Also Real-Time Operating System, kurz RTOS.
Ich habe in die Schultern gezuckt, ich habe keine Ahnung, erstmal den Begriff RTOS bei Google eingegeben.
Bin dann irgendwie drauf gekommen, okay, das hat irgendwas mit Embedded Systems zu tun oder wird oft in dem Bereich Embedded Systems angewandt.
Und dann habe ich immer gedacht, immer wenn ich von Embedded Systems spreche oder das lese, denke ich an meine Waschmaschine.
Und dann frage ich mich, wie würde ich eigentlich meine Waschmaschine updaten?
Denn als ich die Waschmaschine gekauft habe, ich glaube vor drei Jahren, gab es da einen Zettel bei, diese Waschmaschine nutzt diese Open Source Projekte.
Und da war Curl dabei und so weiter.
Und dann frage ich mich, wie update ich das eigentlich?
Und dann...
kam mir irgendwie so wieder in Erinnerung, Moment mal, diese ganzen Embedded Systems, ist das nicht irgendwie Softwareentwicklung in der Steinzeit?
Ich meine, ich habe da einen Chip, ja.
Gibt es da überhaupt Continuous Integration, Continuous Delivery?
Tesla kam um die Ecke und hat Over-the-Air-Updates revolutioniert.
Keine Ahnung, haben sie wahrscheinlich nicht, haben sie wahrscheinlich einfach nur so verkauft.
Und der Wolfgang ist ja ein smarter Jung, würde man hier im Pott sagen.
Und zwar macht der Wolfgang ja das Engineering Kiosk Meetup Inspo.
Der schafft da sich so sein eigenes Ecosystem und rekrutet eigentlich Speaker für diesen Podcast.
Und da hat er den Roland ausgegraben.
Denn der Roland hat nämlich zum Thema Realtime Operating Systems oder speziell zu einem Realtime Operating System im März 2025 einen Vortrag gehalten.
Da hat der Wolfgang gesagt, komm, den quatsch ich einfach mal an.
Und irgendwie...
hat der Roland sich vertippt und hat aus einem Nein dann ein paar Buchstaben geändert und hat ein Ja gemacht.
Ich bin dabei und jetzt sitzen wir hier.
Hallo Roland.
Hallo Andi, danke für die nette Einführung hier.
Also Moment mal, da muss ich jetzt schon ein bisschen ausgegraben.
Das klingt so, als würden wir alle unter dem Stein wohnen in Innsbruck oder so.
Naja, ihr wohnt an einem Berg.
Ein Berg besteht aus Steinen.
Ich würde sagen, irgendwie ist es nicht weit hergeholt.
Ja, wir sind schon on the top.
Ja, dann beweisen wir dir jetzt das Gegenteil.
Aber Roland, ich habe die Aufgabe, in diesem Podcast immer unsere Gäste vorzustellen.
Und kommen wir zum Thema Innsbruck.
Ihr seid sozusagen Nachbarn.
Also für mich, weil ihr wohnt bei den Innsbruck.
Somit seid ihr Nachbarn, weil Innsbruck ist nicht wirklich groß, meines Erachtens nach.
Weltstadt.
Daran habe ich keine Zweifel.
Aber ich glaube, Singapur ist auch ein Weltstaat und Singapur ist auch super klein.
Also von daher.
Aber wer bist du, Roland?
Du trägst einen Doktortitel.
Also ich bin sozusagen der Dümmste hier im Raum, denn ich habe nur einen Bachelor-Titel.
Ihr beide habt einen Doktor.
Ja, ich habe auf der TU Wien Technische Informatik studiert und mich dort irgendwann so weit hinbegeben, dass ich da zu einem Doktorat gekommen bin.
War ein Interessensdoktorat, weil das Thema mich sehr interessiert hat.
Dann ist es um Compiler gegangen und wie man Software tatsächlich auf Hardware bringt.
Moment, bevor du das erklärst, würde ich jetzt gerne wissen, wie der Andi das erklären würde, weil der Andi hat sich natürlich vorbereitet und ich würde jetzt wissen, was er aus deiner Doktorarbeit rausgelesen hat.
Also, bevor wir an das Thema der Doktorarbeit gehen, die wichtigste Frage.
Roland, wie lange hast du für deinen Doktortitel gebraucht?
Ich glaube, vier Jahre.
Wolfgang, wie fühlt man sich dabei?
Ich glaube, wir sollten über die Doktorarbeit jetzt vom Roland sprechen.
Für alle Neulinge?
Der Wolfgang hat etwas über zehn Jahre für seinen Doktortitel gebraucht.
Nein, nein, genau zehn Jahre.
Von daher, also vier Jahre sportlich, Gratulation nochmal.
Ich weiß, das ist schon ein paar Jährchen her, aber trotzdem, ich denke, es ist eine Wahnsinnsleistung.
Und zwar hast du deine Doktorarbeit über Scalable Translation Validation, Tools, Techniques und Frameworks geschrieben.
So, und ich habe erst mal gedacht, what the heck ist das denn eigentlich?
Niemand hat Zeit, eine Doktorarbeit heutzutage zu lesen.
Also habe ich den Gemini gepackt, habe gefragt, pass mal auf, lies mal mir dieses Dokument und fass mir das mal für Fünfjährige zusammen.
Es war dann nicht eine Erklärung wirklich für Fünfjährige, sondern schon irgendwie in einfachen Worten.
Aber ich fasse es jetzt einfach mal in einfachen Worten zusammen und du sagst, ob ich das jetzt richtig verstanden habe.
Es ging um die Zuverlässigkeit von Compilern.
Denn das Problem ist eigentlich, dass du hast deinen Source-Code und wenn ein Compiler seine Arbeit macht, dann übersetzt er natürlich die Hochsprache in irgendwie Assembly und Bits und Bytes und Pipapo.
Und dabei können natürlich unbemerkt Fehler passieren.
Und durch die Fehler auch das Verhalten des Programms verändert werden.
Und wenn das passiert, waren natürlich alle Sicherheitsprüfungen, die man vorher in der Hochsprache gemacht hat, verifiziert hat, für die Cuts.
Denn wenn der Compiler einfach unbedingt merkt, was verändert, schwierig.
Deswegen kann man sagen, gibt es mehrere Lösungsansätze.
Einer ist zum Beispiel, man versucht den Compiler selbst fehlerfrei zu machen.
Dann hast du gesagt, weißt du was, das mache ich nicht.
Bugs fixen mag ja keiner.
Dann hast du gedacht, wir setzen da einfach nochmal ein Tooling drauf.
Und zwar kümmert sich die Doktorarbeit um eine sogenannte Übersetzungsvalidierung.
Also es wird nicht der Compiler selbst geprüft, sondern das Ergebnis und das machst du mittels mathematischen Beweisen, was du dann später vollautomatisiert ausführen kannst, ob der fertige Maschinencode noch exakt dasselbe Verhalten aufweist wie der ursprüngliche Quellcode in der Hochsprache.
Habe ich das richtig?
Verstanden.
Ich würde sagen, das ist eine sehr genaue und sehr akkurate Übersetzung von den viel, viel Seiten.
Ob du das richtig verstanden hast, wage ich jetzt zu bezweifeln, aber die KI hat es zumindest richtig zusammengefasst.
Das ist korrekt, aber diese KI-Zusammenfassung hat mein Interesse für die Doktorarbeit doch schon geweckt, diese zu lesen.
Ob ich sie dann lesen werde, ist dann jetzt eine zweite Frage.
Vielleicht sollte es doch mal in die akademische Welt noch gehen, Andi, und deinen Master machen.
Also ich lese ja schon immer mal wieder irgendwie Hacker News Artikel, wo man Compiler Bugs irgendwie aus, ich wollte gerade wieder sagen, ausmerzt.
Das haben wir jetzt in der letzten Episode, die über inklusive Sprache ging, gelernt, dass ich das nicht sagen sollte, deswegen entschuldige mich, dass man diese Bugs natürlich behebt und das ist schon sehr interessant.
Aber zurück zu dir Roland, es geht nicht um Compiler Bugs, es geht um deine Arbeit.
Und zwar, was machst du nach deiner Doktorarbeit?
Inzwischen bist du CEO.
aka auf gut Deutsch, Geschäftsführer der SILA Embedded Solutions.
Und jetzt habe ich gelernt, ihr sitzt in St.
Pölten und in Innsbruck.
Das ist einmal im Osten und im Westen, habe ich mir sagen lassen.
Genau, Osten und Westen von Österreich.
In den USA würden wir sagen, wir sind worldwide vertreten.
Wir packen etwas kleinere Brötchen.
Wir sind ein Entwicklungsdienstleister mit 15 Ingenieuren und wir entwickeln für Industrie, Kunden, Elektronik und Softwaregewerke nach entsprechend ihren Vorgaben.
Das ist unser Gewerk.
Das heißt, man kann von uns keine Produkte kaufen, wir haben keine.
Man kauft allerdings oder verwendet unsere Produkte oder sie werden für einen verwendet in verschiedensten Industrien und Anwendungen.
Allgemein ist das spezialisiert auf Embedded Systems.
Das bedeutet, ihr schreibt die Firmware, ihr portiert Betriebssysteme und Treiber.
Genau, viel allerdings auch Elektronik.
Das ist eigentlich ein großer Teil, dass wir auch die Elektronik für den Kunden entwickeln, auf denen dann die Mikroprozessoren laufen, Teile unserer Software laufen.
Wir treiben es meistens bis Integration von einem Echtzeitbetriebssystem oder einem Linux bei größeren Systemen.
Die Applikationsentwicklung findet dann zumeistens beim Kunden selbst statt.
Also das ist dann nicht mehr unser Ding.
Hast du gerade geglaubt, irgendwas ist kaputt?
Ja, siehst du, so geht es mir auch oft.
Und dann brauche ich unbedingt einen Kaffee.
Oder wie der Andi sagen würde, einen Kaffee.
Und für diese Koffeinenergie die ihr uns durch diese Kaffeespenden bereitstellt und die es uns eigentlich erst ermöglichen, diese Episoden zu produzieren, möchten wir uns einmal bedanken.
Und zwar bei den letzten Spendern.
Daniel, Jakob, Peter, Alfred, Florian, Michel, Dimo, David, Lukas, Adrian, Nico, Matthias, Wolfgang, by the way, schöner Name, Elias, Björn, Franco, Dominik, Paul und Fabian.
Und egal, ob ihr uns einen Kaffee sponsert oder vielleicht sogar ein Kaffee-Abo wie der Fabian oder einen ganzen Monatsbedarf an Kaffee wie der David, wir schätzen jeden einzelnen Kaffee und freuen uns wirklich über dieses ganze Koffein-Feedback.
Vielen Dank von Andi und von mir und jetzt geht es auch schon wieder zurück zur Episode.
Jetzt habe ich mich in der Intro nicht dumm gegeben, sondern ich habe einfach die Wahrheit erzählt.
Ich habe einfach bis zur Vorbereitung dieser Episode keine Ahnung gehabt, was Realtime Operating Systems sind.
Die erste Frage ist, warum ist Linux zum Beispiel keins?
Dann haben wir uns in diesem Podcast natürlich schon öfters mit dem Thema auch Zeit beschäftigt.
Also Zeigtsynchronisation und auch irgendwie Streaming und so weiter.
Und ich sag mal, in der ganzen Cloud Software Engineering Welt redet man auch immer, ja, das muss in Realtime passieren.
Wie würdest du Zusammenfassen, was ein Realtime Operating System eigentlich ist, warum Linux keins ist oder vielleicht auch Windows oder vielleicht sind die auch welche.
Das erklärst du mir jetzt gleich.
Und was ist eigentlich Realtime in...
unserem Verständnis?
Also das Erste, was man in unseren ganzen Programmiersprachen tut, ist eigentlich der Begriff der Zeit kommt weg.
Man hat die Schritte, die der Rechner ausführt und über Zeit macht man sich dabei keine Gedanken.
Das dauert halt so lange, wie es geht und desto mehr Geld in meine Hardwaren investiert, desto schneller geht es, was ja auch gut ist.
Allerdings ist das alles, was wir programmieren, von Zeit losgelöst in dem Sinn.
Man hat allerdings, wenn man mit der Echtwelt kommuniziert, halt dann doch zeitzeitliche Constraints, also wenn man an Ampelsteuerung denkt, sollte die grünen Phase 35 Sekunden lang sein und nicht, wenn die CPU da drinnen schneller wird, dann nur mit drei Sekunden grünen Phasen oder so.
Das ist ja nicht der Wünsch.
Das heißt, wenn man mit der Echtwelt interagiert, kommt dieser Zeitbegriff wieder in die Software dazu und man muss sich die zeitlichen Gegebenheiten der Anforderung der Echtwelt anpassen.
Das ist einmal der grobe Begriff Echtzeit.
Hier gibt es dann auch Unterscheidungen zwischen etwas, was Soft-Echtzeit heißt.
Das heißt, man möchte probieren, das möglichst gut zu machen.
Es ist allerdings nicht katastrophal, wenn es schief geht.
Das sind so typische Anwendungen wie Video Streaming.
Wenn dort das Audio Paket zu spät kommt vom Server, dann habe ich einen kurzen Hacker im Audio und danach geht es weiter und man ärgert sich kurz, aber kann sein Fußballspiel weiterschauen.
Nichts Schlimmes passiert.
Und dann gibt es noch harte Echtzeit.
Bei harten Echtzeitanforderungen ist es so, dass wenn man die Zeit, die Deadlines verpasst, ist Mensch und Leben in Gefahr.
Man könnte zum Beispiel an einen Airbag-Controller denken, wenn der ein Signal kriegt zum und er ist gerade dabei, seine Festplätze zu defragmentieren, die er hoffentlich nicht hat und sieben Sekunden später den Airbag zündet, dann ist das ein Problem, weil er dann einfach die Funktion, die er tut, nämlich nicht mehr tut, nämlich die Sicherheit des Fahrgastes zu gewähren.
Also das ist so dieses Echtzeitverhalten prinzipiell.
Und ein Echtzeitbetriebssystem ist jetzt ein Software-Framework, das einem halt hilft und unterstützt, auch vom gegebenen Mikrocontroller oder Prozessor.
Software zu schreiben, die echtzeitfähig ist im Sinne von dieser Soft- und gegebenenfalls auch harten Echtzeitanforderungen, die man da hat.
Linux ist tatsächlich ein Echtzeitbildungssystem.
Da hat Herr Gleixner jahrelang den Real-Time-Linux-Patch gepflegt, der es letztes Jahr geschafft hat, in Mainline integriert zu werden.
Das heißt, Linux hat eine sehr fundierte und gut getestete Echtzeitfähigkeit.
Was man da tut, das ist ein anderes Optimierungsziel wie jetzt ein generisches Desktop- oder Serverbetriebssystem.
Bei Desktop- und Serverbetriebssystemen optimiert man primär auf Durchsatz.
Man möchte möglichst viel Rechenleistung aus der CPU rausholen.
Man optimiert vielleicht noch auf Latenz.
Ich möchte schnell auf Anfrage reagieren können.
Und bei einem Echtzeitbetriebssystem optimiert man aber darauf, dass man in einer endlichen und messbaren endlichen und bekannten Zeit auf etwas reagieren kann.
Das heißt dort.
Da muss man möglichst schnell, wenn ein Interrupt auftritt, auf diesen Interrupt reagieren oder zumindest in einer gewissen abgeschränkten Zeit.
Aber habe ich das jetzt beim klassischen Betriebssystem, reagiere ich ja auch möglichst schnell, oder?
Ich will ja nicht langsam reagieren jetzt auf irgendeinen Interrupt.
Genau.
Ist es dann einfach optimierter noch oder gibt es dann auch irgendwelche, weil du jetzt gesagt hast, in einer definierten Zeit?
Also passiert dann auch was anderes bei so einer Reaktion auf einen Interrupt?
Genau, bei so einem Echtseuerbetriebssystem passiert das, wenn ein Interrupt sehr hoher Priorität kommt, auf den ich schnell reagieren muss, wird alles andere, kann dann eingehalten werden und wird geparkt.
Jetzt hat das Serverbetriebssystem, das gerade eine Festplattentransaktion in Flight hat, wird die auf jeden Fall fertig machen und vielleicht noch die nächsten zwei Sektoren, weil das gut ist für die Bandbreite und dann auf den Interrupt reagieren, weil...
da diese harte Echtzeitanforderung nicht da ist.
Und ein hartes Echtzeitbetriebssystem parkt dann sofort, was es gerade tut und macht jetzt diesen Hochprioninterrupt.
Das ist ein bisschen anderes Optimierungsziel und die Software oder die Komponenten vom Betriebssystem müssen also alle unterbrechbar sein zu jedem Zeitpunkt.
Okay, das bedeutet, so ein Interrupt ist nicht so ein klassischer Interrupt, wie wir ihn aus der Softwareentwicklung kennen, sondern so ein Interrupt hat Metadaten, wie zum Beispiel eine Priorität oder ähnliches, damit das Betriebssystem, ich sage mal, eine ordered queue, irgendwie abarbeiten kann.
Genau, und ziemlich so ist dann auch die Implementierung.
Es ist ein Ordered-Queue und die Priorität ist so das wichtigste Element, also Prioritäten.
Das ist etwas, was man im Systemdesign schon festlegt, welche Prioritäten die verschiedenen Interrupts auf so einem System haben werden.
Jetzt hast du von diesem Realtime-Patch in Linux gesprochen, dass der gemerged wurde.
Ich kann mich auch noch daran erinnern, dass da ziemlich viel News in der Industrie waren.
Aber wenn ich dir jetzt so zuhöre, dann sind die Verhaltensweisen von einem Realtime Operating System und einem, kann man sagen, nicht Realtime Operating System, das ist das Gegenteil, ja schon grundsätzlich anders.
Und wenn ich mir heutzutage, weiß ich nicht, so ein Debian, Ubuntu oder ein Arc Linux oder irgendwas installiere, dann kann ich mich nicht daran erinnern, dass ich das Verhalten aktiv wähle.
Also inwieweit sind denn diese zwei Modelle, nenne ich es mal, kompatibel miteinander oder haben explizite Konflikte.
Also für mich ist schon wichtig, dass wenn irgendwas auf die Festplatte geschrieben wird, dass das zu Ende gemacht wird, bevor dann irgendwas anderes gemacht wird, weil für mich jetzt in meinem Fall, weiß ich nicht, Datensicherheit oder ähnliches wichtiger ist als, ich weiß jetzt nicht, was der Interrupt jetzt gerade macht, aber.
Also auf deinem Linux Desktop-System ist das verheiratet, ja, das funktioniert gleichzeitig miteinander.
Es sind jetzt die meisten Tasks, die du ausführst, die nicht echtzeitkritisch, aber Audio zum Beispiel.
läuft jetzt in der Echtzeit Prioritätsdomäne, zumindest einige Audio-Mixe unter Linux.
Das ist eben, dass man diese Hacker verhindern kann.
Hier ist allerdings mehr Soft in der Echtzeit.
Also wenn es jetzt mal passiert und da Audio aussetzt, ist es ja nicht tragisch.
Aber das ist miteinander verheiratbar und läuft auch nebenher.
Aber ist jetzt der Unterschied zwischen...
Soft- und Hard-Limit oder wie du es genannt hast, oder Deadlines, ist es nur auf der Metaebene, dass ich jetzt entscheide, okay, es ist kritisch, ihr habt da jetzt ein hartes Limit, weil eben...
die Ampelsteuerung dranhängt oder keine Ahnung, irgendeine Steuerung, wo sonst was kaputt ginge in meinem Prozess mit meiner Maschine?
Oder ist das wirklich auf Software-Ebene dann auch irgendwie anders implementiert?
Es ist dann auf Software-Ebene anders implementiert, weil beim Soft-Echtware-Sitesystem reicht es, dass ein von 10.000 Interrupts innerhalb von einer gewissen Zeit passieren und sonst gibt es einen kleinen Hacker.
Das heißt, ich muss dort nicht jeden Corner-Case vom...
Echtzeitbetriebssystem oder von dem Software-Framework darauf anpassen, dass er sofort unterbrechbar ist.
Hingegen bei einem harten Echtzeitbetriebssystem wie die Airbag-Steuerung ist es auch nicht gut, wenn ein von 10.000 Mal der Airbag nicht auslöst.
Da darf kein anderes Software-Stück laufen, es darf nie die CPU blockiert sein.
Das heißt, dort muss dieser Hochpriorien-Interrupt immer zeitgerecht abgearbeitet.
Und dafür muss das gesamte Restsystem entsprechend mit Garantien so sein, dass diese Unterbrechung innerhalb von einer gewissen Zeit stattfinden kann.
Wie sieht es denn grundsätzlich mit Startzeiten aus?
Weil ich mache ja zum Beispiel in einem anderen Projekt eine Steuerung von einem Schalter und dieser Schalter, wenn man den resetten will, muss man den fünfmal hintereinander schnell vom Strom nehmen.
Und ich denke mir immer, wie lange muss ich dazwischen vom Stromnehmen warten?
damit er überhaupt realisiert, dass er gerade fünfmal hintereinander irgendwie vom Strom genommen worden ist.
Und das scheint irgendwie da in Millisekunden zu funktionieren.
Oder was ja jetzt mit der normalen Bootzeit von irgendeinem Linux ganz weit weg wäre.
Das ist natürlich unvergleichlich.
Unsere Embedded-Systeme booten tatsächlich sehr stark.
Also es kommt jetzt ein bisschen darauf an, was man hat, aber Millisekunden.
ist die Größenordnung, indem man die Bootzeit schon berechnen kann.
Man hat dann oft in der Software-Stack-Komplexes noch eine gewisse Initialisierung.
Warum ist das so viel schneller wie jetzt der Linux?
Das Boot ist, der Linux hat einmal die Firmware auf x86, die die ganze Peripherie enumeriert und dann entweder UEFI oder wie auch immer Dinge noch tut, die man gar nicht kontrollieren kann als Entwickler.
Und dann ist auch diese Reinitialisierung, die der Linux-Kernel vornimmt von der ganzen Peripherie, das ist alles sehr zeitintensiv.
Auf Embedded hat man einfachere Peripherie meistens, die schneller bereitsteht.
Weniger Quarze, die einschwingen müssen.
Weniger Verzögerungen, die man schon in der Hardware beim Power-Up hat.
Und es gibt Plattformen, die innerhalb von Mikrosekunden die ersten Instruktionen aus dem Flash-Ins ausführen.
Also da ist die Start-up-Zeit wirklich in Mikrosekunden.
Da legt man den Dakt an, wartet fünf bis zehn Dakt-Zyklen.
Danach ist es soweit stabil.
dann führt er schon die ersten Instruktionen aus.
Also da bootet man dann instantan, würde ich fast sagen.
Hast du gerade DAK oder TAKT-Zyklen genannt?
TAKT-Zyklen.
Achso, ich habe mich gerade gefragt, was ist eine Endenzykle?
Andi, das ist dieses tirolerische D und T.
Wir haben ja auch ein hartes D und ein weiches D.
Diese Begriffe kennst du ja gar nicht.
Bei uns muss man das dazu sagen, weil bei uns klingt alles gleich.
Aber entschuldige jetzt meine dumme Frage, aber ich bin ein großer Fan von Es gibt keine dummen Fragen.
Hab seit Jahr und Tag hier so ein, zwei Arduino-Bustle-Kits, mit denen ich mal was machen möchte, Hardware.
Also ich bin ein kompletter Hardware-Nube.
Ich hab das mal damals in der Ausbildung gemacht.
Wenn du jetzt von Plattformen sprichst, die nach etlichen Taktzyklen schon ready sind, irgendwas auszuführen, sprechen wir da von der Software oder von der Hardware?
Von der Hardware.
Also das ist, wenn man so ein Embedded-System oder so ein Mikroprozessor startet, dann gibt es eine gewisse Reihenfolge von Signalen, die high, low.
Low-High werden müssen, man muss einen Dakt anlegen, der muss dann ein bisschen stabil bleiben.
Die Spannungsversorgung muss dann eine gewisse Zeit lang stabil sein.
Und wenn das alles gegeben ist, dann beginnt die CPU mit der Ausführung der ersten Instruktionen.
Von welchen Art Chips reden wir da?
Wir reden da jetzt nicht von einem ESP.
ESP ist schon eine komplexere Plattform, geht schon auch in die Richtung allerdings.
Ich rede jetzt vor allem von Cortex-M, also ARM-Cores, verschiedener Hersteller.
Oder AVR hat auch ein paar sehr kleine 8-Bit-Mitglieds.
Mikrocontroller, die jetzt in der Hinsicht besonders schnell sind, weil sie besonders einfach sind vom Aufbau.
Aber wenn wir da jetzt von einer Millisekunde oder so sprechen, da läuft dann wirklich schon die Firmware-Software, die du gecodet hast?
Genau, die erste Instruktion läuft da innerhalb von wenigen Millisekunden los.
Tja, was kann man sich vorstellen als Startzeit?
Ich habe zum Beispiel ein Gerät mitentwickelt, das ist ein Fernrohr und da ist eine optische Stabilisierung drinnen, weil wenn man mit seiner Hand so ein Fernglas hält, wackelt der Mensch.
Der hat so eine gewisse Frequenz, wo die Muskeln wackeln.
Und dieses Wackeln führt zu einer gewissen optischen Unschärfe.
Und darum kann eine normale Vergrößerung mehr wie 20-fach mit einem handgehaltenen Gerät nicht erreicht werden.
Und wenn man darüber hinaus möchte, braucht man Stativ.
Das heißt, man stellt es am Boden.
Dann ist das Wackeln aus der Hand des Menschen geringer.
Und damit kann man auch in weiterer Entfernung optisch gut sehen.
Eine andere Möglichkeit ist aber, dass man dieses Wackeln mit...
Mit IMU-Sensoren misst.
Das heißt, man misst, wie der Mensch wackelt.
Mit was für Sensoren?
Also es ist eine Immersion-Bashament-Unit.
Das ist sensorisch, die Beschleunigung in den drei Raumrichtungen misst.
Ist das das Klassische, was in meinem Handy auch verbaut ist?
Ja, das ist auch in meinem Handy verbaut.
Dieser Gyroskop.
Mit dieser IMU misst man das Wackeln des Menschen raus und steuert dann eine Linse mit vier Motoren an und die wackelt man links, rechts und so weiter.
um somit das Wackeln der Hand auszugleichen.
Damit kann man jetzt optische Auflösung von Faktor 40 und mehr auch jetzt im Handbetrieb ermöglichen.
Und das ist wirklich spannend.
Also ich habe da durch den Prototypen durchgeschaut und bin dann im Tal unten in meinem Büro gesessen und habe vom Berg hinauf geschaut und habe gesehen, da ist ein Gipfelkreuz, ich sehe es.
Und wir haben dann auch so einen Anschaltknopf gehabt, haben über den gedrückt und dann ist diese Bildstabilisierung angangen und man merkt das gerade, da war auf einmal...
erwischt man sich dabei, wie man jetzt nicht probiert, das Gipfelkreuz an sich zu sehen, sondern wo man probiert zu lesen, was da auf der Inschrift jetzt draufsteht.
Also das ist wirklich stabilisiert gewaltig.
Das ist wirklich ein Riesensprung.
Auf jeden Fall, diese Mechanik ist sehr, sehr fein, weil diese Linse im Mikrometer-Bereich muss die nachjustiert werden.
Das ist jetzt nicht etwas Großes.
Das ist eine sehr feine Mechanik, die natürlich auch sehr anfällig ist für Schlag oder Stoß, würde dort Schaden nehmen.
Und darum gibt es da auch eine Parkposition.
Und eine der Anforderungen zum Beispiel an dieses Produkt war, wenn dieses Gerät jetzt am Tisch liegt und es ist an, das heißt die Linse ist nicht in Parkposition und die Stabilisierung ist an und es fallt hinunter, dann muss die IMU diesen Fall erkennen und die löst dann einen Interrupt heraus.
Also auf diesen IMUs kann man so Muster erkennen, hinterlegen, die sehr automatisch autonom erkennen.
Da ist zum Beispiel Fallerkennung dabei.
Dann muss es während dem Fall diese Linse in die Parkposition.
bringen in der Parkposition, wenn dann Klammern um diese Linse festgefahren, dass sie bei Fall geschützt ist.
Und das muss es schaffen von der Tischplatte hinunter.
Also es ist so die Geschwindigkeit, über die wir da reden.
Und das kannst du aber auch aus dem Deep Sleep.
Das heißt, auch wenn der Mikroprozessor schlaft und die EMU diesen Interrupt generiert, wacht die CPU schnell genug auf und führt diese Sequenz und Instruktionen aus, die da zu dieser sicheren Position führen, dass es keinen Schaden nimmt, wenn es dann am Boden aufknallt.
Dove Frage, wenn ich was vom Tisch schmeiße.
Wie viel Zeit haben wir da in der Regel?
Klar, kommt auf das Gewicht an und pipapo.
Also ich will jetzt keine hochwissenschaftliche Rechnung, sondern ich habe jetzt ein Handy oder dein Zoom-Gerät.
Fernglas heißt das auf Deutsch, dein Zoom-Gerät.
Fernglas, ja.
Also weiß ich nicht.
Ein klassisches Fernglas hat bei mir jetzt noch keine Technik, aber ich bin auch nicht im Fernglas-Business.
So 250 bis 500 Millisekunden.
Eine Zeit lang braucht der beste Fall erkannt wird.
Dann wird dieser Interrupt ausgelöst.
dann muss diese ganze Sequenz, oder muss auch die Mechanik sich schon bewegt haben.
Dann müssen Motoren bewegt werden, die Linse ist jetzt nicht schwer, das heißt, die Trägheit ist nicht sehr hoch, aber doch muss sie dann bewegt werden.
Ich bin mal hingefallen und hatte meine Apple Watch dabei.
Die hat dann auch gesagt, hey, du bist gerade hingefallen, soll ich einen Notruf rufen?
Das müsste doch eigentlich genau dieselbe Funktion sein, oder?
Genau, ist genau diese Funktion, ja.
Oder ich habe auch mal irgendwo gesehen, da gibt es so...
So Helme für Fahrradfahrer und wenn die fallen, dann löst er irgendwie so ein Kopfkissen aus, was dann irgendwie den Kopf schützt.
Das ist ja auch dann...
Genau, das ist diese gleiche Anwendung, weil diese EMUs eben diese Fallerkennung als sozusagen Offload-Produkt drinnen haben.
Das heißt, wenn man so eine EMU hat, hat die meistens genug Logik, um Stürze zu erkennen.
Und dieses Wackeln, was du ausgleichst...
In was für einer Zeitspanne passiert sowas, also damit das sinnvoll funktioniert?
Die Frequenz vom menschlichen Wackeln, wenn ich mich recht entsinne, ist sowas bei einem Herz.
Also ungefähr das ist die Frequenz, mit der Mensch wackelt.
Ein Herz heißt einmal pro Sekunde oder ist das mehr?
Einmal pro Sekunde.
Okay, das heißt aber ich habe dann...
1000 Millisekunden Zeit, um irgendwas zu machen.
Genau, das ist eigentlich sehr einfach für regelungstechnische Anwände.
Also alles, was ein Mensch tut, ist eigentlich sehr langsam.
Das sind biochemische Prozesse, das ist jetzt...
Aber ich meine, 1000 Millisekunden, für 1000 Millisekunden, ich meine, das ist eine Sekunde, dafür brauche ich ja jetzt kein Realtime Operating System.
Das sind ja Welten.
Das ist die Frequenz des Wackelns, was man allerdings schon tut.
Man muss das ja messen.
Das heißt, man misst es dann mit einem Oversampling, man misst dann...
Alle Millisekunden, zum Beispiel die im Uhrhaus, um diese Schwingung, die man jetzt da macht, das Wackeln aufzulöst.
Das muss man ja fein auflösen.
Also der Mensch ändert quasi einmal pro Sekunde irgendwas, aber bewegt sich ständig natürlich.
Aber es ist so, die Grundfrequenz ist so im Herzbereich.
Wie testet man sowas?
Also ich erkläre dir jetzt mal, wie ich mir das bildlich gerade vorstelle.
Du sitzt an deinem Schreibtisch.
Du hast da deinen Chip.
Da hast du ein paar Kabel dran, die vielleicht an ein Oszilloskop gehen.
Oder vielleicht sogar an deinen Computer in irgendeiner Art und Weise.
Irgendwas übersetzt das halt, damit du halt Software drauflöschen kannst.
Diese Kabel sind hoffentlich anderthalb Meter lang oder ähnliches.
Und dann schreibst du die Software für diese Chips und dass du halt packst die Schwellenwerte da rein, ab wann du denkst, ist es ein Sturz oder nicht.
Also ich gehe stark davon aus, dass man da irgendwelche Werte sagen kann, wenn du sagst gerade 250 Millisekunden bis 500 Millisekunden, je nach Höhe des Tisches wahrscheinlich.
Und dann...
Spielst du die dumme Katze und bewegst das Ding halt zum Tischrand, lässt das fallen und guckst, ob du einen, weiß ich nicht, FMT-Printline auf dem Screen siehst und der richtig gefallen ist und dein Interrupt getriggert wurde oder völlig doof.
Wie debuggt man das?
Wie testet man das?
Und wie viele Sensoren machst du während des Testens kaputt?
Ja, also die Sensorik haltet das schon aus.
Die Optik, wie kaputt machen wir, testet es natürlich erst dann nicht gleich mit der Optik.
Aber ja, das ist natürlich Teil von diesem Entwicklungsprozess.
Wie testet man das?
Das ist eine sehr berechtigte Frage.
In dem Fall testet man es mit Geräten, wo es egal ist.
Die sind wirklich mit der teuren Optik gebaut, sondern sind Geräte, die man runterfallen lassen.
Und letztlich schaut man, also die Software modifiziert man halt so, dass sie danach nicht wieder auftut, diese Fangvorrichtung, sondern in der verharrt.
Man schmeißt sie runter und misst mit, trackt mit.
Sobald ich den Interrupter halten habe, der Sturz ist erkannt.
Schau ich mir an, wie lange braucht es, bis es in dieser Phase ist, dass es das festgehalten hat.
Und danach machen wir Postmortem-Analyse, ob es schnell genug war.
Wenn du sagst, du trackst das mit, du speicherst das mit, werden dann Daten auf dem Device selbst gespeichert oder hast du während des Fallens eine Kabelverbindung zu deinem Computer?
Also hast du da irgendeine Art von...
persistentem RAM oder ähnliches, wo die Daten dann hingeschrieben werden, dann wurde das ausgelöst pipapo und liest dann später die Debugging-Informationen aus oder hast du konstant irgendeine Connection zu irgendeinem Screen, einem Device, wo du die ganze Sache sofort auslesen kannst?
Ja, das ist eher eine gute Frage oder gute Frage in dem Sinn, weil das etwas ist, was im BediGon schwer ist, weil die Speicherbandbreiten meistens sehr...
gering sind.
Das heißt, wenn es jetzt nicht im RAM Platz hat, hat man eigentlich kaum einen Speicher, der schnell genug ist, um Echtzeitdaten mitzutracken.
Dann hat man eigentlich nur die Möglichkeit, über spezialisierte Debug-Schnittstellen diese Information schnell nach außen zu bringen.
Und dann muss man kabelgebunden arbeiten.
Beides sind natürlich Ansätze.
In dem Fall hat es im RAM Platz gehabt und dann macht man das, weil es einfacher ist und schließt dann auch den Debugger an und liest es dann aus.
Aber sonst muss man das kabelgebunden machen und diese Tracing-Daten schnell genug mitschreiben.
Von welchen Rechenleistungen sprechen wir denn bei diesen Chips?
Damals wurde ja gesagt, keiner braucht mehr als 4 Kilowatt RAM, um zum Mond zu fliegen und so weiter und so fort.
Ich meine, wir wissen alle...
Wenn wir heute in Google Chrome starten, sind wir weit von entfernt.
Ja, wovon reden wir?
Wie viel RAM hat die CPU überhaupt?
Rechnen wir da was in Megahertz oder rechnen wir drunter?
Megahertz haben wir schon doch.
Also langsame Systeme sind zweistellige Megahertz und der schnellere sind schon 300, 600 Megahertz.
Das ist jetzt alles nicht untypisch.
Es gibt auch Gigahertz, da sind wir dann schon in hohen Leistungsklassen.
Vom internen Speicher reden wir jetzt über schreckend kleine.
Also wenn man da ein bis zwei Megabyte hat, das hat wahrscheinlich ein Riesensystem.
Da gibt es auch Systeme mit 256 Kilobyte Flash.
Da musst du nicht ganz in die Fernweh hineinpassen.
Und RAM reden wir in ähnliche Größenordnung.
Also 256 Kilobyte ist so 512 Kilobyte, das sind so RAM-Größen.
Aber da reden wir jetzt von Setup für das Fernglas zum Beispiel.
Also wenn ich jetzt ein ESB irgendwie sowas habe, dann...
Das ist meistens schon wesentlich größer, oder?
Also der ESP32 ist auch nicht sehr viel größer.
Er ist schon einer der größeren Mikro-Controller.
Der hat halt vielleicht sowas wie 2 MB RAM oder 4 MB Flash.
Das ist aber dann schon sehr üppig hier.
Da gibt es sicher auch kleinere Varianten, weil man nicht immer so viel Speicher und RAM braucht.
Aber man sieht da jetzt schon, dass das wirklich eine andere Welt ist.
Also sogar bei den Sachen bewegen wir uns.
Doch im unteren Segment, obwohl man ja so sagt, eigentlich Kortex und Arm und die Dinger sind ja, was so im Handy verbaut ist, sind ja super stark mittlerweile.
Aber wenn man dann in einem Fanglas unterwegs ist, scheinbar doch noch eine andere Welt.
Und da kommt ja auch dieses ganze Klischee her, was der Andi jetzt in der Intro auch erwähnt hat.
dass das von außen für uns Softwareentwickler und für uns Cloud-Leute, du bist ja bekanntlicherweise, oder für mich bekanntlicherweise, kein großer Cloud-Fan.
Du erklärst mir immer alles, was ich baue mit meinen Schaltern.
Das ist Cloud, würdest du nie verwenden.
Ich sage ja oft, als deutschsprachiger Mensch hat man ja einen großen Vorteil, oder?
I cloud your data.
Also man weiß ja, was da passiert.
Das ist leider der beste Spruch, den ich seit langem gehört habe.
I cloud your data.
Wo hast du den denn her?
Wahnsinn.
Okay, also andere Welt.
Und für mich ist das aus Außenstehender immer so super schwierig.
Hardware irgendwie, alles ist super langsam.
Ich kann nichts testen, haben wir jetzt schon gehört.
Es ist natürlich auch nicht leicht, irgendwie sowas mit einer Linse zu testen.
Aber auch ganz klassische Software ist schon irgendwie schwierig zum Testen und alles ist so unhandlich, würde ich mal sagen.
Kannst du uns mal aufklären, wie denn das jetzt aktuell eigentlich so aussieht?
Wie entwickelt man denn heutzutage so ein Hardware-Projekt?
Wo fängt das an?
was für Elemente sind da überhaupt dabei, damit man mal so versteht, wie so ein Prozess aussieht und dann kann man ja später auch noch in die Teile mit reintauchen, wie es dann konkret ausschaut.
Testing haben wir jetzt schon ein bisschen angesprochen, aber wo fängt denn so ein Projekt an?
Mit was fängt man an und wo hört man auf für mich als Cloud-Mensch?
Wenn ich eine Idee habe, schreibe das in eine LLM heute rein, 10 Minuten später, wenn ich teste und dann brauche ich vielleicht nur 15 Minuten, bis es online ist.
Aber dann steht die ganze Sache.
Wie schaut das im Vergleich zu einem Hardware-Projekt aus?
Hardware-Limitationen verstehen Kunden, die akzeptieren sie.
Software-Limitationen sind viel weniger verständlich intuitiv, glaube ich, für Leute, die jetzt da nicht vom Fach sind.
Aber wenn man sagt, die CPU ist nicht schneller, weil wir haben halt die Langsumme gewählt, dann, aha, okay, ist nicht schneller.
Das kann man verstehen.
Hingegen, der Algorithmus ist nicht schneller.
Ja, da musst du halt ein bisschen drüber nachdenken.
Da geht schon was, oder?
Ein bisschen optimieren und so.
Also da ist viel weniger, wie soll ich sagen, entgegenkommen, des Kunden zu erwarten.
bei Software-Limitationen.
Harte-Limitationen versteht er.
Wie entscheidet man da, was in Software kommt und was in Hardware kommt?
Oder ist die Hardware eigentlich nur die Steuerung und der Rest ist immer alles Software?
In den meisten Fällen machen wir Mikrocontroller-Projekt.
Das heißt, wir machen dann Firmware und lösen die Business-Probleme in Software.
Das funktioniert fast immer gut, außer es ist eben sehr zeitkritisch.
Dann braucht man oft ein FPGA oder ähnliches, wo man jetzt die Echtzeitanforderungen dann auslagert.
Also wenn wir sehen, es ist sehr, knackig von den zeitlichen Anforderungen, dann wird meistens ein FPGA noch dazu verwendet, den wir dann über einen Mikrocontroller ansteuern und dann die Logik totmachen.
Und wie schaut dann so ein Mikrocontroller-Setup aus?
Kann ich mir das vorstellen wie ein Raspberry Pi, mehr oder weniger, nur dass ihr das halt customizt?
Nein, also wir kaufen schon die Chips vom Band, da gehen dann über Stück Automaten drauf.
Wir machen das ganze PCB, designen wir.
Also die PCB ist die Platine, die grüne Platine für mich als Laie.
Genau, die grüne Beline, das grüne Zeug, wo das Ganze draufgeklebt wird.
Also das machen wir meistens.
Das hat sehr viele mechanische Anforderungen, weil ich möchte diese Produkte immer irgendwo hinein verbauen.
Da ist aber ein mechanischer Teil.
Bei hoher Leistung der Komponenten gibt es so eine Kühlungskomponente.
Das heißt, da muss man auch mit der Mechanik mitdesignen, wie kühlt man das, wo ist da Metall, das ist dann in einem Gehäusekühlruppe ableitet, diese Wärme.
Dann hat der Kunde immer Spannungsversorgungen.
Da gibt es jetzt verschiedene Welten.
Da gibt es 24 Volt Gleichstromwelten.
Da gibt es 32 Volt Wechselstrom.
Da gibt es dann auch für feinere Elektronik 3,3 oder USB versorgt 5 Volt.
Also das sind dann verschiedene Versorgungskonzepte.
Oder man möchte eine Batterie, ein Solarpanel.
Dann hat man wirklich ganz andere Entspannungen.
Also das gilt es dann immer zu berücksichtigen.
Und da gibt es erstaunlich viele Varianten an Anforderungen, die da zusammenkommen.
warum sich halt dann ein Custom-Design des PCB rendiert für den Kunden.
Aber was dann am Ende rauskommt, ist so etwas, wie man einen klassischen Computer aufbauen würde.
Also man hat den Mikrocontroller, man hat dann irgendwo RAM außen drauf.
Eigentlich nicht.
Also man schaut, dass man das nicht tut.
Kein RAM, kein Flash.
Man schaut, dass man mit dem System und dem Chip auskommt, mit diesen 1-Megabyte, 2-Megabyte Größenordnungen von Flash.
Okay, das ist dann am Chip schon drauf und dann habe ich meine normalen Schnittstellen.
Urart Schnittstellen wie bei so einem Raspberry und da baue ich dann Sachen dran.
Genau.
Ich möchte mal ganz kurz zu der PCB-Erstellung zurückkommen.
Ich habe damals auch Platinen geätzt und designt und allem drum und dran.
Und wenn ich das jetzt alles immer richtig verstanden habe, dann geht es da ja immer um sehr hohe Stückzahlen, damit das überhaupt rentabel ist.
Das ist aber bei euch völlig anders.
Das bedeutet, da ihr ja Custom-Entwicklungen macht, ätzt ihr auch mit hoher Wahrscheinlichkeit eine unglaublich geringe Stückzahl an Platinen, weil Vielleicht nicht jeder Kunde den Chip oder das, was ihr da habt, 35.000 Mal braucht.
Oder vielleicht doch jetzt mit dem Fernglas, vielleicht doch, wenn es dann später ein Produkt wird, was dann an, weiß ich nicht, an wen verkauft man denn Ferngläser?
An Jäger, Wanderer oder ähnliches?
Vögelbeobachter.
Birdwatcher.
Großes Business.
Okay, ich weiß jetzt nicht, wie viele Birdwatcher es weltweit gibt.
Sehr viele.
Ich bin nicht in dem Birdwatching-Business.
Aber das bedeutet ...
Habt ihr eigentlich für jede Auftragsarbeit ebenfalls die Massenfertigung als Anforderung, wie jetzt in dem Birch-Watching-Business, oder habt ihr auch, hey, ich habe eine Produktionsstraße und da ist mir irgendwie, und die ist von 1970, da ist mir der Controller-Hops gegangen, könnt ihr mal was Neues da bauen und dann macht ihr davon nur drei Platinen oder sowas?
Tatsächlich, diese Anfrage, die du gerade skizziert hast, haben wir gerade neulich gehabt und da haben wir dann drei Platinen gemacht.
Das war völlig random.
Aber es ist tatsächlich etwas, wo es sich rendiert, auch für Custom-Design Geld in die Hand zu nehmen, auch wenn es nur drei Stück ist, weil es eine Produktionsstraße in Summe sehr viel teurer ist, wie diese Elektronik-Komponenten dort.
Dafür hast du da keine Platzprobleme, oder?
Bei so einer Produktionsstraße ist es wahrscheinlich egal, ob das sogar eine Quadratmeter-Platine wäre.
Das stimmt, das wäre dann total egal.
Hier kann man dann mit Menschen, wie soll ich denn sagen, menschenwürdigen Größen oder Bauteile erweiten, also wo man die Widerstände noch sehen kann und so extrem große Dinge und vielleicht sogar selbst löten.
Und sonst ist Massenfertigung, also man braucht bei Gott nicht jetzt die Millionenstücke im Jahr, dass sich das rendiert, sondern das kann sich schon rendieren ab 50 Stück im Jahr.
Sind Customs, Design können schon wirtschaftlich tragfähig sein.
Das kommt jetzt natürlich ein bisschen auf den...
Markt drauf an, also Computer, Maus, nein, braucht man nicht für 50 Stück im Jahr arbeiten, aber für Messgeräte zum Beispiel, da ist auch die Marge entsprechend dann natürlich pro Gerät groß, weil die Entwicklungskosten ja abgetragen werden müssen.
Aber auch da rendieren sich aus vielen Gründen PCBs und da gibt es dann oft 50 Stück im Jahr eine Abnahmemenge von Custom Designs.
Also das ist ganz üblich.
Mit 500 Stück im Jahr ist man eigentlich schon gut dabei.
Für Industrialisierung, also da rentiert sich das schon sehr schnell aufgrund der reduzierten Ausfallwahrscheinlichkeiten, die ein PCB im Vergleich zu einer aus Komponenten zusammengesteckten Lösung hat.
Lustigerweise, das, was mir am meisten ausfällt in der Elektronik, sind die Stecker.
Also das ist so mit einer Größenordnung, ist das die Aufsichtsursache Nummer eins.
Das heißt, beim PCB hat man den Vorteil.
dass man die Steckverbindungen minimiert hat, weil man die Sachen ja auflötet und damit die Produktlanglebigkeit gegeben ist, was dann natürlich Wartung und Reparaturkosten reduziert im Produkt-Lifecycle.
Aber du meinst jetzt mit Stecker, dass sie über die Zeit kaputt gehen oder schon bei der Lieferung?
Nein, über die Zeit.
Stecker gehen kaputt.
Das ist, was Stecker tun.
Was ist, wenn du sagst, ein Ausfall bei einem Stecker?
Also einen Stecker steckt man oder er steckt nicht.
Also das ist ein Ausfall bei einem Stecker.
Hast du noch nie Wackeler gehabt, Andi?
Heißt das bei euch überhaupt Wackeler?
Wackelkontakt.
Ich meine jetzt nicht die Band, hier mit Ich bin eine alte Lampe aus den 70ern oder wie der Song da heißt, sondern okay, also wir reden über Wackelkontakt.
Wir reden verschieden, also nicht nur Wackelkontakte.
Stecker müssen einmal eine hohe Federkraft haben, dass der Kontakt sauber stattfindet.
Also Steckkontakt ist immer elektronisch gesprochen ein ohmscher Widerstand.
Da ist immer Widerstand.
Und wenn der groß wird, gibt es ein Problem.
Das heißt, das muss mit Kraft zusammengepresst werden.
Diese Kraft kann nachlassen.
Geräte können Vibrationen ausgesetzt sein, schütteln, dass diesen Stecker löst.
Man hat dann das Problem, dass das vielleicht alles aufgekratzt ist, wenn da starke Kontakte sind.
Dann kommt vielleicht Feuchtigkeit oder Öl dazu, irgendwas Korrosives.
dann entstehen da seltsame Effekte auf diesen Metallen, die da zusammenkommen.
Schmutz kann reinkommen, der möglicherweise leitet ist und zwischen zwei Steckerkontakten in irgendeiner Art eine leitfähige Verbindung herstellt.
Also gibt es viele Arten, wie dieser Stecker ausfallen kann.
Er ist auf jeden Fall wesentlich anfälliger dafür wie jede Art von Lötkontakten.
Vor allem Lötkontakte können auch Schutz isolieren.
Das heißt, er ist dann gegen Umwelteinflüsse recht robust, während der Stecker in seiner Natur stecken muss, offene Kontakte braucht.
Als Laie würde ich da sagen, gibt es dafür nicht die klassische Zugentlastung?
Zugentlastung ist sehr wichtig, weil wenn man das nicht hat, ist der Steckerkontakt innerhalb von wenigen Wochen kaputt.
Aber gegen die Vibrationen und verschiedene andere Arten von Umwelteinflüssen hilft auch die Zugentlastung nicht.
Jetzt hast du schon gesagt, ihr designt es dann so oder man designt so, dass man möglichst wenig Stecker hat.
Wie schaut denn so Design grundsätzlich aus?
Jetzt habt ihr die Anforderungen vom Kunden oder dem irgendwie die Anforderungen entlockt und habt euch irgendwie so grob auf das System geeinigt wahrscheinlich oder auf eine Preisgrößenordnung, was der braucht?
Dann geht ihr vermutlich ins Hardware-Design oder startet ihr da schon mit der Software?
Gibt es da eine Reihenfolge?
Kann die Software erst entwickelt werden, wenn die Hardware fertig designt ist, wenn man da wirklich einen Prototypen hat?
Also wie ist denn da der Ablauf?
Also wir machen es meistens sequenziell zuerst der Hardware-Design, danach Software-Design.
Man könnte das natürlich auch anders machen und parallelisieren hier.
Tun wir schon auch in Projekten, wo das Sinn macht.
Aber tatsächlich ist viel von der Treiberentwicklung oder der Plattformentwicklung kann man in der Software halt erst machen, wenn die Hardware da ist.
Und man muss das ja auch tun, um die Hardware zu validieren.
Also Hardware besteht aus zumeist Iterationen, zwei bis drei Hardware-Iterationen vom ersten Entwurf bis zum produktfähigen Design.
Und wird das dann irgendwie getestet, also simuliert auch schon irgendwie, also jetzt rein in ein Programm oder?
Geht man dann schon wirklich auf so ein Board, wo man irgendwas zusammensteckt?
Also wir gehen dann aufs Board.
Oder wir warten meistens, bis die erste Hardwareentwurf da ist und testen dann dieses Design durch und machen die Softwareentwicklung auf diesem Design.
Und von welchen Zeitgrößenordnungen sprechen wir da?
Also weil du jetzt gesagt hast, zwei, drei Iterationen und wir warten aufs Hardwaredesign.
Wie gesagt, wir sind jetzt wieder bei meiner Cloud-Welt, wo es um 15 Minuten geht oder so.
Okay, so schnell sind wir jetzt in Hardware nicht.
Aber in VIA Design starten bis zum ersten Prototyp sind so drei Monate.
Die erste Iteration.
Die erste Iteration, genau.
Und dann starten wir meistens auch mit der Softwareentwicklung auf dieser ersten Iteration.
Man identifiziert dann gegebenenfalls Fehler in der Elektronik.
Die tut man dann noch durch Mitarbeiter, die besonders gut am Lötkolben sind und besonders feine Augen reparieren lassen.
Das ist faszinierend, was da geht, was ein Mensch da noch löten kann, selbst für diesen kleinen Bauteilgrößen.
Und damit lernt man ja auch die Verbesserungen, die für das Hardware-Design notwendig ist.
Das sind so die Boards, auf denen die Software-Entwickler dann arbeiten.
Nach der dritten Iteration ist das PCB-Design fertig und man kann wirklich in die Fertigung gehen.
Genau, oft auch schon nach dem zweiten und ganz selten kann es auch passieren, dass man beim ersten Design schon so zufrieden ist, dass man nichts mehr tut.
Was man dann aber halt noch tut, wenn das Design einmal funktional fertig ist, ist das H2 Design, dass man schaut EMV, also eine elektromagnetische Verträglichkeitsprüfung, Einstrahlung, Abstrahlung, ob man da zufrieden ist.
Da gibt es dann meistens noch irgendwo einen kleinen Ferritperle oder irgendwas, was noch Platz finden muss.
Und da geht ihr dann in externe Labors wieder, wo ihr das testen lasst?
Nein, wir können es selbst testen in-house.
Das heißt, wir haben EMV-Messequipment und können das selbst machen.
Wir stellen keine Zertifikate aus.
Das tun wir nicht, weil wir kein kandidiertes Prüfhaus sind.
Okay, ihr könnt mal grundsätzlich für die Entwicklung auch die ganzen Messungen und so weiter machen.
Genau.
Das heißt, wir sprechen da dann von drei Monaten oder so.
Drei Monate bis zum ersten Entwurf, dann eine Softwareentwicklungsphase, Testen, Zulassungsphase.
Ich sage immer ein Jahr ist ein guter Zeitrahmen, um zu sagen, okay, ich starte das Projekt bis ich starte jetzt mit der Serienentwicklung bei unseren Kunden.
Das heißt aber, ihr habt es dann auf einem Developer Board zuerst zusammengesteckt, dann macht ihr die Software und erst wenn alles dann im Zusammenspiel funktioniert, bestellt ihr oder lasst ihr die PCBs fertigen?
Development Boards, genau, da testen wir, wenn es komplex ist, haben wir Evaluation Boards von Herstellern, wo man es probieren muss.
Aber man muss eben dann doch letztlich auf das Custom Design, weil das hat ja einen Grund, warum wir das gemacht haben.
Die Validierung der Software, die Entwicklung kann dann eigentlich nur auf der tatsächlichen Zielhardware stattfinden.
Okay, jetzt seid ihr da grundsätzlich fertig mit einem Custom PCB und bestellt es.
Es wird produziert, ihr bekommt es.
Bestellt man da mal drei Stück oder ein Testboard oder wie läuft dieser Vorgang ab?
Bestellt ihr da dann in China?
Gibt es da lokale?
Baut ihr das selber?
Wie läuft das ab?
Genau, also wir haben prinzipiell in St.
Pölte, unserem Standort, eine Fertigung.
Das ist manuell bedient der Fertigungsautomat, das ist unterstützt, aber die Bestückung findet manuell statt.
Und da können wir kleine Prototypen sehr flott selbst bestücken.
Die Leiterplatten ätzen wir jetzt nicht.
Die sind immer Zukaufprodukte, die können wir in China beziehen oder gibt es auch in Europa Leiterkartenfertiger.
Das geht normalerweise sehr flott und ist auch recht unproblematisch.
Da gibt es auch einen guten Industriestandard, wie man zu denen kommt.
Über diese Gerber-Austausch-Dateien, die kann man eigentlich jedem zur Verfügung stellen und man bekommt es dann.
Das ist ein Prozess, der funktioniert erstaunlich gut.
Das heißt, ihr lasst nur die Platten ätzen und bestücken, das macht ihr dann selber?
Genau, bestücken tun wir dann selber.
Korrekte Bestückung beim Hersteller hinzubekommen ist ein bisschen komplexer wie jetzt die Leiterplatte.
Da ist auch die Beschaffung der Bauteile immer Thema und was jetzt der Fertiger kriegt und wo der sitzt und ob der Kiddy ist, er jetzt alle Bauteile bekommt.
Also das ist spannend.
Du hast mir im Vorgespräch so eine Platine gezeigt, die so groß war ungefähr wie ein Laptop oder so in der Größenordnung.
Was kostet sowas, wenn man da jetzt zehn Stück bestellt?
Sind das dann hunderte Euro?
Was für Größenordnungen bewegen wir uns denn da?
Jetzt nur die Platine ohne die Bauteile, die da drauf kommen.
Kommt, also tatsächlich hat so viele hintere Werte, dass da so eine Aussage ganz schwierig ist.
Da mögen mich auch meine Kunden nie, wenn ich mal sage, ich kann es euch tatsächlich nicht sagen.
Diese Platinen schauen zwar alle grün aus und es kleben Bauteile drauf, aber es ist zum Beispiel der große Unterschied, ob sie ein- oder zweiseitig bestückt sind, weil es jetzt im Fertigungsprozess für den Bestücker sehr viel komplexer ist.
Aber wenn du mal die Bestückung weglasst, nur die Platine an sich, also die ihr dann später bestückt mit den ganzen Mikrocontrollern.
Dann kommt es noch davon, wie viele Lagen die hat.
Okay, Session, du wirst mir keine Antwort geben.
Aber ich schaffe es schon noch.
So eine Bandbreite irgendwo.
Einfaches Material, Basismaterial, wo jetzt keine Hochsignalleitungen drauf sind und alles Einfaches kostet sowas vielleicht 30 Euro.
Pro Stück?
Pro Stück, ja.
Aber da kann ich dann auch nur 10 bestellen, das ist okay.
Oder muss ich dann schon 100 bestellen?
Nein, nein, das kann man auch 10 bestellen.
Also das geht.
Die Lieferkosten kommen halt dann zu und Handlingkosten, die machen es dann in Summe, die Rechnungswert ist dann höher wie die 30 Euro.
pro Platine, aber das ist, was das Material da kostet.
Und eine größere Leiterplatte kann dann auch 300 bis 500 Dollar kosten.
Und jetzt baut ihr das dann alles zusammen, bestückt es selber und dann knallt ihr die Software drauf und alles geht.
Oder so ähnlich.
Wenn man das so tut, kommt der Rauch raus und nichts mehr geht.
Was man bei so einem Design halt dann hat, ist, dass man das Stück für Stück und Baugruppen für Baugruppen in Betrieb nimmt.
Also man beginnt dann einmal sehr vorsichtig bei der Spannungsversorgung und schaut, ob die tun und keine Kurzschlüsse haben.
Das macht man, indem man mit einer Thermikkamera draufschaut und schaut, ob das Ding irgendwo heiß wird.
Mit der Labornetzteile Strombegrenzung erhöht man.
schrittweise den Strom, um irgendwelche Hotspots zu finden.
Das ist einmal der erste Schritt, dass das nicht gleich in Hitze sich thermisch zerstört, dieses Design.
Und wenn man da einmal Konfidenz hat, dass es soweit geht, ist es nächsttrickreich, jetzt zu schauen, ob die ganzen Oszillatoren schwingen anfangen.
Das sind die ganzen Kristalle und Quarze.
Und dann, wenn das soweit ist und die Versorgungsspannung und Quarze gegeben ist, dann fangen wir mal an, mit dem Mikrocontroller zu schauen, ob man den finden kann über die Debug-Schnittstelle.
Dieses Quarze einschwingen, du hast es am Anfang schon erwähnt, für mich als absoluten Laien.
Was bedeutet, die Quarze müssen sich einschwingen oder sowas?
Ein Mikrocontroller ist ja ein synchrones Design.
Das heißt, wir haben diesen Takt, der ja mit einer gewissen zeitlichen Genauigkeit kommen muss.
Und so einen Taktgenerator macht man klassischerweise über einen Quarz.
Das ist ein speziell geschnittenes Stück Silizium.
das sich verformt und dann über Kondensatoren und diese mechanische Verformung einen Schwingkreis bildet, der x-mal pro Sekunde hin und her schwingt und pulsiert.
Das ist ein physikalischer Prozess, der braucht eine Zeit.
Das heißt, wenn ich den Start habe, dauert es zur Zeit, bis der sich stabil einschwingt zum Beispiel.
Und Mikroprozessoren arbeiten dann abhängig von der internen Komplexität erst dann gut, wenn es eine gewisse Genauigkeit hat.
Das heißt, wenn diese Schwingung einmal startet, dieser Takt, gestartet ist, gibt es da normalerweise eine analoge Taktüberwachung, die einmal schaut, ob der gut genug ist und wenn der gut genug ist, kommt die CPU aus dem Reset und startet mit ihren, das was wir halt von der CPU erwarten mit diesen Operationen.
Ich habe jetzt nicht nur die Quarzer eingeschwungen, sondern auch mich und jetzt will ich die ganze Sache endlich mal mit Software bestücken.
Wie sieht denn diese klassische Embedded Toolchain aus?
Sind wir so, wie ich das gerade stereotypentechnisch eingeleitet habe, 1970 stehen geblieben?
Bist du Bist du, Roland, der ANSI-C-Verfechter und klöppelst du die Assembler-Instruktionen wie damals bei Rollercoaster Tycoon noch selbst?
Jein.
Die Antwort ist ein klares und beherztes Jein.
Also es ist so, ich kann Assembler programmieren und unsere Ingenieure können das auch.
Und wir müssen und tun das auch manchmal.
Allerdings nur, wenn es notwendig ist.
Assembly ist beschränkt auf Startup von Mikrocontrollern.
Das heißt, die ersten paar Instruktionen von einem Bootloader oder von einem Kernel sind Assembly.
Das ist, weil halt Mikroprozessor so arbeiten, wie sie arbeiten.
Wir haben auch ein sehr spannendes Projekt gehabt, wo es um Strom sparen gegangen ist.
Da war unser Baubudget für die Ausführung von der Applikationslogik 15 Instruktionen.
Die haben wir dann auch per Hand ausgewählt in Assembly geschrieben, weil uns der C-Compiler hier schon mal...
Also dass der Funktionsepilog schon mal mehr Instruktionen gekostet hätte, wie die ganze Applikation zur Verfügung gehabt hat.
Aber das sind Ausnahmen.
In den meisten Fällen benutzen wir C.
Warum benutzen wir C?
Wahrscheinlich, weil C eine Sprache ist, die adäquat ist für die Größe des Problems und für die Art und Weise, wie Mikrocontroller funktionieren.
Solange der Mikroprozessor in diesem Loop von Instruction, Fetch, Decode, Calculation und Update funktioniert, Assemblesprachen decken diesen Modus operandi gut ab und C als wesentlich ein portabler Assembler ebenso.
Das heißt, die Sprache ist adäquat dem Problem, das sie löst.
Darum gibt es wenig wirklichen Grund, hier von C weg zu migrieren.
Es gibt natürlich schon Schwächen von C oder Sachen, die man heute anders machen würde oder Lessons learned in 50 Jahren Softwareentwicklung.
Ja, natürlich.
Aber viele der Sachen, die halt die modernen Sprachen dazubringen, hilft für die begrenzte Ressourcen, die man zur Verfügung hat am Mikrocontroller.
Ich meine, wir haben schon ein bisschen über die Größen geredet.
Es ist zu teuer.
Es ist zu teuer.
Es bringt im Ende des nicht im Produkt, was es jetzt vielleicht in Software-Wiegelung bringt, weil es andere Kosten an anderen Stellen verursacht.
Was wir auch immer...
Brauchen sind so Sachen wie Linkerskripte, das heißt, wir beschäftigen uns auch ganz fest damit, wo im Speicher liegen denn unsere Sachen, weil verschiedene Speicheradressen verschiedene Eigenschaften in Hardware haben, weil die Hardware-Peripherieblöcke gewisse Speicherbereiche haben, wo sie Daten erwarten.
Das heißt, wir müssen das kontrollieren, wo im Speicher unsere Sachen liegen.
Das heißt, wir brauchen eine Art, mit Speicher zu rechnen und mit Adressen zu rechnen.
Das ist ein großes Plus in der Embedded-Entwicklung.
Wenn ich das wegapster hier und Safety und so weiter nicht zugreifbar mache, dann fehlt was.
Da geht was nicht.
Beim modernen Betriebssystem machst du oft diese Speicherverwürfelung, diese Speicherrandom...
Randomization.
Ganz genau, damit du als Angreifer nicht vorkasten kannst, wo etwas im Speicher liegt.
Das mache ich allerdings nur im User Space.
Also der Kernel weiß dann hoffentlich schon, wo seine Pages sind.
Aber das, wenn ich hier so zuhöre, dann...
Klingt das ja so, als sind diese, ich nenne es mal Sicherheitsmechanismen, oft auf diesen Embedded Devices deaktiviert.
Die meisten Embedded Devices haben in der NMU.
Das heißt, die könnten technisch, wenn sie nicht einmal in der Lage, diese Speicherverwirflung zu machen, in keinster Art und Weise.
Also es ist jetzt schon modernerer CPUs, haben so eine Art Memory Protection Unit und können zumindest, wenn ich gewisse Code-Teile ausführe, kann ich sagen, nur in diesem Speicher bleiben, bitte, danke.
und kriegt dann einen Interrupt, wenn jetzt innerhalb dieser Code-Sequenz außerhalb zugegriffen wird.
Das heißt, ich habe so eine ganz primitive Speicherschutzmechanismen.
Ist eher moderner, sage ich so.
Also da war das auf Desktop und Servern schon lang State of the Art.
Jetzt hast du davor erwähnt, Linux ist mittlerweile auch Realtime-fähig.
Ist Linux dann das Klassische, was man dort verwendet?
Gibt es da andere Betriebssysteme?
Und vor allem ist es dann, wenn man so programmiert, Merkst du da einen großen Unterschied, ob du jetzt C programmierst im Linux oder in irgendeinem anderen Operating System, also so im alltäglichen Coding, gibt es da überhaupt Unterschiede oder programmier da einfach C runter und was für Speicher da im Hintergrund liegt, ist mir eigentlich eh egal.
Das Spannendste ist natürlich die Verfügbarkeit von Bibliotheken und APIs.
Und Linux ist für viele unserer Beugte zu groß, vom Ressourcenverbrauch, Startup-Zeiten.
Es ist einfach mit Kanonen auf Spatzen schießen.
Also es ist den meisten Tasks nicht notwendig, derart potentes Betriebssystem wie Linux einzusetzen, um einen kleinen Eventloop zu schreiben.
Was wir viel verwenden in unseren Projekten ist Sapphire.
Das ist ein Echtzeitbetriebssystem, ein RDoS, das auch unter dem Dach der Linux Foundation ist.
Das teilt auch ein paar Technologien mit dem Linux-Kernel, zum Beispiel den Device Tree, auch das K-Config-System.
teils mit dem Linux-Körnel.
Das ist ein für uns sehr geschicktes System und auch in dem Sinne modern, wie es hat CPU-DIC, es hat Socket-API für Netzwerke.
Also da ist man schon sehr im vertrauten Umfeld.
Und das programmiert sich dann ähnlich, sage ich jetzt einmal, wie Low-Level-Linux-Applikationen, was natürlich sehr fein ist intellektuell, weil man nicht so viele verschiedene APIs schaukeln muss.
Es gibt auch noch andere RTOS, habe ich sehr bekannt, das ist FreeRTOS.
Im Wesentlichen ist es ein Scheduler, das heißt eben ein Task-Scheduler, das ist die Hauptaufgabe, die es macht.
Das heißt, der Hochprioritask kommt dran und tut seine Sachen.
Es ist ein minimalistisches OS, es ist recht weit verbreitet.
Teilweise ist die Code-Qualität so, naja, so genau will man nicht hinschauen.
Es ist übrigens sehr robust, also sehr viele Wi-Fi-Karten oder Netzwerkkarten, Firmware haben, haben da Free-RTOS oder irgend sowas drin, in der so ist.
Wahrscheinlich auch im Desktop-System drei, vier Instanzen davon laufen oder so.
Das ist WordPress der Real-Time Operating Systems.
Ja, so kann man es vielleicht bezeichnen.
Aber das ist alles Open-Source und Free, weil Free-RTOS.
Genau, Free-RTOS ist frei, Open-Source sehr oft mit-licensed, auch SIFIRE ist MIT-licensed.
Ich muss hier meine Anwendung nicht sharen, was auch im Embedded-Markt sehr viel mehr Sinn macht wie GPL, weil ich ja letztlich ein Firmware-Binary baue.
Also ich linke hier alles zusammen.
Ohne Linking-Exception wäre es schwer, mit GPL-lizenzierten Echtzeitbetriebssystemen da irgendwas zu tun.
Und man greift auch für die Applikation sehr oft das Betriebssystem selbst an.
Für kommerziell sind die MIT-Lizenzen attraktiver, sage ich mal so.
Und gibt es dann kommerzielle Operating Systems auch oder ist das dann alles Eigenentwicklung?
Nein, es gibt Echtzeitbetriebssysteme wahrscheinlich wie Sander mehr, weil sie in Wirklichkeit nicht sonderlich komplex sind, weil der Hauptfokus ist, Threats nach Priorität sortiert zu schedulen.
auf Interrupts zu reagieren, unterbrechbar zu sein.
Da gibt es sehr viele.
Also QNX ist zum Beispiel eins oder VXWorks.
ARM hat Embed-OS gemacht, hat das allerdings jetzt aufgelassen und verweist und dann zum Beispiel auf Sapphire als Open-Source-Alternative, als Nachfolgeprodukt, das möglich ist.
Das heißt, es findet auch schon eine gewisse Konsolidierung statt, weil das Tooling rundherum um die Systeme ist eigentlich das, was sehr viel aufwendiger ist.
Board-zu-Board, wie viele Mikroprozessoren werden unterstützt.
Also hier.
ist eigentlich der Hauptauf oder das Hauptaugenmerk zu legen.
Technisch sind sie recht einfach, diese RTOSs.
Jetzt für mich als Endkundenlein, sage ich mal, funktioniert ja in so einem Linux einfach alles.
Ich stecke da eine Maus an und das funktioniert.
Ich bin ja auch alt genug, Andi, du verstehst das jetzt nicht, von was ich rede, aber zu meinen Anfangszeiten, da hat man so einen Maustreiber installiert und einen Tastaturtreiber in DOS und hat den dann geladen und nicht geladen.
Heutzutage geht das alles Magic automatisch.
Ich vermute, bei dir ist es anders.
Wie funktioniert das mit Treibern?
Wird das weg abstrahiert von so einem Operating System oder musst du das alles handeln oder braucht man das heutzutage gar nicht mehr?
Ich weiß gar nicht, warum es bei mir eigentlich alles automatisch geht heutzutage.
Jetzt sind wir ganz nah an dieser 70-Jahre-Diskussion.
Tatsächlich viele Embedded-Projekte.
Aber wir haben da überhaupt keine klare Trennung zwischen Hardware und Applikationslogik.
Das heißt, da hat man ein bisschen Businesslogik.
Wenn jetzt, weiß ich nicht, irgendein Messwert größer ist, irgendeinem Schwellwert, dann, und dann schreibt man hartgecodet irgendwelche Registeradressen und irgendwas rein.
Also du darfst da keinen Treiber, weil du direkt quasi selber direkt drauf, Direct Access.
Direct Access, genau, ist natürlich für Softwarearchitektur, Portierbarkeit und Resetting über den Code ist natürlich eine Katastrophe.
Tatsächlich ist das bei vielen Bedded-Projekten so.
Hier ist zum Beispiel jetzt Sapphire als positives Beispiel zu erwähnen.
Das hat ein Dreibermodell.
Hier gibt es für Lads und leuchtende Elemente eine API.
Und der geneigte Softwareentwickler ist angehalten, das API zu implementieren auf seiner Plattform und dann die API, um ein Lad anzuschalten, zu verwenden, statt dann direkt einfach aufs Register zu schreiben.
Das Problem ist halt, wenn ihr die Registeradressen kennt und das in Bedded-Entwickler kennt man seine Datenblätter, Es ist halt auch sehr einfach, ein Bit irgendwo in einem Speicherbereich zu setzen, um es leuchten zu lassen.
Softwaremäßig ist eine Katastrophe und die Dokumentation von solchen Codes ist natürlich auch eine Kunst für sich, weil so ein direkter Speicherzugriff mit in der Applikationslogik natürlich mehr Kommentar braucht, wie du je irgendwo sparen könntest.
Aber auch hier zieht moderne Softwareentwicklung ein und das geht schon in die richtige Richtung.
Ich bin ja ein bisschen im Energiebereich unterwegs, da gibt es zum Beispiel auch...
Den klassischen Modbus, der wird ganz oft verwendet, um so Wärmepumpen und so weiter anzusteuern.
Gibt es...
Für sowas ist das dann schon alles implementiert?
Da gibt es eine Library und du kannst darauf zugreifen, um so mit Modbus zu kommunizieren zum Beispiel?
Oder programmiert man das dann wieder selbst?
Das hoffe ich nicht.
Allein deswegen, weil eine Tochterfirma von uns ein Modbus-Stack als Produkt vermarktet, hoffe ich, dass...
Okay, wird dann euer Tool verwenden.
Dass man das sehr wohl lizenziert.
Was natürlich die Herausforderung an so einem Tool ist, die Portierbarkeit auf...
X verschiedene Operating-Systeme und Y verschiedene Mikrocontroller.
Es gibt eine große Matrix X mal Y von möglichen Konstellationen, in denen das eingesetzt wird.
Aber ich habe jetzt nicht wie in Python einen Package-Manager, wo ich sage, install Modbus, Package, keine Ahnung, und dann funktioniert alles out of the box oder fast out of the box.
Klassischerweise jetzt eher nicht.
In Sapphire jetzt schon, dort ist das über so ein...
West heißt dieses Tool, so verwaltet eine Summe von Git-Repositores und hier kann ich dann so Third-Party-Bibliotheken sehr einfach hinzufügen, die ich im Manifest beschreibe.
Das ist dann so ein Backpage-Management, halt alles auf Source-Ebene.
Da gibt es das schon und der Trend geht natürlich schon zu dieser einfacheren Erweiterbarkeit auch von Echtzeitbetriebssystemen a la App und Shop und Clickbait-Komponente dazu.
Ist natürlich ein Wunsch, ja.
Ist umgesetzt, aber...
Aber es ist noch nicht so leicht, wie man es gerne sehen würde.
Also ihr seid in den 80ern dann, also nicht mal in den 70ern, sondern in den 85ern.
85er, Digga.
Da weiß ich aber schon weiter.
Also wenn man sich jetzt ganz auf einen Hersteller nur seine Mikrocontroller, seine Serien und seine IDEs einlasst, dann ist man weiter.
Dann hat man schon Eclipse mit Marketplace, wo alles verfügbar ist.
Das sind tatsächlich sehr hochintegrierte Tools.
Allerdings ist man dann, also es ist sehr Apple-Land.
sehr schnell, sehr begrenzt, was geht und was nicht geht.
Viele Dinge gehen out of the box.
Also für ein Team, das jetzt eine Produktentwicklung machen möchte, sagt, wir kaufen uns jetzt da, weiß nicht, irgendein Hersteller Text-Instruments ein, wir werden jetzt da Partner, das ist unser Ding und wir schauen nicht links und nicht rechts, gibt es schon viele sehr gut ausgetretete Wege für den mehr aus dem Open-Source kommenden Entwickler.
Also wir verstehen uns als solche, unsere.
Tools, die wir verwenden, sind im Embedded Linux oder Sapphire, das Open-Source-Betriebssystem, sind da die Wege noch teilweise etwas ruppiger und weniger ausgetreten.
Hast du gerade Eclipse gesagt?
Eclipse ist ein sehr beliebtes Tool, ja.
Moment, da sprechen wir von der IDI.
Von der IDI, ja.
Die IDI Eclipse ist in sehr vielen proprietären Systemen einfach adaptiert und angepasst worden für den Mikrokonzern.
Ich war mit meinen 85er-Jahren gar nicht so weit weg.
Herr Roland, ich wollte gerade sagen, die 90er haben gerade angerufen, die wollen ihre IDE zurück.
Ich wäre sehr gewillt, sie dir wiederzugeben, ja, kein Problem.
Jetzt ist es aber auch in der modernen Softwareentwicklung schon kompliziert genug, die ganze Software für verschiedene Plattformen zu bauen.
Wir haben inzwischen auch in der Cloud ARM CPUs und x86 CPUs und dann haben wir teilweise in den Mobile Apps.
iOS-Applikationen kannst du nur auf einem Mac bauen und natürlich manche Sprachen haben irgendwie so Cross-Kompilathematiken, dass man vielleicht etwas für WebAssembly baut und so weiter und so fort.
Und jetzt kommst du um die Ecke und sagst mir immer, es gibt 35.000 verschiedene Chips mit noch mehr verschiedenen Sensoren, die alle irgendwie Treiber benötigen.
Wie funktioniert Continuous Integration, Continuous Deployment, Continuous Delivery für Embedded-Systeme?
A, gibt es sowas überhaupt?
B.
Hofft ihr, dass eure Realtime Operating Systems fehlerfrei in einer neuen Version für die Target-Chip-Architektur funktionieren?
Also ist bei euch Hoffnung eine Strategie oder habt ihr da irgendwo einen Server stehen, wo ihr, weiß ich nicht, per Kabel alle Chips gerade irgendwie connected habt und dann habt ihr noch, wenn ich jetzt schon über Eclipse rede, einen Jenkins laufen oder damals vielleicht noch einen Hudson.
für die ganz jungen Leute.
Jenkins ist ein Continuous Integration Server.
Hudson war das ursprüngliche Projekt von Jenkins, bevor es geforkt wurde.
Oder was weiß ich, wie die alten CI, CD Produkte heißen.
Also CI, CD ist in Embedded kleingeschrieben, wenn überhaupt vorhanden.
Also hier auch Sapphire als Betriebssystem sehr hervorzuheben und zu erwähnen.
Die haben so etwas aufgebaut.
Das heißt, die haben...
Die machen ihre Releases und ihre Contributions, werden da über einen Continuous Integration Server getestet.
Und dort ist im Serverschrank ganz viele Kabel.
Es geht auf tatsächliche Hardware.
Das heißt, es wird dann in Firmware-Image gebaut, eingespielt und dann über den UART geschaut, ob das erwünschte Output dort rauskommt.
Das heißt, die machen das, was natürlich der Qualität sehr entgegenkommt.
Das ist natürlich schon was sehr Tolles, entspricht aber aufwärtigem Aufbau.
Auch die Wartung und Pflege, das muss man ja alles hegen und pflegen.
Ich könnte mir auch vorstellen, dass grundsätzlich bei deinen Projekten jetzt, du entwickelst das ja mehr oder weniger einmal und that's it und dann läuft das.
Vielleicht gibt es noch ein, zwei Updates, aber Sapphire ist ja auch ein Produkt, was ständig Updates als Operating System bekommt und natürlich viel mehr getestet werden muss, oder?
Ihr könntet das wahrscheinlich einfach von den Kosten auch gar nicht irgendwie...
Und es kommen wahrscheinlich gar nicht so viele Updates, dass es sich rentiert, das irgendwie automatisch zu updaten.
Wir hätten den Benefit nicht, ja.
Also es ist so, wenn wir eine Produktentwicklung mit Safari starten, nehmen wir die Version, die gerade aktuell ist, oder die letzte LTS oder wie auch immer, machen unser Produkt, entwickeln das auf dem und wir testen das Produkt.
Ein Battle-Produkt ist sehr oft tatsächlich vollständig testbar an den Schnittstellen.
Also wenn man jetzt an dieses Fernglas denkt, das hat als User-Schnittstelle einen Anschaltknopf.
einen Ausschaltknopf.
Es hat dann tatsächlich irgendwo eine Updateschnittstelle, die lassen wir mal außen vor, aber das war es in Wirklichkeit.
Also das Ding ist offline?
Das Ding ist offline, ja.
Das hat keinen Funk.
Das hat ein Kabel gebunden in der Updateschnittstelle.
Aber es ist an- und ausschaltbar.
Das ist eigentlich die einzige Interaktion, die der User hat.
Das sind die zwei Events für Blackbox-Testing, die zur Verfügung stehen.
Und danach muss es halt seine Optik-Regeleigenschaften und Performance bringen.
Die testet man natürlich dann schon noch.
bei einem Produkt durch, ob es das tut, was es tut im Sinne der Regelung, aber dann gibt es da nicht so viel.
Und da ich dieses Testen, ob es die Regeleigenschaften bringt, da brauche ich einen Testaufbau, da muss ich jetzt irgendwie diese Optik vermessen.
Das ist ja ein komplexer Aufbau.
Das kann ich jetzt in einem Continuous Integration Run gar nicht wirklich machen.
Also da mache ich einen Release-Kandidat, prüfe den Affair zu nieren und release das dann.
Und dazwischen bringt es nicht viel, dieses Testen direkt in Hardware.
Jetzt bin ich beruflich im Observability-Bereich unterwegs.
Das bedeutet Metriken, Logging, aber auch natürlich sowas wie Tracing, Continuous Profiling und Co.
Und ich weiß gar nicht mehr, wie man ohne Tracing heutzutage überhaupt noch arbeiten soll, bei der ganzen Komplexität von der Software.
Jetzt kommen mir die C-Leute um die Ecke.
Andi, wir haben noch Breakpoints.
Jetzt reden wir über Realtime Operating Systems, über Interrupts, über Prioritäten von Events.
Da passt so ein Breakpoint nicht wirklich ins Konzept, weil das ja das zeitliche Verhalten ändert.
Genau.
Wie debuggt ihr?
Habt ihr sowas wie Tracing?
Gibt es Echtzeit-Debugging bei euch?
Oder wie holt ihr die Fehler daraus?
Die erste Qualität ist natürlich, die Fehler gar nicht erstmal reinzutun.
Dann muss man sie nicht rausholen.
Nachdem dieser Ansatz seit Jahrzehnten scheitert, haben wir so etwas Ähnliches wie Printf-Debugging für arme Embedded-Entwickler und das ist einen Chip-Iopen wackeln lassen und Oszilloskop anschließen oder Logic-Analyzer.
Das heißt, eine Sache ist, wir haben halt ein paar Pins und können auf denen den Pegel ausgeben und schauen damit, was passiert.
Das ist schon einmal sehr, sehr, sehr viel nützlicher, wie nichts über das System zu wissen.
Aber um das zu verstehen, ihr habt dann If drinnen und wenn irgendwas so ist, dann...
geht der Begel nach oben und am Oszilloskop seht ihr dann, dass der Begel nach oben geht und diese IF-Schleife, also dieser IF-Block getroffen wurde.
Genau, ja.
Und vor allem könnt ihr dann auch messen im Vergleich zum anderen Signal die zeitlichen Abstände dazwischen, die ja meistens ebenso interessant sind wie nur, ob das IF getroffen wird oder nicht.
Also du hast das gerade bezeichnet als Printf fürs Oszilloskop.
Und ich glaube, das trifft es 100 Prozent, weil wenn ich das richtig verstanden habe, diese If-Abfragen, die packt ihr dann wirklich nur fürs Debugging da rein und die holt ihr später wieder raus, richtig?
Genau, weil die machen minimale zeitliche Veränderungen im Programm.
Ein Breakpoint in einem Regelalgorithmus, ein Regelalgorithmus per Definition nimmt die Zeit zwischen Iterationen, um sein Regelding zu tun.
Wenn du da ein Breakpoint reinmachst, kann ich mir schon kurz die Arithmetik anschauen, ob die stimmt.
Das Regelverhalten ist natürlich nicht mehr gegeben.
Der Regler ist dann auch tot und das System ist gegen die Wand gefahren oder sehr equivalent, was halt, wenn die Regelung dort nicht mehr funktioniert, passiert.
Also damit kann ich viele Sachen einfach gar nicht testen mit Breakpoints.
Aber so Logging macht ihr dann überhaupt nicht aus Platzgründen, oder?
Logging hat vor allem das primäre Problem der Bandbreite.
Ich habe eigentlich nicht die Schnittstelle, um die Logging-Informationen jetzt irgendwo über UART, was jetzt ja More Advanced Printed ist, verwenden wir schon auch.
dass man dort was rausschreibt.
Also das ist ein Print-Dev-Debugging für Softwareentwickler im Wesentlichen.
Ein UART braucht man doch.
Kann man schon tun, aber die Bandbreite stimmt nicht.
Also es geht nicht.
Ja, wer könnte das ja lokal speichern, oder?
Da stimmen die Speicherbandbreiten nicht.
Flash ist viel zu langsam relevante Mengen.
Also entweder geht es ins RAM mit einem kleinen Buffer und das ganze Event hat im RAM Platz oder man hat dahingehend verloren.
Man hat keinen Speicher, die schnell genug sind.
Nichts wie NVMe oder irgend sowas.
Wir müssen Flash-Bereiche, bevor man irgendwas tut, müssen sie löschen.
Dann müssen wir auf Hardware-Ebene ein bisschen Polling vom Controller machen, wo er schon gelöscht hat.
Die Zeiten sind irgendwo zwischen, bis irgendwas definiert.
Und wenn der dann sagt, ich habe jetzt gelöscht, dann können wir schreiben.
Dann müssen wir wieder ein bisschen pollen, wo er jetzt schon geschrieben hat.
Also da kann man keine Logdaten so in dem klassischen Sinn loswerden.
Was es schon gibt, sind Debug-Units auf der Hardware, am SOC selbst.
Da gibt es auch Tracing-Units.
Die sind natürlich schon sehr, sehr, sehr mächtig, weil die tracen den Instruction-Stream in Echtzeit weg.
Man braucht halt dann eine leistungsfähige PC in Nähe, in Kabelnähe, in Kurzakabelnähe, um ganz genau zu sein, weil es sind hochfrequente Signale.
Parallele Leitungen sind dann vier bis acht Signale.
Aber das ist natürlich schon sehr mächtig, weil hier sieht man die Instruktionen-Stream.
Also jede einzelne Instruktion, die ausgeführt wurde, Mikrocontroller, sieht man hier in zeitlicher Abfolge.
Jetzt programmiert ihr C, wenn ihr da Memory League reinprogrammiert, weil das geht ja bei C, habe ich gehört.
Und so ein Feinglas stürzt alle fünf Tage ab.
Wie debuggt man das?
Na, Memory Leaks haben wir keine, weil wir statisch anlockieren.
Weil wir kein Melog Free oder sowas machen.
Braucht es auch nicht.
Wir kennen eigentlich die Ressourcen vorab.
und pullen die Speicherbereiche entsprechend auf.
Für zyklische Daten gibt es Ringpuffer oder ähnliche Strukturen, wo halt eine gewisse Zeit im Speicher Platz hat und danach wird überschrieben.
Das heißt, sowas wie Memory League ist eigentlich kein Thema.
Was es schon gibt, sind eventuell Data oder Live-Logs.
Das heißt, dass man Locking vergisst, zurückzugeben und der Mutex nicht mehr freigibt oder sowas.
Das könnte passieren.
Und wie findet man das dann raus, wenn das irgendwann mal passiert?
Ich glaube, da ist tatsächlich, ich meine, auch die Größe des Flashes deutet es ja dann noch fest an.
Die Komplexität von den Embedded Software ist geringer.
Ich deploy keine Megabyte großen Stacks, die ich irgendwo im Internet gefunden habe, Frameworks für irgendeine Funktion aufs Gerät.
Es ist minimal und das reduziert natürlich auch die Anzahl der Fehler und letztlich muss das System irgendwie testbar sein.
Wenn die Softwarekomplexität dann so hoch wird, dann macht man was wie Embedded Linux, wo man dann auch die Tools hat für Softwareentwicklung, die man dann kennt.
Ja, und eine Sache natürlich auch bei Embedded Debugging und Tracing.
Also Tracing ist zwar cool, weil man alle Instruktionen sieht, aber oft einmal hat man dann so tolle Fehler wie nach ca.
72 Stunden kommt es zum Systemausfall und der Speicherchip liefert nur mehr Einsen statt der Gewohnheit.
Daten, die da drinnen waren.
Das ist dann schon einmal zur Diagnose an sich schon aufregend genug, zu dieser Diagnose zu kommen, weil einfach das System nach 72 Stunden steht und man fährt halt halt mit Debug-Session drauf und macht dann Analyse, was halt noch periphery dran ist.
Das ist sehr schwer zu debuggen, solche Fehler.
Also da geht dann viel Arbeit oder Entwicklungszeit, geht dann dort einfach hinein.
Thesen aufstellen.
diesen testen, Code instrumentalisieren.
Das heißt zu schauen, na gut, vielleicht passiert ja davor, dass wir irgendwie den externen Speicher resetieren.
Dann wird man halt in der Reset-Logik von dem Speicher einer dieser GPIOs zum Beispiel auf High schalten.
Und wenn der Fehler dann aufgetreten ist, kann man schauen, okay, haben wir den Speicher resetiert, sind wir durch die Reset-Funktion vom Speicher durchgelaufen, ja oder nein.
Und so muss man halt dieses Problem dann nähern, weil vor allem, wenn Hardware-Fehler mit dabei sind, ist das halt Also wir debuggen nicht nur Softwarefehler in Embedded.
Ich wollte gerade sagen, woher weißt du, es könnte ja auch ein Hardwarefehler sein, einfach kaputtes Bauteil, oder?
Genau.
Kaputtes Bauteil ist jetzt weniger oft der Fall, hat es auch schon gegeben.
Es ist fast immer natürlich, dass unser Custom-Design ist, dass irgendein...
Irgendeine Bedingung, wie das Bauteil zu verwenden ist, falsch gemacht worden ist.
Das heißt, dass die Versorgungsspannung 0,01 Prozent unterhalb des Minimalwerts tippt.
In manchen Fällen, das kann passieren, zwar Spannungsversorgung ist nicht immer stabil.
Was man dann tut, ist, dass man Detektor-Schaltung die Spannungsversorgung des Bauteils anhängt und schaut, ob die in diesen 72 Stunden irgendwo hinunter geht.
Könnte ein Drop in der Versorgungsspannung das Fehlverhalten auslösen.
Oder man muss die...
Beim Speicherbaustein hat man viele Leitungen, die zeitliche Constraints haben über die Signale, man muss die mittracen.
Gibt es dort Verletzungen der zeitlichen Integrität?
Also da ist man dann schon, das ist dann schon sehr spannendes Debugging.
Und vor allem Spannungstrops zum Beispiel kann sein, dass eine Leitung verbindet, ja zwei Bausteine, eine Spannungsquelle mit einem Verbraucher.
Kann zum Beispiel sein, dass man bei der Quelle den Spannungstopp nicht sieht.
Allerdings beim Verbraucher schon.
Die Spannung ändert sich über das Signal oder über die Leitung.
Die ist ja nicht überall gleich.
Also da kommt es auch noch dran, wo messe ich und wie gut ist die Messspitze, die ich einsetze.
Da gibt es dann Messspitzen, die kosten mehrere tausend Euro.
Nur die Messspitze, weil die besonders gute Qualitäten hat, um gewisse Signale messen zu können.
Die ist dann im wahrsten Sinne aus Gold?
Ja, das ist eine diamantbeschichtete Messspitze.
Denn Diamant braucht sie, dass sie besonders gut in das Metall hineingesteckt werden kann und da besonders hart ist.
Die braucht man für hochfrequente Signale, zum Beispiel PCI-Express-Signale oder irgend sowas monitoren möchte.
Weil da ist die Messspitze in der Leitung von PCI-Express, also ein sogenannter T-Stich, was die Welleneigenschaften dieses Leiters ändert.
Und damit hast du ein ganz anderes System.
bisher expressmäßig, ob diese Westspitze drinnen steckt oder nicht.
Also Andi, vergiss so Diamantringe, nimm einfach Spitzen in Zukunft.
Das klingt für mich eher nach einem Bereich der Softwareentwicklung, was für den Hobbybereich eigentlich weniger zugänglich ist.
Das ist für den Hobbybereich definitiv weniger zugänglich, da wird dann auch das Equipment teuer.
Nicht nur um Hobbyisten auszuschließen, aber es ist einfach, die Physik ist die Physik.
Da müssen wir uns beugen, da können wir nichts viel machen.
Und wenn sie sagt, Leute haben Welleneigenschaften, dann gilt es, das einfach zu akzeptieren und damit zu leben, dass das halt so ist.
Jetzt haben wir ziemlich viel über Speicherlimitierungen gesprochen, über Bandbereitenlimitierungen und auch über Bugs, die sich leider nicht vermeiden lassen und auch über irgendwelche Ferngläser, die anscheinend jetzt eine Software haben.
Das bringt mich zu der Frage Updates und Wartbarkeit.
Denn klar, Hardware updaten.
Ist ein bisschen schwierig, neue Platinen, Ätzen etc.
Aber vielleicht kriegt man ja irgendwie eine Software drauf.
Und ich sage mal, ein klassischer Update-Prozess in meinem Kopf.
Du hast hier aktuelle Software da laufen, irgendwie kommt die neue Software da drauf, die wird daneben gelegt und irgendwann wird die halt geflippt.
Jetzt sind die Speicherbereiche sehr limitiert.
Und vielleicht kommt auch da der Begriff des Hardware-Breakings irgendwie in den Sinn.
Also wie läuft Updates?
Was passiert, wenn ein Update schief geht?
Wie sieht es mit Over-the-Air-Updates aus?
Oder muss ich das immer mit Pins an meinen Computer adden?
Oder, oder, oder.
Ja, das ist eine Frage, die der Industrie momentan sehr quer liegt, weil halt für viele dieser Embedded-Geräte, die man hat, Updates einfach schlicht nicht vorgesehen waren.
Ohne, dass man da jetzt sagt, ja, man ist hier grob fahrlässig am Weg, aber man hat das Gerät getestet, es bringt die Funktionalität und wozu soll ich jetzt dieses Fernglas, wenn es das tut, updaten?
Ein Grund, warum ich auch dieses Fernglas updaten können muss, ist ein Cyber Resilience Act, der davor schreibt, dass alles prinzipiell, was Software und Mikrokontrolle ist, updatbar sein muss.
Somit auch mein Offline-Fernglas, dessen Attack-Surface jetzt wahrscheinlich schon sehr gering ist.
Eben aus diesem Grund, dass man viel einfach getestet hat und das dann ja auch funktioniert und Hersteller da jetzt nicht immer Updates geliefert haben.
Ich meine, jetzt soll es nicht sagen, okay, das ist alles gut, was da passiert ist, weil es sind ja auch Sachen nicht abgedetet worden, die ein Attack-Surface haben oder die im Netzwerk hängen, was natürlich No-Go ist.
Aber viele der Hardware unterstützt eigentlich.
Kein gutes Update.
Also wir haben oft Mikroprozessoren, die haben zwar in ROM einen Bootloader drinnen, damit kann ich dann von etwas anderem booten, wie vom Internet Flash oder die könnt ihr dann benutzen, um ein Update einzuspielen ins Internet Flash.
Aber das Internet Flash ist sehr begrenzt.
Wenn ich das halbiere, weil ich ein AB-Schema habe und ein Bootloader, dann schmerzt es, weil dann die Applikationen nicht mehr hineingehen.
Das ist natürlich eine Ko-Evolution, Softwarekomplexität und größere Speicher im Mikrocontroller.
sind, was man halt jetzt braucht.
Und mit dem CAA verdoppelt man hier plötzlich den Platz, den man braucht für die Firmware wegen dieser Update-Funktionalität, die bis jetzt ja in dem Sinn nicht vorgesehen war.
Und da sind wir jetzt mit einigen Kunden dran, dass man halt updatebare Embedded-Systeme designen.
Da braucht man externen Speicher in irgendeiner Art und Weise.
Da muss eine Art von SD-Card oder irgendwas hinauf.
Man braucht eine Schnittstelle, man braucht einen Bootloader.
Man braucht eine Erkennung, ob das Update gut gegangen ist oder nicht.
Man braucht eine Infrastruktur beim Kunden, die man davor nicht gebraucht hat.
Das muss einem Kunden zur Verfügung gestellt werden.
Man muss ausschließen, dass man irgendeinen Garbage drauf flasht und dann möchte man auch noch sicher gestalten.
Das heißt, vielleicht signierte Updates.
Das ist dann wieder schwierig, so eine RSA-Signatur zum Beispiel auf einen Mikroprozessor zu rechnen, der kein Hardware-Krypto hat.
Das dauert mit.
Das ist einfach gar nicht so einfach möglich.
Andere Verfahren sind da ein bisschen besser als RSA.
Aber trotzdem ist das auch ein Aufwand.
Und das ist auch die Frage, wenn der Kunde jetzt so fünf Minuten sein Gerät beim Blinken anschauen darf, fragt er sich auch, lebt es doch oder nicht?
Man hat ja nicht wirklich die Möglichkeit, Feedback zu geben im Embedded-Gerät.
Das heißt, man muss auch das noch mit einplanen.
Braucht jetzt noch ein Läd, wo ich den Systemzustand kommuniziere.
Ein Läd bedeutet auch in einem Gehäuse ein Loch.
Ein Loch bedeutet Dichtungsthemen.
Da kommt ja sehr viel zusammen.
Dann kann er sich sagen, okay, ich nehme sowas wie USB, USB ist für Embedded und doch ein sehr komplexer Bus, der braucht schon wieder eigene.
eigene Schwingungen und eigene Taktdomänen und das ist auch ein eigenes Biest und dann brauchen wir Host-Software vielleicht auch noch machen, die das auslesen kann.
Also das ist schon eine große Herausforderung, diese Abdeckbarkeit zu machen.
Einfach ist es nicht, möglich ist es auf jeden Fall, aber wahrscheinlich nicht mit den klassischen Designs, die man gemacht hat.
Das heißt, man wird die Hardware-Design entsprechend für diesen CAA auch anpassen müssen, dass das überhaupt machbar ist, diese Abdeckbarkeit.
Aber das ist ja dann schon, ich sage mal, Gold wert für jeden Security-Researcher, der sagt, Och, die meisten Dinge haben keine Updates, dann kann ich die versuchen zu bricken, denn ich weiß, ein Fix kommt nicht.
Das schon, aber ich meine, was außer Publikation einer Webseite mit einem benannten Bug und ein paar Häme für den Hersteller bringt es das Fernglas, Security zu attacken?
Also was ist der Effekt?
Die Frage ist ja auch, wie viele von diesen klassischen Systemen sind überhaupt online?
Also klar kann man offline auch.
natürlich angreifen, aber der klassische Angriffsvektor ist ja eher, wenn irgendwas online ist.
Und ich vermute mal, so irgendeine Prozesssteuerung wird gar nicht online sein, oder?
Von irgendeiner Produktionsstraße.
Oder sind die online?
Die Realität ist, sie sind online.
Die Theorie ist, sie sollten nicht sein.
Also ich sehe das gar nicht, dass der Attackvektor immer nur online sein muss.
Online ist bequem und es skaliert und ja, pipapo, du musst nicht vor Ort sein.
Aber ich sehe es viel Wenn es halt nicht online ist und mit so Sachen wie Stuxnet und Pipapo, wurde es glaube ich schon etliche Male bewiesen, dass man auch an Systeme kommt, die entkoppelt sind.
Und wenn jetzt wir an das Fernblasbeispiel denken, ich kenne jetzt nicht den Impact für Birdwatcher, wenn ich das Ding hacke.
Auf der anderen Seite hast du, Roland, gerade bestätigt, okay, das...
Ding ist vielleicht auch oft online und dann braucht nur irgendwo eine fehlende IP-Tables-Regel, um das Ding offen zu setzen.
Ich meine, dafür gibt es Shodan.
Shodan, da gehst du ja hin und findest irgendwelche Ölfelder in Texas, die online sind.
Also definitiv, Systeme, die online sind, brauchen Updatebarkeit.
Also ich denke, da muss man ganz klar sagen, ist auf jeden Fall so.
Systeme, die online sind, haben allerdings auch einen IP-Stack, was so ein komplexes Stück Software ist und sowas wie ein Ethernet-Fi.
Hier hat man auch Stützstellen, wo man nach außen kann, um zu kommunizieren.
Und hier zu sagen, Update-Barkeit ist nicht gegeben.
Also da gilt es nicht.
Die Systeme sind auch von den Mikroprozessoren groß genug.
Die haben leicht ein Acer-externer Speicher anschließbar.
Da ist das sicher überhaupt kein Thema.
Für viele andere Sachen, die rein offline sind, Mikrocontroller, die halt jetzt auch irgendeine Stücksoftware haben, warum auch immer, da ist es vielleicht nicht.
nicht einfach und nicht gegeben und auch nicht möglich.
Also ich denke auch, es werden auch gewisse Produkte einfach vom Markt verschwinden, weil das zum Beispiel ein Thema ist, diese Update-Barkeit, wo die Hersteller sagen, na, es rendiert sich dann immer.
Es gibt den Business Case nicht mehr.
Roland, vielen lieben Dank, dass du mir mal einen Einblick in eine Welt gegeben hast, die ich, wo ich jetzt entschieden habe, meiden werde wahrscheinlich.
Du hast mir natürlich jetzt die Komplexität gegeben, wie sehr ich eigentlich meine Waschmaschine updaten könnte.
Jetzt weiß ich gar nicht, ob ich das überhaupt möchte.
Falls es immer noch Leute da draußen gibt, die nach dieser Podcast-Episode noch nicht abgeschreckt wurden, was würdest du den Leuten mitgeben, wie sie als erfahrene SoftwareentwicklerInnen, ich sag mal, einen Fuß in die Tür kriegen?
Also was kann man als Privatmensch machen, ohne so eine Messspitze für einen vierstelligen Betrag zu kaufen?
Welche Hardware ist günstig zu erwerben, wo ich mal dann ein C4-Betriebssystem draufpacken kann?
Also wie ist so...
Der Poor-Mans-Einstieg, würde ich mal sagen.
Kann man Poor-Mans-Einstieg in inklusiver Sprache überhaupt noch sagen?
Poor-Humans-Einstieg.
Poor-Humans-Einstieg.
Also die Arduino und Raspberry-Ebene ist jetzt persönlich für mich, die kommt mehr von der Software her.
Wenn man ein bisschen von der Artwecke reingehen möchte, dann von STMicro, das ist der europäische Hersteller.
Die STM32 Evolution Boards, die kann man sich eigentlich...
Damit kann man sich einen Einstieg verschaffen.
Die sind auch ähnlich einfach zu bedienen wie Arduino.
Man kann die über USB an seinen PC anstecken.
Man bekommt vom Hersteller kostenfrei eine Entwicklungsumgebung, wo auch sehr viel über App-Pakete, Shop, Click, Heap und die zusammengesteckt werden kann.
Man bekommt ein paar Samples.
Sie haben Leuchtonen drauf und blinken schon.
Damit kann man schon einen Fuß in die Richtung kriegen.
Hier hat man jetzt die Hardware halt nicht selbst gemacht, allerdings ist sie schon sehr, sehr hardwareig, sehr embedded vom gesamten Workflow.
Für gewisse Funktionen muss man auch einen Lötkolben in die Hand nehmen, mal einen Widerstand dort setzen oder mal einen Widerstand dort auslöten.
Aber da kann man dann schon sehr viel machen mit diesen Boards in Richtung eigenen Produkten.
Die kommen mit einem Debugger integriert auf der Leiterkarte.
Und diesen Teil mit dem Debugern ist so gestaltet, dass man ihn dann abbrechen kann, wenn man so ein Produkt bauen möchte.
Das heißt, da bricht man dann einen Teil von der Platine ab und ist die Debug-Schnittstelle weg und man hat da tatsächlich ein Abandonnungssystem auf einer Hardware-Größenordnung.
Also da kann man sicher sehr gut erste Schritte machen.
Für alle gilt wie immer, wer wirklich einsteigen möchte, wir haben natürlich ebliche Links in den Show Notes verlinkt.
Roland, vielen lieben Dank.
Ich wünsche dir noch viel Erfolg mit der Erstellung von Birdwatch Software und Hardware für Ferngläser.
Es ist ja schade, dass ihr da, die alle jetzt im Podcast hören, nicht das Gesicht von Andi seht, aber es ist so, es ist wirklich...
Andi sagt ja sonst gerne am Wochenende, probiere ich das aus, aber es ist selten ein Thema, wo ich sage, es ist einfach no way, es ist so weit weg von meiner Cloud-Welt.
Bitte nicht.
Es hat nichts mit Cloud-Welt zu tun, sondern ich bin so froh über alle modernen Techniken, die wir haben, denn ich komme auch noch aus einer Zeit, wo man schön Print-F-Debugging gemacht hat, sich durch den ganzen Flow geklickt hat.
Und wenn ich jetzt dran denke, hier noch eine Platine zu haben.
Ja, Print F ist ja fast die einfache Variante.
Also das ist ja nochmal eine Stufe tiefer.
Ja, und jetzt hier Oszilloskopen-Debugging zu machen und Pipapo, tut mir leid, aber es gibt Masoristen, ich bin keiner.
Also ich wirklich freue mich über moderne Techniken, weil sie machen ja mein Leben einfacher.
Ich will ja Sachen schaffen.
Ich will mir nicht dauerhaft ins Knie schießen.
Und ich bewundere Leute, die das können.
Ich bin keiner.
Und es ist auch okay, wenn ich es nicht können möchte.
Aber es ist mal sehr, sehr interessant, mal einen Einblick darin zu bekommen.
Denn ich denke, nicht nur die Open-Source-Welt, sondern die Informatik ist einfach unglaublich groß.
Ich habe mir gerade mal ein bisschen Free RTOS und C4 auf der Webseite rumgescrollt.
Das ist wieder so ein Bereich.
Es ist ja immer wieder, ich denke, ich habe ein bisschen Ahnung, was so abgeht.
Nee.
Wir leben alle in unseren eigenen Bubbles.
Das ist ganz faszinierend.
Ich mache irgendwas mit Computern.
Früher wollte ich den Leuten erklären, was sie genau tun.
Ich habe das einfach gelassen.
Ich mache irgendwas mit Computern.
Du sagst jetzt, du machst zwei Gläser, oder?
Genau, jetzt sage ich.
Also ich mache nur die Hardware.
Mit Software kenne ich mich gar nicht aus.
Also dieser Podcast hat mir wieder gezeigt, ich bin so fern und so weit von diesem Feld.
Ich weiß, was abgeht.
Oder ich kann irgendwo so ein bisschen mitreden.
Nee, kann ich nicht.
Also ich möchte auch vielleicht dazu sagen, es tut gar nicht so viel weh, wie du das jetzt hier vermutest.
Ich habe auch klassische Softwareentwicklungen gemacht und es sind ganz ähnliche Schmerzen.
Also wenn du die reinen Software-Schmerzen aushaltest, sind diese Hardware-Schmerzen auch aushaltbar.
Eines, was an Hardware-Entwicklung sehr spannend ist, ist irgendwann, und das ist das, was mir an reiner Software-Entwicklung immer gefehlt hat, irgendwann ist es so weit, dass man sagt, es ist Produkt-worthy.
Ich fertig das jetzt und ich stecke das in den Karton und verschicke es.
Und das ist so ein Abschluss von diesem Ganzen.
Es ist dann wirklich fertig.
Es ist gut genug.
Es ist ein Produkt.
Es geht jetzt raus.
Also da möchte ich nur noch mal sagen, ich habe zufälligerweise gestern noch mal mit André Friesen gesprochen.
André Friesen, zur Erinnerung, war die Person, mit der wir die Episode 258 gemacht haben zum Thema Hardware-Side-Project mit ESB Home.
Er hat ebenfalls eine größere Stückzahl bestellt.
irgendwo im Osten, auf jeden Fall in China oder so.
Und die haben irgendwie die falsche Antenne mitgeliefert oder die haben auf jeden Fall irgendwas bei dem Versand verfuckt.
Und jetzt musst du ja wieder zweieinhalb Monate oder so warten, bis die ganze Klamotte da irgendwie kommt.
Also so eine super lange Zeit.
So einfach wie du das gerade erzählst, scheint es dann doch nicht zu sein, dass man einfach diesen tollen Produktabschluss hat.
Ich kann mir aber vorstellen, wenn du eine fertige Platine in der Hand hast, wo die LED leuchtet, dass man dann nackig durch die Wohnung rennt.
Also das kann ich mir schon vorstellen.
Roland, wirklich vielen lieben Dank für alle anderen.
Falls ihr Feedback habt für diese Episode auch an Roland oder falls ihr mehr wissen wollt, schreibt uns gerne.
Wir verbinden da gerne die jeweiligen Leute miteinander.
Ansonsten sage ich Dankeschön und bis zur nächsten Episode.
Bye bye.
Tschüss.
Ciao.