www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik AVR vs MSP430 und Linux


Autor: Klaus W. (Firma: privat) (texmex)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo!!

Meine Microcontroller-Erfahrungen liegen fast schon Jahrzehnte zurück.
Nun möchte ich mich gerne im Rahmen einer Hobby Anwendung mit einem
etwas moderneren Controller beschäftigen. Ich bin in der Auswahl also
völlig frei. Und das macht die Sache kompliziert!

Zunächst wäre es schön, wenn PDIP Gehäuse verfügbar wären. Damit fällt
Freescale schon mal raus, wenn ich das richtig sehe.

PICs wären wohl was die Gehäuse angeht am vielfältigsten,
allerdings erscheint mir die Leistungsfähigkeit dieser Prozessoren
eher etwas eingeschränkt gegenüber der Konkurrenz.

Atmel und Ti sind offensichtlich gerade im Hobbybereich sehr populär.
Das wird wohl seinen Grund haben, aber gäbe es evtl. trotzdem weniger
bekannte Controller, die man sich mal angucken sollte?

Ein ganz wichtiger Punkt ist eine Entwicklungsumgebung unter Linux.
Das schließt auch die Datenübertragung zum Controller mit ein.
Weiterhin wäre es sehr von Vorteil dieses per USB bewältigen zu können.

Sehe ich das richtig, dass eigentlich nur der Bootloader des MSP430 in
Frage kommt um die Daten über eine serielle (USB) Schnittstelle unter
Linux in einen Prozessor zu bekommen?

Die ganzen proprietären Technologien wie debugWIRE und spy-bi-wire
lesen sich recht angenehm, da gerade in einem 14 oder gar 8-pin
Gehäuse die Peripherieleitungen nicht gerade großzügig verwendet
werden können.
Aber dafür wird es wohl gar keine freien Tools geben. Können das denn
wenigstens die kostenlosen Einsteigertools der Hersteller (AVRStudio
bzw. dieses Kickstartdings von ti)? Oder muss man dafür zahlen?

Wenn mir nun jemand raten würde, die Idee die Programmierung über eine
USB Schnittstelle gleich zu vergessen, würde das auch den
Windowseinsatz nicht generell ausschließen. Allerdings stünde dann
nur win98 zur Verfügung und ich bezweifle, daß die Tools darin
lauffähig sind.

Ich will aber nun die Auswahl des Prozessors nicht übermäßig am
Aufwand für das Setup der Entwicklungsumgebung orientieren, wenn
andere Gründe für oder gegen einen Prozessor sprechen würden.

Es heißt der Bootloader des MSP sei recht buggy, auch die A/D-Wandler
seien quasi nicht zu gebrauchen.

JTAG am MSP430 braucht offenbar 4 Leitungen, SPI am AVR aber auch
schon 3. Das macht keinen großen Unterschied mehr. Und das debugging
des MSP mit JTAG scheint mittels gnu toolchain recht praktikabel
zu sein. Wenn ich debugWIRE mangels passendem Betriebssystem für
AVRStudio sowieso nicht benutzen kann spricht diesbezüglich nicht
mehr viel für AVR.

Ich hätte z.B. eine Kfz (äh, pardon, automotive nennt man das wohl
heutzutage :-) Anwendung. Gibt es für den MSP brauchbare
Spannungsregler, deren Eigenverbrauch nicht den sparsamen Verbrauch
des Prozessors wieder kaputt macht? (Natürlich gibt es die, aber es
wäre halt auch wieder schön im DIP oder TO-xx Gehäuse und sie
sollten auch in kleinen Stückzahlen bei so "consumer-distributoren"
wie Reichelt o.a. erhältlich sein).
Der MAX666 schwebte mir da vor, aber der macht ohne externe
Beschaltung nur 5V. Auch anderer Peripherie würden 5V oft besser
"schmecken", was mich wieder eher an den AVR denken lässt.
Aber auch das sind alles Probleme, die sich beim MSP lösen
lassen. Die Frage ist, ob sich der Aufwand lohnt?

