Adjust tables in real time

[STC]

Discussions about adding opportunity to adjust tables in real time

[Fred]

If you tell me to RTFM, fair enough...

Can you write to flash from code on your CPU?
From reading the other thread I assume you CAN write to EEPROM?

I've been thinking abotu a way to do this on limited resources recently as I'm porting FreeEMS to a different CPU in my spare time/when bored.

My idea is to have only one tunable thing in ram at a time. So you use pointers to the things you need to read to run your code, and they all start off pointing at flash. Then you choose one to live tune, copy it up from flash, then switch the pointer to RAM, then tune, then write back down to flash, then move pointer down to flash and you're ready for the next thing to tune. Make sense?

Can you do something similar to this, except write to EEPROM and change pointer to there also?

Thoughts?

Fred.

[STC]

AVR designed in such way, that you can write into code section only from boot section and vice versa. Of course, it is possible to implement dirty hack and jump to boot section for short period of time to perform writing, without reboot. SECU-3's boot loader does not provide such hack.

Maybe if you know AVR has Harvard's architecture. That is why it is impossible to do it by only changing pointers. Either, you must have two versions of code (for RAM and ROM) or recompile program each time.

I imagine it as following:
To have only one tunable set of tables in the RAM. At the startup (previously selected set will be loaded) or when user selects desired set of tables it will be copied in to the RAM. But, how to save edited data into th FLASH? I will use EEPROM for this purpose. Among standard sets of tables user will be able to select "Tunable" set. This means, at the startup data will be copied from EEPROM. User will be able to save tuned tables into EEPROM each time he need. When he feels that tuning process is completed, he will have opportunity to transfer set of tables from EEPROM into FLASH.

[Fred]

AVR designed in such way, that you can write into code section only from boot section and vice versa. Of course, it is possible to implement dirty hack and jump to boot section for short period of time to perform writing, without reboot. SECU-3's boot loader does not provide such hack.

But that doesn't matter due to your EEPROM being available for writing, right?

Maybe if you know AVR has Harvard's architecture. That is why it is impossible to do it by only changing pointers. Either, you must have two versions of code (for RAM and ROM) or recompile program each time.

I don't understand how this can be true.

Your code must have variables otherwise you couldn't do basic math etc. If so, then you could have a var that was a pointer. If so, then you could set and modify that pointer to point at different places. Even if the thing has different style pointers for ram/flash/eeprom you could use a delegator function to do the lookup and a type flag along with a pointer or more than one pointer of the different types. There must be a way, if not, please explain why not more clearly.

I imagine it as following:
To have only one tunable set of tables in the RAM. At the startup (previously selected set will be loaded) or when user selects desired set of tables it will be copied in to the RAM. But, how to save edited data into th FLASH? I will use EEPROM for this purpose. Among standard sets of tables user will be able to select "Tunable" set. This means, at the startup data will be copied from EEPROM. User will be able to save tuned tables into EEPROM each time he need. When he feels that tuning process is completed, he will have opportunity to transfer set of tables from EEPROM into FLASH.

This sounds more or less exactly like what I said above, I think. The EEPROM >> flash copy would be done using an external tool, right?

The point was, that when the data is in RAM the code should use that RAM version to run from. And when its not in ram, but in flash or EEPROM, the code should use that version. As far as I can tell the way to do that is with a pointer.

Fred.

[STC]

But that doesn't matter due to your EEPROM being available for writing, right?

Yes, of course. EEPROM can be R/W

Your code must have variables otherwise you couldn't do basic math etc. If so, then you could have a var that was a pointer. If so, then you could set and modify that pointer to point at different places. Even if the thing has different style pointers for ram/flash/eeprom you could use a delegator function to do the lookup and a type flag along with a pointer or more than one pointer of the different types. There must be a way, if not, please explain why not more clearly

It is not possible to cast pointer between RAM and FLASH in the real time. This is because on this architecture RAM and ROM accessed by different type of CPU instructions. The only way is to keep copy of data in the RAM and load it from FLASH when it is needed.

This sounds more or less exactly like what I said above, I think. The EEPROM >> flash copy would be done using an external tool, right?

Yes, EEPROM >> FLASH will be done by external tool (SECU-3 Manager).

[Fred]

It is not possible to cast pointer between RAM and FLASH in the real time. This is because on this architecture RAM and ROM accessed by different type of CPU instructions. The only way is to keep copy of data in the RAM and load it from FLASH when it is needed.

Then you could use a delegator function to achieve this. Not now, but I'll explain what I mean with some pseudo code later.

[STC]

I've already started implementation of this feature.

[STC]

I will finish implementation of this feature on next week (it is already mostly finished).

[Fred]

I will finish implementation of this feature on next week (it is already mostly finished).

Great! :-)