Angefangen habe ich mit dem AVR und dann wurde der MSP immer interessanter. Und bei www.Reichelt.de gibt es die MSP teilweise erstaunlich billig. Nun gibt es also die Qual der Wahl. Ein paar Hundert Seiten gibt es zu jeder Familie zu lesen. JTAG gibt es nun auch zu immer mehr AVR. Der Stromverbrauch ist bei den MSP oft besser. Atmel legt mit dem 169 nach. Der AVR hat mehr Register und mehr Befehle. Der MSP hat 16 bit, der AVR nur 8. Beim MSP bekommt man kleine stromsparende Controller mit JTAG. Beim AVR haben die kleinen Controller kein JTAG. Der GNU C unterstützt MSP und AVR. Welche Familie also nehmen, wenn man nicht die Zeit aufwenden möchte in beiden Toolketten fit zu werden? Welche Argumente kennt Ihr noch, die helfen können sich für AVR oder MSP zu entscheiden. Wie steht es überhaupt hier in diesem Forum: Wer arbeitet mit C auf dem AVR und wer nimmt den MSP her? Gibt es da viel mehr AVR-Freunde als MSP? Ich bin gespannt auf Eure Beiträge . . .
Also die ständige Jagd nach dem Besten bringt doch nichts. Man kann das nur an der bestimmten Anwendung festmachen. Z.B. ist der Stromverbrauch kein Aspekt, wenn man nicht auch Batteriebetrieb vorsieht. Und für Steuerungsaufgaben, in denen vorwiegend mit Bits und Bytes jongliert wird, bringen 16Bit nur Nachteile. D.h ein 16-Bitter braucht in der Regel für Byteoperation mehr Flash, SRAM und Zeit als ein 8-Bitter. Nur wenn eine CPU, deren Macken man bereits kennt, für die Anwendung ungünstig erscheint, lohnt es sich über den Wechsel auf eine besser geeignete nachzudenken. Wichtig ist dann auch, daß diese Anwendung nicht unter Termindruck steht, da eine neue CPU immer erst eine recht beträchtliche Einarbeitungszeit beansprucht. Beim MSP ist mir in diesem Forum oft aufgefallen, daß selbst einfachste Anwendungen eine unverhältnismäßig große Menge an Flash benötigen. Ob das an der Architektur oder nur an einem sauschlecht optimierenden Compiler oder auch nur an einer schlechten Projektplanung liegt, weiß ich nicht. Z.B.: http://www.mikrocontroller.net/forum/read-1-13296.html Peter
"daß selbst einfachste Anwendungen eine unverhältnismäßig große Menge an Flash benötigen" Das ist nur ein Gerücht, hier sind die Fakten: http://www.mikrocontroller.net/forum/read-1-35648.html#35896
"...hier sind die Fakten" Also wirklich, an einem nur 40 oder 58 Byte kleinen Kode-Schnipselchen kann man doch keine relevante Aussagen treffen ! Zumal es sich dabei auch noch um eine Funktion handelt, die keinerlei praktischen Nährwert auf einem MC hat, eine typische Benchmarkfunktion eben. Für ernstgemeinte Aussagen brauchts schon eine komplette und vor allem sinnvolle Anwendung mit allem Drum und Dran, mindestens 2kByte groß. Peter
Auf jeden Fall ist das aussagekräftiger als irgend eine Mutmaßung wie du sie anstellst. Gib mir ein für dich passenderes Beispielprogramm, dann sehen wir weiter.
Ich habe doch gar nichts gemutmaßt ! Ich habe nur gesagt, daß mir mehrere Beiträge in dieser Richtung hin aufgefallen sind. Jegliche Bewertung, woran das liegt, habe ich jedoch explizit ausgeschlossen: "Ob das an der Architektur oder nur an einem sauschlecht optimierenden Compiler oder auch nur an einer schlechten Projektplanung liegt, weiß ich nicht." Es würde mich aber interessieren, wenn jemand z.B. mal dieses praktische Beispiel auf dem MSP implementieren könnte. Allerdings müßten dann dazu alle Hardwarezugriffe entsprechend angepaßt werden: http://www.specs.de/users/danni/appl/soft/c51/thclock/index.htm Peter
Ja, schon ok ;) Dein Beispiel müsste man mal ausprobieren. Der Code wird sicherlich größer sein als der für AVR (der MSP430 hat nicht einmal halb so viele Befehle wie der AVR!), aber so drastisch wie man bei deiner Beschreibung denken könnte ist es meiner Erfahrung nach nicht. Seine Stärken kann der MSP430 natürlich vor allem bei Anwendungen ausspielen, bei denen viel mit langen Integern hantiert wird. Aber die Codegröße sollte sowieso das letzte Entscheidungskriterium sein. Wem niedriger Stromverbrauch (für Batteriebetrieb) und günstiges JTAG wichtig ist, der nimmt MSP430. Wer hauptsächlich 5V-Schaltungen ansteuern will und Wert auf den großen Erfahrungsschatz in der "Community" legt, der nimmt AVR. Und nochetwas: das Programmieren in den verschiedenen GCC-Toolchains unterscheidet sich nicht sooo sehr voneinander. Die Compileroptionen, das Interrupthandling und der Zugriff auf IO-Register sind weitgehend gleich, Unterschiede gibt es architekturbedingt allerdings bei Zugriffen auf das Flash-ROM (der MSPGCC kann const-Variablen ganz bequem ins ROM legen, beim AVR-GCC geht das wegen den getrennten Adressräumen nicht ganz so einfach). Praktisch ist beim MSP430 außerdem, dass man nicht mit Fuse-Bits hantieren muss, sondern Dinge wie Watchdog und Oszillator zur Laufzeit in IO-Registern ändern kann.
"Seine Stärken kann der MSP430 natürlich vor allem bei Anwendungen ausspielen, bei denen viel mit langen Integern hantiert wird." Genau so isses ! Wobei das Hauptaugenmerk auf dem Wörtchen "viel" liegt. Wenn jemand nur jede Sekunde nen ADC ausließt und daraus 16-Bittig die Temperatur eines PT100 berechnet, dann kostet das weit unter 0,1% der Rechenzeit. Ein AVR langweilt sich bei so "viel" 16-Bit schon tötlich, da muß man einen MSP nicht noch mehr langweilen. Peter
Moin, mir scheint hier ist die Frage von Matthias ein wenig in den Hintergrund gedrängt worden. Vielleicht solltet Ihr die wieder aufgreifen und ein wenig von Euren Erfahrungen mit den verschiedenen Mikrocontrollern berichten. Ich glaube dahin geht sein Interesse. Ich kann nicht mit Erfahrungen zum AVR dienen. Für mich wahr der Stromverbrauch entscheidend außerdem die Anzahl der Timer und Schnittstellen (serielle und SPI). Mit der Entwicklungsumgebung habe ich immer noch Schwierigkeiten. Diese sind aber wohl hauptsächlich durch mangelnde Erfahrung in SW-Bereich und Probleme mit dem MSP-GCC unter WIN95 begründet. Codegröße ist bisher überhaupt kein Thema für mich. Eher schon die Beschaffbarkeit der Bauteile. Ich werde wohl beim MSP bleiben da der 149er die gesamte für mich notwendig Peripherie und den niedrigen Stromverbrauch mitbringt. Viel Spaß bei der weiteren Diskussion und immer ruhig Blut ;-) Tschau Christian
Hast recht Christian, ich hab jetzt mal in die MSP430 Datenblätter geschaut und gemerkt, daß ich vollkommenen Quatsch erzählt habe. Nur die allergrößten Tausendfüßler der MSP430-Serie haben Multiplikation. D.h. der ATMEGA8 hängt auch in Punkto 16-Bit Rechenleistung seine gleichpinnigen MSP430-er um Längen ab. Der MSP430 ist also eher im unteren Leistungssegment der 16-Bitter einzuordnen. Bleibt also nur echt ein Vorteil in Bezug auf Batteriebetrieb übrig. Wenn ich weiterhin richtig gesehen habe, kann er auch keine 5V, damit scheidet er eh für meine Steuerungsaufgaben aus. In vielen Industrieanwendungen ist 5V ja immer noch Standard, wegen der höheren Störsicherheit und der leichteren Verfügbarkeit von 5V-Interface-ICs. Erfahrungen habe ich nur mit dem 8051, der eigentlich alle meine Wünsche zur vollsten Zufriedenheit erfüllt. Aber für neue Projekte will ich auch den ATMEGA8 als untergeordneten MC einsetzen, da er preislich sehr attraktiv ist und im Gegensatz zum 8051 mit Zero-Components arbeiten kann. Schade, daß ich nicht zu den Großabnehmern gehöre, sonst würde Atmel bestimmt auch einen AT89C4051 mit internem Takt, Reset, Bootloader für micht rausbringen und ich könnte komplett alles mit 8051 erschlagen. Mit Timern hatte ich nie Probleme, da ich immer alle Takte aus einem einzigen Timerinterrupt ableite. Aber der ATMEGA8 hat ja 6 Timer (T0, T1, T2, ADC, I2C, UART), so daß dort nie ein Mangel auftreten wird. Die UART mit 3 Byte Empfangspuffer sollte auch der härtesten Echtzeit standhalten. Lediglich das SPI ohne 2. Sendepuffer macht es schwierig, als Slave mehr als 1 Byte verlustfrei zu übertragen. Peter
ich baue portable medizinische Geräte. Und da ist mir der Energiebedarf wirklich wichtig. 5V für die CPU wären mir manchmal auch lieber. Aber mit 5V steigt der Strombedarf halt stark an. Zunehmend mehr Peripherie wird auch mit 3V oder darunter angeboten. Die Strukturen werden ja immer kleiner. Wichtig ist besonders die Programmierung. Wieviel Ärger man eben damit hat. Damals beim 166 von Siemens war die Toolumgebung schrecklich fehlerhaft zu Beginn. Heute, 13 Jahre später ist es ok. Ich habe mal gehört, daß die AVR nicht so schrecklich stabil arbeiten würden. Soll da der MSP besser sein. Oder wie sind da Eure Erfahrungen? Matthias PS: Wie ist hier überhaupt das Verhältnis MSP-Anwender zu AVR hier im Forum? @Andreas: Vielleicht kannst Du was dazu sagen.
> Ich habe mal gehört, daß die AVR nicht so > schrecklich stabil arbeiten würden. > Soll da der MSP besser sein. Oder wie sind > da Eure Erfahrungen? Hallo Matthias, was die AVRs betrifft, kann ich dies nur bestätigen, leider! Ich habe schon des öfteren seltsame Effekte gehabt, wo die Dinger einfach nicht das getan haben was sie sollen, obwohl die Software im Simulator einwandfrei lief. Ändert man dann das Programm an einer ganz anderen Stelle, läuft alles wieder wie gewünscht und diese seltsamen Effekte lassen sich nicht mehr nachstellen. Bei Verwendung in Geräten, wo es auf einwandfreie Funktion ankommt ist das natürlich so eine Sache. Auch sind die AVRs sehr empfindlich gegenüber Störeinstrahlungen. Offene Ein- oder Ausgänge sind tunlichst mittels Widerständen auf festes Potential zu legen, sonst kann es sein, dass die Dinger dann nur noch herumspinnen. Eingentlich schade. Ein AVR mit der elektrischen Robustheit eines PIC wäre aus meiner Sicht sehr wünschenswert. Gruss, Notker
Hallo, ich arbeite mit MSP430 (meistens F149) und proge mit MSPGCC.Die einzigen sachen, wo das mehr an Speicherplatz festzustellen war, waren Floatingpoints-Funktionen (sin, cos, usw...). Ich arbeite viel mit LCD-Displays und tragbare Geräte und bin sehr sehr zufrieden mit der Geschwindigkeit, als auch mit der Stabilität und dem Stromverbrauch. Obwohl ich viele Fonts und BMPs im Flash für meine Anwendungen ablege, hab ich die 25kB Grenze nochnie überschritten (außer ich mache planlose BMPs rein). Einziges Kriterium bei den MSPs ist, dass sie nicht überall (Conrad usw...) erhältlich sind, und somit bei größeren Distributoren eingekauft werden muss. Das Clocksystem ist absolut genial. Es gibt nichts besseres und der WatchDogTimer kann auch für viele sachen verwendet werden (neben der WatchDog-Funktion) mfg Weichinger Klaus http://www.Weinga-Unity.de.vu
@Notker: Das ist lang und breit in de.sci.electronics diskutiert worden. Das Ergebnis war, daß die alten AVRs in der Tat recht empfindsam gegen Störeinstrahlungen sind (besonders auf dem Reset-Pin, man sollte also unbedingt die AppNote von Atmel bezüglich EMV beachten), das betrifft die AT90Sxxx sowie die alten AtTiny und den ATmega103 (vielleicht auch noch den ATmega163, der könnte auch noch in alter Technologie gefertigt sein). Ab den ,,richtigen'' ATmegas hat Atmel einiges in dieser Richtung getan. Als wesentliche Ursache wird der `die shrink' (Verkleinerung der Chipfläche) genannt, der ja zusätzlich auch zu einem gewissen Preisverfall führt. Da außerdem der Reset-Impuls jetzt länger sein muß, bevor er einen Reset auslöst, ist wohl auch dieser Pin robuster gegen Einstrahlungen geworden. Fazit war, daß jemand locker eine Schaltung mit einem ATmega128 neben einer Funkenstrecke in Betrieb halten konnte, wo eine mit einem AT90Sxxx schon lange nicht mehr funktioniert hat. Ansonsten sehe ich das auch so: die Toolchains sind praktisch gleich, auch wenn ich bislang mit dem MSP430 noch nichts gemacht habe, werde ich mich nicht scheuen, ihn für stromsparende Anwendungen mal zu testen (auf jeden Fall viel lieber als einen PIC, den fasse ich freiwillig nicht mehr an ;-).
@Joerg Wunsch diese Diskussion kannte ich bislang nicht, danke für den Hinweis. Heißt das, dass die AT90Sxyz aus aktueller Produktion immer noch diese Unzulänglichkeiten aufweisen? Die Empfindlichkeit des Reset-Pins ist mir bislang eigentlich nicht so besonders aufgefallen, dagegen sind meiner Erfahrung nach die Eingänge für die externe Taktung der Counter sehr empfindlich gegen Störeinstrahlungen und dementsprechend zu behandeln bzw. zu beschalten. Eine Sache, die mich an den AVRs aber auch sehr stört, ist deren elektrische Empfindlichkeit im Bezug auf Beschädigungen oder Zerstörungen des Chips. Es ist mittlerweile technisch gesehen absolut kein Problem, integrierte CMOS-Chips durch entsprechende Schutzbeschaltung nach aussen hin sehr robust zu gestalten. Andere Hersteller können dies problemlos zu akzeptablen Marktpreisen realisieren und erwähnen diesen Umstand sogar in den Datenblättern. Sie empfehlen zwar eine ESD-gemäße Behandlung, schreiben aber, dass der jeweilige Baustein der möglichen Ladung eines menschlichen Körpers problemlos widerstehen kann (hierfür gibt es übrigens genormte Ersatzschaltungen). Wieso kann Atmel dies nicht? Die AVRs sind in ihrer Empfindlichkeit schon fast mit den ersten logischen CMOS ICs zu vergleichen (40er Reihe). Wer diese Zeit noch miterlebt hat, weiß, wovon ich spreche. Bei mir wurde ein eingebauter (!) AVR schon wegen elektrischer Aufladung eines PVC-Fußbodens beschädigt und so was muss ja nicht gerade sein. Mal abgesehen davon, dass das Fehler sind (einzelne Ein-/Ausgänge defekt usw.), die man dann suchen geht wie die Stecknadel im Heuhaufen. Das ist für mich ein sehr entscheidendes k.o.-Kriterium, was entschieden gegen die AVRs spricht. Der Markt der MCs ist ja sehr in Bewegung und es kommen fast täglich Neuerungen heraus. Wenn es eines Tages eine akzeptable Alternative geben sollte und Atmel nicht gewillt ist diese Unzulänglichkeit abzustellen, werde ich mit Sicherheit zu einem anderen Produkt/Hersteller wechseln. Denn solche Sachen, die wohl offensichtlich nur der Kostenersparnis zu Marketingzwecken dienen, sehe ich nicht ein. Hier wird übrigens deutlich, warum ein vergleichbarer MC von Microchip etwas teurer als der von Atmel ist. Nur über die tatsächlichen Gründe spricht kaum jemand denn eine entsprechende Schutzbeschaltung kostet ja auch etwas. Notker
@Notker, welcher Typ ist denn das, der Dir durch ESD ständig kaputt geht ? Als wesentlichen Vorteil der neuen Serie gegenüber den alten 1200, 2313, 8515 nennt Atmel auch die bessere Störfestigkeit. Aber die sind ja auch nicht mehr für Neuentwicklungen empfohlen. Ich setze zur Zeit bereits den Tiny26 / Mega8 ein und habe damit keinerlei Probleme bemerkt. In den Datenblättern steht auch drin, daß der Reset-Pin bei Bedarf extra zu schützen ist. Er hat deshalb keine Schutzdiode, damit die 12V Programmierspannung durchkommen. Im PIC-Forum habe ich gelesen, daß einige PICs ähnliche Probleme gehabt hatten. Man muß einen neuen IC wohl immer erst einige Jahre am Markt reifen lassen. Peter
Ja, alle AT90Sxxx haben diese Probleme, da sie alle noch mit dem alten Prozeß gefertigt werden. Sicher ein Grund, warum Atmel die alle nach und nach ablösen möchte. Die elektrostatische Empfindlichkeit kann ich so nicht bestätigen, bei mir leben bislang noch alle AVRs, die ich in den Fingern hatte -- ohne aufwendige Schutzmaßnahmen. Ja, ich kenne noch die ganz alte MOS-Technik, da habe ich selbst auch paar Transistoren auf dem Gewissen. ;-) Ich denke übrigens nicht, daß die vorsätzlich an einer Schutz- beschaltung gespart haben / sparen wollten, das halte ich einfach für eine Unterstellung. Laut Datenblatt haben ja auch alle Eingänge Schutzdioden außer /RESET, weil der +12 V abkönnen muß. (Daher empfiehtl die Appnote dort eine externe Diode.) Von solcherart Problemen höre ich übrigens zum ersten Mal jetzt, während das EMV-Problem in zahllosen Diskussionen schon breitgetreten worden ist.
@Peter Dannegger > welcher Typ ist denn das, der Dir durch ESD ständig kaputt geht ? Nun ja, ständig wäre etwas übertrieben. Der besagte AVR, der sogar in eingebautem Zustand das zeitliche segnete, war ein 8535. Mit dem 8515 hatte ich auch bereits Probleme, dass z.B. partielle Defekte aufgetreten waren, wie z.B. einzelne I/O-Ports defekt o.ä. Interessanterweise hatte ich mit dem 2313, der auch einer meiner Favoriten für kleine Dinge ist, bislang keine Ausfälle dieser Art gehabt. Aber der Mega8 ist ein sehr interessantes Teil. Mit dem werde ich mich zukünftig mal etwas intensiver beschäftigen. Jeder hat ja in seinem Käferzoo so seine Lieblinge. @Joerg Wunsch > Ich denke übrigens nicht, daß die vorsätzlich an einer Schutz- > beschaltung gespart haben / sparen wollten, das halte ich einfach > für eine Unterstellung. Nun ja, Fakt ist, dass es schon seit einiger Zeit Bauteile mit CMOS-Chips auf dem Markt gibt (z.B. intelligente LED-Displays für Industrie-Anwendungen von Osram/Infineon oder von Siemens), die derart schutzbeschaltet sind, dass sie jeder möglichen Ladung eines menschlichen Körpers standhalten können. Dies wird auch im Datenblatt dieser Teile ausdrücklich erwähnt. So etwas bezeichnet man im Fachdeutsch als "Stand der Technik". Und wenn ein Hersteller dies, aus welchen Gründen auch immer, vermeidet, macht man sich halt seine Gedanken. Unterstellen wollte ich eigentlich nichts, ich habe nur mal laut gedacht und meine Gedanken in die Tastatur gehäckert. Ich hoffe, ich werde deshalb nun nicht als Regimegegner abgeführt und verhaftet (wie wäre es mit der Einführung eines extra Forums für Gegendarstellungen?) Aber im Prinzip dreht sich doch heute eigentlich alles nur noch um Herstellungskosten und Marktbehauptung. Was soll einem denn dazu noch anderes einfallen? Notker
Ach ja, was ich noch zum Thema sagen wollte. Wenn man hier in diesem Forum schon längere Zeit mitliest, so sah man doch des öfteren ein mysteriöses Sterben dieser besagten AVRs und ich denke mal, ich bin nicht der Einzige, der diese Erfahrungen machen musste. Wie schon gesagt, es sind ja nicht immer Totalausfälle die Folge. Oft gehen einzelne Ports kaputt oder der AVR verhält sich in anderer Art und Weise komisch. Aber da so etwas ja nicht durch schiefes Anschauen passieren kann und andere Gründe ausscheiden, liegt es hier mit an Sicherheit grenzender Wahrscheinlichkeit an elektrostatischer Aufladung, die dem kleinen Käfer einen Knacks bereitet hat. Soviel noch zu dieser Sache. Notker
Nu ja, wenn eine ESD-Beschaltung, die 15 kV aushält, so daß man die Chip-Pins z. B. direkt an einen Steckverbinder eines Gerätes legen kann, möglicherweise den Chippreis nahezu verdoppeln würde, dann denke ich, daß ich nicht der einzige wäre, der den Preis bei einem Controller einfach nicht bezahlen wollte. Solch Aufwand ist ganz sicher für Dinge gerechtfertigt, für die das Betriebsfall ist, einen RS-232 Treiber zum Bleistift, aber wie man auch und gerade bei Maxim sehen kann, hat das dann oft seinen Preis. Ich bin mittlerweile etwas zu weit weg von derartigen Technologie-Interna, ich kann mir aber gut vorstellen, daß die dafür nötigen verteilten Rs und Cs einfach mal recht heftig Chipfläche kosten, was den Chip natürlich gut verteuert. Dein Beispiel ist ja auch wieder für ein Bauteil, bei dem das gerechtfertigt ist, da es zum betriebsmäßigen Verhalten gehören kann, direkter ESD-Einwirkung ausgesetzt zu sein. Bei den Interface-Pins eines Microcontrollers sehe ich das nicht, daß das zum betriebsmäßigen Verhalten gehört, sie sind halt nur im Werkstatt-/Laborbereich ESD direkt ausgesetzt, und in dieser Umgebung kann man sicher von wenigstens einer grundsätzlichen Absicherung der Umgebung gegen zu hohe Aufladungen ausgehen (keine Polyamidfaserkittel tragen z. B., und vielleicht nicht gerade eine Werkbank aus PTFE ;-). Professionelle Computerfirmen wollen in dieser Richtung total auf Nummer sicher gehen und verdonnern ihre Techniker, stets nur mit ,,Gebetsmatte'' an den Kisten herumzuschrauben... Die von Dir zitierten häufigen Ausfälle sind mir auch aus Berichten anderer nicht in Erinnerung. Das Einzige, was gelegentlich bei den AVRs mal passiert ist, daß sich EEPROM-Zellen, die eigentlich nicht öffentlich zugänglich sein sollten (z. B. die Chip-ID) durch ein ,,wildes'' Signalspiel an den Programmierpins verbiegen/löschen lassen. Das habe ich selbst schon erlebt, und indirekt hat Atmel in der Appnote 910 zugegeben, daß sowas auftreten kann. Disclaimer: ich habe das bislang nur bei alten AT90Sxxx erlebt, kann also gut sein, daß sich da inzwischen auch was verbessert hat. Je nachdem, wie pingelig Dein Programmiergerät auf eine verbogene Chip-ID reagiert, kann das natürlich einen Chip schon mal für Dich unbrauchbar machen.
Ich habe mich für den MSP430x12x entschieden, arbeite unter WINXP und WIN2000 mit der IAR Software. Da ich Strom sparen muß habe ich mich für den MSP entschieden. Gruß m@is
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.