Forum

@geralds, hws und all diejenigen, die mit µC mehr Erfahrung haben als ich:

Habt ihr vielleicht einen Tipp oder eine Adresse, wo ich Datenblätter oder Handbücher für AVR µC mit C++ Code finde?

Ich finde nur immer Datenblätter/Handbücher mit Assembler/C Beispiel Codes...

Gruß

Max

--
Where is the madness ...

» Habt ihr vielleicht einen Tipp oder eine Adresse, wo ich Datenblätter oder
» Handbücher für AVR µC mit C++ Code finde?

Datenblätter behandeln den µC als Hardwarechip. Kennen daher lediglich die eingebauten Machinenbefehle (entspricht Assembler).

Alles andere geht über einen Compiler.
Der Basic-Coompiler setzt Basicbefehle in Assemblerbefehle um.
Der C-Compiler setzt C-Befehle in Assemblerbefehle um.
Der xxx-Compiler ....

Für Atmel: siehe unter WinAVR. Ist ein C-Compiler, der auch in AVRStudio eingebunden werden kann.

C-Compiler: Das C-Programm ist für alle µC's grundsätzlich gleich. Dem C-Compiler ist es mehr oder minder egal, für welchen µC. Der Compiler muss natürlich für den entsprechenden µC passen.

Du hast ein falsches Verständnis, was höhere Programmiersprachen für µC's bedeuten.

» Ich finde nur immer Datenblätter/Handbücher mit Assembler/C Beispiel Codes...

Und was suchst du konkret?

hws

» » Habt ihr vielleicht einen Tipp oder eine Adresse, wo ich Datenblätter
» oder
» » Handbücher für AVR µC mit C++ Code finde?
»
» Datenblätter behandeln den µC als Hardwarechip. Kennen daher lediglich die
» eingebauten Machinenbefehle (entspricht Assembler).

Da ist mir auch nie etwas ganz klar geworden. Wenn man im Assemblerprogramm z.B. den move-Befehl eingibt, dann erzeugt das Programm den entsprechenden Maschinen-Befehlscode. Es wird also übersetzt...

Worin liegt genau der Unterschied zwischen dem Übersetzen eines Hochsprache-C-Befehles und den eines Assemblerbefehles?

Falls in Assembler nicht übersetzt wird, was passiert dann?

BTW.: Es gibt Leute die wehren sich dagegen C als Hochsprache zu bezeichnen, wogegen C++ würdig genug für diesen Titel ist...

--
Gruss
Thomas

Buch von Patrick Schnabel und mir zum Timer-IC NE555 und LMC555:
https://tinyurl.com/zjshz4h9
Mein Buch zum Operations- u. Instrumentationsverstärker:
https://tinyurl.com/fumtu5z9

» Da ist mir auch nie etwas ganz klar geworden. Wenn man im
» Assemblerprogramm z.B. den move-Befehl eingibt, dann erzeugt das Programm
» den entsprechenden Maschinen-Befehlscode. Es wird also übersetzt...

Im Prinzip ja. Allerdings wird Assembler 1:1 in Maschinencode übersetzt. MOV A, #data wird übersetzt in 2 Bytes: 74h #data
Und statt für einen Jump die absolute Speicheradresse auszurechnen, darf man eine Marke setzen und die Rechnung dem Assembler überlassen.
In den Datenblättern sind oft beispiele für die Bedienung enes bestimmten Registers in Assembler und in C gegeben. Z.B:

Assembly Code Example
in r16, SREG ; store SREG value
cli ; disable interrupts during timed sequence
sbi EECR, EEMWE ; start EEPROM write
sbi EECR, EEWE
out SREG, r16 ; restore SREG value (I-bit)

C Code Example
char cSREG;
cSREG = SREG; /* store SREG value */
/* disable interrupts during timed sequence */
_CLI();
EECR |= (1<<EEMWE); /* start EEPROM write */
EECR |= (1<<EEWE);
SREG = cSREG; /* restore SREG value (I-bit) */


» Worin liegt genau der Unterschied zwischen dem Übersetzen eines
» Hochsprache-C-Befehles und den eines Assemblerbefehles?

In der 1:1 Umsetzung.
Beim obigen Beispiel kommt das nicht klar heraus. Aber versuchs mal mit einem
Case Variable
...
end

