eadf

Yes, i know it's easy to make a one way conversion. E.g just change the `readBytes()` to look something like: `readBytes(uint8_t devAddr,`**_uint16_t_**`regAddr_, uint8_t length, uint8_t *data,...);` But I'm talking about...

An alternative to the `void* register_address` could be to use C union (if plain old C really is required) ``` typedef union AddressV { uint32_t a32; uint16_t a16; uint8_t a8;...

Think I should mention this while it is on top of my stack: \- I made an experimental, templated, version of i2cdevlib that supports any kind of address lengths https://github.com/lacklustrlabs/i2cdevlib...

One way to deal with this problem is to keep an alternative name pointer inside each MenuComponent. One of this pointers is`const char*`and the other is`const __FlashStringHelper *`, only one...

Being capable of storing 'flash memory' strings side by side with 'dynamic memory' inside MenuComponents will also require the signature or getName() to change. It will need to return the...

Now that #22 (NumericMenuItem) is in the code the 'show log' use case can be solved with a subclass of NumericMenuItem. The value of the menu item can be used...

Hm, I don't think there will be any need for a trigger. To display a log we would only need one single MenuItem, a subclass of NumericMenuItem. Normally it will...

> Some users might want a single MenuItem per log file Yes, that's what I ment. Maybe i should have typed it like this.. "To display **one** log we would...

It's allocated just like any other MenuComponent. In setup() or globally (like in serial_nav.ino). When the NumericMenuItem subclass enters 'edit mode' it will have to query the actual log to...

Yeah, the concept breaks down if the number of logs vary. I'm just afraid that dynamic menus will grow the codebase too much. I'm already scavenging for extra bytes (both...