MSP430 Code auf externen Flash auslagern?

[Jochen (Gast)]

Hallo,

ich verwende einen MSP430F168 und wollte fragen ob es möglich ist den 
Quellcode auf eine externen SPI Flash (z.B. SST25VF080B) zu speichern 
und zu nutzen? Das man so größeren Quellcode schreiben kann.

[Helmut L. (helmi1)]

Jochen schrieb:
> ich verwende einen MSP430F168 und wollte fragen ob es möglich ist den
> Quellcode auf eine externen SPI Flash (z.B. SST25VF080B) zu speichern
> und zu nutzen? Das man so größeren Quellcode schreiben kann.

Warum nimmst du nicht einen groesseren MSP430?

Kann man zwar machen muesste aber den Code erst ins RAM laden und dort 
ausfuehren. Dazu muesste dein Compiler aber Codebanking beherschen. Also 
verschiedene Programmteile an die gleiche Addresse linken koennen und 
das nachladen selber anstossen koennen.

[(prx) A. K. (prx)]

Gibts heute noch Entwicklungsumgebungen, die Code Overlays unterstützen? 
Inspiriert die grosse Ähnlichkeit des MSP430 mit der PDP-11? Da war das 
recht verbreitet - aber das war vor 3-4 Jahrzehnten und kaum jemand 
weint dem eine Träne nach.

Das Zeug adressmässig übereinander zu legen und nebeneinander ins Image 
zu schreiben sollte beim GNU-Linker allerdings problemlos möglich sein.

[Helmut L. (helmi1)]

A. K. schrieb:
> Gibts heute noch Entwicklungsumgebungen, die Code Overlays unterstützen?

Das letzte wo ich das mal gemacht habe war beim 68HC11 unter der COSMIC 
Entwicklungsumgebung ist aber auch schon fast 15 Jahre her.

A. K. schrieb:
> Das Zeug adressmässig übereinander zu legen und nebeneinander ins Image
> zu schreiben sollte beim GNU-Linker allerdings problemlos möglich sein.

Ist aber auch nur die halbe Miete. Der Compiler sollte einem aber auch 
Code dafuer erzeugen um das an Ort + Stelle laden zu koennen und 
auszufuehren.

[Reinhard Kern (Gast)]

A. K. schrieb:
> Das Zeug adressmässig übereinander zu legen und nebeneinander ins Image
> zu schreiben sollte beim GNU-Linker allerdings problemlos möglich sein.

Das kann man auch jedem Linker beibringen, der nicht dafür vorgesehen 
ist, das erfordert aber einiges Knowhow. Fazit: geht aber lohnt sich 
nicht, wenn man für ein paar Cent mehr genügend Flash haben kann. Den 
SPI-Chip muss man ja auch bezahlen.

Gruss Reinhard

[easy (Gast)]

Jochen schrieb:
> Hallo,
>
> ich verwende einen MSP430F168 und wollte fragen ob es möglich ist den
> Quellcode auf eine externen SPI Flash (z.B. SST25VF080B) zu speichern
> und zu nutzen? Das man so größeren Quellcode schreiben kann.

Der MSP430 kann Code aus dem RAM laufen lassen. Du kannst selber Code 
aus externen Speichern ins RAM kopieren und per Funktions-Pointer 
ausführen. Du musst nur selber aufpassen, dass der richtige Code vor dem 
Aufruf vorhanden ist.

[Rufus Τ. F. (rufus)]

easy schrieb:
> Der MSP430 kann Code aus dem RAM laufen lassen.

Allerdings gibt es keinen einzigen MSP430, bei dem sich das RAM 
erweitern ließe, und der schon sehr angestaubte 'F168 hat gerade mal 
2048 Bytes RAM. Damit lässt sich nicht viel anstellen.

Es gibt eigentlich keinen Grund mehr, noch so ein altes Schätzchen zu 
verwenden; das kann nur 4-Draht-JTAG (und ist deswegen nicht mit dem 
Launchpad programmierbar, sondern benötigt den teureren MSP-FET430UIF 
oder den Parallelportfrickler) und ist obendrein unverhältnismäßig 
teuer.

Neuere MSP430-Varianten haben modernere Peripherie, benötigen weniger 
Strom, haben teilweise deutlich mehr Flash-ROM (der 'F5438 
beispielsweise hat 256 kB), deutlich mehr RAM, können mit höheren 
Taktfrequenzen betrieben werden und kosten weniger.

[Hinweiser (Gast)]

Hallo Rufus,

sollen wir ihm den Trick verraten, dass er seinen Code aus dem SPI 
scheibchenweise ins Flash spielen kann?

Dazu müßte er sich ein Flash oder Boot-Programm in den RAM-Bereich 
laden.

