Mikrocontroller für Raumfahrt

Hallo Ivan (Rebrov),

vor einer Auswahl steht allgemein eine Leistungs-
beschreibung.
Warum ist der MSP ungeeignet ? Nicht performant genug ?
TI-Allergie ?
Wenn man die Leistungsfähigkeit kennt, kann man bezogen darauf
auch etwas aussuchen, sonst:
>> Ich habe ein rotes Auto, das zuviel Sprit verbraucht-
gibt es blaue, die weniger verbrauchen ? <<

Gruss
Dietmar

die PIC18 haben nanoWatt-technologie, haben aber "nur" 10-12MIPS - ob 
das wohl genügt?

Rebrov wrote:
> - Architektur 8/16/32 bit
also quasi jeder
> - Peripherien: CAN, I2C, etc.
das etc. macht die Sache etwas schwammig... was genau benötigt würde 
wäre hilfreicher
> - Integration von vorhandenener Software (Treiber)
wenn "vorhandener Software" im µC rein soll schränkt das die Sache schon 
ziemlich ein..
> - Zuverlässigkeit (Strahlung, Temperatur, Vibration etc.)
das klingt nach Spezialtypen sofern man nicht statt dessen die ganze 
Platine abschirmen kann
> - Entwicklungsumgebung
sollte es wohl für jeden µC geben
> - Verfügbare zusätzliche Komponenten
Kristallkugel... EEPROM, RTC, Temp-Sensor?

Problem könnte der Strahlungsschutz sein und, wenn nicht geheizt die 
Temperatur

Und in welcher reihenfolge sind die Kriterien zu betrachten?

ist die kosmische Stralung, Temperaturbereich, .. vernachlässigbar, wenn 
Toolchain, Leistungsverbrauch passen?

ich würde das eher andersherum sehen. Kill kritereien wie z.B Strahlungs 
unempfindlichkeit, Temperatur haben vorrang vor Toolchain, Treibern, ...

> - Architektur 8/16/32 bit
> - Peripherien: CAN, I2C, etc.
> - Tool chain
> - Integration von vorhandenener Software (Treiber)
> - Leistungsverbrauch sehr niedrig (Hybernation-Modes möglich)
> - Zuverlässigkeit (Strahlung, Temperatur, Vibration etc.)
> - Entwicklungsumgebung
> - Verfügbare zusätzliche Komponenten
> Des Weiteren wären folgende Probleme zu lösen:
> - Eine stabilere Kommunikationsarchitektur zwischen den einzelnen
> Komponenten
> - Unempfindlichkeit der CPU und des Speichers gegenüber kosmischer
> Strahlung

Die aufgabenstellung sieht eher nach einer Marktanalyse aus, was gibt es 
denn alle, was hat wer, welche vorteile / nachteile gibt es, ...

nur fehler irgendwelche vorgaben, z.B. Temeratur, Maximale Stromaufnahme 
im Hybernat und im Betrieb, gewünschte Rechenleistung, ...

Was ich in der Problemstellung schmerzlich vermisse

* Was, zum Teufel, soll das Ding eigentlich machen.
  Ihr werdet doch ja wohl irgendeine Vorstellung davon haben, welche
  Aufgaben, der µC zu übernehmen hat. Davon schätz man dann die
  Leistungsklasse ab und davon wiederrum kann man eine Aussage
  treffen, welche Architektur angebracht ist.
  Es ist doch völlig sinnlos, sundteures Equipment mit der Rechen-
  leistung eines Rechenzentrums hochzuschiessen, wenn es ein kleiner
  8-Bitter auch tut, der überspitzt ausgedrückt, den rechten Blinker
  betätigen muss. Es wird ja doch wohl zumindest irgendwelche Block-
  schaltbilder geben, in denen die Processing-Architektur des Sat
  abgebildet ist, und in dem man sagen kann: Dieser Prozessor
  übernimmt diese Teile, jener macht jenes.

