Ab wann lohnt sich ein 32bit Controller? Compilerkosten?

@  Askan S. (Gast)

>Auswertung von Sensordaten, desto schneller desto besser.

"je schneller desto besser"

Aber auch mit korrekter Grammatik ist diese Aussage falsch. Es gibt 
IMMER einen sinnvollen Rahmen, indem die Aufgabe erfüllt werden muss.

Also.

Wieviel Daten sollen in welcher Zeit mit welcher Operation bearbeitet 
werden?

>Da dachte ich mir long (32Bit?), könnte ich nicht 30-40% an Leistung
>gewinnen wenn ich auf 32 Bit setzen würde.

Fehlt da am Ende ein Fragezeichen? Denn so hat der Satz keinen Sinn.

>Aktuell habe ich einen Atmega64 mit 16Mhz. Da geht die Geschwindigkeit
>schon merklich runter,

Was heisst bei dir "merklich" ?

>Oder ist es besser und wirtschaftlicher einen schnelleren Prozessor zu
>kaufen?

Schneller ist der sicherlich. Die ARM-Prpozessoren sind ja schon seit 
einiger Zeit in aller Munde und sehr preiswert verfügbar.

> Soweit ich weiß sind die 32bit Compiler extrem teuer. oder?

Auch dort gibt es kommerzielle und freie Compiler. Wie gross die 
Leistungsunterschiede sind weiss ich nicht.

>Aktuell habe ich WinAVR, der kostet ja nichts.

Es gibt auch WinARM.

MFG
Falk

Askan S. wrote:
> Da dachte ich mir long (32Bit?), könnte ich nicht 30-40% an Leistung
> gewinnen wenn ich auf 32 Bit setzen würde.

Einen Leistungsgewinn kann man erst ermitteln, wenn man die bisherige 
CPU-Auslastung kennt.

Also, wie oft müssen welche Berechnungen ausgeführt werden?




> Aktuell habe ich einen Atmega64 mit 16Mhz. Da geht die Geschwindigkeit
> schon merklich runter

Runter in Bezug auf was?

Oftmals wird fälschlich ein Programmteil verdächtigt, aber es ist ein 
anderer (z.B. LCD-, UART-Ausgabe) oder der Programmteil wird unnötig oft 
ausgeführt.


> Soweit ich weiß sind die 32bit Compiler extrem teuer. oder?

Den GCC gibts doch auch für 32-Bitter (z.B. ARM Cortex M3), aber 
manchmal ist er etwas kniffelig zu installieren und zu konfigurieren, 
ehe er läuft.

Eine ähnlich sorgenfreie Ready-to-run Installation, wie den WINAVR gibt 
es wohl nicht.


Peter

Es gibt genau zwei Möglichkeiten.
1. Entweder dein Programm ist wirklich schon so komplex, dass es 
wirklich Rechenpower braucht.
2. Oder Die Ausnutzung der Prozessorressourcen ist nicht optimal gelöst.

Ich vermute mal eher letzteres so aus dem Bauch heraus. Ein Ferrari wird 
im ersten Gang auch nicht wirklich schnell ;)

Askan S. wrote:
> Danke für die Antworten. Ok, nicht besonders toll formuliert.

Stimmt.
Und warum formulierst Du dann Deine Fragen nicht besser?


Du mußt schon Deine Frage interessant machen, also das Problem 
schildern.
Oftmals ergeben sich weit bessere Optimierungsmöglichkeiten als das 
sture Tim Taylor Prinzip: mehr Power.


Nur Abfrage von Werten macht eine Frage nicht interessant, die wirst Du 
dann wohl selber im Web raussuchen müssen.
Abgesehen davon gibt es nich den 32-Bitter, einer mit Hardwaredivision 
wird naturgemäß schneller sein.


Peter

Nach meiner Erfahrung kann man sehr viel mit einer besseren 
Programmierung erreichen. Eine direkte Umsetzung einer mathematischen 
Formel in ein Programm ist meist ineffizient. So kann die Hardware des 
ATMEGA zwar multiplizieren, aber nicht dividieren. Eine Division ist 
also vergleichsweise "teuer". In vielen Fällen kann man aber z.B. statt 
einer Division durch eine Konstante die Multiplikation mit ihrem 
Kehrwert verwenden. Braucht man bei einer Divison auch noch den Rest, 
kann man ldiv verwenden, anstatt mit / und % die Division zweimal 
durchführen zu müssen.

Man kann mit Tabellen arbeiten anstatt Werte explizit auszurechnen. Man 
kann vereinfachte Rechnungen durchführen, wenn ihr Ergebnis für den 
angestrebten Zweck noch ausreichend genau ist. usw.

