-
Notifications
You must be signed in to change notification settings - Fork 188
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
#1131 First try to implement storing keyer memories into serial EEPROM #1435
Conversation
Hi Andreas, Eriks, @Eriks: I will have a look at your code this weekend and see if I find your problem with storing data. |
I am fine with having discussion before merging as I agree that some overall plan for EEPROM usage would be good. Are there any other ideas what to store in EEPROM besides configuration variables, keyer memories, and #236? |
Hi Eriks, storing of SSTV images, voice, logging and so on in is planned for SDcard. But this is not mcHF related - only OVI40. Keyer memories CAN be stored there - but it will be very wise to discuss the structure of the storage. |
Hi, |
Essentially this is implementing malloc. Do we really need it right now? It might make sense for dynamically allocating/freeing memory for received SSTV images, but for configuration information, which is static, it should be sufficient just deciding on the address and consider it reserved for other uses. |
Hi Eriks, we are not lucky to burn EEPROM cells with structures which can (and will) get problems if structures change later. There are already wishes for storing more informations to band specific storage places, and there will come up frequency memories which will need all the storage of a normal band specific storage place. I feel that a "data structure" like Danilo proposes will work for all extensions that will come up the next future. Additinally we should pay attention for maximum capacity of virtual EEPROM. There will be overflow in the future, so no backup possibility from this point on. And the last, most important thing: first all memories should work not only one. Let us discuss about a file system like data block system and define the first identifiers. |
just an idea ... memory for keyer should also be usable in other modes ... and editable with keyboard |
@DG9BFC Memory keyer is usable for playing recorded message in PSK from the start. |
ok on that ... will the memory texts be available in ALL modes (rtty included)? then they also can be used in whatever mode will come ... and that was the idea behind my suggestion (available in all modes) ... GOOD WORK, WELL DONE |
@phaethon: I don't see that we get any progress on the general eeprom storage code. I suggest to change the start address to 0x1000h . Minimum accept EEPROM size is 32k, so 4k boundary is okay, I'd say. |
Changed memory start address to 0x1000. Now it works for all 3 memories. |
Hi Eriks, Thank you! EDIT: To be honest: Maybe these extra commits will go away once merged by Andreas, DF8OE via git, but we won't that risk here. |
@db4ple please, see now. |
Thanks Eriks, result looks perfect. Just for my curiosity did it work more or less with the approach I suggested? |
Roughly, yes. In addition, I did |
This is work in progress. It currently works only for the first memory, but I haven't found the bug yet. May be I am misunderstanding how SerialEEPROM_24Cxx_WriteBulk should be called?
Serial EEPROM is mandatory for this f-ty.
Please, comment on the value of EEPROM_KEYER_MEMORY_ADDRESS
I am not checking the size of EEPROM as the minimum supported size is enough.