MICROKONTROLLER kontra NORMALE SCHALTUNGEN

MCUs bieten die Möglichkeit, via ISP die Eigenschaften der schon existierenden Zielschaltung zu verändern.

Wenn früher eine Schaltung existierte, musste man mit Ihr leben bzw. eine völlig neue designen. Heutzutage kann man, wenn sich die Anforderungen ändern, einfach ein Firmwareupdate draufspielen und hat nix in den Sand gesetzt.

Durch geschickten Einsatz von MCUs werden Schaltungen flexibler. Überzogenes Beispiel: Die Firmware entscheidet, ob die Schaltung ein D-Amp oder eine Umwälzpumpenansteuerung wird. Das spart enorm Kosten...

Andererseits macht der Einsatz von Controllern in Billigstschaltungen keinen Sinn (Billigstlauflicht, Blinker, Kaffeemaschine): Die Entwicklung der Firmware verschlingt Zeit und Geld. Wenn also ein NE555 und/oder 2-3 Komparatoren reichen, nimmt man diese Variante. (Das Verhalten ist in dieser Größenordnung auch bei 'dummen' Komponenten besser simulierbar...)

Bei allem was darüber liegt, führt eine MCU schneller zum Ziel. (C sollte man natürlich können...)

Grüße, Hendrik

Kommt auf den Einsatzbereich an. Bei rein schaltenden Steuerungen oder nicht allzu schnell regelnden Steuerungen erhält bei mir ganz klar der uC den Vorzug. A/D's und PWM's meist schon an Board, ebenso Kommunikation nach außen: RS232, I2C usw. Software kann man halt ganz leicht ändern, ne Platine nicht.

