Softwarequalität von Heinrichs Weikamp Computern

[caligula2000]

Hallo,

ich habe ein Thread zum Thema Softwarequalität von TC im taucher.net forum gestartet.

https://taucher.net/forum-softwarequali ... n-ioz85986

Auf Empfehlung mehrer User dort poste ich daher nun mal in das Forum des Herstellers. Vermutlich gibt es hier mehr User, die Interesse an der Technik v. TC haben und Interesse an einer Diskussion darüber.

Beste Grüße an Alle
Frank

[Ralph]

Hallo Frank,
Hallo an alle die dem Link hierher gefolgt sind,

es ist auf taucher.net ja schon einiges geschrieben worden. Vermutlich ist die Schnittmenge aus OSTC-interessierten Tauchern und Software-Freaks eher klein und die wenigsten haben sich sicher bisher den Code angesehen geschweige denn die Zeit investiert die notwendig ist ihn zu verstehen. Am Anfang meines Interesses am Code habe ich persönlich tatsächlich erst einmal gar nichts verstanden. Aber mit der Zeit liest man sich ein und erkennt die Zusammenhänge, lernt die PIC-Microcontroller Assemblersprache, versteht die Speicherorganisation usw. Daraus hier ein paar "Background-Infos" zum hwos-Code:

- Der Hauptcode (Benutzer-Interaktion, Ablaufsteuerung, Display-Steuerung, auslesen der Sensoren, ...) ist in Maschinensprache geschrieben, die gesamten Gewebe- und Deko-Berechnungen sind in C geschrieben.

- Vom gesamten Assembler-Code ist nur ein sehr kleiner Teil "kritisch" in dem Sinne, dass wenn hier Programmierfehler enthalten sind tatsächlich falsche Tauchgangsdaten berechnet würden. Der Löwenanteil des Codes ist beim Tauchen (im Dive-Modus) gar nicht aktiv, wie z.B. die großen Codeblöcke die das Logbuch realisieren, die Settings-Verwaltung, USB/Bluetooth-Kommunikation, und einiges mehr.

- Es gibt tatsächlich kein Betriebssystem im Sinne einer 3rd-Party Sammlung von Systemfunktionen auf dem der HWOS-Code aufbaut (a la VxWorks & Co.). In gewisser Weise braucht der OSTC ein solches aber auch nicht, denn der OSTC ist weder ein Multi-Tasking System, noch wird dynamisch Speicher allokiert, usw. Stattdessen sind alle Variablen statisch angelegt und der gesamte Code läuft stetig in einer großen Schleife um. Es gibt aber sehr wohl eine Struktur im Code und ein System in welchen Dateien der Code für welche Aufgaben liegt. Dabei ist aller Code OSTC-spezifisch und einsehbar, mithin also bekannt und nachvollziehbar, entgegen z.B. kommerziellen (Echtzeit-)Betriebssystemen bei denen man nicht den Code einsehen kann und daher auch nicht im Detail weiß was der Code macht.

- Auf den OSTC2-Rechnern kommt man nicht umhin den Großteil des Codes in Assembler zu schreiben, da die Ressourcen Rechenleistung und Speicherplatz begrenzt sind. Dass die OSTCs ziemlich lange mit einer Akkuladung laufen hat auch seinen Grund in der geschickten Assembler-Programmierung. Nicht zuletzt weiß man beim Programmieren in Assembler absolut exakt was jeder einzelne Befehl bewirkt, was das Testen wie auch das Fehlersuchen und -beheben mitunter auch deutlich erleichtern kann.

- Es gibt "dunklen Code", also Code der auf den OSTCs liegt aber nicht öffentlich gestellt ist. Dieser Code bewerkstelligt im wesentlichen das Downloaden und Installieren neuer Firmware. Im normalen Betrieb wird nichts von diesem Code benutzt. Dieser Code prüft u.a. auf Sport bzw. Tech-Version und erlaubt die Installation der Tech-Version nur auf entsprechend freigeschalteten Computern. Daher ist das Geheimhalten dieses Codes notwendig im Sinne des Geschäftsmodells.

- Der gesamte Code kann so wie er ist mit der Microchip Software "MPLAB" übersetzt werden, Hinweise zur Konfiguration von MPLAB sind im /doc-Verzeichnis abgelegt.

