Wie habt ihr C gelernt?

C mit K&R, AVR mit dem Datenblatt des ATmega8, alles andere wäre zu 
aufwendig oder unvollständig gewesen.

Erste Schritte auf dem PC, dann aber über den MCU.
Aber richtig den Durchblick hatte ich, als ich mit PHP angefangen habe. 
Die Grundstruckturen sind gleich, hat ähnliche Funktionen und 
Möglichkeiten.

Aber dann wieder zurück auf den MCU war nicht so einfach: Man musste 
sich nicht mit Speicher herumschlagen auf den Servern (ist ja genug da). 
Ebenso wenig mit der Geschwindigkeit.

Einfacher Tip: Üben, üben, üben....

C mit "C von A bis Z"
http://openbook.galileocomputing.de/c_von_a_bis_z/

Einstieg in AVRs in der Schule, den Rest dann selbstständig mit dem 
Datenblatt.

Es macht einen großen Unterschied, ob du vorher schon eine (vernünftige) 
Programmiersprache kennst. Von Pascal auf C umsteigen ist easy. So habe 
ich C gelernt.

C als erste Programmiersprache: Je nach Vorkenntnissen zum Thema 
Ablaufsteuerung, Codierung, Rechnerarchitektur, ...

Manx Aztek C, damals der allerbeste ;)

AT schrieb:
> Mich würde mal interessieren, mit welchen Büchern, Tutorien, etc. ihr
> euer Wissen in C für die AVRs erworben habt?!

K&R, die ursprüngliche Version. Nur gabs damals noch keine AVRs, die 
Systeme waren VAX/VMS (16-Bit Subsystem sowie Eunice) und ein 
68000-System mit viel eigener Hardware und eigenem z.T. in C 
geschriebenen Betriebssystem.

Yalu X. schrieb:
> C mit K&R, AVR mit dem Datenblatt des ATmega8

+1, außer dass es bei mir noch ein AT90S4434 war (und danach ein
ATmega128). :)

Allerdings geht es mir wie A. K., zwischen C lernen und AVR lag ein
Jahrzehnt dazwischen.

Jörg Wunsch schrieb:
> zwischen C lernen und AVR lag ein Jahrzehnt dazwischen.

Mach zwei draus. Allerdings ist es ziemlich schnuppe, ob man den 
Hardware-Support für ein eigenes einfaches Betriebssystem programmiert, 
oder irgendwas für einen AVR, das ähnelt sich. Ausser dass der Compiler 
für den AVR nicht auf dem AVR selbst läuft.

Joachim Drechsel schrieb:
> Manx Aztek C, damals der allerbeste ;)

Genau! Denn bei dem war im Gegensatz zum Lattice-C-Compiler sizeof (int) 
== 2 und nicht 4, was Vorteile auf den 16-Bit-68000ern hatte :)

Den Manx habe ich mir gekauft, einige Zeit nachdem ich den K&R 
fertiggelesen hatte. Ich brauchte ja schließlich etwas, um das Gelernte 
zu überprüfen.


Jörg Wunsch schrieb:
> Allerdings geht es mir wie A. K., zwischen C lernen und AVR lag ein
> Jahrzehnt dazwischen.

Bei mir ging es schon eher in Richtung 2 Jahrzehnte. Allerdings hatte 
ich zwischendurch die Gelegenheit, auf anderen Mikrocontrollern 
(8051-Derivate und C16x) zu programmieren. Da ging der Einstieg in die 
AVR-Serie in zwei oder drei Abenden (einschließlich Hardwareaufbau) 
vonstatten.

Yalu X. schrieb:
> Joachim Drechsel schrieb:
>> Manx Aztek C, damals der allerbeste ;)
>
> Genau! Denn bei dem war im Gegensatz zum Lattice-C-Compiler sizeof (int)
> == 2 und nicht 4, was Vorteile auf den 16-Bit-68000ern hatte :)

Und den gab es auch als Crosscompiler für den 6502 ;)

Yalu X. schrieb:
> Genau! Denn bei dem war im Gegensatz zum Lattice-C-Compiler sizeof (int)
> == 2 und nicht 4, was Vorteile auf den 16-Bit-68000ern hatte :)

... und Nachteile, wenn man Unix-Sourcen portierte, die damals ziemlich 
häufig von sizeof(int) == sizeof(char *) ausgingen.