Wo ich von uC's abrate sind schnelle Regelungen, z.B. eine PFC. Die sorgt in Schaltnetzteilen dafür, dass das Teil sich nahezu wie ein ohmscher Widerstand verhält und über die gesamten 180° eine Halbwelle Strom lutscht anstatt nur in der Nähe des Spannungsscheitels.
Für sowas braucht man Minimum zwei Regelkreise, einen Multiplizierer, sowie eine PWM-Stufe.
In der Fachzeitschrift "Elektronik" (http://www.elektroniknet.de) war mal eine 500W-PFC vorgestellt die auf einem recht schnellen Fixkomma-DSP von Texas Instruments basierte (wenn ich mich richtig erinnere). Es waren verschiedene Oszillogramme abgedruckt und das Teil tat auch was es sollte, jedoch ist es meiner selbstgebauten vollanalogen PFC bei geringen Stromaufnahmen deutlich unterlegen. Meine macht noch einen einigermaßen sinusförmigen Strom, während die digitale schon ziemlich übel am verzerren war. Und daß obwohl meine für eine 3x größere Leistung ausgelegt ist, also bei kleinen Leistungen eher noch pingeliger sein müsste.

Wohl eher ein DSP
Multiplizieren kostet bitter... das geht nicht so lässig mit nem MC wies von vorne aussieht.
Die AD-Wandler sind auch langsam...
so einfach isses (noch) nicht
->da löt ich leber ein paar opamps zam :wink:#

Ich sag nur "Onlinedebugging an der Endstufe" KEIN WITZ!!!

Hallo,

also erstmal finde ich den Titel dieses Threads etwas "böse" gewählt.
Idealerweise ergänzen sich Microcontroller und analoge Schaltungsteile um die positiven Eigenschaften beider zu vereinen. (Als normale Schaltung würde ich heutzutage übrigens welche bezeichnen, welche uC drin haben *g*)
Auch Digitaltechnik arbeitet mit der analogen Physik und das merkt man auch, wenn man mit den Taktfrequenzen über die bei 8 Bittern üblichen geht. Irgendwo hab ich mal gehört: Analogtechnik ist wie Unix - Man muss eine Menge verstehen, damits überhaupt mal läuft, Digitaltechnik ist wie Windows - Am Anfang läuft alles auf Anhieb super toll, aber wehe es hakt mal irgendwo und man hat keine Ahnung von der Analogtechnik...
Um mit einem Controller ein Gesamtsystem zu bauen braucht man immer Analogtechnik: Spannungsversorgung, Taktversorgung, Leistungshalbleiter, Sensorik usw... Ein Mikrocontroller verleiht den um ihn herum angeordneten analogen Komonenten eine unglaubliche Flexibilität und "Intelligenz". Gerade komplexere Steuerungen (z.B. Positionssteuerungen für Movinglights usw.) werden so wesentlich einfacher und besser realisierbar.
Manu, deine Aussage, dass man uC vermehrt einsetzt obwohl sie nicht nötig wären würde jemand, der digital favorisiert vielleicht gerade umdrehen und fragen: "Warum die ganze aufwändige Analogtechnik obwohl das doch auch ein kleiner uC könnte?"
Ein interessanter Punkt (den mal unser Mikrorechner Prof erwähnte) ist auch, dass analoge Schaltungen oft noch irgendwie abgeglichen werden müssen. Das ist für Einzelstücke sicher kein Problem, in der Massenproduktion hat man aber lieber einen uC der direkt funktioniert und gibt dafür auch gerne 2 Cent mehr aus, als wenn man an jedem Exemplar noch einmal Messen und zwei Potis einstellen muss.
Letztlich hängt die Verwendung von Controllern natürlich von den Anforderungen an die Schaltung ab. Für richtiges HF gibts soweit ich weiss noch nichts gutes digitales, für einfache niederfrequentere Analogtechnikaufgaben artet eine digitale Lösung schnell in richtige Arbeit aus, weil man sich mit dem ganzen Abtasttheorem Zeugs schlagen muss. Hat man das aber einmal geschafft so eröffnen sich einem Möglichkeiten der digitalen Signalverarbeitung, die auf analogem Weg gar nicht möglich sind. Allerdings verwendet man für diesen Zweck dann DSPs. Das sind sozusagen spezielle Mikrocontroller, die besonders auf die Verarbeitung "durchfliessender" Daten spezialisiert sind (Fourier usw...). Die haben dann z.B. aufwendigere Adresslogiken, eine speziell auf solche Aufgaben ausgelegte ALU und können über mehr als einen Bus dann auch gleichzeitig auf verschiedene Speicherbereiche zugreiffen.
Mikrocontroller sind wie der Name schon sagt vor allem zum Kontrollieren von recht komplexen Geschichten geeignet, Sachen die mit Analogtechnik nicht möglich wären.
Ein auch nicht zu unterschätzender Vorteil jeder digitalen Schaltung sind ihre Kommunikationsmöglichkeiten. Jeder uC oder DSP verfügt über verschiedene solcher Schnittstellen. So lässt sich ein entwickeltes System (auch im Nachinein) einfach mit anderen Komponenten vernetzten und so ein noch viel leistungsfähigeres Gesamtsystem schaffen.

Mein Fazit: Sicherlich kann man viel mit Analogtechnik lösen, aber oft führt ein uC einfacher zum Ziel und ist zudem im Nachhinein flexibler, wenn man sich Einzelheiten der Schaltung doch nochmal anders überlegt.
Aber immer mit Gewalt einen uC einsetzten zu wollen ist sicherlich auch nicht richtig...
Notwendiges Übel ist natürlich immer eine Software, die man zusätzlich Erstellen muss und wenn man in dieser Richtung noch keine Erfahrung hat muss man bei den ersten Projekten dort auch einige Zeit rein investieren.
Java programmieren können hilft bei Mikrocontrollern meiner Meinung nach übrigens so gut wie gar nicht Ich würde jedem Anfänger erstmal empfehlen in Assembler zu programmieren, um den Controller wirklich kennenzulernen und zu verstehen.

Hier gibts noch ein paar Links zu dem Thema:

http://www.dse-faq.elektronik-kompendium.de/dse-faq.htm#F.7
http://www.dse-faq.elektronik-kompendium.de/dse-faq.htm#F.30.2

Viele Grüsse,
Michi

Zitat von "Manuela"

ich trau mich erst langsam da dran. Bislang nur 8-Bitchen gebastelt (obwohl die teils noch umständlicher sind)

Z80B, 6502, 8051 usw.
Aber diese neuen 16 und noch breiter, auweia :shock: Das sind Männer CPUs, das blick ich nichtmehr durch *g*

Na komm, wenn Du den 8051 schon kennst, dann ist es zu seinen großen Brüdern ja nicht mehr weit...
6502 ist auch süß...oder der 6510 aus der guten alten C64 Zeit...*erinnerungenschwelg*...

Es gibt da aber sehr nette Fachliteratur...ich habe damals z.B. beim 8051 mit dem "Mikrocontroller Kochbuch" angefangen

Schöner Beitrag von Michael D, bin aber keinen Schritt weiter :cry:

Ein vielleicht nicht ganz passendes Beispiel was mir vor einiger Zeit passiert ist:
Rechner hochgefahren, [...] irgendwann hing die Maus(USB) einfach.
Ok das übliche: neu Booten.
irgendwann hing die Maus wieder.
Schon Panik geschoben, Virus etc. nix gefunden.
Adapter hergenommen, und das Ding an den PS2 angeschlossen.
AAAAAAAAAAAha! Wackler im Kabel. :wink:

Was ich sagen will ist dass dieser Trend immer mehr know how in die Software zu stecken durchaus auch seine Schattenseiten hat.
Wenns tut ists ne feine Sache, wenn nicht... :shock:
Da kommen dann die Momente, wo man den Eindruck hat, es tut wenns will.
(Die vermeintliche digitale Schwelle ist in der Analogtechnik, entweder es tut oder es tut nicht bzw. man riecht, dass es nicht tut :D)
Ich bin kein Gegner der uCs, aber um LEDs blinken zu lassen nimm ich höchstens 2 Transistoren.

Jaja, die Manu und die antike Technik...
Also eine höhere Bitbreite eines Prozessors macht ihn sicherlich nicht sonderlich komplizierter. Ein externes 16 Bit Businterface kann einen mal kurz ins Grübeln versetzten weils dann auch noch ne Unterscheidung zwischen High und Lowbyte gibt. Aber ansonsten sind die einfach nur leistungsfähiger, vorrausgesetzt die Anwendung passt dazu, d.h. man kann den breiteren Datenbus auch effektiv nutzen. Und dann wirds ehr einfacher, weil das Programm effizienter wird und man weniger zeitkritisch programmieren muss und sich bei 16 oder 32 Bit Additionen keine Gedanken um Carrybits usw. machen muss. Und Hardware Multiplier/Divider haben die dann auch drin usw..
Und Prozessoren >= 16 Bit sind ja auch meist für grössere Aufgaben gedacht, also vielleicht mit Grafikdisplay und son Schnickschnack. Das hat aber auch zur Folge, dass man die schön effizient in C programmieren kann. Desto grösser der Prozessor, desto mehr gehts dann in Richtung PC programmiererei -> einfacher...
Mein Tipp: Wenn das nächste Projekt ansteht welches nicht morgen fertig sein muss und wo sich ein Controller lohnen könnte einfach mal ausprobieren. Ruhig auch mal mit nem modernen z.B. AVR, die sind halt mit bis zu 20MIPS schon ziemlich schnell.

Bassti, deinen Beitrag verstehe ich nicht so ganz. Wackler im Kabel hätte auch bei Analogtechnik Probleme gemacht. Übrigens finde ich in solchen Fällen ist digital im Vorteil (wenn die Software gut ist), weil mit ner ordentlichen Fehlerkorrektur verringert sich in so einem Fall nur die Datenrate, aber was übertragen wird ist immernoch richtig. Mach das mal mit analog... Aber es gibt natürlich gute und schlechte Firmware, das ist wie bei den analogen Schaltungen auch.

Zitat

Ich bin kein Gegner der uCs, aber um LEDs blinken zu lassen nimm ich höchstens 2 Transistoren.

Geb ich dir recht. Aber wenn die LEDs Teil einer Videoleinwand sind, fänd ich digital wieder geeigneter

Zitat von "Michael D"

Bassti, deinen Beitrag verstehe ich nicht so ganz. Wackler im Kabel hätte auch bei Analogtechnik Probleme gemacht.

Ja, aber da merk ichs sofort dass es ein wackler ist, während wenn die maus einfach stehen bleibt sich erstmal ratlosigkeit breit macht.
Ging vielleicht nicht so direkt hervor, was ich gemeint hab

Zumal sehe ich bei meinen mitstudierenden die schaltungstechnische phantasielosigkeit.... was nicht zuletzt dadurch hervorgerufen wird, dass man für jeden schei... nen uC einsetzt.
Das wird in den künftigen Generationen nicht besser.

Zum Thema "Normal" vs SMD -ich mach nur SMD, wenns irgendwo reinpassen muss, hab auch schon oft gesehen, das auf quadratmetergroßen platinen SMD Widerstände drauf sind, im weiten umkreis Leere, da frag ich mich dann schon..

Reparieren ist auch zunehmend out. :wink:

Problem ist auch an die C-Compiler ran zu kommen. Bei den meisten kann man ein "Development-Kit" bekommen, aber der Compiler macht meist nur 2-4kB Maschinencode um Appetit auf die teure Vollversion zu machen...

Gibt's nicht irgendwelche legale Freeware, z.B. für C166 oder so? Bin schonmal im Internet über sowas für PIC-Controller gestolpert wo ein Informatikstudent einen eigenen funktionstüchtigen C-Compiler programmiert und kostenlos ins Netz gestellt hat...

und dann??

hoffen , dass ein RISC oder Z80 eine Fremdsprache à la x86 versteht?

Servus!

Was mir bei den Softwarelösungen etwas Bauchschmerzen bereitet ist, dass oft halbgare Produkte auf den Markt geschmissen werden, schließlich kann man durch ISP ja Features nachliefern und Bugs beheben. Die PC-Softwareindustrie macht's vor...

Manu, was deinen HEX-Editor betrifft: Es mag im Massenmarkt sicher gerechtfertigt sein wenn man mittels großem Personalaufwand seinen Assemblercode bis aufs letzte optimiert, da macht es sich bemerkbar wenn man dadurch ein paar Cent durch einen kleineren µC/DSP/FPGA spart.
In kleinen Stückzahlen oder für den Hobbybastler macht es aber mehr Sinn wenn er sich den Baustein ein, zwei Nummern größer kauft und in einer Hochsprache programmiert, sieht man von primitiven Aufgaben einmal ab. Sicher läuft das dem Ehrgeiz des einem oder anderen Ings zuwieder, das letzte aus der Hardware rauszuholen :wink:, aber das wird in Zukunft zunehmend die Praxis sein.
Wir haben uns auch über die "Klickibunti"-Programmierversuche der WI-Studenten in VB oder mittlerweile Java amüsiert während wir C mit Notepad und Kommandozeile gemacht haben. Das ist aber der Trend.

Was C-Compiler für µCs betrifft: GNU-C gibt es auch für AVRs und MSP430. Leider habe ich seit einiger Zeit nichts mehr mit dem Thema zu tun, so dass ich da nichts konkretes beitragen kann. Google sollte aber einiges dazu ausspucken.

Viele Grüße,
Holger