* Wer im Entwicklungsteam hat Erfahrung mit welchem Prozessor.
  Sich den neuesten, schönsten, tollsten, schnellsten, stromsparendsten
  µC rauszusuchen ist eine Sache. Wenn aber 80% eures Dev-Teams auf
  einem bestimmten Prozessor 5 Jahre lang gearbeitet haben, dann
  kann dein neuer µC gar nicht so toll sein, dass dich nicht die
  Entwickler in ihrer gewohnten Architektur in Grund und Boden
  programmieren. Sie kennen viele Tricks zum Speicher/Strom/sonstiges-
  sparen. Und bis sie die neue Architektur intus haben, sind schon
  wieder Monate vergangen.
  Erfahrung ist durch nichts zu ersetzen. Noch nicht mal durch Geld.

Studenten 5 Jahre erfahrung? als team zusammen vieleicht ja.

Jede CPU ist anders. selbst wenn es ein ARMx core ist, ist doch jeder 
baustein der auf ihm aufbaut wieder anders, hat andere macken. Selbst 
inerhalb eines Herstellers, wo z.B. IP-Cors in den verschiedensten 
Bausteinen wiederverwendet werden, tauchen doch unerwartet wieder 
abweichungen auf.

ack

Amerikaner nennen solche Leute "rocket scientists". ;-)

Jankey wrote:

> sowas schmerzt ...

Full ACK.

Es kommt auf jedes Milliwatt an. Ueblicherweise ueberleben die 
Sonden/Satelliten ihre projektierte Lebensdauer um ein Vielfaches.

Beispiel Ulysses, 1990 mit Kieler Beteiligung gestartet, und immer noch 
wissenschaftlich aktiv, obwohl nur auf 7 Jahre ausgelegt.

Der Radionukidgenerator liefert inzwischen nur noch um die 50-70 Watt. 
Damit muessen die wissenschaftlichen Instrumente, Avionik und Telemetrie 
laufen sowie die Treibstoffleitungen geheizt werden.

Und das ist nicht die Ausnahme, eher die Regel.

Olli

--
http://www.ieap.uni-kiel.de/et/

ahem wrote:

> Ich darf euch beruhigen, vieles das da mitfliegt ist Studentenarbeit.

Solche grundlegenden Fragen bespricht man mit den Kollegen in der 
Arbeitsgruppe und nicht in einem Forum.

Nichts, was auf kommerziellen oder wissenschaftlichen Missionen 
mitfliegt, ist Studentenarbeit. Allenfalls beruht es teilweise darauf.

Als Diplomand macht man da i.d.R. "Voruntersuchungen" oder arbeitet eine 
Idee fuer einen Protoypen aus.

Olli

Ich wusste schon immer das das Forum echt Witzig is ! Aber is des ned 
etwas früh für den Aprilscherz?

Mal was produktives:

1. Mal eine generelles Treffen aller Teilbereiche des Sats um zu klären 
was wer von wem will (viele Notizen machen bei dem Metting)
Dann mal die wichtigsten Sachen zusammen schreiben.

2. Die einzelnen Entwicklungsbereiche schauen einmal wer von welchem 
Bereich abhängig ist und dann ein Rohkonzept erstellen.
(Kommunikation ist das A und O)

3. Alle wieder auf einen Haufen und erstellen von Lastenheften.

4. Ausarbeitung eines Pflichtenheftes welches dann wieder mit dem 
kompletten Team besprochen wird und dann hat man mal einen 
Ausgangspunkt.

(Naja man kann auch die 4 Punkte überspringen und einfach gleich 
anfangen so war ich auch mal ^^)

Ich würd mich selbst mal Fragen welcher Speichertyp ist am 
unempfindlichsten gegen Strahlung ? (EPROM oder EEPROM usw schon mal 
ned)

