www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik AVR asm code bewerten und kritisieren bitte!


Autor: Attila (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo!

Ich habe meinen ersten etwas komplexeren Code geschrieben und würde mich 
freuen wenn ein paar Profis drüberschauen und kommentieren. Damit sich 
keine Fehler für meine "Programierzukunft" einschleichen.

Das Programm läuft auf einem ATmega 8 und liest über RS 232 ein Navilock 
NL550ERS GPS Modul aus. Auf einem 2*16 LCDisplay werden geographische 
Breite und Länge, Zeit in UTC und GPS Höhe angezeigt.

Eine Frage jetzt schon: Das Display flackert fast unmerklich und sehr 
schnell. Man kann gradezu sehen wie der ATmega arbeitet. Kann man das 
durch geschickte Programierung ändern?

Vielen Dank schonmal!

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  Attila (Gast)

>Eine Frage jetzt schon: Das Display flackert fast unmerklich und sehr
>schnell. Man kann gradezu sehen wie der ATmega arbeitet. Kann man das
>durch geschickte Programierung ändern?

Sicher, das Diplay NICHT löschen sondern überschreiben. Und das auch nur 
mit 1-5 Hz, schneller braucht das eh keiner.

MFG
Falk

Autor: Sauger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nabend,

Attila schrieb:
> Eine Frage jetzt schon: Das Display flackert fast unmerklich und sehr
> schnell. Man kann gradezu sehen wie der ATmega arbeitet. Kann man das
> durch geschickte Programierung ändern?

Mal dir ein Flussdiagramm, dieses wird einige Klarheiten beseitigen :-)

MfG

Autor: Attila (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
1 HZ wär schon ganz nett da meine UTC Zeit mit Sekunden angezeigt wird 
;-)
Ansonsten Danke schon mal!

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Fang damit an, offensichtliche Teilfunktionalitäten in Unterprogramme 
auszulagern.

Dazu gehört zb:
  LCD initialisieren
  einen String auf dem LCD auszugeben

Dazu solltest du dir ein Konzept überlegen, wie du Strings speichern 
willst.

Dein ganzes Programm ist mit Annahmen gespickt, was die Anzahl 
empfangener Zeichen betrifft. zb
    ldi    ZL,LOW(BREITE)      ;Z-pointer für SRAM  Segment "Breite"
    ldi    ZH,HIGH(BREITE)

    rcall  receive          ;Geographische Breite abspiecher
    st    z+,temp
    rcall  receive
    st    z+,temp
    rcall  receive
    st    z+,temp
    rcall  receive
    st    z+,temp
    rcall  receive
    st    z+,temp
    rcall  receive
    st    z+,temp
    rcall  receive
    st    z+,temp
    rcall  receive
    rcall  receive
    rcall  receive
    rcall  receive
    st    z+,temp

die geographische Breite von deinem NMEA Gerät kennzeichnet sich NICHT 
dadurch aus, dass da genau 11 Zeichen daher kommen. Die geographische 
Breite sind die Zeichen, die daherkommen, bis zum nächsten ',' Zeichen!
Dein Code funktioniert jetzt vielleicht bei dir zu Hause, aber am 
anderen Ende der Welt, mit einer anderen Zeichenzahl für die Breite, 
funktioniert er nicht mehr.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Attila schrieb:
> 1 HZ wär schon ganz nett da meine UTC Zeit mit Sekunden angezeigt wird
> ;-)

Ähm.
5Hz ist schneller als 1Hz

1 Hz ... 1 mal pro Sekunde
5 Hz ... 5 mal pro Sekunde

