mal ein kleines beispiel:

Du willst einen IO-Pin des uC setzen / rücksetzen.

In Assembler musst Du dafür die Adresse des Ports mit irgendwas verodern z.B. Du willst das 4te Bit eines Ports setzen, das wäre dann ungefähr


die genaue asm-syntax kenn ich jetzt nicht, aber das soll heißen, "Verodere Adresse 3c3 mit hex 4", also setze das vierte bit.

So, in C kann man sich dafür nun schöne defines schreiben:


ZUM BEISPIEL!
Also das kann man sicher auch anders machen, aber du kannst halt dein gesamtes C-Arsenal drauf loslassen. Für so triviale Sachen wie Bit-Setzen wird das jetzt wahrsch. nicht so deutlich, aber wenns komplizierter wird sind dann halt schnell ne ganze handvoll asm-codes in einer einfachen c-anweisung untergebracht. der c-code ist auf jeden fall auch ohne kommentar in jeder zeile gut lesbar, udn vor allem wartungsfreundlich.

Und ich kann dir mi 99%iger Sicherheit sagen, dass der Code SET_BIT... usw in genau den obigen Assembler-Befehl vom Compiler übersetzt wird.

Das aber nur zur Info, als für kleine Sachen ist asm sicher ne gute Wahl... aber zumindest mir gehts halt so:
Jetzt hab ich das implementiert, jetzt kann man noch das unterstützen, und hier erweitern... und da auch noch... und dann wird der kleine Controller schnell ZU klein, und der asm-Code unwartbar.
Also schreib ich lieber gleich C  

ich glaube ned dass du da noch viel optimieren kannst aber die meisten compiler erzeugen wirklich nur assembler code den se dann halt für den controller nomma übersetzen
den kannst der dann natürlich auch nomma anzeigen lassen

Zitat von »Spunky«

Ja, das mit den Ports ansteuern in C ist gaaaaanz schwer. Hier mal ein Beispiel:

	Quellcode
1 2 3 4 5 6 7	/* Port B komplett auf 1 setzen */ PORTB = 0xFF; /* Jetzt ein eizelnes Bit zurücksetzen */ cbi(PORTB,3); /* Jetzt ein eizelnes Bit setzen */ sbi(PORTB,3);

Verstanden?

Nimm zum C-Programmieren AVRedit. Komplettes Paket mit Editor, gcc usw.

Spunky

Das ist doch aber auch nicht wirklich viel anders als in Assembler ? ( hab seither immer in Assembler programmiert, kann also kein C und hab davon auch keine Ahnung )


-RedHead

Stimmt. Im Prinzip sind die Portbefehle denen von Assembler sehr ähnlich. Der Unterschied zwischen C und Assembler wird aber dann bei Schleifen und Bedingungen sehr deutlich. Auch der Aufruf von Funktionen ist IMHO einfacher.

Ein ist für die meisten Einsteiger in die Controllertechnik einfacher, als sich erst mühsam Assembler zu lernen. Bei größeren Programmen sind Hochsprachen doch etwas einfacher, als Assembler. Viele Konstrukte sind dann übersichlicher. Allerdings lernt man mit Assembler den Mikrocontroller erst richtig kennen.

Es ist halt immer auch eine Geschmacksfrage oder Glaubensfrage, wie man seine Programme schreibt. Jede favorisiert irgendwann seine Sprache, mit der er am besten zurecht kommt.

Spunky

stimmt, is wirklich irgendwo ne glaubensfrage
und ich glaube nunmal dass assembler stinkt ;D

Wer Assembler hasst, ist meistens ein Faulpelz! ;D

Ich gebe ja zu, das ich gerne mal Bascom nehme.

Spunky

mist, ich wurde ertappt ;D

is aba ned nur dass ich faul bin, ich steh einfach mehr auf c, einfacher und logischer kann ne programmiersprache kaum noch aufgebaut sein wennst mich fragst (n halbwegs vernünftiger programmierstil vorrausgesetzt )

