Assemblercode Hilfestellung (Anfänger)

[Markus (Gast)]

Hallo Community,

Hier führe ich den Post weiter, der nach der Frage der 
Programmiersprache angefangen hat.

Folgendes Projekt.


Ein µC, Atmel ATMega 168A soll diese Aufgaben lösen:

Eingangssignal 4...20mA digital Wandeln und in 10 Schaltstufen 
auflösen,á 1,6 mA
je nach ermittelter Schaltstufe sollen bestimmte Telegramme über den 
UART ausgegeben werden. Das schaut so aus:

[Startbyte] [Adressbyte] [Kommandobyte] [Datenbyte] [Checksum]
    0x00        0xFF          1x9C          var         var


Ich habe bisher einen Code geschrieben, welcher zuerstmal das Senden 
über den UART nach Bedingung PIN Eingang x = 1 realisieren soll. Der ADC 
ist noch außen vor.


Ich bitte ein Expertenauge mal über den Code zu schauen und mir eine 
Meinung, Fehler, oder Verbesserungsvorschläge mitzuteilen.

[spess53 (Gast)]

Hi

>Eingangssignal 4...20mA digital Wandeln und in 10 Schaltstufen
>auflösen,á 1,6 mA

Was ist mit <4mA?

MfG Spess

[Yalu X. (yalu) (Moderator)]

Noch ein kleiner Hinweis: Wenn du deiner Assemblerdatei beim nächsten
Mal die Endung .asm verpasst, wird für den Anhang automatisch ein Link
"Codeansicht" generiert, der den Code in buntig anzeigt (s. Beispiel).

[Markus (Gast)]

kleiner 4 mA muss verworfen werden als ungültiges Signal.
Für die Steuerungstechnik ein Drahtbruchmelder. 0mA muss Alarm geben.

[Markus (Gast)]

Yalu X. schrieb:
> Noch ein kleiner Hinweis: Wenn du deiner Assemblerdatei beim nächsten
> Mal die Endung .asm verpasst, wird für den Anhang automatisch ein Link
> "Codeansicht" generiert, der den Code in buntig anzeigt (s. Beispiel).

Danke Yalu. Nächstes mal. ;)

[Markus (Gast)]

Hier nochmal als asm

[Wegstaben V. (wegstabenverbuchsler)]

Markus schrieb:
> Hier nochmal als asm

ist eigentlich bei Assemblerprogrammen Komentar verpönt, oder gar 
verboten und führt zu einem Übersetzungsfehler wegen zu einfacher 
Verständlichkeit?

Daß bei einer prozeduralen Hochsprache (welcher Komplexität auch immer) 
durch geschickte Wahl von Objektnamen, und durch geschickte 
Textformatierung Kommentare häufig überflüssig sind, ist ja "bekannt".

Bei diesen Assembler-Buchstabensalat würde ich jedoch nach 2 Tagen nicht 
mehr wissen, wofür das ganze war und wie es funktioniert.

[Markus (Gast)]

Dachte der Experte Überblickt auch ohne Kommentare die Funktion.
Ich werde Kommentare einfügen sobald ich wieder am PC bin.

Markus

[Wegstaben V. (wegstabenverbuchsler)]

Markus schrieb:
> der Experte Überblickt auch ohne Kommentare die Funktion.

der Experte blickt nur auf Funktionen mit Kommentaren ;-)

[spess53 (Gast)]

Hi

>Stufe_0:
>ldi cmd, 0x80
>ldi cs, 0x1B
>rjmp UART_Send

Wie kommst du eigentlich auf die Checksumme?

MfG Spess

[Markus (Gast)]

spess53 schrieb:
> Wie kommst du eigentlich auf die Checksumme?
>
> MfG Spess

alle Bytes addieren, den Überlauf ignorieren.

Bin mir nicht sicher wie die CS sich bei Carry verhält. Hast du einen 
anderern Ansatz zur Berechnung?

[Markus (Gast)]

Kommentiertes asm Nachgereicht. ;)

[spess53 (Gast)]

Hi

>Bin mir nicht sicher wie die CS sich bei Carry verhält.

$FF + $10 = $0F + CY. Also wäre dein CS = $0F

>Hast du einen anderern Ansatz zur Berechnung?

XOR-Vernüpfung.

MfG Spess

[Sascha W. (sascha-w)]

Hallo,

