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.
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
constintanalogInPin=A0;
2
constintanalogOutPin=9;
3
4
intsensorValue=0;
5
intoutputValue=0;
6
7
voidsetup(){
8
Serial.begin(9600);
9
}
10
11
voidloop(){
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.
