Einsteig in Microcontroller und Programmierung

Apr 07, 2009 445 Replies

Hallo, ich will/muss mich mit der Anwendung und Programmierung von Microcontrollern beschäftigen und bin auf der Suche nach der geeigneten Plattform und Programmier(Hoch-)sprache. Ich brauch das vor allem für Steuerungsaufgaben in der Art "Frag eine Bedienfeldmatrix mit vielen Potis, Tastern und Sensoren ab und erzeuge daraus Schaltsignale und Kontrollspannungen" (mit dem konkreten Anwendungsfall der Steuerung modularer Musik-Synthesizer und dadurch u.a. auch als MIDI-Interface).



Ich hab vor langer Zeit mal kleine 8085- und Z80-Systeme [1] aufgebaut und die in 'manuellem Assembler' programmiert - ist schon wirklich lange her und programmier-mäßig bin ich damit ziemlich 'up from scratch'. Das stört mich aber nicht, sehe ich eher als Vorteil. Die ganze Sache kann ruhig etwas Einarbeitungszeit kosten, wenn man dafür am Ende mit fundiertem Wissen und universeller Programmierkenntnis dasteht.



Hardware-seitig würde ich gerne gleich auf etwas setzen, das gut erhältlich ist (minimum 3rd Source *g*), das es auch in leistungsfähigen Varianten gibt, das flexibel erweiterbar ist und zu dem es möglichst viel und fundiertes Material gibt (ergo großer Anwenderkreis). Stromverbrauch spielt kaum eine Rolle. Auf was könnte das hinauslaufen? Auf den ersten kurzen Blick sahen AVR, PIC und FORTH ganz interessant aus. In den Geräten, die ich so verarzte, sehe ich auch viel H8 und



68er. Ich würd mich schon gerne von vorne herein auf eine Plattform festlegen - oder sollte man das umdrehen und vom Compiler abhängig machen?

Grüße und Danke, Niko


[1] Die sahen so aus:

Hallo Nikolaus,

Wenn die Einarbeistunszeit wichtig ist, ist AVR nicht schlecht. Es gibt viele Quellen im Netz und alles nötige ist weitgehend frei verfügbar.

Mit dem richtigen Compiler und den richtigen Entwicklungstools sind auch PICs ganz schön, vor allem wenn es um minimalistische Designs und geringen Stromverbrauch (im Sleep-Mode) geht. Assembler auf PICs soll übel sein, spielt aber heutzutage keine Rolle mehr.

PICs und AVR sind 8-Bitter, die für Deine Anwendung vermutlich locker ausreichen. Sobald aber viel gerechnet werden muss und Geschwindigkeit ne Rolle spielt, sollte man sich mit den 8-Bittern nicht mehr quälen.

Bei den 16-Bittern sind die MSP430 von TI und S12X von Freescale gängige Typen. Mit letzterem habe ich schon gearbeitet. Das Ding ist ne Rakete und hat inzwischen auch einen Coprozessor integriert. Da der S12X von Freescale deutlich komplexer als ein 8Bit-AVR ist, ist die Einarbeitungszeit auch höher, gerade als Neuling wird man vom Datenblatt schnell erschlagen. Entwicklungstools und Compiler muss man IMHO kaufen (nicht ganz billig).

Bei den 32-Bittern ist ARM gängig, für embedded insbesondern ARM7. Die Rechenleistung ist nicht unbedingt besser als bei den 16Bittern, das kommt auf die Aufgabe an. Der ARM kann z.B. nicht hardwaremäßig dividieren. ARMs gibts von verschiedenen Herstellern, u.a. NXP und Atmel.

Michael

Die c't hatte vor ein paar Jahren genau so ein Projekt am Start:

formatting link

Als Quelle f=C3=BCr Ideen sicher ein guter Einstiegspunkt.

Wolfgang

Hast Du doch schon gefunden (FORTH), siehe Dein letzter Abschnitt :-)

[...]

PIC und FORTH passt nicht so richtig zusammen, das hängt mit ein paar Besonderheiten der PICkel zusammen.

Ansonsten schau Dir mal HOLON an und welche Prozessoren davon unterstützt werden.

Die Deutsche Forth Gesellschaft verleiht auch komplette uC, gut als Anfang.

snipped-for-privacy@forth-ev.de

ansonsten sieh mal:

formatting link

Und wenn Du Forth erst mal genascht hast und damit klar kommst, dann sind Dir die uC Familien recht egal, sehen aus der Oberfläche von Forth so alle ziemlich gleich aus, nur unterschiedlich schnell. Von gut bis ratz-fatz ist alles dabei.

Für Deine einfachen Aufgaben recht ideal. Schau Dir mal an, was Martin Bitter so mit den Lego Computerchen alles macht.

Saludos Wolfgang