- Zum Testen: im C-Code sind Assert-Statements eingebaut die zum Testen benutzt werden können, ebenso defines die ein Cross-Kompilieren auf eine Testplatform ermöglichen. Der größte Teil des Codes ist bereits viele Jahre alt, d.h. in Betrieb und dadurch unter tatsächlichen Praxisbedingungen erprobt. Alles was von Version zu Version neu ist wird intensiv getestet, zuerst im Simulator-Modus und dann in echten Tauchgängen. Dazu gibt es eine kleine Gruppe von Test-Tauchern die wissen dass der Code noch beta ist und damit umgehen können falls er komische Sachen machen sollte. Bei den Testtauchgängen ist natürlich auch immer ein zweiter OSTC mit einer älteren Release-Version als Referenz dabei. Die Beta-Versionen die im Code-Repository online gestellt werden haben die ersten Testrunden immer schon absolviert.

Dies als Information über die "as-is" Situation der weiteren Diskussion beigestellt.

Viele Grüße,
Ralph

[heinrichsweikamp]

Hallo Frank,

Ich poste mal Deinen Text vom taucher.net hier:

[quote=Frank]
da ich mich für das Tec Tauchen interessiere habe ich mir mal diverse Computer für das Deko Tauchen angesehen. Ich bin Softwareentwickler (seit 35 Jahren) und arbeite seit mehr als 10 Jahren im Automotivebereich (aktuell f. autonomes Fahren -> ADAS) und bin daher mit Functional Safety bestens vertraut. Gerade deswegen habe ich erstmal von Haus aus ein ziemliches Mißtrauen gegen Computer von denen in kritischen Situationen mein Leben abhängig ist. Dazu würde ich in jedem Fall auch einen Deko-Tauchkomputer zählen. Ich find es daher sehr lobenswert das Heinrichs Weikamp Einblick in seinen Source Code gibt. Leider ist so etwas heutzutage nicht selbstverständlich.

Ich habe mir daher mal den Programm-Code näher angeschaut:

https://bitbucket.org/heinrichsweikamp/hwos_code/src

Hier mal eine kurze Einschätzung:

Der überwiegende Teil ist in Assembler geschrieben. Davon gibt es unzählige Source Files. Eine Modularisierung ist nicht Ansatz weise zu erkennen. Im Repo befinden sich keinerlei Unit-Tests. Sicherheitskonzepte (watchdog, Asil, etc.) sind ebenfalls nicht vorhanden. Weiterhin gibt es im Repo keine Scripte, die zeigen, wie die Software gebaut wird. Die Doku ist ebenfalls bis auf Inline nicht vorhanden (Design, Architektur). Außerdem scheint nicht die gesammte SW des Geräts im Repo veröffentlicht zu sein.

Meine Einschätzung:

Ich denke, ich muss nicht viel dazu sagen, dass Assembler auch im embeeded Bereich eigentlich (ausser vielleicht im Bootloader, fehlt übriges auch im Repo), keinerlei Berechtigung mehr hat und vom Sicherheitsaspekt vollkommen inakzeptabel ist und das aus mehreren Gründen: Der Aufwand solch einen Code einem Review zu unterziehen ist gigantisch hoch. Es finden keinerlei Typenchecks, wie bei höheren Sprachen statt, ja es gibt ja ausser Register und Speicherzugriffsbreiten ja auch keine. Assembler wurde auch schon in früheren Zeiten (80er) nur von HW-Entwicklern verwendet, die keine Softwareentwickler Ausbildung haben. Weiterhin ist in den Repos nicht mal ansatzweise zu erkennen welche Art von Qualitätskontrolle erfolgt. State of the Art ist erstmal eine ausführliche Dokumentation (Architektur, Design, Erläuterung der Functional Safety Massnahmen). Weiterhin sind automatisierte Tests auf verschiedenen Levels obligatorisch (Units-Tests, Systemtests). Hierfür sollte es Testsuiten geben.

Nur mal so zum Vergleich. Im Automotive Bereich werden bei Sicherheits-kritischen Anwendungen spezielle Microcontroller eingesetzt, die so z.B. solche Dinge mitbringen, wie Schutz vor Speicherüberschreiber, Redundante Cores etc., Watchdog-Timer, die das Einfrieren bei SW-Fehler verhindern etc.

