Hallo, liebe Forumsgemeinde. In der Hoffnung, nicht zum tausendsten Mal die Frage nach dem besseren Controller zu stellen, bräuchte ich eine kleine Anregung, am besten von jemandem, der beide Typen kennt. Für ein kommerzielles Projekt möchte ich entweder einen MSP430F1232 oder einen ATmega48 verwenden. Wichtige Eigenschaften des Controllers sind hierbei ein A/D-Wandler mit 10 Bit Auflösung - und einer guten Genauigkeit, was die Auflösung ja noch nicht selbstverständlich bedingt, und ein UART. Dir Programmierung der Firmware soll in C erfolgen, Hauptaufgabe ist Meßwerterfassung und MODBUS-Kommunikation (dafür der UART). Die Anwendung ist nicht wirklich zeitkritisch - beide Controller wären schnell genug - und auch der Stromverbrauch ist sekundär. Der Spannungsregler kann jederzeit umdimensioniert werden, also ist 3.3 oder 5V auch egal. Was zählt, ist ein guter ADC, günstige EMV-Eigenschaften und brauchbarer UART. Es wäre auch gut, wenn der verwendete Mikro arm an "gemeinen Fallen" ist - man muß ja die Entwicklungszeit nicht unnötig hochtreiben. Beim Atmel würde ich mit AVR-GCC programmieren, beim MSP wahrscheinlich mit IAR. Ach ja, der MSP ist teurer. Aber wenn er für die Aufgabe besser geeignet ist, wäre das egal. Nun, geschätzte Experten... welcher eignet sich besser?
Also ich kann zum MSP430 nur sagen, dass der ADC an sich nicht schlecht ist, aber für echte 10 Bit Auflösung brauchst du einen mit 12 Bit ADC. Die unteren Bits rauschen immer recht viel. Ansonsten hängt das bei einem kommerziellen Gerät doch eigentlich alles am Preis, oder? Wenn der ATMega bei gleichen Daten billiger ist als der MSP430, wieso dann nicht? Übrigens gibts für den MSP430 auch den GCC, mittlerweile sogar recht stabil. Oder Code Composer Essentials von TI, der macht in der freien Version 16 kByte und ist sehr angenehm, weil auf Eclipse basierend. Wenn der Preis egal ist, ist es ja wirklich nur noch eine Glaubensfrage....außer dass vielleicht selbst der Original-TI USB Debugger für den MSP430 viel billiger ist als ein JTAGICE MK II.
Viele MSP430-Derivate haben einen 12-Bit-ADC, und der ist vorzüglich, und mit ein paar hundert kSamples/sec auch recht flott. Mittels Oversampling lässt sich auch noch mehr Auflösung 'rausholen. Für die UART des MSP430 benötigt man keine speziellen Baudratenquarze;mit einem 8 MHz-Quarz lassen sich problemlos die üblichen Baudraten bei einer Fehlerrate von unter einem Prozent erzeugen. Sehr empfehlenswert ist die Verwendung eines anständigen JTAG-Interfaces, das ist beim MSP430 günstiger* zu bekommen als beim AVR, bei dem es wohl auch nicht mit jeder Variante funktioniert. ISP funktioniert beim MSP430 über das JTAG-Interface oder einen seriellen Bootloader (BSL), was diese ganzen Parallelportfrickellösungen entbehrlich macht. Als Alternative zu IAR (was in der nicht-codegrößenbeschränkten Version recht teuer ist) bieten sich Rowley Crossworks oder das freie mspgcc an. Crossworks hat eine funktionierende Floatingpoint-Unterstützung, auch mit 64-Bit-Doubles, wenn man sowas benötigt. Zu guter Letzt: Der MSP430 ist eine von-Neumann-Maschine, kein krampfiges pgmspace.h/PROGMEM-Geraffel. *) Das "Original" MSP-FET430UIF von TI höchstselbst kostet ca. 100 USD, ein Nachbau von Olimex noch weniger. Mit dem TI-"Original" können alle MSP430-Derivate angesprochen werden, auch die, die SpyBiWire verwenden.
Danke für die schnellen Antworten. Was die Programmierung angeht: Für den MSP hätte ich Parallelport-JTAG zur Verfügung (Nachbau, aber kein Eigenbau), für den Atmel ein originales AVRISP MKII (also keinen Debugger). Dafür habe ich mit dem Atmel mehr Erfahrung, der MSP kenne ich nur "von außen", habe also selbst noch nichts dafür programmiert. Ist das eine große Umstellung, was die Bedienung der Peripherie angeht? Ansonsten ist ja wohl C gleich C.
Übrigens: Der 12-bit ADC würde mich schon reizen, das sind dann aber gleich die Versionen im TQFP64-Gehäuse... eigentlich überdimensioniert.
Also der 10 Bit ADC im MSP430 ist auch nicht übel. Muss man halt oversampeln für echte 10 Bit. Geht aber. Parallel-Debugger ist nicht ganz so doll, geht zwar, aber relativ langsam. Mit IAR gehts recht flott, mit mspgcc langsamer. Warum, weiß wohl keiner. Ich hab auf Arbeit die original TI USB Debugger, zu Hause den Olimex JTAG Tiny USB. Der Olimex geht viel viel schneller als die original-Dinger. So macht Debuggen Spaß. Peripherie ist halt sicherlich etwas anders als bei Atmel, aber dank der detaillierten User Guides und der vieln Code-Beispiele direkt von TI leicht verständlich. Schön am MSP430 ist halt das Power-Management und die Möglichkeit, für jedes Peripherie-Moduls verschiedene Takte zu benutzen.
>Ist das eine große Umstellung, was die Bedienung der Peripherie angeht? >Ansonsten ist ja wohl C gleich C. Ich würde sagen das der Vorteil durch JTAG Debugging die Nachteile der Umstellung deutlich übersteigt.
>Ich hab auf Arbeit die original TI USB Debugger, zu Hause den Olimex >JTAG Tiny USB. Der Olimex geht viel viel schneller als die original- >Dinger. So macht Debuggen Spaß. Seltsam das bei mir die parallel JTAGs immer schneller sind :) Hab an der Arbeit den Elprotronic parallel Programmer und zu Hause den original parallel TI. Ein Test mit dem Elprotronic USB Programmer war vernichtend. Umständliches Treibereingestelle und langsam wie die Hölle, nicht zu gebrauchen...
Schon seltsam. Kommt wahrscheinlich auf die Implementierung der Parallelport-Treiber an. Der original TI USB Debugger ist auch kaum schneller als so ein Par-Port-Nachbau (von Steven Wetzel). Allerdings nur mit IAR. Mit dem GCC ist der parport schnarchend lahm. Liegt wohl der GiveIO. Naja, ich hab jetzt den Olimex, hat mich gebraucht 35€ gekostet, der ist sauschnell und kann auch SpyBiWire.
Sebastian E. wrote: > Übrigens: Der 12-bit ADC würde mich schon reizen, das sind dann aber > gleich die Versionen im TQFP64-Gehäuse... eigentlich überdimensioniert. Wenn man noch was anderes vorschlagen darf... https://www.silabs.com/products/mcu/automotive/Pages/C8051F50x.aspx ist ein 8051er, 12-Bit/200 ksps, Automotive, interner Oszillator der auch für eine Serielle reicht, int. Spannungsregler, UART + CAN/LIN. Allerdings sollte man dann mit der Rev B der Controller arbeiten. Entwicklungsumgebung von kostenlos: SiLabs IDE + SDCC bis zu Keil, Tasking, IAR etc. Programmier/Debugadapter (Base + Debug < 30 €) https://www.silabs.com/products/mcu/Pages/ToolStick.aspx
Das klingt ja schon ganz gut. Da das ganze aus Zeitgründen auf Anhieb funktionieren muß, werde ich wohl beide Varianten layouten und die Prototypen-Leiterplatten als gemischten Nutzen bestellen. Dann habe ich eine Backup-Lösung, falls alle Stricke reißen. Aber es scheint ja so, als ob der MSP hier die erste Wahl ist. Wäre eigentlich eine gute Gelegenheit, sich darin einzuarbeiten. Was den ADC angeht, das zehnte Bit könnte ich verwerfen, aber neun müssen brauchbar sein. Notfalls nach Mittelwertbildung.
@Arc Net: Die Silabs-Chips sind eigentlich schön - zumal 8051-basiert und mit wirklich viel Speicher-, aber für diese Anwendung vielleicht doch etwas zu teuer. So 5 bis 6 Euro pro Stück, wenn ich das richtig gesehen habe, gegenüber 4,55€ (Reichelt) bzw. $3,15 (TI) für den MSP, werden dem Kunden dann doch zuviel sein, zumal viele der tollen Eigenschaften dieser Chips bei der geplanten Anwendung gar nicht zum Tragen kommen.
Sebastian E. wrote: > @Arc Net: > Die Silabs-Chips sind eigentlich schön - zumal 8051-basiert und mit > wirklich viel Speicher-, aber für diese Anwendung vielleicht doch etwas > zu teuer. So 5 bis 6 Euro pro Stück, wenn ich das richtig gesehen habe, > gegenüber 4,55€ (Reichelt) bzw. $3,15 (TI) für den MSP, werden dem > Kunden dann doch zuviel sein, zumal viele der tollen Eigenschaften > dieser Chips bei der geplanten Anwendung gar nicht zum Tragen kommen. So viel teurer sind die nicht: MSP430F1232IDW bei Digi-Key 1+ 5 $, 100+ 3.375 $, 1000+ 3.125 $ C8051F506-IM 1+ 5.92 $, 100+ 3.9469 $, 1000+ 3.49962 $ der C8051F507 ohne CAN und LIN liegt bei 1000+ bei 3.27247 $
Das ist eigentlich eine Überlegung wert. Ob der Einkauf diesen Programmieradapter innerhalb weniger Tage bekommt, ist noch die andere Frage.
Die Teile sind z.Z. alle bei Digi-Key auf Lager inkl. komplettem Development Kit (C8051F500DK), Toolstick (Base + Debug) müssten auch bei Farnell auf Lager sein.
Sebastian E. wrote: > Dafür habe ich mit dem Atmel mehr Erfahrung, der MSP kenne > ich nur "von außen", habe also selbst noch nichts dafür programmiert. Ich würde dann eindeutig den nehmen, mit dem ich schon Erfahrung habe. Es sei denn, Du bist nicht unter Termindruck und hast genügend Zeit, was neues auszuprobieren. > Ist das eine große Umstellung, was die Bedienung der Peripherie angeht? Soweit ich weiß, hast der MSP eine ziemlich komplexe Taktversorgung (PLL usw.). Das mag ja für Batteriebetrieb ganz nett sein, aber wenn mans nicht braucht, muß man sich trotzdem damit beschäftigen. > Ansonsten ist ja wohl C gleich C. Im Prinzip ja, aber die ganze Peripherie muß man neu lernen. Zum ADC des AVR (ATmega8) kann ich nur sagen, der steht auf 10Bit, wie ne Eins. Mit Oversampling kann man keine zusätzlichen Bits rausholen, das ist Quatsch. Ich hab selbst mit Summe über 256 Meßwerte kein 11. Bit rauskitzeln können, es hat lediglich nur länger gedauert, bis der Meßwert stabil war. Zusätzliche Bits gibts nur, wenn man ein Rauschsignal erzeugt und addiert oder wenn der ADC selber stark rauscht. Peter
@Peter Dannegger >Soweit ich weiß, hast der MSP eine ziemlich komplexe Taktversorgung >(PLL usw.). Höchstens die 4xx-Reihe, da habe ich aber selbst keine Erfahrung mit. Die 1xxer und 2xxer haben meines Erachtens überhaupt keine komplexe Taktversorgung. Im Simpelsten Fall muss man nämlich gar nix machen und das Dingens läuft;-) Ich finde die Taktversorgung -ganz im Gegenteil- recht einfach zu handhaben, äußerst flexibel und energiesparend
O ja, und man kann die Takterzeugung zur Laufzeit konfigurieren und man muss keine "Fuses" programmieren, was bei AVR-Anfängern wohl eine der primären Fehlerquellen zu sein scheint.
Ich kann die Silabs MCUs nur wärmstens empfehlen! Habe selbst mit dem C8051F041 und dem F530A gearbeitet. Eval Boards sind günstig und dabei gibts immer einen USB Programmer/Debugger dazu. Für diese 8051 Derivate spricht auch der "Configuration Wizzard" von Silabs mit dem sich sehr schnell diverse Controller Module konfigurieren lassen und so wirklich Entwicklugszeit gespart werden kann. Diese Config ist als C-Code speicherbar. Als worklich brauchbares Feature hat sich die "Crossbar" herausgestellt. Dabei handelst es sich um ein Modul das nahezu jede beliebige Peripheriefunktion an nahezu jeden beliebigen PIN routet. Auch das Angesprochene erzeugen von unterschiedlichen internen Systemtakten (auch die UART) ist mit den Silabs Controllern einfach möglich. das ganze "on the fly" ohne lästige Fuses. Ich muss sagen das ich auch den MSP430 so wie auch diverse AVRs kenne. Hauptsächlich gefällt mir an den 8051ern die hoch verfügbare bit-Adressierbarkeit von Registern. Bei den AVRs empfehle ich CodeVision und bei den MSPs Crossworks. Für die 8051er verwende ich uVision von Keil.
> Als worklich brauchbares Feature hat sich die "Crossbar" herausgestellt. > Dabei handelst es sich um ein Modul das nahezu jede beliebige > Peripheriefunktion an nahezu jeden beliebigen PIN routet Das ist ein wirklich geiles Feature. Sollten die anderen auch machen.
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.