MICROKONTROLLER kontra NORMALE SCHALTUNGEN

Hi,

also erstmal muss moderner Controller nicht gleich SMD bedeuten. Diese AVRs sind im Moment wohl so die modernsten 8 Bitter und sie sind aus gutem Grund bei den Hobbybastlern verbreitet. Die gibts z.B. bis Mega32 in DIL40 und auch so Sachen wie "In System Debugging" sind ganz nett. Wenn man bei nem Mikrocontroller als Hobbymensch mal die 32 KB Grenze überschreitet ist das Gesamtgerät sowiso schon so komplex, dass man normalerweise auch andere SMD Bauteile benötigt, sei es RAM oder Kommunikationskontroller für Ethernet usw, weil man eben viel mehr Pins braucht...
SMD ist aber auch nicht wirklich schlimm. Gut, auf Lochraster isses bischen schwierig, aber mit selbstgeätzen Platinen kein Problem. Entscheident ist lediglich die Vorlage, die muss scharf und deckend sein. Der Rest geht mit alten Düppchen aus der Küch... TQFP ging in kompletter Eigenproduktion jedenfalls bei mir noch, und ich hab kein spezial Ätzzeugs. Schwierig wirds erst bei BGA, aber auch da gibts ja schon Hobbylösungsansätze
Und wenn man mal ein paar SMD Chips gelötet hat geht das auch einfacher und schneller als DIL, ganz zu schweigen vom einfacheren Layout...
Zu den freien C Compilern: Für AVR gibts nen GCC, der soll ziemlich gut sein und sogar C++ können. Im 16 Bit Sektor hab ich mal einen M16C (ich finde ein cooles Teil!) verwendet. Da gibts soweit ich weiß ein Evalboard für 50€ wo der C Compiler auch schon dabei ist. Wenn man den Chip einzeln verbaut gibts den Compiler (NC30) und Debuger (KD30) auch als 6 Montate Testversion bei denen zum Download. Danach kann man den sich vermutlich für wenig Geld kaufen oder man schaut mal kurz in die Registry
Für den 32 Bit Sektor gibts soweit ich weiss auch einen M32C oder so, aber damit hab ich mich nicht auseinander gesetzt. So der Standart Controller für 32 Bit scheind aber auch ARM zu sein, und dafür gibts soweit ich weiss auch nen freien GCC.
Für die Standart Lichttechnikaufgaben wüsste ich jetzt aber nichts, wofür man mehr als nen 16K AVR bräuchte...

Michi

P.S.: Multiplikations- und Divisionsroutinen für die AVRs gibts irgendwo auf der Atmel Webseite fertig optimiert. Durchaus auch für 16x16 Bit oder 32Bit / 16 Bit...

Zitat von "Manuela"

Die Praxis dazu besteht aus einer gepflegten Sammlung fertiger Unterprogramme die man umändert und einbindet. Nicht ganz konventionell aber durchaus effektiv, man erfindet das Rad auch da immer nur einmal

Ganz im Gegenteil, code reuse liegt voll im Trend :wink:

Es ist verlockend alles mit nem uC zu machen, und so entstehen dann die Pseudo-Schalter, die ich hasse wie die Pest.
Fallbeispiel(Hat weniger mit den Thread, als mit dem Trend zu tun): DVD-Standalone-Recorder:
Wenn der abstürzt, dann geht nicht mal mer der Ein/Aus Schalter
Ich musste das Ding schon ein paar mal vom Netz trennen -KEIN WITZ
Ich hasse es einfach, wenn man einen Schalter drückt, dass man dann warten muss, bis sich irgendeine Software bequemt etwas zu unternehmen,
die sowieso Priorität über Hardware hat, wie bei den CD/DVD-Brennern im Rechner.
Wenn während dem Brennvorgang Nero abkackt, heisst das neu booten, um überhaupt mal wieder an seine Scheibe zu kommen.
Sorry, aber wenn ich manuell eingreife und auf einen Schalter drücke, dann will ich schließlich dass was passiert, sonst brauch ich keinen :roll:

Boah, da bin ich mal drei Tage nicht im Forum und dann dieser Thread mit meinem Thema.
Als selbständiger Elektronikentwickler habe ich mich vor Jahren schon auf µCs spezialisiert.

