Hallo liebe Mikrocontroller-Community! Ich bin Informatik-Student und habe für meine Bachelor-Arbeit u.a. die Aufgabe, das freie RTOS "ecos" auf einen ARM-Cortex-M3 zu portieren. Mikrocontroller sind mir zwar nicht ganz fremd, aber ich bin noch nicht sehr bewandert in diesem Gebiet, es interessiert mich jedoch sehr, weshalb ich mich für meine BA und meinen weiteren Werdegang in diese Sache "hineinknieen" will ;-) Bisherige Erfahrungen in diesem Bereich: - 5 Monate hardwarenahe SW in C für einen Cortex-M3 programmieren/optimieren (Pflicht-Praktikum) - 1 Semester Vorlesung inkl. kleinen Praktika zur Architektur/Funktionsweise von Mikrocontrollern (anhand des Beispiels MPC555 von Freescale) So weit, so gut...ich habe mich die letzten Tage etwas in das Thema eingelesen und habe nun ein paar Fragen, um zu checken, ob ich bisher alles richtig verstanden habe: - es gibt drei verschiedene Port-Varianten: Plattform-Port, Varianten-Port, Architektur-Port; Der Plattform-Port bedeutet am "wenigsten" Aufwand und für ihn gilt die Voraussetzung, dass die Familie der Ziel-CPU von ecos bereits unterstützt wird. Wenn ich unter http://ecos.sourceware.org/hardware.html nachschlage, ist dort unter unterstützter Hardware die Cortex-M-Familie bereits gelistet. Ich kann also davon ausgehen, dass für meine Absichten dieser sogenannte Plattform-Port ausreichend ist, richtig? Wie groß schätzt ihr den Aufwand dafür ein? - ich bekomme für meine Arbeit u.a. ein Eval-Board von IAR zur Verfügung gestellt. Spielt der Hersteller des Eval-Boards ein Rolle für mein Vorhaben? Die Architektur des Cortex-M3 ist doch überall identisch - unabhängig vom Eval-Board?
> Die Architektur des Cortex-M3 ist doch überall identisch - unabhängig vom > Eval-Board? Kommt drauf an, wie man's sieht. Dass sich die Evalboards unterscheiden dürfte klar sein. Die Controller selbst unterscheiden sich natürlich auch von Hersteller zu Hersteller, was on-chip-Peripherie angeht. Am wichtigsten ist denke ich, dass M3 nicht unbedingt gleich M3 ist. So ist z.B. die BitBanding-Area keine Pflicht, und auch der SysTick-Timer etc. muss nicht unbedingt vorhanden sein - gerade der ist aber für RTOS-Implementierungen gedacht. Daher würde ich schauen, ob's eine Liste der verwendeten Core-Peripherie gibt und das dann mit deinem Derivat vergleichen. Ralf
Ich hab da so leise Zweifel am Sinn des Ganzen. Ecos gibt es schon lange und jedes Jahr sehe ich auf der Embedded einen Stand von "Ecos-centric" oder so ähnlich, die das Stück Programm wie sauer Bier anbieten. Angeblich soll es ja ganz leicht auf alle möglichen Architekturen portierbar sein. Aber die Realität sieht ganz anders aus. Guck dir mal die Quellen an und du wirst das Grausen kriegen. Eigentlich würde ich von einem portierbaren OS erwarten, daß es strikt in hardwareabhängige Teile und hardwareunabhängige Teile getrennt ist, so daß man für letzteres bloß noch den Compiler zu wechseln braucht und sich nur um die Anpassung der untersten hardwareabhängigen Teile kümmern muß oder selbige sogar innerhalb einer Prozessorfamilie selbstkonfigurierend sind. Doch weit gefehlt bei Ecos. Frag dich mal, was die Welt oder du in späteren Jahren davon hast, wenn du es schaffst, diesen Spaghetticode auf einen bestimmten Prozessor auf einem bestimmten Evalboard zum Laufen zu kriegen. OK, deine Bachelor-Arbeit ist damit gemeistert und das ist ja wichtig für dich. Aber ansonsten ist das Ganze vergebliche Mühe bei Ecos. Das Einzige, was wirklich helfen würde, wäre Aufräumen und Ecos ganz gründlich ausmisten, umstrukturieren, modularisieren und so gestalten, daß man wirklich nur noch mit nem Compiler für ne neue Hardware daherkommen müßte und binnen 10 Minuten 99% des BS übersetzt und lauffähig hätte. Aber das ist entweder eine Sysiphosarbeit oder Illusion. W.S.
>Ich bin Informatik-Student und habe für meine Bachelor-Arbeit u.a. die >Aufgabe, das freie RTOS "ecos" auf einen ARM-Cortex-M3 zu portieren. >wenn du es schaffst, diesen Spaghetticode auf einen > bestimmten Prozessor auf >einem bestimmten Evalboard zum Laufen zu kriegen. Da kann ich dir nur zustimmen. Ich würd mal über FreeRtos nachdenken. Das ist wesentlich übersichtlicher.
Ohne es bewerten zu wollen, eCOS ist nicht wirklich mit FreeRTOS vergleichbar. eCOS hat eine sehr umfangreiche und teilweise POSIX (Unix)-kompatible API für u.a. Dateisystem und TCP/IP, während FreeRTOS wirklich nur ein Scheduler mit elementaren Funktionen zur Kommunikation zwischen Tasks ist.
> eCOS hat eine sehr umfangreiche und teilweise POSIX >(Unix)-kompatible API für u.a. Dateisystem und TCP/IP, aber das müsste alles mit C(oder Hochsprachen)-Ebene gehen. Normal (man nicht das letzte aus dem Chip heraus will) sollte nur der Scheduler u. HAL (bsp Hardw.Treiber) hardw-abhängig sein.
Andreas Schwarz schrieb: > eCOS hat eine sehr umfangreiche und teilweise POSIX > (Unix)-kompatible API für u.a. Dateisystem und TCP/IP, während FreeRTOS > wirklich nur ein Scheduler mit elementaren Funktionen zur Kommunikation > zwischen Tasks ist. Das bieten NuttX und ChibiOS auch.
Da hast du was falsch verstanden. Es gibt keine "Ports", das sind HALs. Die Trennung ist da, um Code wieder verwenden zu können (z.B. Code für alle ARMs, Code für bestimmte Familien von ARM, etc). Du kannst dir also die HALs, die du Portieren bzw. Anpassen muss nicht aussuchen, sondern das hängt davon ab, was es schon gibt. Die Architecture HAL wäre wahrscheinlich ARM, Variant HAL M3 und Platform HAL ein bestimmtes Board. Was Hersteller gern verschieden machen ist die ganze Peripherie um den Core ringsherum, aber gerade die will man ja benutzen. Selbst wenn so etwas bei deiner Arbeit ausgeschlossen werden würde, kommt ja noch ggf. MMU, DMA, etc dazu. Bei ARM gibt es auch gern einige Sachen die optional oder "Implementation specific" deklariert sind, da kann dann jeder Hersteller wie er möchte. Ich habe schon mal eCos (mit) portiert und Spass macht das nicht (interessant war es schon). Ich muss meinen Vorrednern Recht geben, der Code ist nicht schön. Ebenfalls sehe ich die Sinnhaftigkeit des Unterfangens nicht. Wenn das Ganze nicht total für die Ablage P werden soll, würde ich dir Raten dich frühzeitig auf der eCos-Developer-Liste zu melden, damit deine Arbeit auch im Repository landet. Deine Vorkenntnisse klingen zwar ordentlich, aber ein Bild kann man sich davon nicht machen. Es ist ja ein Unterschied ob man 5 Montage lang je Woche 1h Praktikum hat oder 8h. Bei letzterem würden die Zeichen sogar auf Erfolg stehen. Ich sehe jedoch ein Zeitproblem, ich würde daher mal abklären, wie es sich verhält, wenn deine Zeit nicht reicht. Manchmal kann man auch schon ein wenig entwickeln und später erst die Arbeit anmelden; somit muss man nicht in die Verlängerung weil die Aufgabe (vom Umfang) explodiert. Hast du denn einen Betreuer bzw. Experten in der Nähe, den du Fragen kannst, falls du Probleme hast? Viel Erfolg beim Abschluss
Vielen Dank für die zahlreichen Antworten! Daran, dass ecos portiert werden soll, gibt es wohl nicht mehr viel zu rütteln – denn das ist die Kernaufgabe der Bachelorthesis. Mal sehen, ob ich das nun richtig interpretiere: Ich nutze ein Derivat eines FM3-Mikrocontroller von Fujitsu auf einem IAR-Evalboard. Dann würde sich die Situation folgendermaßen darstellen: ARM-Architektur --> nämlich Cortex-M3 --> auf einem IAR-Evalboard …da laut der ecos-Website Cortex-M3 von ecos unterstützt wird, würde ich ein „Platform-HAL“ entwickeln müssen, richtig? Wegen dem angesprochenen Praktikum: es waren 5 „volle“ Monate, mit 40 Std. pro Woche :-) Und ja, ich werde bei der Bachelorarbeit seitens einer Firma betreut, falls ich Probleme haben sollte.
>Und ja, ich werde bei der Bachelorarbeit seitens einer Firma betreut, >falls ich Probleme haben sollte. Darauf würde ich nichts geben. Überleg dir das besser noch mal. Aber ist ja dein Leben das du dir versaust wenn du es nicht packst.
Mhh, langsam bekomme ich ein unwohles Gefühl bei der Sache? Ist diese Aufgabe wirklich so schlimm/anspruchsvoll? Wieso würdest du darauf nix geben, Holger? :/
>Ist diese Aufgabe wirklich so schlimm/anspruchsvoll? Hast du überhaupt schon mal einen ARM programmiert? > Wieso würdest du darauf nix geben, Holger? :/ Dir werden dir wohl kaum einen Personal Trainer zur Seite stellen. Im Endeffekt hörst du nur "keine Zeit", "weiss ich auch nicht", "komm Morgen noch mal wieder". Das ist die Realität.
Wie gesagt, ich hab im Pflichtpraktikum die meiste Zeit hardwarenahe Software für einen Cortex-M3 mitentwickelt. Mit OS für Mikrocontroller habe ich bisher keine Erfahrung, geschweige denn mit deren Portierung. Aber es ist ja nicht so, dass mir alles fremd ist, als Informatik-Student sind mir die Grundkenntnisse natürlich geläufig. Ich meine, Professor & Firma machen sich doch auch ihre Gedanken, was man als Bachelorarbeit "anbieten" kann, oder sehe ich das falsch? :/
eCos habe ich bisher nur kurz angeschaut und für den Zweck den ich damals verfolgte als nicht passend empfunden... naja wenn du schon so was machen willst, warum nicht gleich den Job übernehmen? http://wiki.netbsd.org/projects/project/mmu-less/ Wobei das zugegebenermaßen vom Ausmaß her eher in Richtung Diplomarbeit geht... 73
Mich würde grade primär interessieren, wo ihr speziell die Schwierigkeit in dieser Aufgabe seht? Okay, ich hab nun mehrmals gelesen, dass der ecos-Code wohl nicht sehr leserlich zu sein scheint, aber wenn ich nun richtig in der Annahme liege, dass die ARM-Cortex-M3-Architektur von ecos unterstützt wird, dann dürfte ja ein sogenannter Platform-Port/Platform-HAL reichen? ...was ja bekanntermaßen um einges weniger Aufwand ist, als ein Varianten-Port oder Architektur-Port. Oder übersehe ich hier irgendwelche grundlegenden Sachen, die das alles so schwer machen? Bitte klärt mich auf :-)
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.