Das würde ich erst einmal ausschöpfen bevor ich eine neue, mir bislang 
unbekannte Prozessorfamilie ins Auge fassen würde.

Liebe Leute und all ihr guten Programmierer. Ist schon wahr, dass gute 
Algorithmen oft erstaunliche Verbesserungen bringen. Allerdings gilt das 
auch dann, wenn der Controller selbst mehr Leistung bringt. Bei 
derselben Programmierung (demselben guten Programmierer oder Anfaenger) 
wird "der" 32-bit Controller, den es nicht gibt, deutlich schneller sein 
fuer long Variablen als ein AVR8, ATMEGA oder sonst ein 8-bitter. Der 
grosse Vorteil beim 32-bit controller sind die Register, die 32-bit 
breit sind, die Befehle, die 32-bit Variablen als Input verwenden und 
last but not least die moegliche Taktgeschwindigkeit, wenns denn mal 
schneller werden soll.

Jetzt komm mir bitte keiner mit der Power, denn die geforderten 
Berechnungen kann ich mit einem 32-bit Rechner bei ca. 1/3 der Frequenz 
gegenueber einem ATMEGA ausfuehren. Als mal spasshalber einen ATMEGA mit 
16 MHz und einen LPC2134 oder STM32 mit 5 MHz im Datenblatt vergleichen. 
Zu allem Ueberfluss wir der Code auch noch deutlich kompakter auf dem 
32-bit controller. Das passiert immer dann, wenn ich mit einem kleineren 
Controller Klimmzuege machen muss um die Berechnung auszufuehren. Als 
grober Masstab kann man hernehmen, wer ein 8-bit Programm auf einen 
32-bit controller portiert verdoppelt den Speicherbedarf. Wer ein 32-bit 
Programm, also mit ueberwiegend 32-bit Variablen von einem 32-bit auf 
einen 8-bit controller portiert verdoppelt den Speicherbedarf ebenfalls. 
Das Geruecht, der 32-bitter braucht VIEL mehr Speicher, kommt daher, 
dass typischerweisse ein Aufstieg vom 8-bitter zum 32-bitter passiert 
und sich der Speicherbedarf deutlich erhoeht. Wuerde ein Programm von 
neuem geschrieben und haette gleich viele 8/16/32/64-bit Variablen, da 
gaebe es wohl kaum einen Vorteil fuer den 8-bitter.

Wenn also meine Welt die der Einzelbits und Chars ist, dann hat der 
8-bitter seine Staerken. Wenn meine Welt mehr in Algorithmen zuhause 
ist, die mit 256 diskreten Werten (8-bit) nicht auskommen, dann wird der 
32-bit controller sehr interessant.

Fuer ein neues Projekt, das ueberwiegend 32-bit Daten verwendet einen 
8-bit Rechner einzusetzen, erscheint mir einfach der falsche Ansatz, 
egal wie gut oder schlecht der Algorithmus ist. Die 32-bit controller 
gibts zu vergleichbaren oder niedrigeren Preisen, Entwicklungsumgebungen 
gibt es sehr viele, weil viele Anbieter. Angenommen es wuerde ein ARM7 
oder Cortex-M3 werden, dann gibt es definitiv mehr als 10 verschiedene 
Anbieter und alle scheinen noch recht gut zu laufen. Yagarto waere z.B, 
ein Anfangspunkt. Weil der ARM eine Verbeitung hat, von der andere 
Architekturen nur traeumen koennen gibt es einfach so viele 
Moeglichkeiten.

Also mein Rat, einmal in den (nicht so) sauren Apfel beissen, mit ARM 
das Projekt erledigen und danach wahrscheinlich nie mehr nach hinten 
schauen.

Gruss, Robert

Ueber Tools gibts einiges hier: http://www.lpc2000.com/tools habe dort 
kostenpflichtige und kostenlose Tools sehr kurz beschrieben und links 
dazugepackt.

Für eine grobe Abschätzung kann man auch einfach mal eine 
Entwicklungsumgebung (µ-Vision Demo, oder MPLab und C32) installieren 
und eine einfache Schleife mit dem Algorithmus schreiben. Sofern ein 
Simulator vorhanden ist, hat man eine relativ genaue Abschätung der 
Performance. Möglicherweise werden die Verzögerungen, welche durch die 
Unterbrechung der Instruktions-Pipelines entstehen, nicht 100-%ig 
richtig simuliert, aber der Rest ist schon recht gut.

