Hallo, für viele Einsteiger ist es ja am Anfang ziemlich schwer im Thema "AVR-Microcontroller" Fuß zu fassen. Ich bin gerade aus der Phase raus. Mich würde mal interessieren, mit welchen Büchern, Tutorien, etc. ihr euer Wissen in C für die AVRs erworben habt?! Mich hat zuweilen das Buch "Einstieg in die C Programmierung mit dem ATmega32" ziemlich verwirrt... AT
C++ am PC mit Büchern gelernt, dann war es leicht den C Anteil an sich zu betrachten, auch am PC. Programmierung von Mikrocontrollern dann direkt nach den Datenblättern und dem hiesigen Tutorial.
AT schrieb: > Mich hat zuweilen das Buch "Einstieg in die C Programmierung mit dem > ATmega32" ziemlich verwirrt... C an sich lernt man am einfachsten am PC, da kann man sich auf die reine Sprache konzentrieren. Mit den Besonderheiten, die für Embedded dazukommen, wie Bits in Ports ansprechen oder Interrupts programmieren, kann man sich dann auseinandersetzen wenn man sie braucht. Genau genommen ist C auf einem PIC deutlich schwieriger als auf einem Desktop-Computer. Gruss Reinhard
C mit K&R, AVR mit dem Datenblatt des ATmega8, alles andere wäre zu aufwendig oder unvollständig gewesen.
bei mir wars ne lange geschichte: als erstes mit nem lego-rcx und robolab(bildchensprache) dann kam der nxt und die sprache nxc(not exactly c) dann hat mich der lehrer verdonnert mit nem atmega32 asm zu lernen. dann fiel mir auf, dass es auch hochsprachen wie C gibt. tadaaaa C konnte man in den grundzügen schon, den rest hier aus dem Forum und in nem C-buch ;)
8h am tag 5Tage die Woche 6 Monate lang Progen Fehlersuchen Kaffetrinken / Fluchen (über die eigene unfähigkei den dusseligen kleinkarierten Compiler die komischen amerikanischen Indianer die da so ein beliebtes OS erfunden haben / ...) das ganze verwerfen und wieder von vorne anfangen / eine rauchen gehen ab und zu die nacht zum tag machen ... .
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, ...
Bin noch dabei, wird wohl auch nie enden. Gelernt habe ich es ganz banal durch lernen und üben, üben, üben. Alles was man dazu braucht gibt es im Netz, inkl. Compiler und Lehrbücher. Hab lange mit Basic programmiert, bis es irgendwann nicht mehr ging und ich C lernen musste. Die Umstellung war sehr mühsam aber irgendwann hat es "Klick" gemacht. C ist ein geniales Tool. Auf einmal kommt mir der Controller vor wie eine große Wiese auf der ich machen kann was ich will. Bei Basic hatte ich immer nur kleine Schubkästen die ich hin und hergeschoben und umgefüllt habe. Compiler kommen mir manchmal vor wie ein Schachprogramm. In ihrem Regelwerk in allen belangen überlegen aber links und rechts davon dumm wie Stroh.
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.
Xenix286, 2.9BSD .. Ein Freund der Systemprogrammierer an der Uni war hat mir das aufgebürdet :-) Vorher Z80ASM und Turbopascal. Gruß, Holm
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 :-)
Ulrich B. schrieb: > war schlichtweg begeistert wie > elegant man damit, verglichen mit Fortran, programmieren kann. Zunächst war der Vorteil gegenüber den damaligen BASIC-Interpretern, dass die Syntax vom Compiler 'begutachtet' wurde und Tippfehler schnell gemeldet wurden. Bei BASIC konnte irgendwann aus heiterem Himmel die Meldung "Error Line 1387" erscheinen. Nerv! Als Keil dann seinen C51-Compiler für 8051 herausbrachte, war das ein idealer, bezahlbarer Ersatz für die bisherige Programmierung in Assembler. Schleifen, Vergleiche, Felder von Strukturen: alles easy. Kompakt optimierend, Hardware-nah und richtig schnell.
Brian W. Kernighan, Dennis M. Ritchie: The C Programming Language aber die englische Version :o)
C mit K&R und später ein Draft von Bjarne Stroustrup zum "demnächst" erscheinenden c++.
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.
Patrick B. schrieb: > ... Man musste > sich nicht mit Speicher herumschlagen auf den Servern (ist ja genug da). > Ebenso wenig mit der Geschwindigkeit... Genau diese Einstellung ist verantwortlich dafür. daß heute soviel schlechte Software am Markt ist :( ...
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. ;)
Zitat von der 2. Web-Seite
>Für das Verständnis dieses Skriptums sind solide Kenntnisse der >Programmierung
in Pascal von Vorteil; an zahlreichen Stellen werden >Sachverhalte auch durch
einen Vergleich mit Pascal zu erläutern versucht.
Super Sache.
;-)
Da kann man doch gleich bei Pascal bleiben, dessen Quelltexte
sind nämlich leserlich.
-Algol
-Pascal
-Turbo-Pascal
-Lazarus
das ist, geht's auch.
gez. Buna-Pelzer
AT schrieb: > Mich würde mal interessieren,... neugierig, oder was? Wenn ich dir schreibe, daß ich DAMALS mit dem Compiler von van Zandt und Z80-Crossassembler am PC den Sozobon-Compiler (68k) so umgeschrieben habe, daß er Z80-Code produziert, dann hilft dir das auch bloß nicht weiter - oder? Was mich damals am meisten angewidert hatte was K&R. Als später ANSI aufkam, war das ne Erleichterung. Seitdem stehen bei mir die Wörter Kerni* und Ritc* auf der schwarzen Liste. Ich hätte wirklich nix dagegen, wenn die beiden sich damals irgendein anderes verdammtes Hobby ausgesucht hätten und ihre Pfoten von BCPL weggelassen hätten. Jetzt haben wir den Salat, den auch ANSI nicht wirklich hat ausbügeln können. Apropos: Kennt eigentlich hier noch einer den Hisoft-Pascal-Compiler? W.S.
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.
Random ... schrieb: > 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. Absoluter Schwachsinn! C ist eine stinknormale Hochsprache. Die Qualität des erzeugten Maschencode hängt vom Compilerbauer ab und ist von der Hochsprache unabhängig.
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.
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.
Joachim Drechsel schrieb: > ca. Faktor 1,6 "langsamer". Aber nur bei der Programmausführung ... Es kam tatsächlich schon mal vor, daß ich ein Stück C-Code in funktionsgleichen Assembler umschreiben mußte. Der µC kam bei einer seriellen Übertragung von großen Blöcken in und aus FIFOs nicht mehr mit der Geschwindigkeit hinterher. 115200 BAUD und Quarz 7,3728 MHz an einem alten 8051 mit 12-Cycle-Core. Da kann man sich an fünf Fingern abzählen, daß es für heutige Maßstäbe bestimmt nicht berauschend ist. Das waren Vorgaben, ich wollte für diese eine Aufgabe nicht gleich einen neuen µC bestellen, hatte ja bereits ein Board mit weiteren speziellen Teilen drauf. Die Hand-Optimierung wurde dann am Ende noch so schräg, daß es mit dem mehrmals optimierten Assemblercode doch noch gut lief. Es hätte allenfalls noch ein einzelner NOP-Befehl in den Code gepaßt. Wie beim Seemannswunsch: Immer eine Hand breit Wasser unterm Kiel. Am Ende optimierte ich einzelne Instruktionen, suchte für 2-Zyklen-Befehle 1-Zykus-Befehle raus. Der doppelt so schnelle Quarz 14,7456 MHz hätte es auch getan, den hatte ich aber nicht im Haus. Letztendlich wäre dann auch der Energieverbrauch des Boards noch gestiegen. Oder halbe Baudrate, doppelte Wartezeit für die Blockübertragung, auch lästig. Dann hatte ich den SDCC-Compiler, der die multiplen Datapointer eines 80C517A nicht unterstützt, sondern nur Standard-8051-Code macht. Es ist also gehopst wie gesprungen, ich hätte auch die Compiler-Libraries ändern können. Auch das kostet Zeit und Aufwand. Ein Keil-Compiler kann das, kostet auch ordentlich. Es ist bei mir aber Hobby, da kommt es nicht auf meine Arbeitsgeschwindigkeit an, kann mal locker einen ganzen Tag mit sowas vergeigen. Andererseits habe ich eine immer noch nicht fertige Portierung von Assembler nach C hier liegen. Etwas umfangreicher. Denn der alte Code ist 8051-Assembler, ich möchte das Programm aber mal für andere µC verwendbar machen. Das geht nur über den Umweg Portierung in eine bekannte Hochsprache, z.B. C. Auch mußte ich teilweise den Zwischenweg wählen, erst Flußdiagramme zu erstellen. Denn mit Direktübersetzung kam ich nicht an allen Stellen durch. Assembler zu Assembler direkt umportieren ist noch kniffeliger, und bestimmt großer Nonsens.
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.
AT schrieb: > Mich würde mal interessieren, mit welchen Büchern, Tutorien, etc. ihr > euer Wissen in C für die AVRs erworben habt?! Also zum Thema, Threadüberschrift: C fand ich für mich bislang für alle Zwecke OK. Lernen: Grundlagen C in einem Studienfach, wozu es Labor und Klausur gab. Viel weiß man dann noch nicht. Den K&R, die Referenz, lernte ich aber da kennen, und kaufte ihn. Nach wie vor ein gutes Nachschlagewerk. Gelernt habe ich hauptsächlich an Beispielen, die z.B. die µC- und Compileranbieter im Internet haben, bzw. auch Buchbeispiele. Das, was ich immer aktuell gerade brauchte. Wenn ich dort was nicht verstand, erst dann wieder der Griff zu Tutorien und Nachschlagewerken. Ich bin nicht so der Typ, abstrakt ein Tutorial von A-Z streng durchzuackern. Im Job bearbeitet man ja zwangsläufig auch nur ein bestimmtes Thema, Projekt, nicht die gesamte Elektrotechnik. Und dort sucht man sich ja auch, was man gerade braucht. Den Anspruch, C mal vollständig zu kennen oder können zu wollen, erhebe ich für mich nicht. Einzig zu PSPICE arbeitete ich einmal einen guten Buchkurs mit Beispielen durch, es ist einigermaßen umfangreich. Der Kurs war auch didaktisch sehr gut aufgebaut. Dort muß ich aber auch immer wieder nachschlagen.
Thread beobachten
Seitenaufteilung abschaltenBitte 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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.