Ich habe jetzt erst einmal eine optimierte Version des Schedulers erstellt:

http://www.roboter.cc/index.php?option=com_nicaiwci&view=project&projectid=1976&Itemid=41

Demnächst mache ich noch eine vereinfachte Version (mit ähnlicher API), die leichter verständlich ist und schreibe an der Doku weiter ...

Viel Spaß schonmal vorab,
- workwind -

Ich habe der optimierten Fassung des Schedulers noch ein paar Synchronisationsmöglichkeiten hinzugefügt:

• Mutex - (Sperren von Resourcen)
• Semaphoren - (Erzeugen und Verbrauchen von Resourcen)
• Events - (Ereignisse)

Das Projekt ist noch dasselbe:
http://www.roboter.cc/index.php?option=com_nicaiwci&view=project&projectid=1976&Itemid=41

- workwind -

Hi workwind

Ich habe mir Dein neuestes *.zip runtergeladen - da ist kein "Scheduler.S" - file mit dabei; hab mir dann dieses File zusätzlich runtergeladen.
Ich hab versucht, das Ganze mal mit AVRStudio4 zu kompilieren:
- die *.c Files in den Ordner "Source Files"
- die *.h Files in den Ordner "Header Files
- das .S File in den Ordner "other files"

Fazit: es kommt die Fehlermeldungusw => da klappt was mit dem Scheduler nicht..
Frage - wohin muss das file "scheduler.s" bzw was muss ich damit machen?

Meine Projekt Einstellungen sind sonst i.O, da ich alle meine anderen Projekte problemlos kompilieren kann...

mfg

Egon

Hallo Egon,

den Fehler mit den nicht vorhandenen .S Dateien im Archiv habe ich korrigiert! Wie man die .S Datei erfolgreich ins AVR-Studio einbindet kann ich Dir leider nicht sagen... Ich weiss dass es Probleme mit der Dateiendung geben kann, kleines 's' und großes 'S' sind ein Unterschied! Im Prinzip ist die .S Datei wie eine .c Datei und wird vom Compiler/Assembler in eine .o Datei übersetzt.

Dieser Link zum Thema sieht mir erfolgversprechend aus:
ucexperiment.wordpress.com/2012/02/09/mixing-c-and-assembly-in-avr-gcc-and-avr-studio-4/

-workwind-

Hi workwind

Dein link war gut - man muss die *.s-files wie ganz normale *.c-files behandeln - einfach zu den "Source-Files" mit aufnehmen - und schon klappt das Übersetzen

mfg

Egon

Hi,

ich habe mirs angeschaut - siehst soweit sehr gut aus Welche Änderungen hast du für die nicht-optimierte Variante vor?

Drei Sachen (eher Sächelchen):
* Zwei Funktionen enable/disable_scheduling - oder, noch besser, incr/decr_scheduling_lock. Der Scheduler soll dann den Task nur wechseln, wenn die Lockvariable 0 ist. Diese könnte man dann z.B. in Systemfunktionen wie schreiben aufs LCD/UART, I2C etc. verwenden. So könnte man verhindern, dass sie unterbrochen werden und schlimmstenfalls im nächsten Task wieder aufgerufen werden. Deine Listenimplentierung ist wenn ich es richtig sehe z.B. auch nicht threadsafe, oder? malloc und Friends sind ebenfalls Kandidaten für einen Wrapper, der das absichert - ich glaube nicht, dass die threadsafe sind.
Mit incr/decr könnte man Systemfunktionen verschachteln.
* In _thread_s nicht nur den aktuellen Stackpointer, sondern auch Beginn und Größe speichern. So könnte man prüfen, ob der Stackpointer im aktuellen Bereich ist. Man könnte am Anfang und am Ende der jeweiligen Stacks jeweils auch ein Cookie legen und den beim Rein- und Raussprung überprüfen, ob das Cookie noch ok ist. Für viel später könnte man auch eine einfache Checksumme vorsehen
* Das ganze in eine .a-Datei stecken. Dann könnte man es einfach dazu linken und man kommt gar nicht erst in Versuchen zu pfuschen

Das wars erstmal Ich werde den Code mir die nächsten Tage mal genauer anschauen und auf die Biene loslassen

Bissle offtopic: Ist es eigentlich geplant, den Code der Nibo2 und dem Nibobee zusammenzulegen? Oder dass man für die beiden Nibos jeweils eine Lowlevel Lib hat und für die höheren Funktionen wie Multitasking, I2C, Speicherverwaltung etc. in eine weitere Lib zusammenfassen, die dann auf beiden Robotern verwendet werden kann?