Wenn er das implementiert, nach Sinn und Unsinn sei nicht gefragt, hat 
er am Ende eine Menge gelernt.

Gruß

Bernd

[Rufus Τ. F. (rufus)]

Hinweiser schrieb:
> sollen wir ihm den Trick verraten, dass er seinen Code aus dem SPI
> scheibchenweise ins Flash spielen kann?

Das kann man zwar machen, aber ob das sinnvoll ist? Das Flash hält 
schließlich nur eine begrenzte Anzahl an Schreibzyklen aus, und wenn zum 
Abarbeiten des zu großen Programmes ständig Teile des Flash neu 
programmiert werden müssen, ist der Controller bald ein Fall für die 
Tonne.

Da aber Jochen sich nicht wieder gemeldet hat, vermute ich, daß das 
Thema ihm nicht so wichtig gewesen sein wird.

[Helmut L. (helmi1)]

Rufus Τ. Firefly schrieb:
> Das kann man zwar machen, aber ob das sinnvoll ist? Das Flash hält
> schließlich nur eine begrenzte Anzahl an Schreibzyklen aus, und wenn zum
> Abarbeiten des zu großen Programmes ständig Teile des Flash neu
> programmiert werden müssen, ist der Controller bald ein Fall für die
> Tonne.

Oder man nimmt einen der neuen MSP430 mit FRAM drin.

[Rufus Τ. F. (rufus)]

Das ist in der Tat eine Möglichkeit, gibt es die mit bis zu 64 kiB 
FRAM.

Allerdings bezweifle ich, daß das überhaupt nötig ist, für das, was der 
schweigende Threadstarter machen will. Tatsächlich wollte er ja den 
Quellcode auf dem Controller speichern ...

[Max G. (l0wside)]

Hinweiser schrieb:
> Hallo Rufus,
>
> sollen wir ihm den Trick verraten, dass er seinen Code aus dem SPI
> scheibchenweise ins Flash spielen kann?
>
> Dazu müßte er sich ein Flash oder Boot-Programm in den RAM-Bereich
> laden.