Ok, MSP hat 16bit. Das hat gerade bei Assembler-Programmierung
natürlich schon seinen Charme. Ich habe bislang noch nie einen
Mikrocontroller in C programmiert, aber ich stelle mir vor, daß
eine 8bit Variante in C ähnlich komfortabel zu handhaben sein
müsste. Abgesehen davon, dass der Code weniger effizient sein
dürfte.

Ich stehe der C-Programmierung eines Mikrokontrollers sowieso
noch etwas skeptisch gegenüber. Sicher bietet sich das in
leistungsfähigeren und umfangreicheren Applikationen an, aber manchmal
drängt sich mir der Verdacht auf, dass man sich nur vor der
Assemblersprache scheut? - Ok, ich weiß schon, portabilität, reusability 
usw usw... Aber hat das nicht auch seinen Preis?

Der MSP hat kein EEPROM. Ist das in der Praxis eine
Einschränkung? Ist die TI-Philosophie dergestalt, daß man aufgrund
des geringen Stromverbrauchs eh immer irgendwo ne LI-Batt
anstöpseln und so auf "Datensicherung" verzichten kann?

Letztenendes hängt die Entscheidung bei mir wohl in erster
Linie schon maßgeblich davon ab, wie "smooth" sich die
Entwicklungsumgebung handhaben lässt. Aber das ist wohl
auch viel eine Frage des persönlichen Geschmacks und wird man so
pauschal nicht beantworten können. Generell bin ich jedenfalls
eher ein Freund von Comandline-Tools unter Linux als von
bunten Windows-Programmen. Und eine zuverlässige Funktion wiegt
sicher schwerer als dass man mit ein paar Mausclicks eine LED
zum Blinken bringen kann.

Kommt man eigentlich früher oder später zur "Rettung" um so nen
HV-Programmer eh nicht drum rum? Ein AVR ist damit IMMER zu retten,
oder? Bei Ti gibt es etwas vergleichbares nicht, soweit ich sehe.
D.h. ein TI-Controller ist per Programmierung unrettbar zu
zerstören?

Bei Prozessoren dieser Kategorie scheinen Bugs wohl mehr oder weniger
normal zu sein. Bei einigen PICs ist die Liste allerdings schon
beeindruckend lang. TI hat die Bugs veröffentlicht, bei Atmel
habe ich derartiges noch nicht gefunden. Gibt es denn
tatsächlich schwerwiegende Fehler, die die Verwendbarkeit eines
Controllers beeinträchtigen?

Dieses USB-Stick evaluation board von ti sieht recht lustig aus.
Ich vermute das ist aber auch nur mit der mitgelieferten Software
zu gebrauchen und stellt zum Host-System hin nicht etwa eine
normale serielle USB Schnittstelle dar, über die sich z.B.
der Bootloader im MSP bedienen lassen würde?


Ich bin mir schon bewusst, das mein Artikel jetzt recht umfangreich
geworden ist und die Chancen darauf eine umfangreiche Antwort
zu bekommen eher gering sind.
Trotzdem oder gerade deswegen würde ich mich aber SEHR freuen, wenn
sich jemand die Mühe machen würde, das eine oder andere ein wenig
zu kommentieren.

Vielen Dank und viele Grüße!
Klaus

Autor: Εrnst B✶ (ernst)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich hab mich in den letzten Jahren mit 8051ern, AVRs und PICs gespielt, 
für alle gabs unter Linux Compiler, Assembler, Linker und Tools zum 
flashen.

8051er mit SDCC, hatte allerdings den AN2131SC, der schon einige 
Erweiterungen/Änderungen gegenüber den Standard-'51ern hat. Vorallem 
einen eingebauten USB-Bootloader. Ansteuerung über fxload. Den Chip 
gibts leider AFAIK nicht mehr, evtl mal bei den Nachfolgemodellen 
umsehen.

PIC geht ebenfalls mit SDCC, gibt auch ein paar schöne graphische 
Oberflächen für, piklab, ktechlab, pikdev. USB-Programmer dafür gibts 
bei www.sprut.de. Dummerweise weicht die SDCC Syntax deutlich von der 
des  Microchip-Compilers ab, Beispielprogramme aus dem Web lassen sich 
also meist erst nach einigen Anpassungen verwenden.

