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
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.
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
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
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
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...
"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.
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??
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.
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
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.
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 ...
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
hm also ich bezweifele das so ein Ausdruck nur fuer Anfaneger die Hölle ist :) Tobias
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
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. ;)
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.
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...
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?
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 :)
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
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. ;)
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
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
> 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.
..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 ?
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.
also ich weiß nich wie das beim avrgcc is aber bei codevision geht auch PORT.bit = 1
@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.
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.
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.
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).
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.
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
> 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.
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.
Hi, mann muss ich halt etwas an Hex gewoehnen. Da laesst sich auch one große Muehe eine Binaerzahl rauslesen.
Vielleicht sollte ich das ja diesmal an die GCC-Leute mal als Vorschlag einreichen...
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.
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. ;-)
@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.
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.
> 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.
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
> 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.
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
@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.
> 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''.
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
Du meinst sicher while(1) und for(;;). Für den Compiler macht das keinen Unterschied, beides wird zu mark: rjmp mark
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.
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. :-)
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
nicht der Compiler, sondern dessen Programmierer :-) Vielleicht liegts dann aber auch an zuwenig Feedback der User.
Ich finde Assembler super ! ( ... würde gerne auch in C programmieren können ... )
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
...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.
> ..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-Vergleich#Wie_komplex_ist_interrupt-feste_Programmierung_von_I.2FO-Ports Also: In C programmieren, aber gelegentlich mal reinsehen, was dabei rauskommt. Auch für's Debugging per JTAG sind Assembler-Kenntnisse sehr vorteilhaft.
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.
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.
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 ?
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.
...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 !
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.