Add menu options for EEPROM size selection #261
Conversation
Board setup for 0 EEPROM if the lib is not included
if int lgt_eeprom_size(){
if ( ECCR & 0x40 ) return ( 1020 << ( ECCR & 0x3 ) );
return 0;
}
void setup() {
Serial.begin(115200);
Serial.print("lgt_eeprom_size:");
Serial.println(lgt_eeprom_size());
delay(1000);
}
void loop() { }
If the lib is imported#define USE_LGT_EEPROM_API
#include <EEPROM.h>
void setup() {
Serial.begin(115200);
lgt_eeprom_init(EEPROM_SIZE); // this is the constant set through the menu
Serial.print("lgt_eeprom_size: ");
Serial.print(lgt_eeprom_size());
Serial.println();
}
void loop() { }Prints |
| @@ -102,10 +102,6 @@ void lgt8fx8x_init() | |||
| // store ivref calibration value (According to the LGT8F328D databook, if VCAL is rewritten, the value of VCAL1 can be lost.) | |||
| _VCAL_1_ = VCAL1; | |||
|
|
|||
| // enable 1KB E2PROM | |||
There was a problem hiding this comment.
@LaZsolt The EEPROM.h library will set this to 1 by default when imported anyway.
If the lib is not imported, the ECCR register will stay at zero, which means "I won't use the EEPROM"
There was a problem hiding this comment.
Incompatible idea. #261 (comment)
|
@dwillmore @jg1uaa @jayzakk, your feedback (and that of anybody else) very welcome :) Also, I need some help writing a test that:
Any willing volunteer? :) |
|
Uhm... I just read in our wiki that the bootloader is stored right after the 2 kb reserved for the EEPROM, this whole thing may be cursed... I don't find any explicit offset set in platforms.txt though |
Not true. The bootloader is stored before the 2kB reserved EEPROM space. So
not true. The factory burned bootloader started at address Ergo for the different emulated EEPROM size require different bootloader. All in all if the EEPROM size menu exist it is only could reseve ROM space for such a type of EEPROM emulation software which not using the hardware emulation. In this case the bootloader must start at address |
|
Edit:
Not true. The bootloader is stored before the 2kB reserved EEPROM space. |
|
Somehow I unmarked the draft attribute this pull request. But I don't know how. |
it's on the top right. Marked as draft again |
|
Ok, I'm thinking about closing the PR then. What if one is using an ISP? There's no bootloader in that case so maybe adding a new board type for it would allow using all the space |
|
BTW, I did not follow the impact of the recent updates, but if one of you change the address of the bootloader according to the EEPROM size picked in the menu, please update the https://github.com/dbuezas/lgt8fx/wiki/EEPROM-of-the-LGT8F328p-:-the-important-things-you-need-to-know |
As mentioned by @LaZsolt , when i wrote the wiki, the bootloader was actually stored BEFORE the EEPROM :
Extending the EEPROM at runtime would overwrite the bootloader, and might also overwrite a part of the program space. Setting the EEPROM to 0 by default, would leave 2kB of unused blank space AFTER the bootloader, unless you relocate the bootloader. Here is something I did not think about when i rewrote the EEPROM library : maybe it is possible to swap the bootloader and the EEPROM. It is possible to modify the EEPROM library to protect the 2 last 1kB pages in which would be relocated the bootloader. edit : and when the EEPROM is enabled, the unused 1kB page just before (or just after) the bootloader could be used as a emulated-fuse space. (as it is possible to write once into each blank cells without triggering destructive page swap) |
|
@SuperUserNameMan you are back! :) I sent you Collaborator rights. This allows you to merge PRs and allows ppl in comments to link you even if you are not part of the thread yet.
Nothing related to the bootloader or eeprom except this PR.
It probably is, but this will make this core incompatible with the default bootloader these boards typically ship with. Most likely a bad idea.
I don't understand this: the bootloader is in lower ram than the emulated EEPROM space. Does the EEPROM grow backwards? I think the only option available would be to make an option to not reserve EEPROM space specifically to be used without the bootloader (i.e while burning via ISP). WDYT? |
My availability might be unreliable for major contribution, though i might still be of use regarding EEPROM questions as long as my memory is not outdated.
Yes, it is extended backwards so that everything remains within the 32kB memory space.
Yes, i think you could set the size of the EEPROM to 0 by default, so when the sketch is uploaded using an ISP, the whole 32KB of flash is available for the sketch. And when uploading a sketch using the bootloader, setting the size of the EEPROM to 0 by default should have no impact other than wasting 2kB of space at the end of the flash. (however, you might want to check if it does not interfere with the initialization code of the EEPROM library) |
Do you mean the bootloader is copied into the RAM ? |
|
The bootloader runs from flash started at address 0x7400. From these address the code can be read with the pgm_read_byte(). But the bootloader code also readabe from RAM address started at 0xB400. |
|
Crazy idea, but if the EEPROM emulated by software it could be jump up the bootloader code. Another crazy idea, for that case when the EEPROM size is 0, is that define a fixed adressable read only 1k data block with starting address is the same as the bootloader then the compiler could avoid to put any code here, but the last 2k became useable. |
|
Very interesting! |
Unless the compiler is aware of the maximum available memory, yes. |
Yes, i was thinking about the same. We then would have EEPROM with theoretical sizes of 1KB, 3KB or 7KB.
Instead of :
If it is possible to tell the compiler to skip the bootloader, that's a good idea ! |
|
Oh wait, I think i need to refresh my memory about how the EEPROM is emulated before misleading you on that topic. |
|
Well if you want to skip the bootloader, you just have to hack : This function is used to recalculate the EEPROM address so that the library automatically skips the last 4 bytes of each 1KB pages of EEPROM. Note that the EEPROM library is not aware of the hardware page-swap algorithm which consume 2 Flash pages per 1KB EEPROM page. Also note that the EEPROM library does NOT think in term of the Flash memory space : it does not care about the actual address into the Flash memory, because it is handled by the hardware EEPROM module which will convert the EEPROM space addresses into Flash space addresses. So when the EEPROM library will skip the before last 1KB page of its EEPROM space, the hardware module will actually skip 2KB (2 pages) of the Flash memory space (from 0x7000 to 0x7fFF ). Which should preserve the bootloader (and leave 1KB of unused flash memory) |
|
Hi, I have seen this is closed. I have read it, but still I do not understand if there is a way to get completely rid of the EEPROM in order to use the full 32 KB flash for program code. |
|
I think if the program uploaded using an ISP then all the 32 KB flash will be available for program code. |
|
Thanks for the reply. I tried uploading via LArduinoISP, it does not seem to change anything:
I also tried to allocate 0 KB for the EEPROM using: It had no effect. Same with: |
|
The displayed size of uploadable code size comes from here: Line 19 in df986b5 It can be exceeded but we get a warning. |
|
I am used from the AVR Arduinos that this max. value is flexible. E.g. if you use the Optiboot bootloader the value is smaller compared to what you get when you don't use it. If it's just a fixed value which uses the default setting of 1 KB EEPROM this explains my confusion. Displaying the real max available flash would be helpful. |
|
So displaying the full 32KB? We can do that if the community agrees |
|
The main reason for my question is that some people asked if they could use the Arduino Optiboot for the LGT8F328P, because they think it's smaller than the bootloader for the LGT8F328P. Like me, they just at value you get during upload. |
I think displaying the real available flash will not be easy because uploadig with ISP cannot be detected. I will study the Arduino core solution. An Optiboot support wish for LGT8F328P: Optiboot/optiboot#359 |
|
Just to be sure that I have understood it correctly: it's just the bootloader that takes ~ 3KB and this does not include the 2 KB which are needed for the 1 KB EEPROM? And thanks for the link! |
|
The LGT8F328P bootloader less than 1 kB. |
|
< 1KB - that's great. If it's difficult to implement a method to display the exact flash which is available, then some documention how the 29696 bytes are calculated and under which conditions this value applies would be helpful. I am by far not so deep in this matter like you, but still I would say I am not an absolute beginner. I simply thought I did something wrong when I changed the size of the EEPROM and the max available flash size didn't change. Therefore, there are probably quite a number of people who have similar problems. I also have not yet finally understood if there is flash reserved for the EEPROM by default, even if I do not include EEPROM.h. From what I read now I would assume that there are roughly 31 KB Flash available if I don't use the EEPROM and 29696 bytes if I use 1 KB of EEPROM. Sorry, to bother you with all these questions, but would really like to understand this. |
|
From the wiki article about EEPROM written by @SuperUserNameMan, the flash layout is: [0, Program..., ...bootloader..., ...EEPROM, 32000] Trying to use more than 1k of eeprom (taking 2kb of flash) will overwrite the bootloader, because the eeprom "grows backwards". This means that the only way to have bigger programs is to forego the bootloader (upload via isp). |
|
Hi, this is helpful. Sorry to be so tenacious, but there is still one thing I am not sure of: "By default, the size of this emulated EEPROM is set to 1KB, and it can be changed at run-time to 0KB, 1KB,2KB, 4K or 8KB." Does the default (1KB EEPROM) only apply if I include EEPROM.h? In other words: If I use the bootloader and I don't include EEPROM.h, will no flash be reserved for the EEPROM and therefore I should have ~31KB flash? |
I checked the AVR Arduino core.
So in my opinion no need to change the displayed maximum upload size. In summary: The bootloader stored in a fixed location in program flash memory followed by emulated EEPROM space. If EEPROM space changed bigger than 1 KB the bootloader will be overwritten after writing some bytes to the EEPROM spaces. If someone want to use bigger (or smaller) EEPROM space the bootloader must be relocated. This relocation method is not yet invented. |
|
Very clear - that answers my question perfectly. Thank you! The other good news: no more questions from side! Thanks for your patience. |
|
So to use the full 32kb:
Right? |
|
Yes. |
|
And that goes for ATMEL and LGT?
…On Sun, Jul 2, 2023 at 11:37 AM LaZsolt ***@***.***> wrote:
Yes.
—
Reply to this email directly, view it on GitHub
<#261 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACPEX7FOOJZGR2AFE3XOOTDXOGITDANCNFSM6AAAAAAWNZA6DY>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
No, ATMEL has real EEPROM independent of flash |
What do you think about this @LaZsolt ?
Relates to #243