AVRs lassen sich perfekt unter Linux programmieren, immerhin sind fast 
alle AVR-Tools unter Windows einfach Ports der Unix-Versionen, avr-gcc, 
avrdude, uisp, ... Programmieren über USB geht z.B. mit dem USBasp 
(http://www.fischl.de/usbasp/).

HV-Programmer zur Rettung verflashter AVRs hab ich noch nie gebraucht, 
man muss halt ein bischen vorsichtig mit den Fuses sein. Ansonsten: 
Verflashte AVRs alle in ner Kiste sammeln, wenn die zusammen mehr Wert 
sind als ein HV-Programmer kostet lohnt sich die Anschaffung :).

Zur Programmiersprache: Freunde dich mit C an, da ist dann der Umstieg 
auf eine andere Architektur relativ schmerzlos.
Ansonsten:
> fortune
"The C Programming Language -- A language which combines the flexibility 
of assembly language with the power of assembly language."

/Ernst

Autor: Jörg S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> JTAG am MSP430 braucht offenbar 4 Leitungen,
+ Reset + GND (+ evt. TEST).

> Der MSP hat kein EEPROM. Ist das in der Praxis eine Einschränkung? Ist
> die TI-Philosophie dergestalt, daß man aufgrund des geringen
> Stromverbrauchs eh immer irgendwo ne LI-Batt anstöpseln und so
> auf "Datensicherung" verzichten kann?
?? Der MSP hat Flash als NVM. Da geht nichts verlohren, oder wie meinst 
du das?

> D.h. ein TI-Controller ist per Programmierung unrettbar zu
> zerstören?
Wenn man die Fuse nicht kaputt macht (was man unabsichtlich kaum 
schafft) geht da überhaupt nichts kaputt.

> Dieses USB-Stick evaluation board von ti sieht recht lustig aus.
> Ich vermute das ist aber auch nur mit der mitgelieferten Software
> zu gebrauchen und stellt zum Host-System hin nicht etwa eine
> normale serielle USB Schnittstelle dar, über die sich z.B.
> der Bootloader im MSP bedienen lassen würde?
Ich kenn die Platine jetzt ehrlich gesagt im Detail nicht, aber der 
Bootloader wird beim MSP (meiner Erfahrung nach) extrem selten bei 
solchen Boards verwendet. I.d.R. wird immer per JTAG angesteuert um 
Debugging Funktionen nutzen zu können.

Autor: Joe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Kernfrage ist nicht "welchen MC verwende ich (du)" sondern was 
willst du damit machen ?

Du fängst also bei Null an, daher ist es egal womit du startest. Über C 
solltest du aber noch einmal nachdenken. ASM ist nicht portierbar, C 
schon (zumindestens > 80%).

Autor: Klaus W. (Firma: privat) (texmex)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo!!!

Vielen Dank gleich mal für die Antworten!

@Ernst Bachmann:
>avrdude, uisp, ... Programmieren über USB geht z.B. mit dem USBasp
>(http://www.fischl.de/usbasp/).

Das sieht ja schon mal recht vielversprechend aus. Nach dem
Studium der avrdude manualpage bin ich auch auf "AVRISP mkII"
gestoßen. Das Teil scheint dem usbasp vergleichbar zu sein.
Nur wesentlich teurer :-).

>Zur Programmiersprache: Freunde dich mit C an, da ist dann der Umstieg
>auf eine andere Architektur relativ schmerzlos.
Oh, ich hab' kein Problem mit C. Ich frage mich nur immer ob
die Abstraktion im Falle der Microcontrollerprogrammierung
wirklich so ausgeprägt ist, daß der Umstieg
auf eine andere Achitektur WIRKLICH schmerzlos sein kann.
Aber darüber brauchen wir nicht weiter diskutieren, das muss ich halt
einfach mal ausprobieren.


@Jörg:

> > Der MSP hat kein EEPROM. Ist das in der Praxis eine Einschränkung? Ist
> > die TI-Philosophie dergestalt, daß man aufgrund des geringen
> > Stromverbrauchs eh immer irgendwo ne LI-Batt anstöpseln und so
> > auf "Datensicherung" verzichten kann?
> ?? Der MSP hat Flash als NVM. Da geht nichts verlohren, oder wie meinst
> du das?
Naja, der Code im Flash geht natürlich nicht verloren. Aber wenn
ich im Betrieb mal ein paar Byte über einen Stromausfall hinweg
retten will... Das Flash scheint für
solche Aktionen doch eher ungeeignet, oder?

> Ich kenn die Platine jetzt ehrlich gesagt im Detail nicht, aber der
> Bootloader wird beim MSP (meiner Erfahrung nach) extrem selten bei
> solchen Boards verwendet. I.d.R. wird immer per JTAG angesteuert um
> Debugging Funktionen nutzen zu können.
Klar, alles andere ist wohl auch eher ein Notlösung. Aber bei
einem 14pol Gehäuse muss man mit den Pins eben schon etwas geizen.


@Joe:
> Die Kernfrage ist nicht "welchen MC verwende ich (du)" sondern was
> willst du damit machen ?
Jein. Primär will ich erstmal mit dem Prozessor spielen. Die
aktuelle Anwendung ist pipifax und mit jedem Prozessor zu realisieren.
Deswegen würde ich mir eben gerne einen "schönen" aussuchen.
So dass sich das angeeignete Wissen evtl. auch später in Projekten
bewähren könnte (die es jetzt noch gar nicht gibt).

In dem Zusammenhang wären die 16bit des MSP schon auch reizvoll.
Aber wenn ich in C programmiere, werde ich davon (außer
in Form von effizienterem Assemblercode) wohl nicht viel merken, oder?
Das ist ja schließlich der Sinn der Portabilität.

Viele Grüße!
Klaus

Autor: PS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bezüglich des MSP430 ist anzumerken, daß der GCC (mspgcc) für diese
µC-Familie noch auf gcc-3.x basiert und die Weiterentwicklung offenbar
nur schleppend voranschreitet. In den offiziellen GCC-Releases der
FSF ist bisher keine MSP430-Unterstützung vorhanden. (Die aktuellen
Binutils enthalten Unterstützung für den MSP430.)

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

Bewertung
0 lesenswert
nicht lesenswert
> Es heißt (...) die A/D-Wandler
> seien quasi nicht zu gebrauchen.

Es gibt in unterschiedlichen MSP-Varianten unterschiedliche A/D-Wandler 
(ADC10, ADC12 und ADC16), welcher soll denn nicht funktionieren?
Der ADC12 funktioniert in meinem Projekt zufriedenstellend.

> Naja, der Code im Flash geht natürlich nicht verloren. Aber wenn
> ich im Betrieb mal ein paar Byte über einen Stromausfall hinweg
> retten will... Das Flash scheint für
> solche Aktionen doch eher ungeeignet, oder?

Dafür ist das sogenannte "Information memory" gedacht, das ist zwar auch 
"nur" Flash, kann aber im Betrieb beschrieben werden. Es ist in 
Segmenten à 128 Bytes Größe aufgebaut.

