Forum: Mikrocontroller und Digitale Elektronik Flash Speicher beim Booten/Flashen füllen


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von soundmachine123 (Gast)


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

von Jim M. (turboj)


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

von Sascha W. (sascha-w)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,

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

Sascha

von A. B. (Gast)


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

von Rudolph R. (rudolph)


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

von A. B. (Gast)


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

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

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]
  • [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.