In vielen Foren wird natürlich das Thema "Maschinensprache vs. C" diskutiert.
Ich sag's nur in diesem Forum: Alle Maschinensprachen-Freaks sollen so weitermachen
Meine Kunden freuen sich an der Stabilität meiner Programme und der Zeit, in der ich sie fertig habe (natürlich in C).
Zweifler sollten mal ein Testprogramm in C schreiben, sich das generierte Assemblerlisting anschauen und
erkennen, was sie vergessen hätten, hätten sie's in Maschinensprache geschrieben.

Wie sagte damals jemand? "PICs in C? Viel zu wenig Speicher!"
Ich programmiere auch den 12C508 (512 byte) in C

Kostenlose C-Compiler:

PIC (nur 16F84) http://www.htsoft.com
Microchip hat keinen eigen Compiler mehr und empfiehlt diesen (Vollversion)

8051: sdcc von http://sdcc.sourceforge.net/

AVR: WinAVR von http://winavr.sourceforge.net/

Habe gerade ein Projekt: Temperaturmessung an zwei Kühlkörpern eines Low-Budget-Amps. Der wärmere
der beiden steuert die beiden Lüfter. Bei niedriger Temperatur läuft kein(!) Lüfter. Starttemperatur wählbar,
Temperatur für volle Kühlleistung ebenso. Beim Einschalten kurz "volle Power" wg. Staubentfernung
Alle Parameter über RS232 einstellbar.
Mit sowas verdiene ich nicht mein Geld, ist nur Lehrbeispiel.
Bei Interesse veröffentliche ich Schaltbild, Layout und Hex-File.

Nebenbei: Den M16C (Renesas, Ex-Mitsubishi) nutze ich auch sehr gern.

Thomas

Wenn sichs einer beweisen will, dass er alles back to the roots kann
(was ja sicher nicht schlecht ist) soll er doch.
Die Zeiten sind vorbei, wo man kartenweise logikbausteine zusammenlötet,
wenn also hochsprachen da sind dann benutzt man diese auch.
Wenn dann noch funktionen wie zb für atmelMEGA usw da sind um texte auf ein display zu schreiben, dann mach ich mir doch nicht den act und freu mich drüber, wie ich jedes segmet von hand ansteuere.
ISt zwar nicht das thema, aber der ansatz ist derselbe.
Lustig wirds dann, wenn das programm mit einem compiler compiliert tut und mit dem anderen nicht... auch schon erlebt.

Bassti: Du kennst 'lpm', oder?

Performancemäßig kann man mit C gut auf die Fresse fliegen, da es halt naturgemäß nicht die register perfekt einsetzen kann und eine ganze Menge ziemlich umständlich berechnet...

Wenn man allmählich den Überblick in Assembler verliert und selbst Blödsinn macht, habt Ihr völlig Recht. C nimmt einem eine ganze Menge nachdenken ab...

Wenn man hingegen die Performance braucht und halt die Ausführung 100%ig nachvollziehen muss, bleibt man bei Assembler.
Ich zumindest finde disassembliertes C für AVR meist gruselig (exzessiver SRAM-Gebrauch, alles wird auf Teufel komm raus auf den Stack gemüllt...)

X86 asm ist grauenvoll - da gebe ich Euch Recht. Aber kommentierter asm-Code für AVR liest sich doch fast genauso gut wie C.

Wenn man das instruction set nicht beherrscht, fällt es natürlich einfacher auf sein C-Gebastel zu pochen und asm-Lösungen zu belächeln :roll:

mein persönliches Fazit: Es gibt für beide Varianten sein Anwendungsgebiet - also sollte man bei ernsthafter Auseinandersetzung auch beides möglichst perfekt beherrschen!

Hendrik

