Hallo, Ich würde mich gerne Informieren wie man vorgehen könnte oder wo man sich umschauen könnte. Wir haben derzeit ein Projekt welcher auf uns bekanntem 8bit Mikrokontroller läuft. Grob gesagt er bekommt ein oder mehrere Eingangssignale und anhand von diesen setzt er PWM Ausgänge und leitet verschiedene Infos per CAN weiter. Der Programmcode ist in C geschrieben und wir kümmern uns nur um die Programmlogik. Die "tiefere Schicht" wie das Ausgeben/Einlesen von PINs, eeprom r/w oder das Erzeugen und verschicken der CAN-Nachrichten übernimmt der Hersteller vom Kontroller. Wir sagen quasi nur was auf den PINs ausgegeben werden soll. Der Code ist derzeit an die ca. 7K Zeilen und läuft super auf uns bekanntem Kontroller. Meine Frage wäre: wo könnte ich es nachlesen wie man Code/Projekt in Zukunft so gestalten/vorbereiten könnte, dass dieser als Modul in ein (mir) fremdes System mit so wenig Aufwand wie möglich eingebunden werden könnte? So, dass das fremde System dieses Modul immer wieder zur Laufzeit aufruft? Am besten so, dass dieser Modul nicht einsehbar ist? Natürlich muss man sich auf gewisse Sachen einigen wie ausschließlich "C", diverse Schnittstellen. Zielkontroller ist unbekannt, also ob 8, 16 oder 32Bit ist derzeit nicht klar. Oder hat jemand ein paar Tipps/Erfahrung? Ich würde mich über jeden Tipp/Info freuen! Grüße AK
AK schrieb: > Der Programmcode ist in C geschrieben und wir kümmern uns nur um die > Programmlogik. Die "tiefere Schicht" wie das Ausgeben/Einlesen von PINs, > eeprom r/w oder das Erzeugen und verschicken der CAN-Nachrichten > übernimmt der Hersteller vom Kontroller. Der Hersteller des Controllers übernimmt das eher nicht. Der stellt höchstens ein paar Bibliotheken zur Verfügung. Was ihr sucht ist ein Betriebssystem. Das stellt dann definierte Software Schnittstellen für die darüber liegenden Programme zur Verfügung. Also sucht ein Betriebssystem für eure Controller-Familie und lest euch dort ein.
Thomas F. schrieb: > Der Hersteller des Controllers übernimmt das eher nicht. Der stellt > höchstens ein paar Bibliotheken zur Verfügung. Genau, unser derzeitiger Hersteller stellt uns Bibliotheken zur Verfügung (in die wir nicht Einsehen können) und wir rufen diese auf wenn wir die E/A's Pins schreiben bzw. lesen wollen. Das klappt auch super bis jetzt. Allerdings such ich nach einer Möglichkeit was ich zutun habe, wenn ein dritter unsere Programmlogik nehmen wollen würde. Da würden ja die jetzige Bibliotheken eh fehlen(müsste man Schnittstellen zu anderen Schaffen), Compiler und Kontroller wären unbekannt. Danke für deine Antwort!
Moin, - ich habe ja keine Ahnung davon, aber wenn diese Bibliotheke mit diesem geheimen Compiler so relevant fuer die Firma ist gibt es bestimmt einen Vertrag der den Ausfall des Hersteller regelt (z.B. Uebergabe Entwicklungssystem nach Insolvenz/Tod des Entwicklers). Das ist aber nicht technisch, mehr Vertragsgedoense. Und deutlich ueber Deine Kompetenzen oder Gehaltsklasse (es sei denn: GF) Gruesse Th.
Ihr habt ein System gekauft: µC mit Firmware/HAL/OS, wie immer es nennt, mit einer sogenannten API (Applikations-Programmier-Interface). Nun möchtest Du, dass Euer Modul, das bisher auf dieser API läuft, auf "allen" Plattformen läuft. Da gibt es zwei Möglichkeiten: a) Du implementierst auf "allen" Plattformen diese API (bzw. deren Funktionalität) b) Du baust Dein Modul um, dass es mit gängigen APIs läuft. Je nach Umfang vielleicht Free-RTOS, Arduino oder auch eine SPS. In der Praxis wird es auf eine Mischung hinaus laufen, bei der Du Module des Herstellers in C nachbaust, die dann portabel sind. Dafür müsste aber die API (bzw. deren Funktionsumfang) so ungefähr bekannt sein. Man kann so ziemlich alles modular und portabel in C formulieren, man kann sich dabei aber auch ziemlich doll in den Fuß schießen.
AK schrieb: > Allerdings such ich nach einer Möglichkeit was ich zutun habe, wenn ein > dritter unsere Programmlogik nehmen wollen würde. Dann suchst du evtl. sowas: https://de.wikipedia.org/wiki/Hardwareabstraktionsschicht
Nun ja du redest etwas viel um den heißen Brei herum. Ich dass das mal so zusammen wie ich das verstehe - Ihr habt eine App die eine lib benutzt von der kein Source vorliegt sondern nur die Objektfiles - die App läuft auf eurem geheimen Mikrocontroller. - Ihr wollt einen andern Mikrocontroller verwenden für den Ihr die Lib nicht habt. Soweit richtig? Nun die Lösung ist ziemlich einfach. Lib kaufen oder Lib selber nachprogrammieren. Es wird ja vermutlich eine Doku geben wie die Lib angewendet wird. Die andere Alternative wäre dann noch in Lib reinzuschauen, das wäre aber illegal und hilft nicht bei der Umstellung auf alternative CPUs.
AK schrieb: > Zielkontroller ist unbekannt Dann ist die Sache doch ganz einfach. Ohne die Quellen läßt sich der Code für die neue CPU nicht compilieren, kann also dort auch nicht ausgeführt werden. Aber selbst mit Quellen kann es nötig sein, den Code an die neue CPU anzupassen, insbesondere die Hardwareaufrufe.
Es hört sich an, als ob die Logik von eurem Teil eher übersichtlich ist. Dann vermute ich, wäre es für ein neues Zielsystem vielleicht am einfachsten neu zu schreiben, dabei kann de Logik ja als C-Quelltext aus dem bisherigen System weitgehend übernommen werden. Alles darüber hinaus kommt mir etwas schräg vor. Wenn ihr letztlich Libs nehmt, bekommt deren Hersteller doch euer Programm gar nicht zu sehen; wo ist dannn das Problem? Auf einem anderen System muß man halt die bisher zugelieferten Teile neu machen (lassen), z.B. indem man auf STM32 die HAL verwendet oder auf eine Art OS umsteigt (FreeRTOS?), wie Thomas F. schon schrieb. AK schrieb: > wo könnte ich es nachlesen wie man Code/Projekt in Zukunft so > gestalten/vorbereiten könnte, dass dieser als Modul in ein (mir) fremdes > System mit so wenig Aufwand wie möglich eingebunden werden könnte? So, > dass das fremde System dieses Modul immer wieder zur Laufzeit aufruft? > Am besten so, dass dieser Modul nicht einsehbar ist? Wer sollte das einsehen? Je nach Controller kann man evtl. das Flash gegen auslesen schützen. Vielleicht hilft dir auch eine andere Idee weiter: Man könnte die Logik in einer Art eigener Sprache abbilden und zur Laufzeit mit eine, passenden Interpreter abarbeiten. Dann hat man die Freiheit zu sagen, wo die Logik abgelegt ist - z.B. in einem externen Flash, verschlüsselt, signiert..., und im Controller selbst läuft dann der Interpreter. Ich glaube nicht wirklich, daß es in dem Fall sinnvoll ist. Möglicherweise passt es aber zu deinen Gedankengängen.
AK schrieb: > wo könnte ich es nachlesen wie man Code/Projekt in Zukunft so > gestalten/vorbereiten könnte, dass dieser als Modul in ein (mir) fremdes > System mit so wenig Aufwand wie möglich eingebunden werden könnte? Der ursprüngliche Gedanke von C ist genau dieser. Sonst objektorientierte Hochsprachen Gruß H
AK schrieb: > Am besten so, dass dieser Modul nicht einsehbar ist? Man kann den Quelltext zu einer Lib vorcompilieren. Dann sind alle Kommentare und internen Namen gelöscht. D.h. es ist nur der Maschinencode und die exportierten Namen sichtbar. Natürlich ist so eine Lib nur für eine konkrete CPU, Hardware und Compilerversion verwendbar. Z.B. kann eine Lib für den GCC nicht mit dem IAR zusammen gelinkt werden.
Stellt einen echten/"reinen" Software-Architekten an. Ihr könntet mal aufarbeiten, welche Codeteile - Komplett unabhängig vom Zielcontroller sind - Teilweise abhängig vom Zielcontroller sind (z.B. Bitshifts) - Komplett abhängig vom Zielcontroller sind (evtl. spezielle Berechnungsalgorithmen) Diese Einteilung könnt ihr in jedem Modul vornehmen (z.B. der Logik). Dann die Teile als Module herauslösen und eine ordentliche Interfacespezifikation zwischen den Modulen schreiben. Natürlich gibt es unzählige Design Patterns, die genau solche Probleme lösen. Dazu müsste man aber mehr Details kennen und die bestehende Codebasis analysieren.
AK schrieb: > Allerdings such ich nach einer Möglichkeit was ich zutun habe, wenn ein > dritter unsere Programmlogik nehmen wollen würde. Dich darüber freuen, dass eure Programmlogik interessant genug ist. AK schrieb: > unser derzeitiger Hersteller stellt uns Bibliotheken zur > Verfügung (in die wir nicht Einsehen können) Offenbar hatte euer derzeitiger Hersteller die gleiche dumme Idee wie ihr. Geheimhaltung ist Wissensvernichtung und bringt die Menschheit nicht weiter.
AK schrieb: > unser derzeitiger Hersteller stellt uns Bibliotheken zur > Verfügung (in die wir nicht Einsehen können) Wir hatten auch ein ähnliches Problem. Ich hatte dann immer das Gefühl, auf einem Pulverfaß zu sitzen. Auch war es extrem schwer, Fehler in der Blackbox nachzuweisen und die Behebung dauerte extrem lange und kostete viel Kommunikation (und wohl auch Geld). Die Trennung von dieser Firma und in Haus Entwicklung hat dann die Lage deutlich entspannt. Fremdentwicklung rechnet sich nur für einmalige Projekte mit sehr großen Stückzahlen, d.h. keinerlei Support und Weiterentwicklung notwendig.
Es ist nicht eure "Programmlogik", die vorbereitet werden muss, sondern die neuen Mikrocontroller und ihre Frameworks. Arduino macht vor, wie so etwas geht. Schau dir das folgende Beispiel an. Diese "Programmlogik" liest die Stellung eine Poti von einem analogen Eingang ein und erzeugt dementsprechend ein PWM Signal um eine LED zu dimmen. Außerdem wird der Messwert auf einer seriellen Konsole ausgegeben:
1 | const int analogInPin = A0; |
2 | const int analogOutPin = 9; |
3 | |
4 | int sensorValue = 0; |
5 | int outputValue = 0; |
6 | |
7 | void setup() { |
8 | Serial.begin(9600); |
9 | }
|
10 | |
11 | void loop() { |
12 | sensorValue = analogRead(analogInPin); |
13 | outputValue = map(sensorValue, 0, 1023, 0, 255); |
14 | analogWrite(analogOutPin, outputValue); |
15 | |
16 | Serial.print("sensor = "); |
17 | Serial.print(sensorValue); |
18 | Serial.print("\t output = "); |
19 | Serial.println(outputValue); |
20 | |
21 | delay(2); |
22 | }
|
In dieser "Programmlogik" befindet sich kein einziger hardwarespezifischer Befehl. Deswegen läuft das Programm auf allen Mikrocontrollern, die das Arduino Framework unterstützt. Wenn der Hersteller des neuen Mikrocontrollers kein kompatibles Framework bereit stellt bleibt dir nichts anderes übrig, als es selbst zu entwickeln oder eine Adapter-Schicht über das unpassende Framework zu legen. Auch das kannst du dir bei Arduino anschauen, und zwar im Falle von STM32 und ESP8266 Mikrocontrollern. Da hast du gleich zwei inkompatible Hersteller-Frameworks, die dennoch mittels Adaptions-Layer wieder verwendet wurden. Erhoffe dir aber nicht zu viel davon. Es wird Stellen geben, die nicht 100% kompatibel machbar sind.
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.