Go Down

Topic: isolating a digit (Read 4185 times) previous topic - next topic


If it's under your control, I suggest you rethink the way you encode those button states into an integer. Using bit masks or bit fields would make it much simpler and cleaner, and you could simply extract each set of bits representing the state of a given input and pass it to some common code to work out what to do with it, applying your fallback logic to treat a 'hold' as a 'press' etc where that was sensible. A 32-bit int would be sufficient to support eight inputs with four bits each which seems to be more than you need, and is very handily fits a hex output format with one hex character per input which help with debugging/logging.

Paul Beaudet

The suggestion the encoding blows is something I agree with. However it does add a degree of complexity having the chords be represented by 32 bits vs 16 because these values are actively be drawn from and assigned in eeprom. I guess I'm just not sure how chop a long into bytes and reassemble them again.

I did show a preset layout in progmem here, but that is just to get by and doing testing on things other then the currently buggy learning algorithm. Like for instance this noise filter. In the ultimate designed working state of the device the layout is somewhat fluid, 'learning the user' initially and reassigning itself given common error making eeprom essential. 

I will do some research on bit mask and bit fields though, thank you for the reference, Peter. 

Go Up