Hier von einem OS (Operating System zu sprechen -> HWOS) lässt auch erhebliche Zweifel aufkommen, ob die Entwickler überhaupt wissen, was das ist. Ich konnte im Code nichts dergleichen finden. Es gibt nicht mal eine Modularisierung von Laufzeitbibliotheken, Treiber, UI oder User-Functions.

Kurzum der gesammte Code ist lässt an keiner Stelle erkennen, dass die Entwickler über irgendeine Qualifikation (Softwareentwickler-Ausbildung) verfügen.

Trotzdem finde ich es gut, dass die Entwickler trotzdem die Eier haben, so einen Code in ein öffentliches Repo hochzuladen. Die HW kann ich nicht beurteilen. Das Housing, Screen etc. macht auf mich aber einen guten Eindruck. Deswegen möchte ich hier nicht nur kritisieren, sondern den Entwicklern/Geschäftsleitung ein paar Empfehlungen geben, was zu tun wäre, damit man solch einem Gerät sein Leben anvertrauen kann:

Es sollte der gesammte Code veröffentlicht werden wie zB. der Bootloader, build-scripte. Open-Source bedeutet, dass jeder Entwickler in der Lage sein sollte die Software selbst zu bauen und zu flashen. Das ist hier erstmal so nicht möglich.

Der gesammte Code sollte nach C portiert werden. Hierfür sollten Coding-Styles verwendet werden.

Der nächste Schritt wäre dann, mal ein bischen Struktur in die Software zu bringen, um separat Test-bare Module zu bekommen, für die Unittestsuits geschrieben werden müssten. Es wäre dann eine Functional Safty Konzept (Minimum ASIL-B) erforderlich, da ich mal davon ausgehe, dass die derzeitige HW ein höreres Asil-Level, was aber dringend notwendig wäre (da Menschenleben an dem Gerät hängen), derzeit noch nicht zulässt. So ein Konzept löst z.B. so Fragen, was passiert bei Softwarefehler (Speicherüberschreiber, Freezes, Ausfall v. HW wie z.B. Sensoren, Display, Tastern, Selbstdiagnose, Plausibiliesierung, Redundanzen, Systemtests, Buildtoolchain) etc.

Zum UI könnte ich auch noch einiges Schreiben, aber gemessen an dem Gesamtzustand des Programmcodes, spielt das wohl keine grosse Rolle mehr.

Weiterhin sollten Code-Reviews stattfinden.

Ich kann verstehen, das Organisationen wie die GUE davon abrät, überhaupt Computer zu verwenden. Im Übrigen gehe ich davon aus, dass es bei den anderen Herstellern, wahrscheinlich genauso, wenn nicht, noch trostloser aussieht.

Beste Grüße an Alle von Frank
[/quote]

Wenn das nicht einfach nur ein Troll-Posting sein soll, weiß ich gar nicht wo ich anfangen soll zu kommentieren Zumindest behauptest Du gleich mehrere Dinge, die einfach falsch sind und packst natürlich auch gleich die persönliche Keule aus ( "...ob die Entwickler überhaupt wissen, was das ist" ). Natürlich nicht so gut, wenn man "eine halbwegs sachliche Disussion (sic!) bzgl. der heute üblichen Technologie in Tauchcomputern erwartet"...

Aber hier bekommt jeder eine zweite Chance, daher bitte ich Dich diese Diskussion nun zu beginnen.

Ralph hat schon mal recht sachlich vorgelegt.

Gruß,
Matthias (OSTC Software und Hardware-Entwickler)

[dadefay]

Hallo,

This discussion seems fascinating, happy those who understand German!

Viele Grüße

[caligula2000]

Hallo Ralph,

vielen Dank für Deine Erläuterungen. Und danke an Matthias für die "zweite Chance".

Ich denke es ist unstrittig, dass man in einen TC kein RTOS braucht, sondern (so wie Du beschrieben hast) alles in einer Schleife abarbeitet. Die Gründe, die Du dafür anführst sind richtig. Mehr ist nicht erforderlich und das vereinfacht die SW erheblich und ist auch m.M. nach State-of-State in low-Power-Geräten.

Das der Bootloader aus den genannten Gründen nicht veröffentlich ist, hatte ich schon vermutet.