Ich find der Stromverbrauch is ned das wichtigste sondern das das Teil 
mal in der Lage ist ein gewissen Zeitraum ohne fehler der Strahlung zu 
wiederstehen.

Das Energieversorgungskonzept muss Global für den Satelliten entwickelt 
werden. zB wenn man Daten sendet das der µC mit einem geringeren 
Taktläuft usw.
Es muss an ein Notfallsystem gedacht werden das zB nur bei einem 
gewissen Energielevel gewisse Bauteile an die Stromversorgung kommen und 
ned einfach nur beim µC sparen.

MFG Patrick

Naja ich würd nen OTP µC nehmen oder PROM µC da kann kein bit so leicht 
umkippen wie bei (E)EPROM.

MFG Patrick

>Naja ich würd nen OTP µC nehmen oder PROM µC da kann kein bit
>so leicht umkippen wie bei (E)EPROM.

Ist es nicht mittlerweile so, dass die meisten OTP Controller nur 
EPROM-Typen ohne Fenster sind? Welcher Controller hat denn noch echte 
Fuses als Speicher?

Ich denke, dass mit der Strahlung alles ein Problem hat, was bei 
Fenstertypen durch UV löschbar ist. Da fallen EPROM und EEPROM auf jeden 
Fall darunter. Ich gehe auch davon aus, dass Flash ebenfalls nicht 
dagegen resistent ist, es beruht ja auch auf dem Prinzip, die Daten 
durch eingeschlossene Ladung zu speichern, ähnlich einem EEPROM.

Was ich mir als Alternative vorstellen könnte, ist (S)RAM mit 
Pufferbatterie. Das ist elektrisch statisch stabil, ein kleiner 
Ladungsverlust wird sofort durch einen entsprechenden Gegenstrom 
ausgeglichen. Ich glaube auch nicht, dass ein Elektronendurchschuss 
durch einen der Transistoren diesen so lange öffnen könnte, dass ein Bit 
kippt. Das Problem ist ja nicht gepulste, starke Strahlung, sondern die 
lange Zeit mit erhöhter Intensität.

Alphastrahlung lässt sich abschirmen und Beta- und Gammastrahlung muss 
er einfach aushalten.

Ich kann mir durchaus vorstellen, dass ein MSP430 dafür geeignet ist, 
wenn man auf den Flashspeicher verzichtet und das Programm aus dem Ram 
ausführt (die neuen haben auch genug RAM dafür). Dazu noch regelmäßige 
Fehlerkorrektur der Software, die auch automatisch aufgerufen wird, wenn 
der Controller abstürzt. Also alle nicht benötigten Interruptvektoren 
darauf setzen und den Watchdog verwenden, wobei ein Reset erst zur 
Fehlerkorrektur der Anwendersoftware führt, bevor diese gestartet wird.

Die edelste (und mit Abstand teuerste) Variante, die mir einfällt, ist 
sich bei TI maskenprogrammierte MSP430 Prozessoren zu bestellen. Da kann 
man natürlich nichts mehr dran ändern, wenn einem doch noch was 
auffällt. Ich glaube, die machen das schon ab 1000 Stück wirtschaftlich 
und für mehr Geld bestimmt auch schon für weniger Prozessoren. Man muss 
halt entscheiden, ob das Budget dafür ausreicht. Ich kann mir 
vorstellen, dass man schon für 5000€ was vernünftiges bekommt.

Viele Grüße,

Peter

Die TI MSP 430 gibts auch als OTP version
http://focus.ti.com/docs/prod/folders/print/msp430p325a.html

MFG Patrick

OK jetzt echt mal was Produktives !!!!!

Die meisten größeren Hersteller führen eine Reihe von Aerospace 
Produkten oder Military Sachen. Nach der Norm MIL-PRF-38535 QML Class V 
also setzt dich mit den Herstellern in Verbindung!!!!!!!

