On Tue, Nov 5, 2013 at 3:53 PM, Derek dlahouss@mtu.edu wrote:
Aaron J. Seigo <aseigo <at> kde.org> writes:
a) must be writable [reasons] ergo, (a) is not an option.
b) must not be writable that is a horrible precedence to set in the very first revision of the spec.
c) may be writable, but portable software may not rely on this [reasons] I highly recommend (c)
Would it be so horrible to say something like "must provide physical pads to be shorted or a switch" (or some suitable technical term) to allow the end-user to remove the "write-protect" status of the EEPROM?
agreeing with aaron (read in advance) - "must" is too strong for the standard. it's enough that end-user applications (including linux kernel) have to treat the EEPROM as read-only but that factories and "upgrade" programs have their own vendor-specific EEPROM-upgrading procedures... .... where "engineering boards" *happen* to fall into that same EEPROM-is-writeable category
Are there any examples of software that store values in EEPROM?
it's usually in the ARM/embedded world.
MAC IDs for ethernet.
l.