Forum: Mikrocontroller und Digitale Elektronik welche Programmiersprache?


von Blackmore (Gast)


Lesenswert?

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

von Wolfgang B. (et-tutorials) Benutzerseite


Lesenswert?

Wenn Du Dich für "C" entscheiden solltest, dann ist vielleicht mein 
C-Anfängerkurs etwas für Dich:
http://et-tutorials.de/mikrocontroller/

von Björn C. (Firma: privat) (blackmore)


Lesenswert?

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...

von Wolfgang B. (et-tutorials) Benutzerseite


Lesenswert?

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.

von TestX .. (xaos)


Lesenswert?

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..

von Karl H. (kbuchegg)


Lesenswert?

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.

von Björn C. (Firma: privat) (blackmore)


Lesenswert?

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

von Björn C. (Firma: privat) (blackmore)


Lesenswert?

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)

von Chris (Gast)


Lesenswert?

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.

von Björn C. (Firma: privat) (blackmore)


Lesenswert?

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

von Chris (Gast)


Lesenswert?

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.

von Björn C. (Firma: privat) (blackmore)


Lesenswert?

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...

von Chris (Gast)


Lesenswert?

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!

von Björn C. (Firma: privat) (blackmore)


Lesenswert?

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

von Detlev T. (detlevt)


Lesenswert?

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

von Peter D. (peda)


Lesenswert?

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

von Heinz B. (Firma: Privat) (hbrill)


Lesenswert?

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.

von Thomas B. (escamoteur)


Lesenswert?

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 ;-)

von Erdbeere (Gast)


Lesenswert?

>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.

von Karl H. (kbuchegg)


Lesenswert?

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...

von MCUA (Gast)


Lesenswert?

>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.

von Oliver (Gast)


Lesenswert?

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

von tuppes (Gast)


Lesenswert?

>>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.

von Björn C. (Firma: privat) (blackmore)


Lesenswert?

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

von Thomas R. (tinman) Benutzerseite


Lesenswert?

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)

von Karl H. (kbuchegg)


Lesenswert?

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.

von Detlev T. (detlevt)


Lesenswert?

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.

von ulrich (Gast)


Lesenswert?

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.

von Carsten S. (dg3ycs)


Lesenswert?

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.

von A. S. (telekatz)


Lesenswert?

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

von David (Gast)


Lesenswert?

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...

von spess53 (Gast)


Lesenswert?

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

von Joe (Gast)


Lesenswert?

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

von Karl H. (kbuchegg)


Lesenswert?

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.

von A. S. (telekatz)


Lesenswert?

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).

von Thomas R. (tinman) Benutzerseite


Lesenswert?

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

von Justus S. (jussa)


Lesenswert?

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...

von spess53 (Gast)


Lesenswert?

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

von Tom (Gast)


Lesenswert?

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. :)

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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. ;-)

von Karl H. (kbuchegg)


Lesenswert?

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.

von Peter D. (peda)


Lesenswert?

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

von Senfdazugeber (Gast)


Lesenswert?

> .. 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.

von (prx) A. K. (prx)


Lesenswert?

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).

von Karl H. (kbuchegg)


Lesenswert?

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.

von (prx) A. K. (prx)


Lesenswert?

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.

von Sven P. (Gast)


Lesenswert?

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.

von Walter (Gast)


Lesenswert?

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

von Sven P. (Gast)


Lesenswert?

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.

von (prx) A. K. (prx)


Lesenswert?

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.

von DERLEVELER (Gast)


Lesenswert?

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.

von (prx) A. K. (prx)


Lesenswert?

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.

von Yalu X. (yalu) (Moderator)


Lesenswert?

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.

von Joe (Gast)


Lesenswert?

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

von Bernadette (Gast)


Lesenswert?

.
.
Eine Programmiersprache ist keine Religion.
.
.
Im Mittelalter bis in die Zeit der Industrialisierung gabe es 
Religionskriege.
.
.
Und heute ?


B.

von (prx) A. K. (prx)


Lesenswert?

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.

von Björn C. (Firma: privat) (blackmore)


Lesenswert?

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...

von Carsten S. (dg3ycs)


Lesenswert?

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

von (prx) A. K. (prx)


Lesenswert?

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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.

von Björn C. (Firma: privat) (blackmore)


Lesenswert?

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

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.

von Björn C. (Firma: privat) (blackmore)


Lesenswert?

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...

von Peter D. (peda)


Lesenswert?

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

von Alexander V. (avogra)


Lesenswert?

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.

von Björn C. (Firma: privat) (blackmore)


Lesenswert?

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...

von Bernadette (Gast)


Lesenswert?

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.

von Björn C. (Firma: privat) (blackmore)


Lesenswert?

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...

von eklige Tunke (Gast)


Lesenswert?

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...

von Ralph (Gast)


Lesenswert?

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.

von Sven P. (Gast)


Lesenswert?

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
int main(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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.

von Detlev T. (detlevt)


Lesenswert?

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

von spess53 (Gast)


Lesenswert?

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

von Oliver (Gast)


Lesenswert?

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

von spess53 (Gast)


Lesenswert?

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

von Oliver (Gast)


Lesenswert?

spess53 schrieb:
> Scrollbare, verschachtelte Menüs auf Grafikdisplays mit Touch habe ich
> beispielsweise schon vor 10 Jahren realisiert.

In Assembler?

Oliver

von spess53 (Gast)


Lesenswert?

Hi

>In Assembler?

Selbsverständlich rede ich von Assembler. Und was auch so geht:

Beitrag "Re: Zeigt her Eure Kunstwerke !"

MfG Spess

von Oliver (Gast)


Lesenswert?

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

von Des Pudels Kern (Gast)


Lesenswert?

Ich bin der Geist, der stets verneint! Und das mit Recht; denn alles, 
was entsteht, ist wert, dass es zugrunde geht

von Des Pudels Kern (Gast)


Lesenswert?

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.

von A. S. (telekatz)


Lesenswert?

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

von Karl H. (kbuchegg)


Lesenswert?

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
1
   x_pos = value_min + ( scrollbar_pos - scrollbar_min ) *
2
           ( value_max - value_min ) / ( scrollbar_max - scrollbar_min );
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.

von Sven P. (Gast)


Lesenswert?

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.

von Björn C. (Firma: privat) (blackmore)


Lesenswert?

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

von Kluchscheißernder N. (kluchscheisser)


Lesenswert?

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

von MCUA (Gast)


Lesenswert?

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)

von Björn C. (Firma: privat) (blackmore)


Lesenswert?

So..

Buch ist bestellt - mal sehen, wie weit ich komme...

Bitte 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
Noch kein Account? Hier anmelden.