Schau mal hier:
Beitrag "Re: LPC2103 63MIPS?"
http://www.mikrocontroller.net/attachment/highlight/16997

Da hatte ich mal den Versuch unternommen ein paar Controller zu 
vergleichen. Habe letztens auch mal einen PIC32 (80MIPS/32Bit/C32) mit 
einme PIC24 (40MIPS/16Bit/C30) vergleichen. Bei reinen 16 Bit 
Berechnungen war der PIC32 ca. doppelt so schnell, wenn man mal von den 
Spezialfunktionen der dsPICs absieht. Sobald dann aber 32 Bit Interger 
oder Floats verwendet wurden, war der PIC32 teilweise bis zu 10x 
schneller als ein PIC24@40MIPS.

Von der Programmierung sind die 32-Bitter genau so einfach wie die 
8-Bitter. Einzig die etwas komplexeren Interruptcontroller und die 
Takterzeugung brauchen minimal mehr Einarbeitungszeit.

Ich unterstelle mal vorsichtig, daß die Wahl des Richtigen Compiler auch 
noch etwas Einfluß auf die Performance hat.

Hallo alle

Wie ist eigentlich die Registerorganisierung bei den 32 Bitter? Gibt es 
bei denen auch mehrere Registerbänke die umgeschaltet werden können ?

MFG Patrick

Meinst Du Register = CPU Register oder das RAM/ROM Banking der uralt 
PICs?

Speicher und Peripherie wird beim ARM7 (LPC2103) und MIPS (PIC32) linear 
angesprochen. Du hast "quasi" eine von Neumann Architektur. Auch die 16 
Bit PICs können Flash-ROM ins RAM einblenden, so daß der Speicher auch 
weitgehend linear erscheint.

Der ARM7 hat 15 oder 16 32-Bit MCU Register, von denen einige, je nach 
Interrupt-/MCU-Mode, Shadow-Register haben. Werden also bei Fast 
Interrupts automatisch geswitched.
Der PIC32 (MIPS-32) hat 31! 32-Bit MCU Register. Für die höchstwertigste 
ISR gibt es 31 Shadow Register, so daß hier keine Register in SW 
gerettet werden müssen. Für alle anderen ISRs muß das dann aber in SW 
gelößt werden.

In ARM7/MIPS32 Assembler stecke ich nicht tief genug drin. Aber hingegen 
all meinen bisherigen Erkenntnissen ist die MIPS-32 Architekture die 
einzige mir bekannte, die ohne Flags (Carry, Zerro, Negativ, und so ...) 
auskommen muß. Dieses führt insbesondere bei Berechnungen mit mehr als 
32 Bit schon mal zu einigen zusätzlichen Instruktionen. Auf der anderen 
Seite scheint der MIPS-32 (PIC32) viele Befehle tatsächich in einem 
Zyklus auszuführen, während ich beim ARM7 (LPC2103) eher das Gefühl 
habe, daß da die meißten Befehle im Schnitt bei ca 2 Zyklen liegen. 
Anders herum hat der LPC2103 Stärken, wenn es um die Rotation von Bits 
geht. Ich habe beim MIPS-32 auch keine Pre- oder 
Postincrement/-dekrement Befehle gefunden.

Sowohl LPC2103 als auch PIC32 können mit vollem Tempo aus dem Flash 
heraus arbeiten. Ein Sprung dauert bei beiden ein oder zwei Zyklen 
extra, wobei der PIC32 den Befehl nach der Sprunganweisung ausführt, 
während die Pipeline mit neuen Befehlen vom Sprungziel gefüllt wird. Was 
zu einer kleinen Leistungssteigerung führt.

Der C32 (Compiler für PIC32) hat aber auch noch einige Schwächen. Siehe 
hier: http://forum.microchip.com/tm.aspx?m=386539&mpage=1&key=&#386539

Hab grad wieder bei den LPC2103 etwas nach gelesen. Da steht was von 
Thumbs Befehlen usw . Was bedeutet dies nun genau ?

MFG Patrick

Sowohl ARM7 als auch MIPS32 verfügen sowohl über einen 32 Bit als auch 
über einen 16 Bit Befehlssatz.

Der 16 Bit Befehlssatz braucht etwas weniger Speicher (30% oder so), ist 
dafür aber auch etwas langsammer.

Der Thumb Mode ist der 16-Bit Befehlssatz des LPC2103. Ich würde auf ihn 
verzichten, wenn Du mit dem LPC2103 hantierst. Zum Thumb-Mode gibt es 
auch noch einen Know-Bug. Siehe Errata Sheet des LPC2103.

