Kann der Programm-Flash-Speicher des Mikrocontrollers zum Speichern der Benutzerkonfiguration verwendet werden?

Viele Mikrocontroller, zB PIC18F , haben Flash-Programmspeicher: "Der Flash-Programmspeicher ist während des normalen Betriebs lesbar und beschreibbar". Bedeutet dies, dass ich einige Benutzerkonfigurationen im Programmspeicher speichern kann?

Antworten (2)

Ja, du kannst. Ich habe dies viele Male getan.

Es gibt jedoch einige Nachteile in Bezug auf die Verwendung eines separaten EEPROM:

  1. Die Anzahl lebenslanger Schreibvorgänge in Programm-Flash-Speicher ist deutlich geringer als in Daten-EEPROM.

  2. Der Prozessor geht während der Lösch- und Schreibzeiten zum Mittagessen aus.

  3. Programm-Flash wird blockweise gelöscht. Sie können nicht nur ein einzelnes Byte aktualisieren. Ich verwende normalerweise ein Block-Caching-Schema, um damit umzugehen.

Perfekt, Sie scheinen irgendwie zu wissen, dass meine Frage wirklich lautet: "Warum ein EEPROM benötigt wird, während Sie den Programmspeicher sowohl für Programm- als auch für Benutzerdaten verwenden können" :)
Olin, wird der gesamte Flash gelöscht, wenn eine neue Firmware-Version in den PIC gebrannt wird? Gibt es eine gute Möglichkeit zu verhindern, dass die Benutzerkonfiguration (oder Kalibrierungsdaten) im Flash während des Firmware-Downloads gelöscht werden? Hier geht es um Komfort bei der Firmware-Entwicklung. Ich könnte mir vorstellen, dass die Benutzerkonfiguration im allerletzten Block oder Flash gespeichert wird.
@Nick: Das hängt vom verwendeten PIC-Programmierer ab. Viele, darunter alle von mir, führen eine Massenlöschung durch, sodass die Kalibrierungsdaten gelöscht würden. Ich habe bei einigen Gelegenheiten eine spezielle Programmier-App geschrieben, die die Kalibrierungsdaten las, die Massenlöschung durchführte und dann die Kalibrierungsdaten als Teil des normalen Programmiervorgangs zurückschrieb. Einige Programmierer von Microchip können möglicherweise nur Teile des Programmspeichers aktualisieren. Beachten Sie, dass der Programmierer eine Massenlöschung durchführen muss, wenn Sie den Codeschutz aktiviert haben.
Auf Nicht-Harvard-Prozessoren (ich denke an MSP430) können Sie Code in den RAM kopieren und in den RAM springen und ausführen, während das Flash-Schreiben / -Löschen stattfindet. Ich habe dies für einen Bootloader verwendet, um gleichzeitig neue Daten von einem Radio zu schreiben und zu empfangen.
@mark: Ja, das funktioniert auch auf PIC32, wo es auch möglich ist, aus dem RAM auszuführen. Tatsächlich geht das schneller.

Viele PIC18 haben einen EEPROM-Speicher mit einer Größe von bis zu 1 KB. Leider ist dies bei dem PIC18F46J50, auf den Sie verweisen, nicht der Fall. Wenn ein EEPROM verfügbar ist, ist es eine viel bessere Wahl, wenn es groß genug für Ihre Daten ist, da das EEPROM mindestens 1.000.000 Lösch-/Schreibzyklen hat und der Flash nur 10.000 beträgt.

Der PIC18 verwendet, wie die meisten anderen Mikrocontroller, eine sogenannte Harvard-Architektur, was bedeutet, dass es physisch getrennte adressierbare Bereiche für Programme und Daten gibt (dh Sie können eine Programmadresse 4 und eine Datenadresse 4 haben, und sie sind nicht gleich). Daher können Sie den Flash-Speicher weder mit den normalen Methoden in C noch in der Assemblersprache lesen oder schreiben.

Stattdessen richten Sie bei der PIC18-Familie eine Startadresse in einem 22-Bit-Register namens TBLPTR ein. Um Bytes aus dem Flash zu lesen, verwenden Sie eine TBLRD-Anweisung. Es gibt eine Option, um die Adresse nach einem Lesevorgang automatisch zu erhöhen oder zu verringern, Sie müssen dies nicht manuell tun.

Um in den Flash-Speicher zu schreiben, müssen Sie zuerst einen oder mehrere 64-Byte-Blöcke des Flash-Speichers löschen, die überschrieben werden. Nach dem erneuten Einrichten der Startadresse in TBLPTR und Werten in einigen anderen Registern zum Initialisieren der Löschoperation werden Interrupts deaktiviert, und dann müssen Sie 0x55 unmittelbar gefolgt von 0xAA in ein Register schreiben; Dies entsperrt den Löschbefehl und wird benötigt, um zu verhindern, dass fehlerhafter Code versehentlich den Speicher löscht. Schließlich wird der Befehl zum tatsächlichen Löschen ausgeführt, gefolgt von der erneuten Aktivierung von Interrupts.

Das Schreiben in den Flash-Speicher ähnelt dem Löschen, außer dass die Blockgröße kleiner ist. Der Schreibvorgang wird tatsächlich unter Verwendung eines TBLWT-Befehls ausgeführt, der ebenso wie der TBLRD-Befehl eine automatische Inkrementierung/Dekrementierung ermöglicht.

Zusätzlich zum Speichern von Konfigurationsdaten ermöglicht das Schreiben in den Flash-Speicher das Aktualisieren der Firmware vor Ort unter Verwendung von sogenannter "Firmware over the air". Sie benötigen einen festen Firmware-Block, normalerweise am Anfang des Programmspeichers, der das Update von einem Bluetooth-Modul, Wi-Fi, Mobilfunkmodul oder sogar einer Kabelverbindung empfangen und den Flash über einen bestimmten Punkt hinaus aktualisieren kann das Programm (zB ein "Zaun") mit neuem Code. Nachdem die Aktualisierung abgeschlossen ist, wird ein Reset initiiert und der neue Code wird verwendet.

Viele andere Mikrocontroller neben der PIC-Familie haben die Möglichkeit, ihren Flash-Speicher zu aktualisieren; Die meisten verwenden eine Kombination aus Konfigurationsregistern, einem Adresszeiger und speziellen Anweisungen, um die Aufgabe auszuführen.

Diese "Firmware-over-the-air"-Methode sieht sehr interessant aus. Beseitigt es die Notwendigkeit der In-System-Programmierung (ISP)?
@student1 Es beseitigt nicht die Notwendigkeit einer anfänglichen Programmierung des Chips über eine ISP-Schnittstelle, da Sie etwas Firmware auf den Chip legen müssen, um später mit den Updates umgehen zu können. Die auf den Arduino-Boards verwendeten ATmega-Mikrocontroller verfügen bereits über diese Art von Firmware, die als Bootloader bezeichnet wird, weshalb Sie keine ISP-Schnittstelle verwenden müssen, um Skizzen auf ein Arduino herunterzuladen. Wenn Sie jedoch den Bootloader selbst aktualisieren möchten, ist dafür eine ISP-Schnittstelle erforderlich. Dieser Bootloader verarbeitet nur Updates über USB, ist also nicht wirklich "Firmware over the air".