Wer das auf dem MSP430 funktionierend hinbekommen hat, möge bitte 
Bescheid geben. An dem Thema verzweifle ich seit zwei Wochen.
Der ins RAM kopierte Code macht einfach nur Blödsinn, so bald er ins 
Flash schreiben soll. Aus dem Flash heraus läuft er 1a. Sprünge sind 
alle relativ, ich überschreibe mir auch nicht den Stack. Aber sobald die 
1:1-Kopie im RAM steht und angesprungen wird, passieren wunderliche 
Dinge :-(

Max

[Jochen (Gast)]

Erstmal danke für die antworten war über die Woche nicht Zuhause.

Also den Prozessor kann ich nicht tauschen, weil das nicht gewünscht 
ist. Daher versuche ich gerade das über SPI auszulagern auf dem Flash. 
Auslagern will ich einige Funktionen weil der Flashspeicher auf dem 
MSP430F168 dafür nicht ausreicht. Das Problem dabei ist habe da garkeine 
Erfahrungen wie man sowas macht.

[Rufus Τ. F. (rufus)]

Jochen schrieb:
> Also den Prozessor kann ich nicht tauschen, weil das nicht gewünscht
> ist.

Aha. Und den Code zu optimieren, oder dem "Wünschenden" mitteilen, daß 
das Festhalten an unterdimensionierten Museumsstücken halt irgendwann 
harte Grenzen setzt, das geht nicht?

Vergiss das mit dem Codeauslagern. Mit den gerade mal 2 kiB RAM könntest 
Du eh nur winzige Schnipsel aus externem Speicher laden; und Teile des 
Flashs willst Du nicht umprogrammieren, weil dann Dein 'F169 ziemlich 
bald stirbt.

Mit was für einem Compiler arbeitest Du, was machst Du in Deinem 
Programm, und was möchstest Du noch an zusätzlichen Dingen anstellen?

Oft lässt sich durch Optimierung oder Umstrukturierung einiges an 
Codegröße einsparen -- solltest Du floating-Point-Arithmetik nutzen, ist 
die Frage ganz laut zu stellen, ob das wirklich nötig ist, solltest Du 
printf und Konsorten nutzen, ist auch hier die Frage zu stellen, ob 
das wirklich nötig ist.

Zu guter Letzt: Womit bestimmst Du die Codegröße? Siehst Du Dir nur die 
Dateigröße einer Hex-Datei an, oder wertest Du die tatsächliche 
Codegröße aus, die Dir der Linker verraten sollte?

[Jochen (Gast)]

Rufus Τ. Firefly schrieb:

> Mit was für einem Compiler arbeitest Du, was machst Du in Deinem
> Programm, und was möchstest Du noch an zusätzlichen Dingen anstellen?

Ich nutze das Code Composer Studio 5.
Was auf ein Display darstellen mit Berechnung und ich würde gerne die 
Schriftzeichen bzw. die Fonts auslagern.

> Oft lässt sich durch Optimierung oder Umstrukturierung einiges an
> Codegröße einsparen -- solltest Du floating-Point-Arithmetik nutzen, ist
> die Frage ganz laut zu stellen, ob das wirklich nötig ist, solltest Du
> printf und Konsorten nutzen, ist auch hier die Frage zu stellen, ob
> das wirklich nötig ist.

Habe schon den Code soweit optimiert und einiges gewonnen. Nutze 
floating-Point-Arithmetik Extra nicht, weil da ja nochmehr verloren 
geht.

> Zu guter Letzt: Womit bestimmst Du die Codegröße? Siehst Du Dir nur die
> Dateigröße einer Hex-Datei an, oder wertest Du die tatsächliche
> Codegröße aus, die Dir der Linker verraten sollte?

Die benötigte größe wird mir angezeigt und dazu auch der Adressbereich 
und der ist so bei 0xDF93.

[Rufus Τ. F. (rufus)]

Jochen schrieb:
> Was auf ein Display darstellen mit Berechnung und ich würde gerne die
> Schriftzeichen bzw. die Fonts auslagern.

Ah. Die sind kein Code, und die kannst Du natürlich jederzeit aus einem 
externen Flash-ROM laden. Wie auch beliebige andere Daten, also z.B. 
irgendwelche Menütexte oder irgendwelche Umrechnungstabellen o.ä.

Nur Programmcode ist zum Auslagern ungeeignet, weil er vor der 
Ausführung ausführbar ins RAM (bzw. interne Flash-ROM) geladen werden 
muss.

Bei einem Font sieht das natürlich anders aus; Du wirst eine Routine 
haben, die das Bitmuster für ein darzustellendes Zeichen aus dem ROM 
holt - und diese Routine musst Du halt entsprechend anpassen, so daß das 
Bitmuster eben aus per SPI oder I2C oder wie auch immer extern 
angebundenem ROM geholt wird. Das ganze wird dann natürlich langsamer, 
weil das, was mit einem einzigen Speicherzugriff möglich war (lese ein 
bzw. zwei aufeinanderfolgende Bytes) jetzt einiges an 
Peripheriezugriffen erfordert.

[Jochen (Gast)]

Also sowas wie:

const char character_a[]={0x1F,0x00,0x3F,0xB0,0x31,0xB0,0x31,0xB0,0x3F,0xF0,0x3F,0xE0};

kann man also auf dem Flash speichern? Das habe ich denn richtig 
verstanden?

[Eumel (Gast)]

Jochen schrieb:
> kann man also auf dem Flash speichern? Das habe ich denn richtig
> verstanden?

So ist es.

[Rufus Τ. F. (rufus)]

Jochen schrieb:
> Das habe ich denn richtig verstanden?

Ja. Nur erfolgt der Zugriff dann natürlich nicht mehr mit einem 
einfachen Array-Zugriff à la

c = character_a[24];

sondern durch Aufruf einer von Dir zu schreibenden Zugriffsfunktion auf 
das externe Flash-ROM. Das wird dann irgendwie so aussehen:

uint8_t spi_rom_read(uint16_t addr);

c = spi_rom_read(24);

Was die Funktion genau machen muss, hängt vom verwendeten SPI-ROM ab. 
Nimmt man beispielsweise ein 25LC512*, so sind für jeden Lesezugriff 
vier SPI-Zugriffe durchzuführen, bei dreien davon werden Daten an das 
SPI-ROM übertragen, ein Befehlsbyte und zwei Bytes mit der Adresse. Der 
vierte Zugriff liefert dann die Nutzdaten.

Damit sähe Deine Funktion in etwa so aus:

uint8_t spi_rom_read(uint16_t addr)
{
  uint8_t wert;

  spi_set_cs();

  spi_write_byte(READ);
  spi_write_byte(addr >> 8);
  spi_write_byte(addr & 0xFF);

  wert = spi_read_byte();

  spi_clear_cs();
  return wert;
}

Das ist natürlich deutlich langsamer als ein einfacher Arrayzugriff.


*) http://www.microchip.com/wwwproducts/Devices.aspx?dDocName=en530925

[Jochen (Gast)]

Rufus Τ. Firefly schrieb:
> Damit sähe Deine Funktion in etwa so aus:
>
> uint8_t spi_rom_read(uint16_t addr)
> {
>   uint8_t wert;
>
>   spi_set_cs();
>
>   spi_write_byte(READ);
>   spi_write_byte(addr >> 8);
>   spi_write_byte(addr & 0xFF);
>
>   wert = spi_read_byte();
>
>   spi_clear_cs();
>   return wert;
> }
>
> Das ist natürlich deutlich langsamer als ein einfacher Arrayzugriff.