Henry wrote:
> Für mein jetziges Privat-Projekt mit viel float 32-Bit Arithmetik habe
> ich auch von ATmega auf einen 32-Bit Controller gewechselt. Das ist bei
> gleicher Taktfrequenz ein mächtiger Sprung.
>
> Dabei bin ich auf den, in Europa weitgehend unbekannten, ZNEO von Zilog
> gegangen. Der rechnet grundsätzlich alles mit 32-Bit und kann auch
> MUL/DIV in Hardware.

Das Dingen hat doch nichtmal ne FPU, wieso benutzt du dann float? In 
aller Regel ist float unnötig oder gar schlecht. Fixkomma ist die 
bessere Alternative.

Henry wrote:
> Warum verwende ich Gleitkomma-Arithmetik?
>
> Ich habe keine Freude an Tüfteleien mit dem Zahlensystem. Das hat mit
> dem Kern meines Problems und dem eigentlich interessanten Teil nichts zu
> tun.
Damit stellt man sich aber ganz ganz schnell ein Bein. Gleitkomma ist ja 
auch nur eine Annäherung an die Zahlen.
Wobei man bei Fixkomma sich im Voraus schon Gedanken machen MUSS, wie 
das mit der Genauigkeit ist ;)

> Heute gibt es Controller mit ausreichend Kraft für menschenfreundliche
> Zahlendarstellung. Soll sich doch der µC quälen. Ich bin kein Masochist.
Ja, wobei man aber für Gleitkommaoperationen eigentlich eher einen 
Controller mit FPU nehmen sollte.

Es gibt Aufgaben, da ist Fliesskommaarithmetik schlicht einfacher. Klar 
kann man oft drum herum rechnen, aber spätestens bei der 
Sonnenaufgangs/Untergangszeit wird das etwas umständlich. Das hat aber 
zunächst rein garnichts mit 8bit vs 32bit zu tun, denn ein 8bitter kann 
das genauso - nur nicht so schnell, allenfalls behindert von bisweilen 
mangelnder 64bit Rechnung. Es spricht nichts dagegen, sie zu verwenden, 
wenn schnell genug. Und dank ausreichend Register schneidet AVR dabei 
garnicht mal so schlecht ab.

Aus reinem Intresse - Welchen der wirklich unzähligen verschiedenen µCs 
mit 32Bit würdet ihr den nem Einsteiger empfehlen. Einsteiger meint, 
dass das ding lohnt sich einzuarbeiten, es relativ kostengünstig in Hard 
und Software ist und vllt auch etwas verbreitet also, dass bei Problemen 
irgendwo ne Anlaufstelle ist ^.^

Das Intresse kommt daher, dass ich gerne auch mal Projekte verwirklichen 
würde, die z.b. mit Lan arbeiten, sowie nen VGA-Monitor, was sicher 
alles auf den Megas geht wie man das in der Codesammlung bewundern kann 
aber manchmal reicht halt nicht oder nur mit einschränkungen. Würde 
einfach gerne genau wie der Treadautor für sowas dann auch auf stärkere 
Hardware zurückgreifen können.

Gruß ErgoProxy

Meinst du die AVR32? Ps bisher habe ich eigendlich nie einen Debugger 
bei den Megas gebraucht ^^ glaub da käm ich auch ohne aus. Also 
eigendlich brauch ich nur Software und Programmierhardware und vllt n 
Tipp wie die einfachste normale Schaltung zu realisieren ist. Das die 
komplizierter sein wird als bei den Megas ist mir klar.

Gruß ErgoProxy

