carletonurocketry / fetcher Goto Github PK

A sensor interface needs to be implemented for the humidity and temperature sensor:
https://www.mouser.ca/datasheet/2/682/Datasheet_SHT4x-3003109.pdf

You can find more information about how the avionics hardware team implemented the board here (including addresses).

Currently fetcher is configured to write only to stdout. It should be possible to pass a command line option to have fetcher write its output to any stream (such as a file or pipe).

Command would look like:

fetcher -o <output_stream>

This will require the modification of how sensor data is printed (to allow writing to any stream using fprintf) as well as the parsing of command line parameters.

Finally, make sure you update fetcher.use to include the new command line option.

The I2C official specification describes that in a 7-bit addressing mode, the 8th bit is used for specifying a read (1) operation or a write (0) operation.

Silly me thought that I had to manually do this by masking the address appropriately (addr & 0xFE) vs (addr | 0x01). This is in fact totally wrong. Behind the scenes, the I2C library will shift the address up 1 bit and then mark the 8th bit appropriately for read/write operations.

Example:

// What I was doing
(0x42 | 0x01) // This becomes 0x43
(0x43 << 1) | 1 // This is what the library does, and it results in 0x87

// What would be correct
0x42 // Leave the address alone
(0x42 << 1) | 1 // The address is dealt with by the library and becomes 0x85

Please remove all the read_addr() and write_addr() macros in all the libraries within fetcher. Let the library handle addresses!

Each sensor board has an EEPROM at address 0x50 which contains a plain-text list of all the sensors on the board and their addresses. This EEPROM should be used to select which sensor drivers to use and which addresses each sensor is located at.

On startup, fetcher will read the EEPROM and initialized based on the listing of sensors.

CUInSpace
SEN-B: 2024-02-04
MS5611 76 77
MAXM10S 42
LSM6DSO32 6B
SHT41 44

This is what the EEPROM contents look like; each sensor on a new line with all of the addresses it occupies (if there is more than one sensor, there is more than one address).

The following I2C GPS sensor needs to have a sensor interface implemented for it:
https://content.u-blox.com/sites/default/files/u-blox-M10-SPG-5.10_InterfaceDescription_UBX-21035062.pdf

You can find more details about how the avionics hardware team implemented it here (including address).

Fetcher should be able to provide information about the time when measurements are taken.

Eventually, there will be a separately powered clock device on I2C which should maintain the correct time even if the Pi onboard loses power.

The system clock should have a sensor interface surrounding it to abstract it in the same way as other I2C devices.

We want to avoid allocating using the heap in case this program needs to be ported to a fully embedded system. However, allocating sensor contexts on the stack can use a lot of stack space since some contexts are quite large. Instead of doing this, a static buffer should be defined called an arena.

As sensors are created/initialized, the space required to store their contexts should be allocated from this arena instead of on the stack. This way we don't have a stack overflow.

Read more about arena allocators here. This article goes very in-depth about memory management.

A sensor interface needs to be provided for the inertial sensor module:
https://www.st.com/resource/en/datasheet/lsm6dso32.pdf

You can find more information about how the avionics hardware team implemented the board here (including addresses).