Python to C, EEPROM Strategy for replacing the dictionary type used

Here are a couple of storage functions created with python (dict[key]=value, probably like an array in array i believe)

def checkMap(intake):#check if input assigned
    if intake in assigned:
        print assigned[intake]
        
def assign(correctGuess,intake):#builds assigned dictionary 
    assigned[intake]=correctGuess

My problem is im going to receive one piece of data (ie buttons 1&2 or 3&4 pressed) and I need to check the EEPROM to see If that key/byte has an assigned value (single ascii char).

In python this was made easy with the dictionary variable with its keys and values, I realize that I'm going to have to be more explicit here and be conciseness of space used. I sure intake and assignment(correctGuess) can be stored as bytes, I'm just not sure how I'm going to associate them with one another.

Really looking on thoughts on strategies to approach this, I'm kinda new, sorry if its something obvious.

What (how many) are the possible values of “intake”? If you have 4 buttons then there are only 16 possible values to store/check-- do I understand correctly? If so then something like this may work:

signed char assigned[] ={ -1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1};

void checkMap(byte intake){
   // precondition: 0<=intake<16
   if ( assigned[intake] > 0) {
      // print assigned[intake]
   }
}

void assign( char guess, byte intake) {
   // precondition: 0<=intake<16
   assigned[intake]=guess;
}

unsigned char assigned ={ -1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1};
What?

PaulS:
unsigned char assigned ={ -1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1};
What?

Yeah, pretty stupid mistake! Changed to “signed”

the buttons will produce more then 16 values. There will be accounting for double clicks, holds, and offset between chords ie, b1&b2 press within 2 milliseconds = regular chord, vs b1 then b2 outside 3 milliseconds = offset chords Which produces a lot more entropy then 16, and also brings the issue that I'll probably assign multiple keys/chords to the same char in some instances

The reading will be converted to a byte value to keep these functions within the means of the arduino. (I presume this is necessary) In any case I need to make at least 128 assignments to persistent storage that is writable at run time, so the arduino will remember the assignment and be able to do assignments based on a learning function

my curiosity is mainly about being able to figure out the assignment from read() on EEPROM (and making the assignment fit there, if that is difficult) but as im just getting started with c++ I guess I'm also confused about how to append to; char assigned[ ]={"a","b","c"}; after it has been declared (though im sure ill figure this out with some reading)

maybe I could place the key in the EEPROM byte position as relates to the char on the ascii chart?

My thought is that with 128 (or even 256) possible values it would still be workable to store in a “sparse array”, either in EEprom or in RAM (saved/restored from EEprom). As a “sparse array”, you don’t have to “append” to it because all possible indexes are pre-allocated.

The RAM version would be as above, but with “ENTROPY=128” rather than what I wrote, in effect, “ENTROPY=16”.

The EEPROM version would be pretty much like (warning: not compiled)

const int ENTROPY=128;

void checkMap(byte intake){
   // precondition: 0<=intake<ENTROPY
   byte val=EEPROM.read( intake);
   if ( val > 0) {
      // print val
   }
}

void assign( byte guess, byte intake) {
   // precondition: 0<=intake<ENTROPY
   EEPROM.write( intake, guess);
}

void initAssigned(){
   for (int i=0; i< ENTROPY; i++) 
      EEPROM.write( i, -1);
}

Does that make sense?

Cheers,
John

johncc:
Does that make sense?

yes, but I think there was a misunderstanding of my intention, regardless gave me some kindling for the thinking fire.
I probably should have included the function that produces guess in the op but I didn’t want the topic to go into the weeds.

anyhow here is what I have come up with

void assign(byte correctGuess, byte chordValue)
{//assigns chords to chars
  EEPROM.write(correctGuess, chordValue);
//guess is artificially stored as address space
}

bolean checkPROM(byte chordValue)
{
 boolean isHere=false;// needs to return a true if value is here, to prevent guess
 for(byte letter=0; letter<127; letter++){
  if (EEPROM.read(letter)==chordValue){
    char letterChar=char(letter);//would 97 convert to "a"? opposed to 097?
    Keyboard.print(letterChar); 
    isHere=true;
    break;
  }
 }
return isHere
}

let me know if that looks wrong, I cant test it since my program isn’t fully formed yet

checkPROM() needs to be very responsive as its a user input reaction, will the for loop be fast?
whats EEPROM read time like?

I may have forgot to mention that chordValue is the same as intake as mentioned previously
Its named differently now because the raw input from my buttons need to be converted to a byte

I think I solved the potential responsiveness problem

boolean selectiveRead(byte startL, byte endL, byte modifier, byte chordValue)
{
  boolean isHere=false;// needs to return a true response if value is here to prevent guess
  for(byte letter=startL; letter<endL; letter++){
    if (EEPROM.read(letter)==chordValue){
      modifiedL=letter-modifier;
      char letterChar=char(modifiedL);// would 97 covert to "a"? opposed to 097
      Keyboard.print(letterChar);
      isHere=true;
      break;
    }
  }
 return isHere   
}

boolean checkPROM(byte chordValue)// finds chordValue and prints its adress space
{
  boolean isHere=false;// needs to return a true response if value is here to prevent guess
  isHere=selectiveRead(96,123,0,chordValue)//lowercase letters
  if (isHere==true){
    return isHere
  }
  isHere=selectiveRead(32,97,0,chordValue)//uppercase numbers and symbols
  if (isHere==true){
    return isHere
  }
  return isHere 
}

This allows the read to happen by an order of priority.
ie if a lower case letter is found the program immediately resumes, as opposed to needing to go through less used characters
shouldn’t take long to parse 26 possibilities

I think my initial question has been mostly answered, but again if any of this looks wrong please let me know

That’s good, because you completely lost me regarding what you’re trying to do :slight_smile:

Cheers,
John