also in deiner UART_send:
um einen Wert in ein Register zu laden musst du
ldi  temp,0x00
schreiben!

bei checkTXR:
ldi temp, UCSR0A   ;falsch >lds temp, UCSR0A  ;richtig

Alle I/O-Register, die mit IN/OUT erreichbar sind, sind in den 
Definitionsdateien auch mit diese Adresse hinterlegt. Wenn du auf ein 
solches Register mit LDS/STS zugreifst, musst du 0x20 zur definierten 
I/O-Registeradresse dazurechnen.


Und ja Kommentare sind in ASM-Code sehr willkommen, sonst weißt du 
selbst nach ein paar Wochen nicht mehr was dein Code machen soll, und 
andere schon gar nicht.

Sascha

[Jobst M. (jobstens-de)]

Moin!

Wie sieht eigentlich die Hardware aus?

In meinem Beispiel habe ich ADC0 als Eingang gewählt und unterstelle 
einen Shunt von 47Ω.

Ich hänge das File hier nun in der kurzen und unkommentierten Form an. 
Sollte die lange Form erwünscht sein, reicht eine kurze Nachricht hier.

Wie gesagt, ist ungetestet, läuft aber ohne Protest durch den Kompiler.


Sascha Weber schrieb:
> Und ja Kommentare sind in ASM-Code sehr willkommen, sonst weißt du
> selbst nach ein paar Wochen nicht mehr was dein Code machen soll, und
> andere schon gar nicht.

;-)


Gruß

Jobst

[codeverwerter (Gast)]

Jobst M. schrieb:
> Sascha Weber schrieb:
>> Und ja Kommentare sind in ASM-Code sehr willkommen, sonst weißt du
>> selbst nach ein paar Wochen nicht mehr was dein Code machen soll, und
>> andere schon gar nicht.
>
> ;-)

...und du merkst beim Schreiben der Kommentare, dass der Code nicht 
das tut, was er sollte! Mir jedenfalls hilft das Kommentieren während 
des Codens manchmal auf die Sprünge. :)

[Jobst M. (jobstens-de)]

ich habe meinen Code mit Kommentaren geschrieben ;-)


Gruß

Jobst

[Markus (Gast)]

Bahnhof. ;-)

Kannst du mal die lange Version Posten bitte?

Danke &, Gruß

Markus

[Jobst M. (jobstens-de)]

Long-Version ...

Ich hoffe es hilft!


Gruß

Jobst

[oldmax (Gast)]

Hi
Nun, da wundert mich nicht, wenn Assembler den Ruf hat, nicht 
erweiterbar zu sein. Sicherlich sind Sprünge in abgesetzte Routinen 
nicht notwendig, erleichtern aber das Arbeiten ungemein. Wird mit 
kleinen Programmsequenzen gearbeitet, läßt sich ein Code nicht nur 
wesentlich besser aufbauen, er läßt sich sogar prima pflegen. Im Prinzip 
:

Reset: 
     JMP INIT           ; Sprung über die IVT zu Init

Init: 
                        ; alles, was parametriert werden muß. z.B.
     CALL INIT_UART
     CALL INIT_I_O
     CALL INIT_Timer
