Announcement: there is an English version of this forum on Ich hoffe dies ist der richtige Ort für meine Frage... <<<<Hintergrund>>>> Unser Team entwickelt seit einigen Jahren Embedded-Software in Embedded C++ welche wir (bare-metal) auf ATxMega MCUs deployen. Die Applikation basiert auf selbst-definierten Modulen. Die Module können sich untereinander Nachrichten (Datenobjekte) schicken und haben jeweils einen Task. Für das Message Passing und (kooperatives) Scheduling haben wir proprietären Code geschrieben. Die Verbindung zwischen Modulen wird über Listen definiert. Die Module erfüllen diverse Aufgaben und können sich dafür auch andere Teile der Software nutzen. An sich funktioniert das System gut. Die Anforderungen haben sich jedoch geändert, so dass wir es in Betracht ziehen unser eigenes Framework zu verändern oder gegen ein bestehendes auszutauschen. Die Anzahl an Modulen und Verbindungen ist gewachsen und damit sind die Listen zur Definition der Verbindungen unübersichtlich. Besser wäre es ein Tool zu haben in dem man die Verbindungen grafisch definieren und prüfen könnte. Wir möchten den Code auf andere MCUs (z.B: Cortex-M) deployen und müssen dafür Teile unseres Codes überarbeiten um ihn konform zum C++ Sprach-Standard zu machen. Embedded C++ wird als Randbedingung aufgegeben. Es wäre auch denkbar ein RTOS "von der Stange" zu nutzen. Z.B: FreeRTOS. Aufgrund der geänderten Anforderungen wollen wir uns umschauen, welche Lösungen es bereits gibt, welche wir mittelfristig einsetzen könnten. Uns ist bewusst, dass eine Umstellung mit Aufwand verbunden ist. <<<</Hintergrund>>>> **Was gibt es für GUI Tools um Nachrichtenaustausch zwischen RTOS Tasks zu definieren?** Das Tool würde auf dem Entwicklungs-PC laufen. - Potentiell in Kombination mit einem Framework (inkl. Scheduler?) für die MCUs - generierter Quellcode (nicht Listen oder Konfiguration) müsste in C oder C++ sein - Speicherbedarf ist limitiert (<<10k RAM) Ich tu mir bei der Recherche schwer. Vielleicht suche ich nicht mit den richtigen Stichwörter? Deswegen habe ich hier im Forum nichts passendes gefunden.
Klingt für mich nach BizTalk und BPMN. Ich kann mir nicht vorstellen, wie so etwas (selbst in rudimentärer Form) auf einem Mikrocontroller mit so wenig RAM laufen soll.
Für Euer bisheriges System wird es nichts geben, dazu ist es wohl zu speziell. Schaut Euch mal das hier an - vielleicht geht das in die richtige Richtung: https://www.sparxsystems.de/ fchk
Das einzige Tool, was ich kenne, das ein bisschen in die Richtung geht, ist Rhapsody: https://nohau.eu/products/rational-rhapsody/ https://www.ibm.com/products/systems-design-rhapsody Kenne ich aber auch nur, weil wir Kunden haben, die das mit SEGGER RTOS embOS einsetzen. Ansonsten bieten wir auch Schulungen an, in denen der Umstieg von Bare Metal auf RTOS thematisiert wird. https://wiki.segger.com/embOS_training
David H. schrieb: > Listen zur Definition der Verbindungen unübersichtlich. Was soll das (genau) sein? Was steht in diesen Listen?
Vielen Dank für die bisherigen Antworten. Unsere embedded Software bildet Prozesse bestehend aus Tasks verschiedener Module ab. Tasks sind Funktionen, ähnlich wie bei FreeRTOS. Ein Modul hat einen Task, jedes Modul hat Ein- und Ausgänge welche miteinander verbunden werden können. Alle Module sind Teil einer Software. Bruno V. schrieb: > David H. schrieb: >> Listen zur Definition der Verbindungen unübersichtlich. > > Was soll das (genau) sein? Was steht in diesen Listen? In den Listen sind die Verbindungen für Nachrichten/Events definiert. Heißt die Quelle und Senke wird identifiziert, jeweils mit Modul-ID und ID des Aus- und Eingangs. Daraus wird aktuell Quellcode generiert welcher von unserem Message-Passing System verwendet wird um die Verbindungen zu implementieren. Die Listen schreiben wir aktuell händisch in einem JSON-Format. Bei vielen Verbindungen wird das unübersichtlich. Monk schrieb: > BizTalk und BPMN BizTalk scheint für deutlich höhere Systemebene ausgelegt zu sein. BPMN ist ja erst mal nur eine Notation. Frank K. schrieb: > Schaut Euch mal das hier an - vielleicht geht das in die richtige > Richtung: > https://www.sparxsystems.de/ Enterprise Architect ist schon eher die richtige Abstraktionsebene. Allerdings ist mir nicht bekannt, dass EA selber ein Message Passing Framework mitbringt. Wir müssten also die modellierten Verbindungen noch irgendwie in Quellcode wandeln. Til S. schrieb: > https://www.ibm.com/products/systems-design-rhapsody Mit Engineering Systems Design Rhapsody (- Developer) habe ich noch keine Erfahrung. Auf dem ersten Blick scheint es ein vollwertiges Engineering Lifecycle Management Tool zu sein. Und obwohl es sehr mächtig ist, scheint es die Kern-Komponente für unser vorhaben - das Message-Passing - nicht von Haus aus zu unterstützen. --- Eine Überlegung, welche wir haben ist ein generisches graphisches Tool/Library für Netzlisten zu nutzen und daraus unsere Verbindungslisten (aktuell JSON) zu generieren. Idealerweise auch in entgegengesetzter Richtung. Diesen Generator müsste man aber erst schreiben. Da ich diese Anwendung gar nicht so speziell finde, dachte ich, es könnte bereits öffentliche/kommerzielle Lösungen geben, welche wir einsetzen könnten. Insbesondere, da wir das bestehende Framework sowieso anpassen müssen.
David H. schrieb: > Da ich diese Anwendung gar nicht so speziell finde Prinzipiell ist die Anwendung nicht speziell, aber durch die konkrete Ausprägung entsprechend eurer Bedürfnisse wird sie sehr speziell. Es gibt in dem Umfeld nur wenige universelle Lösungen (keine der mir bekannten läuft auf Mikrocontrollern)
David H. schrieb: > Die Module können sich > untereinander Nachrichten (Datenobjekte) schicken [...] Die Verbindung zwischen Modulen wird > über Listen definiert. [..] > Verbindungslisten (aktuell JSON) Liest sich wie ein node-red Nachbau auf µC? So grob zumindest? Wäre das ein gangbarer Weg? Einmal Node-Red nehmen, aber nur mit Nodes, die euren Modulen entsprechen. Dann könnte man graphisch alles zusammenstöpseln, und evtl. auch direkt simulieren wenn man sich die Arbeit macht, die Module einmal in Javascript nachzuimplementieren. Export des Flows aus node-red wäre ebenfalls json, zusätzlich zu entwickeln wäre dann ein "Compiler", der aus dem node-red flow eure Json-Verbindungslisten generiert.
AUTOSAR bietet genau das, was ihr sucht. Allerdings ist das so ein Moloch, dass man sich danach seine alten Probleme zurückwünscht.
David H. schrieb: > Eine Überlegung, welche wir haben ist ein generisches graphisches > Tool/Library für Netzlisten zu nutzen und daraus unsere > Verbindungslisten (aktuell JSON) zu generieren. Gibt es, generiert JSON Output, auf PC. Ein Programm zu schreiben das diesen Output in ein JSON compatibile mit eurem Codegenerator macht dürfte nicht schwer sein. Geschrieben ist es in Python, wie es genau heißt müsste ich nachsehen, dafür benötige ich aber einige Tage, sollte es von Interesse sein.
David H. schrieb: > In den Listen sind die Verbindungen für Nachrichten/Events definiert. > Heißt die Quelle und Senke wird identifiziert, jeweils mit Modul-ID und > ID des Aus- und Eingangs. > > Daraus wird aktuell Quellcode generiert welcher von unserem > Message-Passing System verwendet wird um die Verbindungen zu > implementieren. > > Die Listen schreiben wir aktuell händisch in einem JSON-Format. Bei > vielen Verbindungen wird das unübersichtlich. konfiguriert Ihr noch andere Dinge mit JSON + Codegenerator und habt ein entsprechendes Habitat? Manchmal bietet es sich an, die Konfiguration in C/C++ zu belassen, falls die meisten Entwickler C/C++ sprechen.
Leider geht für mich aus der Beschreibung nicht hervor, um welche Domäne sich es hier handelt. Manchmal verrent man sich auch gerne mal und denkt viel zu kompliziert. Im klassischen Maschinenbau würde ich Aufgaben(Digital/ANALOG IO/Gateway etc) auf spezialisierte Module aufteilen. Dann ist die Aufgabe, die diese individuell erfüllen müssen gar nicht mehr so komplex. Als Verbindungsprotokoll wäre hier zb CANOPEN gut geeignet(Je nach Domäne und Anforderungen), welches sich gut konfigurieren lässt(Auch grafisch). Wenn Endwnwender diese Verbindungen frei konfigurieren können, wäre dies wiederrum eine ganz andere Anforderung. Hier war Nodered ja schon eine ganz gute Richtung. Kurzum - ihr wollt euer System neu designen. Vielleicht kannst du hier ja noch ein paar Details zu schreiben.
:
Bearbeitet durch User
Ergänzen möchte ich noch, das ein eigener Sprachinterpreter eine coole Sache ist, wenn Nicht-Software-Entwickler Abläufe integrieren müssen. So kann man quasi logische Abläufe(Anwendung schlussendlich) aus dem Code aussparen, was erheblich weniger Aufwand bedeutet in der Pflege der Software sowie eine gewisse Stabilität garantiert. Würde ich hier einen Interpreter einbauen, wäre ein standard Werkzeug auch mneine erste Wahl. Dann entfällt natürlich auch der Aufwand für die Pflege der erforderlichen Tools. Das Beispiel beziehe ich hier auf Nodered.
Vielleicht sollte man noch mal versuchen zu klären worum es dem Fragesteller eigentlich geht. Diese ominösen Listen sind ja kein Selbstzweck (hoffentlich nicht), sondern die Implemenmtation, der Ausdruck, eines Konzepts. Dieses Konzept müssten wir wissen, nicht die Datenstruktur mit der das Konzept zufällig implementiert wurde. Ich schmeiße mal ein paar Buzzwords zusammen, vielleicht triggert das ein paar Erinnerungen was man da wirklich macht, besonders wenn man die Buzzwords mal googelt: Ich kann mich nicht entscheiden ob das nach einem übermäßig komplizierten Messagebus (MB) klingt oder nach Datenfluss-Programmierung. Zu Messagbus "GUI"s fällt mir eigentlich nichts ein außer dass es vielleicht um ein GUI zur Definition der Messages selber und Message-Filter geht. Das wären dann messagbus-spezifische Tools. Aus dem Stand fällt mit keins ein. Es dürfte nicht so schwer sein sich ein eigenes zu programmieren. Wie immer dürften 8ß% des Aufwandes in die GUI gehen, bei relativ einfacher Logik dahinter. Zu Datenfluss-Programmierung gibt es durchaus eine stattliche Anzahl von GUI-Tools, meist für Domain-Specific-Languages (DSLs). Dabei ist das GUI eng mit der Sprache verbunden. Nicht selten ist es das Einzige, was der Programmierer von der Sprache sieht, weil es für den Programmierer kein direkte Zugriff auf die Runtime bzw. den Compiler, Kern etc. vorgesehen ist. Bekannteste Datenfluss-Programmiersprachen dürfte LabView sein. Daneben gibt es sie auch zur Programmierung von Diskreten Event Simulationen (DES) und wahrscheinlich hunderten andere domain-spezifische Anwendungen. Das sie mit ihrer jeweiligen Sprache eng verbunden sind dürfte es unmöglich machen so ein System direkt für eigenen Anwendungen einzusetzen. Aber, es gibt Open-Source die man sich umstricken könnte. Zum Beispiel NodeRed, JaamSim oder Logisim, die man auseinander nehmen und umstricken könnte. Der Aufwand das jeweile GUI dort auszubauen und ein eigenes Backend , das die ominösen Listen generiert, dranzuflanschen könnte allerdings erheblich sein.
:
Bearbeitet durch User
Hannes J. schrieb: > mal ein paar Buzzwords zusammen, Noch ein Buzzword von mir: Wir haben auch schon mal Protel (Altium) für solche Verbindungen benutzt und die "Listen" aus der Netzliste (bzw. generiertem VHDL-Code) geparst. War gut, doch mittlerweile sprechen alle Beteiligten C (mit entsprechenden Browsern/IDEs)
Εrnst B. schrieb: > Liest sich wie ein node-red Nachbau auf µC? So grob zumindest? Node-Red habe ich mir schon angeschaut. Das würde in die richtige Richtung gehen, wenn es auf der richtigen Systemebene wäre. Also innerhalb eines Mikroprozessors. Und wenig Ressourcen benötigen würde. Walter T. schrieb: > AUTOSAR bietet genau das, was ihr sucht. Ich kenne AUTOSAR nicht, aber ein erster Blick sagt mir, dass es tatsächlich gut abdeckt was wir suchen: Basis-Module, Laufzeitumgebung und Anwendungssicht. > Allerdings ist das so ein Moloch, dass man sich danach seine alten > Probleme zurückwünscht. Heißt es es lohnt sich nicht in die Richtung weiter zu schauen? Chris S. schrieb: > Gibt es, generiert JSON Output, auf PC. Ist es zufällig NodeGraphQt? Wenn nicht, würde mich interessieren, welche Alternative du empfehlen kannst. Bruno V. schrieb: > konfiguriert Ihr noch andere Dinge mit JSON + Codegenerator und habt ein > entsprechendes Habitat? Also der Codegenerator den wir für die Verbindungslisten (JSON) geschrieben haben macht nur das. Wir haben allerdings für ein anderes Feature (Parameter-Listen) einen anderen Generator welcher mit einem anderen Quell-Format arbeitet. Ziel-Format ist immer C++ Quellcode. Es ist halt gewachsen... > Manchmal bietet es sich an, die Konfiguration in > C/C++ zu belassen, falls die meisten Entwickler C/C++ sprechen. JSON ist ja nicht schwer zu lesen. Und tatsächlich ist die Liste in JSON schon deutlich übersichtlicher als wenn diese direkt in C++ geschrieben wäre. Der Generator nimmt einem Boilerplate-Code ab. Joe J. schrieb: > Vielleicht kannst du hier > ja noch ein paar Details zu schreiben. Die MCU-Software ("Firmware") ist Kern-Bestandteil von Steuerungen (HW+SW). Diese Baugruppen oder Geräte steuern verschiedene Anlagen oder Systeme. Die zu steuernden Systeme sind Großgeräte aus verschiedensten Branchen, aber insbesondere Lebensmittelindustrie und Kälte. Die Regelungsalgorithmen sind i.d.R. langsam (z.B. 1Hz Regler-Takt) und einfach. Der große Vorteil der Steuerungen sind diverse Zusatzfunktionen die spezifisch für den jeweiligen Einsatz sind. Die Steuerungen sind spezifisch für den jeweiligen Einsatzzweck, die Firmware ist jedoch modular aufgebaut (ein Modul kann über eine Klasse (C++) realisiert sein), so dass sie in der Serien-Entwicklung schnell angepasst werden kann. Der hohe Grad an Flexibilität ist nicht zur Laufzeit gegeben. Teil der jeweiligen Firmwareentwicklung ist es die Module zusammenzuschalten. D.h. die jeweiligen Ein- und Ausgänge miteinander verbinden. Wie gesagt sind diese Verbindungen aktuell als JSON Datei definiert weil wir dafür leicht einen Generator bauen konnten der den C++ Code dafür generiert. Die Verbindungen sind zu vergleichen mit Messages, welche zwischen Tasks/Threads geschickt werden (vgl FreeRTOS). Die Verbindungen sind zur Compile-Zeit fix. Die Systeme sind aber so komplex (ca. 100 Module), dass man eine graphische Repräsentation braucht um sie verstehen zu können. Diese erstellen wir aktuell indem wir ein anderes Programm dafür missbrauchen. Dessen Ausgabe lässt sich leider nicht nutzen um daraus die Verbindungen abzuleiten. Es ist ein besseres Zeichenprogramm. Das Ergebnis dient nur der Dokumentation und ist nicht maschinell mit der eigentlichen Firmware verknüpft. Hätten wir hier ein besseres Tool, mit dem man Verbindungen zwischen "Modulen" definieren kann, dann wäre uns schon geholfen. Die Verbindungen müssten in einem verwertbaren Zwischenformat (z.B. JSON) oder direkt in Quellcode erstellt werden. Und wenn das Programm für die Verbindungen seine eigene Laufzeitumgebung (für die Firmware) mitbringt dann müsste diese mit den restriktiven Ressourcen zurecht kommen. Und wir ziehen auch in Betracht die Prozessor-Familie zu wechseln. Von ATxMega auf Cortex-M. Genauer ist noch nicht bekannt, aber wir sind Preis-sensitiv unterwegs, daher werden nicht viel mehr als ein paar kB RAM für das Framework zur Verfügung stehen. Messages werden zwischen Modulen/Tasks geschickt welche auf einer MCU laufen. Es ist kein Netzwerk oder mehrere Recheneinheiten involviert. Verbindungen transportieren Messages (wenige Byte) oder Events. Verbindungen bestehen zwischen Ein- und Ausgängen von Modulen. An einem Ausgang können mehrere Verbindungen, an einem Eingang nur eine Verbindung verbunden sein. Hannes J. schrieb: > Bekannteste Datenfluss-Programmiersprachen dürfte LabView sein. Ja, das was wir machen, würde in etwa wie eine sehr stark vereinfachte Version von LabVIEW aussehen. Vielleicht muss ich mir das, in Kombination mit dem LabVIEW C Generator mal genauer anschauen. Die Frage wäre insbesondere wie viel Ressourcen die Laufzeitumgebung auf dem Mikrocontroller benötigen würde. Und MATLAB Simulink hat auch einen Generator für C Code. > Aber, es gibt Open-Source die man sich umstricken könnte. > Der Aufwand das jeweile GUI dort auszubauen und ein eigenes > Backend , das die ominösen Listen generiert, dranzuflanschen könnte > allerdings erheblich sein. Oder alternativ ein Ausgabeformat von diesen Tools zu nutzen welches man sinnvoll parsen kann. Ausbauen wäre nicht unbendingt notwendig. Eine solche Zweckentfremdung kann funktionieren. Ob ein solches System langfristig in der Zweckentfremdung nutzbar ist, ist fraglich. Die Wahrscheinlichkeit, dass ein Update des zweckentfremdeten Tools die Kompatibilität bricht ist höher als würde man ein dediziertes Tools für die Graphen-Programmierung nutzen. Vielen Dank für die Antworten und Anregungen so weit!
David H. schrieb: > Messages werden zwischen Modulen/Tasks geschickt welche auf einer MCU > laufen. Es ist kein Netzwerk oder mehrere Recheneinheiten involviert. > Verbindungen transportieren Messages (wenige Byte) oder Events. > Verbindungen bestehen zwischen Ein- und Ausgängen von Modulen. An einem > Ausgang können mehrere Verbindungen, an einem Eingang nur eine > Verbindung verbunden sein. Ich kreiere mal ein Szenario, was Du vielleicht meinst: Es gibt 100 verschiedene Module M (M1..M100) von denen m auf einem (konfigurierten) µC laufen. Es gibt 100 verschiedene Nachrichten N (N1..N100), von denen jedes Modul M eine Anzahl senden und eine andere Anzahl empfangen kann. Beispiel: Modul M1 kann N1, N7, N23 und N66 senden und N9, N55 und N83 empfangen. Die "Liste" enthält jetzt die verwendeten Module (z.B. M1, M5, M7, M88) und deren Verbindungen, hier mit N1 von M1 an alle anderen (z.B. M1:N1-->M5;M7;M88, M5:N9-->M1; ...) Sowas wäre eine "Netzliste" und ein Schaltplanprogramm eine mögliche Repräsentation. Das Symbol jedes Moduls orientiert sich an seiner Funktion, die möglichen Nachrichtigen sind "Pins" mit Eingang-Ausgang-Charakteristik, die Verknüpfungen können per Wire, Port oder Netzlabel erfolgen. Und der generierte C-Code bindet die verwendeten Module und Nachrichten-Aufrufe zu einem Projekt, das kompiliert und als SW für Gerät X bereitgestellt wird Vielleicht magst Du das Bild entsprechend korrigieren. (Bei uns würde das in C konfiguriert und per "Compilerscript" in Tabellenform ausgegeben werden, z.B. eine Spalte pro Modul und eine Zeile pro Modul:Nachricht mit einem X in jeder Spalte die diese Nachricht empfängt. Warum: Weil C/C++ viele Möglichkeiten bietet, bestimmte Abhängigkeiten auszudrücken, die graphische Repräsentationen meist nicht bieten. z.B. M77:N14-->M19 nur dann, wenn M66 nicht verwendet wird. )
:
Bearbeitet durch User
In einer gewöhnlichen Diagrammsoftware (z.B. Dia, UMLet, Yed) anlegen und das Dateiformat parsen?
David H. schrieb: > Walter T. schrieb: >> AUTOSAR bietet genau das, was ihr sucht. > > Ich kenne AUTOSAR nicht, aber ein erster Blick sagt mir, dass es > tatsächlich gut abdeckt was wir suchen: Basis-Module, Laufzeitumgebung > und Anwendungssicht. Das kann ich bestätigen. Die größte Stärke von AUTOSAR besteht definitiv darin, auf den ersten Blick nach einer fabelhaft guten Idee auszusehen.
Walter T. schrieb: > Die größte Stärke von AUTOSAR besteht definitiv darin Kommt man da überhaupt dran als gewöhnliche Firma die nicht im exklusiven Automotive-Club ist?
Meines Wissens nach ist das alles normal käuflich. Ich wüßte nur keinen Grund, warum man nicht das antun wollte, wenn man nicht dazu gezwungen ist.
Bruno V. schrieb: > Vielleicht magst Du das Bild entsprechend korrigieren. Du triffst den Nagel auf den Kopf! Das Projekt ist nicht auf die Module beschränkt. Es hat auch die Möglichkeiten auf Quellcode außerhalb der Modul-Welt zuzugreifen. Aber das spielt - denke ich - für diese Fragestellung keine Rolle. Die Darstellung rein in textueller Form wird schnell unübersichtlich. Eine tabellarische Form ist schon besser. Aber einer graphischen Darstellung immernoch weit unterlegen. Joe J. schrieb: > Ergänzen möchte ich noch, das ein eigener Sprachinterpreter eine coole > Sache ist, wenn Nicht-Software-Entwickler Abläufe integrieren müssen. Das ist auch eine Idee: Das Entwickler, welche sich nicht im Detail mit der Software auskennen (Teile der) Anwendung über eine GUI selber definieren können.
Niklas G. schrieb: > In einer gewöhnlichen Diagrammsoftware (z.B. Dia, UMLet, Yed) anlegen > und das Dateiformat parsen? Grundsätzlich ja. Ich schau mir mal deren Ausgabe-Formate an. 👀 Aber auch hier handelt es sich um Zweckentfremdung. Kann also sein, dass diese Tools bei einem Update ihr Format anpassen (ist ja aus deren Sicht "intern"). Und dass dann unser Parser nicht mehr funktioniert.
David H. schrieb: > Das ist auch eine Idee: Das Entwickler, welche sich nicht im Detail mit > der Software auskennen (Teile der) Anwendung über eine GUI selber > definieren können. Meiner Erfahrung nach können sie es nicht. Den Aufwand treibt man erst ab einer gewissen Komplexität, wo die nicht-programmierer überfordert sind. Die Programmiersprache (egal welche) ist dabei selten das Problem, sondern die Komplexität der Geschäftslogik. Manager brauchen Programmierer, um unvollständig formulierte Anforderungen technisch umzusetzen. Dabei ist eine GUI nicht hilfreich. Grafische Darstellungen können aber hilfreich sein, Abläufe verständlich darzustellen. Dabei lässt man oft Details aus, zeigt nur die einfachen geradeaus Fälle.
Schaut euch mal das hier an: https://github.com/nlohmann/json Das ist eine C++ Lib die Json Objekte auf C++ Objekte mapped. Ob das mit eurem embedded C++ Compiler funktioniert, keine Ahnung... Aber für einen Code Generator zu schreiben wäre es ein Ansatz. Auf der untersten Ebene ist ein SAX-Parser für Json.
:
Bearbeitet durch User
David H. schrieb: > Aber einer graphischen Darstellung immernoch weit unterlegen. Manche verdrängen die Nachteile der graphischen Programmierung: * Änderungsverfolgung (VCS) * Kopieren von Blöcken * statische Analyse * meist keine bedingten Blöcke * manchmal nicht scriptbar * (manchmal nicht standardisiert) * manchmal schwer zu patchen (Bsp: Bei allen 100 Konfigurationen muss XY hinzugefügt werden, wenn Z vorhanden ist) * oft abhängig von einem bestimmten Tool Einige Punkte fallen nicht auf, weil das Derivat (z.B. die Liste) in Textform eingecheckt oder verglichen wird. Da macht man sich was vor.
Ich hatte einfach mal nach MPI und RTOS gesucht. Darauf hat die Suchmaschine sowas ausgespuckt: (u.a.) https://people.mpi-sws.org/~bbb/events/ospert15/pdf/ospert15-p7.pdf https://ieeexplore.ieee.org/document/656130 https://opus.bibliothek.uni-augsburg.de/opus4/frontdoor/index/index/docId/92905 https://www.dcs.ed.ac.uk/home/trollius/www.osc.edu/Lam/lam/xmpi.html https://www4.cs.fau.de/Publications/2014/klaus_14_ospert.pdf
https://github.com/phoddie/node-red-mcu aber mir ist deine Beschreibung ehrlich gesagt zu abstrakt. Irgendwelche Module können irgendwas hin und her schicken und irgendwie verstöpselt werden und irgendwie noch anderen Code einbinden. Klingt irgendwie nicht so danach, als ob die Frage ist, ob du nun FreeRTOS einsetzen sollst oder nicht. Gehts dir jetzt um die Verwaltung des ganzen? Aber das generische Tools(was auch immer das nun in dem Fall machen soll) nun super Speichersparsam sind und unbedingt mit 10k(was heute nun nicht mehr viel ist) auskommen ist auch schon fraglich Aber wie gesagt...ich finde die Fragestellung viel zu nebulös, was sich auch schon aus der Art der Antworten ablesen lässt. Vom JSON Parser bis Autosar war nun alles dabei
Auch das Scheduling...wäre ja jetzt eher was, was auf dem Controller abläuft(Taskscheduling). Ich verstehe es jetzt eher so, das es darum geht wie die Module(für mich ist jetzt 1 Modul = 1uC) untereinander kommunizieren. Worüber überhaupt? CAN, RS485, WiFi? Da nimmt man halt irgendein Protokoll was das handelt
A. B. schrieb: > Klingt irgendwie nicht so danach, als ob die Frage ist, ob du nun > FreeRTOS einsetzen sollst oder nicht. (Free)RTOS ist die "Lösung" für ein anderes Problem. A. B. schrieb: > für mich ist jetzt 1 Modul = 1uC Nein: David H. schrieb: > Messages werden zwischen Modulen/Tasks geschickt welche auf einer MCU > laufen. Es ist kein Netzwerk oder mehrere Recheneinheiten involviert.
Hans-Georg L. schrieb: > https://github.com/nlohmann/json Das könnte nur ein Bruchteil der Lösung sein. Bruno V. schrieb: > Manche verdrängen die Nachteile der graphischen Programmierung > ... > Da macht man sich was vor. Das sind gute Punkte. Welche auf unseren Fall mehr oder weniger stark zutreffen. Aber gerade der VCS (vergleichen, mergen, ...) ist ein wunder Punkt. Die Netzliste, welche graphisch definiert wird, wäre ja nur ein Teil der Anwendungsdefinition. Bedingte Ausführung und "skriptbarkeit" können z.T. von Modul-internen Code umgesetzt werden. Aber nicht notwendigerweise vollständig. Das Problem habe ich schon gehabt, z.B. bei bedingten Verbindungen für die verschiedenen Konfigurationen der Anwendung (z.B. zum Testen). Dafür kenne ich keine elegante Lösung, welche die Übersichtlichkeit einer graphischen Darstellung hat. Rbx schrieb: > Ich hatte einfach mal nach MPI und RTOS gesucht. Ich suche eine implementierte Lösung und bin auch bereit für ein Produkt zu bezahlen. Theoretische Betrachtungen und akademische Projekte helfen mir nicht weiter. Ich habe den Thread im Forum aufgemacht um zu fragen ob jemand Erfahrungen mit einem passenden Tool gemacht hat. Und nach Hilfestellungen für die Recherche. Da kamen schon ein paar interessante Stichpunkte. Z.B. - AUTOSAR und die fehlende positive Empfehlung - LabVIEW mit C Generator? - Hinweise zu potentiellen Nachteilen einer graphischen Repräsentation - die Erkenntnis, dass es wahrscheinlich nicht die spezielle Lösung gibt, die wir suchen; oder zumindest ist sie nicht offensichtlich bekannt A. B. schrieb: > ich finde die Fragestellung viel zu nebulös Die Problemstellung ist auch offen. Die Kern-Frage ist mit welchem existierenden Tool wir die Modul-Verbindungen (alle Module auf einem µC, vgl. Messages & Tasks @ FreeRTOS) graphisch definieren können. Daran verknüpft ist, dass damit ein passendes Framework oder Laufzeitumgebung für den µC einhergehen könnte, falls das Tool nur damit kompatibel ist. Das Framework könnte z.B. für das Message Passing und (optional) für Scheduling verantwortlich sein. Voraussetzung ist, dass das Framework nicht zu viel Speicher frisst. Ansonsten würden wir die Ausgabe des Tools nutzen um Code zu generieren, welches mit unserem eigenen Framework kompatibel ist. Meine Formulierung der Fragestellung ist sicher nicht optimal. Die technische Ausgangssituation wurde im Beitrag "Re: GUI Tool (+Framework) zur Verbindung von RTOS Tasks" gut alternativ beschrieben.
David H. schrieb: > Dafür kenne ich keine elegante Lösung, > welche die Übersichtlichkeit einer graphischen Darstellung hat. Es ist ganz einfach: Du brauchst (immer) eine möglichst problembezogen-ausdrucksstarke Sprache (im weitesten Sinne, kann auch UML oder Labview sein) um die Aufgabe nativ zu realisieren und zu warten. Und danach Tools, um alternative Repräsentationen zu erzeugen. Beispiel embedded: Meist ist C/C++ die verwendete Sprache. Die Tools sind Compiler, IDE, Übersetzer nach Nassi-Shneydermann, Doxygen, ... Für manche Teile ist Simulink/Stateflow die Sprache und der C-Code nur abgeleitet. Das ist OK. Oder Parser generieren Code aus Listen. Dann muss dieses Listenformat ausdrucksstark sein. Das ist auch OK. Was regelmäßig nicht funktioniert, ist mit z.B. UML-Tools die "Architektur" festzulegen und dann die erzeugten Stubs manuell anzupassen. Wenn Textformate ausdrucksstärker sind, dann suche/baue Dir einen Parser, der das nach XY übersetzt und ein Tool, dass daraus Deine Grafik oder Linkliste zaubert. Unter Umständen brauchst Du dafür Annotationen im Textformat. Das ist OK. Siehe z.B. Doxygen (vielleicht kannst Du dessen Fähigkeit schon missbrauchen). Die Ausdruckskraft von Grafik wurde in den letzten 50 Jahren massiv überschätzt. Was auf eine Seite passt, OK. Was ausgedruckt werden soll für fachfremde, OK. Aber die Vorstellung 100.000 Zeilen Code in UML oder Stateflow abzubilden und zu debuggen, ist meist vergeblich. Schaltpläne werden grafisch programmiert. Ja. Aber auch nur, weil HW i.d.R. einfach ist. Das sage nicht ich, sondern z.B. die Norm über Functional Safety (61508) (BTW.: riesige Schaltpläne, z.B. mehrere BGAS mit 500 Pins, werden oft auch nicht grafisch erzeugt, sondern direkt die Netzliste erstellt und gewartet) Ich habe auch kein Problem damit, für ein konkretes Beispiel eine Text-Representation zum Vergleich zu erstellen. Hier kamen alle paar Jahre Glücksritter mit dem ultimativen Ansatz. Der ab 3 Seiten A4 in lesbarer Größe einer Textform mit IDE unterlegen war.
:
Bearbeitet durch User
Bruno V. schrieb: > Schaltpläne werden grafisch programmiert. Nur teilweise. Im Schaltplan stehen noch lange nicht alle Infos drin, um daraus eine Platine zu produzieren, geschweige denn das ganze Gerät. An der Stelle Endet schon der Komfort der grafischen Bearbeitung.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.