Flash Speicher beim Booten/Flashen füllen

[soundmachine123 (Gast)]

Hallo Zusammen,

ich arbeite momentan mit einem STM Cortex M3 C8T6. An diesen habe ich 
einen seriellen Flash Speicher über SPI 1 angebunden. An SPI 2 hängt ein 
FT800 Touch Display. Das Display funktioniert soweit nah meinen 
Vorstellungen. Nun zum Problem. Auf dem Display sollen diverse Bilder 
und Symbole nacheinander angezeigt werden. Da die Speichergröße der 
Bilder die Speichergröße des M3 bei weitem übersteigt möchte ich diese 
gerne im Flash Speicher ablegen.

Nur, wie kommen die Daten dahin.
Momentan habe ich das so realisiert, dass man ein Programm auf den 
Cortex flashed, was Daten aus der USB Schnittstelle empfängt und im 
Flash ablegt. Das heißt aber in der Praxis:
- M3 Flashen
- Visual Studio aufmachen. Bilddaten übertragen
- M3 mit Anwendersoftware flashen

was alles in allem Zeitazfwändig und umständlich, gerade im Bezug auf 
die Serie (ca. 100 im Jahr) ist.

Gäbe es nicht eine Möglichkeit schon beim flashen der Anwendersoftware 
die Daten "durch den Prozessor" in das Flash zu schieben?

Bzgl. Bootloader etc kenne ich mich leider überhaupt nicht aus. 
Programmiert wird mit EMBiz.


Für jede Anregung/´jeden Gedankenanstoß bin ich äußerst Dankbar.

[Jim M. (turboj)]

soundmachine123 schrieb:
> be es nicht eine Möglichkeit schon beim flashen der Anwendersoftware
> die Daten "durch den Prozessor" in das Flash zu schieben?

Kommt auf Deine Umgebung an. Mit dem in OpenOCD integriertem TCL 
Skripting könnte man sowas machen - aber Dich erwartet da einiges an 
Einarbeitungs- und Entwicklungszeit.

GDB kennt auch Scripting. Damit könnte man auch an den Pins wackeln.

Bei Größen im MB Bereich würde ich allerdings eine kleine Funktion in 
den RAM packen, die jeweils einen Bereich mit Daten ebenfalls aus dem 
RAM flasht. Der µC kann nämlich von selbst sehr viel schneller an den 
Beinchen wackeln als man das via JTAG kann.

[Sascha W. (sascha-w)]

Hallo,

was spricht dagegen die Funktion zum Upload der Bilddaten mit in der 
Anwendungssoftware unterzubringen?

Sascha

[A. B. (Gast)]

Genau das, die Daten "durch den Prozessor in das Flash schieben" machen 
die Flash-Treiber lpcspifi, stmsmi, stmqspi, ... in OpenOCD. Die sind 
zwar für den Fall gedacht, dass der Prozessor ein speziell auf externen 
Flash ausgelegtes SPI-Interface hat, aber mit einem "normalen" 
SPI-Interface ginge es ganz analog. Nach Initialisierung werden in 
diesen Treibern auch nur die Daten 1:1, wie sie zum Flash gehen sollen, 
in die Datenregister gepumpt. Lästig wäre aber, dass es beim "normalen" 
SPI so viele Freiheitsgrade gibt ...

Funktionsweise: ein kurzes (Assembler-) Programm wird via JTAG/SWD ins 
RAM geschrieben und gestartet, die Daten werden dann simultan (d. h. 
während die Programmierung des externen Flash im Controller läuft) über 
das JTAG/SWD-Interface in ein (Software-) FIFO im RAM nachgeschoben, die 
Synchronisation vom Controller und Host erfolgt über die 
FIFO-Schreib-/Lesezeiger.

Ein wesentlicher Unterschied wäre dann aber der Adressraum: Die obigen 
"speziellen" SPI-Interfaces besitzen einen "Memory-Mapped"-Modus, wo der 
externe Flash (für Lese-Zugriffe!) in den normalen Adressraum des 
Prozessors eingeblendet wird und so quasi als ganz normaler interner 
Speicher erscheint. Fürs Programmieren ist das natürlich egal, man 
müsste jedoch einen Adressbereich für das externe Flash frei halten, der 
auch im Linker-File definiert wird. Damit könnten Code fürs interne und 
Daten fürs externe Flash aus einer einzigen Binär-Datei in einem Rutsch 
programmiert werden, die separate Behandlung von internem/externem Flash 
liefe dann in OpenOCD vollautomatisch ab.

Mit 'nem STM32F746-Disco, F769, oder F723 mal ausprobieren ...

[Rudolph R. (rudolph)]

Einfach einen dickeren Controller benutzen?
C8T6 ist 48 Pins mit 64kb FLASH, richtig?
Es gibt zumindest laut Liste bei ST 48 Pinner mit 256kb FLASH.

Geschicktere Kompression der Bilder könnte auch helfen, für Symbole 
bieten sich die Graustufen Formate an die mit dem Image_Convert_Tool von 
FTDI gepackt werden können.
Dabei ist zu beachten, dass der Converter ab V0.9 blöderweise per 
Default Dithering an hat, was die gepackte Größe genenüber dem was aus 
der V0.7 raus kam mal eben verdoppelt.
Seit der V0.9.1 kann man das Dithering wenigstens abschalten.

[A. B. (Gast)]

Ist zwar einmal etwas aufwendig zu konfigurieren, aber dann tut's 
hoffentlich genau das:

http://openocd.zylin.com/#/c/4152/