> Bei mir ging es schon eher in Richtung 2 Jahrzehnte. Allerdings hatte
> ich zwischendurch die Gelegenheit, auf anderen Mikrocontrollern
> (8051-Derivate und C16x) zu programmieren.

Wenn man schon einige Architekturen verschiedenster Grössenordnungen 
kennt, dann ist eine weitere - und zudem ziemlich "normale" wie AVR - 
keine Besonderheit.

Hier mal die Reihenfogle bei mir:

NXT bekommen, NXT-G benutzt(Klicki Bunti)

Arduino bestellt, Arduino programmiert

Durch Schule Java gelernt

Quadrokopter begonnen, Fernsteuerung in Java geschrieben.

C auf Mikrocontroller versucht(mit Atmel Studio)

C-Tutorials durchgearbeitet.

Dank der ähnlichen Syntax von Java und C ist der Umstieg einfacher.
Java's Syntax ist IMO etwas lesbarer.

Von C geht's dann demnächst zu C++, aber das kommt später.

So habe ich C gelernt.

A. K. schrieb:

>> zwischen C lernen und AVR lag ein Jahrzehnt dazwischen.
>
> Mach zwei draus.

Nun, ich habe spät mit C und relativ früh mit AVR angefangen. ;-)

> Allerdings ist es ziemlich schnuppe, ob man den
> Hardware-Support für ein eigenes einfaches Betriebssystem programmiert,
> oder irgendwas für einen AVR, das ähnelt sich.

In meinem Falle war es kein „eigenes einfaches Betriebssystem“, sondern
erst 386BSD und dann FreeBSD.  Aber vor 20 Jahren war auch dort in den
Gerätetreibern die Abstraktion noch nicht so weit getrieben wie heute,
sodass sich ein damaliger Gerätetreiber nicht so grundlegend von der
Hardwareansteuerung auf einem Controller unterscheidet.  (Die
Abstraktion bei diesen „großen“ Betriebssystemen wurde nochmal einen
Schritt weiter getrieben, als man auch die Bussysteme abstrahiert hat.
Damit wiederum kann man gleiche Basistreiber für eine bestimmte
Hardware[familie] bauen, egal, ob sie über ISA, EISA, PCI, PCMCIA,
Cardbus, ACPI oder weiß der Geier[TM] angesprochen wird.)

Ich hab in jungen Jahren am C64 Basic gelernt, dann an der Uni Fortran 
77.

Irgendwann gabs für den C64 einen C-Compiler von Data Becker. Hab mir 
dann den guten, alten K&R reingezogen und war schlichtweg begeistert wie 
elegant man damit, verglichen mit Fortran, programmieren kann. Seitdem 
ist das "meine" Sprache.

Weiter gings dann auf dem Amiga und später professionell in C.

wirklich gut ... und günstig ...

das Buch: C-Programmierung  von Jürgen Wolf
ISBN: 978-3-8272-4769-8

---- >

und dann hab ich mir dieses Buch geleistet:

Elektronik AVR-Mikrocontroller in C programmieren
beim Franzis Verlag.

und ... man lernt nie aus

> Wie habt ihr C gelernt?
In der Schule am PC (QBASIC) sowie daheim am C64 BASIC gelernt (C64 
Handbuch).
Irgendwann dann am PC auf C umgestiegen, weil QBASIC zu lahm war 
(interpretiert). Zu der Zeit konnte ich noch kein C, wusste aber sehr 
wohl von strukturierter Programmierung.

Mein erstes C programm war dann im Grunde ein Suchen / Ersetzen im BASIC 
programm: aus gosub/return wurden functions, print zu printf, 
if-then-else-endif zu if(){...} else {...} und so weiter. Entsprechend 
lustig schauts aus heutiger Sicht auch aus **grins**

So richtig C gelernt habe ich dann mit dem AVR AT90S8535 (und google), 
danach kamen ein paar Neuerungen in Sachen Pointer und C++ sowie etwas 
MFC während des ETechnik-Studiums dazu, und Vertiefung in 
Windows-Programmierung und ARM Cortex-M im Job.

Pointer hasst man zunächst wie die Pest, sobald man damit umgehen kann 
will man sie besonders auf einem µC nie wieder missen :-)

