Hi,
ich bin ganz neu im Bereich Mikrocontroller... nun hab ich meine ersten
Gehversuche mit GCC-Tut gemacht, und - naja - die LED blinkt...
Nachdem ich das Tut mit Assembler angeguckt hab, und ein wenig mit GCC
gespielt, weiß ich nun gar nicht mehr, was ich wie machen solll...
Wie gesagt - erste Gehversuche mit µC...
absolut null Plan von Assembler bzw. C
Bascom noch nicht getestet - Zeitmangel
Jetzt möchte ich aber ein wenig lernen, und bin bei der Wahr der
Programmiersprache recht flexibel...
An welche Sprache sollte ich mich halten, wenn ich schon verschiedene
Projekte vorhab, und genau weiß, das eines der Projekte sehr viel
Speicher braucht (640x480 Display Ansteuerung)
Programmiert hab ich schon mit QBasic, Visual Basic, ein wenig PHP,
HTML. Mir ist schon klar, das ich mir Objektorientierten Sprachen nicht
wirklich weiterkomm...
Da ich noch keinen Plan hab von nichts, zu welcher Sprache würdet ihr
mir raten - lernen muss ich sowieso von neuem...
Gruß Blacky
der Kurs ist doch aber für 8051er... für Atmel hatte ich mich aber schon
entschieden - frat bitte nicht nach dem Grund - irgendwie gefallen mir
die Dinger am besten...
Der zweite Teil nach dem C-Kurs geht über den 8051.
Im ersten Teil geht es nur um C, da ist der Controller noch egal.
Zum Atmel gibt es hier auf Mikrocontroller.net ein gutes Tutorial.
mikrocontroller bleibt dir eigtl nur C... bzw. c++ um nen paar sachen in
oop zu kapseln. asm musste dir imao nicht antun, außer du hast sehr
zeitkritische dinge zu erledigen..
Am allerbesten ist es allerdings, wenn du zunächst den Atmel zur Seite
legst, dir ein C-Buch holst und deine ersten Gehversuche in C erst mal
auf dem PC machst.
Hol dir einen Kernighan&Ritchie und arbeite die ersten Kapitel durch.
Genau darum geht es ja - mit was bin ich besser beraten - C lernen, plus
die µC programmierung - oder gleich Assembler plus µC - oder bascom -
fast nur den µC...
Lernen muss ich sowieso - was dürfte mir - bei meinen Projekten
letztlich am besten weiterhelfen...
Hier mal eine kleine Liste von Projekten, die ich in den nächsten Jahren
realisiert haben will...
# modulare USB-Eingangskarte mit n*8 digitalen Eingängen
# Wetterstation
# Weinkeller-Klimasteuerung
# Instant-Tee Automat
# GPS-, Geschwindigkeits- und Uhrzeitanzeige fürs Auto
# Temperatursteuerung eines Serverschrankes mit
433MHz-Temperatur-FUnkmodulen
# MP3-Player in einem Cityruf
# Multimeter mit Autorange und RS232/USB Verbindung zum PC
# Netzteil mit Festspannungen und regelbarer Spannung, sowie
Verbindung/Einstellungen zum PC via USB/RS232
ohne Zeitliche Reihenfolge
Andi D. schrieb:> asm musste dir imao nicht antun, außer du hast sehr> zeitkritische dinge zu erledigen..
zeitkritisch dürfte, bis auf die Displayansteuerungen, nichts sein
Aber - wie sieht es aus, ein Programm komplett in Assembler geschrieben,
compilliert und eines in C geschrieben und kompilliert - welches ist
letztlich größer - bei welchem hab ich letztlich mehr Möglichkeiten
(Arbeit und Planung vorausgesetzt)
Assemblerkenntnisse können nie schaden! Das ist auch die einzige
Möglichkeit deinen Controller so richtig kennen zu lernen. Wenn man in C
programmiert schaut man bei kritischen Dingen oder wenn etwas nicht wie
erwartet funktioniert auch des öfteren mal in den erzeugten ASM-Code.
Mein Tip: Falls Du die Zeit und Muse hast, dann arbeite das AVR-Tutorial
gründlich durch, programmiere das ein oder andere eigene kleine Projekt
mit ASM und wende dich dann im Anschluss C zu.
Ichhab jetzt mal bei einem Bücherladen geguckt...
Dort haben die das Buch
http://www.buecher.de/shop/mikrocomputertechnik/mikrocomputertechnik-mit-controllern-der-atmel-avr-risc-familie/schmitt-guenter/products_products/detail/prod_id/23835372/
So wie es aussieht, behandelt es das, was Du gerade gesagt hast -
Assembler und danach C...
Leider hab ich auf Arbeit nur die Möglichkeit zu lesen, aber nicht zu
Programmieren... Deswegen würde ich mir gerne so ein Buch holen, auf
Arbeit ein Kapitel theoretisch lernen, zu Hause dann praktisch
nachverfolgen...
Evtl eigene Ideen gleich verwirklichen - zum testen...
Also so wie:
Buch - Wir lassen eine LED an und ausgehen - im weiteren Text soll sie
automatisch blinken...
ICH - ich lass die LED an, aus gehen und blinken, bastel noch eine
weitere dazu und lass sie abwechselnd blinken - das wäre eine
Erweiterung...
Wäre das Buch für diesen Zweck akzeptabel???
Gruß Björn
Das Buch ist nicht schlecht. Man muss sich nur dran gewöhnen, dass der
Autor dazu neigt Begriffe "einzudeutschen" :-) Zusammen mit dem
AVR-Tutorial und dem Datenblatt deines Controllers bist Du dann gut
gerüstet.
Achja, noch ganz wichtig:
http://www.atmel.com/dyn/resources/prod_documents/doc0856.pdf
Gibt es zwar auch in der Hilfe des AVR Studios, ich finde es persönlich
als PDF jedoch besser.
Was deine Ideen angeht: Genau so. Sei kreativ und arbeite dich in
kleinen Schritten vorwärts. Fange klein an und wachse mit der Zeit.
Viele machen den Fehler und nehmen sich zu Beginn viel zu viel vor. Ohne
(kleine) Erfolgserlebnisse gibt man dann schnell auf.
Chris schrieb:> Was deine Ideen angeht: Genau so. Sei kreativ und arbeite dich in> kleinen Schritten vorwärts. Fange klein an und wachse mit der Zeit.> Viele machen den Fehler und nehmen sich zu Beginn viel zu viel vor. Ohne> (kleine) Erfolgserlebnisse gibt man dann schnell auf.
Erste Idee war ein Microcompter selbst entwickeln, wurde aufgrund der
Kosten verworfen
Zweite Idee war die Weinkeller-Steuerung, danach gleich die
Wetterstation...
Dann hab ich hier mal etwas mitgelesen - und bin froh,m das ich mit dem
Tut jetzt zumindest mal zwei LEDs wechselseitig blinken lassen kann -
mit einer zufälligen Leuchtzeit der LEDs...
Erstes echtes Projekt wird dann später die n*8 Eingänge für einen Mega8
sein... irgendwann einmal... wenn ich bis dahin nicht schon die Lust
verloren habe... grins...
Ich glaub, ich bestell mir mal das Buch - eingedeutsch ist bei mir eh
besser...
Björn C. schrieb:> Ich glaub, ich bestell mir mal das Buch - eingedeutsch ist bei mir eh> besser...
Ganz schlecht ;-) Ohne das Datenblatt kommt man nicht weit und das wirst
Du nirgendwo übersetzt finden.
Ein kleines Board mit 8 digitalen Eingängen und weiteren 8 digitalen
Ausgängen über RS-232 anzusteuern ist denke ich schon als erstes Projekt
für einen Anfänger geeignet. Das könnte man dann später noch um ein paar
analoge Ein- und Ausgänge erweitern. Anfangen könnte man z.B. mit 8
Ausgängen "simuliert" mit LEDs und sich dann stückchenweise heran
tasten.
Ich wünsche dir auf jeden Fall viel Erfolg!
Quatsch... ein wenig englisch kann ich ja... grins...
(Cheese and Onions, Salt and Pepper)
ich hab so ein Breadboard, 5 Mega8 und ein bisserl Kleinkram...
und damit will ich erstmal zurecht kommen... morgen werd ich mir erstmal
das Datenblatt des Megas ausdrucken und durchlesen... vllt steig ich da
ja schon so halbwegs durch...
das mit dem Ansteuern der LEDs ist dann aber eigentlich nur Übung - das
mit den n*8 Eingängen (später auch evtl Ausgänge) müsste ich über
Schieberegister 74xx166 machen - aber bis dahin ist noch viel Zeit - und
ein Urlaub zwischendrinn... grins
Und wenn meine Lernphase I abgeschlossen ist, werd ich mir vllt sogar
das EasyAvr6 Board holen - dann hab ich weniger Stress mit dem
allgemeinen Aufbau, und kann mir ganz auf das eigentliche Problem
kondensieren...
Gruß Blacky
Chris schrieb:> Assemblerkenntnisse können nie schaden! Das ist auch die einzige> Möglichkeit deinen Controller so richtig kennen zu lernen. Wenn man in C> programmiert schaut man bei kritischen Dingen oder wenn etwas nicht wie> erwartet funktioniert auch des öfteren mal in den erzeugten ASM-Code.>> Mein Tip: Falls Du die Zeit und Muse hast, dann arbeite das AVR-Tutorial> gründlich durch, programmiere das ein oder andere eigene kleine Projekt> mit ASM und wende dich dann im Anschluss C zu.
Ich bin da genau gegenteiliger Meinung. Die zum 8051 inkompatiblen AVRs
wurden doch gerade entwickelt, um mit Hochsprachen programmiert zu
werden. Den "Controller kennenlernen" heißt aus meiner Sicht, erst
einmal nach und nach die Funktionalität der Hardware kennenzulernen.
Also welches Bit in welchem Register man setzen muss, damit die Hardware
so konfiguriert wird, wie man sie haben will. Mit welchen
Assemblerbefehlen das am Ende erreicht wird, ist doch egal.
8080/Z80, 6502, 6809 und schließlich 8051 habe ich damals noch in
Assembler programmiert. Bis ich feststellte, dass der Code des
C-Compilers (sdcc) gar nicht so viel schlechter ist als von Hand
optimierter Assembler - vielleicht 50% mehr Programmcode und 30%
langsamer. Dafür lohnt sich die Mühe in der Regel nicht, alles in
Assembler zu schreiben, denn in 99.6% der Fälle kommt es darauf einfach
nicht an.
Assembler auf AVR habe ich daher gar nicht erst mehr gelernt. Ab und zu
gucke ich schon in das Assembler-Listing, was der gcc-avr da so
"verbrochen" hat. Um das zu verstehen, muss ich aber kein Assembler
beherrschen. Ich muss grundsätzlich wissen, wie ein AVR so programmiert
wird (RISC), die Bedeutung der einzelnen Anweisungen kann ich ggf.
nachschlagen.
"Assemblerkenntnisse können nie schaden!" ist sicher genau so richtig
wie, "wenn man Auto fahren will, kann es nicht schaden, wenn man seinen
Wagen ggf. auch reparieren kann". Aber Assembler auf einem
RISC-Prozessor, wo man mit den Registern jonglieren muss, ist für einen
Anfänger eine verdammt hohe Hürde. Wir wollen doch niemanden
abschrecken, oder?
Gruß, DetlevT
Björn C. schrieb:> zeitkritisch dürfte, bis auf die Displayansteuerungen, nichts sein
An nem Display ist nur der Mensch zeitkritisch. Du mußt so langsam
darstellen, daß der Mensch es auch ablesen kann.
Der MC fällt bei Diplayausgaben eher ins Koma, weil er soviel warten
muß.
Es sein denn, Du willst ein GLCD ohne Controller ansteuern, dann hat die
CPU zu ackern mit dem ganzen Refresh.
> Aber - wie sieht es aus, ein Programm komplett in Assembler geschrieben,> compilliert und eines in C geschrieben und kompilliert - welches ist> letztlich größer
Das, wovon man weniger Ahnung hat.
Kann man beides gut, sind C-Programme etwa 5..20% größer.
Peter
Hätte hier noch einen Link zu einer Leseprobe
von MyAvr :
http://www.myavr.info/download/software/pjb_leseprobe-myavr-lehrbuch_de.pdf
Das Lehrheft ist zwar relativ teuer (49 €).
Aber ich hatte es mir letztes Jahr trotzdem
gekauft. Es hat mir schon oft geholfen, weil
einiges schön erklärt ist. Nicht nur was ASM
angeht, sondern auch zur Hardware (ADC, PWM,
RS232, Comparator usw.)
Ich schreibe zwar meine Programme in BASCOM,
für mich war es aber auch mal interessant, die
Hardware - Internas zu verstehen.
Lern C! Ich programmiere seit über 20 Jahren, auch µC und Treiber und
bin bis jetzt ohne Assembler ausgekommen. Es ist nicht schlecht, wenn
man ein wenig Assem lesen kann, aber programmieren ist heute niht mehr
nötig, da heutige C Compiler meist besseren Code erzeugen als ein
durchschnittlicher Assemblerprogrammierer produziert.
Hauptargument dürfte aber die bessere Wartbarkeit sein. Nach einem Jahr
sein eigenes Assemprogramm noch zu verstehen ist deutlich schwieriger
als be einem C Programm. Außerdem bist Du mit C eben µC unabhängig, was
nützt es Dir viel Zeit mit AVR-Assembler zu verbringen wenn Du später
vielleicht mal auf einem STM32 willst.
Gruß
Tom
P.S.: Ich werd jetz zwar gleich Schläge wie Sau von den Dinos hier im
Forum kriegen, ist mir aber egal ;-)
>Hol dir einen Kernighan&Ritchie und arbeite die ersten Kapitel durch.
Damit war doch schon alles Wesentliche gesagt.
Schmink Dir Dein 640x480 Display erst einmal ab und fange da an, wo
jeder anfangen muß: ganz unten!
Eine Stoppuhr z. B. mit einen 7-Segmentanzeige wäre ein guter Anfang.
Tastenentprellung, Timerinterrupt, bin-dez-Wandlung, I/O, Multiplexing,
....
Eben alles, was man immer wieder braucht.
Ich seh das eigentlich auch so, wie die meisten hier:
Ein wenig Assembler kann nicht schaden. Und sei es nur, um das Gefühl
dafür zu bekommen, wie die Dinge im Datenblatt zu lesen sind, wie das
mit den Registern funktioniert. Gerade Neulinge denken oft, dass da der
Compiler noch irgendwie magisch seine Finger im Spiel hat, bis sie dann
merken: Nein, dem ist nicht so; Ein Bit wird in einem Register gesetzt
und dann macht die Hardware etwas. Mit Assembler kriegt man das viel
unmittelbarer vermittelt, als wie wenn da noch eine Blackbox namens
Compiler dazwischen sitzt.
Größere Projekte als die ominöse blinkende LED würd ich dann real nicht
mehr in Assembler machen. Es gibt dann ganz einfach zu viele Details auf
die man achten muss. Wenn man darin Übung hat, ist es kein Problem, aber
ehrlich gesagt will ich mich gar nicht darum kümmern müssen, welche
Register in einer ISR auf den Stack gesichert werden müssen und welche
nicht.
Um besagten Überblick zu bekommen, reicht meiner Meinung nach das
Assembler Tutorial völlig aus. Die wichtigen und wesentlichen Sachen
sind alle drinnen, auch wenn noch einiges fehlt. Wenn man die Teile aus
dem Tutorial verstanden hat, hat man den nötigen AVR-spezifischen
Unterbau, ohne den man auch in C nicht auskommt.
Bei C gibt es 2 Problemkreise
* C an sich
* C spezifisch für AVR-Prozessoren
Den Teil 'C an sich' sollte man vorteilshalber auf einem PC hinter sich
bringen. Die Möglichkeiten des Programmschreibens, der Fehlersuche, des
Debuggings sind auf einem PC einfach viel besser. Alleine die
Möglichkeit sich Ausgaben ins Programm einzubauen, die ohne viel Aufwand
auf dem Monitor auftauchen sollte man nicht unterschätzen. Dem hat eine
leuchtende/nicht leuchtende LED als Kontrollausgabe erst mal nur wenig
entgegenzusetzen.
Das AVR-gcc-Tutorial baut auf einem gewissen Grundstock an C-Kentnissen
auf und behandlet hauptsächlich die Besonderheiten in der µC
Programmierung. Dinge die in den 'generellen C-Büchern' zu kurz kommen,
einfach deswegen, weil die Mainstream-Programmierer sie ihr Lebtag lang
nicht brauchen. Und natürlich all die Dinge, die mit der AVR Hardware
spezifisch zusammenhängen.
Daher: Zu deinem Spezial-µC Buch würde ich dir auf jeden Fall einen
Kernighan&Ritchie als C-Lehrbuch (mit der Betunung auf C) ans Herz
legen. Wir sehen hier im Forum jeden Tag unzählige Programmierer, die in
C bestenfalls über Halbwissen verfügen. Teilweise sind das richtiggehend
lachhafte Wissenslücken, die in jedem noch so grindigen C-Buch
ausführlichst behandelt werden und die nach 1 oder 2 Wochen Übungen auf
dem PC machen normalerweise sitzen. Stringverarbeitung ist da zb so ein
Thema, Parameter Passing ein anderes, Arbeiten mit Arrays, Datentypen in
Ausdrücken, etc...
>Die zum 8051 inkompatiblen AVRs wurden doch gerade entwickelt, um mit >Hochsprachen programmiert zu werden.
Falsch.
Die wurden entwickelt, um schlichweg mehr Leistung aus einem uC zu
holen. (Und wenn ein uC grässlich ist, ist er nicht nur in ASM
grässlich, sondern dadurch auch für Hochsprache (also für den
Compilerbauer) grässlich )
Und wenn man in ASM effizient progr. können soll kommt man auf DIE
SELBEN sinnvollen CPU-"Features" wie wenn man zB in C effizient progr.
können soll.
Die Angabe "für Hochsprachen entwickelt" (gabs schon bei CPUs in den
70er(!)) ist überwiegend nur Marketing-getue. (Manchmal reichen schon
billige Index-Register und ein autoinc-Befehl um dieses "für
Hochsprachen entwickelt" zu "rechtfertigen" )
>dass der Code des C-Compilers (sdcc) gar nicht so viel schlechter ist>als von Hand optimierter Assembler - vielleicht 50% mehr Programmcode>und 30% langsamer.
Das wird wohl nicht akzeptabel sein, insbes. da Speicher (nach wie vor)
Geld kostet.
>Hauptargument dürfte aber die bessere Wartbarkeit sein.
Sofern es sich überhaupt (sinnvoll) in C progr. lässt.
MCUA schrieb:>>dass der Code des C-Compilers (sdcc) gar nicht so viel schlechter ist>>als von Hand optimierter Assembler - vielleicht 50% mehr Programmcode>>und 30% langsamer.> Das wird wohl nicht akzeptabel sein, insbes. da Speicher (nach wie vor)> Geld kostet.
Was da "vergessen" wurde, sind die mindestens 200% höheren Programmier-
und Wartungskosten des "handoptimierten" Assemblercodes. Und solange es
am Ende nicht um Millionenstückzahlen geht, wird das wohl nicht
akzeptabel sein.
Oliver
>>vielleicht 50% mehr Programmcode>>und 30% langsamer.
Ich glaube, das ist übertrieben. Bei Trivialaufgaben wie LED-Blinklicht
trifft das vielleicht noch zu, weil man auf nichts Rücksicht nehmen
muss, was der Assembler-Programmierer schamlos ausnutzt, was der
C-Compiler aber nicht wissen kann.
Bei einer echten Applikation, die was Sinnvolles und Umfangreiches tut,
muss auch der ASM-Entwickler seinen Code irgendwie strukturieren, d.h.
es wird auch hier verzweigt, gepusht, gepopt und gecallt. Dadurch kommt
Overhead rein, und der ASM-Code nähert sich in der Größe dem C-Kompilat
an.
Außerdem ist ein Vergleich "Handoptimierter ASM-Code gegen C-Code ohne
Optimierung" unfair. Wenn schon, dann muss man auch gegen Compiler UND
Optimizer antreten, und der Optimizer kann richtig viel bringen, das ist
nicht nur hier und da ein Prozentchen. Beispielsweise bei der Toolchain,
die ich hier verwende (arm-gcc 4.4), hat der optimierte Code weniger als
60 % der Größe vom nichtoptimierten.
Ich dachte nicht, das ich hier SO einen Glaubenskrieg vom Ufer trete...
Aber die einhellige Meinung letztlich, die ich glaube rauslesen zu
können ist, das es besser ist, zu wissen, was Assembler ist, letztlich
jedoch auf C zu bauen. Bascom wird hier letztlich nie erwähnt...
Also werde ich mich wahrscheinlich für C entscheiden, mit den
Grundkenntnissen von Assembler... Also letztlich die beiden Tuts
nacheinander durchakkern... Mit meinem Buch...
Evtl. Probleme, die ich ohne C Kenntnisse habe, werde ich mir durch
meine VB Kenntnisse eher erarbeiten...
Mir ist schon klar, das VB und C vollkommen unterschiedlich sind, aber
ich glaube auch, das die Ideen, die ich bei VB hatte, mir weiterhelfen,
um in C nicht vollkommen daneben zu liegen.
Erdbeere schrieb:> Schmink Dir Dein 640x480 Display erst einmal ab und fange da an, wo> jeder anfangen muß: ganz unten!
Das Display kommt eh ganz zum Schluss... vorher werde ich wahrscheinlich
alles andere realisiert haben, bevor irgendwas auf dem Display
erscheint... Hatte ja auch geschrieben - ohne zeitliche Abfolge...
Gruß Björn
Björn C. schrieb:> Ich dachte nicht, das ich hier SO einen Glaubenskrieg vom Ufer trete...
ist kein Glaubenskrieg , die meisten die "C reicht" sagen habe nie
wirklich zeitkritisch programmieren müssen.
>> Aber die einhellige Meinung letztlich, die ich glaube rauslesen zu> können ist, das es besser ist, zu wissen, was Assembler ist, letztlich> jedoch auf C zu bauen.
µC spricht assembler, also wenn du die sprache wirklich beherscht gibts
gar keine probleme, sprichst du allerdings "dialekt" wird schon hin und
wieder nix funktionieren. C ist wie ein dolmetscher, wenn man schnell
genug spricht kommt der nicht mehr mit.
Wenn ich nicht anders muss, benutze ich wie die meisten auch C, weil es
ausreichend ist für 99% der anwedungen.
> Bascom wird hier letztlich nie erwähnt...
Bascom ist ein wie betrunkener dolmetscher :)
> Also werde ich mich wahrscheinlich für C entscheiden, mit den> Grundkenntnissen von Assembler... Also letztlich die beiden Tuts> nacheinander durchakkern... Mit meinem Buch...
Es gibt auch menschen die einen dolmetscher benutzen obwohl sie die
sprache selber einigermassen beherschen, daher ist deine entschedung
richtig (wenns kracht, ist es wirklich hilfreich zu verstehen was der
asm code macht)
Thomas R. schrieb:> Wenn ich nicht anders muss, benutze ich wie die meisten auch C, weil es> ausreichend ist für 99% der anwedungen.
Puh, aufatmen.
Nach deiner Einleitung dachte ich schon, das wird wieder auf ein 'C
Programmierer sind Weicheier, nur Assembler ist das einzig wahre, weil
man da auch noch den letzten Taktzyklus rausquetschen kann' - Thread
hinauslaufen.
>> Bascom wird hier letztlich nie erwähnt...>> Bascom ist ein wie betrunkener dolmetscher :)
Würd ich so nicht sagen.
Auch BASCOM hat seine Berechtigung. Allerdings würde ich jedem
empfehlen, erst mal ohne die Automatismen von BASCOM auszukommen, damit
man später auch weiß was einem BASCOM alles abnimmt und wo man dann am
BASCOM vorbei erst recht wieder auf die µC-Register zugreifen muss.
Ein Auto mit Automatikgetriebe ist super, aber in Einzelfällen geht
nichts über Gangschaltung und Kupplung.
tuppes schrieb:>>>vielleicht 50% mehr Programmcode>>>und 30% langsamer.>> Ich glaube, das ist übertrieben.
Das sollte nur eine grobe Schätzung sein und betrifft den sdcc-Compiler
für 8051 des Jahres 2000 mit einer deutlich schlechteren Optimierung als
der gcc-avr. Beim AVR habe ich keine Vergleichsmöglichkeit, weil mir da
die Erfahrung in Assembler fehlt.
Der Unterschied zwischen der Lösung in C und der in ASM hängt sehr vom
Problem ab. Bei Teilen die der C Compiler gut kann (16 Bit arthmetik,
vergleiche usw.) muß man sich in ASM schon anstrengen um so gut zu
werden wie der C Compiler mit Optimierung. Mit viel Erfahrung gibt das
dann vielleicht 5 % weniger Code / Laufzeit. Es gibt aber auch
Aufgaben, wo man in ASM spezielle features nutzen kann, wie z.B. eine
spezielle Behandlung des Carry flags oder von C nicht unterstützte
Datenformate (z.B. 24 Bit Integers). Da kann es dann sein, dass man in
ASM auch 2-5 mal schneller ist.
Längere Programme (bei mir ab etwa 2 kBytes) werden in ASM einfach
leicht unübersichtlich unübersichtlich und kaum noch wartbar.
Die Lösung ist es dann oft C wenn nötig mit ASM zu kombinieren. Also nur
den absolut nötigen Teil (wenn es denn so einen gibt) noch in ASM zu
schreiben. Allerdings ist gerade die Kombination per Inline ASM nicht
so ganz einfach - gute Kentnisse in C und ASM sind da schon die
Vorraussetzung.
Auch wenn die AVRs Risk-µCs sind, lassen sie sich ausgesprochen leicht
im ASM programieren, denn die ASM-befehle sind recht logisch aufgebaut
und übersichtlich. Wenn man unbedingt ASM lernen will sind die AVRs da
ein realtiv einfaches Ziel.
Hi,
Eigendlich ist ja schon alles gesagt und die meisten hier sind sich ja
einig. ASM Kentnisse gehören dazu wenn man sich nicht selbst
einschränken will, aber alles was ein wenig größer wird ist
normalerweise ein Fall für C, ggf. mit Inline ASM.
Ich würde vor allem jetzt einmal zwei Grundlegende Dinge machen...
Welches jetzt zuerst oder ob beide gleichzeitig sei dir überlassen wie
du meinst das es FÜR DICH am besten ist.
1. Wie schon gesagt besorge dir gute Literatur für C und übe am Rechner
die Grundlagen der C Programmierung.
2. Baue dir EINFACHE Testschaltungen auf fange mit ein wenig ASM an,
halt einfache Programme für die Basics. Aber nichts wildes.
(Wie schon geschrieben, LED blinken, Lauflicht, Ausgabe auf 7segment.
Ports einlesen und vieleicht noch so Dinge wie eine Stoppuhr und
einfaches Voltmeter) Halt alles noch übersichtlich, aber wo die
Grundfunktionen drin sind. Natürlich könnte man das auch direkt in C
schreiben, aber hier soll es ja eher um die Grundlagen gehen um zu
verstehen was überhaupt wirklich im Controller abläuft. Denn der C
Compiler übersetzt deinen Code ja schließlich auch in ASM (und dann in
den eigendlichen Programmcode der direkt aus dem ASM abgeleitet wird)
Danach würde ich dann als dritten Schritt dazu übergehen und die
einfachen Übungen noch einmal in C auf den Controller zu schreiben um
danach dann richtig mit C durchzustarten...
Deine von dir aufgezählten Projekte sind z.B. alle ein Fall für C, wenn
du die in ASM schreiben willst, dann bist du bis zur Fertigstellung alt
und grau!
GRuß
Carsten
>> Schmink Dir Dein 640x480 Display erst einmal ab und fange da an, wo> jeder anfangen muß: ganz unten!>> Eine Stoppuhr z. B. mit einen 7-Segmentanzeige wäre ein guter Anfang.> Tastenentprellung, Timerinterrupt, bin-dez-Wandlung, I/O, Multiplexing,> ....> Eben alles, was man immer wieder braucht.
Carsten Sch. schrieb:> Natürlich könnte man das auch direkt in C> schreiben, aber hier soll es ja eher um die Grundlagen gehen um zu> verstehen was überhaupt wirklich im Controller abläuft.
Erklär mir das mal. Wieso versteht man den Controller besser, wenn man
z.B. weiß, dass das setzen eines Portpins in C
1
#include<avr/io.h>
2
3
DDRB=0xff;
4
PORTB=0x03;
in Assembler so gemacht werden kann:
1
ldi r16, 0xFF ; lade Arbeitsregister r16 mit der Konstanten 0xFF
2
out DDRB, r16 ; Inhalt von r16 ins IO-Register DDRB ausgeben
3
4
ldi r16, 0x03 ; 0x03 in r16 laden
5
out PORTB, r16 ; r16 ins IO-Register PORTB ausgeben
Hier wird immer wieder behauptet, Assembler zu lernen sei die einzige
Möglichkeit, den Controller so richtig kennen zu lernen. Wichtiger ist
aber meiner Meinung nach weniger die Assemblerkenntnisse, sondern die
Kenntnisse um die Funktionen der Register eines µC. Ohne die nützen mir
Assemblerkenntnisse recht wenig.
Es wurde ja schon eingeräumt, dass bei 99% der Anwendungen Assembler
nicht notwendig sei. Wieso wird dann trotzdem einen Anfänger geraten mit
Assembler anzufangen? Fangen Anfänger immer mit dem 1% der Anwendungen
an, bei denen Assembler notwendig ist?
Oder haben etwa alle "erst Assembler" Befürworter am PC mit Assembler
angefangen, bevor sie zu einer Hochsprache übergegangen sind?
Gruß
Telekatz
Kann mich meinem vorschreiber überhaupt nicht anschliessen...
klar er hat insoweit recht, dass es wichtig ist, erstmal den uc für
welchen man programmiert zu kennen...
Doch um als totalanfänger ne grobe vorstellung zu bekommen wie so ein uc
funktiniert, ist es unabdingbar dass erstmal in assambler programmiert
wird, so wird man gezwungen sich mehr mit dem daten blatt
auseinanderzusetzen als in c... vorausgesetzt eins der primärziele
lautet die uc programmierung zu erlernen, ist dies nicht der fall, ist C
weit intelligenter, da einfacher, schneller zu erlernen, etc...
Hi
>Oder haben etwa alle "erst Assembler" Befürworter am PC mit Assembler>angefangen, bevor sie zu einer Hochsprache übergegangen sind?
Mein erstes PC-Programm war in Assembler.
MfG Spess
Mein Weg von Algol über Fortran, ein HP-Basic, Assembler bei Wang,
PASCAL bei Apple und Atari, Q-Basic, Assembler für 6809 und 68000, C
,Delphi und auch Assembler für Atmegas, hat mich bei den Atmegas zu
MikroPascal für AVR geführt.
Wenn's schnell gehen soll, dann greife ich lieber aus BASCOM (=BASIC)
zurück, als mich mit der unschönen Syntax von C abzumühen.
C mag seine Berechtigung haben, aber in einem von C dominierten Forum
erhält man eben nur solche Vorschläge und eine gewisse Hochnäsigkeit
gegenüber BASCOM.
MikroPascal erlaubt genau so das Einbinden von Assembler wie Bascom und
C.
Aus meiner Sicht ist PASCAL immer noch die eleganteste Hochsprache, und
dies auf einem Atmega, das ist doch fantastisch.
In jeder Sprache kann man große Speicher einbinden, von 24C64 bis zum
direkten Anschluss einer Festplatte. Beispiele findet man gerade dafür
überwiegend in C als auch BASCOM. Einige Assembler-Lösungen gibt es
auch. In PASCAL wird man sicher auch fündig werden, probiert hab ichs
jedoch noch nicht.
Fragt man in einem BASCOM-orienierten Forum nach einer geeigneten
Sprache, so findet man natürlich nur derartiges Lob, u.s.w.
Joe
Joe schrieb:> Wenn's schnell gehen soll, dann greife ich lieber aus BASCOM (=BASIC)> zurück, als mich mit der unschönen Syntax von C abzumühen.>> C mag seine Berechtigung haben, aber in einem von C dominierten Forum> erhält man eben nur solche Vorschläge und eine gewisse Hochnäsigkeit> gegenüber BASCOM.
Langsam:
Die Hochnäsigkeit gegenüber BASCOM rührt hauptsächlich daher, dass hier
im Forum die Erfahrung vorherrscht, dass die BASCOM Anfänger gerne
denken 'alles ist so einfach' und sich nicht mit den Möglichkeiten des
µC bzw. wie man dies erreicht auseinandersetzen.
BASCOM hat in meinen Augen einen entscheidenden Vorteil, der
gleichzeitig auch in einem gewissen Masse ein Nachteil ist. Der Vorteil
besteht darin, dass die Hardware weitestgehend vom Programmierer
ferngehalten wird. Der Nachteil besteht darin, dass diejenigen, die nur
daran gewöhnt sind in BASCOM vordefinierte Funktionalität zu benutzen,
denken, dass das so sein muss und in Sonderfällen den Schritt durch
diese Ebene hindurch direkt auf die Hardware nicht schaffen.
Zudem macht es einem BASCOM sehr einfach, Spaghetticode zu produzieren.
Hier im Forum gab es schon Fälle in denen Kontrollstrukturen
'überlappend' ineinander geschachtelt wurden, ohne das der Compiler dies
angemerkt hätte.
Der Code hat natürlich nicht funktioniert.
Du hast eine Vorbildung aufzuweisen und kannst offenbar programmieren.
Ich hege auch keine Zweifel, dass du dir im Falle eines Falles selbst
helfen kannst und direkt auf die Register durchgreifst. Aber bei den
meisten BASCOM Fragen in diesem Forum ist das keineswegs so. Teilweise
muss man auf die Leute einreden wie auf eine kranke Kuh, bis sie endlich
mal einen Blick ins Datenblatt werfen.
David schrieb:> Doch um als totalanfänger ne grobe vorstellung zu bekommen wie so ein uc> funktiniert, ist es unabdingbar dass erstmal in assambler programmiert> wird, so wird man gezwungen sich mehr mit dem daten blatt> auseinanderzusetzen als in c...
Auch wenn du in C programmierst wirst du gezwungen, dich mit dem
Datenblatt auseinanderzusetzen. C nimmt dir den richtigen Umgang mit den
Registern nicht ab.
> vorausgesetzt eins der primärziele lautet die uc programmierung zu erlernen
Wieso kann ich das nur in Assembler?
spess53 schrieb:>>Oder haben etwa alle "erst Assembler" Befürworter am PC mit Assembler>>angefangen, bevor sie zu einer Hochsprache übergegangen sind?>> Mein erstes PC-Programm war in Assembler.
Würdest du es einem Anfänger empfehlen, das auch so zu machen? Meinen
ersten µC hab ich auch in Assembler programmiert (MSC-51).
A. S. schrieb:>> Hier wird immer wieder behauptet, Assembler zu lernen sei die einzige> Möglichkeit, den Controller so richtig kennen zu lernen.
richtig, der sprich auch assembler und nicht C
assembler lernen sind zwei schritte:
- die sprache an sich lernen/verstehen
- die des jeweiligen targets lernen, egal ob das PC, µC, oder mikrowelle
ist.
> Wichtiger ist> aber meiner Meinung nach weniger die Assemblerkenntnisse, sondern die> Kenntnisse um die Funktionen der Register eines µC.
das gehört dazu, unabhängig welche sprache man benutzt, spätestens wenn
statt blinken gequalmt
> Es wurde ja schon eingeräumt, dass bei 99% der Anwendungen Assembler> nicht notwendig sei. Wieso wird dann trotzdem einen Anfänger geraten mit> Assembler anzufangen? Fangen Anfänger immer mit dem 1% der Anwendungen> an, bei denen Assembler notwendig ist?
es ist wie ABC in der grundschule.
Direkt C oder BASCOM lernen ist vergleichbar mit kleinen kindern, die
lernen auch wörter an sich, und wie man sätze zusammen baut. Denoch
beherschen die dadurch die sprache nicht wirklich. Später wird es
korrigiert in dem man sie zur schule schickt um ABC zu lernen.
Beim programmieren neigen viele den einfachen weg zu wählen, das geht
natürlich solange gut bis die anwendungen "laufen und simple bleiben".
Im laufe der jahre wird jeder programmierer auch verstehen das assembler
kenntnisse hilfreich sind und nicht schädlich.
99% der anfänger werden es genau so machen, egal ob man den sagt "lerne
erst assembler !", später wenn es qualmt werden die sich dadran erinnern
können und doch mindestens ein blick in die tuts reinwerfen.
Noch ein vergleich :
An sich wird jeder programmierer auch einen PC haben, so ist es einfach
den assembler mit command prompt und/oder linux shell zu vergleichen,
während C/Bascom nur "klicki-bunti GUI" sind.
Wer damit leben kann es nicht 100% zu verstehen was abläuft (und das ist
auch nicht wirklich immer notwendig und auch keine schande), kann auf
assembler verzichten, das muss schon jeder selber entscheiden.
>> Oder haben etwa alle "erst Assembler" Befürworter am PC mit Assembler> angefangen, bevor sie zu einer Hochsprache übergegangen sind?>
man kann wunderbare gui apps für PC in asm programmieren, ist genauso
unübersichtlich wie .net
Karl heinz Buchegger schrieb:> Teilweise> muss man auf die Leute einreden wie auf eine kranke Kuh, bis sie endlich> mal einen Blick ins Datenblatt werfen.
aber auch als Vertreter der C-Fraktion muss man zugeben, dass es auch
genügend beratungsresistente C(-Anfänger) gibt...
Hi
>Würdest du es einem Anfänger empfehlen, das auch so zu machen? Meinen>ersten µC hab ich auch in Assembler programmiert (MSC-51).
Ich habe für mich noch keine Veranlassung gesehen, µCs nicht in
Assembler zu programmieren. Und für den PC benutze ich Delphi.
Ein Anfänger sollte die verschieden Möglichkeiten einfach mal alle
testen. Für ASM, C, Pascal, Bascom und andere gibt kostenlose Software.
Einfach ausprobieren, und dann das nehmen, was einem am besten gefällt.
MfG Spess
Eigentlich existieren Assembler & C völlig gleichberechtigt.
Gerade als Anfänger, kannst Du Deine einfachen Programme, wie die
Experimente mit LEDs, Timer, Tastenabfragen oder RS232 in beiden
Sprachen ausprobieren.
Die beiden Tutorials hier auf der Seite beinhalten die gleichen Themen.
Gerade bei den Grundlagen wirst Du ziemlich schnell Fortschritte machen.
So findest Du auch heraus welche Sprache Dir eher liegt. Die Sprache
kannst Du dann intensivieren und von der andere Sprache behälst Du
wenigstens die Grundlagen. :)
Thomas R. schrieb:> es ist wie ABC in der grundschule.
Eher wie ein Autofahrer, von dem du erwartest, dass er sich seinen
Motor erst einmal komplett zusammenschraubt, bevor er damit auf der
Straße fahren darf, weil er ja nur so die Funktion jedes Einzelteils
darin kennt und im Zweifelsfall den Motor richtig bedienen kann.
Ich habe zu Zeiten von CP/M viel in Assembler programmiert, und dann
insbesondere auch Z8-Controller (die man in diesem Teil unseres Landes
dazumals noch gern "Einchipmikrorechner" nannte). Nach 10jähriger
Abstinenz von derartigen Dingen habe ich dann im Jahr 2000 mal wieder
einen "zeitgemäßen" Controller benutzen wollen und mir einen PIC
rausgekramt. 16F84 tauchte damals überall auf. Ich habe das kleine
Projekt damit fertigstellen können, aber mit einem vergleichsweise
so großen Aufwand, dass ich danach wusste, dass ich künftig meine
Controller doch eher nicht in Assembler programmieren möchte. Der
Aufwand, die ganzen kleinen Kasperfallen zu debuggen, in die man
so reintapst ("skip next instruction if bit is not set", wobei die
"next instruction" ein jump ist -- da kriegste schnell einen Knoten
im Gehirn davon) lohnt sich einfach nicht; wenn schon debuggen, dann
möchte ich mich auf das Debuggen meiner algorithmischen Fehler
konzentrieren können, nicht auf den Kleinkram. Daher sollte mein
nächster Controller einer sein, für den es einen Compiler gibt (habe
kurz JAL für den PIC angesehen, war aber ob der völlig fehlenden
Optimierung schlicht erschrocken, da wurden selbst zur Compilezeit
konstante Ausdrücke der CPU zur Berechnung aufgehalst). Da eine
Unix-Umgebung für mich Bedingung war, bot es sich an, einen Controller
zu nutzen, der sich der Unterstützung des GCC erfreut, und so bin ich
beim AVR gelandet.
Ich stimme den "du musst Assembler können!"-Rufern nur dahingehend zu,
dass es für die Programmierung eines Controllers dieser Größenklasse
zweifellos mehr als hilfreich ist, wenn man den Assemblercode dafür
lesen kann, aber selbst schreiben muss man ihn weiß Gott nicht
mehr können, um damit erfolgreich zu sein. Man muss die Hardware des
Controllers verstanden haben, um sie zu benutzen, aber wie andere
schon schrieben, ist die Ansteuerung der Hardware sehr oft eher
unabhängig von der Programmiersprache.
Ansonsten: A dedicated Real Programmer can write FORTRAN programs
in any language. ;-)
Jörg Wunsch schrieb:> Thomas R. schrieb:>> es ist wie ABC in der grundschule.>> Eher wie ein Autofahrer, von dem du erwartest, dass er sich seinen> Motor erst einmal komplett zusammenschraubt, bevor er damit auf der> Straße fahren darf, weil er ja nur so die Funktion jedes Einzelteils> darin kennt und im Zweifelsfall den Motor richtig bedienen kann.
Na ja.
So krass würde ich das nicht ausdrücken.
Wie der ADC im µC im Detail auf Gatterebene funktioniert, ist dann doch
ein wenig übertrieben.
Aber Waschwasser nachfüllen, Öl nachfüllen und Reifen wechseln sollte
man als Autofahrer dann schon können. Bei einem ausgebrannten Birnchen
scheiden sich dann die Geister. Die Assembler Programmierer können das
mit links, die C Programmierer meistens auch, die BASCOM Programmierer
(wie gesagt, nur die die wir hier so im Forum mitkriegen) schreien nach
dem Tankwart.
> Ich stimme den "du musst Assembler können!"-Rufern nur dahingehend zu,> dass es für die Programmierung eines Controllers dieser Größenklasse> zweifellos mehr als hilfreich ist, wenn man den Assemblercode dafür> lesen kann, aber selbst schreiben muss man ihn weiß Gott nicht> mehr können, um damit erfolgreich zu sein. Man muss die Hardware des> Controllers verstanden haben, um sie zu benutzen, aber wie andere> schon schrieben, ist die Ansteuerung der Hardware sehr oft eher> unabhängig von der Programmiersprache.
Full ACK.
Ich denke die Empfehlungen weiter oben laufen auch in diese Richtung:
Mach gerade soviel Assembler, damit du in etwa weißt was sich da
abspielt und wie das prinzipiell funkitioniert.
> Ansonsten: A dedicated Real Programmer can write FORTRAN programs> in any language. ;-)
Sowieso Full ACK.
Jörg Wunsch schrieb:> aber mit einem vergleichsweise> so großen Aufwand, dass ich danach wusste, dass ich künftig meine> Controller doch eher nicht in Assembler programmieren möchte.
Da hattest Du Dir aber auch ausgerechnet den Chip mit dem grausligsten
Assembler rausgesucht.
Ich hab nach der Wende den 8051 kennengelernt.
Daß der MUL und DIV hatte, gefiel mir ganz gut. Und CJNE, DJNZ war ja
fast schon Hochsprache.
Und 1993 gabs den von Atmel als schnuckeligen 20-Pinner mit Flash.
Damals mußten die PIC-Leute noch EPROM-MCs mit Löschfenster nehmen.
Peter
> .. so ist es einfach> den assembler mit command prompt und/oder linux shell zu vergleichen,> während C/Bascom nur "klicki-bunti GUI" sind.
Könnt ihr mal bitte aufhören diesen nervtötenden Begriff "klicki-bunti"
immer wieder in phrasendreschender Manier in Forum zu verwenden? Habt
ihr Torfköppe denn längst vergessen warum Apple mal auf die Idee kam
Computer für VIELE besser bedienbar zu machen, indem man sie BUNT UND
KLICKBAR gestaltet? Fragt mal eure älteren Kollegen die noch die Zeit
genau kennen, als es überhaupt keine brauchbaren GUIs gab und nur eine
DOS "Oberfläche" die nur ein Programm ausführen konnte (und vielleicht
gerade noch einen Promt). Seit doch froh, dass es klickbare Oberflächen
gibt, mit denen jede Hausfrau heutzutage zurecht kommt und die Kinners
mit klickbaren Lego Mindstorm sogar programmieren können. In der
Hochschule (Uni/FH) haben wir einst auch mit Hochsprachen wie Pascal
angefangen und nicht mit Assembler. Das hat niemandem geschadet, im
Gegenteil. Warum sollten sich Interessierte nicht auch BASCOM mal
betrachten? Wenn es ihnen nicht gefällt werden sie das schon bald
merken. Jeder wird SEINEN Weg finden. Es gibt keinen Grund immer gleich
"den Hardcore" raushängen zu lassen und alles was etwas bequemer ist zu
verdammen. Jede gut gemachte IDE hat auch was für sich. Und wenn die
Interessierten z.B. mit BASCOM an ihre Grenzen geraten, dann werden sie
schon ihren Horizont erweitern und sich Alternativen suchen, vielleicht
mit C oder Assembler. Das Leben besteht auch vielen Verästelungen und
nicht nur aus dem EINEM geraden Weg.
Peter Dannegger schrieb:> Da hattest Du Dir aber auch ausgerechnet den Chip mit dem grausligsten> Assembler rausgesucht.
Nö, das ist (war) durchaus steigerungsfähig (1802, SC/MP).
Senfdazugeber schrieb:> immer wieder in phrasendreschender Manier in Forum zu verwenden? Habt> ihr Torfköppe denn längst vergessen warum Apple mal auf die Idee kam> Computer für VIELE besser bedienbar zu machen, indem man sie BUNT UND> KLICKBAR gestaltet?
Du hast offenbar nie einen der ersten Mac unter den Fingern gehabt :-)
Ausserdem stammt die Idee gar nicht von Apple, sondern von Xerox
> Fragt mal eure älteren Kollegen die noch die Zeit> genau kennen, als es überhaupt keine brauchbaren GUIs gab und nur eine> DOS "Oberfläche" die nur ein Programm ausführen konnte (und vielleicht> gerade noch einen Promt).
Brauch ich nicht. Bin noch aus der Ära.
Viele (die meisten Dinge) gingen mit einer Command Line schneller, als
heute mit der Maus.
> Seit doch froh, dass es klickbare Oberflächen> gibt, mit denen jede Hausfrau heutzutage zurecht kommt und die Kinners> mit klickbaren Lego Mindstorm sogar programmieren können.
Ist ja ok.
Lieschen Müller soll sich an ihrer GUI erfreuen.
Aber für einen Programmierer ist es ein Armutszeugnis, wenn er beim
Anblick einer textbasierten Entwicklungsumgebung oder gar einer Command
Line W.O. gibt.
> In der> Hochschule (Uni/FH) haben wir einst auch mit Hochsprachen wie Pascal> angefangen und nicht mit Assembler.
Wir auch.
Allerdings hätten sich die Operator auch massig gefreut, wenn wir ihren
Mainframe mit ein paar unbedachten Assembler Anweisungen gecrasht
hätten.
> Es gibt keinen Grund immer gleich> "den Hardcore" raushängen zu lassen und alles was etwas bequemer ist zu> verdammen.
Tut doch auch keiner.
Aber gerade der AVR Assembler hat gegenüber C einen gewaltigen Charme:
Seine Syntax ist im Vergleich zu C trivial. D.h. Gerade als Anfänger
kann man sich mit dem AVR Assembler darauf konzentrieren seine ersten
LED ein/aus zu schalten, wei das mit binären Zahlen etc. funktioniert
ohne erst einmal einen Vortrag über main, geschwungene Klammern und wie
einem ein vergessener ; den Tag versauen kann über sich ergehen zu
lassen.
Wenn das Ziel darin besteht, möglichst schnell ein in allen Details
nachvollziehbares Erfolgserlebnis zu bescheren, ist der AVR Assembler
immer noch unübertroffen.
Karl heinz Buchegger schrieb:> Allerdings hätten sich die Operator auch massig gefreut, wenn wir ihren> Mainframe mit ein paar unbedachten Assembler Anweisungen gecrasht> hätten.
Welcher Mainframe liess sich so crashen? Auf Mainframes war Assembler
recht verbeitet. Bei 360/370 zur grossen Freude jener, die später diesen
Code mit >16MB Adressraum kombinieren wollten.
AVR-Assembler ist geradezu das Paradies der Assembler. Einfacher, klarer
und konsequenter hab ich bisher noch nicht erlebt.
Ansonsten meine Meinung: Assemblerkenntnisse sind absolute Grundlage.
Alleine schon deshalb, weil sich damit auf simpelste und verständliche
Weise Problemchen erklären lassen, die C zu verbergen weiß:
- Read-modify-write oder nicht RMW
- 'atomare' Operationen
- warum Schieben so lange dauern kann
- weshalb Datenzeiger nicht unbedingt genauso groß sind, wie
Funktionszeiger
- warum sich das eine 16-Bit-Register direkt auslesen lässt, das andere
aber nur getrennt über oberes und unteres Halbwort
- ...
AVR-ASM ist wirklich geschenkt.
Wer seinen Prozessor grundlegend verstehen möchte, und das sollte man
wollen, sobald man die eingebaute Peripherie benutzt, wird um
Bitgefrickel und ASM ohnehin schlecht drumherumkommen.
A. S. schrieb:> Oder haben etwa alle "erst Assembler" Befürworter am PC mit Assembler> angefangen, bevor sie zu einer Hochsprache übergegangen sind?
also ich habe mit Assembler angefangen (und zwar den Hexcode noch von
Hand zusammen gebastelt), dann an der Uni Mikroprogramme für einen
Bitslice-Prozessor geschrieben und ich würde heute jedem Anfänger
empfehlen:
erst C am PC lernen (mit einem schönen Debugger)
dann Aufbau des Controllers verstehen (mit Unterstützung durch
C-Tutorials)
mit Assembler kann man sich dann später beschäftigen wenn man sich
langweilt oder wirklich eine der 1% Anwendungen schreibt
Walter schrieb:> A. S. schrieb:>> Oder haben etwa alle "erst Assembler" Befürworter am PC mit Assembler>> angefangen, bevor sie zu einer Hochsprache übergegangen sind?
Es geht doch um Mikrocontroller.
Und ja, Intel-Assembler ist bekanntermaßen eine fürchterliche
Katastrophe. Den würde ich mir nicht freiwillig antun.
Sven P. schrieb:> Und ja, Intel-Assembler ist bekanntermaßen eine fürchterliche> Katastrophe. Den würde ich mir nicht freiwillig antun.
Jesses bist du sensibel ;-). Seit 386 oder ohne Segmentierung ist das
recht verträglich, jedenfalls was die Maschine angeht. Man muss ja nicht
jeden Blödsinn von Intel mitmachen, wie die typisierten Namen. Es gibt
genug andere Assembler für x86, die das machen was du hinscheibst, nicht
versuchen, allzu viel mitzudenken.
Würde ich auch machen.
Ich habe (bitte nicht ausbuhen) mit VB angefangen, habe dann in Q-BASIC
gearbeitet, dann in KBasic.
Bis ich zu der Wahrheit gefunden habe, C, seit dem programmiere ich nur
noch in C.
Dann habe ich C für uCs gelernt (hier das GCC Tut), und bin jetzt im
Moment an C++ für PC Programme (um Kontakt leichter zum uC aufbauen zu
können.) also C++ und auch noch gleichzeitig QT.
Ach ja ich empfehle es niemandem BASIC zu erlernen, denn ich habe locker
nen halbes Jahr gebraucht den Syntax aus meinem Hirn zu Streichen, das
irritiert bei proggen in C, also führt zu Fehlern.
DERLEVELER schrieb:> Ach ja ich empfehle es niemandem BASIC zu erlernen, denn ich habe locker> nen halbes Jahr gebraucht den Syntax aus meinem Hirn zu Streichen, das> irritiert bei proggen in C, also führt zu Fehlern.
Ich habe relativ früh mit der gesamte Bandbreite zu tun gehabt, die in
Reichweite war (APL, 6502-Assembler, Basic, Forth, Pascal), ohne dass
solche Effekte aufgetreten wären. Wird wohl individuell unterschiedlich
empfunden.
Joe schrieb:> C mag seine Berechtigung haben, aber in einem von C dominierten Forum> erhält man eben nur solche Vorschläge und eine gewisse Hochnäsigkeit> gegenüber BASCOM.
Es ist nicht speziell dieses Forum, das von C dominiert wird, sondern
die Mikrocontrollerwelt insgesamt. Die einzige weitere Sprache, die im
8-/16-Bit-Bereich eine nennenswerte Rolle spielt (allerdings mit
abnehmender Tendenz), ist Assembler.
Wenn hier ein Schüler, Student oder junger Ingenieur danach fragt,
welche Sprache er lernen soll, muss man davon ausgehen, dass er mit der
µC-Programmierung auch irgendwann einmal Geld verdienen möchte. Es ist
also überhaupt nicht verkehrt, erst einmal C und als Ergänzung Assembler
zu empfehlen. Das hat nichts mit Hochnäsigkeit zu tun.
Bascom ist völlig in Ordnung für jemanden, der die Mikrocontrollerei
ausschließlich als Hobby betreibt, wo selten mit anderen Entwicklern
zusammengearbeitet wird und wo es kein Problem darstellt, an eine
bestimmte µC-Familie (AVRs) gebunden zu sein.
Sehn wirs mal so:
Zu der Zeit, als Speicherplatz noch teuer war und man um jedes Byte
kämpfen musste, hatte Assembler auch seine Rechtfertigung.
Meine letzten Assembler Anwendungen waren eingebundene
Interrupt-Routinen, die in weniger als 200us ablaufen mussten, um einen
gleichzeitigen seriellen Empfang nicht zu stören. Das war weder in C,
MikroPascal noch BASCOM machbar. Da BASCOM den seriellen Datenaustausch
sehr gut unterstützt, wurden die Ass-Befehle in BASCOM bzw. in
MikroPascal integriert.
Die Arbeitsgeschwindigkeit auf der untersten Ebene ist halt unschlagbar.
Wie bereits oben schon erwähnt, ist die Syntax von C "sehr eigen".
Da lobe ich mir doch andere Sprachen, deren Syntax eine vergleichbare
Struktur aufweist. Speicherplatz ist heutezutage billig, so dass der
Speicherplatzbedarf und somit ggf. auch Assembler bei der Entscheidung
für die Sprache an Bbedeutung verlieren.
Der Anfänger möge zuerst einmal die Hardware verstehen und sich dazu
durchaus mal mit den "alten" CPU's beschäftigen. Auf dieser Grundlage
kommt er mit jeder Sprache mehr oder weniger elegant zu einem Ergebnis.
Zugegeben, C und PASCAL fordern beide eine gewisse Sauberkeit beim
Programmieren, aber auch hier können z.B. Stacks und Rücksprungadressen
manipuliert werden.
Dafür erlaubt BASCOM Sprünge in und aus Unterprogrammen, was jedem
ernsthaften Programmierer die Haare zu Berge stehen lässt. Aber man muss
es ja nicht machen.
Der direkte Zugriff auf Hardware-Register, Bits und Bytes ist wiederum
in allen Hochsprachen (natürlich erst recht in Assembler) möglich.
Ich empfehle daher einem Anfänger zu allererst das Studium der Hardware
und zum Einstieg die Sprache BASCOM. In dieser einfachen Umgebung ist
ein Herantasten an Assembler möglich.
Nach den ersten Schritten sollte man C und wenn ggf. Vorkenntnisse in
Delphi bzw. PASCAL vorhanden sind, auch mal MikroPascal ausprobieren.
In allen Varianten ein Programm zu Blinken oder Rotieren von LED's zu
schreiben bietet jedem Anfänger die Chance seine eigenen Interessen und
Fähigkeiten zu beurteilen.
Joe
Ich finde schon, dass die Methoden seither etwas verfeinert wurden. Auch
wenn Bascom noch so viel z.T. zweifelhafte Abneigung entgegenschlägt,
ist dennoch bisher noch keiner deshalb verb(r)annt worden.
Sollen sich die Leute doch fetzen wegen C vs. Bascom. Das ist auch
friedlicher als manche Fussballspiele.
Karl heinz Buchegger schrieb:> Brauch ich nicht. Bin noch aus der Ära.> Viele (die meisten Dinge) gingen mit einer Command Line schneller, als> heute mit der Maus.
Daaanke... ich komme auch noch aus dieser Zeit... und die Commandline
ist das schönste, was es gibt... Noch heute habe ich Probleme, wenn ich
in der Wondows CMD was eingeben möchte, jedoch die von Linux gewohnte
Tab-Taste nutzen will - auch einige Befehle (ls, etc) mekern jedesmal,
wenn ich sie versuche auszuführen...
DERLEVELER schrieb:> Ach ja ich empfehle es niemandem BASIC zu erlernen, denn ich habe locker> nen halbes Jahr gebraucht den Syntax aus meinem Hirn zu Streichen, das> irritiert bei proggen in C, also führt zu Fehlern.
nochmal Daaaanke... ich kann - wenn auch nicht wirklich supergut, VB...
aber ich bekomme es noch immer hin, Programme zu schreiben, die das
machen, was ich will...
Yalu X. schrieb:> Wenn hier ein Schüler, Student oder junger Ingenieur danach fragt,> welche Sprache er lernen soll, muss man davon ausgehen, dass er mit der> µC-Programmierung auch irgendwann einmal Geld verdienen möchte. Es ist> also überhaupt nicht verkehrt, erst einmal C und als Ergänzung Assembler> zu empfehlen. Das hat nichts mit Hochnäsigkeit zu tun.
und ein drittes mal Daaaanke... ich bin weder Schüler, Student noch
Ing... ich bin dummer Heizer auf Schicht, der einem Bekannten etwas
versprochen hat (Weinkeller-Klimasteuerung). Und nun muss ich mich dem
Verbrechen - ähm, Versprechen stellen...
Ich wusste nicht, das diese Frage zu so einer Diskussion führt - ok, ich
für mich hatte Bascom schon ausgeschlossen, aber eher wegen der meiner
Meinung nach nicht optimalen Übersetzung - irgendwo las ich, das Bascom
für ein einfaches Programm viel mehr Speicher braucht als es C oder
Assembler tun... Deswegen schloss ich es aus...
Da ich keine Ahnung habe, wieviel ich mit meinen 8k Speicher in einem
Mega machen kann, möchte ich mir von vorne herein alles offen halten,
und nicht nach 1 Jahr Bascom wieder was anderes lernen... ok - Assembler
dürfte nur für 1% der möglichen Anwendungen in Frage kommen, C für 99% -
an Pascal hab ich überhaupt nicht gedacht...
Ich suche halt für mich eine Sprache, ich ich mit meinen, oben
geschriebenen Kenntnissen, relativ leicht erlernen kann, sehr weit damit
komme, nicht wegen der Sprache selbst nen anderen Controller nehmen
muss, weil der HEX-Code zu groß geworden ist und die
Geschwindigkeitstechnisch auch noch in Ordnung ist...
Das diese Frage in einem C-geprägten Forum letztlich in eine bestimmte
Richtung geht, das wusste ich nun nicht - bzw. ich wusste nicht mal, das
der Anteil der C-Programmierer hier soooo extrem hoch ist...
Deswegen nun eine etwas andere Frage:
Da ich schon recht intensiv mit VB und PHP geaschafft habe - welche
Sprache dürfte für mich einfacher zu erlernen sein, C oder Assembler???
letztlich denke ich, wird es auf eine dieser SPrachen hinauslaufen - und
wenn ich Assembler beherrsche, dann brauche ich letztlich kein C mehr...
So denke ich...
Hi,
A. S. schrieb:> Carsten Sch. schrieb:>> Natürlich könnte man das auch direkt in C>> schreiben, aber hier soll es ja eher um die Grundlagen gehen um zu>> verstehen was überhaupt wirklich im Controller abläuft.>> Erklär mir das mal. Wieso versteht man den Controller besser, wenn man> z.B. weiß, dass das setzen eines Portpins in C>
1
>#include<avr/io.h>
2
>
3
>DDRB=0xff;
4
>PORTB=0x03;
5
>
> in Assembler so gemacht werden kann:>
1
> ldi r16, 0xFF ; lade Arbeitsregister r16 mit der Konstanten 0xFF
2
> out DDRB, r16 ; Inhalt von r16 ins IO-Register DDRB ausgeben
3
>
4
> ldi r16, 0x03 ; 0x03 in r16 laden
5
> out PORTB, r16 ; r16 ins IO-Register PORTB ausgeben
6
>
>
Also zumindest im zweiten Beispiel sieht man die Arbeitsweise des
Controllers ja ganz deutlich... Jeder Operand geht durch das W
Register...
Dazu noch einige hier nicht gezeigte Funktionsweisen wie das die I/O
Ports ebend auch Register sind, wie ein µC Rechnet, davon abgesehen habe
ich das Prinzip der indirekten Adressierung überhaupt erst beim Arbeiten
mit dem µC verstanden... (Kann aber auch am Alter gelegen haben, C habe
ich ´93 mit 14 begonnen, µC kam dann ab ´97 mit 16F84 natürlich mangels
Tools mit ASM)
Davon abgesehen: Was ist denn wohl für einen völligen Neueinsteiger
leichter? Eine LED mit ASM oder eine mit C blinken lassen...?
Bei C habe ich nun einmal auch im C Code einen Overhead durch die ganzen
Includes, Defines, muss mich an den Syntax mit der Main{ } gewöhnen.
Klar, in einem aufwendigen Projekt spielt das keine Rolle, aber in einem
4 Zeilen Code schon! (Der BWL´er würde jetzt mit Break even Point
anfangen ;-)
Meine Güte, es redet hier doch keiner mehr davon das er ein perfekter
ASM Programmierer werden soll und jeden Kniff kennen muss. Es geht um
einige rudimentärste Übungen die wenn jemand bereits in irgendeiner
Sprache was geschrieben hat (und auch verstanden hat was er da macht) in
einem einzigen Wochenende abgehakt sind. Ein wenig Bit Banging halt!
Dann aber soll er doch schon mit C anfangen, zuerst einmal schauen was
beim C Compiler anders ist, sich dran gewöhnen wie das für den µC
umgesetzt wird und dann beginnen sich zu steigern bis er die vollen
Fähigkeiten der Programmierung in C für den Controller ausreizen kann!
Wobei wie gesagt die allerersten C Schritte besser auf dem PC gemacht
werden!
Zum Thema BASCOM o.ä.:
Sicher hat Bascom seine Berechtigung. ICh kenne auch einige wirklich
Tolle in Bascom geschriebene Projekte. Nur wenn jemand generell in die
µC Welt eintauchen will um etwas zu lernen und nicht aus mittel zu Zweck
um schnell Funktionelle Ergebnisse halte ich Bascom als Einstiegssprache
für weniger geeignet. Die µC Welt spricht mittlerweile C. Daneben noch
ASM in vielen Dialekten mit geringer werdender Bedeutung. Bascom o.ä.
sind da Sonderfälle mit den man sich durchaus beschäftigen kann wenn
diese einem für das aktuelle Projet vorteile gegenüber C bringen, keine
Frage.
Aber da diese alles andere als allgemein sind und damit überhaupt nur
für AVR und 8051 überhaupt verfügbar als genereller "Lerneinstieg", nur
weil es zufällig auf dem ersten verwendeten µC läuft, keinesfalls Ideal.
Sobald man dann die Familie wechselt (wechseln muss?) darf man dann
sonst ganz von vorne beginnen!
Gruß
Carsten
Björn C. schrieb:> wenn ich Assembler beherrsche, dann brauche ich letztlich kein C mehr...
Nö. Es mag ein paar Extremisten dieser Richtung geben, aber ich kann
dieser Philosophie nicht folgen und halte es eher wie Wirth: jedem
Problem seine angemessene Sprache. Womit ich allerdings nicht wie dieser
sie jedesmal neu erfinden will. Obwohl das auch schon vorkam.
Björn C. schrieb:> Noch heute habe ich Probleme, wenn ich> in der Wondows CMD was eingeben möchte, jedoch die von Linux gewohnte> Tab-Taste nutzen will
Geht, du musst dazu irgendwo in der Registry herumpopeln und das
completion character von 40H auf 09H stellen, habe die Details
vergessen, aber das wirst du irgendwo finden. Die completion selbst
funktioniert etwas anders als unter Unix (es werden mit jeden Drücken
der TAB-Taste alle auf den getippten Anfang passenden Erweiterungen
zyklisch durchgegangen), aber ist auf jeden Fall besser als gar keine.
Jörg Wunsch schrieb:> Geht, du musst dazu irgendwo in der Registry herumpopeln und das
geht nicht so einfach...
privat nutze ich die CMD sehr selten, im Betrieb muss ich schon eher
ran... aber auf den Rechnern kann ich nicht einfach in die Registry -
ist alles geschützt...
nach wenigen Minuten hab ich mich auch wieder dran gewöhnt, und mache es
richtig... wenn ich dann wieder zu Hause bin, erstmal nen SSH-Login auf
den Server und wieder ein wenig gespielt, nur um zu wissen, das ich doch
nicht so doof bin... Egostreichel
Björn C. schrieb:> aber auf den Rechnern kann ich nicht einfach in die Registry -> ist alles geschützt...
Naja, vielleicht kannst du ja die entsprechende Einstellung mal
irgendwo im betrieblichen Prozess einkippen? Die stört ja sonst
niemanden, da sie ja ganz klar nur auf die Kommandoeingabe von
cmd.exe wirkt.
nicht bei einem der drei größten Chemieunternehmen der Welt - da brauch
ich für den Vorschlag schon eine Vorlaufzeit von mindestens drei Jahren
- in vierfacher Ausfertigung... und letztlich kommt eh ein Abgelehnt
raus, weil das nur mir was bringt, und ich eigentlich nicht so tief in
der Materie rumwurschteln darf...
Joe schrieb:> Dafür erlaubt BASCOM Sprünge in und aus Unterprogrammen, was jedem> ernsthaften Programmierer die Haare zu Berge stehen lässt.
Das kannst Du in C aber auch (setjmp.h).
Aber es macht eben (fast) keiner, weil der Code dadurch unlesbarer wird
und damit fehlerträchtiger.
Peter
Also mein Einstieg ist ca. ein dreiviertel Jahr her. Ich hab mich recht
schnell für ASM entschieden, einfach weils mir sympathischer war. Ich
hab mir dann oft gedacht, eigentlich wärs in C bestimmt übersichtlicher.
Aber zum Umstieg konnt ich mich nie so recht überwinden. Seitdem sind
auch schon ein paar aufwändigere Projekte entstanden (ist natürlich
immer subjektiv). Bis jetzt waren nachträglich Änderungen nie ein großes
Problem.
Was ich allerdings schnell festgestellt hab: mind. 80% der Zeit gehen
fürs Konzepte ausdenken drauf und fürs Denkfehler debuggen. Obs jetzt
Assembler oder C oder Bascom ist, macht da eigentlich keinen
Unterschied. Bei Bascom hab ich allerdings die Befürchtung, dass mich
das oft ziemlich stark einschränken würde und das Konzepte-Ausdenken
eher noch aufwändiger wird. Ob das stimmt, werd ich vermutlich aber nie
rausfinden.
Ich hatte mir die beiden Tuts mal grob überflogen - und mein erster
Eindruck war auch, das Assembler mir irgendwie sympatischer ist...
Aber so richtig entscheiden knn ich mich immer noch nicht...
Es hat doch schon einer geschrieben, du solltest alles mal an einem
kleinen Programm probieren.
Ob Blinken, Lauflicht oder auch LCD-Ausgabe sind da geeignete Objekte.
Ich schlage dir die Reihenfolge Bascom, Pascal, C und dann Assembler
vor.
Dabei vereinfacht dir die vorherige Sprache jeweils den Einstieg in die
folgende Sprache.
Welche Sprachen kannst du den schon ?
B.
Können - nun ja, VB kann ich problemlos was auf die Beine stellen,
einfachere Projekt mit PHP sollten auch kein Problem darstellen...
Mehr hab ich noch nicht testen können...
Bernadette schrieb:> Ob Blinken, Lauflicht oder auch LCD-Ausgabe sind da geeignete Objekte.> Ich schlage dir die Reihenfolge Bascom, Pascal, C und dann Assembler> vor.>> Dabei vereinfacht dir die vorherige Sprache jeweils den Einstieg in die> folgende Sprache.
Und in 10 Jahren ist schon bei Assembler angekommen...
Assembler :
Naja, man sollte es lesen und interpretieren können um beim debugging zu
wissen was da gerade passiert.
Es gibt je nach µC einige Low level Funktionalitäten die nur mit
Assembler machbar sind. zb startup code.
Aber für alles andere gehört da eine Sprache hin die man auch später
noch lesen kann.
Wenn in einer Interrupttroutine auf jeden Taktzyklus geachtet werden
muss, ist von Projektbeginn schon einiges falsch gelaufen.
1. Das Design war falsch und damit die benötigte Bearbeitungszeit
grundlegend falsch kalkuliert.
2. der µC schlicht uns einfach zu schwach / klein ausgewählt ==> für die
gestellte Aufgabe ungeeigneter µC.
Beliebige Hochsprache mit für den ausgewählten µC vorhandenem Compiler:
Wird in der Regel C sein, ist im Endeffekt allerdings egal.
Der Compiler in Verbindung mit dem Optimizer wird einen schnelleren und
kleineren Assemblercode produzieren als mindestens 90% aller
selbsternannten Assembler Gurus.
Vor allem "denkt" der Compiler an die vielen Fallstricke im Assembler,
wie zb welches Register zu welcher Zeit wohin gerettet und zurückgeholt
werden muss. Und diese schematischen Umsetzungen macht der Compiler bei
jedem Befehl korrekt, das schafft kein Mensch.
Ein Projekt das mal die 1K Codegröße übersteigt wird keine Firma die
wirtschaftlich denken muss in Assembler machen. Die Entwicklungs und
Wartungs kosten sind einfach viel zu hoch.
Man kann ja mal vergleichen. Klassisches C (also nicht Kindergarten-C,
sondern übliches, idiomatisches) gegen Assembler.
Ein schneller Rechteckgenerator:
1
.include "m8def.inc"
2
3
sbi DDRA, DDA0
4
5
loop:
6
sbi PORTA, PA0
7
cbi PORTA, PA0
8
jrmp loop
1
#include<avr/io.h>
2
3
intmain(void){
4
DDRA|=_BV(DDA0);
5
6
for(;;){
7
PORTA|=_BV(PA0);
8
PORTA&=~_BV(PA0);
9
}
10
}
Was ist jetzt einsteigerfreundlicher? Und da ist der Aufruf von
Übersetzer und Binder und die Zerlegung in Segmente noch nicht mit
dabei.
Größerer Projekte setzt man praktisch nicht mehr in C an. Das mach ich
als Hobby noch, weil ich den ASM mag.
Ralph schrieb:> Wenn in einer Interrupttroutine auf jeden Taktzyklus geachtet werden> muss, ist von Projektbeginn schon einiges falsch gelaufen.
Seh ich nicht ganz so krass. Man kann sich durchaus ein Projekt
entwerfen, bei dem es von vornherei klar ist, dass eine der ISRs
tatsächlich so häufig aufgerufen wird, aber andererseits so wenig
zu tun hat, dass man die paar Zeilen in Assembler schreibt. Wenn
es nur ein paar Zeilen sind, bleibt deren Code ja trotzdem noch
überschaubar, und man kann die teilweise nicht so gut optimierten
Formalismen des Compilers (wie bspw. ein AVR-GCC, der schematisch
erstmal immer das SREG sichern will und dafür noch vorher andere
Register sichert) vermeiden. Dafür muss man dann noch nicht
unbedingt zum schnelleren Prozessor greifen.
Ansonsten aber Zustimmung.
> Ein Projekt das mal die 1K Codegröße übersteigt wird keine Firma die> wirtschaftlich denken muss in Assembler machen.
Hängt davon ab, wie groß die Produktionsstückzahl ist. Wenn man für
ein Millionenprojekt den nächstkleineren Prozessor damit benutzen
kann, kann es sich lohnen. Für Einzelstücke oder Kleinserien wird
es sich dagegen in der Tat nicht lohnen.
Sven P. schrieb:> Was ist jetzt einsteigerfreundlicher?
Wenn man die Bitoperatoren von C nie verstanden hat, wird man wohl
den Assemblercode (dieses ansonsten ja eher pathologischen Falls)
besser verstehen, denn man muss nur in der Befehlsreferenz
nachlesen, was CBI und SBI machen.
Wenn man die Bitoperatoren von C einmal verstanden hat, ist der
C-Code besser zu verstehen, denn für dessen Verständnis muss man
dann die Befehlsreferenz des verwendeten Prozessors nicht noch
zusätzlich rauskramen.
Bei Assembler die Befehle zu kennen, ist aus meiner Sicht das gleiche
wie beim Schach die erlaubten Züge zu kennen. Das Spiel beherrscht man
deswegen noch lange nicht. Man muss wissen, wie man gewisse Dinge
umsetzt.
Da gab es jetzt gerade hier einen Thread, den ich auf die schnelle
leider nicht wieder finde. Da will jemand eine Konstante zu einer
16-Bit-Zahl addieren und einen möglichen Überlauf abfangen. Das ist
sicher etwas, was sich viel effizienter in ASM als C lösen lässt, weil
man da das Carry-Flag direkt ausnutzen kann.
ABER: Es gibt keinen Assembler-Befehl "Konstante addieren". Es gibt nur
einen Assembler-Befehl "Konstante subtrahieren". Damit kann man das auch
machen, indem man das Zweierkomplement der Konstante (also quasi minus
Konstante) abzieht. Aber dann reagiert das Carry-Flag auch genau
invertiert zu einer Situation, die man schon kennt und wo man Register
zueinander addiert hätte. Man braucht also genau den anderen
Verzweigungsbefehl. Aus Sicht des AVR-Designers ist es konsequent,
keinen addi Befehl zu implementieren, wenn man mit dem subi auch alles
genauso gut machen kann, aber so mancher bekommt da halt auch einen
Knoten in seinen Gedankenfaden. Das kostet Zeit, das macht Frust.
Wie beim Schach legt man sich dann mit der Zeit im Kopf eine Bibliothek
von Standard-Zügen an, auf die man bei bekannten Situationen zurück
greifen kann. Und dann kann man sicher auch größere Projekte mit ASM
umsetzen. Aber einem Einsteiger kann ich nur davon abraten, weil der
Einstiegsfrust viel zu groß ist.
Gruß, DetlevT
Hi
>Bei Assembler die Befehle zu kennen, ist aus meiner Sicht das gleiche>wie beim Schach die erlaubten Züge zu kennen. Das Spiel beherrscht man>deswegen noch lange nicht. Man muss wissen, wie man gewisse Dinge>umsetzt.
Das trifft ja wohl auf jede Programmiersprache zu.
MfG Spess
Sven P. schrieb:> Ein schneller Rechteckgenerator:.include "m8def.inc"> <snipp>> Was ist jetzt einsteigerfreundlicher?
Was die oben genannte Aussage: "Die passende Programmiersprache für den
passenden Zweck" bestätigt.
Wenn das Projekt aus nicht mehr als einer blinkenden LED besteht, ist
Assembler wunderbar geeignet.
Wenn das aber mal ein erstzunehmender Rechteckgenerator werden soll, mit
LCD, Drehgebereingabe, ein paar Tasten, und Menus, liegt der Anteil des
assemblerfreundlichen hardwarenahen Bitgeschubses am Gessamtprogramm
zeilenmäßig unter 1 Promille. Wer unbedingt will (und die 20-30 Zeilen
nicht in C auf die Reihe kriegt), darf das dann immer noch in Assembler
machen.
Der Rest ist Statemachine, Menugestaltung, Eingabebereichüberprüfung,
Stringverarbeitung, und so weiter. Dafür werden seit mehr als 60 Jahren
höhere Programmiersprachen erfunden. Warum nur?
Oliver
Hi
>Wenn das aber mal ein erstzunehmender Rechteckgenerator werden soll, mit>LCD, Drehgebereingabe, ein paar Tasten, und Menus...
Wen willst du denn mit so einer Fingerübung erschrecken. Davon hat man,
wenn man es schon eine Weile macht, dreiviertel in der Schublade.
Scrollbare, verschachtelte Menüs auf Grafikdisplays mit Touch habe ich
beispielsweise schon vor 10 Jahren realisiert.
MfG Spess
spess53 schrieb:> Scrollbare, verschachtelte Menüs auf Grafikdisplays mit Touch habe ich> beispielsweise schon vor 10 Jahren realisiert.
In Assembler?
Oliver
spess53 schrieb:> Und was auch so geht:>> Beitrag "Re: Zeigt her Eure Kunstwerke !"
Ich zitiere mal die allererste Antwort darauf:
Colt Fish schrieb:>> Software komplett in Assembler.> Masochist!>> Respekt, sieht gut aus!
Der Meinung schließe ich mich uneingeschränt an.
Oliver
Jaaaaa!
Streitet Euch ruhig um die Seele des armen Anfängers.
Redet Euch ruhig Euere Fähigkeiten und Euer Wissen gegenseitig schlecht.
Wetzt Eure Waffen!!! Schmiedet Eure Pointer und jumpListen!!!
Der Tag des Armagedon ist nah! In dieser heiligen Schlacht wird
entschieden ob die einzig wahre Sprache für den MikroController C oder
Assembler ist.
Die Sieger werden als wahre Herscher der Welt in den Olymp einziehen und
für alle Ewigkeiten in Ruhm, Reichtum und Glück leben.
Aber wehe dem Verlierer! Schande und Trotzlosigkeit wird Euer Schicksal
sein.
Thomas R. schrieb:> Direkt C oder BASCOM lernen ist vergleichbar mit kleinen kindern, die> lernen auch wörter an sich, und wie man sätze zusammen baut. Denoch> beherschen die dadurch die sprache nicht wirklich. Später wird es> korrigiert in dem man sie zur schule schickt um ABC zu lernen.
Du würdest dein Kind also zuerst zur Schule schicken, damit es das ABC
lernt, und ihm dann erst das Sprechen beibringen.
Analogien sind wie holzbeinige Piraten. Sie hinken oft.
spess53 schrieb:>>Wenn das aber mal ein erstzunehmender Rechteckgenerator werden soll, mit>>LCD, Drehgebereingabe, ein paar Tasten, und Menus...>> Wen willst du denn mit so einer Fingerübung erschrecken. Davon hat man,> wenn man es schon eine Weile macht, dreiviertel in der Schublade.> Scrollbare, verschachtelte Menüs auf Grafikdisplays mit Touch habe ich> beispielsweise schon vor 10 Jahren realisiert.
Und was ist bei einem Wechsel der Prozessorarchitektur? Bei einem
Wechsel von AVR nach ARM kann ich den Assemblercode wegwerfen und neu
anfangen. C Code kann großteils wiederverwendet werden. Nur der Hardware
Layer ist neu zu erstellen.
Ich meine ja nicht, dass Assemblerkenntnisse unwichtig sind. Aber bei
den Projekten, die der Threadersteller realisieren möchte, ist C oder
auch BASCOM ein Weg der vermutlich schneller zum Ziel führt. Da ist kein
Blinklicht oder schneller Rechteckgenerator dabei. Später, wenn er sich
mit dem µC besser auskennt, kann er sich ja immer noch mal Assembler
anschauen (so er es denn brauchen kann).
Gruß
Telekatz
spess53 schrieb:> Hi>>>Wenn das aber mal ein erstzunehmender Rechteckgenerator werden soll, mit>>LCD, Drehgebereingabe, ein paar Tasten, und Menus...>> Wen willst du denn mit so einer Fingerübung erschrecken. Davon hat man,> wenn man es schon eine Weile macht, dreiviertel in der Schublade.> Scrollbare, verschachtelte Menüs auf Grafikdisplays mit Touch habe ich> beispielsweise schon vor 10 Jahren realisiert.
Deine Routinen in allen Ehren.
Aber die meisten schreiben dann doch lieber
und überlassen es dem Compiler dafür Code zu generieren, als sich da
jetzt aus dem Fundus die entsprechenden Arithmetik-Funktionen
rauszusuchen, abzuklären ob die Registermässig zusammenpassen, welcher
Wert in welches Register muss etc.
Und wenn der Umstieg auf ARM naht, dann geht obiges immer noch, während
du erst einmal anfangen musst, deine Basisroutinen auf ARM zu portieren.
Nichts gegen Assembler. Ich bin auch stark dafür, dass man seine ersten
Schritte damit macht, eben weil AVR Assembler relativ einfach zu
schreiben und zu lesen ist und der Hauptfokus damit für den Einsteiger
auf dem liegt was das Programm tun soll und nicht auf irgendwelchen
syntaktischen Feinheiten.
Aber ein richtiges Projekt, dass über den Umfang des 'Simpel
Rechteckgenerators' von oben hinausgeht: Das nenn ich Masochismus.
Karl heinz Buchegger schrieb:> Nichts gegen Assembler. Ich bin auch stark dafür, dass man seine ersten> Schritte damit macht, eben weil AVR Assembler relativ einfach zu> schreiben und zu lesen ist und der Hauptfokus damit für den Einsteiger> auf dem liegt was das Programm tun soll und nicht auf irgendwelchen> syntaktischen Feinheiten.> Aber ein richtiges Projekt, dass über den Umfang des 'Simpel> Rechteckgenerators' von oben hinausgeht: Das nenn ich Masochismus.
Richtig.
Und wenigstens einmal sollte man doch mal die Grundlagen verstehen. Und
was besseres als AVR kann einem da eigentlich nicht passieren.
Danke für den Beinahe-Glaubenskrieg...
ich denke, ich werde mir das oben genannte Buch bestellen, sowohl das
Buch als auch die beiden Tuts durcharbeiten, mein aller erstes Projekt
mit Assembler machen (weil ich letztlich nur Copy&Paste machen brauch)
und mir dann entscheiden, welches die Sprache meiner Wahl wird...
Ihr werdet es mitbekommen, welche Sprache ich genommen habe -
spätestens, wenn ich das hunderste mal kreische, erinnert mich bitte an
diesen Fred - das ich meine Entscheidung dann vllt nochmal überdenke...
Gruß Blacky
Björn C. schrieb:> Danke für den Beinahe-Glaubenskrieg...>> ich denke, ich werde mir das oben genannte Buch bestellen, sowohl das> Buch als auch die beiden Tuts durcharbeiten, mein aller erstes Projekt> mit Assembler machen (weil ich letztlich nur Copy&Paste machen brauch)> und mir dann entscheiden, welches die Sprache meiner Wahl wird...
Es gibt noch einen anderen Aspekt, warum man sich den Controller mal aus
ASM-Sicht ansehen sollte. Die Funktionstegister der internen Peripherie
kann man auch in C erkunden, dazu braucht es nicht unbedingt Assembler.
Aber den eigentlichen Kern (das Rechenwerk) lernt man nur in ASM richtig
kennen. Und nur dann, wenn man weiß, was der AVR (mit seinem
Befehlssatz) kann und was nicht (das dann in Software nachgebildet
werden muss), hat man ein Gefühl dafür, die (gegenüber dem PC verdammt
knappen) Ressourcen auch in einer Hochsprache vernünftig zu nutzen.
>> Ihr werdet es mitbekommen, welche Sprache ich genommen habe -> spätestens, wenn ich das hunderste mal kreische, erinnert mich bitte an> diesen Fred - das ich meine Entscheidung dann vllt nochmal überdenke...>> Gruß Blacky
MfG
Jemand der heute noch (bzw seit den 90ern) eine graph. Oberfläche in ASM
schreibt (noch dazu für nen kleinen 8 Biter) der muss techn. gesehen
total hinterm Mond leben, denn
- gerade eine GUI hat extrem GERINGE Zeitanforderungen, zig oder
hunderte ms, (was eine Programierung in ASM eigentlich als
Schwachsinn erscheinen lässt)
- 32 Biter sind auf jeden Fall schnell genug, sind sehr günstig bzw
kosten nur Bruchteile von einem Display, das man für GUI benötigt
(soll aber nicht heissen, dass man ASM nicht können soll)