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).
