Mikrokontrollertechnik

[ChristianF]

Moin moin,
ich möchte mich mal auf einem anderen Feld des Lowlevel beschäftigen, und habe mir dafür die Mikrokontrollertechnik, wie das bei mir in der Schule genannt wurde herausgesucht.
 
Was ich gerne machen möchte:
Ein kleines Gerät bauen, dass ein analoges Signal (z.B. von einer Gitarre) in ein digitales umwandelt, dieses irgendwie modifiziert (sollte hörbar sein ), wieder in ein analoges umwandeln und an eine Box, einen Lautsprecher, schicken.
 
Nun ist es doch ein oder zwei Jahre her, als ich mich das letzte Mal mit so etwas beschäftigt habe. Ich müsste mich also wieder einlesen... 
Gibt es hier jemanden, der sich mit ähnlichen Themen beschäftigt hat? Könnt ihr mir eventuell etwas Literatur empfehlen, das die Grundlagen der Mikrokontrollertechnik abdeckt?
 
Gruß Christian
 
PS: So etwas kann man auch als Vertiefung zum Studiengang "Elektro- und Informationstechnik" studieren (evtl. ja ein Thema für mich nach meinem Zivi) 
 
EDIT:
Kann ich hier auf einen Mikroprozessor zurückgreifen, oder sollte ich mich besser mit FPGAs beschäftigen?

[MasterLee]

In der Schule hatten wir einen Mikrocontroller, ich glaub es war eine 6502 Variante von Siemens die hatte Analog-Digital-Converter und Digital-Analog-Converter auf dem Chip.

[ChristianF]

Welche Schule war das denn? Wir hatten glaube ich auch irgend einen Mikrocontroller von Siemens...

[Svenska]

Am einfachsten nimmst du dir einen µC mit einem A/D-Wandler, also einem Analogeingang. Was du dann damit tust, bleibt allein dir überlassen.

Als Ausgang hast du oft einen D/A-Wandler in den µCs drin, notfalls hängst du ein Widerstandsgrab (Widerstandsleiter) hinten dran. Auf die Weise hab ich mal einen Verstärker über LPT angeschlossen (vgl. Covox Speech Thing).

Du musst das Audiosignal hinreichend oft sampeln, um eine vernünftige Datenbasis zu bekommen; da du wahrscheinlich mit dem Audiosignal im Zeitbereich nicht viel anfangen kannst, solltest du deine Effekte im Frequenzbereich einbauen - also das Signal vorher Fouriertransformieren und danach invers Fouriertransformieren. Damit dürftest du einen kleinen 8-Bitter aber überfordern... da bräuchtest du einen DSP.

MIDI ist demgegenüber einfacher zu implementieren (=> ist eine serielle Schnittstelle mit komischer Baudrate), aber eben digital. Auf mikrocontroller.net werden Sie geholfen.

Gruß,
Svenska

[erik.vikinger]

Hallo,


Mikro-Controller mit ADC und DAC drin gibt es mehr als reichlich.
Wenn Du damit Audio verarbeiten möchtest brauchst Du aber etwas Rechenleistung unterm Plastik-Deckel, da würde ich eher zu den 32 Bit ARM-lingen raten. Da gibt es z.B. von NXP die LPC2000-Serie, aber auch von sehr vielen anderen Firmen gibt es die mit unterschiedlichster Ausstattung. Es gibt für fast alle davon einfache Evaluation-Boards, wenn da nicht zu viel drauf sein muss geht der Spaß von etwa 40 Euros bis ca. 100 Euros (es geht aber auch deutlich teurer/umfangreicher wenn Du willst), der Vorteil ist das Du ein fertiges Board bekommst auf dem alles wichtige drauf ist und auch schon alle Kabel, Netzteil usw. mit im Karton liegt.

Der Hinweis auf mikrocontroller.net kam ja schon. Das Forum dort ist sehr gut und geht auch ohne Anmeldung.

Ein richtiger Audio-DSP eröffnet Dir natürlich ganz andere Möglichkeiten aber erfordert auch eine deutlich steile Lernkurve und etwas mehr Geld (dafür sind z.B. auch die ADCs und DACs von deutlich besserer (Audio-)Qualität). Nebst dessen das sich damit weniger Leute beschäftigen und Du möglicherweise nicht so einfach Rat und Hilfe bekommst.