Meine 7 Sinne: Unsinn, Schwachsinn, Blödsinn, Wahnsinn, Stumpfsinn, Irrsinn, Lötzinn. Wolfgang Allinger Paraguay reply Adresse gesetzt ! ca. 15h00..21h00 MEZ SKYPE:wolfgang.allinger

Ok, das war das Stichwort und damit gibt es IMHO praktisch nur eine vernueftige Wahl. 89x51 im 44-Pin Flat Pack. Da ich den Code dafuer anderen ueberlasse kann ich zum Compiler nichts sagen. Die Jungs, mit denen ich zusammenarbeite haben bisher alle Keil benutzt (der kostet allerdings richtig Geld). Die uebliche Programmiersprache waere C.

Auch das spricht fuer die 8051 Architektur, obwohl es bei AVR, PIC und MSP430 ebenfalls grosse Fan-Gemeinden gibt. Doch wenn man am Ende der Schotterpiste in Brasilien dringend einen Programmierer vor Ort braucht, ist die Chance bei 8051 meist hoeher.

Forth? *HUST* ... SCNR. Und ja, 68er sind auch hier (USA) noch sehr gaengig in der Industrie.

Sehr nostalgisch :-)

Schon moderner ...

Gruesse, Joerg http://www.analogconsultants.com/ "gmail" domain blocked because of excessive spam. Use another domain or send PM.

Auf die Gefahr hin, mich hier in einer Elektronik-Newsgruppe unbeliebt zu machen:

Für die meisten Mess- und Steuerungsaufgaben im Eigenbau-Bereich muss man sich meiner Ansicht nach heute keinen Mikrokontroller mehr antun.

Ein WLAN-Router wie der Fonera 2.0 kostet ¤40, hat die Grösse einer Zigarettenschachtel, braucht 5 Watt aus dem Steckernetzteil, hat 180MHz,

32MB RAM und 8MB Flash, Ethernet, USB und WLAN. Das langt für ein ziemlich vollständiges Linux, auf dem Niveau dessen, was seinerzeit auf den ersten Pentiums lief. Und ein Gehäuse ist auch schon dabei :-) Die zugehörige Software und Entwicklungsumgebung ist komplett Open Source (z.B. OpenWRT). Kombinier' das mit einem Hardware-2-USB-Interface deiner Wahl, und du hast ein ziemlich universell einsetzbares Steuerungs- und Messinstrument. Das Ding programmiert sich kinderleicht, ist nicht viel schwerer als direkt für einen Linux-PC zu entwickeln. Die meisten Libraries für Linux sind auch portiert worden oder leicht zu portieren. Bei sehr grossen Stückzahlen, harten Echtzeitanforderungen oder hoher Datenrate ist der Ansatz nicht geeignet. Für ein bisschen Hardware-Interfacing schon. Wenn Du etwas komplexere Peripherie ansteuern willst ohne für die Libraries viel Geld auszugeben ist es sogar der einzige vernünftige Ansatz.

Jo

Nikolaus Riehmschrieb: "

Warum? Genaue Bgründung fehlt hier.

Was heißt "flexibel erweiterbar"? Eine Familie die weitestgehend auf- und abwärtskompatibel ist? Fundiertes Material ist Datenblatt, Erratas und Appnotes.

Ich gebe hier mal bewußt keine Empfehlung für einen Controller ab, weil einfach überhaupt nicht genügend Informationen vorliegen.

Zeichne erstmal deine Schaltpläne mit dem/den Controller/n als Black Box. Mache dir klar, was du an IO-Ports, A/D-D/A-Wandlern, PWM-Kanälen, DMA-Kanälen, UARTs, SPI-/I2C-Schnittstellen, externen Interrupts, Key-Interrupts, Timer, Capture-/Compare-Einheiten usw. benötigst und zeichne das in deine Black Box ein. Versuche dann abzuschätzen, was du an Flash/RAM, schneller Mathematik und an Taktfrequenz brauchen wirst. Überlege dir auch, welche und wie viele verschiedene Versorgungsspannungen für dich in Frage kommen (können).

Überlege dir, wie du arbeiten möchtest. Sollen es ICE, Monitor,Simulator, oder Plain sein. Wie sieht dein Budget aus? Kannst/Willst du in eine komerzielle Entwicklungsumgebung investieren, oder kommen nur freie Entwicklungswerkzeuge in Betracht?

Ist das Ganze ein komerzielles, oder ein privates Projekt? Welche Stückzahlen werden angepeilt?

Erst wenn du auf alle diese Fragen eine hinreichende Antwort geben kannst, lassen sich auch sinnvolle Antworten auf den geeigneten Controller finden.

Dirk

Rafael Delianoschrieb: "

Oder weil sie schlicht portablen Code schreiben wollen.

Dirk

Bei Code der z.B. in I/O-Registern Flags setzt und löscht dürfte das kaum möglich sein.

MfG JRD

formatting link