Der Knackpunkt sind für mich die Unmengen von Assembler-Code. Der Aufwand diesen Code zu verstehen dürfte wohl gemessen an der geringen Komplexität der gesammten SW ziemlich hoch sein. Das ist nun mal bei Assembler-Programmen so, weswegen Assembler ja eigentlich auch nur dort verwendet wird wo es unbedingt Sinn macht.
Solcher Code kann nur schwerlich von anderen (z.B. Open Source Community) gereviewt werden.

Du führst hier an "Auf den OSTC2-Rechnern kommt man nicht umhin den Großteil des Codes in Assembler zu schreiben, da die Ressourcen Rechenleistung und Speicherplatz begrenzt sind."

Rechenleistung kann nicht das Problem sein, den das was Rechenleistung kostet ist ja bereits in C geschrieben: " die gesamten Gewebe- und Deko-Berechnungen sind in C geschrieben.". Wie ich dem Microcontroller-Handbuch entnehmen konnte gibt es 128K Programm-Speicher. Wieso kann dann der Rest "Der Hauptcode (Benutzer-Interaktion, Ablaufsteuerung, Display-Steuerung, auslesen der Sensoren, ...)" nicht auch in C geschrieben werden? Die heutigen Compiler (auch f. 8-Bit Microcontroller) optimieren den meisten Overhead ohnehin wieder weg. Das Ganze wird wesentlich übersichtlicher und es gibt doch erstmal prinzipiell weniger zu debuggen (weil weniger Fehler). Der Maschinencode des Compilers sollte im Debugger ebenfalls kein Problem sein, da ja die Zuordnung zur C-Source in vernünftigen Fullscreen-Debuggern angezeigt wird.

Überhaupt sind die Argumente, die hier für Assembler angeführt werden, seit den 80er bekannt und haben schon damals nicht gestimmt. Mir sind GPS-Tracker bekannt, die zu 95% in C programmiert sind und mit 5000mA Batterien rund 7 Jahre (24h an Tag) laufen während laufend Sensor-Daten auslesen und dabei noch zyklische Kommunikation über GSM abwickeln.

Die Unterteilung von kritischen und unkritischen Code ist schon richtig, aber wenn man keinen Speicherschutz (MMU) hat kann erstmal jeder Opcode theoretisch überall hinschreiben kann. Insofern sollte dann schon alles tiptop programmiert sein.

"Es gibt aber sehr wohl eine Struktur im Code und ein System in welchen Dateien der Code für welche Aufgaben liegt."

Das mag schon sein, jedoch ist eine Struktur normalerweise auch klar erkennbar und erleichtert das Verstehen des Codes.

Wie Euer Test-Konzept aussieht ist mir noch nicht so ganz klar. Soweit ich das verstanden habe könnt ihr den Code auch für eine lokale Simulation kompilieren, was ja schon mal eine gute Voraussetzung ist. Bloss wie sehen die Tests aus? Gib es Testsuiten, die alle möglichen Usecases automatisch testet? Ich denke hier sind automatisierte Tests mit möglichst hoher und systematischer Testabdeckung gefragt.

Generell finde ich aber die Tatsache, dass ihr Euren Code veröffentlicht erst mal sehr gut. Und vielleicht kann ich Euch ja dazu bewegen den Code ein bisschen zu "modernisieren".


Gruß
Frank

[Ralph]

Hallo Frank,

zunächst eine kleine Erläuterung: ich gehöre nicht direkt zu HeinrichsWeikamp, sondern bin "nur" ein Open-Source Programmierer der sich letztes Jahr einen OSTC cR gekauft hat, dann aus Interesse an der Sache sich in den Code eingearbeitet hat und dann angefangen hat den Code zu überarbeiten und neue Funktionen zu ergänzen, insbesondere für CCR-Tauchgänge. Meinen Code habe ich HeinrichsWeikamp (Matthias) zur Verfügung gestellt und das meiste davon ist im Laufe der letzten Zeit tatsächlich in die offizielle Version eingeflossen. Daher kenne ich mich mittlerweile ziemlich gut aus im Code.

Ich persönlich fühle mich sehr sicher mit dem OSTC / hwos, da ich allen für meine Sicherheit relevanten Code mittlerweile Zeile für Zeile nachvollzogen habe. Und natürlich weiß ich dass sowohl jedes Stück Ausrüstung urplötzlich seinen Geist aufgeben kann, wie auch dass das Bühlmann-Modell eben nur ein Modell ist, welches auch nicht 100% sicher/zuverlässig ist. Eine Sache sollte jedoch betont werden:

-> Es gibt keine bekannten signifikanten Probleme mit dem Code.

Daher ist es nicht notwendig quasi rückwärts nochmal haufenweise Tests zu entwickeln die dann alle ein Pass liefen. So denn die Tests dann überhaupt alle richtig sind... Man darf die Anzahl der Zustände die der OSTC annehmen kann übrigens nicht unterschätzen, ein vollständiges Durchtesten aller Kombinationen wird praktisch kaum realisierbar sein. Daher mache ich für meine Codebeiträge White-Box-Tests, bei denen ich ganz gezielt alle Entscheidungszweige im neuen Codefragment einmal durchfahre.

Zu Assembler versus C-Code: Fakt ist, dass der Assembler-Code läuft. Ihn in C neu zu schreiben würde vermutlich eher neue Fehler eröffnen... Auch ist der "kritische" Code nicht übermäßig komplex. In C würde er vermutlich ziemlich genau so aussehen, nur eben mit anderen Befehlsworten geschrieben und die Codeblock-Sprungbefehl-Gruppen in Klammerstrukturen aufgelöst. Von den 128k Programmspeicher sind übrigens aktuell noch rund 2k frei, d.h. der Speicher ist so ziemlich kurz vor aufgebraucht (ok, man könnte noch die Sprachwahl rauswerfen, dann hätte man nochmal weitere 3,5k frei. Hatte ich schon mal machen müssen bevor ich den C-Teil massiv optimiert hatte um wieder freien Speicher zu gewinnen). Und im RAM sieht es nicht viel anders aus. Kompakter Code ist also schon nötig.

Gestatte mir eine Frage: wie viel Zeit hast du in die Code-Analyse bisher investiert? Ich habe einige Wochen benötigt (Freizeit, abends) um die wesentlichen Teile des Codes zu verstehen. Ich denke unter dem kommt man nicht hin, egal in welcher Sprache es geschrieben ist.

Viele Grüße,
Ralph

PS: "Und vielleicht kann ich Euch ja dazu bewegen den Code ein bisschen zu "modernisieren"." --> Du bist herzliche eingeladen Teil der Open-Source-Gemeinde zu werden und an Code, Tests, etc. mitzuarbeiten!

[caligula2000]

Hallo Ralph,

ich bin Freiberufler und arbeite mich ca. alle 12-24 Monate in größere SW Systeme (20-30k Lines) ein. Weiterhin ist es heutzutage üblich, das alles was in ein Repo geht von anderen Entwickler gecheckt wird (Code-Review). Das Tool hierfür heißt Gerrit. Da wird dann fleißig kommentiert. Der entsprechende Entwickler korrigiert solange, bis alles passt. Die heutige Sicherheits-Kultur ist sehr methodisch. Da gibt es z.B. Standards wie MISRA und die Projekte haben entsprechende Codings-Styles um den Code für möglichst viele lesbar zu machen. Übersichtlicher standardisierter Code ist eigentlich die Basis für alles weitere.

Ich habe mir heute nur einen kurzen Überblick verschafft und exemplarisch mir auch Code im Detail angeschaut.

Mein Bauchgefühl sagt mir, dass das Ganze in C unterhalb von 10k Lines liegen müsste. Wenn so etwas gut geschrieben ist, sollte man innerhalb von wenigen Tagen den Überblick haben.

-> Es gibt keine bekannten signifikanten Probleme mit dem Code.

"Daher ist es nicht notwendig quasi rückwärts nochmal haufenweise Tests zu entwickeln die dann alle ein Pass liefen."

Doch das ist es. Denn die Fehlerfreiheit wird nicht im Feld nachgewiesen, sondern durch umfangreiche Tests. Das ist State-of-the-Art. Dafür gibt es viele Tools und bei sicherheitsrelevanten Anwendungen sollte hier ein nicht unwesentlicher Anteil reingehen. Was meinst Du ist wohl der Grund, warum TC prinzipiell misstraut wird? Weil so eine Aussage, das es keine Probleme gibt, man nur glauben oder nicht glauben kann. State-of-the Art heißt, dass man Standards bzgl. funktionaler Sicherheit entspricht. Und dafür sind festgelegte Maßnahmen notwendig. Alles andere ist Kasperle-Theater.

