Hallo Leute, ich bin an dem Punkt angekommen, an dem meine Software zu kompliziert wird, um so weiterzumachen wie bisher. Ich muss ein bisschen multi threading simulieren, weil ich öfter mal 20-100ms warten muss und sonst andere funktionen zu kurz kommen. Nebenbei brauche ich aber auch noch eine resourcenverwaltung. Also falls der BUS belegt ist, kann nur der prozess zugreifen, der ihn reserviert hat. Hat jemand für mich ein OS (für atmega640), mit dem ich relativ schnell meine Applikation umbauen kann? Grüße
google??? google G O O G L E !!! Das findet dann sicher auch die Infos hier aus der AVR-Softwarepool hier aus dem Forum. Oliver
Schon gelesen? http://www.mikrocontroller.net/articles/Multitasking Imo kommt man auf einem AVR sehr gut ohne Betriebssystem aus, wenn man die Grundsätze aus dem Artikel beachtet. Ansonsten finde ich das Konzept von TinyOS ziemlich gut, wenn man modulare und perfekt wiederverwendbare, aber trotzdem sehr effiziente Anwendungen erstellen möchte. Allerdings ist die Einarbeitung und vor allem das Umstellen eines existierenden Programms nicht einfach. Man muss sich zuerst Bibliotheken und Konfigurationen für nicht von Haus aus unterstütze Hardware anlegen und seine Denkweise eventuell ziemlich umstellen. Wenn man sich darauf einlässt, macht es aber wirklich Spaß.
Tommi schrieb: > Ich muss ein bisschen multi threading simulieren, weil ich öfter mal > 20-100ms warten muss und sonst andere funktionen zu kurz kommen. > Nebenbei brauche ich aber auch noch eine resourcenverwaltung. Also falls > der BUS belegt ist, kann nur der prozess zugreifen, der ihn reserviert > hat. Nun trag hier mal nicht so dick auf und befass dich erstmal mit Timern. Dann kommt auch keiner zu kurz. mfg.
Tommi schrieb: > Also falls > der BUS belegt ist, kann nur der prozess zugreifen, der ihn reserviert > hat. Was fürn Bus denn?
Wenn man's richtig macht, darf eh nur ein Prozess auf einen Bus zugreifen.
Ich benutze ein einfaches Zeitscheiben Verfahren + Interrupts. Wenn man es richtig macht muss da nirgends gewartet werden. Schau dir mal Timer an, hört sich nämlich so an als ob du Spaghetti-Code produziert hast. (Keine Angst, so fängt jeder an!)
Eine einfache Aufgabe die wahrscheinlich sogar mittels delay erledigt werden könnte braucht also ein Betriebssystem ... Soweit ich mich erinnere wird ein Bus durch Adressierung verwaltet und ein Flag das anzeigt das der Bus anderweitig belegt/benutzt wird reicht um anderen Programmteilen den Zugriff zu regeln. Also wo liegt nun eigentlich das Problem ?
OT: warum ein mini betriebssystem, wenn man auch linux haben kann.? http://dmitry.co/index.php?p=./04.Thoughts/07.%20Linux%20on%208bit mach dir ein diagramm was der code tun soll und überleg dir dann wie du die anregungen der vorposter umsetzen kannst. ein betriebssystem ist auf einem kleinen µc eigentlich immer eine der schlechtesten optionen.
cppler schrieb: > Eine einfache Aufgabe die wahrscheinlich sogar mittels delay erledigt > werden könnte braucht also ein Betriebssystem ... In den meisten Fällen wir genau anders rum ein Schuh daraus. Gerade WEIL er _delay_ms benutzt, benötigt man ein Betriebssystem :-) (Ausnahme: wirklich kurze delays wie sie zb bei der Pulserzeugung am TWI Bus entstehen) _delay_ms ist selten die Lösung. Aber oft das Problem.
Wenn Du deine Threads mit Zustandsautomaten umsetzt, brauchst Du kein Betriebssystem. Dann führtst Du einfach beide Zustandsautomaten in dern main-Schleife aus. In diesem Zusammenhang gefällt die Arbeit von Adam Dunkels gut, die ich hier kommentiert habe: http://stefanfrings.de/avr_io/protosockets.html
Karl Heinz Buchegger schrieb: > Gerade WEIL er _delay_ms benutzt, benötigt man ein Betriebssystem :-) Gut machen wir ihm ein _delay_h :-P Oder noch besser _delay_y lapalomapfeif Warum er sich wohl nimmer meldet ?
Thomas Eckmann schrieb: > Uwe schrieb: >> Der BUS würde mich auch mal interessieren... > External Memory Interface > > mfg. Huch. Wußte garnicht, daß der AVR multicore ist und es deshalb beim Memoryzugriff Konflikte geben kann. Peter
Peter Dannegger schrieb: > Wußte garnicht, daß der AVR multicore ist und es deshalb beim > Memoryzugriff Konflikte geben kann. Löte 2 AVRs übereinander und du hast Multicore duckundwech
Peter Dannegger schrieb: > Wußte garnicht, daß der AVR multicore ist und es deshalb beim > Memoryzugriff Konflikte geben kann. Durch besonders geschicktes Verwursten von Memory Mapped I/O kriegt man das auch so hin. Und dann braucht man ein Betriebssystem. Martin Wende schrieb: > Löte 2 AVRs übereinander und du hast Multicore Man könnte auch aus einem alten Pentium4 das Hyperthreading ausbauen. mfg.
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.