außerdem hat man da viel weniger möglichkeiten fehler einzubaun weil man sich zb ned drum kümmern muss welcher befehl welches register verändert, wann, wo und wie ich daten evtl sichern muss, ...

alles in allem wirklich besser als assembler

ps: obiger text enthält größere mengen von 'meine meinung^TM', sollte sollte jmd das anders sehen is das zwar sein gutes recht aber überzeugen wird er mich trotzdem ned könne

Hallo, noch ein Argument, C zu programmieren:

Die AVR-Controller von Atmel sind bereits für C bezüglich der Registersätze optimiert, wäre Quatsch, diesen Vorteil nicht zu nutzen. Ich stelle mir gerade mit Grauen vor, ein komplexeres Kommunikationsprotokoll wie CANopen oder IAP in Assembler schreiben zu müssen...

Ausserdem: Alle Ingenieure können (mindestens) C ;D !

Zitat von »r1ppch3n«

außerdem hat man da viel weniger möglichkeiten fehler einzubaun weil man sich zb ned drum kümmern muss welcher befehl welches register verändert, wann, wo und wie ich daten evtl sichern muss, ...

Is nicht böse gemeint, aber du weisst, daß in sicherheitskritischen Bereichen C teilweise sogar verboten ist? Bei Militärs, Raumfahrt und Medizin kann man sich keine Pointer-Fehler und Bufferoverflows leisten. C bietet da ein paar böse Fallen.

Aber davon ab prgrammiere ich auch gerne in C. Assenbler setzt, wie du sagst, etwas mehr Mühe und Fleiss vorraus. Aber ein geüberter Assembler-Programmierer hat auch keine Probleme mit den Registern. Wer einen Macro-Assembler gut beherrscht hat nach einiger Zeit auch fast eine einfache Hochsprache.

Ich programmiere halt meist in Hochsprachen, weil ich auch andere Systeme bearbeite. Hier ein bisschen awk und Shellscript, dort PHP und Perl. Da ist nach einer kleinen Pause im Mikrocontrollerprogrammieren der Rückeinstieg über C oder Basic einfacher. Die Schleifen und Bedingungen sind in den Hochsprachen doch ähnlicher als in Assembler.

Spunky

ach ja... pointer...
ok, damit kann man wirklich viel kaputt machen wenn man mist baut ;D
andrerseits haben die mich auch in assembler scho das eine oder andre ma 'geärgert'... (nich dass ich nich damit umgehen könnte aber wenn man doch ma n winzigen denkfehler macht hat steht man wirklich gleich vor nem super gau... :)

trotzdem bleib i meiner lieblingssprache treu
und bei den sachen die ich progge brauch i mer auch kei gedanken machen dass jmd draufgeht wenn das teil sich ma aufhängen sollte, is momentan ja wirklich ned mehr als n kleines hobby

Zitat von »r1ppch3n«

...assembler ... (nich dass ich nich damit umgehen könnte aber wenn man doch ma n winzigen denkfehler macht hat steht man wirklich gleich vor nem super gau... :)

Das stimmt. Bei C erkennt man leichter Fehler im Programm. Bei Assembler wird es schonmal richtig kniffelig. Vor allem bei Mikrocontroller ist das Debugging mühsam. Zum Glück gibt es heute die Atmels mit FLASH. Vor gut 15 Jahren musste ich für meine 8051 immer ein EPROM brennen und dann testen. Später habe ich die Programme teilweise direkt im HEX-Editor des Brennprgramms editiert. Heute klickt man nur noch auf _Compile_ und _Flash_ und dann gucken obs läuft.

Spunky

hatte das eigentlich mehr auf die pointer bezogen, einfach praktisch, einfach genial, einfach ne schlimme teilweise schwer zu quelle
wollt se trotzdem nich missen

ps: ein hoch auf das in system debugging ;D