Loop:    ;(Main oder was sonst noch auf's Hauptprogramm zutrifft)
     CALL Read_IO      ; Lesen der Eingänge 
     CALL Debounce     ; entprellen und Flankenbits setzen
     CALL Read_Uart    ; Ringpuffer Empfang prüfen
     CALL Chk_Event    ; Ereignisbearbeitung
     CALL Set_Job      ; Ausgaben aufbereiten
     CALL Write_IO     ; Ausgaben zuweisen
     CALL Send_Uart    ; Senden der Ergebnisse
JMP Loop

Auch wenn es den Code geringfügig aufbläht, durch diese Aufrufe erhält 
man Codebereiche, die einzeln gut zu prüfen sind. Die Informationen 
können über Variablen oder Registerinhalte durchgereicht werden. Ich 
persönlich bevorzuge eine solche Struktur, da sie mir erlaubt, ein 
Programm schrittweise aufzubauen und dabei den Überblick zu behalten. 
Ellenlange Codeabschnitte sind nicht grad  das gelbe vom Ei. Außerdem 
lassen sich solche "Unterprogramme" sehr gut dokumentieren, in dem man 
am Anfang mit Kommentarzeilen die Funktion und die verwendeten oder 
aufbereiteten Variablen schreibt.

;***********************************
;*    Read_IO list die Eingänge    *
;*  und sschreibt diese in die     *
;*  Variable      New_In           *
;***********************************
Read_IO:

Ret

Ab jetzt interessieren nicht mehr die Portbits. In New_In sind die Bits 
völlig anders zugeordnet. Dadurch ist diese kleine Routine auch leicht 
an eine andere Hardware anzupassen. Aber bei der Gestaltung der 
Programmstruktur hat jeder so seine Philosophie. Warum auch nicht.
Gruß oldmax

[Markus (Gast)]

Danke für deine Arbeit Jobst.


Zum Verständnis ein paar Fragen zu deinem Code.

    ldi  tmp2, 233    ;    x*233>>12 = 0-10
    mul  temp, tmp2    ;
    mov  temp, r1
    swap  temp      ; :256(weil MSB) :16 = :4096
    andi  temp, 15
            ; sollte an dieser Stelle 11-15 heraus kommen, wird 'Error' gesendet
            ;  - oder man ergänzt die Zeilen unten

    ldi  tmp2, 5      ; Ein Datensatz hat 5 Byte
    mul  temp, tmp2    ; Multipliziere mit 5

Kannst du mir die Schritte näher erklären?
Warum die ADC Wert Multiplikation mit 233?
Warum Nibbletausch und die oberen 4 bits auf 0?
Wie geht der Verweis auf "Error bei 11-15"?

Warum multiplizierst du den Wert dann nochmal mit 5?

Gruß Markus

[spess53 (Gast)]

Hi

Ich werfe mal kommentarlos eine andere Variante ins Rennen.

MfG Spess

[Peter D. (peda)]

@Spess,

CLR geht direkt auf R2.
Nur Befehle mit I am Ende (LDI, SUBI usw.) gehen nur auf R16..31.
SBR/CBR sind umbenannte ORI/ANDI.

Ich würde für SREG Sicherung ein Register (R3) spendieren, spart je 
Interrupt 4 Befehle (2*PUSH, 2*POP).


Peter

[Jobst M. (jobstens-de)]

oldmax schrieb:
> Im Prinzip

Jo. Aber dafür ist mir dieses Projekt zu klein und ist trotzdem gut zu 
lesen.
Bei größeren Projekten mache ich das auch so.


Markus schrieb:
> Kannst du mir die Schritte näher erklären?

Ganz kurz ... ;-)

> Warum die ADC Wert Multiplikation mit 233?
> Warum Nibbletausch und die oberen 4 bits auf 0?

Ich nehme eine Festkommamultiplikation vor.

233 ist Binär 11101001

Ich setze mein Komma in dem 16-Bit Ergebnis an die 4. Stelle von vorn:
xxxx.xxxx xxxxxxxx

Die 233 darauf gesehen sind

0000.0000 11101001 und sind damit dezimal 0,0568... oder 10/176

z.B. 176 mit 0,0568 multipliziert sind 10,0117...

Oder auch

10110000 x (0000,0000)11101001 = 1010,000000110000

Den Rest hinter dem Komma schneide ich ab. -> 1010 = 10 dez

Aus 10100000 (in R1) wird nach swap 00001010 und dann muß ich noch die 
oberen 4 Bit sicher auf 0 setzen (ist hier schon - ist aber nicht immer)

> Wie geht der Verweis auf "Error bei 11-15" ?

Error steht einfach für die Werte 11 bis 15 unten in den Datenzeilen.


> Warum multiplizierst du den Wert dann nochmal mit 5?

Die 5 ist die Länge eines Datensatzes, der verschickt werden soll.
Die Daten starten also bei 'pakete', 'pakete+5', 'pakete+10', usw.

Ich habe nach der obigen Berechnung eine Ganzzahl von 0 bis 10 (bzw. 15)
Würde ich die 5 gleich mit bei obiger Berechnung einfliessen lassen, 
würde bei 4,5mA z.B. die letzten drei Byte von dem ersten Datenpaket und 
die ersten zwei Byte vom zweiten Datenpaket verschickt.
Also nehme ich die 0-10, multipliziere diese mit 5 und weiß nun, an 
welcher Stelle ab 'pakete' meine 5 Byte zum verschicken stehen.

Ich muß los :-)


Gruß

Jobst