Der Einstieg ins Thema FPGA ist gegenüber einer µC deutlich anspruchsvoller (man kann es aber auch als Herausforderung betrachten) und für ein vernünftiges Einstiegs-Board legt man problemlos über 200 Euronen hin. Für einen SW-Programmierer (wo alles sequenziell abgearbeitet wird) ist das entwickeln von Logik (wo alles parallel arbeitet) schon was neues, war für mich auch so, so das man zumindest Erfahrung im programmieren von Multithreading-Programmen (mit vielen Threads) haben sollte. Auf mikrocontroller.net gibt es übrigens auch ein Unterforum für VHDL.

edit: Ich vergaß zu erwähnen das Audio-Verarbeitug im FPGA zwar möglich ist aber auch eine wirklich enorme Herausforderung darstellt. Ein weiterer Aspekt ist das die Compilezeiten bei FPGAs deutlich höher sind, ich hab schon große Projekte gehabt wo selbst ein flotter PC mal eine Stunde dran werkelt bis ich die letzte Quell-Code-Änderung testen konnte (das Try-and-Error-Vorgehen mancher SW-Entwickler fällt da schon mal weg) und das schreiben einer guten Simulation kann dann schon mal ein komplexes Projekt für sich werden.


Grüße und viel Erfolg!
Erik

[ChristianF]

Ich werde auf jedenfall mal weiterschauen...
 
Allerdings müsste ich erst einmal mein Grundwissen (Elektrotechnik, Digitaltechnik) auffrischen und erweitern. Was auch interessant ist, ist, dass man anscheinend einige Effekte direkt über die Hardware, sprich ohne Mikrocontroller usw., realisieren kann... wenn ich jetzt noch den Link wiederfinden würde -.-

[Programm Noob]

Hallo

Ich bastle nun auch schon seit fast einem halben Jahr mit µC´s rum. und muss sagen, die sind einfacher zu programmieren als nen x86er. macht auf jeden fall sehr viel Spaß. Nur leider habe ich deswegen keine Zeit mehr für´s OS -Dev 

Programm Noob

[erik.vikinger]

Hallo,

und muss sagen, die sind einfacher zu programmieren als nen x86er.

Das war ja wohl auch zu erwarten, so einen Sch.... wie bei x86 hat sich noch nie ein anderer CPU-Hersteller getraut zu verkaufen. Ich glaube keine der CPU-Architekturen, die in den letzten 20 Jahren entwickelt wurden, ist so dermaßen vermurkst wie x86.

macht auf jeden fall sehr viel Spaß

Dann mach das weiter!


Grüße
Erik

[Svenska]

Liegt aber daran, dass x86 bereits 30 Jahre alt ist... fast alle anderen Architekturen sind jünger.

[PorkChicken]

Ich würde ja erstmal grundsätzlich infrage stellen, dass x86 "vermurkst" ist.

[erik.vikinger]

Hallo,

fast alle anderen Architekturen sind jünger.

Ich bin mir nicht ganz sicher aber 68k dürfte in etwa das selbe Alter haben und war von Anfang an schon nicht so vermurkst. Die aller ersten Anfänge von ARM (damals noch mit 26Bit-Adressen) müssten doch auch etwa aus dieser Zeit sein. Ich kenne mich leider mit den ganz alten CPU-Architekturen nicht wirklich aus aber so viel schlimmes wie bei x86 hab ich da nie gelesen. Ich hab vor allem noch nie gelesen das x86 für irgend etwas anderes Vorbild war, von altertümlichen CPUs wie PDP-11 liest man sowas schon eher mal.

Ich würde ja erstmal grundsätzlich infrage stellen, dass x86 "vermurkst" ist.

Darf ich Eure geschätzte Aufmerksamkeit auf sowas http://www.agner.org/optimize/blog/read.php?i=25 lenken?
Auch finde ich die Befehls-Architektur von x86 alles andere als geschickt. Das ging damals schon deutlich besser (siehe PDP-11).


Grüße
Erik

[Programm Noob]

macht auf jeden fall sehr viel Spaß

Dann mach das weiter!

Werde ich .

Programm Noob

