Hallo, ich habe mir einen kleinen Scheduler in ASM geschrieben, siehe Anhang. Gedacht ist er für nicht zeitkritisches quasi Multitasking und in seiner späteren Anwendung auch für Powermanagement. Der Scheduler wird im MAIN loop aufgerufen und ist daher nicht all zu genau, kann aber ohne großen Aufwand auch auf Interruptsteuerung umgebaut werden. Das ganze ist im Moment für ein mega164 mit dementsprechenden Registerpositionen gedacht, aber kritische Passage sind im Quelltext markiert. Geplant ist eventuell noch eine Routine um Tasks zu löschen, im Moment besteht dazu aber keine Notwendigkeit. Wenn Ihr Fragen oder Anregungen habt, immer her damit.
flex schrieb im Beitrag #4839561:
> phpJEsxV7
Wenn das ANSI ist, hast du es zumindest gut versteckt - nu' aber nochmal
richtig mit ordentlicher Dateierweiterung. Das hier lädt sich keiner auf
seinen Rechner.
Grad is wohl der Wurm drin. Wenn ein Mod das vorhergehende bitte löschen könnte. Versuch korrekter Code die Dritte...
Ähm kurze Frage zu diesen beiden Befehlen gibs die wirklich beim Mega164 ? Finde die im InstructionSet nicht STO SDLR_TIME, tmp LOD tmp, TIFR2 Kommt mir eher von ner älteren Plattform bekannt vor
an Chris: Ist im Textblock erklärt; allerdings hätte ich das Zeigen des konkreten Macros für sinnvoller gehalten.
S. Landolt schrieb: > an Chris: > Ist im Textblock erklärt; allerdings hätte ich das Zeigen des konkreten > Macros für sinnvoller gehalten. H. d. das obige Konstrukt lässt sich ohne die Makros nicht übersetzen?
Ausprobieren; ich hab's nicht versucht. Es wäre ja aber kein Hexenwerk, diese selbst zu schreiben.
Danke alles gut habs überlesen :D ne das kein Makro, ich kanns nachvollziehen wenn man es zum Beispiel auf nen Controller packt wo z.B das TIFR2 ausserhalb des IO-Bereiches(>$3F) liegt dann muss man LDS/STS nutzen statt IN/OUT.
an chris: Wieso kein Macro? So z.B.:
1 | .macro STO |
2 | .if @0 < $60 |
3 | out @0,@1 |
4 | .else |
5 | sts @0,@1 |
6 | .endif |
7 | .endmacro |
8 | |
9 | .macro LOD |
10 | .if @1 < $60 |
11 | out @1,@0 |
12 | .else |
13 | sts @1,@0 |
14 | .endif |
15 | .endmacro |
Und wenn man dann noch die defs für tmp&c. ergänzt sowie SDLR_STRUCT_ADDR mit was auch immer, dann wird zumindest assembliert.
Und nochmal, hoffentlich richtig:
1 | .macro STO |
2 | .if @0 < $60 |
3 | out @0,@1 |
4 | .else |
5 | sts @0,@1 |
6 | .endif |
7 | .endmacro |
8 | |
9 | .macro LOD |
10 | .if @1 < $60 |
11 | in @0,@1 |
12 | .else |
13 | lds @0,@1 |
14 | .endif |
15 | .endmacro |
Es ist aber kein MACRO weils oben so drin steht. LOD is synonym for IN/LDS depending on actual register position in AVR. Same for for STO - OUT/STS. Beitrag "AVR-Assembler Verständnisfrage bei IN/ OUT vs. STS/LDS verwenden" Beitrag "ersetzen von in/out durch lds/sts" MaWin schrieb: > Wo ist denn jetzt der Vorteil das in ASM zu schreiben statt in C? Darum gehts jetzt nicht!
chris schrieb: > Darum gehts jetzt nicht! Warum nicht? Das ist halt meine Frage und ich würde das gerne wissen.
an MaWin
Abwarten:
flex schrieb:
> Wenn Ihr Fragen oder Anregungen habt, immer her damit.
Hab nicht geschrieben das man keine Macros schreiben kann. Nur in seiner Beschreibung hab ichs überlesen für was sto/lod steht und nein es müssen nicht zwingend Macros sein. Naja jetzt wird wieder getrollt....
MaWin schrieb: > chris schrieb: >> Darum gehts jetzt nicht! > > Warum nicht? Das ist halt meine Frage und ich würde das gerne wissen. Bist du der Psychopath?
Donny schrieb: > Bist du der Psychopath? Ich bin MaWin und ich würde gerne wissen, wo der Threadersteller seine Motivation hernimmt das in ASM zu implementieren. Wo ist da jetzt das Problem? Die Antwort kann auch lauten: "Weil es mir in ASM mehr Spaß macht." Das wäre natürlich völlig OK. Ich würde es halt nur gerne wissen. Könnten wir jetzt mit der Trollerei aufhören?
Mich würde die Motivation auch interessieren. Multithreading hat wohl wenig Sinn mit 2K RAM, genauso wenig Sinn macht es einen Scheduler in ASM zu schreiben, bis auf den Contextswitch. Für die AVRs sind wohl Statemachinen besser.
MaWin schrieb: > Könnten wir jetzt mit der Trollerei aufhören? Mach das. Und such Dir einen anderen Namen aus. Denn Du bist nicht MaWin.
Karl M. schrieb: > Hallo, > > also mein AVR Assembler kennt keine AVR Befehle: STO und LOD also müssen > es Macros sein. Zu meinen Assemblerzeiten hatte ich Macros die XOUT bzw. XIN genannt für eXtended IN/OUT.
Hallo Peter, ja in unserer Macrosammlung haben wir diese auch. Ich hätte mir gewünscht, das der TO seinen Assembler oder Macrosammlung benennt.
Hallo, wieso Assembler? Weil ich uCs eigentlich nur in Assembler programmiere. Das hat verschiedenen Gründe. Die LOD / STO Befehle sind wie schon vermutet einerseits Macros, aber andererseits auch Gedankenstützen um es von Hand an verschiedenen AVRs anpassen zu können, falls man nicht die Macrosammlung aus AVR001 benützt. http://read.pudn.com/downloads169/sourcecode/math/777464/macros.inc__.htm Ob Multitasking in kleinen 8bittern sinnvoll ist, steht hier nicht zur Diskussion, das muss jeder für sich selbst und seine Anwendung entscheiden. Als Beispiel könnten lange aber nicht rechenintensive Routinen, die auf Peripherie warten, genannt werden. Wenn sich die Diskussion aber einfach nur um den Code selbst drehen könnte, wäre ich dankbar. Frohe Weihnachten!
flex schrieb: > Ob Multitasking in kleinen 8bittern sinnvoll ist, steht hier nicht zur > Diskussion, das muss jeder für sich selbst und seine Anwendung > entscheiden. Das, was du gepostet hast, ist aber kein Multitasking, es sind ganz einfach Routinen, die hintereinander aufgerufen werden. Sollte nur eine davon blockieren, bzw. auf irgendeine Eingabe warten, wartet dein Scheduler auch vergebens. > Als Beispiel könnten lange aber nicht rechenintensive > Routinen, die auf Peripherie warten, genannt werden. Und genau da ist dein Scheduler, welcher in Main sitzt, nutzlos. Der wartet geduldig darauf, dass die Routine endet und zurückkehrt. > Wenn sich die Diskussion aber einfach nur um den Code selbst drehen > könnte, wäre ich dankbar. Warum ? So, wie es jetzt aussieht, ist es absolut nutzlos. Genauso kann man die Routinen auch aufrufen.
So als Idee: Weiß eine Routine, dass sie Wartezeiten hat oder zu lange rechnet, aber die Operation nicht Zeitkritisch ist, könnte sie sich eine Task einrichten (der die Wartezeit abschätzt) und dann den Prozessor freigeben. Nennt sich Kooperatives Multitasking. Daran arbeite ich gerade und es funktioniert wunderbar, insofern ist deine Aussage schlichtweg falsch. Zusätzlich ist ein recht gutes Powermanagement möglich, da wartende Prozesse Tasks einrichten können und zwischen den Task der uC schlafen geht. Da der Scheduler sehr einfach auf Interruptmodus umgebaut werden kann, könnte man übrigens auch Präemptives Multitasking implementieren. Z.B. prüft der Scheduler bei einem neuen anstehend Task ob der PC beim Aufruf innerhalb eines bestimmten Bereichs war, der Subroutinen enthält die unterbrochen werden können. Ist dem der Fall wird ein neuer Task angelegt, der dorthin zurück springt und die Register wieder herstellt. Der anstehende Task wird abgearbeitet und der ursprüngliche darf seine Aufgabe erledigen wenn sein Timeslot gekommen ist.
flex schrieb: > So als Idee: Weiß eine Routine, dass sie Wartezeiten hat oder zu lange > rechnet, aber die Operation nicht Zeitkritisch ist, könnte sie sich eine > Task einrichten (der die Wartezeit abschätzt) und dann den Prozessor > freigeben. Nennt sich Kooperatives Multitasking. > Daran arbeite ich gerade und es funktioniert wunderbar, insofern ist > deine Aussage schlichtweg falsch. Nein. Dein Problem ist, dass alles ohne Timer-Interrupt über main geht. Praktisch eine Statemachine, nur fehleranfälliger und komplizierter. Wenn schon aus main und ohne Timer, dann geht das Ganze mit Flags und Statemachine viel besser. Vorteil: a) Dein Programm weiss immer welche Tasks ausgeführt und welche noch auszuführen sind. b) Dein Programm ist viel leichter zu debuggen und zu verstehen, auch noch nach ein paar Wochen. Ohne Timer-ISR bringt das Ganze überhaupt keine Vorteile, da jeder neue Task erst die anderen Tasks abwarten muss, aber nicht im Voraus wissen kann, wieviele Tasks noch vor ihm auf Abarbeitung warten und wie lange dessen Ausführung überhaupt dauert. Wenn es keiner oder nur einer ist, kann das u. U. zu schnell sein, wenn es aber mehrere sind, kann es schon zu spät sein. Oder es wird als besonders geniale Idee mit Task-Stack rum hantiert, Anzahl der Tasks rausgefunden, die benötigte Gesammtzeit erechnet und am Ende ist dann doch nicht genug Zeit vorhanden. Was dann ? Einen Flag setzen und wieder zurückkehren oder in der Routine warten? Falls Flag - genauso gut geht es mit Statemachine. Falls warten - nix mit Multitasking... Einen Sinn macht das Ganze nur mit Interrupts und TimeSlice, das aber ist eine ganz andere Liga.
Zeig uns doch jetzt mal, wie man jetzt z.B. zwei Tasks einbindet, von denen eine einen Piepser an irgendeinem Port quäken lässt und eine einen Taster abfragt, die den Piepser startet und meinetwegen 2 Sekunden quäken lässt. Ich vermisse übrigens die .def für deine Register.
Auch wenn es nicht direkt Topic ist (da kein ASM). Ich finde diese AVR-Thread-Library super (auch die Dokumentation) http://www.bourbonstreetsoftware.com/AVRDevelopment.html MfG
Hallo und allen noch ein gesundes Neues Jahr 2017! Falls es den einen oder anderen interessiert: Ich habe mal zwei Bibliotheken erstellt, die auf AVR den Umgang mit Code vereinfachen sollen. U.a. die CPU abstrahieren fuer z.B. cooperatives Multitasking... Fuer konstruktive Anmerkungen, Forks oder Sternchen bin ich dankbar :-) https://github.com/dumpsite/avr-contexts MfG Stephan
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.