Hallo: gibt es eine einfache Möglichkeit (unter AVR Studio 7) beim Flashen des ROMS nicht alles (d.h., so lang das Kompilat eben ist) zu braten, sondern einen bestimmten Teil wegzulassen (soll heissen, den bestehenden ROM-Inhalt erhalten). So ähnlich halt, wie man EEPROM beim Brennen mitnehmen kann oder nicht. Mir ist klar, dass dies -wenn überhaupt- nur Page-weise gehen kann. Warum brauche ich das: 90% meines Codes sind feste Daten, die ich dort via lpm zur Laufzeit abhole. Diese ändern sich nicht mehr, wogegen die 10% eigentliches Programm bei der Entwicklung schon. Dei jedem Zyklus muss ich nun meinen uC und mich (warten!) unnötig stressen und würde das - wenn geht - gerne vermeiden. Ideen?
Page-Erase geht nur über einen internen Bootloader, den Du selber programmieren mußt. Per ISP geht nur komplettes Erase.
Via ISP dürfte das nicht gehen, da du dann nur den gesamten Flash löschen kannst. Mit nem Bootlader-Programm sollte es funktionieren. Ob es am ENde schneller ist?? Wie oft musst du denn neu flashen, dass du Angst bekommst den Chip zu ruinieren? Und selbst wenn - was hilft es, wenn du einen Teil kaputtgemacht hast, der Rest aber noch fast jungfräulich ist? Nichts!
H.Joachim S. schrieb: > Via ISP dürfte das nicht gehen, da du dann nur den gesamten Flash > löschen kannst. Danke - das war mir nicht klar. Mein Dragon könnte auch JTAG - da muss ich dann mal lesen... > Mit nem Bootlader-Programm sollte es funktionieren. Ob > es am ENde schneller ist?? ...werde ich probieren (gute Idee!) > Wie oft musst du denn neu flashen, dass du Angst bekommst den Chip zu > ruinieren? Und selbst wenn - was hilft es, wenn du einen Teil > kaputtgemacht hast, der Rest aber noch fast jungfräulich ist? Nichts! Das stimmt wohl. Wenn ich ehrlich bin, ist es mehr meine eigene Ungeduld als die Befürchtung, den uC zu ermorden. .
Hm, wie es beim JTAG-Programmieren ist weiss ich ehrlich gesagt gar nicht. Hat aber auf jeden Fall den Nachteil, dass du 4 Pins nicht für deine Anwendung benutzen kannst, da die JTAG-Fuse gesetzt sein muss und damit die Portlogik für diese 4 Pins futsch ist.
H.Joachim S. schrieb: > Hm, wie es beim JTAG-Programmieren ist weiss ich ehrlich gesagt > gar nicht. Habe gerade mal im data shett gelesen: "The AVR specific public JTAG instruction to directly load the Flash data page via the JTAG port. An 8-bit Flash Data Byte Register is selected as the Data Register." Scheint also möglich zu sein, habe ich aber noch nicht probiert. > Hat aber auf jeden Fall den Nachteil, dass du 4 Pins nicht für > deine Anwendung benutzen kannst, da die JTAG-Fuse gesetzt sein muss und > damit die Portlogik für diese 4 Pins futsch ist. Ist mir klar. Damit könnte ich leben. Die finale Version ann man ja wieder mit ISP brennen. .
Hallo, wie stellt man sicher, das ein C Programm die Daten immer an der selben Stelle alloziiert ?
Karl M. schrieb: > Hallo, > > wie stellt man sicher, das ein C Programm die Daten immer an der selben > Stelle alloziiert ? Linker section definieren und passend benutzen.
MegaAVR kann auch via JTAG nur ein chip erase, kein page erase (sieht man in der Tabelle mit den JTAG-Programmierbefehlen). Xmega kann seitenweises Löschen, unabhängig vom zum Programmieren benutzten Interface. Inwiefern Atmel Studio das jedoch kann, wäre auch da noch eine andere Frage.
Eine Lösung wäre natürlich ein Bootloader. Der kann nämlich Seitenweise (bzw. bei manchen Typen 4 Seitenweise) löschen.
sigma9 schrieb: > Warum brauche ich das: 90% meines Codes sind feste Daten, die ich dort > via lpm zur Laufzeit abhole. Diese ändern sich nicht mehr, wogegen die > 10% eigentliches Programm bei der Entwicklung schon. Wenn es nicht besonders Zeitkritisch ist, dann externes: (SPI oder I2C) NVRAM EEPROM Flash FRAM SD-Karte
Jörg W. schrieb: > MegaAVR kann auch via JTAG nur ein chip erase, kein page erase > (sieht > man in der Tabelle mit den JTAG-Programmierbefehlen). > bist du sicher? Zitat aus data sheet ATmega1284P, Seite 321: 2a. Enter Flash Write 0100011_00010000 xxxxxxx_xxxxxxxx 2b. Load Address Extended High Byte 0001011_cccccccc xxxxxxx_xxxxxxxx (10) 2c. Load Address High Byte 0000111_aaaaaaaa xxxxxxx_xxxxxxxx 2d. Load Address Low Byte 0000011_bbbbbbbb xxxxxxx_xxxxxxxx 2e. Load Data Low Byte 0010011_iiiiiiii xxxxxxx_xxxxxxxx 2f. Load Data High Byte 0010111_iiiiiiii xxxxxxx_xxxxxxxx 2g. Latch Data 2h. Write Flash Page 2i. Poll for Page Write Complete 0110111_00000000 xxxxxox_xxxxxxxx (2) Hier wird doch explizit eine einzelne Flash Page geschrieben - oder sehe ich das falsch? Falls ja, bitte ich um Aufklärung - wie gesagt, praktisch probiert habe ich das noch ncht > Inwiefern Atmel Studio das jedoch kann, wäre auch da noch eine andere > Frage. ...gar nicht, befürchte ich nach kurzem Studium der JTAG tool options. .
Arduino F. schrieb: > sigma9 schrieb: >> Warum brauche ich das: 90% meines Codes sind feste Daten, die ich dort >> via lpm zur Laufzeit abhole. Diese ändern sich nicht mehr, wogegen die >> 10% eigentliches Programm bei der Entwicklung schon. > > Wenn es nicht besonders Zeitkritisch ist, dann externes: (SPI oder I2C) > NVRAM > EEPROM > Flash > FRAM > SD-Karte ...YES! Das ist die Lösung weil nicht zeitkritisch. Danke! Allerdings bleibt dann immer noch die akademische Frage ob es auch AVR-intern geht... .
sigma9 schrieb: > Allerdings bleibt dann immer noch die akademische Frage ob es auch > AVR-intern geht... Nur über den Bootloader Bereich. Mindestens 1 Forth System tut das so.
sigma9 schrieb: > Hier wird doch explizit eine einzelne Flash Page geschrieben - oder > sehe ich das falsch? Vor dem schreiben kommt löschen.
Arduino F. schrieb: > sigma9 schrieb: >> Hier wird doch explizit eine einzelne Flash Page geschrieben - oder >> sehe ich das falsch? > Vor dem schreiben kommt löschen. okay DAS ist es! Schreiben geht page-weise, löschen aber nur chip-weise. Danke für die Aufklärung .
sigma9 schrieb: > Wenn ich ehrlich bin, ist es mehr meine eigene Ungeduld > als die Befürchtung, den uC zu ermorden. Also wie es beim Dragon ist, weiß ich nicht, mein AVR-ISP merkt sich aber die letzte Bitclock vom Flashen. Wenn ich die Bitclock (-B) nicht neu einstelle in AVRDUDE dann wird weiterhin mit der zuletzt eingestellen Bitclock geschrieben. Das kann schon nerven wenn man einmal mit ~8 kHz geschrieben hat weil der AVR mit grad mal mit ~32 kHz läuft und den Programmer nicht auf z.B. 1 MHz Bitclock zurückgestellt hat. Also bezüglich deiner Ungeduld: Wie schnell willst du denn Flashen und wie schnell wäre denn möglich (hab da was von 1/4 CPU-Clock im Kopf)? Vielleicht kannst du ja die Flash-Geschwindigkeit erhöhen ;)
Bezüglich der Flash-Geschwindigkeit kann JTAG übrigens in der Tat einen Vorteil bringen, da man dann nicht mehr an < F_CPU/4 gebunden ist.
@Jörg W @M. Köhler > Bezüglich der Flash-Geschwindigkeit kann JTAG übrigens in der Tat > einen Vorteil bringen, da man dann nicht mehr an < F_CPU/4 gebunden > ist. Das hatte ich gelesen, aber aus dem Blick verloren. Das kann idT deutlich schneller werden. Bitclock: Dies ist (zumindest bei mir) in der Kombination AVR-Studio7 und Dragon in der Tat nervig. Einmal am Tag geraten die außer Synchronisation. Doch wenn dass passiert, ist die Flash-Dauer 8* länger. Das ist dann sooo nervig (8*20s = 160s!), daß ich es sofort merke und korrigiere durch Hard-Reset des Dragon und Restart des AVR Studio. Ich habe den 328 mit internem Takt/1 laufen, d.h. 8MHz. Der schnellste mögliche ISP-Takt ist damit 1MHz. Damit dauert das Flashen ca. 20s. .
sigma9 schrieb: > Ich habe den 328 mit internem Takt/1 laufen, d.h. 8MHz. Der schnellste > mögliche ISP-Takt ist damit 1MHz. Damit dauert das Flashen ca. 20s. Öhm, IMO ist da doch irgend etwas bei dir kaputt/nicht OK. Ich hab dieser Tage erst was auf den 328 geflasht, waren nur rund 6k Byte und die Bitclock war bei 1us (also 1 MHz). Das hat nicht mal 0.5 s gebraucht fürs flashen und das Verify war, mein ich, auch unter 0.5 s.
M. K. schrieb: > sigma9 schrieb: >> Ich habe den 328 mit internem Takt/1 laufen, d.h. 8MHz. Der schnellste >> mögliche ISP-Takt ist damit 1MHz. Damit dauert das Flashen ca. 20s. > > Öhm, IMO ist da doch irgend etwas bei dir kaputt/nicht OK. Ich hab > dieser Tage erst was auf den 328 geflasht, waren nur rund 6k Byte und > die Bitclock war bei 1us (also 1 MHz). Das hat nicht mal 0.5 s gebraucht > fürs flashen und das Verify war, mein ich, auch unter 0.5 s. ....hmmmm, da muss ich dann doch mal forschen. Meine 20s für 32k sind auch incl. verify, aber ohne EEPROM. Dragon hat neueste FW. Außerdem läuft alles stabil in dem Sinne, dass ich nie Fehler kriege (weder verify noch andere): er brät immer absolut korrekt, nur dauert es halt 20s. Werde mal mit dem Oszi drohen... .
M. K. schrieb: > sigma9 schrieb: >> Ich habe den 328 mit internem Takt/1 laufen, d.h. 8MHz. Der schnellste >> mögliche ISP-Takt ist damit 1MHz. Damit dauert das Flashen ca. 20s. > > Öhm, IMO ist da doch irgend etwas bei dir kaputt/nicht OK. Ich habe den Verdacht dass mein Dragon im Win10 nur als USB1 ((!!) - Device geführt wird und dass das der Flaschenhals ist. Kenn jemand dieses Problem? Weiß jemand auf die Schnelle, wie ich diesen Verdacht checken kann? Und falls das Zutrifft: woran könnte das liegen? Ich habe keine Hubs und eine gute 1m-Leitung zwischen USB-Port und Dragon. Wie gesagt, bis jetzt nur ein Verdacht... .
sigma9 schrieb: > Ich habe den Verdacht dass mein Dragon im Win10 nur als USB1 ((!!) - > Device geführt wird und dass das der Flaschenhals ist. 12MBit/s - Ehr nicht. ATm1284 oder m644 schaffen so 256Byte / 4,5ms (~57kB/s) Nach dem Warten muss geschoben werden. 2kBit bei f/4 sind (Bei int. RC und DIV/8) nochmal 8ms Also 12,5ms für 256Byte - also 20kByte/s effektiv. Die 8ms kann man wohl mit JTAG verkürzen. Die 4,5ms bleiben. Gruß Jobst
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.