http://www.dscc.dla.mil/programs/qmlqpl/QPLdetail.asp?qpl=38535

Dann kann man an das Stroomproblem gehen!

Vielleicht bekommt ihr auch Unterstützung von denen so ein CubeSat ist 
sicher eine gute Werbung, denn in so einem CubeSat ist die Abschirmung 
vor Strahlung und Temparatureschwankungen schwerer zu lösen deswegen 
werden die Bauteile besser beansprucht.
2. Es gibt da mehr Presse bei dem Sart des Sats usw

MFG Patrick

http://learningmedia.ti.com/public/media/SLL/HiRel_Space/index.htm

das zeigt auch einiges bezüglich von Strahlung auf Halbleiter usw



Was ist wenn wir nen eigenen Mikrocontroller.netCubeSat entwickeln ich 
glaub das Know-How müsste dazu dasein. Nur es ist niemand da der das 
raufschießen bezahlt ^^

MFG Patrick

Es werden sich doch bestimmt n paar Maschinenbauer und so n Volk finden 
lassen, die parallel ne OpenSource Rakete bauen können... :)

Peter wrote:
> @Matthias Nix
>> Es werden sich doch bestimmt n paar Maschinenbauer und so n Volk finden
>> lassen, die parallel ne OpenSource Rakete bauen können... :)
> Aber die Rakete ist wohl das kleinste Problem, die Opensource
> Startrampe, controllzentrum und das Opensourcegeld fehlt leider noch.

Dann wirds halt n größeres Opensource Projekt. Beim OpenSource-Geld 
könnte man BWLer ja mal sinnvoll mit einbeziehen :)

>Die TI MSP 430 gibts auch als OTP version

OTP (MSP430P...) ist bei TI ein UV-löschbares EPROM, soweit ich das 
verstanden habe. Nur, dass man es nicht löschen kann, weil das Fenster 
dafür fehlt (mit Fenster heißt er dann MSP430E...). Ich glaube die 
maskenprogrammierte Version heißt bei TI "ROM".
Also die MSP430C...

Die neueren Flashtypen können außerdem einen sog. "Marginal Read Mode", 
dieser kann Bits im Flash erkennen, die kurz vor dem Umkippen sind. 
Darauf kann entsprechend mit einem Auffrischalgorithmus reagiert werden. 
Zusammen mit einer Prüfsumme ist das laut TI eine relativ sichere Sache. 
Erwähnt wird das in Bezug auf erhöhte Betriebstemperaturen, die das 
Flash innerhalb der Produktlebensdauer andernfalls löschen würden. 
Vielleicht funktioniert das auch für erhöhte Belastung mit 
Gammastrahlung. Voraussetzung ist, dass ein Gammaquant ein Bit nicht 
komplett kippt, sondern nur fast, so dass es vom Marginal Read für 
defekt erklärt wird, normal aber noch gelesen werden kann.

Wenn ich die Hardware von diesem Qubesat entwickeln müsste und vom 
Leistungsumfang ein MSP430 angemessen wäre, würde ich den gesamten Code 
im Ram halten und direkt von dort ausführen. Damit nichts verloren geht, 
gibts eine CR2032 Batterie als Puffer falls mal kein Licht für die 
Solarzellen da ist. Die neuen MSP430F5... habe 16kB Ram, das reicht um 
ein paar Bilder auf die Erde zu morsen (der letzte hat sie gemorst). 
Aber man kann ja auch noch externes Ram anschließen. Dann sollte 
regelmäßig eine Prüfsumme über den Code berechnet und ausgewertet 
werden. Das am besten  mit einem fehlerkorrigierenden Code, so dass 
gleich mehrere falsche Bits lokalisiert und korrigiert werden können 
(solche Codes gibt es ja schon; z.B. auf CDs). Das ganze macht man auf 
dem Flash auch nochmal, so dass ein wirklich nicht mehr korrigierbarer 
Zustand im Ram durch entsprechend redundant abgesicherten Code aus dem 
Flash rekonstruiert werden kann.

