Hallo, grade habe ich auf der Micrium-Website gesehen, dass der Code von uC/OS-III verfügbar ist. Den habe ich mir gleich über meinen Studi-Account geholt. Bis jetzt habe ich für private Bastelzwecke immer uC/OS-II benutzt, ein wirklich tolles Betriebssystem! Einziges Manko dabei fand ich immer, dass jeder Task eine andere Priorität haben muss und kein Round-Robin möglich ist. Das wurde ja in uC/OS-III verbessert. Aber auch sonst gibt es einige tolle Neuerungen, die ich gerne ausprobieren möchte! So, für Cortex M3 sowie einige Renesas-Prozessoren sind Ports erhältlich. Leider nicht für meinen ARM9. Und ich kriege es einfach nicht portiert! Ich blicke in dem Manual nicht so recht durch, was ich alles für Files erstellen muss und welche ich von uC/OS-II übernehmen kann. Der Cortex M3-Port, den ich habe, hilft mir auch nicht viel; ich kenne diese Architektur überhaupt nicht und daher weiss ich auch nicht, was ich da übernehmen kann und was ich selber neu schreiben muss. Kann mir jemand helfen, hat das Betriebssystem vielleicht selber im Einsatz oder hat es schon portiert und kann mir weiter helfen? Das wäre echt toll! Vielen Dank schon im Voraus.
Hmm, mal ne neugierige Frage: was alles hast du denn so bislang mit dem uC/OS-II getan? Das ist doch eigentlich nur ein Task-Scheduler - oder? Was alles sonst zu einem richtigen Betriebssystem gehört (API, Peripherie, Filesystem, Applikationslader usw) ist m.W. nicht dabei. W.S.
W.S., ja so halbwegs hast du recht. Ein Memory- und ein Timer-Manager sind beim uC/OS noch dabei. Den Rest, Filesystem, Linker/Loader und so weiter habe ich selber gemacht. Ich finde halt, dass sich mit einem solchen RTOS das Programmieren um einiges vereinfacht; zwar muss man sich plötzlich um Semaphoren, Mutexe und so weiter kümmern, was es ja beim klassischen mainloop mit Interrupts nicht gibt - aber dafür hat man andere Vorteile. Weisst du, was ich beim Portieren beachten muss?
M3 und ARM9 sind jetzt nicht so verschieden, dass Dich das vor Probleme stellen sollte... Manche Sachen, zB. Interrupts sind bei ARM9 umständlicher als bei Cortex. ZiZi.
Hmm, das hilft mir jetzt auch nicht so viel ;-) Im Cortex M3-Port wird da mit diesem NVIC etwas gemacht. Ich habe keine Ahnung, was der Unterschied zum VIC ist, den ich hier habe. Des Weiteren weiss ich auch nicht, wie ich diese WFI und WFE Assembler-Instruktionen auf ARM9 ummünzen soll, der hat sowas ja gar nicht. Ob ich diese Instruktionen brauche oder nicht, wird im Manual von Micrium leider auch nicht gesagt...
moin, hast du mal die sourcen verglichen? wenn ich mich jetzt noch recht errinnere, war das doch halbwegs sauber getrennt, das was machine spezifisch ist (timer, irq) das was plat(form) spezifisch war (arm cortex ... taskswitch und irq/exeptin switch ) und das was generisch ist (der ganze rest der in c geschrieben ist).
Hallo 123, na so direkt verglichen habe ich die Sourcen nicht. Aber bestimmte Gemeinsamkeiten bestehen schon, es gibt da z.B. Funktion CPU_GetPSR und so weiter. Die sind auch kein Problem. Was mir Kopfzerbrechen bereitet, ist der Context Switch, der beim Cortex-Port leider vollkommen anders ist, sowie die Exception Handlers für IRQ, FIQ, SWI. Da habe ich keine Ahnung, wie ich die portieren soll. Mittlerweile habe ich noch Micrium angemailt von meiner Studi-Adresse aus, ob Ports für ARM9 verfügbar sind; ich rechne allerdings nicht mit einer Antwort (eine frühere Anfrage wurde auch einfach ignoriert). Aber anscheinend gibt es einen ARM-Port; zumindest in Google habe ich Fragmente von sowas gefunden - war aber leider nicht brauchbar, weil es nicht vollständig war. Warum der Port allerdings nicht auf der Website zum Download angeboten wird wie für uC/OS-II ist mir nicht klar.
Thomas schrieb: > Im Cortex M3-Port wird da mit diesem NVIC etwas gemacht. Ich habe keine > Ahnung, was der Unterschied zum VIC ist, den ich hier habe. Des Weiteren > weiss ich auch nicht, wie ich diese WFI und WFE Assembler-Instruktionen > auf ARM9 ummünzen soll, der hat sowas ja gar nicht. Ob ich diese > Instruktionen brauche oder nicht, wird im Manual von Micrium leider auch > nicht gesagt... Lesen kannst Du aber? In der Zeit, in der Du hier rumheulst, hättest Du Dich mal mit den relevanten Kapiteln des ARM-v7M Reference Manuals und weiterer tonnenweise im ARM Infocenter vorhandener Literatur beschäftigen können. So schwer ist das alles nicht..., jedenfalls nicht für einen Studenten. >so weiter. Die sind auch kein Problem. Was mir Kopfzerbrechen bereitet, >ist der Context Switch, der beim Cortex-Port leider vollkommen anders Anders als was? Ich wiederhole mich: M3 und ARM9 sind jetzt nicht so verschieden, dass Dich das vor Probleme stellen sollte. Du hättest ja mal den entsprechenden Code bei uCos-II anschauen können, sofern es da einen ARM9 Port gibt (ich kenne uCos nicht nehme aber an, dass das der fall ist) ZiZi.
Hi, so, okay, da ich heute frei hatte, habe ich mal den ganzen Tag investiert in die Portierung. Es läuft jetzt auch! Die Frage ist jetzt nur noch, wie ich testen kann, ob mein Port auch wirklich zu 100% zuverlässig läuft. Gibts da eine Möglichkeit? z.B. muss das Handling der Nested Interrupts geprüft werden und so weiter. Abstürzen tut der Rechner zwar mittlerweile auch nach 1Stündigem Betrieb nicht mehr, aber ich traue der Sache doch noch nicht so ganz. Bestünde wohl Interesse an einem ARM9-Port für uC/OS-III? Ich könnte es ja nach meinem Test hier hochladen.
Thomas schrieb: > z.B. muss das Handling der Nested Interrupts geprüft werden Du müsstest einen entsprechenden Testfall konstruieren, z.B. indem Du in der niederprioren Interruptroutine einen höherprioren Interrupt auslöst, vielleicht über einen SWI oder einen rückgekoppelten GPIO. ZiZi.
Hmm, da scheint noch ein Problem zu bestehen. Im ARM7 Port von uC/OS-II habe ich einen Bug gefunden, der SWI-Handler kann da unmöglich funktionieren! Den Bug habe ich behoben, aber die SWI-Instruktionen funktionieren trotzdem nicht; es führt jeweils zum Absturz der CPU. Etwas befremdlich erscheint mir auch, dass da ein eigener "Exceotion Stack" implementiert wurde; wozu soll der genau dienen? Für die normale Interruptbehandlung wird der nicht gebraucht.
Ach ja, der Bug den ich gefunden habe lautet wie folgt:
1 | MRS R3, CPSR [1] |
2 | . |
3 | . |
4 | . |
5 | LDR R1, __OS_TCBCur [2] |
6 | LDR R3, [R1] [3] |
7 | STR SP, [R3] |
8 | . |
9 | . |
10 | . |
11 | MSR CPSR_cxsf, R3 [4] |
Die Instruktion [1] wird aufgerufen, wenn ein Task von einem Interrupt oder einer Exception unterbrochen wird. Hierbei wird zuerst das cpsr gesichert in r3. Anschliessend werden noch einige weitere Register gesichert und eine Hook-Funktion aufgerufen. Danach muss unter Umständen der Task gewechselt werden. Daher muss bei [2] der aktuelle SP gesichert werden im TCB des aktuellen Tasks. Dabei wird aber R3, das immer noch das CPSR enthält, überschrieben! Und in der darauf folgenden Zeile gibts dann den Crash: das CPSR wird mit R3 geladen, das aber noch die adresse vom TCB enthält. Das ist aber der Original Code von Micrium! Richtigerweise muss es meiner Meinung nach aber heissen
1 | MRS R3, CPSR |
2 | . |
3 | . |
4 | . |
5 | LDR R1, __OS_TCBCur |
6 | LDR R1, [R1] /* R1 kann man gefahrlos verändern */ |
7 | STR SP, [R1] /* SP speichern */ |
8 | . |
9 | . |
10 | . |
11 | MSR CPSR_cxsf, R3 /* R3 enthält immer noch CPSR */ |
Das nur zur Info, falls jemand auch Probleme feststellt. Des Weiteren funktionieren auch SWIs nicht. Dort habe ich bis jetzt allerdings noch keine Lösung gefunden...
Hmm, du hast dich immer noch nicht darüber ausgelassen, was du denn so bislang damit gemacht hast. Ich meine jetzt nicht "compilieren und freuen darüber, daß es durchläuft", sondern was für eine Anwendung des Ganzen. W.S.
W.S., na wenn dir das so wichtig ist... - CNC-Fräse - Webserver mit Anbindung an die heimische Wärmepumpe und Interface zum Stromzähler - Wetterstation alles Sachen zwar, wo man nicht wirklich unbedingt ein RTOS braucht. Aber es ist interessant, und ausserdem bringts mich auch beruflich weiter - immerhin kenne ich dank diesen Basteleien schon das ganze Zeug wie Semaphoren und Mailboxen, und da war es dank diesem Vorwissen sehr einfach, als ich auf der Arbeit plötzlich mit einem RTOS arbeiten musste (wenns auch ein anderes war, in den Grundzügen sind sie wohl doch alle gleich).
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.