Nee, das ist eigentlich eine ganz andere Baustelle, bzw. genau die umgekehrte: "Was früher mit unzähligen Oszillatoren, Filtern und Hüllkurvengeneratoren in aufwendige Hardware gegossen wurde, lässt sich dank der enormen Rechenleistung aktueller Prozessoren in Software perfekt emulieren - und mannshohe Synthesizer-Burgen schrumpfen auf ein paar Megabyte im PC-Hauptspeicher."

Bei mir geht's aber eben genau um unzählige Oszillatoren, Filter und Hüllkurvengeneratoren mit aufwändiger Hardware in mannshohen Synthesizer-Burgen - und nicht um deren Emulation und simple Fernsteuerung via MIDI-Controller.

Grüße, Niko

Rafael Deliano schrieb:

Aber "count1ms++;" oder "inttext="UART"; mache ich lieber in C.

Und selbst das Setzen eines Bits kann man vernünftig erledigen:

foo_AVR.h #define IMPORTANT_PORT PORTC #define IMPORTANT_BIT PC3 #define SET_IMPORTANT_BIT IMPORTANT_PORT|=(1

Rafael Delianoschrieb: "

Wenn man seinen Code so schreib wohl nicht.

Ich verwende für meine Controller inzwischen immer eine Art HAL. In der sind dann die speziellen hardwarespezifischen Operationen abgebildet. Auf die kann ich dann mit einfachen Funktionen zugreifen, also z.B. SetTimer(TIMER_XXX, time, Callback), GetTimer(TIMER_XXX), KillTimer(TIMER_XXX), SetPWM(PWM_CANNEL_XXX, HighTime, LowTime, PWM_START) usw. Bleibe ich innerhalb einer Controller-Familie, dann sind nur marginale Anpassungen in der HAL nötig. Für verschiedene Controller-Familien habe ich jeweils eine eigene HAL. Falls ein Controller mal nicht die benötigte Hardware hat, gibt es eine Software-Emulation dafür. Das stellt sicher, dass ich fast beliebig die Controller wechseln kann, ohne irgendwas am eigentlichen Code herumschrauben und wieder alles komplett neu testen zu müssen.

Wenn das konsequent durchgezogen wird, muss man auch keine Flags in der ISR setzen. Damit will ich mich auf diesen Programmlevel gar nicht mehr mit beschäftigen müssen, es sei denn, die ISR wird in der HAL behandelt und ich sehe sie nicht von außen.

Dirk

Das würde in nanoFORTH Assembler so aussehen: PC 3 MBS, Und in nanoFORTH so: PC 3 B1! Und wenn man das in nanoFORTH so eintippt dann wird ohne viel Compilierei das Bit gesetzt, bekanntlich hat FORTH einen Interpretermodus. Was das für Testen von Hardware und Programm- teilen bedeutet können C-Programmierer allerdings wohl nichtmal erahnen.

Das sind typisch Dinge die man in nanoFORTH als ein Assemblerunterprogramm einbinden würde das sich nach aussen ( d.h. Datenübergabe ) aber nicht von einem FORTH-Befehl unterscheidet. D.h. die Routine kann man dann auch wieder sofort im Interpretermodus testen.

MfG JRD

Rafael Deliano schrieb:

compiler.h muss man halt einmal schreiben oder aus dem Netz runterladen

Johannes Deisenhoferschrieb: "

Sicher nicht. Interessante Vorschläge sind immer willkommen.

Zurück aus der Zukunft?? Laut

formatting link
soll es den erst ab 21.04.09 geben.

Dirk

Rafael Deliano schrieb:

Braucht man auch nicht ;-)))

Das einzige, was wirklich Assembler sein muss ist der Startupcode bis zu main(...)

Wo ist das Problem Interrupts in C zu schreiben ?

Ist im industriellen Bereich normal

Und bei C auch ;-)

Wir hatten mal vor 15 Jahren ein medizinisches Gerät in Forth programmiert und hinterher war sich das komplette Team einig: Nie wieder

Rafael Deliano schrieb:

Und woher weiß FORTH, an welches Bit welchen Ports die LED angeschlossen ist? Das muß ja auch irgendwo beschrieben sein.

Kann ich. Aber nur, weil ich auch in PERL programmiere ;-)

Sklavenarbeit bzw. Assembler schreiben, überlasse ich gerne dem Compiler.

Falk

An Enfield Diesel seems to do an even better job than a Harley at converting fuel into noise without much unwanted speed!

Johannes Deisenhofer schrieb:

Und ohne Linux reicht vielleicht ein 8051 ;-)))

Wenn du WLAN Ethernet und USB brauchst macht das Sinn aber für Potis und Tasten ab zu fragen und Midi über serielle Schnittstelle ...

Im Industrie Umfeld ist open source auch nicht so der Hit. Da rechnet sich ein "teurer" Compiler wenn er Time to Market Zeit spart auf jeden Fall.

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required