Hallo, ich möchte mal eure Meinung zu folgendem Vorschlag hören. Ich möchte über ein PC Programm eine .inc Datei generieren, die einen Programmablauf mit ein paar wenigen, vorher festgelegten Befehlen darstellt. AVR Studio soll diese Datei dann über den Assembler laufen lassen und auf den AVR brennen. Ich habe mir folgendes gedacht: ; Programm anfang rjmp 4 ; überspringen der db's .db a,b,c,d,e,f ; Verwendete Parameter im Befehl 1 call befehl_1 ; aufruf Befehl 1 rjmp 3 ; überspringen der db's .db a,b,c,d ; Verwendete Parameter im Befehl 2 call befehl_2 ; aufruf Befehl 2 ; Programm ende ret ; rücksprung zum Hauptprogramm Somit würde das fertige ASM Programm sogar noch lesbar sein und man könnte noch den einen oder anderen Kommentar einfügen. Im Unterprogramm (Befehl) wird die Rücksprungadresse vom Stackpointer gelesen, um die Anzahl der parameter subtrahiert und die vorher definierten Parameter können mittels lpm gelesen werden. Gibt es hierfür eine elegantere Lösung? Oder würdet ihr das ähnlich machen? Viele grüße, Tubie
AVR Studios integrierter Quellcode-Editor Notepad etc. Die Fragenstellung bzw. das Problem ist etwas unverständlich. Deinen Quellcode kannst Du doch in x-verschiedenen Dateien leserlich erstellen, bevor er übersetzt wird.
Oder meinst Du damit eine Art Funktions Interpreter, der den Code aus Deiner INC Datei ausführt?
Hi Wenn du die Parameter nach dem 'call' setzt, kannst du dir den 'rjmp' sparen. Ich habe das mal für eine Stringausgabe gemacht:
1 | ; Schreibt nachfolgenden String |
2 | ; |
3 | ; call print_str |
4 | ; .db "abcde",0 |
5 | ; |
6 | |
7 | print_str: push r18 |
8 | push r19 |
9 | push ZL |
10 | push ZH |
11 | |
12 | in ZL,SPL |
13 | in ZH,SPH |
14 | adiw ZH:ZL,5 |
15 | ld r19,Z+ |
16 | ld r18,Z |
17 | movw ZH:ZL,r19:r18 |
18 | lsl ZL |
19 | rol ZH |
20 | |
21 | print_str10: lpm r18,Z+ |
22 | tst r18 |
23 | breq print_str20 |
24 | rcall lcd_out_char |
25 | rjmp print_str10 |
26 | |
27 | print_str20: adiw ZH:ZL,1 |
28 | lsr ZH |
29 | ror ZL |
30 | movw r19:r18,ZH:ZL |
31 | |
32 | in ZL,SPL |
33 | in ZH,SPH |
34 | adiw ZH:ZL,5 |
35 | |
36 | st Z+,r19 |
37 | st Z,r18 |
38 | |
39 | pop ZH |
40 | pop ZL |
41 | pop r19 |
42 | pop r18 |
43 | |
44 | ret_adr: ret |
Den ersten Teil deiner Frage hebe ich allerdings auch nicht so richtig verstanden. MfG Spess
Mir ist nicht verständlich geworden für welches Problem, das beschriebene Verfahren die Lösung ist. 1. inc oder asm (wieso inc? asm wäre formal korrekter) 2. Generiertes oder manuell gschriebenes "Programm" (Was spielt das problembezogen für eine Rolle?) 3. "Progammablauf" vs. "Programm" (Wo ist da problembezogen der Unterschied?) 4. Übersprungene db direktiven vs. in Register laden Wo ist da problembezogen der Unterschied?) 5. Was heisst "lesbar"?
Hallo, sorry für die unverständliche Erklärung. Im einfachsten Fall möchte ich mit der PC Software ein Programm schreiben - später sogar grafisch das so aussieht: Befehl_1 a b c d e f Befehl_2 a b c d Dieses PC Programm soll mir dann eine .inc Datei im ASM format generieren, die dann natürlich vom AVR Studio verstanden wird. Das ist aber nicht das große Problem. Mir geht es darum, die Parameter an das ASM Programm sauber zu übergeben. eingabe am PC: Befehl_1 a b c d e f ausgabe in der .inc Datei: rjmp 4 ; überspringen der db's .db a,b,c,d,e,f ; Verwendete Parameter im Befehl 1 call befehl_1 ; aufruf Befehl 1 Befehl_1: in z,sp ; rücksprungadresse vom stack laden sub z,4 ; anzahl der übergebenen Parameter abziehen lpm r16,z+ lpm r17,z+ ; jetzt die gespeicherten Parameter (a,b,c,d,e,f) in lpm r18,z+ ; Register laden . . . ret Macht man das in der Praxis so oder denke ich zu kompliziert/gibt es was eleganteres? Gruß, Tubie
Die Frage ist warum Du diesen (Um-)Weg über diese Darstellung gehen willst? Was ist der Vorteil von dieser Darstellung Befehl_1 a b c d e f ggü. z.B. dieser
1 | Befehl_1 (a, b, c, d, e, f); |
oder auch dieser ldi R10, a ldi R11, b ldi R12, c ... call Befehl_1 oder auch irgendeiner anderen Möglichkeit. Erst wenn man weiss welches Problem Du lösen willst kann man auch beurteilen ob der von Dir vorgeschlagene Weg der eleganteste ist. D.h. die angemessenheit einer Lösung kann nicht an ihr selbst allein gemessen werden, sondern nur in Zusammenhang mit dem Problem für das die Lösung gelten soll.
Hi >Macht man das in der Praxis so oder denke ich zu kompliziert/gibt es was >eleganteres? Nennt sich Macro. Zu dem Unterprogramm von oben gehört noch ein Macro:
1 | .macro print |
2 | call print_str |
3 | .db @0,0 |
4 | .endmacro |
Im Programm sieht das Ganze so aus:
1 | .... |
2 | print 'abcdefg' |
3 | .... |
MfG Spess
Ein anderes Beispiel: Zyklisch und abhängig von der Kolbenstellung Benzin in einen Zylinder zu spritzen und zu zünden ist hübsch anzusehen. Aber für ein Landfahrzeug als Lösung anders zu bewerten als für einen Helikopter. Klar, was ich meine?
Tubie schrieb: > Im einfachsten Fall möchte ich mit der PC Software ein Programm > schreiben - später sogar grafisch das so aussieht: = mit einem Editor erstellte Textdatei namens *.inc Tubie schrieb: > Dieses PC Programm soll mir dann eine .inc Datei im ASM format > generieren, die dann natürlich vom AVR Studio verstanden wird. Das ist > aber nicht das große Problem. Mir geht es darum, die Parameter an das > ASM Programm sauber zu übergeben. eine .inc Datei im ASM Format ?????? (klingt wie der Wolf im Schafspelz) was ist den bei Dir ASM Format? eingabe am PC: Befehl_1 a b c d e f ausgabe in der .inc Datei: rjmp 4 ; überspringen der db's .db a,b,c,d,e,f ; Verwendete Parameter im Befehl 1 call befehl_1 ; aufruf Befehl 1 Welches nicht selbst geschriebene Programm sollte das tun. Du redest von einer Art eigenem Compiler oder Interpreter. Tubie schrieb: > Macht man das in der Praxis so oder denke ich zu kompliziert/gibt es was > eleganteres? Assembler oder C Programm !?!?!
Hi >eine .inc Datei im ASM Format ?????? (klingt wie der Wolf im Schafspelz) Du glänzt mit Halbwissen. inc-Dateien sind im AVR-Assembler absolut üblich. Eine steht immer am Programmanfang. MfG Spess
Spess53 schrieb: > Du glänzt mit Halbwissen. @spess besser lesen spess. es ging darum, was eine Dateieindung mit dem darin enthaltenem Format zu tun hat. Und ein Macro hat herzlich wenig mit dem Denkansatz von Tubie zu tun. Hauptsache mal wieder schnell was in die Runde gebracht.
Hallo jetzt mal ganz langsam - ich komm ja kaum mit dem lesen hinterher... erstmal vielen Dank für die ganzen Hinweise! Mir geht es darum wenn ein ganzer Programmablauf ca. 20-40 Befehle zusammenkommt, das das ganze noch sauber lesbar und vor allem nachvollziehbar auf dem Bilschirm steht. Das Format, wie es jetzt auf dem Bildschirm steht ist mir relatiov egal. Das mit dem Macro ist aber echt genial und im prinzip genau das, was ich eigentlich gesucht habe. Dann kann ich die .inc Datei erstmal im AVR Studio manuell schreiben und dann später einen selbstgeschriebenen Befehlsinterpreter die Arbeit machen lassen. Viele Grüße, Tubie
Tubie schrieb: > Dann kann ich die .inc Datei erstmal im AVR Studio manuell schreiben und > dann später einen selbstgeschriebenen Befehlsinterpreter die Arbeit > machen lassen. @spess tut mir leid, versteh ich nicht mehr, kannst DU mir das jetzt vielleicht erklären was er meint?
Hi >es ging darum, was eine Dateieindung mit dem darin enthaltenem Format zu >tun hat. Beim AVR-Assembler hat schon mit der Dateiendung zu tun. Syntaxhervorhebung funktioniert dort nur bei .asm und .inc. MfG Spess
Momentan in der Entwicklungsphase kann ich diese Datei dank der Makros von Hand schreiben. Wenn das Projekt abgeschlossen ist, wird diese Datei von einem externen Programm generiert und muß nicht mehr von Hand bearbeitet werden. sorry
Hi >Tubie schrieb: >> Dann kann ich die .inc Datei erstmal im AVR Studio manuell schreiben und >> dann später einen selbstgeschriebenen Befehlsinterpreter die Arbeit >> machen lassen. >@spess >tut mir leid, versteh ich nicht mehr, kannst DU mir das jetzt vielleicht >erklären was er meint? Nicht wirklich. Vielleicht der x-te Basicinterpreter. Entschuldige. Deine Frage war mir erst eben aufgefallen. MfG Spess
so wie ich es verstanden habe, soll aus einem graphischen Programm(vielleicht sowas wie FUP/FBS bei SPS-Programmierung) ein ASM-Code erzeugt werden, der dann in den MC kommt
Spess53 schrieb: > Nicht wirklich. Vielleicht der x-te Basicinterpreter. Entschuldige. > Deine Frage war mir erst eben aufgefallen. Leicht daneben... Ich möchte für meine Heizungssteuerung die verschiedenen Software Module z.B. Mischer, Außentemperatur, Heizkurve, Pumpensteuerung, etc miteinander Verknüpfen. Da ich die Konfiguration jederzeit abändern möchte, benötige ich einen kleinen Interpreter hierfür. Ein Programm hierfür könnte dann so aussehen: TempSoft AussenTemp,SoftTemp,Trägheit ; Temperatur soften Heizkurve SoftTemp,Neigung,AT0,VLSoll ; Berechnet VorlaufSoll Mischer VLSoll,VList,RList,RelaisAuf,RelaisZu ; Steuert den Mischer Hinzu kommen noch Temperatur Schalter, Grenzwert Schalter, WW Regelung, usw. Ein ELV FS20 Empfänger um den Öffnungsgrad der HK-Ventile zu ermitteln und ggf. die Heizkurve automatisch zu korrigieren. So ist es dann auch problemlos möglich einen Solarkreis mit Temperatur Differenz oder sogar eine Pumpe mit Wellenpaketen anzusteuern. Soweit sogut. Danke nochmal für die Hilfe! gruß, Tubie
Dann sollte Dein AVR aber ein Betriebssystem enthalten! oder willst Du jedes mal den gesamten Code Deines AVR erneuern? Warum verwendest Du für Deinen Anwendungsfall keine SPS?
Ich verwende für diesen Anwendungsfall einen kleinen Linux-Rechner (aktuell Edimax-Router später Dockstar oder Bifferboard). Die komplette Steuerung besteht aus Perl-Skripten. Jederzeit leicht anpassbar. War insgesamt schneller fertig, als eine µC-System zunächst hardwaremäßig aufzubauen und dann noch ein "Betriebssystem" zu schreiben.
Hi >Da ich die Konfiguration jederzeit abändern möchte, benötige ich einen >kleinen Interpreter hierfür. Aber du vermischt mit deiner Methode 'Interpreter' und 'Programm'. Lege deine 'Parameter' im EEPROM ab und schreibe dir eine Routine, mit der du über UART diese Parameter ändern kannst. Das was du dir ausgedacht hast geht in die Richtung: 'Von hinten durch die Brust ins Auge'. MfG Spess PS. >Dann sollte Dein AVR aber ein Betriebssystem enthalten! >Ich verwende für diesen Anwendungsfall einen kleinen Linux-Rechner Solche Aussagen erheitern mich immer wieder.
Spess53 schrieb: > Solche Aussagen erheitern mich immer wieder. Ach, wieso? Ist halt eine Alternative zum Schreiben eines "Betriebssystem" (der Begriff ist etwas hoch gegriffen)/"Interpreter" mit eigener Sprache. Der Linux-Rechner (Router!) ist hierbei, meiner Meinung nach, am flexibelsten.
Hi Wozu braucht man dafür ein Betriebssystem? Und wenn der TO das in Assembler realisieren will, was kein Problem, braucht man auch kein Linux und keinen Linux-Rechner. MfG Spess
Hi Korrektur: 'Problem, braucht ' -> 'Problem ist, braucht ' MfG Spess
Tubie schrieb: > Da ich die Konfiguration jederzeit abändern möchte, benötige ich einen > kleinen Interpreter hierfür. Noch ein Tip von mir: Suche in der Doku mal nach ".equ" Änderungen in der Konfiguration macht man schon mal damit. Ganz viele .EQUs mit den ganzen zu ändernden Werten in eine Datei, diese auswechseln, ändern oder automatisch ändern, und assemblieren. Wenn es noch flexibler werden soll, kannst Du mit ".if", ".else" und ".endif" arbeiten..
Hi Das sind Assembler-Directiven, was soll im das nutzen. MfG Spess
Guten Morgen, ja das Programm ist in ASM geschrieben. Ich stelle am besten mal ganz kurz das System vor, bevor noch mehr geraten wird... ;) Kern des Sytems sind die 100 Ram Parameter es sind jeweils 16 Bit Werte mit einer Typ Kennzeichnung (Datum, Zeit, Festkomma Zahl, int) die werden beim Start auf 0 gesetzt und mit denen arbeitet das System. Dazu kommen Eprom Parameter, die werden im Flash definiert (Factory, Min, Max, Typ) im Eprom steht dann nur noch der aktuelle Wert drin. Beim zurücksetzen auf werkseinstellung wird der wert aus dem Flash ins Eprom gebrannt. Temperaturfühler (1wire) werden auch durch ihre 8 Byte breite id einem Ram Parameter zugeordnet. Puls eingänge für Durchflussmesser und natürlich Relais ausgänge, um Ventile und Pumpen zu schalten. Im RS-485 Netzwerk können dann verschiedene Teilnehmer (Steuerungsgeräte mit fester Teilnehmer Adresse) ihre Parameter austauschen. z.B. Ram Param 10 = Ram Param 15 @ 02 dann wird auf dem RS485 Netz gelauscht, bis Teilnehmer 02 den Wert seines Parameter 15 sendet. Verschiedene Status Bildschirme können auf dem 20x4 LCD angezeigt werden wenn ein Wert eines Parameters dargestellt werden soll genügt es eine $fe zu schreiben und der Wert steht auf dem LCD. Im Master Gerät gehe ich sogar noch weiter. Ein Vinculum VDrive kann die Parameter auf einem USB Stick als .csv Datei mitschreiben. Auf der UART wird ein Siteplayer (kleiner HTTP Server) mit vorher ausgewählten Parametern versorgt. Der Programmablauf arbeitet ausschließlich mit den 100 Ram und Eprom Parametern. Somit ist es letztendlich egal, ob der Temperatu Fühler am Gerät angeschlossen ist oder ein Aussenfühler im Netzwerk ist. Damit ist es auch dann problemlos möglich ein Modul zu bauen, das eine Pumpe mit Wellenpaketen ansteuern kann - Hängt ja am Netzwerk. Diese ganzen Einstellungen mit dem Programmablauf möchte ich in einer .inc Datei auf dem PC mit einem eigenen Programm komfortabel bearbeiten können. Es geht aber erstmal auch mit dem Editor. Ganz später möchte ich dann die einzelnen Module über das RS485 Netzwerk mit dem PC verbinden und über einen Boot Loader die Module Upgraden können. Viele grüße, Tubie
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.