[Svenska]

Bei ARM ist Kompatiblität auch nicht so wichtig (deswegen sind die 26-Bit-ARMs ja inzwischen auch vollkommen inkompatibel zu den jetzigen 32-Bit-ARMs) und es gibt insgesamt komplett inkompatible Versionen (z.B. Cortex-M0, die können nur Thumb) und es gibt einen Wildwuchs an inkompatiblen Basen. Sowas hätte sich der PC-Markt nicht leisten können. Bedenke auch, dass x86 auf Kompatiblität zu 8-Bittern abgezielt hat und nie auf Weiterentwicklung. Traurig, dass es dabei geblieben ist.

Die 68k-Architektur ist quasi-ausgestorben, Motorolas ColdFire wird nur sehr selten verwendet. Die PDP-11/VAXen waren Großrechner und DEC wollte die niemals so einsetzen, wie IBM das vorhatte. Zumal es ja dort 16-, 18-, 32- und 36-Bit-Maschinen gibt.

x86 ist das einzige, was immer mit der Kompatiblität in Rückhand entwickelt wurde.

Was nicht heißt, dass µCs keinen Spaß machen - ich hab selbst ein paar auf Messen zugeworfen bekommen.

[erik.vikinger]

Hallo,

Bei ARM ist Kompatiblität auch nicht so wichtig (deswegen sind die 26-Bit-ARMs ja inzwischen auch vollkommen inkompatibel zu den jetzigen 32-Bit-ARMs) und es gibt insgesamt komplett inkompatible Versionen (z.B. Cortex-M0, die können nur Thumb) und es gibt einen Wildwuchs an inkompatiblen Basen.

Naja, die ganzen Thumb-Varianten sind auf speziellen Bedarf der ganz kleinen Mikrocontroller hin entstanden (extrem kleiner Energiebedarf und extrem kleine Siliziumfläche), die sind nicht für die "normale" Verwendung gedacht. Die größeren 32Bitter dürften auch noch 15 Jahre alten Binär-Code ausführen können. Selbst wenn nicht, so sind die Befehlssätze doch extrem ähnlich so das man das meiste eigentlich nur noch mal durch den Assembler jagen müsste. Für den Compiler sind die verschiedenen ARM-Befehlscodierungen jedenfalls kein allzu großes Problem und selbst wenn kann das dem Programmierer, ebenso wie dem End-User, ziemlich egal sein. (Die 26Bitter sind auch schon seit mindestens 20 Jahren Out-of-Date)

Sowas hätte sich der PC-Markt nicht leisten können.

Wieso? Das tut er doch. Denke nur mal an SYSCALL vs. SYSENTER, Vanderpool vs. Pacifica oder MMX vs. 3Dnow vs. SSE (dieser Kampf ist wohl eindeutig zugunsten von SSE entschieden aber das andere läuft noch und bereitet den OS-Codern so manche Schwierigkeit).

Bedenke auch, dass x86 auf Kompatiblität zu 8-Bittern abgezielt hat und nie auf Weiterentwicklung. Traurig, dass es dabei geblieben ist.

Ja, das ist wirklich sehr traurig. Wer hat schon Programme auf seinem Computer deren Compilation mehr als 10 Jahre zurück liegt? (Okay ich, aber sonst wohl kaum jemand) Wie man sein OS von PowerPC nach x86 nach ARM portiert, ohne das die User damit ein Problem hätten, hat Apple ja eindrucksvoll gezeigt. Ich persönlich denke nicht das Rückwärtskompatibilität das Maß der Dinge ist.

Die 68k-Architektur ist quasi-ausgestorben, Motorolas ColdFire wird nur sehr selten verwendet.

Sicher? Ich sehe die noch ab und an.

Die PDP-11/VAXen waren Großrechner und DEC wollte die niemals so einsetzen, wie IBM das vorhatte.

Das schmälert aber nicht das einfach elegante Design der PDP-11.

x86 ist das einzige, was immer mit der Kompatiblität in Rückhand entwickelt wurde.

Ja, aber alle anderen haben kapiert dass das nicht so extrem wichtig ist das man dafür so einen Scheiß bauen muss.


Grüße
Erik

[Svenska]

Hallo,