Ein Schwachpunkt wäre noch der erste Jump und die Interruptvektoren, das 
muss im Flash stehen. Hier ist aber gut bekannt, was dort stehen muss, 
deswegen ist eine Überprüfung und Korrektur einfach.

So könnte man das Teil dann wahrscheinlich für 10 Jahre in die 
Umlaufbahn schicken. Der letzte ist ja glaub ich (korrigiert mich, wenns 
nicht stimmt) wegen einer defekten Stromversorgung ausgefallen.

>Was ist wenn wir nen eigenen Mikrocontroller.netCubeSat entwickeln ich
>glaub das Know-How müsste dazu da sein

Angeblich dürfen auch Firmen an dem Projekt teilnehmen und eine 
Cubesatstart kaufen. Mich würde mal interessieren, was das kostet.

Grüße,

Peter

Testpiloten kenn ich ein paar bessere Kandidaten!

BWLer sind wenn man so ein großes Projekt durchziehen will auch wichtig. 
Genauso wie ein Jurist wär auch ned schlecht. Irgendjemand muss sich ja 
auch um Genehmigungen oder das Geld vorm Staat verstecken kümmern.

Oder das Zeitliche managment usw .

Aber das größte Problem ist wohl das Teil in das All bringen. Aber so 
ein "Openprojekt" könnte man wirklich mal versuchen aber sicherlich 
nicht der Weltraum als Ziel.

MFG Patrick

> Aber man kann ja auch noch externes Ram anschließen.

Kein MSP430 hat ein externes Speicherinterface, daher kann kein Code aus 
externem RAM ausgeführt werden.
Sicher, mit Port-IO kann alles angesteuert werden, aber zur 
Codeausführung muss dieser ins interne RAM kopiert werden.

Du Guido da hast recht, aber das Teil wird von Technikern entwickelt und 
nicht von Menschenrechts Fanatiker. Aus diesem Grund werden wegen 
Gewichtseinsparungen die Sauerstoffflasche, Sicherheitsgurte, 
Manuellekontrollen wegratoinalisiert. Der Rettungsfallschirm is nur für 
die Datenkerne des Satellitens.

Was eigentlich nochmal Strahlemschutz ?


Das Problem liegt ned im Speicher OTP oder Hardrad externerspeicher für 
das Programm. Aber das Problem sind die Register zB wenn immer wieder 
durch Elektronenbeschuss der Wert des Watchdogtimers verändert wird 
sieht das blöd aus für das ganze Programm oder gar Projekt. Das 
wichtigste ist den MSP430 so gut wie möglich abzuschirmen oder einen 
Hardrad zertifizierten µC zu finden!

Es nutzt nämmlich nichts wenn alles auf niedrigen Energieverbrauch 
getrimmt ist und alle 10 ms sind die Date in den Registern so Fehlerhaft 
das die Berechnug abgebrochen werden muss!!!

Es gibt jetzt 2 Möglichkeiten:
1. anderer µC mit Radhard zertifizierungen (also grobere Struktur und 
daher höhere Verlustleistung)

2. Wäre eine Abschirmung die aber wieder Gewicht kostet aber dafür kann 
man mit geringem Energie Verbrauch auf Trumpfen

MFG Patrick

Wer noch nicht nen Tag wegen einem kleinen Problem verschießen hat der 
ist ned wirklich Programmierer.

Geduld, Datenblatt und ein Debuger und das wird schon werden.

MFG Patrick

Was ist jetzt mit dem Herren "Weltraum-Ingeneurs-Anwärter" ?
Ein kurzes Feedback kann er wohl ned geben ?
Es kann ja sein dass jemand mal mit solchen Rahmenbediengungen wie der 
Weltraum hat arbeiten muss und dann auf diesen Beitrag zurückgreifen 
kann.

