arduino / arduino/ArduinoCore-avr
Unnecessary bloat in EEPROM class
- Dominant language
- C
- Stars
- 1.5k
- Forks
- 1.1k
- PR merge metrics
- No merged PRs in 30d
Description
Every time EEPROM.get or EEPROM.put is called with a different type it expands to another specialized inlined version of these fussy loops:
template< typename T > T &get( int idx, T &t ){
EEPtr e = idx;
uint8_t *ptr = (uint8_t*) &t;
for( int count = sizeof(T) ; count ; --count, ++e ) *ptr++ = *e;
return t;
}
template< typename T > const T &put( int idx, const T &t ){
EEPtr e = idx;
const uint8_t *ptr = (const uint8_t*) &t;
for( int count = sizeof(T) ; count ; --count, ++e ) (*e).update( *ptr++ );
return t;
}
Simpler and more efficient to defer to the universal standard library functions in avr/eeprom.h:
template< typename T > T &get( int idx, T &t ){
eeprom_read_block(&t, (void*)idx, sizeof(T));
return t;
}
template< typename T > const T &put( int idx, const T &t ){
eeprom_update_block(&t, (void*)idx, sizeof(T));
return t;
}
Contributor guide
No contributing guide indexed for this repository
Research direction
Locate the EEPROM class and its get and put methods, then read avr/eeprom.h to confirm the eeprom_read_block and eeprom_update_block interfaces. Replace the duplicated loops with those standard-library calls while preserving the existing return values, then verify EEPROM reads and updates still behave as expected.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- cpp
- Domain
- embedded-iot
- Issue type
- Refactor
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Activity status
- Stale
- Clarity
- Clearly specified
- Newbie friendliness
- 45/100