Um mich meinem Vorredner anzuschliessen:
Seit dem ist auch C/C++ die Sprache meiner Wahl, und ich möchte sie 
nicht wieder missen. Java und Konsorten gehen für mich eher in die 
"Spieleecke"...
Java Programmierung hab ich an der FH bei den Informatikern "aus Spass" 
mitgemacht, aber möchte ich nicht für etwas ernsthaftes hernehmen :-)

AT schrieb:
> Mich würde mal interessieren, mit welchen Büchern, Tutorien, etc. ihr
> euer Wissen in C für die AVRs erworben habt?!

Als ich C gelernt habe, was vor über 20 Jahren gewesen sein muß, konnte 
ich schon diverse Basic-Dialekte, Z80 Assembler und 6502 Assembler. 
Außerdem Turbo-Pascal und Modula-2. Motivation war damals ein Account 
auf den (für damalige Verhältnisse) dicken UNIX-Hobeln im FB Informatik. 
Da gabs schlicht nix anderes als C und Korn(?) Shell.

Von C ging es dann recht rapide weiter zu C++ und nebenbei auch zurück 
zum PC (Borland C++, Linux gcc) - allerdings immer mit der Bedingung daß 
der Code auch auf Solaris und HP-UX compilieren muß. Privat habe ich 
nebenher einen Assembler für Z8 geschrieben (in C++, flex, bison) und 
dabei eine Menge gelernt.

Im "richtigen Job" mußte ich C Code dann höchstens lesen. Geschrieben 
habe ich eher PHP, Perl, Shell. µC habe ich hobbymäßig mit Assembler 
programmiert. Und vor ca. 3 Jahren erst habe ich das gcc-Tutorial hier 
überflogen und mein erstes C Projekt auf dem AVR durchgezogen.

Ich würde mich all jenen anschließen, die empfehlen C auf dem PC zu 
lernen. Wenn man die Sprache an sich beherrscht und vielleicht auch 
schon die richtige^Wselbe Toolchain (gcc) verwendet, dann hilft das 
enorm weiter wenn man den Schritt zum µC geht. Da kommt dann eigentlich 
bloß noch ein Sack magische Namen wie PORTD oben drauf. Und natürlich 
eine andere Standardlibrary.

Für µC kleiner als ARM/MIPS würde ich auch immer noch 
Assemblerkenntnisse empfehlen.


XL

Axel Schwenke schrieb:
> Privat habe ich nebenher einen Assembler für Z8 geschrieben (in C++,
> flex, bison) und dabei eine Menge gelernt.

**Interesse bekund**

Habe noch irgendwo ein, zwei oder drei Z8 rumliegen, mag aber ungern
unter CP/M assemblieren, falls ich sie wirklich nochmal nehme.

Mit der Doku zum Maxon C/C++, damals auf dem Amiga… Sind jetzt sicher 
zwei Jahrzehnte.

Jörg Wunsch schrieb:
> Habe noch irgendwo ein, zwei oder drei Z8 rumliegen, mag aber ungern
> unter CP/M assemblieren, falls ich sie wirklich nochmal nehme.

Ich habe zwar auch noch einen eigenen Z8 Assembler rumliegen, aber da 
wirds wohl für beide Seiten einfacher:
http://shop-pdp.kent.edu/ashtml/asxdoc.htm
http://john.ccac.rwth-aachen.de:8000/as/index.html

Zum Glück garnicht...
jetzt geht es bald mit Kommentare gleich los...LoL

Thomas der Bastler schrieb:
> Zum Glück garnicht...

Kannste schnell nachholen. ;-)

Buch dazu gibt es noch ein paar Tage umsonst zum runterladen

http://www.degruyter.com/viewbooktoc/product/226716

ein ansi-c.pdf existiert auch noch dazu

http://info.baeumle-courth.eu/c-main.html

> jetzt geht es bald mit Kommentare gleich los...LoL

Den Beipackzettel zu C (bezüglich Nebenwirkungen und 
Begleiterscheinungen) hat hier einer umschrieben (er hat's zumindest 
versucht)

http://www.henning-thielemann.de/CHater.html

Anscheind ist er Modula 2(3) Fanboy.

Jeder wie er möchte. ;)

Oh man ... zu dem C-Haters link fällt mir nur ein:
Manche Programmiersprachen sind dafür da, um den Programmierer vor 
seiner eigenen Blödheit zu beschützen...