Controller in C programmieren ist schon was schönes, gerade wenn eine grössere, komplexe, zeitunkritische Kontrollaufgabe gefordert ist. Und es hat in dem ganzen Thread auch niemand etwas gegenteiliges behauptet, von daher müssen wir das hier jetzt hoffentlich auch nicht ausdiskutieren. Wie der gcc für AVR ist hab ich noch nicht ausprobiert, der NC30 für M16C hat jedenfalls in der Regel effizienten Code generiert, den ich in ASM auch nicht anders geschrieben hätte. C Compiler sind (bzw. können sein) heute schon ziemlich ausgereift, ich kann mir aber durchaus vorstellen, dass sie sich mit einer Harvard Architektur wie bei den AVRs noch etwas schwerer tun, weils eben nicht wie beim PC ist.
Wenns allerdings um zeitkritische Aufgaben geht (was ja in der Regel bei Microcontrollern der Fall ist) die man in C programmieren möchte, ist es schon sehr sinnvoll zu wissen wie der Compiler arbeitet, was er produziert und wie man es alternativ direkt in Assembler vielleicht besser machen könnte. Um ein bischen Text auf ein LCD zu schreiben oder ne Salve LEDs blinken zu lassen muss man sicherlich nicht unterhab von C schauen, aber wenn man z.B. einen Timerinterrupt hat, der mit 50 KHz aufgerufen wird und Zündpunkte für 8 Triacs aus 16 Bit Variablen ausgibt, dann macht man sich schonmal gedanken, ob das Hauptprogramm überhaupt nochmal zum Zuge kommt...

Zitat

Es gibt für beide Varianten sein Anwendungsgebiet - also sollte man bei ernsthafter Auseinandersetzung auch beides möglichst perfekt beherrschen!

Full Ack! Selbst wenn man nur in C programmiert ist eine Vorstellung, was nacher rauskommt immernoch Gold Wert.

Zitat

Die Zeiten sind vorbei, wo man kartenweise logikbausteine zusammenlötet.
stimmt, PAL

Wie langweilig... FPGA sind die Lösung, wenn einem die Microcontroller zu langweilig werden... Die aktuellsten sollen sogar die 1GHz Grenze durchbrechen (für einfache Logik).

Mich würds eher mal interessieren wie das in assembler geht, hab ich noch nie gesehen :?

Hallo zusammen,

ich möchte noch einen Einwurf zur ursprünglichen Frage machen:

Selbst wenn ein uC mehr kostet als die Handvoll diskreter Bauteile die man brauchen würde, um den selben Zweck zu erfüllen, kommen immer noch weitere Kosten dazu:

- Leiterplattenherstellung: Diskret braucht man garantiert mehr Platinenfläche als integriert. Auch werden Vias nicht gratis gemacht.

- Bestückungskosten: Ein Bestücker lebt davon, nach Bauteilen abzurechnen. Mehr Bauteile = mehr Kosten.

- Siebdruck: Je aufwendiger eine Siebdruckmaske wird (vielleicht sogar zweiseitig), desto teurer, weil mehr Lötpaste draufgeht.

Genau aus diesen Gründen werden z.B. Niedrigpreisfernostgroßstückzahlgeräte gerne auch COB-bestückt - hier wird es noch günstiger, da man sich die kompletten Gehäuse für die Halbleiter sparen kann.

Und Was die SMD-Bestückung angeht: Dient in erster Linie auch nur der Kostenreduktion: Keine Bohrungen, höhere Packungsdichte -> weniger Platinenfläche. Und TQFP lässt sich auch wirklich prima noch von Hand verarbeiten. MLF hab ich ein paar mal gemacht, aber Spaß macht es nicht BGA sollte man Leuten überlassen, die sich damit auskennen.

Zur Assembler kontra Hochsprachen-Diskussion.
Ich programmiere keine Microcontroler, aber ich war eine Zeitlang im High Performance Computing (HPC) taetig. Das ist zwar etwas anders, aber die Assembler-contra-Hochsprache-Diskussion ist auch dort relevant.

Unsere Gruppe entwickelte und implementierte unter anderem den weltweit schnellsten seriellen FFT-Algorithmus.
Grundsaetzlich war die gesamte Umgebung in Hochsprachen abgefasst, aber die tatsaechlichen Rechenroutinen wurden nicht nur disassembliert (ohne direkte Kontrolle geht im HPC kaum etwas, weil die Compiler leider etwas eigenartig sind...) sondern es wurde auch in Assembler direkt programmiert. Grund war schlicht die Performance.

In zeitkritischen Anwendungen werden auch heute noch die Kernroutinen meiner Ansicht nach am Besten in Maschinensprache abgefasst. Ich denke, das gilt auch fuer die Microcontroller.

Gruss,

Mathematiker