Ich kenne eigentlich nur PIC32 und LPC210x. Mir scheint der PIC32 im 
Moment etwas leistungsfähiger. Allerdings kommen die "dicken" 
Erweiterungen (128kRAM on Chip, Ethernet, CAN,...") wohl frühestens 
2009.

WinARM ist zwar nicht schlecht, aber ohne Simulator etwas umständlich.
Keil µVision Eval ist super, aber auf 8 oder 16k Code beschränkt. Es 
werden glaube ich 32k von Keil angegeben, aber wie auch immer hatte ich 
nach dem Kompilieren immer einen 16k großen Block mit 0x00 in der 
Ausgabe, so daß unterm Strich nur 16k oder so übrig blieben. Einen 
Bootloader + Hardware kann man sich für wenige Euro selber basteln. Hier 
meine Variante: http://home.arcor.de/bernhard.michelis/LPC/index.html 
Sie läßt sich auch mit der sonst üblichen Bootloader SW für LPC2xxx 
benutzen.

Für den PIC32 empfiehlt sich MPLab und C32. Als Programmer für ca. 22€ 
(http://home.arcor.de/bernhard.michelis). Kann zwar nicht debuggen, aber 
mit etwas Vorbereitung tracen ;-)

Das Hauptproblem für jemanden, der neu einsteigt, ist nicht, daß 
32-Bitter großartig schwieriger währen, was die Programmierung angeht. 
Da ist es sogar zum Teil eher umgekert (32-Bitter => leichter). 
Allerdings gibt es die meißten 32-Bitter nur in den Gehäuseformen mit 
0,5mm Pitch und kleiner.

Das interessante am PIC32 ist, daß seine Peripherie denen der 
PIC24/dsPIC33 entspricht, so daß man mit Chips in handlicher Gehäuseform 
(TQPF-44/SO-28) beginnen kann und bei Bedarf auf PIC32 umsteigen kann. 
Es gibt für die PICs auch vorbereitete Bibliotheken. Aber bitte 
beachten: 
http://forum.microchip.com/tm.aspx?m=391938&mpage=1&key=&#392340

Andreas K. wrote:
> ... bisher habe ich eigendlich nie einen Debugger bei den Megas gebraucht

Solche Saetze lese ich hier im Forum immer wieder. Und jedesmal sage ich 
mir: "Entweder sind das Genies, oder ich bin etwas unterbelichtet"
Ohne Debugger würde ich ein Projekt erst gar nicht anfangen.

Ich verwende gelegentlich einen Debugger, komme aber zu 99% ohne aus. 
Bei ARMs wird er manchmal nötig, bei AVRs so gut wie nie. Es ist einfach 
so dass ich mit Trace-Ausgaben auf LED/UART summarum auch ganz gut zum 
Ziel komme. Vorausgesetzt die Ladezeit hält sich in Grenzen. Nicht 
selten geht deutlich Zeit drauf, bis man bei einem Debugger am 
kritischen Punkt ist, sofern man den auf das entsprechende Event oder 
die problematische Stelle überhaupt gezielt triggern kann.

Es gibt allerdings Bereiche in denen er ziemlich essentiell ist. Wenn 
man beispielsweise an Startup-Code, Interrupt-Dispatchern und 
Initialisierungen bei ARMs drechselt, oder an den grundlegenden 
Elementen eines RTOS. Für's Tracing fehlt da schlicht die Infrastruktur.

Wenn man im Laufe der Zeit auf einem Dutzend verschiedener Plattformen 
hantiert hat, dann funktioniert Tracing trotzdem praktisch immer gleich, 
beim Debugging hingegen kämpft man jedesmal mit einem anderen Debugger. 
Wenn man überhaupt sowas zur Verfügung hat - beispielsweise waren zu 
6502- und 68000-Zeiten Quellcode-Debugger nicht oft anzutreffen. Man 
gewöhnt sich schlicht daran, ohne auszukommen, auch dann wenn man 
könnte.

Gast wrote:

> So spricht die Jugend von heute :-(

O tempora o mores, wie schon die alten Römer sagten. Wenn dir in einem 
Forum als erstes dieser Satz einfällt, dann weisst du dass du deine 
Jugend schon deutlich hinter dir hast. Wenn es dich beruhigt: Es ergeht 
der vor dir erwähnten Jugend später auch nicht anders ;-).

Gast wrote:
> Es gibt viele Entwicklungsboards für wenig Geld und in der Codegröße
> begrenzten Compilern, was für viele Anwendungen ausreichend ist. Wenn Du
> erst einmal mit 32Bittern warm geworden bist, möchtest Du nicht mehr auf
> kleinere µCs zurück.

Was heiß zurück?
Hast Du immer nur ausschließlich Monsteranwendungen?

Ich finde es schon sinnvoll, einen für die Aufgabe passenden MC zu 
verwenden, der dann auch mal zu über 10% ausgelastet wird.

Es kann auch wesentlich günsiger sein, statt eines Boliden, mehrere 
kleinere MCs zu verwenden, wenn dadurch das PCB und die Verdrahtung 
bedeutend einfacher werden und weniger EMV-Probleme bestehen.


> Wozu auch? Der Preis ist genauso günstig

Also für 0,70€ (Reichelt: ATtiny13) habe ich noch keinen 32Bitter 
gesehen.


> und die
> Leistung deutlich höher.

Aha, Du bestückst also alle MC-Platinen auch immer mit 400V-Elkos und 
10W-Widerständen.
Leistung lohnt sich nur dort, wo man sie auch braucht.


Peter

Gast wrote:
> So spricht die Jugend von heute :-(

Ich komme aus einer Zeit, als es Linux noch nicht gab und AT&T-Unix 
Marktführer war. Aus einer Zeit, in der man Fenster-Applikationen mit 
curses programmierte. Und, so als Fussnote, in der eine 20MB 
SCSI-Harddisk 2.000 USD kostete.
Aber auch damals, wenn ich mich an das Terminal setzte (ja, ja, damals 
gab es noch fast keine PC's), kontrollierte ich zuerst, ob sdb 
installiert war.

Aber wie gesagt, ich schliesse die Möglichkeit einer Unterbelichtung 
nicht aus :)

Gast wrote:
> Du mußt Dich nicht entschuldigen, wenn Du in Deinem Leben noch nichts
geleistet hast.

Wenn Du im Forum so herumstocherst und Dir die Beitraege von  Peter 
Dannegger anschaust, wirst Du vielleicht merken, wie unangebracht diese 
Bemerkung war.

Wieso müssen immer alle Threads so verrissen werden. Im Endeffekt muß 
sowieso jeder selber entscheiden, was er will.

Der Grund für die Fragestellung dürfte schlicht sein, daß man mal die 
Meinung anderer hören möchte. Was man letztlich nimmt, muß man selbst 
entscheiden.

Im übrigen: Man kann vieles optimieren. Welche Lösung am Ende 
tatsächlich die beste ist, hängt von den Zielen ab, die man sich setzt.

Es mag sein, daß ein 8-Bitter rein technisch für eine Aufgabe sehr gut 
geeignet ist. Vielleicht gibt es aber für den 32-Bitter Bibliotheken die 
man verwenden möchte. Oder man will sich eben nicht mit der technischen 
Optimierung auseinandersetzten, weil das zulange dauern würde. Habe ich 
die 10-fache Rechenleistung zur Verfügung, kann ich 10x so schlecht 
programmieren ;-) und erhalte immer noch ein gutes Ergebnis.

Im übrigen, Optimierung kostet auch Zeit. Und was nützt es 3 Euro bei 
den Komponenten zu sparen, wenn ich dafür eine Woche länger brauche, bis 
alles zu meiner Zufriedenheit läuft?

Und nicht zu vergessen. Hat man sich erst einmal auf einem 
Mikrocontroller eingearbeitet, kommt man schneller ans Ziel, als wenn 
man ständig zwischen den Controllern hin und her schwenkt. Habe ich 
jahrelang so gemacht.

Immer den optimalen Controller zu verwenden macht letztlich nur dann 
Sinn, wenn man dabei Ressourcen spart. Hat man ein Produkt, daß in hoher 
Stückzahl vertrieben wird, macht es Sinn extra Arbeit zu investieren, um 
vielleicht ein paar Cent zu sparen. Baut man sein Projekt nur einmal auf 
(Hobby-Bereich), nehme ich daß, was am schnellsten zum Ziel führt oder 
wo ich bereits über Erfahrung und Tools verfüge.

Ein schneller/großer Controller kann in den meißten Fällen die Aufgaben 
eines kleinen/langsamen Controllers übernehmen, mal abgesehen vielleicht 
von Stromsparanwendungen. Umgekehrt allerdings selten.

Habe ich einen wirtschaftlichen Nutzen/Spaß an einer technisch möglichst 
optimalen Umsetzung, mache ich mir die Arbeit und tausche Zeit gegen 
Geld. Ist mir meine Zeit wertvoller, als ein paar Euro, nehme ich die 
Sachen eine Nummer größer und tausche Geld gegen Zeit.
Natürlich spricht auch nichts dagegen, einen kleinen Controller zu 
verwenden, wenn man ihn bereits kennt, die nötigen Tools hat und 
beherscht.
Letztlich muß man sich entscheiden, was eine "Gut Lösung ausmacht". 
Schnell ans Ziel kommen oder eine günstig zu reproduzierende Lösung.

Bernd M. wrote:

> Es mag sein, daß ein 8-Bitter rein technisch für eine Aufgabe sehr gut
> geeignet ist. Vielleicht gibt es aber für den 32-Bitter Bibliotheken die
> man verwenden möchte. Oder man will sich eben nicht mit der technischen
> Optimierung auseinandersetzten, weil das zulange dauern würde.

Niemand hat behauptet, daß man einen 8-Bitter nehmen muß, wenn es an 
dessen Grenzen geht. Bloß oftmals wissen viele nicht, wo die realen 
Grenzen eines 8-Bitters liegen und unterschätzen diesen total.
Man muß also beim 8-Bitter nicht lange optimieren oder sogar Zyklen 
zählen. Es reicht schlichtweg, wenn man einfach geplant programmiert.


> Habe ich
> die 10-fache Rechenleistung zur Verfügung, kann ich 10x so schlecht
> programmieren ;-) und erhalte immer noch ein gutes Ergebnis.