Außerdem mich würde, der µC der verwendet wird auch interessieren.

MFG Patrick

Scherbo wrote:
> Nimm doch den COSMAC 1801, war der erste uC im Weltraum ...
> hab noch nen ganze Palette von den Mistdingern im Schrank :p

Hallo Scherbo, kannst du davonn eventuell ein paar Stück an mich 
abtreten?

Gruß, Iwan

Ich bin bei der Strahlung generell skeptisch, dass ein Programm in einem 
Speicher wie SRAM oder Flash längere Zeit ohne Fehlerkorrektur lauffähig 
ist.
Jedenfalls ist
http://www.actel.com/documents/RTAXS_DS.pdf
ein Rad-Hardened FPGA und dort wird eine Wahrscheinlichkeit von 10^-10 
pro Bit pro Tag in einem Geosynchronem Orbit angegeben, dass das Bit 
kippt. Bei einigen MB Speicher ist die Wahrscheinlichkeit für Bitfehler 
nicht zu vernachlässigen. Das ist natürlich nur begrenzt mit den oben 
genannten Bedigungen vergleichbar. Einerseits dürft in einem niedrigem 
Orbit deutlich weniger Strahlung unterwegs sein, andererseits verwendet 
der genannte FPGA bereits Korrekturmechanismen

> While each SEU-hardened R-cell appears as a single
> D-Type flip-flop to the user, each is implemented in
> silicon using triple redundancy to achieve a LET threshold
> of greater than 60 MeV-mg/cm2. Each TMR R-cell consist
> of three master-slave latch pairs, each with asynchronous
> self-correcting feedback paths. The output of each latch
> on the master or slave side votes with the outputs of the
> other two latches on that side. If one of the three latches
> is struck by an ion and starts to change state, the voting
> with the other two latches prevents that change from
> feeding back and permanently latching. Care was also
> taken in the layout to ensure that a single ion strike
> could not affect more than one latch

Und trotzdem kommen eben noch Fehler vor.

Nebenbei, aber auch die Mars Rover verwenden Flash Speicher.

Johnny

Schau mal wie wir uns bei unseren ersten Projekten angestellt haben. Der 
Weltraum ist auch nicht unbedingt alltag. Man soll nicht immer so 
Leichtfertig reden.


Gast
1. Wie schon von wem hier gesagt wenn man eine gute software hat mit 
Fehlerkorrektur im programmcode usw ist das mit non rad-hard sachen 
sicher auch kein problem. Also alles ist möglich !!!

MFG Patrick

Statt des MSP430F169 könnte einfach ein neuerer MSP430 wie z.B. der 
pinkompatible MSP430F2618 verwendet werden, der eine geringere 
Stromaufnahme hat und obendrein ein besseres Powermanagement durch 
erweiterte Takterzeugungsmöglichkeiten bietet.

> Naja ich würd nen OTP µC nehmen oder PROM µC da kann kein bit so leicht
> umkippen wie bei (E)EPROM.

Sorry, das ist nicht richtig. Kann ich einfach nicht stehenlassen.

OTP heisst "one time programmable", dahinter kann alles stecken. Das ist 
keine Speichertechnologie.

Wenn Du e-Fuses, Holraumfuses, Polyfuses oder ähnlich gemeint hast, 
können die in Punkto Zuverlässigkeit nicht mithalten. Daher stecken sie 
auch in einer XBOX360 und PS3, aber nicht in einem Auto. (Grund: 
"wachsen" gerne zusammen oder lassen sich nicht ordentlich programmieren 
- vor allem sind sie nicht testbar und damit in qualitativ 
anspruchsvollen Projekten ein Problem). Aus dem Grund kann man wie 
eingefleischte Gamer wissen die eFuseschaltung in der XBOX360 zum 
späteren Downgraden lahmlegen, da IBM und Microsoft aus 
Zuverlässigkeitsgründen nicht darauf vertrauen können - sie bekämen noch 
mehr Retouren von "ordenlichen Kunden" als bisher :-)