Die Zweidraht-Debugschnittstelle der kleinen MSP430 ('F20xx) heißt 
SpyBiWire, verhält sich aber im Endeffekt wie ein echtes JTAG-Interface.

Der für just diese kleinen MSPs verkaufte "USB-Stick" ist ein 
vollwertiges SpyBiWire-Interface, darüber ist mit der mitgelieferten 
Software sowohl ein Programmieren als auch ein Debuggen möglich. Die 
codegrößenbeschränkte Version des IAR-Compilers ist hier vollkommen 
ausreichend, da die kleinen MSPs weniger Flash-ROM haben als der 
Compiler kostenlosen Code generieren kann ...

Allerdings ist das Windows-Software; inwiefern der "USB-Stick" mit 
irgendeinem *nix-Derivat zu verwenden ist, entzieht sich meiner 
Kenntnis.

Von Olimex gibt es ein USB-JTAG-Interface für MSP430, mit dem sich auch 
die größeren Brüder bearbeiten lassen, es soll auch ein 
SpyBiWire-Interface enthalten (habe ich selbst nicht getestet).

Aber auch hier kann ich zur Praxis unter *nix nichts sagen.

Zur Entwicklung jedenfalls ist JTAG einem einfachen Bootloader gegenüber 
vorzuziehen, und beim '20xx belegt das SpyBiWire-Interface eh nur nicht 
anderweitig nutzbare Pins.

Literaturempfehlung:
"Das große MSP430-Praxisbuch, Bierl, Franzis-Verlag". Zwar spröde 
geschrieben und geht auch nicht auf neuere Familienmitglieder wie die 
'20xx ein, aber von einem (übrigens deutschen) Entwickler des MSP430 
höchstselbst verfasst.

Autor: Rolf Magnus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> I.d.R. wird immer per JTAG angesteuert um Debugging Funktionen nutzen
>> zu können.
> Klar, alles andere ist wohl auch eher ein Notlösung. Aber bei
> einem 14pol Gehäuse muss man mit den Pins eben schon etwas geizen.

Bei den kleineren AVRs gibt's dafür DebugWire. Da kann man die 
Programmierung und das Debugging komplett über einen einzigen (den 
RESET-) Pin erledigen. Das geht dann sogar schon bei Achtbeinern wie dem 
ATtiny13. DebugWire und JTAG werden z.B. vom AVR-Dragon unterstützt, 
aber leider nur bei Controllern bis 32k Flash. Das kann man dann per 
avarice auch unter Linux mit GDB verwenden.

Autor: Klaus W. (Firma: privat) (texmex)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Rolf Magnus wrote:
> Bei den kleineren AVRs gibt's dafür DebugWire. Da kann man die
> Programmierung und das Debugging komplett über einen einzigen (den
> RESET-) Pin erledigen. Das geht dann sogar schon bei Achtbeinern wie dem
> ATtiny13. DebugWire und JTAG werden z.B. vom AVR-Dragon unterstützt,
> aber leider nur bei Controllern bis 32k Flash. Das kann man dann per
> avarice auch unter Linux mit GDB verwenden.

AHA! Das ist ja toll dass debugWIRE mit dem gdb nutzbar ist!
Mit dem USBasp Adapter wird das aber wohl nicht gehen?

Inzwischen habe ich festgestellt dass es offensichtlich sehr günstige 
Bundles aus AVR-Dragon und STK500 (39 Euro?) gegeben hat. Ich hab' zwar 
nichts gegen Selbstbasteln, aber in dem Fall würde man wohl nichts 
falsch machen.

Ob es da wohl wieder irgendwelche Sammelbestellungen gibt?


Viele Grüße!
Klaus

Autor: Fastpensioniert (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Klaus,
Du hast derart einengende Anforderunegen, dass du die Mikrocontroller 
besser sein laesst. Du kannst auch ohne diese schnell genug pensioniert 
werden. Eine SMD Leiterplatte gehoert heute dazu. Mit PDIP gewinnt man 
nichts. Faedeln und Wrappen sind vorbei. Die EMV Anforderungen sind 
heute derart hoch, das das nicht mehr geht. Jeder will sein 
Mobiltelephon auch noch auf die Leiterplatte legen koennen ohne dass da 
nichts mehr laeuft. Und das ist mit geaetzen Leiterplatte und SMD 
Technologie machbar. Vergiss Linux fuer die Microcontrollerentwicklung. 
Da ist nichts. Die heute verwendeten Tools sind fuer Windows geschrieben 
worden. Die modernen Click-click IDEs bieten auch was fuer's Clicken. 
Einen globalen Replace mit GREP, naja, muss nicht sein. Simulatoren 
gehoeren zu einer IDE und sind besser als ein Singlestep auf dem Target. 
Vergiss, dass du mit einem Bootloader einen Programmer aushebeln kannst. 
Den Programmer, unter Windows, benoetigt man weiterhin, zumindest um den 
Bootloader ins Device zu kriegen. Der JTAG Anschluss ist nicht immer die 
optimale Alternative zum SPI ptrogrammer. Aus Platzgruenden kommt es 
vor, dass das JTAG Port auf dem ADCs oder sonstwo liegt. Dh man tauscht 
JTAG gegen eine funktionalitaet, wogegen das SPI port nemeb dem 
Programmieren auch als SPI laufen kann.
Vergiss die vielzitierte C-Kompatibilitaet fuer Portierbarkeit. Das ist 
dummes Geschwaetz. Wenn man etwas fuer einen AVR entwickelt hat wird 
man's nicht nach PIC, oder MSP430 portieren, das Problem ist ja geloest. 
Genauswenig wird man PC programme auf den Prozessor portieren. Die 
Programmierstile sind zu verschieden. Vergiss Objekte in verketteten 
Listen, vergiss Floating point, das macht man alles nicht so. Ausser C 
gibt es genuegend Alternativsprachen, nicht immer gratis, aber guenstig. 
In dem Sinne...

Autor: antworter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Man sollte zwischen professionellem (viel-Geld-verdienendem) und 
Hobby-Bastler (Geld-reinsteckendem) unterscheiden.

Wer die Programmiertätigkeit pro Stunde bezahlt bekommt, kauft seine 
Geräte/Software nach dem Kosten:Zeitersparnis Faktor - der Hobbybastler 
geht vor allem nach dem Preis.

...und so kommt es, daß der Hobbybastler gerne in den "sauren Apfel" 
beißt, und mittels gcc und eclipse unter Linux entwickelt - kostenlos 
und fast genauso produktiv.

Somit gilt die Aussage

>Vergiss Linux fuer die Microcontrollerentwicklung. Da ist nichts.

Vielleicht gilt es in einer Firma, aber nicht in diesem Forum :-)

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Vergiss Linux fuer die Microcontrollerentwicklung.
> Da ist nichts. Die heute verwendeten Tools sind fuer Windows geschrieben
> worden.

Crossworks AVR, MSP430 und ARM gibt es für Linux. Man kommt aber auch 
mit den Open-Source-Tools schon sehr weit. JTAG-Debugging funktioniert 
z.B. bei MSP430 & ARM unter Linux einwandfrei (AVR habe ich nicht 
ausprobiert). Und wer gern klickt kann das ganze in Eclipse oder eine 
andere universelle IDE einbinden.

> Den Programmer, unter Windows, benoetigt man weiterhin, zumindest um den
> Bootloader ins Device zu kriegen.

Das geht unter Linux genauso.

> Vergiss die vielzitierte C-Kompatibilitaet fuer Portierbarkeit. Das ist
> dummes Geschwaetz.

Das ist alles andere als "dummes Geschwätz". Es ist sehr angenehm die 
gleichen Bibliotheken für FAT32, LCD, 1wire, RC5, Entprellung, Drehgeber 
usw. auf verschiedenen Controllern verwenden zu können, ohne wieder bei 
Null anfangen zu müssen.

Autor: Rüdiger Knörig (sleipnir)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zum rein virtuellem Experimentieren ist KTechLab
http://ktechlab.org/
ganz nett. Da kannst Du (leider nur PIC-) Mikrocontroller in "analoge" 
Schaltungen einbetten und das in Echtzeit durchsimulieren.

Ansonsten habe ich meinen "Wiedereinstieg" mit AVR's geschafft indem ich 
mir einen einfachen SP-12-Programmieradapter gebaut
http://www.xs4all.nl/~sbolt/e-spider_prog.html
Dazu brauchst Du eigentlich nur eine Lochrasterplatte wo Du eine 
DB-25-Buchse (? oder Stecker?) seitlich raufschiebst und dann die paar 
Widerstände und Kondensatoren verlötest. Ich habe eine längere Platine 
genommen und auf dieser dann die Programmierleitungen als eine Art "Bus" 
oben durchgezogen. Darunter habe ich dann Sockel gelötet für die 
gängigen ATtiny's. Einen für den Tiny15 (ohne Quarz aber mit LED + 
Lötstifte für ein Eingangssignal), dann einen für einen ATtiny12/13 mit 
Quarz und jeweils einen für den ATtiny2323 und den ATtiny26.