Schlechtheit läßt sich aber nicht quantifizieren.
Es reicht ein simples delay_ms(1000) in Deiner Mainloop und Dein 
Programm ist so grottenschlecht, da hilft auch keine 512Bit-CPU.


> Im übrigen, Optimierung kostet auch Zeit.

Aber planvolle Programmierung spart sogar Zeit.


> Und was nützt es 3 Euro bei
> den Komponenten zu sparen, wenn ich dafür eine Woche länger brauche, bis
> alles zu meiner Zufriedenheit läuft?

Ich hab noch nicht viel Erfahrung mit 32-bittern, aber sie ist 
gegenteilig.
Das PCB dauert länger, ist wesentlich teurer und mehr EMV-empfindlich.
Ich hab auch nicht den Eindruck, daß die Programmierer damit merkbar 
schneller ihre Projekte fertigstellen.


> Und nicht zu vergessen. Hat man sich erst einmal auf einem
> Mikrocontroller eingearbeitet, kommt man schneller ans Ziel, als wenn
> man ständig zwischen den Controllern hin und her schwenkt.

Das stimmt. Deshalb versuche ich möglichst viel mit den 8-Bittern zu 
machen, die ich länger kenne.
Das gleiche Arbeitstempo auf nem 32-Bitter zu haben, wird noch einige 
Jahre dauern.


