Hallo, der ATmega2560 hat ja 256K Bytes Flash. In der Doc2549 steht unter 8.1 auf Seite 21: ...128K × 16. For software security, the Flash Program memory space is divided into two sections, Boot Program section and Application Program section. Die X,Y,Z Register sind ja weiter nur 16 Bit breit. Somit kann man ja nun 64K * 16 adressieren. Ist es so das ich praktisch nur 64K * 16 für irgendein Bootloader Krams nutzen kann und wenn das ausgeführt ist, gibts eine Möglichkeit in die 2. Page "Application" zu springen und meine "Application" Programme können dann nur diese 2.Page mit 64K*16 benutzen? Oder kann man auch zwischen diesen "Boot Programm" Page und "Application Program" Page adressieren? Ich dachte zum Beispiel daran, wenn das nicht ein durchgehender Bereich ist, im Bootloader Bereich Texte für Menüs oder Fonts für Grafiken abzulegen. Oder klappt das auch nicht ? Einen Bootloader brauch ich nicht/hab ich nicht geplant. Danke schon mal. (Ist mein 1. Idee den 2560 zu benutzen) Viele Grüße Herbert
Hi
>Danke schon mal. (Ist mein 1. Idee den 2560 zu benutzen)
Und warum liest du dann nicht erst mal das Datenblatt. Da steht einiges
über den Bootloader drin.
MfG Spess
Herbert K. schrieb: > Oder kann man auch zwischen diesen "Boot Programm" Page und "Application > Program" Page adressieren? Ich dachte zum Beispiel daran, wenn das nicht > ein durchgehender Bereich ist, im Bootloader Bereich Texte für Menüs > oder Fonts für Grafiken abzulegen. Oder klappt das auch nicht ? Einen > Bootloader brauch ich nicht/hab ich nicht geplant. Die Grenze ist nur eine logische. Sie kann zudem per Fuses gesetzt werden. Wenn Du keinen Bootloader benutzt steht dir der komplette Flashspeicher als ein durchgängiger Bereich zur Verfügung. Weite Sprünge und der Zugriff auf Daten im Flash benötigen das Z-Register. LG, Sebastian
Sebastian Wangnick schrieb: > Weite Sprünge und der Zugriff auf Daten im Flash benötigen das > Z-Register. Wie Herbert dem Datenblatt richtig entnommen hat, ist das 16 Bit breit... Oliver
Hallo Falk, Danke sehr ! Viele Grüße Herbert (doc2549: 7.6.1 RAMPZ – Extended Z-pointer Register for ELPM/SPM)
Herbert K. schrieb: > (doc2549: 7.6.1 RAMPZ – Extended Z-pointer Register for ELPM/SPM) Das ist beim 2560 nur die halbe Wahrheit. Da kommt dann noch das EIND-Register dazu, was gebraucht wird, wenn man Code in dem Teil oberhalb 128kB anspringen oder als Unterprogramm aufrufen will und aktuell zu weit weg davon ist, um das per rjmp/rcall zu erledigen. Dann hilft nämlich auch jmp/call nicht weiter, was vom Mega16 bis zum Mega1284 der Fallback ist, sondern die Sache ist per eijmp/eicall indirekt zu behandeln. Das "fehlende" Bit hat dann in diesem Register zu stehen, der Rest der Sprung(wort)adresse im Z-Register.
Hallo c-hater, ebenfalls Danke für die Erklärung/Hinweis. Ich hoffe doch, das haben die Compilerbauer im Griff. :-) Viele Grüße Herbert
Herbert K. schrieb: > Hallo c-hater, > > ebenfalls Danke für die Erklärung/Hinweis. > > Ich hoffe doch, das haben die Compilerbauer im Griff. :-) Warum sollten sie Code besser als Daten können? Entweder ich beherrsche als Compilerbauer das Zielsystem, dann sollten sich Compilerbenutzer weder um das eine noch um das andere kümmern müssen, oder ich beherrsche es nicht, dann ist es das Beste, den Compiler überhaupt nicht zu benutzen, denn er taugt offensichtlich nicht für das Zielsystem. So einfach ist das...
Herbert K. schrieb: > Ich hoffe doch, das haben die Compilerbauer im Griff. :-) Bei Daten die im Flash liegen hat der GCC (genau genommen der WinAVR, AVR Studio 4.xx) keine Möglichkeit die Adressen über 64K anzusprechen. Es konnte jedenfalls bisher keiner erklären wie ein Far-Pointer in diesem Umfeld auszusehen hätte bzw wie dieser funktionieren sollte. Bauen kann man schon einen aber das alleine hilft nicht wenn der Pointer nicht dorthin zeigt wo man ihn braucht bzw der Code dort nichts macht was man adressieren will. Erst bei der "Toolchain" unter AtmelStudio (5.x? 6.x?) soll es dann möglich sein .....
Hallo, von gcc hab ich bisher nichts geschrieben. Soweit versteht das Micropascal noch.... const TST_TEXT1000 = 'ABC'; far; org 0x3D125; Wird dann in der LST Datei zu: ;Pointer-Tabelle-getestet-Beispiel.mpas,3 :: _TST_TEXT1000 0x3D125 0x4241 ;_TST_TEXT1000+0 0x3D127 0x0043 ;_TST_TEXT1000+2 ; end of _TST_TEXT1000 Soweit ok. Aber das wars dann schon. Far Pointer auf 0x3D125 gibts dann schon nicht mehr, bzw. wird dann bei 64K abgeschnitten. org 0x3E000; funktioniert nicht mehr. Da ist doch Flash, da liegt doch kein Stack. ??? Warum ??? Normalerweise sollte org 0x3FFFC noch funktionieren bei "ABC" + 0 als Ende vom String. Kopfschüttel ... Die .HEX Datei sieht auch falsch aus. Da steht "ABC" bei "D125" wenn ich das richtig sehe: (Die Leerzeichen hab ich da reingemacht) :10D11000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF1F :10 D1 20 00 FF FF FF FF FF 414243 00 FFFFFFFFFFFFFF45 :00000001FF Aber das sind Dinge, die gehören zu mikroe... Allen noch einen schönen Abend. Viele Grüße Herbert
@ 2560er (Gast) >Bei Daten die im Flash liegen hat der GCC (genau genommen >der WinAVR, AVR Studio 4.xx) keine Möglichkeit die Adressen >über 64K anzusprechen. >Es konnte jedenfalls bisher keiner erklären wie ein Far-Pointer >in diesem Umfeld auszusehen hätte bzw wie dieser funktionieren >sollte. doch das geht. https://www.mikrocontroller.net/articles/AVR-GCC-Tutorial#Flash_mit_PROGMEM_und_pgm_read "Variablenzugriff >64kB"
so, ich glaub für Daten hab ich was in einer LST Datei gefunden: 0x033E 0xE0B2 LDI R27, 2 0x0340 0x2E4B MOV R4, R27 0x0342 0xE0B0 LDI R27, 0 0x0344 0x2E5B MOV R5, R27 0x0346 0xDF58 RCALL _FLASH_Read_Bytes+0 LDI R27, 2 Die 2 stammt aus const F_ADDRESS : longint = 0x29977; landet in R4 und damit wird in dies Unterprogramm gesprungen und damit die "Page" ausgewählt: _FLASH_Read_Byte: ; tmp start address is: 16 (R16) 0x023C 0xB70B IN R16, RAMPZ+0 0x023E 0xBE4B OUT RAMPZ+0, R4 0x0240 0x01F1 MOVW R30, R2 0x0242 0x9006 ELPM R0, Z 0x0244 0xBF0B OUT RAMPZ+0, R16 ; tmp end address is: 16 (R16) ; Result start address is: 17 (R17) 0x0246 0x2D10 MOV R17, R0 0x0248 0x2F01 MOV R16, R17 ; Result end address is: 17 (R17) 0x024A 0x9508 RET ; end of _FLASH_Read_Byte Ich hoffe, ich habe das so richtig analysiert. Das ist ein übersetzter Code Schnipsel aus einer Demo für UART Nutzung. Und wenn man "LONG HEX Format" ausschaltet, sieht es auch im "Burner" Programm gut aus. Auch noch den letzten Rest im Flash adressieren kann man unter "EDIT Project" -> "Program Memory is used" einstellen. Praxis Test stehen noch aus. Heute nicht mehr. Viele Grüße Herbert
:
Bearbeitet durch User
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.