Oder Du baust Dir halt einen Adapter mit einem ATmega nach dieser Art 
und baust dann darunter noch einen MAX232 mit seriellem Port.

Hier sind noch ein paar nette Artikel:
http://www.linuxjournal.com/article/7289

Autor: Rolf Magnus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>>Vergiss Linux fuer die Microcontrollerentwicklung. Da ist nichts.
>
> Vielleicht gilt es in einer Firma, aber nicht in diesem Forum :-)

Bei mir gilt es auch in der Firma nicht. Auf allen meinen Rechnern, 
sowohl in der Firma, als auch zuhause, mache ich die 
Mikrocontroller-Entwicklung ausschließlich unter Linux.

>> Vergiss die vielzitierte C-Kompatibilitaet fuer Portierbarkeit. Das
>> ist dummes Geschwaetz.
>
> Das ist alles andere als "dummes Geschwätz".

Ich würde eher das, was "Fastpensioniert" so schreibt, als dummes 
Gewschätz bezeichnen. Da ist ziemlich viel Unsinn dabei.

Autor: STS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

für den Hobbybereich sind beide Controller je nach Einsatzzweck geeignet

MSP 430:

+ preiswerte DEBUG/Download-Tools erhältlich (MSPFET oder Olimex-clone 
für 19 €)
+ gut strukturierter Assemblerbefehlssatz (man versaut sich nicht den 
Stil)
+ recht ausgereift: ADC12 geht ohne Props, wenn der 2,5V-Pufferzweig gut 
geblockt wird, siehe Datasheet. Interne Referenz auch OK.