Wenn Du Mask-Programmable gemeint hast, ist das keine Technologie für 5 
Samples in so einem Projekt. Erlaubt kein Bugfixing u.s.w. und wurde 
früher ausschließlich aus Kostengründen eingesetzt. In vielen Bereichen, 
auch Automotive, zu 99% verboten. Gibt es auch kaum mehr, ausser in 
Chinesischem Spielzeug. Das ist übrigends auch kein OTP... :-)

Wenn Du Laserfusing gemeint hast, ist dies gängig für Kalibrierung von 
ICs aber nicht für größere Speichermengen. Wird oft verwendet, hat aber 
auch Probleme, da man dafür das Die an gewissen Stellen ja "beschädigt" 
(Löcher z.B. in der Silizid-Schicht) was u.U. Zuverlässigkeitsprobleme 
bringen kann (ESD, Feuchtigkeit, Chem. Reaktion beim Molden, ...). 
Dennoch, hat man gut im Griff und wird durchaus verwendet.

Es gibt magnetische Speicher, die mittlerweilen auch integriert wurden 
(MRAM) sich nicht durchgesetzt haben und auch vermutlich nicht werden - 
zu teuer. Magnetische Speicherprinzipien waren früher auch in der 
Avionik/Raumfahrt in Verwendung, wenn auch etwas größer... :-)

Letzendlich entscheidet die Zuverlässigkeit die Speichermenge und 
Umweltanforderungen (Temperaturprofil, Störstrahlung, ESD,...). 
Unabhängig von der Speichertechnologie kann man mit Redundanz (FEC, ...) 
problemlos mathematisch nachweisen, dass das Kippen eines Speichers 
genauso wahrscheinlich wird, wie das Ausfallen der Logik dahinter. 
Moderne Flash in Automotive-Produkten bieten üblicherweise diese 
Zuverlässigkeit und - das wichtigste - ein Flashspeicher ist schon ab 
dem Halbleiterhersteller testbar (auch z.B. in einem Burn-In, was man 
für viele hohe Qualitätsstandards zum Nachweis der Zuverlässigkeit 
braucht!!!) Bei einem "OTP" generell muss das der "Endkunde" machen, 
hier ist es auch sehr teuer, wenn der Speicher kaputt war und man 
deshalb das ganze Modul wegschmeissen kann...

Zum Flash/EEPROM: der technische Hauptunterschied ist übrigends in 
erster Linie nur, dass Flashzellen in gemeinsamen Wannen liegen und 
daher nur Blockweise gelöscht (z.B. 128byte) und bitweise gesetzt werden 
können, hingegen "echte" EEPROM Zellen einzeln bit/byteweise in beiden 
Richtungen setzen/löschen beschrieben werden. Damit eignen sie sich u.a. 
besser für Datalogging, Fehlerspeicher,... wenn öfters byteweise 
geschrieben werden muss (beim Flash stresst man ja nicht nur das eine 
Byte, sondern immer den ganzen Block). Es werden in vielen µC im 
Consumer/Industriebereich mit dem Flash das EEPROM gerne nur emuliert 
(durch dahinter liegendem RAM), da aufgrund des Aufbaus "echte" EEPROMs 
viel weniger Speicherdichte haben.

Sehr erbaulicher Thread hier ;-)

Den MSP430 wird man strommäßig nicht weit überholen können. Der Aufwand 
etwas besseres zu suchen, sollte sich auf den zu erwartenden 
Leistungsverbrauch durch die geschriebene Software konzentrieren.

Eigentlich ist das Thema relativ gegessen. Ansprechpartner für 
erfolgreich durchgeführte Projekte wäre das Team um Karl Meinzer in 
Marburg. Die geben sicherlich gerne Tipps.


Gruß -
Abdul