Vielleicht wäre es ja sinnvoll, die BL Sperre aufzuheben, damit auch professionelle Open Source Entwickler Interesse haben hier mal mit anzupacken. Würde meiner Meinung nach dem Geschäftsmodell gut tun. Der Hersteller hat ja immer noch die Hände auf der HW, die ja nicht schlecht zu sein scheint.

>> Du bist herzliche eingeladen Teil der Open-Source-Gemeinde zu werden und an Code, Tests, etc. mitzuarbeiten!

Ja würde ich auch gerne machen. Aber dafür ist es mir z.Z. noch zu wenig Open Source. Code schreiben, den man selbst auf der HW nicht testen (laufen) lassen kann, finde ich nicht so spannend.

Übrigens was die 128 kb angeht. Vielleicht wäre es besser (überfüssige) Funktionen über Board zu werfen und dafür mehr auf (nachweisbare) Sicherheit und Stabilität zu gehen, anstatt per Assembler alles in EPROM zu quetschen. Ich denke mal, dass das vielen Tauchern eher zusagen würde.

Beste Grüße
Frank

[Ralph]

Ähh, der OSTC Code ist keine sicherheitsrelevante Anwendung und behauptet auch nicht eine solche sein zu wollen. Es mag ja alles richtig sein was du schreibst, aber ich verstehe nicht was deine Intention dabei ist. Wenn dir die OSTC Rechner nicht zusagen, dann ist das eben so - steht jedem frei. Wenn du einen Hersteller findest der Tauchcomputer anbietet die nach einem SIL entwickelt sind und dir das auch nachweisen kann, kaufe so einen wenn das für dich wichtig ist. Wenn du eine SIL-Firmware-Variante für die OSTC2-Plattform entwickeln möchtest - keiner wird dich hindern. Programmierumgebung und Download-Tool gibt es alles for free, ebenso Unterstützung bei ernsthaftem Interesse - kann ich aus eigener Erfahrung sagen. Bin nämlich gerade am Programmieren, Downloaden und Testen...

PS (nochmal): "Kasperle-Theater" - solche Begrifflichkeiten sollte man sich genau überlegen zu benutzen. Wenn das ernst gemeint war (Stichwort zweite Chance), dann habe ich für meinen Teil glaube ich jetzt alles gesagt was mir wichtig war.

[Rob]

Ich finds lustig

Ich hab mir den ganzen Thread durchgelesen und weis nicht ob ich lachen oder weinen soll.

@Ralph - Kasperle trifft es doch ganz gut

Grüße
Rob

... der auch gerade am Entwickeln ist

[Anonymous User]

Ich finde die die Diskussion interessant.
Auch die grundsätzliche Erwartungshaltung an OC Software von caligula2000.

Bei anderen Computer-Herstellern kommt es gar nicht erst zu solchen Diskussionen.
Niemand von extern kennt den Source-Code. Oder die Qualitäts- oder Qualifizierungs-Richtlinien.
Da muss ich noch viel mehr in "vertrauen" in die Kompetenz (oder die Angst vor der Produkthaftung)
des Herstellers haben.

Für mich ist der umfangreiche Einsatz von Assembler auch überraschend, aber nicht unbedingt ein negatives
Qualitätskriterium. Es macht nur die Einarbeitung, Wartung und Fehlersuche meist schwierger.
Im Gegenzug muss man sich nicht auf die Qualität und Feherfreiheit der Compiler der µC Hersteller verlassen.

Es stellt sich mir eher die Frage: Wieso hat HW den Code überhaupt als OC veröffentlicht?

[heinrichsweikamp]

kan2sp Wrote:
> Es stellt sich mir eher die Frage: Wieso hat HW
> den Code überhaupt als OC veröffentlicht?

Wieso nicht? Der Name ist ja schließlich Programm und die Frage hat sich so eigentlich nie gestellt. Wir nutzen hier in der Arbeit und Produktion auch viel Open-Source Software.

Welche Sprachen nutzen denn andere Hersteller?

Die "kleinen" OSTC sind bei uns in ASM+C, der DR5 und der OSTC4 sind komplett in C. Die fehlende Performance bei den Low-level Routinen werden dort durch eine höhere Taktfrequenz kompensiert.

Assembler erfordert Hardwarewissen und Sorgfalt. Fehlende Sorgfalt kann aber auch durch eine andere Sprache nicht kompensiert werden.