Autor: Attila (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Aua! Ja das mit den 5HZ stimmt natürlich!

Was ein "string" ist weiss ich nicht aber das werde ich hier nachlesen 
und umsetzen.

Das mit dem ',' habe ich nun garnicht vertstanden. Das GGA Protokoll 
spuckt eine Unmenge von Kommata aus.
Und was ich auch nicht verstehe: Wieso soll denn eine geograghische 
Breite nicht immer die gleiche Anzahl Zeichen haben?

Bevor jetzt jemand schimpft: Ja! Ich lese ein Zeichen zuwenig für die 
Länge aus! Das sieht schöner auf dem Display aus und es ist nicht 
anzunehmen dass ich mich in absehbarer Zukunft nach 100 plus Grad Ost 
oder West bewege.

Autor: doofi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Was ein "string" ist weiss ich nicht
http://forum.finanzen.net/board/anonymize/attachme...

SCNR

"String" ist die englische Bezeichnung für "Zeichenkette".

>Wieso soll denn eine geograghische
>Breite nicht immer die gleiche Anzahl Zeichen haben?
Hm...
5° = 1 Zeichen
25° = 2 Zeichen
?

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Attila schrieb:
> Aua! Ja das mit den 5HZ stimmt natürlich!
>
> Was ein "string" ist weiss ich nicht aber das werde ich hier nachlesen
> und umsetzen.

Ein string ist eine Ansammlung von Textzeichen.
"Attila" ist ein String. Er besteht aus den Buchstaben 'A' 't' 't' 'i' 
'l' und 'a'. Und irgendeinem Verfahren, das dir erlaubt das Ende eines 
Strings zu erkennen.

> Das mit dem ',' habe ich nun garnicht vertstanden. Das GGA Protokoll
> spuckt eine Unmenge von Kommata aus.

Aus guten Grund. Damit man per Programm feststellen kann, wo eine 
Information zu Ende ist und eine ander anfängt

> Und was ich auch nicht verstehe: Wieso soll denn eine geograghische
> Breite nicht immer die gleiche Anzahl Zeichen haben?

Weil   0.123  nun mal über weniger 'Buchstaben' verfügt als 42.786
Aber es ist ja nicht nur die Breite. Du hast ja in der Länge dieselbe 
Annahme gemacht. Einmal kurz nach England fliegen, und schon ändern sich 
die 15.876 Grad östlicher Länge zu 1.265 Grad westlicher Länge. Oder 
nach Australien. Da sind es dann irgendwas bei 180.234 Grad

>
> Bevor jetzt jemand schimpft: Ja! Ich lese ein Zeichen zuwenig für die
> Länge aus! Das sieht schöner auf dem Display aus und es ist nicht
> anzunehmen dass ich mich in absehbarer Zukunft nach 100 plus Grad Ost
> oder West bewege.

Darum gehts nicht. Wenn du es richtig machst, spielt es keine Rolle wo 
du bist. Und kürzer wird dein Programm ausserdem.

Autor: Attila (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also:

Ich sehe ein das man es wohl anders machen muss als einfach nur eine 
betimmte Anzahl Zeichen anzunehmen. Allein schon für irgendwas was in 
der Zukunft auf mich zukommt und ausgelesen werden muss

aber:

Zumindest bei dem Protokoll was mein GPS auspuckt ist es immer die 
gleiche Anzahl Zeichen. Es kommen dann Nullen an die Stelle die nicht 
gebraucht wird.
Im Datasheet so beschrieben:

Message Structure:
$GPGGA,hhmmss.ss,Latitude,N,Longitude,E,FS,NoSV,HDOP,msl,m,Altref,m,Diff 
Age,DiffStation*cs<CR><LF>

Example:
$GPGGA,092725.00,4717.11399,N,00833.91590,E,1,8,1.01,499.6,M,48.0,M,,0*5 
B

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Attila schrieb:

> Zumindest bei dem Protokoll was mein GPS auspuckt ist es immer die
> gleiche Anzahl Zeichen. Es kommen dann Nullen an die Stelle die nicht
> gebraucht wird.

Da hast du wohl recht.
Das war mir noch gar nie bewusst. Liegt wohl daran, dass ich mich lieber 
am ',' orientiere, als bestimmte Stellenanzahlen zu verlangen. Ist auch 
Codetechnisch simpler, wenn man ein Abschlusszeichen hat

rec_info:  Empfange Zeichen
           ist es ','
           Ja -> Sprung nach rec_Ende
           Speichere das Zeichen über das Z register
           springe nach rec_info
rec_ende:  noch ein 0-Byte an den Text anhängen um
           den String abzuschliessen
           return

und schon hab ich eine Routine, die sowohl Breite als auch Länge 
empfangen kann. Ich muss nur das Z Register vorher mit der Adresse 
füllen, wo die Information im SRAM abgelegt werden soll.

Selbiges für die Ausagberoutine

lcd_string  hole Zeichen über Z
            ist es 0?
            ja -> lcd_string_ende
            Zeichen ausgeben
            spring nach lcd_string
lcd_string_ende:
            return

Z Register auf den Anfang des Strings setzen und schon gibt er aus, was 
er dort vorfindet. Und da die empfangsfunktion am Ende des Textes eine 0 
abgelegt hat, kann die Ausgabefunktion diese 0 benutzen um das Ende des 
Textes festzustellen

Ich hab nur 2 Funktionen, die mit beliebig langen Texten umgehen können, 
solange ich nur im SRAM genügend Speicher dafür vorgesehen habe.

Autor: Attila (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Karl!

Da ich noch Anfänger bin ist mir nicht ganz klar wie Du das machst aber 
mir ist klar (glaube ich) was Du da machst. Jetzt Frage ich mich aber:
Wie sortierst Du das richtige Komma aus den unzähligen Kommata aus?

Aber ist schon mal ein sehr lehrreicher Diskurs hier!

Autor: Spess53 (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hi

>Ich sehe ein das man es wohl anders machen muss als einfach nur eine
>betimmte Anzahl Zeichen anzunehmen.

Als erstes solltest du das Einlesen des NMEA-Strings im Hintergrund 
laufen lassen. Erst wenn der vollständig vorliegt werden die Werte 
extrahiert und angezeigt.

Im Anhang mal ein Stück Code aus dem Programm zu dem hier:

Beitrag "Re: Zeigt her Eure Kunstwerke !"

Wie du siehst ist die 'mainloop' kurz und übersichtlich. Der NMEA-String 
wird im RX-Interrupt eingelesen und bei Vollständigkeit ein Flag 
gesetzt. Wenn das gesetzt ist verzweigt die 'mainloop' zu Verarbeitung.

MfG Spess

Autor: BjoernC (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok dann möchte ich mal kurz etwas zu deinem Code sagen vom Stil her. Ich 
kann mich ansonsten nur den Vorrednern anschließen.
Also kommen wir zu nächst zu den ausgerollten Schleifen.
    st    z+,temp
    rcall  receive
...
    rcall  receive
    st    z+,temp
    rcall  receive
...
    rcall  receive
Dieser Stil ist in diesem Programm meines erachtens nach nicht 
angebracht. Das Problem ist folgendes. Dieses kleine Programm ist später 
teil eines größeren Projektes und du musst den Namen recieve ändern - 
spätestens dann hast du ein Problem. Daher solltest du das ein einer 
schleife verpacken. Dadurch wird dein Programm wartbarer.
Das hat zweierlei Vorteile, zum einem ist es wartbar und zum zweiten 
schont es dein Programmspeicher. Für ein kleines Programm ist es 
natürlich nicht immer relevant den Programmspeicher zu schonen, nur bei 
ein wenig größeren Projekten kann dir das ausrollen dein Genick brechen 
;).

Das ausrollen von Schleifen kann Sinn machen aber nur dann, wenn du 
wirklich Zeitkritische Dinge hast die du auf 1-2 Takte genau benötigst.

Dann gehe ich mal weiter, kommen wir mal zum Naming:
test:  
  
D:    rcall  receive          ; NMEA Protokol "GGA" identifizieren
    cpi    temp,'$'
Das "D" stört mich zunächst erstmal gewalltig, es sagt nichts aber 
überhaupt nichts aus. Ich kann weder beurteilen was es macht und einen 
einzelnen Buchstaben übersieht man leicht. Desweiteren "recieve" finde 
ich auch unglücklich und zwar sehe ich das ich etwas empfange aber nicht 
was. Das kann aber zT. sehr wichtig sein. Daher würde ich eher sowas 
hinschreiben: "rec_GPS_char" oder sowas in der Art (nur die erste Idee 
von mir).

Zu der Formatierung:
.include "m8def.inc"
 
.def temp   = r16
.def temp1  = r17
.def temp2  = r18
 
.equ F_CPU = 8000000                            ; Systemtakt in Hz
.equ BAUD  = 38400                              ; Baudrate
...
main:
        ldi      temp, HIGH(RAMEND)    ;Stackpointer initialisieren
         out     SPH, temp
         ldi     temp, LOW(RAMEND)  
         out     SPL, temp

    ldi    temp, 0b11111110    ;Port D auf Ausgang
    out    DDRD,temp
...      
init:  rcall zeit     
...          
HOHE:    .byte  10           ;10 Byte unter dem Namen 'HOHE' reservieren
Auch hier wäre es sehr angenehm wenn du das wirklich einheitlich 
gestaltest. und zwar EINE Spalte Label, Befehl, Operand "präprocessor 
direktiven" sollten sich ebenfalls in einer festen Spalte befinden.
So das wars von meiner Seite...

Autor: Attila (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Spitze! Als ich den Code hier eingestellt habe hatte ich genau solche 
Kommentare erhofft wie sie jetzt hier kommen! Einfach Klasse! Ich sehe 
schon das viel aber spannende "Arbeit" auf mich zukommt! Danke schonmal!

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Attila schrieb:
> Karl!
>
> Da ich noch Anfänger bin ist mir nicht ganz klar wie Du das machst aber
> mir ist klar (glaube ich) was Du da machst. Jetzt Frage ich mich aber:
> Wie sortierst Du das richtige Komma aus den unzähligen Kommata aus?

genauso wie du das auch machst
Du weisst ja, in welcher Reihenfolge die 'Felder' daherkommen und was 
nach dem jeweils nächsten Komma kommt

Autor: tobi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Ich habe meinen ersten etwas komplexeren Code geschrieben und würde mich
> freuen wenn ein paar Profis drüberschauen und kommentieren. Damit sich
> keine Fehler für meine "Programierzukunft" einschleichen.

Noch eine ganz prinzipelle Frage: Wieso in Assembler?
("Profis" nehmen kein Assembler, zuminderst nur in Ausnahmefällen)

Autor: Attila (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe am Anfang irgendwo gelesen dass es ganz schlau ist erst einmal 
assembler zu lernen bevor man eine "höhere" Sprache lernt.

Ausserdem glaube ich dass es in allem was man so machen kann auf dieser 
Welt Profis gibt.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Attila schrieb:
> Ich habe am Anfang irgendwo gelesen dass es ganz schlau ist erst einmal
> assembler zu lernen bevor man eine "höhere" Sprache lernt.

Natürlich, stimmt schon.
Aber die meisten schwenken dann ab einer gewissen Komplexität auf eine 
höhere Programmiersprache um. Irgendwann hat man in Assembler einfach 
zuviel unproduktiven Aufwand rundherum, so dass es sich nicht mehr 
lohnt.

> Ausserdem glaube ich dass es in allem was man so machen kann auf dieser
> Welt Profis gibt.

Industriell sehen die Zahlen in etwa so aus:
Man rechnet, dass ein Programmierer durchschnittlich am Tag in etwa 10 
Zeilen fehlerfreien Code produziert (10 Anweisung, alles in eine Zeile 
quetschen gilt nicht). Das darfst du dir jetzt nicht so vorstellen, dass 
er nur 10 Zeilen schreibt, sondern da ist auch alle Zeit für 
Vorbereitung, Testen und Debugging, Fehlersuche und Fehlerbehebung mit 
eingerechnet und auf die komplette Projektlaufzeit umgelegt. Es gibt 
natürlich Tage, an denen man seitenweise Code schreibt und es gibt 
natürlich Tage an denen man überhaupt nichts schreibt sondern nur auf 
Fehlersuche ist. Auch die 10 sind nicht Gott gegeben, sondern hängen vom 
Schwierigkeitsgrad des Projekts ab. Ob das jetzt 10 oder 15 sind ... 
geschenkt. Aber irgendwo in diesem Bereich bewegt sich die Zahl in einem 
realen Projekt.
Das Interessante daran ist, dass diese Anzahl ziemlich unabhängig von 
der Programmiersprache ist. Hat man eine höhere Programmiersprache, dann 
kann man in einer Anweisung sehr viel mehr ausdrücken als in Assembler. 
Daher ist man in einer höheren Sprache auch produktiver. Eben weil der 
Compiler den ganzen Routineteil zwischen den Anweisungen übernimmt. Je 
mächtiger die Sprache ist, desto mehr kann man in ca. 10 Zeilen 
ausdrücken.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  Karl heinz Buchegger (kbuchegg) (Moderator)

>Compiler den ganzen Routineteil zwischen den Anweisungen übernimmt. Je
>mächtiger die Sprache ist, desto mehr kann man in ca. 10 Zeilen
>ausdrücken.

play(chess);

;-)

Autor: ziegenpeter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich würd gerne mal die Label-Namen kritisieren.
Man kann auch in Assembler lange, sprechende Namen verwenden (macht die 
resultierende Binary nicht größer - scheint bei manchen die Sorge zu 
sein), dann kann auch jemand der den Code zum ersten Mal sieht (oder man 
selbst, nach längerer Zeit, beim Debuggen), direkt am Namen erkennen, 
was eine Fuktion machen soll.

z.B.

statt "receive" -> "receiveOneCharacterFromUART"
statt "zeit" -> "wait80milliseconds" (wo man sich ja schon die Mühe 
macht einen Kommentar "eine 80ms Warteschleife" rein zu schreiben)

Ich mach auch gerne "Trennstriche" zwischen Funktionen, macht es auch 
noch etwas übersichtlicher.
-------------------------
clearDisplay:
      ldi    temp, 0b00000001  ;Clear display, return cursor to home
      rcall  sendDataToDisplay
      ret

-------------------------
jumpTo2ndLine:
      ldi    temp, 0b11000000  ;zur zweiten Zeile im Display springen
      rcall  sendDataToDisplay
      ret  

-------------------------    
receiveOneCharacterFromUART:
      sbis     UCSRA, RXC                      
      rjmp     receiveOneCharacterFromUART
      in       temp, UDR
      ret


Autor: Attila (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also vielen Dank bisher für die konstruktive Kritik aber vielmehr dafür 
dass ich mich , aufgrund der Kommentare, entschlossen habe C zu lernen.
Ich denke meine asm Kenntnisse sind ausreichend um jetzt darauf 
basierend auf C umzusteigen. Auch wäre ich ohne die Beiträge hier nicht 
auf die Idee gekommen "asm vs C" hier im Forum durchzulesen was wiederum 
zu der Erkenntnis führte das ich auf C umsteigen sollte.

Vielen Dank dafür und bis bald mit Anfängerfragen in C hier im Forum :-)

Ach so:

play(chess);

ist natürlich genial :-) :-) :-)

Autor: Jay (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Karl heinz Buchegger:

> ...  Da sind es dann irgendwas bei 180.234 Grad ...

War nicht irgendwie bei +- 180 Grad schluß?
Oder meinst Du Gon (Neugrad), das ging glaub ich bis 400.

Grüße
Jay

Autor: oldmax (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

>Ich denke meine asm Kenntnisse sind ausreichend um jetzt darauf
>basierend auf C umzusteigen.
Nun, wenn ich mir dein ASM Programm so anschau... also, da ist noch viel 
besser zu machen. Nicht, das ich gegen C wäre, Aber Assembler zwingt 
geradezu kleine Programmblöcke zu schreiben, damit der Überblick nicht 
verloren geht. Bei höheren Sprachen ist's aber ähnlich. Auch hier sind 
kleine Codeabschnitte von Proceduren oder Functions hilfreich, aber man 
verliert leicht den Bezug zur Hardware. Schnell hat man in einen Atmega 
ein paar überflüssige Codes geschrieben, weil eben C mehr als nur eine 
Anweisung in eine Zeile bekommt, oder man wundert sich, das 70% vom 
Speicher schon belegt sind, obwohl noch so viel offen ist.
Also, meine Empfehlung, bleib erst noch ein Weilchen im Bereich 
Assembler, bis du in deriner Programmierung etwas modularer wirst. 
Zumindest im Bereich der µC's. Dafür empfehle ich, weils vielleicht 
nicht so stressig ist, im PC Bereich mit C-Programmen zu arbeiten. Z.B. 
Software, um deinen Controllern Daten zu entlocken und diese zu 
bearbeiten oder Parameter in die Controler zu schieben, um andere 
Funktionalität ohne Programmänderung zu erreichen. Das Übt.

Gruß oldmax

Autor: Attila (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo oldmax!

Du hast sicher recht aber was ist denn mit den ganzen Leuten die in C 
programieren und haben sich noch nie mit assembler beschäftigt?

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Attila schrieb:
> Hallo oldmax!
>
> Du hast sicher recht aber was ist denn mit den ganzen Leuten die in C
> programieren und haben sich noch nie mit assembler beschäftigt?

Auch die müssen sich durch die Datenblätter/Handbücher quälen.
Allerdings haben sie meistens etwas verschrobene Vorstellungen davon, 
was da auf der CPU wirklich passiert.
Als Assembler Programmierer bist du direkt am Geschehen.
Sozusagen: Autofahren ohne Servolenkung und ABS. Und gebremst wird, 
indem du mit den Händen die Bremsbacken zusammendrückst.

Autor: Attila (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Naja durch Datenblätter usw habe ich mich ja bereits gequält und zwar 
nicht zu knapp. ich werde es ja sehen ob meine assemblerkenntnisse auf 
deisem Stand tatsächlich zu mangelhaft sind um in C weitermachen zu 
können. Ich kann es mir kaum vorstellen ehrlich gesagt.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Attila schrieb:
> Naja durch Datenblätter usw habe ich mich ja bereits gequält und zwar
> nicht zu knapp. ich werde es ja sehen ob meine assemblerkenntnisse auf
> deisem Stand tatsächlich zu mangelhaft sind um in C weitermachen zu
> können. Ich kann es mir kaum vorstellen ehrlich gesagt.

Denk ich nicht.
Nach dem Code oben zu urteilen, hast du noch Bedarf in den Themen 
"Codeorganisation" und "Allgemeine Programm-Strategien".
Das ist in C auch nicht anders als in Assembler. Nur eben auf einem 
anderen Niveau.

In C schiebst du Funktionalität in Funktionen und arbeitest mit 
Hilfsvariablen ohne mit der Wimper zu zucken. In Assembler musst du 
immer aufpassen "hab ich jetzt die richtigen Register", "zerstör ich mir 
da jetzt Register", "was ist mit den Flags", etc. Alles Dinge, um die 
sich der C-Compiler kümmert.

Autor: Harald M. (mare_crisium)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Attila,

hier

http://www.roboternetz.de/phpBB2/viewtopic.php?t=5...

hatte ich mit robo_wolf auch mal einen AVR-Assembler-Lernkurs angelegt. 
Ist vllt in Hinblick auf einen modularen Programmierstil interessant.

mare_crisium

Autor: Attila (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Harald: Danke!

@Karl: Aber genau das will ich eben nicht: Wissen wann wo welcher Flag 
und wie man dividiert wenn man nur + und - zur Auswahl hat.

Ich hatte beim Studium das assembler Tutorials eben NICHT den Eindruck 
dass es um Programmstartegien geht sondern eher darum dass es eben 
tatsächlich nur + und - gibt. Und das es register gibt und Flags usw 
usw.

Ich habe ein wenig den Eindruck das ich lernen soll ein Ventil 
auszutauschen und es nicht reicht zu wissen dass ein Motor Ventile hat 
und wofür die sind. Dabei will ich doch nur Auto fahren!

Autor: oldmax (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi
>Dabei will ich doch nur Auto fahren!
Ich glaub, hier verwechselst du etwas. Wer sich (privat) mit µC's 
beschäftigt, der will eben nicht nur Autofahren, der will ein Formel 1 
Fahrzeug um die Kurven jagen.
Wenn du nur Auto fahren willst, dann mach es wie die unzähligen PC User, 
schreibe Briefe in Word und kalkuliere deine Kosten in ExCell oder 
spiele stundenlang irgend ein Game.
Aber egal, welche Programmiersprache... du mußt lernen zu analysieren 
und Aufgaben zu verteilen.
Hier ist nix mit "ich setz mich mal eben hin und dreh den Schlüssel um" 
und Hui... auf geht's.
Auch auf Controllern ist die Sprache meiner Erachtens letztlich abhängig 
von der Anwendung. Und ich denke, wer im professionellen Bereich 
Programme schreibt, der hat auch gute Compiler. Was ich aber bei einem 
Anflug von Wissensdrang mit BASCOM und e-Lab (Pascal) erlebt habe, war 
jenseits von Speichersparend. Da sind ein paar Zeilen mit Aufrufen von 
ein paar Funktionen und schon ist der halbe Flash voll....
Bitte nicht darüber diskutieren, ich weiß, das ich da überhaupt keine 
Ahnung von hatte und vieles falsch angesetzt war. Aber trotzdem wollt 
ich erwähnen, es ist schon ein Unterschied, ob die Software für lau oder 
ein professionelles Entwicklungssystem dahintersteckt....
Ach ja, noch was. Glaub nicht, das eine Programmierung  in C leichter 
erlernbar wie Assembler ist. Ich möchte sogar fast behaupten, Assembler 
ist einfacher.
Gruß oldmax

Autor: Attila (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja! Ich habe auch den Eindruck dass assembler einfacher ist! Ich möchte 
aber jetzt den Kurs zwischen 2 Koordinaten berechnen. Und da komme ich 
nicht weiter.

Ich will NICHT wissen wie man das in assembler macht. Ich kann es mir 
vorstellen wie man es macht. Aber mein Ziel ist es Anwendungen zu 
"basteln" Und mir nicht den Kopf darüber zu zerbrechen wie man assembler 
erklärt den arkustangens zu berechnen!

Darum fragte ich hier im Forum schon mal nach einem 
"Taschenrechnermodul"

Und gäbe es eine Bibliothek aus der man solche operationen kopieren 
könnte (habe ich nicht gefunden) dann wäre auch gut.

Ein Modelboot soll ein viereck auf einem See abfahren. Da kann ich 
keinen PC draufschrauben und exel nützt mir da auch wenig. Aber:

Ein qC
Ein GPS Modul
und ein Servo
sind das Richtige

Alles läuft....bis auf die Berechnung des Kurses!

Vielleicht habe ich die Problematik so besser beschrieben?

Autor: oldmax (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi
Ja, du hast die Problematik so besser beschrieben.
>Ich habe meinen ersten etwas komplexeren Code geschrieben und würde mich
>freuen wenn ein paar Profis drüberschauen und kommentieren. Damit sich
>keine Fehler für meine "Programierzukunft" einschleichen.
Und das war der Einstiegssatz  aus deinem ersten Posting.
Warum fragst du nicht gleich nach Winkelberechnungen ?
Sorry, aber wenn du Antworten bekommst, die du NICHT willst, dann liegt 
es daran, das du eine Frage gestellt hast, auf die du scheinbar KEINE 
Antwort haben willst.
Gruß oldmax

Autor: Attila (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sorry oldmax!

Das hat sich während der Diskussion so entwickelt! Ursprünglich ging es 
tatsächlich nur um den Code aber im Rahmen der Diskussion (und es sind 
ja auch ein paar Tage vergangen) wurde die Problematik auch für mich 
wesentlich klarer. Soll ich jetzt ein neues Posting erstellen oder kann 
das auch in Diesem behandelt werden?

Autor: oldmax (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi
Bei mir brauchst du dich nicht zu entschuldigen, aber wenn du anfängst, 
Betonung in deine Sätze zu bringen, solltest du zumindest wissen, wovon 
du ursprünglich mal geredet hast. Und dazu brauchst du eigentlich nur 
deine Überschrift lesen.... Sie steht übrigends zur Erinnerung über 
jedem Beitrag. Nie nicht vergessen, das du hier Hilfe suchst. Sonst sind 
die, die es könnten, schnell weg. Übrigends, ich kann dir auch nicht 
helfen, aber habe ich mal ein solches Problem nehme ich die üblichen 
Hilfsmittel. Ja, auch diese und andere Foren sind da durchaus geeignet, 
bei angemessenem Ton.
Gruß oldmax

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.