www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik C oder Assembler


Autor: Josef (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Habe ewig lange mit Assembler programmiert. Ist meine Lieblingssprache.
Aber ihr bekommt null Aufträge im prof. Programmiergeschäft. Wenn du
einem Kunden sagst, du bist Assemblerprogrammierer, bist du leider ein
hoffnungsloser Steinzeitprogrammierer. Habe ich selbst erfahren. Kein
Mensch popt und pusht mehr, wenn er damit Geld verdienen will.
Der beste Assemblerprogrammmierer hat keine Chance gegen einen guten
C-Compiler (zB Codevision) bezüglich Codegröße. Diese Zeiten sind
vorbei. Sobald Fließkomma usw gefragt sind, ist's aus.
Die Portierbarkeit des Codes bei Assembler - unmöglich.

Jedes AVR C Programm läuft auch auf 8051 (nur kleine Anpassungen)
und vielen andern Prozessoren. Für Auftraggeber (Industrie)
ist das überlebenswichtig (Prozessorabkündigungen)


Josef

Autor: crazy horse (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
ist auch ne Kostenfrage.
Ein einfaches Programm ist in C in 2h erledigt, incl. Test. Kostet den
Kunden 200€, alle sind zufrieden. In Assembler würde ich dafür einen
ganzen Tag brauchen, dementsprechend mehr würde es kosten - das will
keiner bezahlen.
Klar kann man (wenn man es kann!) in Assembler mehr aus dem Proz
rausholen. Aber wann braucht man das das? Selten bis gar nicht. Wem
nutzt es, alle Routinen in 10ms erledigt zu haben, um dann 90ms zu
warten? Genausogut kann das Programm 20ms laufen, um dann nur 80ms zu
warten (völlig überspitztes Beispiel, so gross ist der Unterschied bei
weitem nicht). Für den Kunden macht das keinen Unterschied in der
Performance, für mich als Programmierer schon, und für den Kunden im
Preis natürlich.
Ich weiss, dass hier ein paar beinharte Assemblerprogrammierer
unterwegs sind, oft allerdings, weil sie mal gehört haben, nur das sei
das Wahre (und vielleicht die Kosten für einen ordentlichen Compiler
scheuen). Ich möchte mal eine Aufgabe sehen, die nur in Assembler und
nicht in C lösbar ist. C bietet ja die Möglichkeit, in besonders
zeitkritischen Situationen Assembler einzubinden, deswegen muss ich mir
nicht den ganzen Aufwand reiner Assemblerprogrammierung antun.

Autor: Josef (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gute Gedanken Crazy Horse !


Habe gemerkt, daß der Umstieg von Assembler auf C ein Beiharter ist.
Deswegen glaube ich, daß viele weiterhin in Assembler programmieren.
Habe momentan ein Betriebssystem für Spielautomaten in Arbeit das bis
jetzt ca 7000 C Zeilen hat. Würde es auch in Assembler schaffen - wenn
ich schon in Pension wäre ;-). Aber ich muß diese Programm
auch noch in 2  Jahren warten können. Das ist für mich bei meinen
eigenen, gut kommentierten Assemblerprogrammen unmöglich - ich versteh
sie einfach nicht mehr...

Schöne Grüße Josef

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Assembler ist schon nicht schlecht, man lernt vieles dabei.

Und zum Schaden ist es bestimmt nicht. Man kann dann viel besser
effizienten C-Code schreiben und wenns mal wirklich klemmt an den
kritischen Stellen Assembler includieren.


Aber ist schon richtig, der Kunde zahlt nach Stunden und da ist C
wirklich um Klassen schneller, wenn mans erstmal kann.

Man kann zwar einen C-Preis machen und dann nach Feierabend Assembler
eintippen, aber was sagt die Ehefrau dann dazu.


Also solange ihr Schüler oder Studenten seid und die Zeit dazu habt,
macht Assembler und versucht nebenbei C zu lernen.

C lernt sich auch gut, indem man sich das Assembler-Listing ansieht,
wie so ein Compiler denkt.


Peter

Autor: Stefan_h (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

Ich habe eine Zeit lang mal in Assembler rumgeschnüffelt, kleine
programme geschrieben(LED-blinken). Es hat mir einen grossen Vorteile
gebracht, denn dadurch habe ich verstanden wie ein Controller arbeitet.
Aber in C lasst sich ein Controller doch einfacher und Schneller
programmieren als in Assembler, wenn man weis wie der Hase läuft.

Alles in allem, es ist gut wenn man Assembler kann, es ist besser mit C
zu programmieren.

lg,

Stefan

Autor: crazy horse (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
da will ich jetzt nicht missverstanden sein - ich halte es fast für
unverzichtbar, als Programmierer die Assemblerprogrammiererei zu
beherrschen. Aber das heisst eben nicht, seine Programmme deswegen auch
in Assembler zu schreiben, sondern helfend eingreifen zu können, wenn
es mal mit dem Compiler klemmen sollte. Und, wie Peter schon sagte,
auch andersherum - sich die compilierten Programme anzuschauen und
daran zu sehen, wie man effizienter in C schreiben kann. Aber sich das
ganze drumherum mit Variablenverwaltung, mathematischen Funktionen,
Fliesskomma usw anzutun - das muss ich nicht haben, sinnlose
Fleissarbeit, sehr fehleranfällig. Die Fehlersuche in einem
Assemblerprogramm dauert länger als die eigentliche Programmerstellung,
und dass man seine eigenen Assemblerprogramme nach einem Jahr nicht
mehr versteht, geht sicher nicht nur mir so. Von fremden ganz
abgesehen...

Autor: René König (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"Aber ich muß diese Programm auch noch in 2  Jahren warten können. Das
ist für mich bei meinen eigenen, gut kommentierten assemblerprogrammen
unmöglich - ich versteh sie einfach nicht mehr..."

Da allerdings bin ich der Meinung, daß Du etwas grundlegendes falsch
machst. Das sollte keine Frage der verwendeten Sprache sein. Du kannst
auch in C Programme schreiben, die Du in einem halben Jahr nicht mehr
verstehst. Und genauso kannst Du Programme in Assembler schreiben, die
Du in 2 Jahren noch verstehst. IMO.

Autor: crazy horse (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das ist schon ein Problem. Assemblerinstruktionen sind nun mal nicht so
aufschlussreich. Jeder C-Befehl repräsentiert eine logische Funktion,
mit sinnvollen Variablennamen ist das schon fast selbsterklärend.
Einzelne Assemblerbefehle machen i.a. überhaupt keinen Sinn, nur in
ihrer Summe und Anordnung tun sie etwas sinnvolles, und den
Programmierer möchte ich sehen, der zu jeder Zeile wirklich sinnvolle
Kommentare schreibt (also mehr, als schon aus dem Befehl als solches
hervorgeht)
in r16, sreg
push r16  //save SREG
Auf solche Kommentare kann man gut verzichten, leider machen solche
Kommentare den Grossteil der Kommentare aus.
Dazu kommt, dass man in dem Moment, in dem man das Programm schreibt,
die Sache glasklar vor Augen liegt, man gar nicht daran denkt, was
später eine sinnvolle Erläuterung wäre. Setz doch mal ein Fragment
eines deiner Meinung nach vollständig kommentierten Codes hier rein -
ob das jeder versteht??

Autor: René König (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Selbstverständlich macht das Kommentieren in Assembler mehr Mühe, das
stelle ich gar nicht in Abrede. Nur ist das deswegen nicht unmöglich.
Und natürlich kann man auch schlecht kommentieren, wie in jeder anderen
Sprache auch. Ebenfalls wird man sich auch in Assembler Funktionen
basteln und nicht stumpf von oben nach unten programmieren.

Code werde ich nicht hier hineinsetzen. Wozu auch? Es gibt hier eine
Codesammlung. Und da gibt es jede Menge verständlichen Code, z.B. von
Peter.

Aber damit Ihr mich nicht falsch versteht: Ich hier will hier nicht auf
Biegen und Brechen für Assembler Partei ergreifen. Ich halte es
lediglich für falsch, eigene Fehler der Sprache anzulasten. Man sollte
halt seinen Stil überdenken, wenn man seinen eigenen Code schon nach
so kurzer Zeit überhaupt nicht mehr blickt. Aber offensichtlich ist das
Geschmackssache.

Autor: Tobias Schneider (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,
ich hab bis vor kurzem auch in Assembler programmiert. Doch ich hab vor
ca. nem halben Jahr mit nem Netzwerk-MP3 Player angefangen und zuerst
versucht das ding in asm zu bauen. Ich mein ich hab auch schon ein paar
komplexere Projekte als nen LED zum blinken zu bekommen in asm geloest.
Doch als es dann ans Netzwerk ging hab ich aufgegebn und angefangen
mich mit c zu beschaeftigfen. Da ich schon bissel Java konnte war das
auch kein Problem sich die neue Syntax anzugewohnen. Und ich muss sagen
es hat sich gelohn c zu lernen. Mann kann sich sehr viel mehr
aufswesetliche konzentrieren und das wofuer ich vorher Monate in asm
gebraucht hab war in ein paar Wochen in c neu implementiert. Ich kann
mir garnicht mehr richtig vorstellen wieder ganze Projekte in asm zu
coden. Trotzdem halte ich ee auch fuer wichtig auch asm zu beherschen,
da man so erst wirklich lern mit dem MC und seinen Resourcen
umzugehen.

Tobias

Autor: thkais (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nun, ich zähle mich zu den "beinharten" Assembler-Programmierern. Mir
ging es eine Zeit lang auch so, daß ich nach einiger Zeit meine eigenen
Programme nicht mehr verstand. Aber der richtige Kommentar an der
richtigen Stelle und eine ordentliche Dokumentation drumherum (was
bezwecke ich mit der Software, wie sehen die Datenstrukturen aus) lösen
dieses Problem. Ich sehe es aber so, daß eine gute Dokumentation nicht
nur bei Assembler, sondern auch bei C oder anderen Hochsprachen wichtig
ist, wenn jemand Anders auch etwas damit anfangen können soll.
Ich habe schon so einige (halbherzige) Anläufe, C zu lernen, hinter mir
- ich verstehs einfach nicht. Diese Sprache ist mir ein Greuel,
vielleicht ist es auch diese innere Einstellung, die mich von C
abschreckt. Die Frage ist: Woher kommt dieser "hype" nach C? Es gibt
wesentlich schönere Sprachen. Wenn ich ein C Programm vor mir sehe,
kommt es mir vor, als ob eine Katze willkürlich über die Tastatur
gelaufen ist. Wenn schon eine Hochsprache, dann würde mir
beispielsweise BASIC wesentlich besser gefallen.
Den einzigen Vorteil, den ich momentan in C sehe, ist die relativ
einfache Portierbarkeit auf andere Systeme. Aber wenn ich aus
zeitkritischen oder anderen Gründen Assemblerfragmente einbinde, habe
ich m.E ein wesentlich größeres Problem bei der Portierung.
Sieht man von Spezialfällen wie z.B. Fließkomma-Operationen mal ab, bin
ich der Meinung, daß man ein Assemblerprogramm fast genauso schnell wie
ein C-Programm erstellt. Hinzu kommen noch die Unwägbarkeiten, z.B. was
macht der Compiler mit meinem Code, wie setzt er ihn um, gibt es evtl.
Fehler - es scheint garnicht mal so selten zu sein, daß der Compiler
irgendwo Code anders umsetzt, als er sollte.

Autor: Ronny Schulz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
BASIC steht garnicht zur Debatte das kann man nicht vergleichen. Früher
oder später kommt man an die Grenzen bei BASIC und greift dann zu einer
vernünftigen Hochsprache, womit man auch was machen kann. Zumindest war
das früher so. Jetzt hat sich da sicher einiges getan.

Aber ich werde doch mal den WinAVR (C) ausprobieren ...

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

also der Schritt von ASM nach C viel mir sehr leicht. C hat ja auch den
Ruf nur ein hardwareunabhängiger ASM-Dialekt zu sein.

Und C ist ein Standard. BASIC ist ja im Prinzip nur ein Oberbegriff
über viele Sprachen.

Das man in C schneller und effektiver programmiert als in ASM sieht man
schon daran das es verwendet wird. Wäre es nicht effektiv würde es
nicht verwendet werden.

Allerdings sind Ausdrücke wie *(g+x+(y/8)*832)|=128>>(y%8);
für den Anfänger sicher die reinste Hölle. Obiger Ausdruck setzt
übrigens ein über x und y addresiertes Bit in einer 288x832 Pixel
großen Grafik die aber Adresse g im Speicher steht.

Matthias

Autor: Tobias Schneider (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hm also ich bezweifele das so ein Ausdruck nur fuer Anfaneger die Hölle
ist :)

Tobias

Autor: ape (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mhmm also ich für meinen Teil habe früher eigentlich nur programmiert
(also aufm PC) und zwar überwiegend mit Java ab und zu auch mal was mit
C++ (dann aber nur einfache Konsolen-programme)
Ich beschäftige mich jetzt seit ein paar Monaten mit Mikroprozessor
programmierung und hatte auch den festen Vorsatz mit asm anzufangen,
aber wie das mit den guten Vorsätzen so ist hab ich es schnell wieder
aufgegeben. Bin über das Niveau des Tutorials hier auf der Seite nicht
hinaus gekommen. Schon eine einfache bedingte Anweisung (in C if else)
hat mich immer einiges an Überlegung gekostet. Sicher is das auch
einfach eine Frage der Übung und Gewöhnung aber ich kannte halt bis
dahin nur Hochsprachen.
Daher der Umstieg auf C. Die Syntax ist ja ähnlich wie bei Java, daher
ging der Einstieg eigentlich Ruck Zuck. Dennoch befriedigt mich auch C
noch nich so wirklich. Aber richtige Objektorientierte Programmierung
lässt sich wohl auf nem AVR nich wirklich realisieren, würde aber viele
Dinge noch erheblich vereinfachen.
Mit Basic hab ich mich noch nie auseinandergesetzt, mein Instinkt sagt
mir aber das das doof is :)

ape

Autor: Ronny Schulz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe heute den Tag genutzt, um mich mal mit WinAVR
auseianderzusetzen. Ich muss sagen, dass gefällt mir sehr gut. Wenn man
alles schön kofuguriert hat, braucht man kein Ponyprog mehr. Einfach
den Editor anschmeissen, kompilieren lassen und gliech programmieren
lassen mit avrdude. Echt cool.

Die Programmierung ist an sich halt in einigen Punkten wesentlich
leichter. Gerade was Ausgaben von Strings und Umrechnungen angeht. Da
muss man nicht ewig viele Pointer laden. Parameterübergabe ist
natürlich noch besser. In ASM bleiben einem ja nur die Register oder
der Stack, wenn man das damit macht.

Ich werde jetzt mein Programm, was ich in den letzten Tagen geschrieben
habe nach C portieren und verbessern. Der Vorteil ist ja, wenn es auf
ASM läuft ist die Umsetzung voll einfach. Umgekehrt ist das etwas
komplizierter. ;)

Autor: crazy horse (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schön, wieder einer....Vielleicht muss ich mir langsam Gedanken um meine
Kundschaft machen??? Frau und 3 Kinder hängen an dem Job:-).
Den endgültigen Umstieg habe ich geschafft, als ein Projekt unbedingt
mit einem PIC realisiert werden musste, und den habe ich
assemblermässig einfach nicht auf die Reihe bekommen (noch heute hege
ich einen gewissen Argwohn gegen die Dinger, auch wenn es
offensichtlich an meiner eigenen Beschränktheit lag), mein Werdegang
Z80/8051/AVR. Der PIC passt da von seiner Struktur und Befehlssatz
irgendwie überhaupt nicht rein. Für einen nicht vorbelasteten User ist
das sicher kein Problem, aber wenn man erstmal was kennt und
beherrscht, ist man in seinen Denkstrukturen nicht mehr frei. Insofern
war der Umstieg auf eine Hochsprache fast zwangsläufig, bereut habe ich
es nie, auch wenn der Anfang manchmal steinig war. Ohne C könnte ich
die Programmierei höchstens als Hobby oder nebenberuflich betreiben,
niemals als Broterwerb.

Autor: Markus Müller (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also ich bin vielleicht eher nicht so erfahren...aber ich hab z.b. von C
(ok...mit relativ schlechten Kenntnissen) zu asm gewechselt...weil mich
der avr-gcc ein wenig angek*** hat ;)

Aber ich überleg mir grad ob ichs vielleicht doch mal wieder mit C
versuchen soll...

Autor: thkais (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also, wenn ich *(g+x+(y/8)*832)|=128>>(y%8); sehe, sehe ich mich
bestätigt. Wer zum Teufel weiß nach einem halben Jahr bei so einer
Zeile im Code, was das bedeutet?!? Dann schreib ichs in Assembler zwar
mit 20-30 Zeilen Code, aber dann kann man wenigstens ansatzweise
nachvollziehen, was da passiert.
Wenngleich ich zugeben muß, daß ich eben nicht vergleichen kann, da ich
des C nicht mächtig bin. Wenn ich als Rentner mal mehr Zeit habe, lerne
ichs vielleicht doch noch mal... g
Aber mit der Hardwareunabhängigkeit ist es doch auch nicht weit her -
wenn man spezielle Eigenheiten des Controllers berücksichtigen muß
(PWM, TWI....) hat man damit doch auch Probleme, oder sehe ich das
falsch?

Autor: ape (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich würde
*(g+x+(y/8)*832)|=128>>(y%8);
auch nich unbedingt als guten Programmierstil bezeichnen. Es mag Leute
geben die damit klar kommen und sogar welche die sowas schön und
ästhetisch finden. Aber die Nachvollziehbarkeit leidet auf jeden Fall.
Ansonsten kann man das sicher auch in C in vielleicht 3 - 4 Zeilen
schreiben wodurch es wesentlich übersichtlicher werden dürfte :)

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

*(g+x+(y/8)*832)|=128>>(y%8);
ist das schlimmst was ich selber in C verbrochen habe. Mit
entsprechendem Kommentar und Kenntnis der Operatoren kann man da aber
genausogut durchsteigen wie durch:

    17b4:  9b 01         movw  r18, r22
    17b6:  83 e0         ldi  r24, 0x03  ; 3
    17b8:  36 95         lsr  r19
    17ba:  27 95         ror  r18
    17bc:  8a 95         dec  r24
    17be:  e1 f7         brne  .-8        ; 0x17b8
    17c0:  80 e4         ldi  r24, 0x40  ; 64
    17c2:  93 e0         ldi  r25, 0x03  ; 3
    17c4:  28 9f         mul  r18, r24
    17c6:  f0 01         movw  r30, r0
    17c8:  29 9f         mul  r18, r25
    17ca:  f0 0d         add  r31, r0
    17cc:  38 9f         mul  r19, r24
    17ce:  f0 0d         add  r31, r0
    17d0:  11 24         eor  r1, r1
    17d2:  4a 0f         add  r20, r26
    17d4:  5b 1f         adc  r21, r27
    17d6:  e4 0f         add  r30, r20
    17d8:  f5 1f         adc  r31, r21
    17da:  67 70         andi  r22, 0x07  ; 7
    17dc:  70 70         andi  r23, 0x00  ; 0
    17de:  80 e8         ldi  r24, 0x80  ; 128
    17e0:  90 e0         ldi  r25, 0x00  ; 0
    17e2:  02 c0         rjmp  .+4        ; 0x17e8
    17e4:  95 95         asr  r25
    17e6:  87 95         ror  r24
    17e8:  6a 95         dec  r22
    17ea:  e2 f7         brpl  .-8        ; 0x17e4
    17ec:  20 81         ld  r18, Z
    17ee:  28 2b         or  r18, r24
    17f0:  20 83         st  Z, r18

Das macht der GCC aus obiger Codezeile.

Und hier http://www.ioccc.org/ wird das ganze ins extreme getrieben.

Ich persönlich meine das die Sprache C das struktorierte,
übersichtliche Programmieren eher unterstützt als z.B. Pascal mit
seinen begin/end Konstrukten. {/} unterscheidet sich einfach viel
besser von "normalem" Programmcode wie die Textbausteine von Pascal.
Nicht umsonst wurde dieser Syntax (also das bilden von Blöcken usw.)
für C++, C#, und Java aber auch in Scriptsprachen wie PHP übernommen.

Matthias

Autor: Ronny Schulz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
crazy horse:
Um deinen Job brauchst Du dir deshalb keine Gedanken zu machen. ;) Ich
werde sowas mehr oder weniger nur als Hobby betreiben. Dafür hätte ich
im Moment auch zu wenig Ahnung von der ganzen Sache .. bzw. brauche
einfach zu lange dafür. ;)

Autor: Jens Renner (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Ich war bis jetzt auch eher Hardcore-Assemblerprogrammierer, habe mich
aber vor ein paar Tagen mal dazu überwunden, mit avr-gcc anzufangen.
Aller Anfang ist schwer ("toolchain", "makefile", "avr-libc" ...
was geht'n!?), vor allem wenn ein gutes Tutorial fehlt, aber gestern
habe ich mein erstes kleines Projekt realisiert, und ich bin nicht
unzufrieden mit C.

Manches lässt sich in C leichter realisieren, manches in Assembler.
Vielleicht mag mal jemand einen Blick auf meinen Code zu werfen und
konstruktive Kritik üben. Es geht nicht um meinen Stil (Einrückungen,
Kommentare etc.), oder wie man ein Programm möglichst allgemein hält.

Ich weiß, dass man statt
  sbi(LCD_CTRL_OUT, LCD_CTRL_PIN_RD);
auch z.B. definieren kann:
  #define LCD_RD_HI()     sbi(LCD_CTRL_OUT, LCD_CTRL_PIN_RD)

Vielmehr geht es mir um Code-Optimierung, ich will ja etwas lernen für
kommende Projekte.
Sehr interessieren würden mich Alternativen zu meiner Funktion
lcd_delay100ms()und zur Bit-Shifterei in lcd_printbitmap(). Letzteres
konnte ich in Assembler viel kürzer lösen.
Und stört Euch bitte nicht an dem großen Array am Anfang :-)

Viele Grüße

Jens

Autor: crazy horse (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
was ist eine *.rar-Datei? Eine einfache txt sollte es doch auch tun??

Autor: Hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
nur zur info... sbi sollte man ned verwendn..hab ich irgendwo gelesn in
irgeneiner docu zum neuen gcc...

ich zähle mich zu dem kreis der eingeweihten die wissn was m$ so
insgeheim verbricht...sprich ich mach etwas reverse engeneering und da
muss man eben den x86er etwas beherrschen ...aber ich sag euch immer
wenns geht compiler anwerfn...code tippsn und dann in ne file dumpen
was da rauskommt (wie gesagt hardcore)... is zwar ned unbedingt die
feine englische aber es geht...

nur am avr kommt mir mehr oder minder kein asm rein... bis auf delays
usw..dort wo ich halbt wissn will was aber geht... ein asm
volatile("..."); und passt schon..

c kann man übrigens wie einen besseren makro assembler ansehen... ist
ja auch das gleiche..wo is also das problem ?
die eine a4-seiten syntax???
oder doch der gcc toolchain???

btw wenn man gcc einen nach makro-asm aussehenden c-source vorschmeisst
dann greifn die optimierungen am besten... hacker compiler halt G

73 de oe6jwf / hans

Autor: Jens Renner (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
> was ist eine *.rar-Datei? Eine einfache txt sollte es doch auch
> tun??

Ja, ja... es sollte halt noch der Header mit rein. Also nochmal für
diejenigen, die sich nicht mit proprietären Formaten aufhalten.

Autor: grunz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
..nur zur info... sbi sollte man ned verwendn..hab ich irgendwo
..gelesn in irgeneiner docu zum neuen gcc...

mov und ret sol man auch ned verwenden !

du kleppri fingern od du ned dteusch ? oder göbelguru ?

Autor: Jens Renner (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stimmt, das mit dem sbi() habe ich jetzt auch in der Dokumentation
gelesen, danke für den Hinweis.
Habe es jetzt mit PORT |= 1<<bit (oder PORT |= _BV(bit) ) ersetzt.
Ähnliches gilt wohl auch für inp()/outp().

Aber irgendwie ziemlich nervig, dass man so gezwungen ist, ggf.
rückwirkend alle seine Programme zu modifizieren.
Da heißt es, immer die Übersicht über alle Änderungen des Compilers zu
bewahren.

Autor: ape (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
also ich weiß nich wie das beim avrgcc is aber bei codevision geht auch
PORT.bit = 1

Autor: Joerg Wunsch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Jens:

Nein, Du bist nicht gezwungen, rückwirkend all Deine Programme zu
modifizieren.  inp/outp/sbi/cbi sind als `deprecated' markiert, das
könnte man mit ,,nicht mehr für Neuentwicklungen benutzen''
übersetzen.  Sicher, das Ziel dabei ist, daß man sie irgendwann ganz
rauswerfen kann.

Daß es diese Makros mal gab lag einfach daran, daß die direkte
Zuweisung von/zu einem Port-Makro früher im avr-gcc noch nicht
implementiert war, so daß die entsprechende Funktionalität vorerst
über diese Makros und das Hintertürchen von inline assembler
statements implementiert worden ist.  Im Zuge der Entwicklung hat aber
auch avr-gcc gelernt, mit der Methode umzugehen, die Atmel in den
Datenblättern benutzt und alle anderen AVR-C-Compiler implementieren.

@ape:

Wie dieser Konstrukt in die C-Syntax passen soll, hat mir noch niemand
erklären können.  Ich mein', es wär nichts einzuwenden, das auch im
avr-gcc zu haben, sofern es gültiges C wäre.  Aber PORT.bit (sofern
mit `bit' eine Ziffer von 0 bis 7 gemeint ist), kann nach alldem, was
ich von der C-Syntax kenne, kein gültiges C sein (weil Feldnamen
innerhalb von structs nicht mit einer Ziffer beginnen können).  Ich
kann mir auch keinen C-Präprozessor-Trick vorstellen, mit dem man dies
in gültiges C konvertieren könnte.

Autor: Jens Renner (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg, ich weiß, aus der Doku geht hervor, dass diese Makros in neuem
Code nicht mehr verwendet werden sollen. Aber teilweise (wie Du auch
erwähnst) steht ja die komplette Entfernung aus der avr-libc bevor, und
spätestens dann kommt man um Änderungen nicht herum.

Um es klarzustellen, ich kann die Gründe verstehen (dadurch wird das
ganze C-konformer und logischer), aber das kann einem schon
Stolpersteine in den Weg legen.
Anders als in Assembler muss man sich schon intensiver mit dem Compiler
beschäftigen.

Aber letztendlich ergeben sich daraus auch die Vorteile von C, so dass
es schon Spaß macht.

Autor: ape (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ja mit "bit" war eine Zahl zwischen 1 und 7 gemeint, ich hatte mich
damit auf den vorherigen Beitrag bezogen und hatte vorausgesetzt, dass
jeder Leser etwas damit anfangen kann und daher die mathematische
definition für "bit" weggelassen. (Mit "PORT" war übrigens auch ein
konkreter Port wie z.B. PORTB gemeint)

habe jedenfalls gerade mal den winavr auf meine maschine geschmissen
und ausprobiert ob der was mit PORT.bit (der genaue Code lautete
"PORTB.1 = 1;") was anfangen kann. Er kann nicht. Das bestätigt mich
jetzt darin das der Codevision einfach besser ist :) Fangt jetzt nicht
an zu heulen, weil das nich C konform is. Gerade bei der
Mikroprozessorprogrammierung brauch man sowas ziemlich oft und ich
finde diese Lösung elegant, einleuchtend und übersichtlich. Ok die
Portierbarkeit leidet darunter. Ich werds trotzdem weiter verwenden,
weil ich es hübscher finde und sollte ich irgendwann mal in die
Situation geraten, das ich all meine Programm C konform machen muss
muss ich mir halt nen kleines Prog schreiben das jede Zeile mit
PORT.bit = 1; in PORT = 0x01<<bit; umwandelt (Ich glaub nich das je
werde tun müssen).

PS: Ich kannte diese Methode auch nich und habs in nem C-Sourcecode für
nen PIC gesehen, Codevision scheint also nich de reinzige Compiler zu
sein der das unterstützt.

Autor: Ronny Schulz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe aber auch einen Nachteil, der gegen C spricht. Was mir gerade
gestern so auffiel:

Die zeitkritischen Sachen sind sehr kompliziert zu regeln bzw. schwer
nachvollziehbar. Gerade die Delays konnte man ja in ASM auf den Takt
genau berechnen. In C muss man sich erst des Debuggers bedienen und
dann die zusätzlichen Laufzeiten manuell irgendwo rausrechnen.

Mein Delay unter C habe ich jetzt mit dem 16 Bit-Timer geregelt, was
mir zwar den Timer wegnimmt aber halbwegs genau ist. Allerdings ist das
bei verschiedenen Takraten wegen dem eingeschränkten Prescaler auch
nicht so einfach. Und die Genauigkeit fängt auch erst wirklich ab 15us
zu greifen an (bei 8MHz).

Autor: crazy horse (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
auch da Einspruch, bei CodeVision gibts die delay.h, mit den Funktionen
delay_ms() und delay_us(), wird in der Projektverwaltung die richtige
Quarzfrequenz angegeben, arbeiten die ziemlich genau. Ein delay ist
nicht dazu da, 100% exakte Zeiten zu generieren (braucht man 10ms, ist
es wurscht, ob es 9,99ms oder 10,01ms). Ist ne schöne einfache Sache,
wenn man im Programm Wartezeiten benötigt. Für ein exaktes Zeitraster
braucht man sowieso einen Timer -egal ob mit asm oder C.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also ich mag Codevision nicht, da ist alles in Black-Boxen.

Deshalb gibt es da auch immer diese Fragen: 1-Wire geht nicht, LCD geht
nicht, I2C geht nicht, ADC geht nicht usw.

Beim WIN-AVR gibt es auch Bibliotheken, aber die liegen als Quelltext
vor, d.h. da kann man bei Fehlern korrigierend eingreifen, was bei den
Black-Boxen, die mitten im Compiler versteckt sind, nicht geht.

Und ich programmiere zu lange selber, als daß ich glauben kann, daß
einer wirklich 100% fehlerfreien und universellen Code schreiben kann.


Derlays mit einem Timer zu machen ist sehr elegant, da man dadurch auch
Interrupts mit berücksichtigt, d.h. die Delays werden nicht unnötig
verlängert.
Einen Timer verschwendet man dadurch aber nicht, da der ja frei
durchlaufen kann und so z.B. für Pulsweitenmessung, RTC,
Tastenentprellung usw. weiterhin zur Verfügung steht.


Das mit dem
PORT |= 1<<bit;
bzw.
PORT &= ~(1<<bit);
für SBI / CBI ist reine Gewöhnungssache, hat man schnell kapiert und
ist dann genauso gut lesbar.


Peter

Autor: Joerg Wunsch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> habe jedenfalls gerade mal den winavr auf meine maschine geschmissen
> und ausprobiert ob der was mit PORT.bit (der genaue Code lautete
> "PORTB.1 = 1;") was anfangen kann. Er kann nicht.

Das hätte ich Dir auch so sagen können.  Es ist halt kein C.  Damit
wirst Du auch die GCC-Programmierer kaum überzeugen können, daß sie
das in irgendeiner Form in den GCC einbauen.  Mehr Chancen sehe ich
noch dafür, daß vielleicht 0bXXX Binärzahlen machbar sind, hier finde
ich zumindest nichts im Standard, was gegen eine derartige Erweiterung
spricht.

Autor: Ronny Schulz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Binärzahlen fehlen mir ohnehin in C. Vieles würde übersichtlicher
wirken.

Autor: ape (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
tja codevision kanns... :)

nochmal zu der PORT.bit geschichte. verstößt das wirklich gegen die C
Syntax? Ich weiß das Felder in nem struct nich mit Zahlen beginnen
dürfen, aber ein PORTB (so als Beispiel) is ja meines Wissens kein
struct sondern nen simpler primitiver datentyp (nen char?). nun sollte
es doch für den compiler möglich sein nen struct von nem char zu
unterscheiden und bei nem struct auf das benannte element zuzugreifen
und bei nem primitiven auf das benannte bit (So denk ich mir jetzt ma
macht das auch der codevision compiler). Aber C tut sich ja sowieso
schwer mit der typenunterscheidung. Java is da viel schöner... träum.
na is auch egal.

Autor: Tobias Schneider (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,
mann muss ich halt etwas an Hex gewoehnen. Da laesst sich auch one
große Muehe eine Binaerzahl rauslesen.

Autor: Joerg Wunsch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielleicht sollte ich das ja diesmal an die GCC-Leute mal als
Vorschlag einreichen...

Autor: Joerg Wunsch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Achso:

> nochmal zu der PORT.bit geschichte. verstößt das wirklich gegen die
> C Syntax?

Ja.  Ich finde keinen syntaktischen C-Konstrukt, der das erlauben
würde.

> aber ein PORTB (so als Beispiel) is ja meines Wissens kein struct
> sondern nen simpler primitiver datentyp (nen char?)

Es ist eher ein ziemlich komplexer (Zeiger- oder was auch immer)
Ausdruck.  Schau mal in das Headerfile.  Anyway, die Frage ist ja
nicht, was es denn genau ist (das könnte man mit Präprozessortricks
ggf. zurechtbiegen), sondern daß ein Punkt in der C-Syntax nur an drei
Stellen statthaft ist: innerhalb einer Gleitkomma-Zahlenkonstante, als
Einleitung eines Feldnamens einer union oder struct, und als "..."
in
Funktionsköpfen.  (Das ist geringfügig vereinfacht, aber ausreichend
für den Zweck hier. ;-)

Da wir die Fälle "..." und Gleitkommankonstante ausschließen können,
bliebe also als einziger syntaktischer Konstrukt übrig, daß es sich um
eine struct oder union handeln müßte.  Bei diesen muß nach dem Punkt
ein `identifier' stehen.  Für einen solchen aber ist ausdrücklich
ausgeschlossen, daß er mit einer Ziffer beginnt (d. h. auch einer
compilerspezifischen Erweiterung ist dies nicht gestattet, so der
Standard).

Ergo ist ein Compiler, der den Ausdruck "foo.0" als gültiges
Sprachelement parsen kann, kein C-Compiler. ;-)

Was man sicher implementieren könnte, wäre

PORTB_0 = 1;

oder sowas, aber ich sehe keinen übermäßigen Sinn drin.

Autor: Joerg Wunsch (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hmpf, irgendwie scheint der emacs-w3m das Posten eines
Attachments zu verschrummsen. :-(

Hier also nochmal der GCC-Patch, der 0bXXX implementiert.
Getestet und für gut befunden. ;-)

Autor: ape (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ok ich geb mich geschlagen
so tief sind dann meine c kenntinsse doch nich

Autor: Schmittchen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Jörg:
Was wäre anders, wenn man PortB.PB0=1; schreiben wollte?
Dann ist dein Hauptargument mit dem Ziffern am Anfang erledigt.
War da nicht noch was mit den Strukturelementen und deren nicht
definierte Anordnung im Speicher? (hab da noch was im Hinterkopf).

Kurzum, selbst wenn PortB.PB0=1; (oder ähnlich) syntaktisch dann
erlaubt wäre, könnte man das in einen Ansi-C konformen GCC einbauen?

Selbst PortB_0=1; wäre IMHO schon eine deutliche (optische)
Vereinfachung gegenüber den Bitschieberei- oder _BV-Geschichten - und
das besonders für Anfänger.

Schmittchen.

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der MSPGCC erlaubt sowas wie port1.in.pin1. Das ist zumindest
syntaktisch gültiges C, aber theoretisch darf ein C-Compiler die
Elemente eines Bitfeldes beliebig im Speicher anordnen.

Das Problem bei solchen Konstruktionen ist dass das Programm dadurch
unportabel wird. sbi(var, bit) lässt sich auf jedem Compiler per Makro
nachrüsten, das mit den Bitfeldern wohl nicht.

Autor: Joerg Wunsch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Was wäre anders, wenn man PortB.PB0=1; schreiben wollte?

Im Prinzip gültige Syntax, aber PB0 ist als 0 definiert, und diese
Definition entspricht vor allem dem Atmel-Datenblatt.

PORTB.bit0 oder sowas wäre machbar, außer daß die derzeitigen IO
Makros das nicht hergeben.

Die Anordnung der Bits eines Bitfeldes ist nicht wirklich beliebig,
sondern die Reihenfolge ist `implementation-defined', d. h. AVR
Compiler #1 darf sich anders verhalten als AVR Compiler #2.  Ich bin
mir aber fast sicher, daß die Aufeinanderfolge selbst erhalten bleiben
muß, also ein Compiler darf von bit 0 nach 7 oder bit 7 nach 0
anordnen, aber nicht etwa das erste Bitfeld auf bit 0, das zweite auf
bit 2, das dritte auf bit 1 usw.

Autor: Hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
tjo im übrigen bin ich der meinung cpp muss her... der mega 128 hat doch
schon genug speicher für klassn ;)... ich mein...sram drann und passt
g

btw wenn ich mal irgendwo einen buchstaben "vergessn" (<-- z.b den
da) sollte liegt das daran, dass ich derzeit wieder mal "etwas" in
die mundart bzw dialekt verfallen bin....

also es gibt da einige sachen die mir nicht sehr behagen am avr-gcc...

keine c++ unterstützung in der libc ;( will mir keine klassen
compilieren
malloc wird nicht wirklich unterstützt,...

sprich ich will alles was ich am x86 auch machen kann... ist doch nur
eine frage des rams..den hab ich jetzt und jetzt würd ich ihn auch
brauchen... dann bin ich zwar mit der performance herunten auf 8051
neveau aber wenn ich will können einzelne funktionen in asm sein und
alles is wieder schön fix...

klassen wären z.b bei uarts lustig... baseclass mit funktionen und
davon abgeleitet werden dann die klassen für 90S uart, Mega uart
M128uarts,...

nur so zum beispiel...

oder mal angenommen ich hab mehrere Chips an verschiedenen pins hängen
die KEIN CS haben... auch dumm mit spagetticode....

najo soviel zu dem thema...

73 de OE6JWF / hans

Autor: Joerg Wunsch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> tjo im übrigen bin ich der meinung cpp muss her...

Ist doch dabei: der C-Präprozessor (cpp) wird jedesmal automatisch mit
aufgerufen. ;-)

> keine c++ unterstützung in der libc

Welcher AVR-Compiler außer IAR hat eigentlich C++?

> will mir keine klassen compilieren

Das stimmt so allgemein nicht.  Siehe FAQ.

Was sicher ohne libstdc++ nicht geht sind virtuelle Methoden (also
echtes OO).  Aber Klassen an sich funktionieren sehr wohl.

> malloc wird nicht wirklich unterstützt,...

Häh?

Oder meinst Du, daß new/delete nicht unterstützt werden?  (Das wäre
einfach zu beheben, denke ich.  Wo sind die Freiwilligen, die endlich
mal die Armee der avr-libc maintainer um ein kompetentes C++-Team
bereichern?)

> sprich ich will alles was ich am x86 auch machen kann... ist doch
> nur eine frage des rams.

Nein.  Manches geht schon allein durch Harvard nicht.  Außerdem fehlt
Dir (zumindest für x > 2) die MMU.

Autor: Hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hmmmmm ich glaub ich weis schon warum ich zu der annahme kam avrgcc kann
keine klassen..ich schätz ich hab da ein dummes compilerflag vergessn,
dass mir die exeptions abdreht grml

najo das müsst ich fast einmal genauer durchschaun weil ich hasse es
dauern über irgendwelche defines da herumzumuxn damit z.b meine uartlib
auf allen meinen controllern läuft... also at90s kleine megas und mega
128... is ja grausig der code..

73 de oe6jwf

Autor: Johannes (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Hans:
"dann bin ich zwar mit der performance herunten auf 8051
neveau": Wieso herunten? Die meisten aktuellen 8051er sind 2-6 mal so
schnell wie die schnellsten AVRs. Schau mal in die Datenblätter.

Autor: Joerg Wunsch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Die meisten aktuellen 8051er sind 2-6 mal so schnell wie die
> schnellsten AVRs.

Nee Du.  Kann ja sein, daß deren Takt 2-6 mal so schnell ist, aber
Standard-8051 teilt den durch 12.  Jaja, ich weiß, es gibt auch
welche, die das nicht machen und dann wirklich schneller sind, aber
die fallen keineswegs mehr unter ,,die meisten''.

Autor: Wolfgang (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hallo,
ihr jungen Hüpfer -vorzugsweise thkais-,
wenn ich lese "Wenn ich als Rentner mal mehr Zeit habe", dann muß ich
annehmen, daß der Ausspruch:
"Rentner haben niemals Zeit" noch unbekannt ist. Wer weiß, welche
Programmiersprachen es bis dahin noch alles gibt.Dann hast du aber zu
tun.
Ich bin zum Zwangsfrührenter verurteilt worden, aber Zeit habe trotzdem
nicht.
Da in dieser Runde es nur so von C- Spezies wimmelt,eine Frage, wenn
nicht zu trivial:
wann verwende ich while(1) und wann while(;;) als Endlosschleife ?
Gruß
Wolfgang

Autor: Jens Renner (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Du meinst sicher while(1) und for(;;).
Für den Compiler macht das keinen Unterschied, beides wird zu
  mark:
  rjmp mark

Autor: crazy horse (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
so isses, ich persönlich finde aber while(1){} schöner als die hässliche
for-Schleife.
Logisch ist es wurscht, nur eine Frage der (persönlichen) Ästhetik.

Autor: René König (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich verwende die Variante for, da ich schon Compiler gesehen habe, die
bei der Variante while eine Warnung wegen des konstanten Ausdrucks
schmeissen. Und Warnungen mag ich nicht.

An das Aussehen gewöhnt man sich mit der Zeit.  :-)

Autor: Wolfgang (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ihr habt recht, ich meinte for(;;)
wurde in einem Beispielprogramm für den Timer des MSP 430 angewendet,
ein Austausch mit while(1) ging bei mir nicht
danke für die Erläuterung, wobei der Grund wohl nicht so richtig zu
erklären ist
Gruß
Wolfgang

Autor: Josef (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
While produziert mehr Code.

Josef

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nur wenn der Compiler bescheuert ist.

Autor: crazy horse (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
nicht der Compiler, sondern dessen Programmierer :-)
Vielleicht liegts dann aber auch an zuwenig Feedback der User.

Autor: Alexander (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
off topic: ich hasse Assemlber und liebe C++

Autor: Josef (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
assembler ist cool !

Josef

Autor: buz11 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich finde Assembler super !

( ... würde gerne auch in C programmieren können ... )

Autor: kamil (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hi,
das erst was ich gelernt habe war C mit visual studio,
dann etwas C++ mit visual studio,
dann Java mit editor und Jbuilder.
vor nicht allzu langer zeit hab ich mit dem proggen von AVRs
angefangen.
angefangen mit codevision,
sodass ich mehr oder weniger rückwärts herausgefunden habe,
was man überhaupt für einen code braucht, damit der avr überhaupt
startet.
da ich bis dahin überhaupt garnix mit registern zu tun hatte,
war das auch nicht gerade einfach für mich.
bis jetzt weis ich auch garnix mit assembler anzufangen,
da es für mich einfach nur "sinnloses" aneinanderreihung von
buchstaben ist. liegt wohl daran, dass ich mich nie mit assembler und
der tatsächlich funktion einer CPU beschäftigt habe.
für mich ist C oder C++ ode java auf jeden fall viel sinnvoller,
denn a= b+c; ist doch einfach zu verstehen und wenn ich doch nur b mit
c addieren will,
dann hab ich eigentlich auch kein interesse irgendwelche register zu
MOV en  ;-)
das leid der hochsprache ;-)
ich würde mal sagen,
codevision ist doch ganz nett für den anfang,
ausserdem auch, wenn man zb visual studio gewöhnt ist.
einfach mal codevision ausprobieren.
grüsse

Autor: Carsten (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
...da hab ich jetzt wochenlang Assembler gelernt und muss jetzt lesen
dass das nix is ?
Ok, da es auch jede Menge C-Code-Beispiele gibt möchte ich jetzt
zumindest mal so viel C lernen um diese Codeschnipsel zu verstehen.
Wenns dann spass macht könnte ich assembler auch gerne wieder
vergessen. Irgendwie scheint mir als VB-Programmierer C etwas
sympathischer zu sein obwohl ASM extremen Reiz auf mich ausübt.
Wenn man richtig in C programmieren möchte, welchen Compiler sollte man
dann nehmen ?
Lohnt es sich einen zu kaufen oder sind die Freeware-dinger gut ?
Wenn ich wirklich auf C umsteige möchte ich eigentlich keinen der
wieder so eine selfmade-Sprache hat (siehe PORTB.0-Diskussion).
Es macht in meinen Augen keinen Sinn eine Abwandlung vom kleinsten
gemeinsamen zu lernen. Oder gibt es vielleicht gar keine Standard-C
Sprache?
Wenn ich MC's mit C Programmieren kann, hab ich dann genug C gelernt
um nachher auch, zumindest im Ansatz Windows damit zu programmieren ?
Oder ist das C wie Visual C oder Borland C wieder eine völlig andere
Sprache.

Autor: Carsten (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Welchen C-Compiler soll ich denn nun nehmen ?
Was kann man da empfehlen ?

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> ..da hab ich jetzt wochenlang Assembler gelernt und muss jetzt lesen
> dass das nix is ?

Ohne Kenntnisse in Assembler kann man so manche Stoplerfallen garnicht
erkennen. Siehe beispielsweise
http://www.mikrocontroller.net/articles/AVR_PIC_51...

Also: In C programmieren, aber gelegentlich mal reinsehen, was dabei
rauskommt. Auch für's Debugging per JTAG sind Assembler-Kenntnisse
sehr vorteilhaft.

Autor: Carsten (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Na, das ist doch was...
dann wars ja nicht vergeblich.
Ich will's ja auch nicht ganz dran geben aber C wird doch immer öfter
gefragt.

Autor: Philipp Sªsse (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Natürlich gibt es Standards für C (der Plural wirkt natürlich schon
etwas beunruhigend). Und wenn Du ANSI-C lernst, kannst Du Dich schnell
auf jedem Compiler eingewöhnen.

Aber da Du Assembler kannst, kannst Du Dir vielleicht vorstellen, warum
gerade im µC-Bereich der Standard hier und da verlassen wird. Beispiel
Ports, auf die wird bei C eigentlich über die Funktionen inportb() und
outportb() zugegriffen. Dann wird plötzlich aus einem einfachen
Assemblerbefehl, der ein Portbit setzt, ein verschachteltes Monster,
das man nur schwer lesen kann und das der arme Compiler wieder
analysieren muß, um daraus den kompakten und schnellen Bitbefehl zu
produzieren. Also behandelt der eine Compilerhersteller Portregister
wie Variablen; der andere führt Makros für Bitmanipulationen ein; der
dritte erfindet lustige Operatoren.

Und zahlreiche weitere Beispiele. Überall, wo die Architektur der
Controller den Rahmen verläßt, für den C konzipiert wurde, differieren
die Erweiterungen von einem Compiler zum nächsten.

Welchen Compiler also? Für was denn eigentlich? Welcher Controller, was
für Projekte? Mit avr-gcc zum Beispiel habe ich mich sofort zuhause
gefühlt, aber man muß bedenken, daß der Code deutlich größer ist als
bei den Profi-Werkzeugen und daß Du auf Extras wie StateCharts mit
CodeGeneration verzichten mußt, die Dir bei großen µC-Projekten
unglaublich unter die Arme greifen können.

Autor: Carsten (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok, das verstehe ich. Ist schon klar, dass ich mit Windows-C nicht PortB
ansprechen kann.
Grundsätzlich ict dieses C aber schon mit VisualC o.ä. vergleichbar.
Es geht in erster Linie um kleine AVR's (Tiny's evtl doch mal
Megas).
Was sind StateChars mit CodeGeneration ?

Autor: Philipp Sªsse (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vergleichbar: ja, natürlich. Die Struktur, die Operatoren, die
"normalen" Funktionsaufrufe: egal ob AVR oder Cray (-; .

Tinies: Achtung, achte bitte auf die unterstützten Typen. Ohne SRAM
z.B. kein gcc, wenn ich mich nicht irre.

StateCharts: bei µC-Anwendungen überlagern sich oft bestimmte Zustände:
beim Abfragen des ADC ist man gerade im Zustand "Wandlung angestoßen,
aber noch nicht fertig", die UART ist gerade am Punkt X eines
Protokolls, Taster A ist gedrückt, aber noch innerhalb der Prellzeit
und in der Benutzerinteraktion befindet man sich gerade im dritten
Untermenü. Dazu hat man jetzt noch einen Haufen Flags, die das alles
überwachen. Wenn jetzt aber die Verknüpfungen zwischen den
Zustandsebenen losgehen, verliert man trotz aller Übung leicht den
Überblick: der Tastendruck hat eine andere Bedeutung, je nachdem, in
welchem Displayzustand man gerade ist; wenn der ADC ausgelesen ist,
wird der neue Wert angezeigt, es sei denn, man ist gerade im Menü ...
wenn jetzt noch Flags zwischen Hauptprogramm und Interrupts
ausgetauscht werden, kann man durchaus übersehen, daß der Übergang von
Zustand A nach B nicht mehr definiert ist. Wer in so einem Programm
nachträglich etwas erweitert, braucht gute Nerven.
Im StateChart malst zu die Zustände auf und definierst, welches
Ereignis den Übergang von Zustand X nach Y auslöst und welcher Code
dann ausgeführt werden soll. Die ganze Entflechtung der Ereignisse,
Überwachung der Vollständigkeit und das Semaphorgedöns nimmt Dir das
Programm ab. Die CodeGeneration macht Dir aus Deinen kleinen
Codeschnipseln dann das Gesamtprogramm.
Wenn man das professionell macht, viel alten Code recyclen will,
Kundenanpassungen leisten muß, zwischen verschiedenen µCs wechselt
etc., ist das eine enorme Erleichterung.

Autor: Carsten (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
...hört sich sehr interessant an.
Nun, zum Anfang denke ich werde ich mit WinAVR wohl arbeiten.
Da kann ich wenigstens schon mal die Grundlagen lernen.
Danke für die ausführliche Erklärung !

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.