Hallo zusammen, für meine aktuellen Projekte möchte meine Firmware mit einem mC auf ein externes EEPROM speichern und danach per Bootloader die gespeicherten Daten auf den FLASH schreiben. Dazu habe ich den 25LC512 gefunden, der groß genug ist. Angesteuert wird er per SPI. Gibt es für diesen Speicher schon ein Lib oder muss ich die komplette Steuerung selbst schreiben? Gibt es irgendeine Besonderheit, die bei diesem EEPROM beachtet werden muss? Danke für die Hilfe. P.S.: Ich möchte aus folgendem Grund den FLASH nicht direkt beschreiben: - Max. Flashspeicher nutzen - kleiner Bootloader! - Es könnte zum Verbindungsabbruch während dem FLASHEN kommen. - Flashdaten müssen nur vom EEPROM kopiert werden, keine Interpretation der HEX nötig. Liebe Grüße aus Hessen
Irgendwie ergibt die Aufgabenstellung wenig Sinn. > P.S.: Ich möchte aus folgendem Grund den FLASH nicht direkt beschreiben: > - Max. Flashspeicher nutzen - kleiner Bootloader! Wenn du den Flash-Speicher direkt beschreibst, brauchst du gar keinen Bootloader! > - Es könnte zum Verbindungsabbruch während dem FLASHEN kommen. Beim Beschreiben des EEPROMs ebenso. > - Flashdaten müssen nur vom EEPROM kopiert werden, keine Interpretation > der HEX nötig. Die Hex-nach-Binär-Wandlung macht der Brenner - egal, ob das nun im EEPROM oder im Flash landet.
foobar schrieb: >> Es könnte zum Verbindungsabbruch während dem FLASHEN kommen. > > Beim Beschreiben des EEPROMs ebenso. >> Flashdaten müssen nur vom EEPROM kopiert werden, keine Interpretation >> der HEX nötig. > > Die Hex-nach-Binär-Wandlung macht der Brenner - egal, ob das nun im > EEPROM oder im Flash landet. Während der mC noch im Programm läuft, können die Daten so oft wiederholt und geprüft werden, bis alles korrekt ist. Die Daten werden per ASCII übertragen und müssen vom Programm gewandelt werden und danach in EEPROM geschrieben werden.
honky schrieb: > auf ein externes EEPROM speichern ---> auf einem externen EEPROM speichern honky schrieb: > Gibt es für diesen Speicher schon ein Lib Der Lib, die Lib oder das Lib? honky schrieb: > muss ich die komplette Steuerung selbst schreiben? Was gibt es da schon gross zu schreiben wenn man sich das Datenblatt anschaut .... honky schrieb: > während dem FLASHEN kommen ---> während des Flashens kommen Der Dativ ist dem Genitiv sein Tod! honky schrieb: > Liebe Grüße aus Hessen Liebe Grüße von deinem Deutschleera.
Ein Versuch, die Verwirrung zu vermindern: Du möchtest wohl, daß ein Firmware-Update nicht direkt im Flash landet, sondern daß es zuerst mal in einem externen EEPROM abgelegt wird. Von da soll es in den Flash des Controllers übertragen werden. Richtig? > - Max. Flashspeicher nutzen - kleiner Bootloader! Die Größe des Bootloaders ist in beiden Richtungen durch die konfigurierbare Größe begrenzt (BOOTSZ Fuses). Bei einem ATMega328 kommst du bspw. nicht unter 512 Bytes. Es gibt jede Menge Bootloader, die da bequem reinpassen. Du kannst den Bootloader-Code zwar kleiner machen, hast davon aber nichts. Weiterhin hat dein Bootloader jetzt zwei Funktionen: 1. neue Firmware empfangen und im externen EEPROM ablegen und 2. neue Firmware im EEPROM prüfen und evtl. flashen er wird also tendenziell nicht kleiner dadurch. Selbst wenn man argumentiert, daß Teil 1 ja nicht im Bootloader sein muß - im Flash muß er trotzdem liegen. > - Es könnte zum Verbindungsabbruch während dem FLASHEN kommen. Ja, das ist ein mögliches Problem. Man umgeht es üblicherweise, indem man die Firmware irgendwo zwischenspeichert. RAM, Flash (hat dann effektiv nur noch die halbe Größe). Oder eben externen Speicher. Meist ignoriert man das Problem einfach. Das Gerät ist dann halt gebrickt, bis mal ein Firmware-Update klappt. Der Bootloader funktioniert ja noch. Ansonsten ist der aufwendige Teil eines Bootloaders die Kommunikation mit extern (Handshake, Prüfsummen, konvertieren). Der weniger aufwendige Teil ist das flashen selber. Und das Zwischenspeichern in einem externen EEPROM ist geradezu trivial. Gerade bei einem SPI-EEPROM. Also: machen!
Ein zu beachtendes Problem bei externen EEPROMS : Die Schreibzeit. Allenfalls wuerde sich ein magnetisches FRAM auszeichnen. Das ist viel schneller. und unwesentlich teurer.
Pandur S. schrieb: > Ein zu beachtendes Problem bei externen EEPROMS : Die Schreibzeit. Die 2,5s für 64kB sollten zu verkraften sein. Da er ja jedes Byte sparen will, wird es wohl eher ein kleinerer AVR, z.B. mit 8kB Flash sein.
Dass ein wie auch immer gearteter Bootloader nicht ständig überschrieben werden muss halte ich für wertvoller, als diesen für einen möglichen Übertragungsfehler ständig neu zu schreiben. Ansonsten würde ich mir überlegen, einen Controller zu benutzen, der Code aus dem RAM ausführen kann. Dann kann man das EEPROM beim Start in das RAM laden und loslaufen lassen. Und der Bootloader ist auch noch da. Da ist der AVR aber raus. Gruß Jobst
Axel S. schrieb: > Ein Versuch, die Verwirrung zu vermindern: > Du möchtest wohl, daß ein Firmware-Update nicht direkt im Flash landet, > sondern daß es zuerst mal in einem externen EEPROM abgelegt wird. Von da > soll es in den Flash des Controllers übertragen werden. Richtig? >> Max. Flashspeicher nutzen - kleiner Bootloader! > > Die Größe des Bootloaders ist in beiden Richtungen durch die > konfigurierbare Größe begrenzt (BOOTSZ Fuses). Bei einem ATMega328 > kommst du bspw. nicht unter 512 Bytes. Es gibt jede Menge Bootloader, > die da bequem reinpassen. Du kannst den Bootloader-Code zwar kleiner > machen, hast davon aber nichts. > Weiterhin hat dein Bootloader jetzt zwei Funktionen: > > neue Firmware empfangen und im externen EEPROM ablegen und > neue Firmware im EEPROM prüfen und evtl. flashen > > er wird also tendenziell nicht kleiner dadurch. Selbst wenn man > argumentiert, daß Teil 1 ja nicht im Bootloader sein muß - im Flash muß > er trotzdem liegen. >> Es könnte zum Verbindungsabbruch während dem FLASHEN kommen. > > Ja, das ist ein mögliches Problem. Man umgeht es üblicherweise, indem > man die Firmware irgendwo zwischenspeichert. RAM, Flash (hat dann > effektiv nur noch die halbe Größe). Oder eben externen Speicher. Meist > ignoriert man das Problem einfach. Das Gerät ist dann halt gebrickt, bis > mal ein Firmware-Update klappt. Der Bootloader funktioniert ja noch. > Ansonsten ist der aufwendige Teil eines Bootloaders die Kommunikation > mit extern (Handshake, Prüfsummen, konvertieren). Der weniger aufwendige > Teil ist das flashen selber. Und das Zwischenspeichern in einem externen > EEPROM ist geradezu trivial. Gerade bei einem SPI-EEPROM. Also: machen! Vielen dank für diesen Beitrag. Damit kann ich sinnvoll etwas anfangen. ;) Danke ;) Die Frage in diesem Thema ging hauptsächlich in die Richtung "Ansteuerung eines externen EEPROM". Ich dachte es gibt vielleicht für diese Art von Speichertyp schon eine fertige LIB, um mir arbeit zu sparen. Die Übertragung findet per ESP8266 12F (WLAN) statt. Der Chip auf dem nach der Übertragung geschrieben werden soll ist ein atMega64A. Emfangen wird im Format [Adresse][LEN][DATA]. Geprüft wird mit einfachem Zurücksenden der Daten an den Server und gefolgt von einer Bestätigung. Danach muss im Programm nur noch von ASCII in HEX gewandelt und im externen EEPROM geschrieben werden. Allerdings weiß ich noch nicht genau, wie ich die Daten dort organisiere. Ich stelle mir vor, dass ich jeweils eine Page (128 Bytes) in das EEPROM schreibe. Nach der kompletten Übertragung springt das Programm in den Bootloader. Danach werden jeweils 512 Bytes vom EEPROM in den RAM kopiert und ins FLASH geschrieben. Um das Thema nochmal zu Begründen: - Um max. FLASH(Programm) Speicher nutzen zu können, möchte ich den Bootloader klein halten. Dies geschieht dadurch, dass der Bootloader nur die Bytes in den Flash kopieren muss, ohne dabei etwas zu konvertieren, zu empfangen o.ä. - Der Aufwand mit dem externen EEPROM wird nur gemacht, um 100% sicher zu gehen, dass alle Daten korrekt übertragen sind, bevor das eigentliche Programm gelöscht wird. - Es könnte während dem Flashen zum Ausfall der Stromversorgung kommen. Wenn dies passiert, wird beim nächsten Start wieder der Bootloader gestartet und das Programm wird erneut versucht zu flashen. Es geht schlicht darum eine nahezu 100%ige Sicherheit zu haben, dass das Geräte nach einem Update weiterhin benutzbar bleibt. Ein manuelles Flashen per ISP soll in jedem Fall vermieden werden.
Honky schrieb: > Axel S. schrieb: >> Ein Versuch, die Verwirrung zu vermindern: ... Du mußt mich nicht komplett zitieren. Zitiere doch bitte nur das, worauf du dich spezifisch beziehen willst. > Die Frage in diesem Thema ging hauptsächlich in die Richtung > "Ansteuerung eines externen EEPROM". Ich dachte es gibt vielleicht für > diese Art von Speichertyp schon eine fertige LIB, um mir arbeit zu > sparen. Was willst du da mit einer Lib? Du mußt einen GPIO auf L bringen (CS) und ein paar Bytes über das SPI raustakten. > Die Übertragung findet per ESP8266 12F (WLAN) statt. Der Chip auf dem > nach der Übertragung geschrieben werden soll ist ein atMega64A. Emfangen > wird im Format [Adresse][LEN][DATA]. Geprüft wird mit einfachem > Zurücksenden der Daten an den Server und gefolgt von einer Bestätigung. > Danach muss im Programm nur noch von ASCII in HEX gewandelt und im > externen EEPROM geschrieben werden. Ja, mach halt. Denk dran, daß die Page Size des EEPROM sich in der Länge eines Datenblocks wiederfinden sollte. > Nach der kompletten > Übertragung springt das Programm in den Bootloader. Danach werden > jeweils 512 Bytes vom EEPROM in den RAM kopiert und ins FLASH > geschrieben. Du meinst sicher: das komplette Firmware-Image wird vom EEPROM in das Flash kopiert. Natürlich in Chunks von der Größe der Flash-Pagesize. Wie groß auch immer die ist. Wobei jetzt nicht klar ist, ob du das EEPROM vom ESP8266 beschreiben willst oder wie das laufen soll. > Es geht schlicht darum eine nahezu 100%ige Sicherheit zu haben, dass das > Geräte nach einem Update weiterhin benutzbar bleibt. Ein manuelles > Flashen per ISP soll in jedem Fall vermieden werden. Mit einem Bootloader stellt sich das Problem nicht. Der Bootloader geht immer. Wenn das Firmware-Image kaputt(geflasht) ist, erkennt er das z.B. über eine Prüfsumme und wartet dann auf ein neues. Im schlimmsten Fall signalisiert dein Gerät also über z.B. eine LED, daß es ein Firmware-Update braucht und ohne nicht starten kann.
Honky schrieb: > Der Chip auf dem > nach der Übertragung geschrieben werden soll ist ein atMega64A. Warum diesen Oldtimer? Nimm den ATmega1284, der ist pinkompatibel und kann aber deutlich mehr.
Vielen Dank für die Beiträge. Ich werde versuchen das Umzusetzen. Aktuelle bin ich etwas über die Angaben des EEPROM verwirrt. Speicher: 512kb (64kx8), Page Size: 128 Bytes, Word Size: 8bit, Cascade 8 Meine Fragen dazu: - Wordsize 8bit? Ich kenne von C nur 2 Bytes = 1 Word - Kann nur eine komplette Page gelesen / geschrieben werden? Also 128 Bytes? (Oder 64k ?) - Wie groß ist das ROM jetzt in KiloBytes? atmega64A hat 64 KiloBytes. Mindestens diese Größe muss ich abbilden können.
Hallo, die Gesamtgröße wird in kilo Bit angegeben. Also deiner hat 512kBit. Ansprechbar mittels 64 Tausend Bytes. 64k * 8Bit = 512kBit oder 512kBit / 8Bit = 64kByte. Passt. Kannst dir auch überlegen FRAM zu verwenden. Je nachdem wie oft du vorhast ihn zu beschreiben.
Honky schrieb: > Muss ich seitenweise schreiben bzw. Lesen? Im Prinzip kannst du das EEPROM sogar byteweise beschreiben. Aber das wird zäh. Also wirst du dich wohl darauf einlassen müssen, eine EEPROM-Page im RAM zwischenzuspeichern und dann als ganzes zu schreiben. Lies halt das Datenblatt. Wenn ein Firmware-Update immer 64K groß ist (ist es nicht, der Bootloader geht ab) dann kannst du das EEPROM auch gleich im Ganzen löschen. Bzw. vorlöschen. Da mußt du nicht die Logik mit "erst Page löschen, dann beschreiben" implementieren. Lesen kannst du das frei Schnauze. Wenn es sein muß, sogar an einem Stück. Nützt dir nur nichts, weil das Flash ja auch seitenweise zu schreiben ist.
Danke, die Informationen hat mir noch gefehlt! ;)
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.