Okay das macht soweit Sinn, aber was ich noch nicht verstehe wie ich 
diesen Wert

character_a[]={0x1F,0x00,0x3F,0xB0,0x31,0xB0,0x31,0xB0,0x3F,0xF0,0x3F,0xE0};

 auf den Flash übertrage. Daran scheitert es gerade bei mir.

[Helmut L. (helmi1)]

Jochen schrieb:
> character_a[]={0x1F,0x00,0x3F,0xB0,0x31,0xB0,0x31,0xB0,0x3F,0xF0,0x3F,0x E0};
>  auf den Flash übertrage. Daran scheitert es gerade bei mir.

Dazu brauchst du die umgekehrte Funktion:

void spi_rom_write(uint16_t addr,uint8_t val)

Und dann schreibst du dir eine funktion wo du von aussen via RS232 etc. 
das aufrufen kannst. Dann einmal bei der Produktion die Daten in Flash 
uebertragen.

[Jochen (Gast)]

Helmut Lenzen schrieb:
> Dazu brauchst du die umgekehrte Funktion:
>
> void spi_rom_write(uint16_t addr,uint8_t val)
>
> Und dann schreibst du dir eine funktion wo du von aussen via RS232 etc.
> das aufrufen kannst. Dann einmal bei der Produktion die Daten in Flash
> uebertragen.

Achso also am besten zweites Programm schreiben, wo man nur den Flash 
beschreibt. Okay ich danke euch erstmal bei weiteren Frage melde ich 
mich :)

[Matze (Gast)]

Hallo habe so ähnliches Problem. Was ich bei nicht verstehe beim 
beschreiben des Flashes
Helmut Lenzen schrieb:
> Jochen schrieb:
>> character_a[]={0x1F,0x00,0x3F,0xB0,0x31,0xB0,0x31,0xB0,0x3F,0xF0,0x3F,0x E0};
>
> Dazu brauchst du die umgekehrte Funktion:
>
> void spi_rom_write(uint16_t addr,uint8_t val)
kann man z.B. die Variable von Jochen 1 zu 1 so übertragen oder wie 
genau macht man das? Kann da mal einer bitte einen Sample code posten 
mit dieser Variable?

[Rufus Τ. F. (rufus)]

Matze schrieb:
> kann man z.B. die Variable von Jochen 1 zu 1 so übertragen

Klar:

for (i = 0; i < sizeof (character_a); i++)
  spi_rom_write(basisadresse + i, character_a[i]);

Basisadresse, falls das ROM nicht beginnend bei seiner Anfangsadresse 0 
gefüllt werden soll.

[Matze (Gast)]

Rufus Τ. Firefly schrieb:
>> Matze schrieb:
>> kann man z.B. die Variable von Jochen 1 zu 1 so übertragen
>
> Klar:
> for (i = 0; i < sizeof (character_a); i++)
>   spi_rom_write(basisadresse + i, character_a[i]);
>
> Basisadresse, falls das ROM nicht beginnend bei seiner Anfangsadresse 0
> gefüllt werden soll.

Danke schön dafür genau sowas habe ich gesucht.

[Christian R. (supachris)]

Beim Schreiben natürlich das Löschen und evtl. Sichern des Sektors nicht 
vergessen. Ein bisschen mehr als der Pseudocode ist das schon, 
jedenfalls beim Schreiben.

[Tüddel (Gast)]

Hab übrigens auch schon "Program-Code" Extern von einem MSP430 
ausgelagert :-P

Hab mir dazu im Flash des MSP430 die HAL (Hardware Abstraction), einen 
Interpreter und eine rudimentäre "EVA" (Eingabe-Verarbeitung-Ausgabe) 
gestopft und alle möglichen platzfressenden Sachen in eine 
"Zwischensprache" gebracht und dann auf den ext. Flash gespeichert.

Der MSP430 hat dann einfach das Program im externen Speicher durch 
seinen Interpreter gejagt und schon hatte man größeren Speicher ;)

Das war sehr viel Softwareaufwand und auch bei weitem nicht mehr 
schnell, ging aber!

Bevor die Rückfrage kommt: Nein, ich gebe den Code nicht "Frei" - es 
steckt einfach zu viel arbeit da drinnen... Ich wollte halt nur 
berichten, das es auch geht ;)

[Rufus Τ. F. (rufus)]

Nun gut, der Interpreteransatz ist natürlich auch noch möglich.

Hier z.B. ein Basic-Interpreter:

http://www.rowley.co.uk/msp430/basic.htm

Möglicherweise lässt sich auch Lua bzw. eLua auf den MSP430 portieren.

Und für Freunde der UPN gibt es auch das hier:
http://www.camelforth.com/page.php?8