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
@ 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 ;)
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.
1 | long * long - Zeit 16bit 32 Zyklen - Zeit 32 Bit ??? Zyklen |
2 | long / long - Zeit 16bit 20 Zyklen - Zeit 32 Bit ??? Zyklen |
3 | long + long - Zeit 16bit 10 Zyklen - Zeit 32 Bit ??? Zyklen |
4 | 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
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
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
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.
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
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.
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.
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=񞗫
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.
Das ist beim Arm genau die Geschichte 32/16 Bit Befehlssatz. Einfach ein paar Seiten weiter lesen. :o)))
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.
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.
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.
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).
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
so richtig billig ist eigentlich nur die avr serie debugger software controlle alles bekommst du so für 200 euro
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
@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.
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.
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=񟲔
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.
>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, ...
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 ;-).
@A.K. Ich weiß es und es beruhigt mich :-)
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.
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 :)
>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.
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
>Ich hab noch nicht viel Erfahrung mit 32-bittern, ...
Das ist schon klar geworden!
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 !!!
@ 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
hmm alles klaro......"DEI" Grundlagen der deutschen Sprache......was für ein Spinner
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.
@ 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!
Angehängte Dateien:
-
ZNEOplusFRAMfliegend.png
230 KB
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.
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
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!
Gut die 16 Arbeitsregister des ZNEO sind mit jeweils 32 Halbbits bestückt. Hast ja recht und ich meinen Frieden.
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
@Henry: Lesen ist nicht Deine Stärke? Zitat von der Zilog Webseite: "The Zilog Z16F 16-bit CISC microcontroller" Ab in die Ecke!
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.
@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?
@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!
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 ;)
>> 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.
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.
> 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.
@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!
> 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.
@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.
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.