hat jemand eine checkliste mit punkten, die man bei einer portierung (C Sourcen) zwischen zwei verschiedenen mikrocontrollern beachten sollte? stehe gerade vor dieser aufgabe.
Tiffy schrieb: > hat jemand eine checkliste mit punkten, die man bei einer portierung (C > Sourcen) zwischen zwei verschiedenen mikrocontrollern beachten sollte? > stehe gerade vor dieser aufgabe. LOL. Fast alles was irgendwie mit Hardware zu tun hat.
Tiffy schrieb: > hat jemand eine checkliste mit punkten, die man bei einer portierung (C > Sourcen) zwischen zwei verschiedenen mikrocontrollern beachten sollte? Bevor du dir über die Sourcen Gedanken machst, muss erstmal sicher gestellt sein, dass du die Hardware-Funktionalität abbilden kannst.
>hat jemand eine checkliste mit punkten
Der Compiler für den anderen Controller erstellt dir
deine Checkliste;)
Ich kann ein Straßenfahrzeug fahren und will mich portieren ein Wasserfahrzeug fahren zu können, was soll ich beachten?
Das wird auf mich auch zukommen diesen Sommer. Allerdings eher gemächlich da vom stm32f4 auf stm32f7. Ansich müssen bei mir nur die Register Adressen und takte angepasst werden. Ansonsten habe ich beim coden darauf geachtet dass controllereigene Dinge möglichst an die Klassenmember übergeben werden müssen. Wird wohl trotzdem n gschäft für ne Woche.
Reginald L. schrieb: > vom stm32f4 auf stm32f7. Einfach neu compilieren. > Ansich müssen bei mir nur die Register Adressen und takte angepasst > werden. Damit solltest du eigentlich garnicht in Berührung kommen. Dafür hat ST den HAL vorgesehen. CubeMX passt das alles automatisch an.
Also erstens, wenn Du eine vernünftige hardware abstraction hast, dann sollte sich die Arbeit im Wesentlichen auf diese Schicht konzentrieren. Wenn Du die nicht hast, dann hast Du ohnehin ein gewaltiges Problem. Davon ab hat man aber noch ein wenig zu beachten, was hoffentlich von vornherein gemacht wurde: - sind chars auf beiden Plattformen signed bzw. unsigned? - wurden grundlegende Datentypen nach C99 abstrahiert (int32_t und so)? Sonst kann z.B. "int" alles mögliche sein mit mindestens 16 bit. Das wird speziell dann "lustig", wenn statt sizeof überall magic numbers verteilt wurden. - wurden Bitfields wirklich nur benutzt, um über Membernames zuzugreifen? Die sind sonst nicht portabel. - Performance: Auf 8bit-Controllern sind logischerweise 8bit-Operationen am schnellsten. Deswegen wurden oftmals 8bit-Datentyoen gewählt, besonders in Schleifen. Auf ARM hingegen sind 32bit-Datentypen am schnellsten. Für spezifischere Hinweise wär's wie immer eine Idee, wenn Du die betroffenen beiden Mikrocontroller-Familien nicht geheim halten würdest.
Ach ja, und außerdem ist besonders beim Übergang von 8bit auf 32bit alles, was mit Alignment zu tun hat, ein Quell der Freude. Besonders bei structs, die unsauber benutzt wurden (wie etwa, Binärdaten in structs einzulesen). Das kann man u.U. je nach Compiler schnell fixen, indem man packed structs benutzt - aber erstens muß das der 32bitter überhaupt können, und zweitens kostet es Performance. Oh, und Endianess hatte ich auch vergessen. Das haut immer dann rein, wenn man ints von irgendwoher übernimmt, wie z.B. eintreffende Datenpakete, manchmal auch eincompilierte Binärdateien (als Headerfiles). Jedwedes undefined behaviour ist natürlich schon auf der Ausgangsplattform ein Bug, kann aber funktioniert haben - und kann auf der Zielplattform unerwartete Effekte haben. Ansteuerung externer IO-Bausteine können im Timing radikal abweichen, wenn Du z.B. von einem AVR 8bit-Prozessor auf einen schnellen ARM gehst. Da müssen dann auf einmal Delays rein, wenn der Ausgangsprozessor einfach von sich aus langsam genug war. Je nachdem, wieviele Register es auf beiden Plattformen so gab, kann sowas wie register spill zu erhöhtem Stackbedarf führen. Es ist hilfreich, ein Tool wie CppCheck drüberlaufen zu lassen. Außerdem den Compiler mit sämtlichen Warnungen zu aktivieren, bei GCC mit -Wall.
Ich habe schon viel FW portiert und finde das relativ leicht. Solange die einzelnen uC die Randbedingungen der Anwendungen minimal erfüllen ist das in der Praxis kein zu großes Problem vorausgesetzt das funktionierende Original Programm wurde nicht in Assembler geschrieben. Es ist klar, daß man Rücksicht auf die Leistungsfähigkeit der einzelnen uC Rücksicht nehmen muß. Als Beispiel habe ich eine RTU FW die ursprünglich für PIC geschrieben wurde. Da mir diese RTU FW beim Testen von neuen uC Schaltungen und Projekten sehr nützlich ist, dient sie bei mir als Grundbaustein zum Hardware Testen, habe ich sie schon auf jeden uC der für mich von Interesse war, erfolgreich portiert. Wie "Nop" schon sagt, die meisten Änderungen beziehen sich auf das HAL. Bis jetzt portierte ich das besagte RTU Programm auf folgende uC: PIC16F - Original FW (mit CCS C Compiler) PIC16F auf PIC18F (CCS C) DSPIC24/30/33 (CCS C) AVR (328P/32/644P/1284P/120/2560) (CodeVision/GCC) Arduino (328/1284P/2560) (CodeVision/Arduino GCC) NEC28C11 auf AVR1284P (CodevisionAVR oder Arduino) ZILOG Z8 Encore! (ZILOG IDE/Compiler/Debugger) STM32F103/407 (IAR/Crossworks/ImageCraftICCV8/Atollic TS./CooCox) LPC2103 (IAR/Imagecraft V7) LPC2366 (IAR/Imagecraft V7) LPC2476 (IAR/Imagecraft V7),(FORTH Interpreter mit TFT LCD 320x240) AT89LP51ED - (Keil uV2 und uV4) (Hier habe ich noch ein hartnäckiges Problem mit dem ADC. Sonst geht alles. Ist "Work in Progress"). Auch habe ich einiges an publizierten FW Fragmente von verschiedenen uP/uC für mich angepaßt. Viele Code Beispiele hier im Forum habe ich für meine Zwecke portiert. (Peter Danegger Quadratur Encodierer, Tastenabfrage, etc.) Funktioniert auf alle von mir gebrauchten uC. Auch ein für X86-PC geschriebenes Borland C Programm habe ich mal auf PIC portiert (Enigma Simulator) Auch habe ich schon viele Module kreuz und quer portiert. Ich schreibe deshalb meine FW so, daß sie leicht portierbar ist. Einmal auch ein 68HC908 Programm auf PIC16F (CCS C) Man muß halt nur etwas Geduld und Ausdauer haben wenn beizeiten etwas nicht gleich funktioniert und lernen was zu lernen ist wenn mal hier und da Probleme anfallen. Der Weg zum Erfolg: Datenblätter und Referenz Manuale lesen und verstehen. Man lernt beim Portieren viel dabei. Diese ganze Portiererei hat auch den großen Vorteil, daß man in den Quellen die sich schon bewährt haben, Vertrauen haben kann. Jedenfalls geht es mir so. Bei vielen kleineren Projekten ist es selten ein Problem.
:
Bearbeitet durch User
Neutron schrieb: > Damit solltest du eigentlich garnicht in Berührung kommen. Dafür hat ST > den HAL vorgesehen. CubeMX passt das alles automatisch an. Ich arbeite nicht mit hal.
Reginald L. schrieb: > Neutron schrieb: >> Damit solltest du eigentlich garnicht in Berührung kommen. Dafür hat ST >> den HAL vorgesehen. CubeMX passt das alles automatisch an. > Ich arbeite nicht mit hal. Ist doch egal. Der Thread wurde von Tiffy eröffnet, willst du ihn jetzt kapern?
Huh schrieb: > Ist doch egal. Der Thread wurde von Tiffy eröffnet, willst du ihn jetzt > kapern? Hast natürlich recht.
Ich nutze auch weder CubeMX noch HAL, trotz STM32. Erstens ist der ST-Kram meiner Meinung nach kein HAL, sondern ein obfuscation layer. Der abstrahiert die Hardware gerade nicht, sondern macht eigentlich nur register renaming, so daß man dann erstens das Datenblatt UND zweitens die ST-Software verstehen muß, und die ST-Software ist alles andere als gut. Außerdem begibt man sich damit von Seiten der Software in einen vendor lock-in, sofern man nicht sämtliche Hardwaresachen in einem eigenen, dann "echten" HAL kapselt. Was dann entsprechend langsamer wird, wenn das auch noch durch die ST-Pseudo-HAL tickern muß. Was verdeutlicht, wieso man sich seinen eigenen HAL schreiben sollte, um die Anwendung wirklich von der Hardware zu trennen. Die Migration wird damit deutlich einfacher. Einen ganz Teil der Sachen kann man damit übrigens dann auch schon auf dem PC testen, wenn man sich seine Anwendung entsprechend aufbaut.
danke für die zahlreichen hinweise, meinetwegen kann hier jeder zwischenfragen und antworten, ist auch für mich lehrreich. Der zielconrtoller steht noch nicht fest, aber es wird sicherlich von 16Bit nach 32Bit gehen, gibt es hier auch kritische punkte auf die man achten könnte bzw. was ist mit performancegewinn (Maschinenzyklen)? Kennt ihr ein Buch, Internetpfad zu diesem Thema?
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.