» Falls in Assembler nicht übersetzt wird, was passiert dann?
Lesbare Variablennamen statt bitweise Speicheradressen bzw Sprungmarken.

» BTW.: Es gibt Leute die wehren sich dagegen C als Hochsprache zu
» bezeichnen, wogegen C++ würdig genug für diesen Titel ist...

Nunja, manche weigern sich auch, Basic als Programmiersprache anzuerkennen. Kommt halt drauf an, wie gut man ein Problem mit einer Sprache lösen kann.

hws

Hallo Thomas,

» Da ist mir auch nie etwas ganz klar geworden. Wenn man im
» Assemblerprogramm z.B. den move-Befehl eingibt, dann erzeugt das Programm
» den entsprechenden Maschinen-Befehlscode. Es wird also übersetzt...
»
»
» Worin liegt genau der Unterschied zwischen dem Übersetzen eines
» Hochsprache-C-Befehles und den eines Assemblerbefehles?
»
» Falls in Assembler nicht übersetzt wird, was passiert dann?
»

Auch der Assembler übersetzt, aber anders.....


» BTW.: Es gibt Leute die wehren sich dagegen C als Hochsprache zu
» bezeichnen, wogegen C++ würdig genug für diesen Titel ist...

ähmmm, naja....

--->>>
Meiner Meinung nach hat hws da einen kleinen Flüchtigkeitsfehler.

Der Maschinenbefehl ist die Sprache des Prozessors, folglich dann auch des Controllers.

Der Assembler ist ein Interpreter.
Er interprediert die Syntax der Befehls-Mnemonik und setzt sie in die Prozessor Sprache um.
---> Aus den definierten Buchstaben entstehen die Zahlen, welche den Befehl für den geforderten Prozess ergeben.

""1:1"" Übersetzung" .. irretiert hier..

Bei einem 8bit Prozessor können es bis zu 256 Befehle sein.
Praktisch wird dieser Zahlenvorrat (Befehlsvorrat) nicht voll verwendet.

Beispiel mit dem Microprocessor 6502:

http://www.c64-wiki.de/index.php/%C3%9Cbersicht_6502-Assemblerbefehle

LDA - load accumulator immediate -- lade den Akku unmittelbar mit einem Zahlenwert --> A9 #$nn
http://www.c64-wiki.de/index.php/LDA_(RAUTE)$nn
http://translate.google.de/#en|de|immediate

http://de.wikipedia.org/wiki/Maschinensprache

==> Den Prozessor 6502 nehme ich deshalb ganz gern als Taschentuchknoten,
abgesehen davon, dass ich den komplett durchkaute -- damit fasst ausschließlich arbeitete,
weil er sehr einfach zu verstehen ist, und daher auch für MicroCONTROLLER als Referenz dienen kann.
-- ist meine Meinung...

Na, der Controller hat halt seinen Prozessor im Häubchen,
inklusive der Peripherie - Sätze von Register und Ports.
Der Prozessor hat sie halt draussen, mit Daten und Adressbussleitungen verbunden,
-- lange Leitungen, im Gegensatz zu den kurzen Controller-Interne_Leitungen.

---=>>
Assembler - Programmier 1.Ebene, Interpreter
Basic - 2.Ebene, Interpeter (in der Urform - jetzt ist es auch auf einen Comiler hochgewachsen)
Compiler - 3.Ebene
Die Interpreter und Compiler sind meiner Ansicht nach immer Sparingpartner ...
... "Übersetzer" im Überbegriff, bis runter zum Assembler, der den Befehlszahlen"Salat" richtig einordnet.

Früher musste ich vom C compilieren, dann interpredieren,
"händich" mit eben diesen zwei Programmtypen.

--- > ERGO --- der Assmebler kann auch ein Mensch sein, der die Mnemonik und Prozessorbefehle kennt,
eben diesen Zahlensalat im ROM /Befehlsspeicher/ lesen kann.
-- Genau das trainierte ich mit dem 6502 und 8080, 8085 ausgiebigst.

Mit den Programmiersprachen in in den höheren Ebenen ist das um ein Vielfaches schwieriger.

Grüße
Gerald
---

--
...und täglich grüßt der PC:
"Drück' ENTER! Feigling!"

Anscheinend habe ich mich "falsch" ausgedrückt.

