www.mikrocontroller.net

Forum: Compiler & IDEs AVR oder MSP430


Autor: Matthias (Gast)
Datum:

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

Autor: Peter Dannegger (peda)
Datum:

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

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

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

Autor: Peter Dannegger (peda)
Datum:

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

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

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

Autor: Peter Dannegger (peda)
Datum:

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


Peter

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

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

Autor: Peter Dannegger (peda)
Datum:

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

Autor: Christian Bischoff (Gast)
Datum:

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

Autor: Peter Dannegger (peda)
Datum:

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

Autor: Matthias (Gast)
Datum:

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

Autor: Notker (Gast)
Datum:

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

Autor: Weinga-Unity (Gast)
Datum:

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

Autor: Joerg Wunsch (Gast)
Datum:

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

Autor: Notker (Gast)
Datum:

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

Autor: Peter Dannegger (peda)
Datum:

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

Autor: Joerg Wunsch (Gast)
Datum:

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

Autor: Notker (Gast)
Datum:

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

Autor: Notker (Gast)
Datum:

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

Autor: Joerg Wunsch (Gast)
Datum:

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

Autor: m@is (Gast)
Datum:

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

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.