| ??? 03/28/08 03:46 Read: times |
#152646 - Re: options Responding to: ???'s previous message |
Jan Waclawek said:
This depends on HOW do you want to "put it" there. If you are going to use some parallel programmer, you need to do whatever that programmer needs. There is no real standard how to "mark" separate memory areas (such as blocks of FLASH, EEPROM, nonvolatile battery-backuped RAM, configuration fuses, and mixture of these in various microcontrollers). It might well be that such records are required as separate files, or in other instance, in a single file mapped to different addresses. You'll need to refer to your programmer's documentation. Yeah I tried it with my programmer (I use the SSTFlashFlex software, and a home made serial programmer), and it needs it in a separate file. Tells me the program is too large if I put anything above F000. Jan Waclawek said:
It's quite likely that the bootloader does not occupy the whole block1, so you might use that spare space. Is it a bootloader of your own, I mean, do you have full control over it (how much space it occupies)? Also, if you don't use a parallel programmer and program your chip via that bootloader, there might be a risk of destroying the bootloader.
I don't have the original source file, but I looked at the .hex and it does actually occupy the whole block, except for 64 bytes at the beginning of the file (F040 to F080). I could put some stuff in there, but that means I can't use your two sectors of 64 bytes idea, which by the way was pretty smart I thought. I only have about 20 bytes of user settings, so maybe I could load it into a temporary memory, erase the sector, have an offset for each setting in the temporary memory address, write to that offset for the one setting I want to change, and then rewrite the whole temporary memory back into the same 64 byte sector. I just thought of that, I wonder if it would work. That almost seems too easy to work... Maybe I'll test that out. Jan Waclawek said:
You don't need to do this. Simply put aside two sectors. Keep your settings in one of them, and keep the other erased. When you want to change one setting, simply copy those which don't change into the "empty" sector, and write those which did change, and when you're don, erase the "old" sector. Upon startup or at any moment when you need to read the current settings, it's easy to detect which sector is "empty" and which is "active". (You'll certainly figure out also the details of marking sectors valid/invalid, and recovery from an interrupted reprogramming sequence). That's a good suggestion. Thanks. Jan Waclawek said:
Well, the standard way of doing things is slightly different.
Instead of putting setup into block1, the bootloader in block 1 is written so that it contains "methods" to erase sectors in block 0 and program them. Then, both the application and setup data are sitting in block 0, but the application is able to reprogram "herself" by calling the IAP "methods" in block1. JW That makes sense. That would also be helpful to get out of the 2k limit (I'm using Keil evaluation version) I suppose... I'm at 71% right now, so if I could split the reprogramming part into a separate project for another 2k of space if need be, that'd be swell. Are there any serious drawbacks to doing it the way I originally planned it, or is it just "not usual"? I'm thinking it would be a bit easier on me to have all the code in one project, when it comes to the documentation I have to write up. This is pretty much the only code I have left to write, everything else seems to work great in my breadboard setup. Hopefully I'll get my circuit board all soldered this weekend. I had to mill the board for the third time yesterday, so I'm hoping this one isn't faulty. Thanks for your input, it's greatly appreciated. |
| Topic | Author | Date |
| IAP to save settings | 01/01/70 00:00 | |
| Disregard that... | 01/01/70 00:00 | |
| options | 01/01/70 00:00 | |
| Re: options | 01/01/70 00:00 | |
| to make the long story short... | 01/01/70 00:00 | |
Thanks | 01/01/70 00:00 |