Guten Tag, ein Bekannter hat mir sein Sam D21 Evalkit gegeben und ich würde gerne darauf programmieren können, jedoch habe ich in dem Gebiet keinerlei Vorkenntnisse. Gibt es gute Literatur oder sonstige Hilfe, die den Einstieg in die Mikrocontroller - Programmierung erleichtert, also die Technik von Grund auf erklärt? LG
Cubix C. schrieb: > Sam D21 Evalkit Ach, herrje. Ein so ziemlich nackiges Board, mitten drauf ein einsamer Cortex M0+ mit 48 MHz und dann auch noch von Atmel. Für mich kein Wunder, daß dein Bekannter es verschenkt hat. Kein Bootlader, nur SWD, 32 kHz Quarz. Das ist so etwas dieselbe Riege wie die Kinetis von Freescale. Hoffentlich ist wenigstens die PLL besser als bei denen. Wenn du tatsächlich irgend einen sinnvollen Rat bekommen willst, dann beschreibe zu allererst mal, von was für einem Startpunkt aus du das Spielfeld betreten willst. Als nächstes solltest du beschreiben, was du konkret mit diesem Brettl anstellen willst. W.S.
Ok, dann muss ich vielleicht doch ein bisschen ausholen. Da ich gerade in der 12. Klasse bin und deshalb Praktika mache, war ich in einem Unternehmen, was sich mit der Softwareentwicklung für "embedded systems" beschäftigt. Mir hat es dort so gut gefallen, dass mein Beruf in der Richtung sein soll. Jedoch kenne ich mich überhaupt nicht mit Mikrocontrollern aus, weshalb ich mich auf diesem Gebiet vor dem Studium noch einigermaßen gut auskennen möchte. Als ich heute das Evalboard bekam, habe ich mich natürlich sehr gefreut, jedoch weiß ich halt nicht damit umzugehen. Also ist mein Startpunkt: In C habe ich mich nur kurz eingelesen und von der Technik, die hinter Mikrocontrollern steckt, habe ich ehrlich gesagt keine Ahnung. Aus diesem Grund suche ich Literatur, die einem von Anfang an fundiertes Wissen vermittelt. Über das, was ich damit anstellen möchte, habe ich mir ehrlich gesagt noch keine Gedanken gemacht, was ich mir aber als Projekt vorstellen könnte, wäre, dass ich über das mitgelieferte Touchpad (QT6) beispielsweise LED´s dimme. Ich hoffe, diese Beschreibung war ausreichend ^^
Das ist nicht wirklich eine Hilfe, aber probier es mal damit. Das ist zumindest diesselbe Prozessorfamilie: https://www.elektormagazine.de/articles/Kurs-ARM-Controller-fur-Einsteiger-Teil-1
Cubix C. schrieb: > In C habe ich mich nur kurz eingelesen und von der Technik, die hinter > Mikrocontrollern steckt, habe ich ehrlich gesagt keine Ahnung. > Aus diesem Grund suche ich Literatur, die einem von Anfang an fundiertes > Wissen vermittelt. Dann tue dir bitte einen Gefallen und lerne erst mal ordentlich C auf dem PC. Du wirst genug Probleme mit dem µC haben, da brauchst du nicht noch eine Baustelle. Es gibt hier zu viele Anfänger, die sich über eine fehlerhafte UART Kommunikation beschweren, weil sie nicht verstanden haben, dass Strings in C mit einem Nullbyte enden! Grundlagen halt. Hol dir am besten den alten K&R also "Programmieren in C" oder besser die englische Version "the c programming language". Aber auf gar keinen Fall "C: Programmieren von Anfang an" oder ähnliche Werke! Der Preis mag verlockend sein, aber es ist voller Fehler. Der Author kann sich maximal einen Tag mit C beschäftigt haben, anders kann man sichs nicht erklären. Nur Laien, die die Beispiele im Buch nicht ausprobiert haben, können diesen Schund als gut befinden.
> Dann tue dir bitte einen Gefallen und lerne erst mal ordentlich C auf > dem PC. Wird wahrscheinlich die beste Lösung sein, hatte ich auch anfangs vor. War nur sehr verlockend, gleich mit dem Evalkit anzufangen, wenn man schon eins bekommt :D Dann werde ich zuerst C lernen und mich erst später mit µC beschäftigen Vielen Dank für den Rat :)
W.S. schrieb: > Kein Bootlader, nur SWD, 32 kHz Quarz. Das ist so etwas dieselbe Riege > wie die Kinetis von Freescale. Nein, die Atmel sind doppelt so teuer ;-) > Kein Bootlader, nur SWD Hab noch keinen getroffen der nen Werksbootloader produktiv verwendet und SWD ist ne feine Sache, kannst den Segger anstöpseln, was braucht man mehr?
:
Bearbeitet durch User
Bernd K. schrieb: > Hab noch keinen getroffen der nen Werksbootloader produktiv verwendet Das ist der absolute Standard im Production Programming, da geht niemand mit SWD ran. Die meisten ARM haben werksseitig nicht nur UART sondern auch CAN, I2C, USB, Ethernet Bootloader. Und bei NXP unterstützt FlashMagic all diese Methoden.
wie bescheuert ist das denn?! System Requierements: Visual Studio 2008 - 2015 or 15 Preview Have aber nur die Free Version installiert und er meckert...nur dafür jetzt the evualation Version installieren ist echt beknackt..ahhhh
Zudem was hier schon gesagt wurde würde ich dir auch empfehlen mit einer einfachen Architektur zu starten wie z.B. http://www.ti.com/tool/msp-exp430g2 Wenn du die Grundlagen und die C Programmierung dann halbwegs im Griff hast kannst du auf ARM wechseln.
Cubix C. schrieb: > Dann werde ich zuerst C lernen und mich erst später mit µC beschäftigen > > Vielen Dank für den Rat :) Besser nicht so, sondern anders herum. Cubix C. schrieb: > Da ich gerade in der 12. Klasse bin und deshalb Praktika mache, war ich > in einem Unternehmen, was sich mit der Softwareentwicklung für "embedded > systems" beschäftigt. > Mir hat es dort so gut gefallen, dass mein Beruf in der Richtung sein > soll. Jedoch kenne ich mich überhaupt nicht mit Mikrocontrollern aus Eben. Es gibt nen grundsätzlichen Unterschied zwischen dem Schreiben von irgendwelchen PC-Programmen und dem Schreiben von µC-Firmware. Auf dem PC hat man regelmäßig mit Dingen zu tun, die auf der Applikationsseite eines Betriebssystemes angesiedelt sind und die Schnittstelle zum Rest der Welt ist das API des BS. Wer Firmware für einen µC schreibt, der will und muß einem Bauteil auf irgend einer Leiterplatte zu der Funktionalität verhelfen, was genau dort gebraucht wird. Und dafür ist erstens die Kenntnis der gewünschten Funktionalität der Leiterplatte (sprich Baugruppe) nötig, zweitens die Kenntnis der konkreten Schaltung auf dieser Baugruppe und drittens die Kenntnis der Innereien dieses Chips, den man programmieren will. Kurzum, beim µC-Programmieren ist man nicht nur ganz nahe an der Hardware dran, sondern man steht mit 1 1/2 Beinen direkt dort drin und das restliche halbe Bein ist Programmeschreiben. Das wird von ganz vielen Möchtegern-Mikrocontroller-Programmierern hier im Forum ignoriert - und entsprechend dämliche Fragen, die auf massiver HW-Unkenntnis beruhen, sieht man hier zuhauf. Ganz klar: zu allererst stehen Kenntnisse von Schaltungstechnik. Sowohl analog als auch digital als auch Funktionalität innerhalb von Mikrocontrollern. Als nächstes stehen wenigstens rudimentäre Kenntnisse über deren Maschinencode nebst Assemblersprache. Wohlgemerkt, es geht nicht um albernes Protzen ("ein echter xyz schreibt nur in Assembler" oder so), sondern darum, die tatsächlichen Fähigkeiten eines Controllers zu begreifen. Zu allerletzt kommt das Schauen nach einer komfortableren Programmiersprache, was heutzutage in den allermeisten Fällen auf C hinausläuft. Allerdings halte ich es für durchaus nützlich, sowohl zuvor schon einmal im Leben einige Zeilen in Basic geschrieben zu haben und erste richtige Programme am PC in Pascal verfaßt zu haben. Freepascal mit Lazarus wäre hier das richtige Werkzeug. Der Grund dafür ist, daß heutiges Pascal wesentlich systematischer und auch mächtiger ist als C und man es mit Pascal deshalb deutlich leichter als mit C hat, sich einen sauberen Programmierstil anzugewöhnen. Den obengenannten Rat zu den (Mach-)Werken von Kernighan&Ritchie als Einstiegs-Literatur kann ich wirklich nicht gutheißen. Sowas kannst du dann lesen, wenn du mit Pascal einen Grundstock an Programmierwissen dir angeeignet hast und deshalb deren Ideologie/Denkweise mit kritischem Abstand zu betrachten in der Lage bist. Der Grund meiner Bedenken liegt darin, daß C eine Menge an Geburtfehlern hat, die man kennen und richtig einzuordnen verstehen sollte. Der ursprüngliche C-Entwurf von K&R war schlichtweg Bockmist, weswegen Jahre danach von Anderen heftige Korrekturen angebracht wurden, was dann ANSI-C genannt wurde. Ab da ist C ordentlich benutzbar geworden, hat aber immer noch grundlegende Entwurfsfehler, die man mal salopp gesagt in die Worte fassen kann: "In C kann man beliebig viel Bockmist bauen und sich danebenbenehmen". Deswegen der Rat, nicht zu allererst mit C loszulegen, sondern sich zuerst woanders das grundlegende Verständnis zu erwerben. W.S.
W.S. schrieb: > Den obengenannten Rat zu den (Mach-)Werken von Kernighan&Ritchie als > Einstiegs-Literatur kann ich wirklich nicht gutheißen. Sowas kannst du > dann lesen, wenn du mit Pascal einen Grundstock an Programmierwissen dir > angeeignet hast und deshalb deren Ideologie/Denkweise mit kritischem > Abstand zu betrachten in der Lage bist. Der Grund meiner Bedenken liegt > darin, daß C eine Menge an Geburtfehlern hat, die man kennen und richtig > einzuordnen verstehen sollte. > > Der ursprüngliche C-Entwurf von K&R war schlichtweg Bockmist, weswegen > Jahre danach von Anderen heftige Korrekturen angebracht wurden, was dann > ANSI-C genannt wurde. Ehm die Second Edition behandelt längst ANSI-C und die ist auch schon ganz schön alt. Zugegeben K&R mag sich nicht so einfach lesen wie andere Werke, aber er ist schon ziemlich gut (wenn man mal von der uralten skurrilen Übersetzung absieht) und vor allem fehlerfrei! Ich würde ihm ja gerne ein anderes deutschsprachiges Buch empfehlen, aber die sind alle qualitativ absolut minderwertig.
W.S. schrieb: > Wer Firmware für einen µC schreibt, der will und muß einem Bauteil auf > irgend einer Leiterplatte zu der Funktionalität verhelfen, was genau > dort gebraucht wird. Und dafür ist erstens die Kenntnis der gewünschten > Funktionalität der Leiterplatte (sprich Baugruppe) nötig, zweitens die > Kenntnis der konkreten Schaltung auf dieser Baugruppe und drittens die > Kenntnis der Innereien dieses Chips, den man programmieren will. Aus diesem Grund wollte ich ja wissen, ob es Literatur gibt, die einem diese Dinge ganz von Anfang an erklären. Ich denke, es wäre am besten, mit dem AVR - Tutorial zu beginnen, natürlich mit dem nötigen Equipment, da es für den Einstieg anscheinend besser ist. Dann, wenn ich ein einigermaßen gutes Verständnis in diesem Gebiet habe, kann ich ja immer noch auf den ARM zurückgreifen.
:
Bearbeitet durch User
Cubix C. schrieb: > Ich denke, es wäre am besten, mit dem AVR - Tutorial zu beginnen, > natürlich mit dem nötigen Equipment, da es für den Einstieg anscheinend > besser ist. > > Dann, wenn ich ein einigermaßen gutes Verständnis in diesem Gebiet habe, > kann ich ja immer noch auf den ARM zurückgreifen. Das klingt vernünftig. ARM ist toll, ja. Leistungsfähiger u.s.w. Aber ein AVR ist besser um erstmal die "Basics" zu verstehen. Viel Spaß und Erfolg wünsche ich dir. 900ss PS. Bitte bitte jetzt keine Diskussion abwerfen, warum ein ARM genauso gut ist für einen Anfänger.
Ich habe den ganz steilen Pfad direkt zum ARM genommen. Zu dem Zeitpunkt konnte ich gerade einmal ein bisschen Python programmieren. Im nachhinein würde ich auch empfehlen zunächst einmal nen AVR zum hoppeln bekommen. Der Weg war sehr steinig und den AVR-Krams benötigt man beim Hobby eh früher oder später einmal.
Nico W. schrieb: > Im nachhinein würde ich auch empfehlen zunächst einmal nen AVR zum > hoppeln bekommen. Der Weg war sehr steinig Als ich 1989 mit ARM angefangen habe gabs noch gar keine AVR :-) Und steinig war da gar nichts. Es gab ein Computer-Heft ähnlich 64er da konnte man seine ersten Assembler-Beispiele abtippen und Schaltpläne für GPIO Kram. https://de.wikipedia.org/wiki/64%E2%80%99er https://en.wikipedia.org/wiki/Acorn_User
Cubix C. schrieb: > Aus diesem Grund wollte ich ja wissen, ob es Literatur gibt, die einem > diese Dinge ganz von Anfang an erklären. hehe! Du referierst im Folgenden einfach nur auf die Frage "AVR oder ARM". Das ist gelinde gesagt Quatsch. Fang bei den Grundlagen an, befaß dich mit Problemlösungen elektronischer Art, krieg ein Gefühl für eine sinnvolle Herangehensweise. Reine Programmierer, bei denen an aller erster Stelle die Programmiersprache ihrer Wahl steht, sind sowas wie Eunuchen in µC-Gefilden. Denk mal an den ollen Spruch von Adenauer: "Wir alle leben unter dem gleichen Himmel, aber..." na lies selber. Ich sag's mal so: bloß keine Scheuklappen, sondern ein möglichst weiter Horizont. Und Literatur? Natürlich gibt es Grundlagenliteratur wie den Tietze-Schenk, oder Sparten-Literatur wie z.B. das ARRL-Handbuch - was zwar gründlich, aber eben auch ein bissel speziell ist, dazu Firmenschriften aller Art, die zum Teil wirkliche Schätze an Ideen beherbergen. Für das Kennenlernen von Programmier-Algorithmen ist mMn immer noch der Lampe-Jorke-Wengel eine allererste Adresse, wenngleich auch die konkret darunter liegende Hardware (Z80) mittlerweile weg vom Fenster ist - auf das systematische Kennenlernen der Algorithmen kommt es an. Aber nicht auf irgend eine ganz bestimmte Controller-Architektur. Ebenfalls empfehlenswert ist die DSP-Guide (The Scientist and Engineer's Guide to Digital Signal Processing), die das andere Ende der Algorithmen beleuchtet. All diese Literaturstellen sind wohlgemerkt nichts für reine Bastler und Wurschtler, die lediglich mit ihrem auf der Embedded ergatterten Evalboard oder dem tollen Raspberry eine LED blinken lassen wollen. Der Rest ist Selbststudium - mir ging es jedenfalls mein bisheriges Leben lang so. Den Nürnberger Trichter sucht man vergeblich. W.S.
Lothar schrieb: > Als ich 1989 mit ARM angefangen habe gabs noch gar keine AVR :-) Ich beziehe mich hier jetzt zwischen nem Atmega328p und nem SAM3X8E oder nem STM32F4. Den C64 kenn ich auch noch. Aber mehr als Basic war für mich Butschi damals nicht drinne :)
Nico W. schrieb: > Den C64 kenn ich auch noch. Aber mehr als Basic war für mich Butschi > damals nicht drinne Das C64 Basic war doch noch schlimmer als 6502 Assembler, weil es so wenig Befehle hatte, musste man immer direkt an die Register: https://www.c64-wiki.de/index.php/POKE Aber zur Auffrischung kannst Du Dir mal ARM Basic auf dem Pi ansehen, das hat immerhin Inline Assembler, damit kann man wirklich gut ARM lernen: https://www.riscosopen.org/content/sales/risc-os-pico https://www.riscosopen.org/forum/forums/5/topics/466?page=14 > Ich beziehe mich hier jetzt zwischen nem Atmega328p und nem SAM3X8E oder > nem STM32F4 Dass die Atmel und ST ARM konfuse Peripherie haben, da kann ja der ARM nichts für. Schau mal die LPC ARM zum Vergleich an. Oder auch den BCM im Pi, dort sind die Peripherie-Register schön organisiert. Da läuft PWM mit ein paar Bits setzen, einfacher als beim AVR.
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.