> Ein schneller/großer Controller kann in den meißten Fällen die Aufgaben
> eines kleinen/langsamen Controllers übernehmen

Die Entwicklung geht aber in umgekehrter Richtung (intelligente 
Sensoren, Aktoren), d.h. viele kleine MCs.
Diese MCs kümmern sich um das Aufbereiten der Daten und die zentrale CPU 
verschickt nur Befehle und empfängt Daten.
Ich hab z.B. ein Gerät, wo Parameter nicht mehr als DAC/ADC-Werte auf 
dem Bus verschickt werden sondern als SI-Einheiten (V,A,°K usw.).

Nur bei hohem Kostendruck und großen Stückzahlen lohnt sich noch eine 
einzelne CPU.


Eine optimale Lösung gibt es nicht.
Man sollte aber versuchen, eine effiziente Lösung zu erreichen in Bezug 
auf Kosten, Entwicklungszeit und Zuverlässigkeit.
Reine Programmierer vergessen oft, daß Schaltung/PCB/EMV auch 
Entwicklungszeit benötigen und daß man auf einer länger geübten 
Programmierumgebung fehlerfreier (also schneller) arbeitet.

Nicht auf die höchste Leistung kommt es an, sondern darauf, die Leistung 
sinnvoll einzusetzen. Daher ist auch die Frage nach höchster Leistung 
ohne Bezug auf eine reale Aufgabe vollkommen sinnlos. In der Mathematik 
kann man rein theoretische Probleme erörtern, da sind sie gut 
aufgehoben.


Peter

@ Micha (Gast)

>Wolltest Du mal Deutschlehrer werden und hast die Prüfung nicht geschafft?

Nöö, bin mit meiner Qualifikation ganz zufrieden.

>Oder was soll hier dieses ständige gesafte mit Deinen tollen Grammatik

Neidisch? Ausserdem schreibt man Gesafte gross und es heisst "deiner", 
Genitiv, welcher aber bekanntlich durch den Dativ vom Tode bedroht ist, 
was hier aber durch den Akkusativ ausgedrückt werden muss. Der Nominativ 
hat heute frei. ;-)

> oder sonstigen Formulierungen ??? Kopfschüttel !!!

Das ist ein Forum, welches Wissen vermittlen will. Wenn gleich auch an 
erster Linie elektrotechnisches Wissen, sollten und DÜRFEN dei 
Grundlagen der deutschen Sprache nicht den Bach runter gehen. Sonst sind 
wir bald bei "Ehy, alda, was geht ab". Sieht man überall, im TV (ohje), 
in den Tageszeitungen und selbst in eingentlich seriösen, und nicht so 
leicht von hippen Strömungen irritierbaren Fachzeitschriften. Und ich 
meine damit nicht den Playoy ;-)

MFG
Falk

@ Micha (Gast)

>hmm alles klaro......"DEI" Grundlagen der deutschen Sprache......was für
>ein Spinner