ich geb dir grundsätzlich Recht.

Die Geschichten mit SYSCALL/SYSENTER kamen ja auch erst später auf und haben vor allem einen Markt getroffen, der sehr umsatzstark - und sehr kompatiblitätsbedacht - war. Außerdem hat AMD meistens eine Vorreiterstellung gehabt und Intel dann (wahrscheinlich aus Prinzip) eine dazu inkompatible Lösung geschaffen. Via sitzt ja genauso dämlich da.

ColdFire sieht man nur gelegentlich, aber neuere Projekte setzen da meistens nicht drauf, da sind MIPS/ARM halt die Großen der Branche. Ein PDP-11-Notebook hätte natürlich auch was, mit 2.11BSD, aber der Zug ist weg. (Wobei es FPGA-Implementationen gibt, aber was soll man damit eigentlich. 2.11BSD hat ja nichtmal poll()...)

Kompatiblität ist DAS Zugpferd für x86, alle anderen haben vielleicht begriffen, dass es nicht so sein muss, aber selbst Apple ist auf den Zug aufgesprungen. Und ich glaube nicht, dass ARM-Netbooks so große Verbreitung finden werden (oder MS Windows nicht-CE jemals für ARM existiert); die Architektur ist verkorkst, wir leben immernoch mit BIOSen, können keine Festplatten jenseits 2TB adressieren - aber es gab nie einen wirklich harten Umstieg. Plus die Garantie, dass es einen solchen mit den PCs auch nicht geben wird.

Die Lösung von Apple für den Umstieg hängt mit Design-Entscheidungen zusammen, die m.M.n. genug Nachteile mit sich bringen.

Übrigens kann Qemu seit kurzer Zeit auch Windows NT/MIPS emulieren (die Firmware der MIPS Magnum ist jetzt Freeware) - zum Probieren: "qemu-system-mips64el -M magnum -hda ... -cdrom ...", einstellen und dann "cd:\mips\arcinst" (für die Systempartition) und "cd:\mips\setupldr" vom ARC aus ausführen. Das waren auch komische Biester, an sich normale PCs mit anderen Prozessoren; teilweise sogar mit memory-mapped ISA (ISA = CPU-Bus des 8086...).

Gruß,
Sebastian

[taljeth]

Wer hat schon Programme auf seinem Computer deren Compilation mehr als 10 Jahre zurück liegt?

Och, ich hätte da ein paar DOS-Spiele anzubieten.

[PorkChicken]

Darf ich Eure geschätzte Aufmerksamkeit auf sowas http://www.agner.org/optimize/blog/read.php?i=25 lenken?
Auch finde ich die Befehls-Architektur von x86 alles andere als geschickt. Das ging damals schon deutlich besser (siehe PDP-11).

Der Autor führt da ja ähnliche Kritikpunkte an, wie du in deinem folgenden Beitrag. Seine Folgerung (Standardisierung bzw. Kooperation) ist allerdings weniger drastisch als die Forderung sich von x86 auf dem Desktop abzukehren, wenn auch mMn eigentlich genauso unrealistisch.

Ich kann mir nicht vorstellen, dass der Verzicht auf Rückwärtskompatibilität überhaupt praktisch umsetzbar ist. Neben der Henne-Ei-Geschichte ist da vermutlich vor allem die Übergangsphase problematisch. Es müssen zwangsläufig alte und neue Softwareversionen parallel verwendet werden. Mit OSS kann man das Problem nicht vollständig lösen (mangelnde Verbreitung) und Emulatoren würden eher die Übergangsphase verlängern und dem Wechsel entgegenwirken.

Ich denke nicht, dass die einzige verbleibende Alternative ist, (ich sag mal) bei jeder sich bietenden Gelegenheit über x86 herzuziehen. Die Architektur musste einfach so werden wie sie ist. Weder war der 8086 besonders schlecht, noch sind die Erweiterungen in sich besonders schlecht. Ich bin kein Experte für ARM/68k/PDP-11/... und erst recht nicht für deren Märkte, aber ich denke mal, dass auch da die Entwickler und Hersteller kommerzielle Interessen verfolgen. Hätte IBM 1979 in seinen PC einen 68k eingebaut, wäre dieser jetzt so "vermurkst" wie x86.