"caligula2000" Eingangspost spricht für sich, das muss man nicht groß kommentieren. Um eine "sachliche Diskussion" ging es nicht.

Gruß,
Matthias

[Rob]

Hallo Forum,

Sorry for not writing in English.

ich will das mal nicht so stehen lassen wenn man solche Aussagen präsentiert bekommt,
ich zitiere mal:
-Assembler auch im embeeded Bereich ... keinerlei Berechtigung mehr hat
-vom Sicherheitsaspekt vollkommen inakzeptabel
-Assembler wurde auch schon in früheren Zeiten (80er) nur von HW-Entwicklern verwendet, die keine Softwareentwickler Ausbzildung haben.
-automatisierte Tests auf verschiedenen Levels obligatorisch
-lässt auch erhebliche Zweifel aufkommen, ob die Entwickler überhaupt wissen, was das ist
-Kurzum der gesammte Code ist lässt an keiner Stelle erkennen, dass die Entwickler über irgendeine Qualifikation (Softwareentwickler-Ausbildung) verfügen.
-dass die Entwickler trotzdem die Eier haben, so einen Code in ein öffentliches Repo hochzuladen

Weitere Zitate mit Kommentar von mir:
"damit man solch einem Gerät sein Leben anvertrauen kann "
-> hat auch vom Tauchen wenig bis keine Ahnung.

"Open-Source bedeutet, dass jeder Entwickler in der Lage sein sollte die Software selbst zu bauen und zu flashen. Das ist hier erstmal so nicht möglich. "
-> Der TO hat auch von der OSTC Firmware (Entwicklung) keine Ahnung - denn das gelang mir "Damals" (TM) nach kurzer Einarbeitungszeit (3-4 Tage wobei das Einrichten der Entwicklungsumgebung die längste Zeit in Anspruch nahm). Aber vielleicht liegt es ja auch daran dass der TO kein Entwickler ist.

"Code sollte nach C portiert werden "
-> warum das - Sauber programmierter Assembler ist in vielen Teilen wesentlich effizienter, auch was den Overhead anbelangt und somit auch energieeffizienter. Aber der TO kommt ja aus dem Automotiv bereich und da hat man es ja nicht so mit Energieeffizienz - zumindest nicht mit der Realen.

"ein bischen Struktur in die Software zu bringen "
-> da ist genug Struktur drin die man auch erkennen kann, wenn man kann und auch will. Wenn man nur nörgeln will...

"as aber dringend notwendig wäre (da Menschenleben an dem Gerät hängen) "
-> wie weiter oben schon geschrieben, auch vom Tauchen nicht viel Ahnung.

"Zum UI könnte ich auch noch einiges Schreiben, aber gemessen an dem Gesamtzustand des Programmcodes, spielt das wohl keine grosse Rolle mehr"
- dazu fällt mir nur ein "Was für ein Blender".

Abschließend zum Eingangspost gibt es nur noch zu sagen, viele Buzz Words, die so auch nur von den ganz Großen aus der Business-Kasper-Szene genutzt werden.
Anscheinend muss er hier, richtige "Imprägnieren" und zeigen wesentlich er für ein "toller Hecht" ist.


Kann noch nicht mal sachlich argumentieren ohne andere zu beleidigen, zieht aber den Schwanz ein und läuft davon, sobald er merkt das er etwas Gegenwind bekommt.
Schaut mal ins Taucher.net- da kommt von ihm auch nix mehr - auch wenn, ausser viel heisser Luft, vom ihm auch sonst nicht viel gekommen ist.

Grüße
Robert

[Laurie_the_Knot]

Is anyone here prepared to attempt an English translation of the core of the discussion here for the benefit of those members of the audience not fluent in German? Please, pretty please?

[dadefay]

Hi Laurie,

At the beginning of the discussion, I was interrested me too to understand what it was about. But after I managed to translate some parts from German, I found this is just the opinion of a so called software specialist about the comparative advantage of Assembler and C language in technical computers software.

I'm myself a software engineer, and I don't believe this forum is the right place for such a discussion. Let's talk about diving, please ! And in English, if possible, since this forum is worldwide...

Regards

[swissdiving]

Laurie,

I do agree with dadefay, however if you want a reasonable good translation of a long text (bettern than Google Translate) try https://www.deepl.com