feat(hardware): Added a driver to read and write data from the Flex eeprom

[vegano1]

Overview

We need a way to read/write to the eeprom on the carrier board, this python module will let us do that from userspace.

Closes: RET-1346

Property Format
Data is written to the eeprom in the form of serialized property byte string with the following format
prop_id(1b) + data_length(1b) + data(1-253b)

• The prop_id is a 1-byte 1-0xFE value and denotes the unique property being stored: NOTE: 0xFF is invalid
• The data_length is a 1-byte 1-0xFD value and denotes the length of the data
• The data is a 1-253b long hexadecimal value representing some data that corresponds to a prop_id.

Properties
Properties represent some piece of data stored on the eeprom, and are categorized by a prop_id, a data_type, and a value. When we find a valid serialized property byte string, which means we have a bytestring matching our format denoted above where the length byte corresponds to the actual size of the data. We deserialize this bytestring based on the specific prop_id, the type of data that prop_id is associated with, and how long the data should be. We use the data_type to encode/decode the data accordingly and create a Property object with the parsed data type.

API
In order to interact with the eeprom we have the concept of properties, and we use the methods self.property_write and self.property_read to read and write these properties to the eeprom.

The self.property_write method takes a set of property and value tuples Set[Tuple[property_id, Any]]) which are serialized, chunked up, and written to the eeprom. This method returns a set of PropId for the properties that were successfully written to the eeprom.

The self.property_read method takes a set of PropId enums and returns a set of Property objects which represent the eeprom data.

Test Plan

• Make sure we can read/write data to/from the eeprom on the flex

Changelog

• Added eeprom module that lets us read/write data to/from any eeprom device in /sys/bus/i2c/devices

Review requests

• Does this approach make sense?
• Am I missing something?

Risk assessment

Low, flex work

[codecov]

Codecov Report

Merging #12847 (c082230) into edge (cba2f3c) will increase coverage by 0.00%.
The diff coverage is 83.10%.

@@            Coverage Diff             @@
##             edge   #12847      +/-   ##
==========================================
  Coverage   72.34%   72.35%              
==========================================
  Files        1548     2348     +800     
  Lines       50597    64379   +13782     
  Branches     3235     7120    +3885     
==========================================
+ Hits        36606    46580    +9974     
- Misses      13513    16127    +2614     
- Partials      478     1672    +1194     

Flag	Coverage Δ
g-code-testing	96.44% <ø> (ø)
hardware	57.62% <83.10%> (-1.56%)	⬇️
notify-server	89.13% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
...entrons/hardware_control/backends/ot3controller.py	66.50% <ø> (ø)
...pentrons/hardware_control/backends/ot3simulator.py	87.30% <ø> (ø)
...ardware/opentrons_hardware/drivers/eeprom/build.py	0.00% <0.00%> (ø)
...rdware/opentrons_hardware/drivers/gpio/__init__.py	46.77% <37.50%> (-1.38%)	⬇️
hardware/opentrons_hardware/drivers/__init__.py	66.66% <66.66%> (ø)
...ardware/opentrons_hardware/drivers/eeprom/utils.py	85.13% <85.13%> (ø)
...rdware/opentrons_hardware/drivers/eeprom/eeprom.py	92.00% <92.00%> (ø)
...ware/opentrons_hardware/drivers/eeprom/__init__.py	100.00% <100.00%> (ø)
...ardware/opentrons_hardware/drivers/eeprom/types.py	100.00% <100.00%> (ø)

... and 880 files with indirect coverage changes

[sfoster1]

I think if we're doing TLV, we should do TLV all the way. We can drop the start and end tokens, because we have the type, length and value. Require the type to not be 255 and you can't be confused with erased data; then, you can read out size-1 bytes, nice and easy.

[sfoster1]

same?

[sfoster1]

Looks good to me!