www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Ab wann lohnt sich ein 32bit Controller? Compilerkosten?


Autor: Askan Simon (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Zusammen,

ich hab eine Berechnung, die vorwiegend - zu 80% - mit long Datentypen
arbeitet.
Auswertung von Sensordaten, desto schneller desto besser.

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

Aktuell habe ich einen Atmega64 mit 16Mhz. Da geht die Geschwindigkeit
schon merklich runter, beim großen Addieren, Multipliziere, vergleichen
etc.

Oder ist es besser und wirtschaftlicher einen schnelleren Prozessor zu 
kaufen? Soweit ich weiß sind die 32bit Compiler extrem teuer. oder?

Aktuell habe ich WinAVR, der kostet ja nichts.

Danke & Viele Grüße
Askan

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  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

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ;)

Autor: Askan Simon (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

Danke für die Antworten. Ok, nicht besonders toll formuliert.

Gibt es irgendwo Informationen, wie schnell bei 16Mhz und
ein 32bit Controller wäre, im vergleich zu einer 16bit
Architektur.

z.B.
long * long   -   Zeit 16bit 32 Zyklen  - Zeit 32 Bit ??? Zyklen
long / long   -   Zeit 16bit 20 Zyklen  - Zeit 32 Bit ??? Zyklen
long + long   -   Zeit 16bit 10 Zyklen  - Zeit 32 Bit ??? Zyklen
long - long   -   Zeit 16bit  5 Zyklen  - Zeit 32 Bit ??? Zyklen

Dann könnte ich den Zeitvorteil in etwa abschätzen.
Uart / LCD wird nicht ausgeführt.

Danke & Viele Grüße
Askan

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Tim T. (tim_taylor)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter Dannegger wrote:
> 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.

Ähm, auch Tim Taylor kennt -O3...

Wobei, wie wärs mit einem 24Mhz Quarz und etwas mehr Vcc Power? 
Harrharrrrr

SCNR

Autor: Detlev T. (detlevt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Henry (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Besondere Vorteil für mich waren die geringen Kosten für das 
Programmier/Debugger-Kabel von 30$. Da ich sowieso Bauelemente bei 
digikey.com bestellen musste brachte mich dieser Preis in die 
versandkostenfreie Zone.

Das gesamte  Softwarepaket für C/ASM inklusive Debugger ist downloadbar 
und kostenlos. Es ist aber ein altmodischer C-Compiler der keine 64-Bit 
Arithmetik unterstützt.

http://www.mikrocontroller.net/articles/ZNEO

Autor: Robert Teufel (robertteufel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Ulrich (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn wirklich 32 Bit daten verarbeitet werden müssen, kann er 32 Bit 
Controller viel schneller sein. Ich würde eher 4-6 fache Geschwindigkeit 
erwarten, aber da ist ja auch immer die Frage wie viele Take ein Befehl 
braucht. Oft kann der Takt bei 32 Bit µCs auch höher sein.

Allerdings wüßte ich nur sehr wenige Messdaten die wirklich 32 Bit 
brauchen. Als zweites ist dann oft der AD-Wandler langsamer als selbst 
ein 8 Bit µC.

Die Unterschied im Preis muß nicht hoch sein. Ein kleiner ARM7 µC muß 
nicht teurer als ein Mega64 sein. Man muß sich aber vor allem in den 
neuen Compiler einarbeiten und den erst mal installieren und ggf. auch 
kaufen, wenn man es mit der Installation einfach haben will.

Autor: Be Mi (bemi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Patrick Weinberger (seennoob)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Be Mi (bemi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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=...

Autor: Patrick Weinberger (seennoob)
Datum:

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

MFG Patrick

Autor: Be Mi (bemi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das ist beim Arm genau die Geschichte 32/16 Bit Befehlssatz. Einfach ein 
paar Seiten weiter lesen. :o)))

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Henry (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Mein faules Hirn soll seine ganze Kraft für die Entwicklung eines 
physikalischen Models verwenden. Da bleibt kein Rest für 
Zahlenspielereien.

Heute gibt es Controller mit ausreichend Kraft für menschenfreundliche 
Zahlendarstellung. Soll sich doch der µC quälen. Ich bin kein Masochist.

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Ale (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ein uC mit FPU ?, ja wenn du 10 FLOPS brauchst. Für 1 DIV je 10 s, es 
lohn gar nichts.

Gibt viele Möglichkeiten für 32-Bit Prozessoren (Hast du schon auf dem 
Parallax Propeller gedacht ?), PIC32, AVR32, ARMs, ZNEOs, Renesas R32, 
uvä., und in-zwischen wie den eZ80, H8/300, H8S(X).

Eine Möglichkeit wurde sein: deine Quellcode für ein z.B. ARM 
compilieren und mit ein Simulator es laufen... und versuchen wie es geht 
und welche Takt wurde es brauchen akzeptabel zu laufen.

(Ich entschuldige mich für meine schlechte Deutsch).

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Andreas K. (ergoproxy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: GG (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
so richtig billig
ist eigentlich nur die avr serie debugger software controlle
alles bekommst du so für 200 euro

Autor: Andreas K. (ergoproxy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Tim (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Andreas K.:

Nimm einen MC mit Cortex M3 Kern. Dem gehört die Zukunft.
Da er der Nachfolger der Krücke ARM7 ist, dürfte er bald der MC mit der 
größten Verbreitung auf dem Markt sein (wobei "bald" durchaus ein oder 
zwei Jahre sein können).
Dementsprechend dürfte er auch in den Internetforen unter Hobbyisten 
auch Zustimmung erfahren.

Fang aber bloß nicht mit dem ARM7 an. Viel zu umständlich. 2 
Befehlssätze, die umständlich umgeschaltet werden müssen, lausige und 
nicht deterministische, ultralange Interruptlatenz (66 Zyklen bis 
Eintritt in IRQ, wenn höherpriorer IRQ einen anderen unterbricht im 
worst case gegenüber festen 18 Zyklen beim M3!!!), spurious interrupts, 
etc.

Anbieter vom M3, die ganz gut erhältlich sind, sind im Augenblick 
Luminary und ST. NXP kommt nächstes Jahr auch dazu, spätestens dann sind 
die in jeder Internetshopklitsche zu haben. Es gibt auch andere Anbieter 
wie Toshiba oder Ti, aber die verkaufen im Wesentlichen nur an 
Großkunden.

Von Luminary z.B. gibt es Boards so ab ca. 40,- Euro, die auch als 
Debughardware für eigene Projekte benutzt werden können, da sie über USB 
als JTAG Hardware dienen können, eine Buchse ist auf den Boards 
vorhanden, mit einem Kabel wird die Zielhardware damit verbunden.
Ich nutze auch so ein Board, das funktioniert prima.

Autor: Tim (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nachtrag:
>Das die komplizierter sein wird als bei den Megas ist mir klar.

Nein, das ist bei den Cortex M3 nicht der Fall. Spannung, Quarz (nicht 
nötig, wenn einem die 30% - ja, richtig, dreissig % - Genauigkeit des 
internen Oszillators reichen), 2 Kondensatoren und fertig.

Ein Bootloader ist ab Werk vorprogrammiert, JTAG ist also gar nicht 
nötig. Allerdings kann man den Bootloader überschreiben, wenn man nicht 
aufpasst.
Dann muss man doch wieder mit JTAG ran.

Autor: Be Mi (bemi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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=...

Autor: Mehmet Kendi (mkmk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Ohne Debugger würde ich ein Projekt erst gar nicht anfangen.

So spricht die Jugend von heute :-(
Ohne Debugger ist man gezwungen, sich zuerst Gedanken über das Programm 
zu machen und dann zu programmieren. Macht man das heute nicht mehr?

Robert hat ja schon alles Wesentliche geschrieben.

@Askan
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. Wozu auch? Der Preis ist genauso günstig und die 
Leistung deutlich höher.
Ein ganz spezieller Tipp meinerseits wäre ein Edelprozessor SH7211 
(Entwicklungskit RSK7211). Deine Frage zu 32bit-Taktzyklen wäre recht 
einfach zu beantworten: je 1 Takt bei 320MIPS.

Ein sehr wichtiger Punkt bei der Prozessorwahl ist die verfügbare 
Hardware: interner Speicher RAM/ROM, I/O, Timer, UARTs, IIC, CAN, USB, 
DMA, Speicherinterface, ...

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ;-).

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@A.K.
Ich weiß es und es beruhigt mich :-)

Autor: Ale (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
rant
@Hal: You do not seem to write better than me. Why bother posting ? What 
is it with you people ? As if you were born knowing everrything!. Do you 
want to show us all the 0s you got on School ? you didn't get any ? I'm 
not sorry for you.
/rant

Btw my suggestion is quite valid: Test first, buy later.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Mehmet Kendi (mkmk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :)

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Aha, Du bestückst also alle MC-Platinen auch immer mit 400V-Elkos und
Grundsätzlich und in low ESR Ausführung.

>Leistung lohnt sich nur dort, wo man sie auch braucht.
Du mußt Dich nicht entschuldigen, wenn Du in Deinem Leben noch nichts 
geleistet hast.

>in der eine 20MB SCSI-Harddisk 2.000 USD kostete.
Eh, manno eh, ich mußte noch Kernspeicher ansteuern.

Autor: Mehmet Kendi (mkmk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Be Mi (bemi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Ich hab noch nicht viel Erfahrung mit 32-bittern, ...

Das ist schon klar geworden!

Autor: Micha (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
QFalk Brunner,
hab selten so einen Krümelkacker wie Dich erlebt. Wolltest Du mal 
Deutschlehrer werden und hast die Prüfung nicht geschafft? Oder was soll 
hier dieses ständige gesafte mit Deinen tollen Grammatik oder sonstigen 
Formulierungen ??? Kopfschüttel !!!

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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

Autor: Micha (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hmm alles klaro......"DEI" Grundlagen der deutschen Sprache......was für 
ein Spinner

Autor: Stefan Salewski (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
QAutor:  Micha (Gast)

>hab selten so einen Krümelkacker wie Dich erlebt.

Und warum?
Weil viele der kompetenten Leute auf dümmliche bzw. lieblos 
dahingeschmierte Postings (sowohl Fragen als auch Antworten) überhaupt 
nicht mehr reagieren bzw. sich total aus dem Forum zurückgezogen haben.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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!

Autor: Henry (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hier das Bild eines 32-Bitters in fliegender Verdrahtung.

Ringsum 30 Jahre alte Bauelemente der DDR. Rechts auf Fädeldraht ein 
8kByte FRAM welches mit 1MHz I2C Takt gejagt wird.

Links, die blaue Perle, ist ein 20MHz keramischer Resonator Murata. 
Verwendet noch jemand Quarze?

Die vielen 100nF Scheibenkondensatoren sind nach neueren Erfahrungen 
nicht notwendig. Jetzt verbaue ich nur noch zwei.

Autor: Robert Teufel (robertteufel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Mike (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Henry, verkaufe uns doch nicht immer die ollen 16Bitter als 32Bitter.
Es gilt immer noch das, was der Hersteller schreibt. Die Zilogs sind 
schlicht 16Bitter.

Thema verfehlt, 6, setzen!

Autor: Henry (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gut die 16 Arbeitsregister des ZNEO sind mit jeweils 32 Halbbits 
bestückt. Hast ja recht und ich meinen Frieden.

Autor: Patrick Weinberger (seennoob)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Mike (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Henry: Lesen ist nicht Deine Stärke?

Zitat von der Zilog Webseite:
"The Zilog Z16F 16-bit CISC microcontroller"

Ab in die Ecke!

Autor: Henry (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dann bist du das, der den MIPS Angaben der Hersteller glaubt?

Ja der ZNEO ist vom Hersteller als 16 Bit eingestuft. Damit grenzt er 
sich vom 32 Bit ARM9 aus gleichem Hause ab. Nennt man wohl 
Marketingstrategie.

Für mich als Anwender ist es aber ein überwiegend 32-bittiger 
Mikrocontroller.

Autor: Be Mi (bemi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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?

Autor: Dirk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Henry:
>Für mich als Anwender ist es aber ein überwiegend 32-bittiger
>Mikrocontroller.


Jo, und für mich ist mein 1,6l 4-Zylinder Astra eigentlich ein 6l V12...
Nee, ist klar.

Man bekommt bei Dir den Eindruck, Du müsstest Dich permanent 
rechtfertigen, weil Du so einen Exoten-MC einsetzt, der nur von wenigen 
genutzt wird und der keine Zukunft hat.
Steh doch darüber und freu Dich, daß den Controller hier sonst keiner 
nutzt. Auch wenn der MC unter vielen Gesichtspunkten sicherlich nicht 
erste oder zweite Wahl ist, warum auch nicht so etwas ausprobieren?
Also steh dazu, auch dazu, daß es "nur" ein 16bitter ist. Ist dich 
nichts Schlimmes!

Autor: Hmm... (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich denke ähnlich wie Peter, so ein kleiner 8-Bitter reicht in 80% der 
Anwendungen aus. Gerade die knappen Ressourcen der Tinys sind eine gute 
Schule um ein Gefühl für die Hardware zu bekommen. Und wenn das da ist, 
ist kann man dann auf eine Plattform aufsetzen, die der Aufgabe 
angemessen ist.

Nicht zu vergessen das man bei vielen 8-Bittern das Zeitverhalten auf 
den Takt genau voraussagen kann und so bei zeitkritischen Steueraufgaben 
wesentlich mehr Kontrolle über das Timing hat.

Oder schlägt jemand seinem Chef vor, die nächste 7-Segment Anzeige mit 
Pulszähler durch einen Pentium QuadCore-Rechner mit 3GB RAM anzusteuern?

Andersherum hat ein dicker ARM oder DSP bei großen Anwendungen die viel 
Speicher oder Rechenzeit benötigen schon seine Berechtigung.

8-Bit und 32-Bit zu vergleichen brint hier recht wenig. Man sollte mal 
lieber über den Sinn von 16-Bittern diskutieren ;) Die sind häufig 
wesentlich teurer als 32-Bitter und genauso 'umständlich' wie die 
8-Bitter. Abgesehen vom MSP430 fallen mir jetzt auch kaum noch welche 
ein, die ich bereit wäre in einem Projekt einzusetzen. Maximal noch die 
sündhaft teuren (X)C167 wenn es wirklich mal ein paar dutzend 
Capture-Kanäle braucht ;)

Autor: Lutz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> 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...

Nun ja, als in der Anfängerliga befindlich sehe kleine delays als 
extrem sinnvoll an. Für jeden kleinen "Furz" jedesmal dieses irre 
Timersetup (und dabei auch noch aufpassen, da ja oft mehrere Prozesse 
einen Timer nutzen MÜSSEN). Aber vielleicht kriege ich ja noch doe 
Erleuchtung, wie man mit einem Timer ganz simpel und übersichtlich 
mehrer Prozesse steuert.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: crazy horse (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
es hilft EMV-mässig fast nichts, einen an sich schnellen Prozessor 
langsamer zu takten.
Das Problem sind die internen Stufen, die auch bei langsamer Taktung 
entsprechend schnell umschalten, das ist unabhängig von der eigentlichen 
Taktfrequenz.

Autor: Hmm... (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> es hilft EMV-mässig fast nichts, einen an sich schnellen Prozessor
> langsamer zu takten.
> Das Problem sind die internen Stufen, die auch bei langsamer Taktung
> entsprechend schnell umschalten, das ist unabhängig von der eigentlichen
> Taktfrequenz.

Jap. Ein 200MHz ARM9 hat ja auch keinen externen 200MHz Takt dran. Der 
hohe Takt wird bei allen mir bekannten Chips per PLL von einem deutlich 
geringereren Takt gewonnen. Und irgendein Teil im Controller arbeitet 
auch bei geringerem CPU-Takt recht fix, z.B. die USB-Peripherie oder der 
interne Ethernetcontroller.

Autor: Andy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Hmm...:
>Nicht zu vergessen das man bei vielen 8-Bittern das Zeitverhalten auf
>den Takt genau voraussagen kann und so bei zeitkritischen Steueraufgaben
>wesentlich mehr Kontrolle über das Timing hat.

Dumm nur, daß das beim Atmel AVR nicht stimmt, die Interruptlatenz ist 
nicht vorhersagbar.
Beim 32Bitter ARM Cortex M3 dagegen schon...

Tja, und nun?
Also doch besser einen 32Bitter nach Deiner Argumentation bei 
zeitkritischen Steueraufgaben!

Autor: Hmm... (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Dumm nur, daß das beim Atmel AVR nicht stimmt, die Interruptlatenz ist
> nicht vorhersagbar.

Naja, wenn man tatsächlich extrem exakt arbeiten muss, kann man 
Interrupts in der Zeit auch einfach deaktivieren.

> Beim 32Bitter ARM Cortex M3 dagegen schon...

Niemand sagt, dass ein Controller mit priorisierbaren Interrupts mit 
einem anderen mit starrem Interruptsystem vergleichbar ist.

> Tja, und nun?

Sag du es mir ;)

> Also doch besser einen 32Bitter nach Deiner Argumentation bei
> zeitkritischen Steueraufgaben!

Und dann gleich noch mit Linux, weil da echtes Multitasking möglich ist 
und das ganze mit 250 MHz takten, damit die paar ns Jitter im Interrupt 
nicht mehr auffallen.

In diesem Forum werden bevorzugt Atmel-Controller (AVR, SAMxxx) und 
gelegentlich PICs und MSP430 eingesetzt. Deshalb habe ich meine 
Beispiele an diesen hier verbreiteten Controllern gewählt.

Autor: Andy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Hmm...:
>Naja, wenn man tatsächlich extrem exakt arbeiten muss, kann man
>Interrupts in der Zeit auch einfach deaktivieren.


Ach, und dann pollt der die ganze Zeit? Dann langt auch ein 4bitter...


>Niemand sagt, dass ein Controller mit priorisierbaren Interrupts mit
>einem anderen mit starrem Interruptsystem vergleichbar ist.


Richtig, das hat aber hier nix mit der Latenz zu tun.
Auch wenn der Cortex mit nur einer Priorität läuft, ist die Latenz immer 
gleich im Gegensatz zum AVR.
Das Argument von Dir zieht hier schlicht nicht, weil es nicht stimmt.
32Bitter können ein besseres Timingverhalten haben als 8Bitter, wie mein 
Beispiel schön zeigt. Mehr wollte ich nicht sagen.

Autor: chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ein 32bitter lohnt sich im Preis. Wenn z.B. die 8bitter pic10/12/16
avr48 .. nicht genügen, wegen zuwenig RAM, ... dann ist meine Wahlt ein
32bitter, außer ein günstiger dsPic (16bit) oder ein siLabs (8bit 8031)
reicht. Es ist eine reine preisliche Entscheidung. pic18 sind auch schon
zu teuer, außer wenn spezielle Interfaces wie Can, Ethernet usw 
gefordert
sind. Aber auch da, speziell im USB-Bereich haben die 32bitter Preislich
und supportmäßig die Nase vorne. z.B. USB, die gibt es auch von 
Microchip,
kosten ca 2 Euro, also billig, aber keinen Driver für Vista, hingegen
siLabs hat welche, sind aber dann schon gleich teuer wie ein 32bit ARM,
welcher dann auch andere Sachen mehr bietet.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.