Hey guys;
Im just wondering what the plans are for allocating certain sections of the EEPROM for settings and other peripherals. Im wondering because I would like to see a welly developed mapping/allocation library for general use; I have yet to find one. Its usually just per application:
#define SETTINGA 0x03
#define SETTINGB 0x05
but I would assume the BP will need a more advanced method of restoring and allocation; so other features dont take over sections its not supposed to touch.
What I would like to see is one main function for calling the data; and one for reading it. That function should be smart enough to know what mode or peripheral is seeking what byte address in the eeprom and 'defend' incorrect writing to the eeprom. Then if every function uses those functions; you wouldnt have to worry about corruption.
I know its more difficult then it sounds.
Does anyone have any ideas thus far?
Kind of hard to think about; if each setting only needed one byte this would be a super simple task; I would imagin a simple eeprom.h and c file; the c held the functions and the h held a 'memory map' for each byte available. But what about settings that need multiple byte; such as storing last used BAUD settings.
hmm
Perhaps the must include; start byte address and length. and mode/callee.
Doesnt the BP already hold _modeConfig I think it is to already know what mode the BP is in; perhaps this is howt he function could know which page this mode belongs too; thats an interesting thought. What if each peripheral got its own page; we will say each page is 64bytes for example.
So; UART is predefined as page 3;
UART_LAST_BAUD is address 0x04; So instead of calling every byte; perhaps the call function already knows UART=3; so UART_LAST_BAUD really = 0x04+(64*3).
I dont know; im just typing while im thinking... Anyone have experience with somthing like this? I will admit iv always just lamed it and used defines for each byte address...
It would be super nice to see no actual hard-coded addresses; if thats possible. The functions themselfs will allocate and remember each location somehow. doubtfull but i uno.
So far the onl y solid thing we have said about the EEPROM is to split it into user playgound and Bus Pirate settings. Playground is probably the first few pages. The Settings will go at the end. We'll discuss this more during Bus Pirate week ;)
Is the eeprom on the bp4 broken into pages by chance? If not you might want to consider doing it via software. Like one page per mode; the first 5 bytes of each page are for standard settings seen on all modes and bytes after that allocated for for different settings. And perhaps one page for global settings.
I think the simplest way would be to have an eeprom_settings.h file and within it defines, a lot of defines:
#define BP_GLOBAL_STARTMODE 0x03 //0x03 = STK500 Mode
#define BP_GLOBAL_
But one thing that’s going to be annoying for example will be:
#define BP_UART_LASTUART_1 0x00
#define BP_UART_LASTUART_2 0x00
…
Because some settings need multiple bytes.
Ian; I know this is something I could tackle; if you give me your thoughts I could setup an allocation header or struct and demo it to you; see if you like it.
I think the globals should be loaded first thing; then mode settings should be loaded when entering that particular mode. For example when your asked for what Buad you want to use in UART the default should be the last used Baud or something like that. I don’t think every setting should be sticky and you have to change it and so on… I think the settings should be more discreete then that… but I don’t know, just my thought.
I have some notes filed away on my plans for this.
I wanted to store the bpconfig struct, with plenty of room. It needs a new bit that determines if BP starts according to the saved BPconfig struct mode setting. Will be set true for STK, etc, or by user config for other modes. SHould leave plenty of extra.
I wanted to store modeconfig too, in a array of structs (I think the EEPROM has 32byte page boundaries). Each located at protocol# + Xbytes. This should be a quite large allocation for future modes and features. This could load preferred/saved settings for each mode on startup (instead of the config dialog at the beginning). It will need new variables for v4 - stuff like pullups enabled, power on, pullup source, and if to use the saved config on startup.
Maybe the config could even be independent of the startup in v4. Startup in HiZ, then use a command for config, or a command to load the saved config. Or at least the option to do that, so newbies still get presented the options.
Maybe we could have a region to save syntax entered at the prompt too. Maybe 10 slots 100bytes wide. We could use an allocation table so big commands can be used up to the total space dedicated to command storage.
These are just some ideas I had, feel free to run with it.
Hi Brent,
I tested latest EEPROM stuff and it seems to work. So the issue was the write protect? When I diable it everything works fine. We asked for 50% protected EEPROM on BPv4, but could not find it, so I assumed you got the type without protection. (I sampled mine, it is the H version with 50% protected).
I will continue here tomorrow.