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?
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.
.
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.
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.
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 ;)
@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
