www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik MSP430 oder ATmega für Projekt? (ADC, UART wichtig)


Autor: Sebastian E. (der_andere_sebastian)
Datum:

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

Autor: Christian R. (supachris)
Datum:

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

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

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

Autor: Sebastian E. (der_andere_sebastian)
Datum:

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

Autor: Sebastian E. (der_andere_sebastian)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Übrigens: Der 12-bit ADC würde mich schon reizen, das sind dann aber 
gleich die Versionen im TQFP64-Gehäuse... eigentlich überdimensioniert.

Autor: Christian R. (supachris)
Datum:

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

Autor: Jörg S. (joerg-s)
Datum:

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

Autor: Jörg S. (joerg-s)
Datum:

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

Autor: Christian R. (supachris)
Datum:

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

Autor: Arc Net (arc)
Datum:

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

Autor: Sebastian E. (der_andere_sebastian)
Datum:

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

Autor: Sebastian E. (der_andere_sebastian)
Datum:

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

Autor: Arc Net (arc)
Datum:

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

Autor: Sebastian E. (der_andere_sebastian)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das ist eigentlich eine Überlegung wert. Ob der Einkauf diesen 
Programmieradapter innerhalb weniger Tage bekommt, ist noch die andere 
Frage.

Autor: Arc Net (arc)
Datum:

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

Autor: Peter Dannegger (peda)
Datum:

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

Autor: Stefan (Gast)
Datum:

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

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

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

Autor: Bertram S. (bschall)
Datum:

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

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

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

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.