» » Habt ihr vielleicht einen Tipp oder eine Adresse, wo ich Datenblätter
» oder
» » Handbücher für AVR µC mit C++ Code finde?
»
» Datenblätter behandeln den µC als Hardwarechip. Kennen daher lediglich die
» eingebauten Machinenbefehle (entspricht Assembler).
»
» Alles andere geht über einen Compiler.
» Der Basic-Coompiler setzt Basicbefehle in Assemblerbefehle um.
» Der C-Compiler setzt C-Befehle in Assemblerbefehle um.
» Der xxx-Compiler ....
»
» Für Atmel: siehe unter WinAVR. Ist ein C-Compiler, der auch in AVRStudio
» eingebunden werden kann.
»
» C-Compiler: Das C-Programm ist für alle µC's grundsätzlich gleich. Dem
» C-Compiler ist es mehr oder minder egal, für welchen µC. Der Compiler muss
» natürlich für den entsprechenden µC passen.

Das weiß ich ja schon, was Du obig geschrieben hast...

» Du hast ein falsches Verständnis, was höhere Programmiersprachen für µC's
» bedeuten.

Warum heißt es dann im Volksmund, dass C oder C++ eine sogenannte "Hochsprache" ist??

» » Ich finde nur immer Datenblätter/Handbücher mit Assembler/C Beispiel
» Codes...
»
» Und was suchst du konkret?

Dazu folgendes Bild aus dem AVR Mega 16 (wenn es den nicht gibt, dann sei mir verziehen, zumindest habe ich mit dem das "Laufen" gelernt):





In solchen PDF´s sind "immer nur" Beispiele im Assembler- oder C-Code, aber ich habe bisher noch keines mit einem C++ - Code gefunden.

Und da ich grad nebenher nicht nur bisschen - mindestens an 3 Tagen in der Woche - in C++ programmiere, wollte ich einfach fragen, ob jemand von euch erfahrenes von "Handbüchern/Datenblättern" mit Beispielen in C++ - Codes wüsste...

Weil ich inzwischen der Meinung bin, dass ich mich lieber auf eine "Sprache" konzentriere als mehrere Sprachen gleichzeitig zu lernen...

--
Where is the madness ...

» Auch der Assembler übersetzt, aber anders.....

Würde ich auch so sehen, aber es gibt eben keine exakte Definition von "übersetzen".

» Der Maschinenbefehl ist die Sprache des Prozessors, folglich dann auch des
» Controllers.

Richtig, und daher wird auch ein Assemblerbefehl in genau einen maschinensprachenbefehl umgesetzt.

» Der Assembler ist ein Interpreter.

Ganz sicher nicht.
Ein Interpreter nimmt sich genau einen Befehl der Interpretersprache (Basic war damals das Übliche) und führt diesen Befehl aus. Dann nimmt er sich den nächsten Befehl und führt den aus. Ein "for I=1 to 1000: next" übersetzt 1000 mal die Schleife und führt sie 1000 mal aus. Ein Compiler übersetzt diese Schleife genau einmal und beim anschließenden "run" wird sie dann 1000mal in Maschinensprache ausgeführt.
(oder auch gar nicht, weil jeder halbwegs vernünftige Compiler merkt, dass in der Schleife nix passiert und sie deshalb wegotimiert. Daher die Verwunderung, warum dasselbe Programm im Interpreter prima läuft und als compiliertes Programm nicht. Ebenso, wenn man aus der Schleife wegen bestimmter Bedingung ausgestiegen ist, und dann das I benutzen will, um die durchlaufenen Schleifen zu zählen. Im Interpreter funktioniert das (fast immer) als compiliertes Programm öfter nicht, da das I außerhalb der Schleife nicht unbedingt definiert sein muss)

» Bei einem 8bit Prozessor können es bis zu 256 Befehle sein.
Nein. Der Z80 ist ein 8Bit Prozessor, kann aber mehr als 256 Befehle. Bei Befehlen, die mit FDh / FEh anfangen, gehört auch das nachfolgende Byte zum Befehl. (IX und IY Manipulationen)

» Praktisch wird dieser Zahlenvorrat (Befehlsvorrat) nicht voll verwendet.
»
» Beispiel mit dem Microprocessor 6502:

Ähhm, DAS Beispiel zeigt, dass nicht für jeden Befehl alle Adressierungsarten benutzt werden ...

» Assembler - Programmier 1.Ebene, Interpreter
Nein, ein Interpreter interpretiert immer wieder seinen Eingangscode. Ein Assembler setzt seine (Assembler) Source einmal in eine Bitfolge (samt Berechnung von Sprüngen und symbolischen Adressen) um und setzt diese Folge einmal dem µC vor, der dann ohne weitere Benutzung des Assemblers den Maschinencode ausführt.

» Basic - 2.Ebene, Interpeter (in der Urform - jetzt ist es auch auf einen
» Comiler hochgewachsen)

Für Basic gibt es sowohl Interpreter (früher ausschließlich) als auch Compiler für Basic. (und ebenso für andere Sprachen)

» Früher musste ich vom C compilieren, dann interpredieren,
» "händich" mit eben diesen zwei Programmtypen.

Also für C kenn ich nur Compiler, aber keine Interpreter. Oder kennst du einen C-interpreter?

» --- > ERGO --- der Assmebler kann auch ein Mensch sein, der die Mnemonik
» und Prozessorbefehle kennt,
» eben diesen Zahlensalat im ROM /Befehlsspeicher/ lesen kann.

Sicher kann man auch direkt im Maschinencode programmieren (wenn man's kann). Beim Z80 konnte ich auch mal einen Speicherdump in Hex-Zahlen als Programmalauf nachvollziehen. Und wenn man sich das Programm so geschrieben hat und die Adressdifferenz von Sprungbefehlen selbst errechnet hatte .. ging alles.

» Mit den Programmiersprachen in in den höheren Ebenen ist das um ein
» Vielfaches schwieriger.

Was ist dort schwieriger? Man kann sich auch den vom C-Compiler generierten Assemblercode ansehen (und sogar verändern / optimieren - wenn man's kann)

Vorauszusagen, wie ein Compiler den Hochsprachentext in Assemblerbefehle umsetzt - kann vielleicht der Schreiber des Compilers, aber kein Normalsterblicher. Zumal man bei Compilern auch noch diverse Optimierungsstufen wählen kann.

hws

Besten Dank für Deine ausführliche Antwort. Ich glaub' ich habe das Wesentliche verstanden.

Richtig praktisches Assemblieren kam bei mir nie zur Anwendung. Ich lernte das mal etwas in den 1980er-Jahren mit dem "Micro-Professor" mit einem Z80:


Quelle: http://www.tietokonemuseo.net/koneita/multitechmpmpf1.htm

Als ich später einen ATARI-ST kaufte (der war damals auch an einigen ETH-Instituten hoch im Kurs), "spielte" ich mit einem Assembler-Tutor herum. Das war noch lustig, man konnte problemlos, ohne den Rechner zum Absturz zu bringen, sich im Assemblieren des MC68000 üben. Mehr wurde daraus nicht, weil jemand anders, der auf diesem Gebiet ein Guru war, programmierte in Assembler eine schnelle Routine fuer den Daten-In/Output über die ROM-Port-Schnittstelle. Ich lernte und schrieb damals nur grad ein paar C-Routinen (TurboC-2) um meine selbstentwickelten Schaltungen zu testen. Diese Routinen implementierte dann der Guru in sein GEM-Programm. Es ging damals um ein 4-kanaliges AD/DA-Wandler-System...

Jaja, das waren noch Zeiten...

» » BTW.: Es gibt Leute die wehren sich dagegen C als Hochsprache zu
» » bezeichnen, wogegen C++ würdig genug für diesen Titel ist...
»
» Nunja, manche weigern sich auch, Basic als Programmiersprache
» anzuerkennen. Kommt halt drauf an, wie gut man ein Problem mit einer
» Sprache lösen kann.

Es hat vielleicht auch etwas damit zu tun, dass es doch recht grosse Qualitätsunterschiede zwischen den verschiedenen Basicdialekten gab. Ich freundete mich damals sehr rasch mit dem GFA-BASIC an, mit dem man ohne den Spaghetticode anzuwenden, sauber strukturiert programmieren kann. Weil dem so war, distanzierten sich die GFA-Programmierer Engels und Ostrowsky von der File-Extention ****.BAS zu ****.GFA ab der Version 3.

--
Gruss
Thomas

Buch von Patrick Schnabel und mir zum Timer-IC NE555 und LMC555:
https://tinyurl.com/zjshz4h9
Mein Buch zum Operations- u. Instrumentationsverstärker:
https://tinyurl.com/fumtu5z9

» Hallo Thomas,

Hallo Gerald,

Auch Dir, vielen Dank für Deine Ausführungen.


» --->>>
» Meiner Meinung nach hat hws da einen kleinen Flüchtigkeitsfehler.
»
» Der Maschinenbefehl ist die Sprache des Prozessors, folglich dann auch des
» Controllers.
»
» Der Assembler ist ein Interpreter.
» Er interprediert die Syntax der Befehls-Mnemonik und setzt sie in die
» Prozessor Sprache um.

Ja, so verstehe ich das. Ich erinnere mich, wenn man einen Assemblercode in ein GFA-BASIC-Programm einbinden wollte, musste man ja den Maschinencode einbinden, der vom Assembler-Programm vorher erzeugt wurde.

Allerdings bleibt mir das Wort Interpretieren etwas im Hals stecken. Darunter vestehe das typische alte Basic, bei dem man das Programm nur Zeile für Zeile interpretierend laufen lassen konnte. Das war auch entsprechend langsam.

GFA-BASIC erzeugt fuer den Interpreter sowas wie ein vorverdauter Code, der im Interpreter viel schneller abläuft. Manchmal, je nach Programminhalt, kaum sichtbar langsamer als das fertige Compilat. Dieser vorverdaute Code wird direkt beim Speichern des Programmtextes im GFA-eigenen Editor erzeugt. Das hatte auch den grossen Vorteil, dass bei jedem Fehler in der Programmzeile beim Eingeben, mit einem Ping der Cursor sogleich an die Stelle landete wo man Mist getippt hat.

» ---> Aus den definierten Buchstaben entstehen die Zahlen, welche den
» Befehl für den geforderten Prozess ergeben.
»
» ""1:1"" Übersetzung" .. irretiert hier..

Aber ich denke, dass HWS das gemeint hat...

» --- > ERGO --- der Assmebler kann auch ein Mensch sein, der die Mnemonik
» und Prozessorbefehle kennt,

Genau so musste ich es mit dem alten Micro-Professor noch lernen. Beim diesem konnten man nur Zahlen eingeben. Die neueren Geräte erlaubten die Eingabe des Assembler-Codes.

--
Gruss
Thomas

Buch von Patrick Schnabel und mir zum Timer-IC NE555 und LMC555:
https://tinyurl.com/zjshz4h9
Mein Buch zum Operations- u. Instrumentationsverstärker:
https://tinyurl.com/fumtu5z9

» Warum heißt es dann im Volksmund, dass C oder C++ eine sogenannte
» "Hochsprache" ist??

Sind es für mich auch. Die Behauptung "C ist keine höhere Programmiersprache" stammt nicht von mir.

» Dazu folgendes Bild aus dem AVR Mega 16 ....

Doch, und das passt für fast alle ATMEgaxxx

Man kann natürlich in C exakt so programmieren, wie in Assembler - Bit für Bit setzen und schieben. Aber man hat noch mehr Möglichkeiten.

Nimm eine (möglicherweise noch verschachtelte) CASE Anweisung oder For-Schleife oder einen bedingten Sprung. Dort ist der erzeugte Assemblercode nicht mehr so einfach 1:1 mit den C Befehlen vergleichbar. (Kann man sich ansehen, wenn man die Option im C-Compiler einschaltet.)

» In solchen PDF´s sind "immer nur" Beispiele im Assembler- oder C-Code,
» aber ich habe bisher noch keines mit einem C++ - Code gefunden.

Es ist auch nicht sinnvoll, ein C++ Programm auf einen Assemblercode zurückzuführen. (und ob es sinnvoll ist, bei einem KLEINEN µC in C++ programmieren bezweifle ich ebenfalls mal)

Was ich für Einsteiger als sinnvoll ansehe: Bei einem bestimmten µC Grundlagen mit Assembler zu üben. Dabei lernt man die grundlegende Arbeitsweise, wie der µC intern arbeitet. Dann in C einsteigen und das Assemblerprogramm in C umsetzen (mehr oder minder 1:1, gleicher µC)
Danach in C weitermachen, auch die Befehle, die man nicht mehr 1:1 aus Assembler übernehmen kann. (Felder, Pointer, FOR und IF Konstrukte usw)
Hilfreich für das C-Verständnis wäre auch, wenn man auf dem PC mal mit Quick-C oder ähnlichem programmiert hat, ohne sich um die interne Umsetzung jemals gekümmert zu haben - muss aber nicht.

Und wenn man einen bestimmten µC in C programmieren kann, kann man auch einen andren µC in C programmieren.
Der einzige Unterschied ist die unterschiedliche Hardware. Der AD Wandler eines PIC's wird anders ausgelesen als der eines AVR's.
Und genau diese Codeschnipsel sind die Beispiele in den entsprechenden Datenblättern. (Aus der Register- und Bitzuordnung des AD-Wandlers könnte man sich das auch selbst ableiten - aber die Beispiele sind halt hifreich)

» Und da ich grad nebenher nicht nur bisschen - mindestens an 3 Tagen in der
» Woche - in C++ programmiere, wollte ich einfach fragen, ob jemand von euch
» erfahrenes von "Handbüchern/Datenblättern" mit Beispielen in C++ - Codes
» wüsste...

Beispiele weiss ich nicht. Aber wenn du C++ beherrscht, solltest du auch C kennen?
Also ist die Frage, gibt es für den gewünschten µC einen C++ Compiler?

Assembler und einfache Brenner, Entwicklungssysteme gibt es für fast jeden µC. Neben Atmel und Pic gibt es auch noch Texas, Renesas, Holtec und nen Haufen andere.
C und/oder C++ ist dann mehr ne Frage, was man für dieses System zahlen will. Und wenn man komfortable Debugger in Hardware und Software haben will, ist das ebenfalls ne Preisfrage.

In kommerziellen Firmen weniger, da dort die Arbeitszeit bewertet wird - im Gegensatz zu "Bastlern".

» Weil ich inzwischen der Meinung bin, dass ich mich lieber auf eine
» "Sprache" konzentriere als mehrere Sprachen gleichzeitig zu lernen...


Korrekt. Lerne C, das können die meisten (alle?) µC's. Vielleicht willst du dich ja auch nur (vorerst?) auf einen µC fokussieren.
Neben C musst du für jeden µC auch noch die spezifische Peripherie lernen (Timer, PWM, AD-Wandler, Interrupts usw) Und genau das sind die Beispiele in dem Datenblatt (in C und Assembler)
Eine "Schlaraffenland-Programmierung" gibt es nicht. C++ für einen Prozessor schreiben ohne Ahnung, welche Peripherie drin ist, geht nicht.

hws

Ja,,,, ich denke, da habe nun einen Patzer geleistet.

Der Assembler ist kein Interpreter, er kompiliert.... ganz unten auf der Maschinenebene.

Also,, vom Wurzelwort "assemble" aus gesehen heißt das in den Verben montieren, sammeln, versammeln, zusammenfügen, zusammenbauen.....und einige mehr..

Der Assembler wäre dann in der Monteur, Versammlungsteilnehmer....

So gesehen stimmt es ganz genau.. der Assmbler baut den
in einer Symbolsprache erstellten Code in den Maschinencode zusammen.

Das macht er genau in der Reihenfolge, wie es der
Programmierer eintippt,,, fast zu Fuss ...
ok.. besser als zu Fuss, weil schneller als der Mensch es auscodiert,
bzw. in seinen Varianten behandelt er Makros, durchläuft mehrere Durchgänge und hat Optionen.

So gesehen auch, ist der Assembler (Assemblierer nach DIN44300) ein Hilfsprogramm der Programmierung.

http://de.wikipedia.org/wiki/Assembler_(Informatik)
http://de.wikipedia.org/wiki/Interpreter

Hws hat recht in dem Sinn...

----

--
...und täglich grüßt der PC:
"Drück' ENTER! Feigling!"

hier gibts was zum Aussuchen:

http://www.elektor.de/suchen.7172.lynkx?searchValue=avr

www.franzis.de/franzis/div/search/
search.jsp;jsessionid=72041B7A55E5EC359E460616876194AD?actionRequest=smartSearch&fuzzy=0.8&sparam_area=download-shop&text=avr

"avr" ist das Suchwort.
Bitte beide Zeilen in den Browser kopieren, dann kommst direkt dorthin.

www.atmel.com
http://sourceforge.net/projects/winavr/files/WinAVR/20100110/

Viel Spass
Grüße
Gerald
---

--
...und täglich grüßt der PC:
"Drück' ENTER! Feigling!"

Ich muss mich bei euch entschuldigen.

Ich war auf dem völlig falschen Tripp.

Ich dachte, man kann µC - egal von welchem Hersteller der jeweilige µC ist - auch in C++ beschreiben.

Falsch gedacht. Für sowas ist C++ auch nicht gedacht.

Zumindest habe ich erst heute gelesen, dass Assembler und normales C eher Programmiersprachen für die Hardware sind - also z. B. für ein LED-Lauflicht über µC - und C++ eine Programmiersprache eher für Software ist.

Werde ich wohl doch zweigleisig fahren müssen... wobei eher wollen.

» Beispiele weiss ich nicht. Aber wenn du C++ beherrscht,
» solltest du auch C kennen?
» Also ist die Frage, gibt es für den gewünschten µC
» einen C++ Compiler?

Was ich gemerkt habe, sind Sachen wie FOR-Schleife, WHILE-Schleife, Variablen Deklaration (Integer, Character, usw.), ... gleich, aber wenn man in´s Detail schaut sind die beiden Sprachen schon anders.

Beispiel: Texteingabe / Ausgabe

C - Sprache:

printf(...); -> Textausgabe
scanf(...); -> Eingabe

C++ - Sprache:

cout << "..."; -> Textausgabe
cin >> ... ; -> Eingabe

Ich bin noch in den Kinderschuhe in der C++ Programmierung unterwegs, aber ich glaube, dass es da noch viel mehr Details gibt.

Zudem kann man in C keine Klassen programmieren.

Naja ... wie gesagt, werd ich wohl zweischneidig fahren müssen. Wobei, schaden kann es ja nicht, wenn man mehr als nur eines kann.

--
Where is the madness ...

Hi Max,

Das empfehle ich dir auch...

Assembler und C++ für dein gewähltes Target -- suche mal diesen Begriff

Wenn du schon dabei bist, dann trainiere auch fleißig den händich auscodierten Maschinenbefehlsatz.
Also,,, ROM auslesen, den Hex Code sorgfältig durcharbeiten, damit du wieder auf die Symbolspache Assembler kommst.
Das geht natürlich auch mit dem Disassembler,,, ist genau das Gegenteil vom Assembler.

Vergiss nicht.... Die Info-Texte, die Label, usw. im Source werden nicht' in den Hex Code codiert.
Daher mache dir unbedingt eine sorgfältige Dokumentation
von deiner Arbeit, damit das Disassemblieren fehlerfrei erfolgen kann.
---ok, ok, oder du vergibst neue Labelnamen ist ja nur eine Symbolsprache...

Grüße
Gerald
---

--
...und täglich grüßt der PC:
"Drück' ENTER! Feigling!"

» Wenn du schon dabei bist, dann trainiere auch fleißig den händich
» auscodierten Maschinenbefehlsatz.
» Also,,, ROM auslesen, den Hex Code sorgfältig durcharbeiten

Nöö, das macht kein Mensch mehr. Außer, ich will einen fremden Code knacken. Aber da scheitert man meist schon daran, dass der µC gegen Auslesen gesichert ist.

Ansonsten debugt man seinen eigenen Code auf der C-Ebene.
Der C-Befehl wird angezeigt und auch der daraus erstellte Assemblercode. Je nach Wahl kann man jetzt jeden Assemblerbefehl einzeln durchsteppen oder komplett den C-Befehl.
Dabei sich jeweils die Register ansehen, Flags, ausgewählte RAM Bereiche u.ä.

Auf diese Weise kann man sich auch den Programmablauf eines fremden Programms ansehen, wenn man die Sourcen hat.

Hat man versehentlich seinen eigenen Sourcecode gelöscht, ist es meist einfacher, das Programm an Hand der vorhandenen Ablaufdiagramme nochmal zu schreiben, anstatt aus dem disassemblierten HexCode zu restaurieren.

hws

DOCH !!!

gerald
---

--
...und täglich grüßt der PC:
"Drück' ENTER! Feigling!"