Geh zur Mutti und lass dir ein Lob aussprechen, dass du einen Tippfehler 
gefunden hast. Bist unser Held!

OT (off topic)
Schade, dass hier viel Information verwaessert wird und der SNR immer 
kleiner wird. Grammatikkorrekturen gehoeren genauso zur Verwaesserung 
wie "Flaming". Mein Deutsch wird auch immer schlechter, die 
Rechtschreibreform habe ich nur aus 10000 km Entfernung mit einigem 
Schmunzeln betrachtet und freue mich sehr ueber Beitraege, die 
Information enthalten aber etwas holprig geschrieben sind.

@Gast, scheinst aehnliche Erfahrungen gemacht zu haben wie ich, fuer die 
meisten Anwendungen gibt es fuer mich nicht genuegend Gruende noch ueber 
8-bit nachzudenken, trotzdem bitte nicht Teilnehmer wie Peter angreifen, 
er betrachtet die Sache aus einem anderen Winkel und schreibt sehr viel 
informatives und konstruktives!

@peda es ist richtig, dass Hardwareentwicklung auch Zeit benoetigt, 
allerdings kommt bei den Firmen, mit denen ich gearbeitet habe (sehr 
viele) im Schnitt ungefaehr 1 HW-Ing. auf 4 oder mehr SW-Ing. Also sind 
Einsparungen bei der SW-Entwicklung sehr viel ausschlaggebender. Ein 
schnellerer Prozessor laesst schlechteren Programmerstil zu, d.h. ich 
kann ohne Optimierung, d.h. frueher am Markt sein. Das macht oft den 
Unterschied zwischen Erfolg/Profit und Misserfolg/Verlust aus. Wie 
gesagt, das ist meine Erfahrung aus 10+ Jahren Kundenservice 
Mikrocontroller.

@Ale don't be pissed, Hal is not the typical guy here in the forum and I 
agree that your contribution was a lot more useful than his.

@Falk Wissen ueber Mikrocontroller soll hier vermittelt werden, das 
Forum "Deutsch fuer Fortgeschrittene" wird am Goetheinstitut angeboten.

@Veteranen Ich hab noch Lochkarten programmiert ;-) und der Leser auf 
der IBM/370 hat mich echt beeindruckt.

Alles Gute im Neuen Jahr!

Robert

Hallo alle wieder mal!

Ich kann Falk nur rechtgeben ! Ein gepflegte Umgangsform ist auch für 
einen Techniker wichtig. Von ihm wird nicht erwartet das man ein Buch 
schreibt oder rafinierte Verträge aufsetzt. Wenn er z.B. einen Brief an 
eine andere Abteilung der Firma schreibt, dann sollen die ja nicht 
denken man ist irgend so ein Depp.

MFG Patrick

@Peter Dannegger:
> Schlechtheit läßt sich aber nicht quantifizieren.
> Es reicht ein simples delay_ms(1000) in Deiner Mainloop und Dein
> Programm ist so grottenschlecht, da hilft auch keine 512Bit-CPU.

Wer Timings mit Delays oder Wait_While_Busy() erzeugt gehört erschossen 
;-)
Dafür gibt es Timer-Interrupts, UART-Interrupts, I2C-Interrupts, 
...interrupts, ...interrupts...

> Das PCB dauert länger, ist wesentlich teurer und mehr EMV-empfindlich.
> Ich hab auch nicht den Eindruck, daß die Programmierer damit merkbar
> schneller ihre Projekte fertigstellen.

Daß das PCB länger dauert, würde ich nicht zwingend behaupten. Es gibt 
auch AVRs mit 100 Pins. Es gibt PIC32 mit 64 Pins und es gibt die 
LPC210x mit 48 Pins. Wie lange das Layout dauert, hängt in erster Linie 
von der größe der Anwendung ab, nicht von der MCU.
Übrigens, der PIC32 hat 2 interne Oszillator. Bei Bedarf kann man ihn 
sogar mit 80MIPS laufen lassen, da einer der internen Oszillatoren auch 
als Quelle für die PLL geeignet ist. Und es wird auch nur eine externe 
Betriebsspannung gebraucht.

Ich bin zwar kein EMV-Experte, aber ich denke, daß die EMV-Problematik 
eher mit der Taktfrequenz und weniger mit der Registergröße des 
Prozessors zu tun hat. Ein PIC32 kann auch mit 8MHz und weniger laufen. 
Und die 8051'er von Silicon Laboratories haben mit ihren 100 MIPS 
weniger EMV-Probleme?

Beitrag "Wartezeiten effektiv (Scheduler)"