C wird zwar als "The Devils Assembler" bezeichnet, ist dafür aber auch 
fast ebenso schnell, und daher für µCs (wenig Rechenleistung) sehr 
geeignet.

Random ... schrieb:
> C wird zwar als "The Devils Assembler" bezeichnet, ist dafür aber auch
> fast ebenso schnell, und daher für µCs (wenig Rechenleistung) sehr
> geeignet.

ca. Faktor 1,6 "langsamer". Aber nur bei der Programmausführung ...

Beim Erstellen dauert es halt mit Assembler.

es gibt mehr als C schrieb:
> Die Qualität des erzeugten
> Maschencode hängt vom Compilerbauer ab und ist von der Hochsprache
> unabhängig.

Nicht so ganz.

Sprachen mit weniger freiem Umgang mit Pointern und einem rigideren 
Typensystem haben beispielsweise weniger Probleme mit Aliasing. Zwar 
kann man C und dessen Compiler entsprechend restriktiv nutzen bzw. 
einstellen, aber typisches C erschwert manche Optimierungen.

Dank der fehlenden Arrays in der Parametrisierung (die optionale 
Schreibweise als Array ist nur ein syntaktisches Zuckerle ohne faktische 
Bedeutung) gehen dem Compiler wesentliche Information über Grenzen und 
mögliche Überlappung solcher Arrays verloren.

Seiteneffektfreie Sprachen erleichtern Compilern den optimierten Umgang 
mit Daten erheblich.

Vielen dürfte bekannt sein, dass C formal betrachtet die Rechnung 
mindestens in "int" erzwingt, was das Ergebnis angeht. Auch das ist ein 
durch die Sprache definiertes Optimierungshindernis, wie Anwender von 
8-Bit Controllern wissen.

Manches lässt sich zwar durch globale "alles auf einmal" Übersetzung 
wieder ausgleichen, weil so lokal verloren gegangene Informationen 
wieder in Beziehung gebracht werden können, aber der Aufwand steigt 
entsprechend.

g. c. schrieb:
> Kannste schnell nachholen. ;-)

Sehe ich momentan keinen Anlass

A. K. schrieb:
> Seiteneffektfreie Sprachen erleichtern Compilern den optimierten Umgang
> mit Daten erheblich.

Einserseits ja. Insbesondere wird dadurch auch die Nutzung von 
Multicore-Systemen stark vereinfacht.

Andererseits erfolgt in Funktionalsprachen die Programmierung auf einem 
sehr viel höheren Abstraktionslevel als in C. Durch diese 
"Maschinenferne" muss der Compiler komplexere Transformationen 
durchführen, bis schließlich Assembler-Code unten herauspurzelt. Alleine 
die Tatsache, dass in Funktionalsprachen (zumindest in den reinen) 
sämtliche Variablen (insbesondere auch große Datenstrukturen) immutable 
sind, erfordert einige Verrenkungen, um trotzdem halbwegs effizienten 
Code zu generieren.

Gemessen an diesen Hürden sind einige der Funktionalsprachen-Compiler 
wirklich als genial zu bezeichnen, so dass man damit durchaus auch 
rechenintensive Probleme angehen kann. Aber ganz so schnell wie in C 
laufen die Programme eben doch nicht.

Joachim Drechsel schrieb:
> ca. Faktor 1,6 "langsamer". Aber nur bei der Programmausführung ...

Das ist ne Mondzahl, die vielleicht auf einige Deiner Anwendungen 
zutreffen mag.

Z.B. wenn Du LCD-Routinen hast, sind die 50µs Delay je Datenbyte 
entscheidend und ein Laufzeitunterschied zwischen C und Assembler 
praktisch nicht merkbar. Genauso bei 100kHz-I2C, 9600Baud UART usw. usw.

Und meine 8051-Programme waren in C sogar deutlich schneller, weil die 
C-Libs viel besser optimiert waren, als meine selbst geschriebene 
Assembler-Lib.

Eine konkrete Zahl kann daher keiner nennen, alles ist möglich, von 1:10 
bis 10:1.

Peter Dannegger schrieb:
> Das ist ne Mondzahl, die vielleicht auf einige Deiner Anwendungen
> zutreffen mag.

Natürlich. Ich habe mir auch nur genau einmal die Mühe gemacht
das mal auszumessen.