- je nach Derivat und Gehäuse nicht mehr vom Hobbyelektroniker 
beherrschbar (Leiterplattenselbstherstellung MSP430 z. B. F149)
- miese EMV-Festigkeit (Ground-bounce wegen Low-Powerarchitektur-> 
KFZ???)
- kann über die PIN's mit Betriebsspannung versorgt werden (KFZ?)


AVR:

+ schöne DIL-Gehäuse
+ ausgereift
+ viel Flash/RAM verfügbar
+ kostenlose Downloadtools (Ponyprog)
+ recht EMV-fest (Mega): läuft als WIS auf Hochseeschiffen, hat auch 
eine DNV-Prüfung überstanden -> KFZ dürfte kein Problem sein

- Debugger teuer (bei Tiny-Typen oder dem alten S1200 kaum sinnvoll 
möglich)
- die alten Tiny-Typen hatten Latch up bei ESD-Pistolen-Beschuß im 
EMV-Labor
- exotische Assemblersyntax (Addressierungsarten)

Im übrigen würde ich C für den Controller nicht verschmähen. Bringt viel 
Lesbarkeit, einfache Wartung und Robustheit ins Programm. Ab 2k Flash 
mache ich nichts mehr in Assembler (zeitkritische Routinen, ISR mal 
ausgenommen)

Ein schöner C-Compiler für beide kommt von Imagecraft 
(www.imagecraft.com) und NoIce als Debugger. Der Vorteil: Sehr 
ausgereift, gleiche Oberfläche für beide und als Demo und Hobbyvariante 
kostenlos verfügbar. Nachteil: Nicht für Linux, keine Stimuli, keine 
SFR-Überwachung, keine Trace-Überwachung. Beide Tools liefen bei mir 
unter Win '98, Imagecraft für den ARM geht aber nur noch unter XP!

Ich würde für µC-Entwicklung eigentlich auch eher zu Windows raten.


PS: Schau mal bei MCT vorbei: www.elektronikladen.de

Autor: Klaus W. (Firma: privat) (texmex)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
STS wrote:

[diverse infos]

Vielen Dank für die Informationen! Die Entscheidung ist zwar inzwischen 
gefallen, aber ist trotzdem schön nochmal Bestätigung zu bekommen.

viele Grüße!
Klaus

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
falls Du nochmal einen Blick in diesen Beitrag wirfst, hätte ich noch 
einen Tip :

Interessant ist auch der R8C µC, hier gibt es für Linux das kpit-gnu 
tool (kostenlos) chain und der download in den µC geht mittels RS232 
Pegelwandler.

Einfach nur zur Info ...

Autor: R8C (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Funzt das kpit... auch mit dem E8?

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.