For starters, get a test working outside of the library. I've been carefully reading the datasheet and I think we need to follow this sequence:
Write 0xa0 0x03 - this enables the chip
Write 0xb4 to set the register to read from to 0x14 (CDATA low byte)
Wait at least 2.4 ms for the chip to finish powering on
Do the following in a loop
Wait 2.4 ms plus the integration time (default 2.4 ms) for a new value to be produced
Read 8 bytes from the device for all the channels
Note that I don't think we need to resend the command byte setting the address to 0x14 each time we read from the chip; the datasheet says that it will always use the address specified in the last command byte, not the address of the last byte read.
Further note that the resolution of the data we read back will be limited by the integration time. At an integration time of 2.4 ms (the smallest, and the default) the max value will be 1024.
After getting the test code working, generalize it to a library. See the motors library for guidance if necessary.
[x] Kept in a file lib/platform/sensor.c
[ ] List public functions in lib/platform.h
[x] platform_sensor_get_data to obtain the latest data.
[ ] More functions might be good, such as setting integration time or the gain.
[ ] List the functions private to the platform library in lib/platform/sensor.h
[x] sensor_tick to be called in the systick handler; this will read data from the sensor (rate limit this based on the integration time - reading 8 bytes over I2C already takes nearly a whole millisecond) and keep it somewhere to be e.g. returned by platform_sensor_value.
[x] sensor_init to be called by platform_init (in lib/platform/init.c) for the code corresponding to the first two bullet points above.
This is just a rough outline and will probably evolve as it's being implemented.
I've been reading through Adafruit's library for the RGB sensor. Some interesting insights I've come across are:
Light sources like fluorescent bulbs have a frequency; too fast for the human eye, but at the speed of the sensor it affects the colours it reads. This may be causing the ramping values Markus pointed out to me on Thursday
The reason the colours we've been getting don't look like the one's we're expecting may be because we haven't been doing things like gamma correction. I've found an article which I think explains it well: https://www.cambridgeincolour.com/tutorials/gamma-correction.htm. The Python from Adafruit does seem to do something about this though, so maybe not.
For starters, get a test working outside of the library. I've been carefully reading the datasheet and I think we need to follow this sequence:
Note that I don't think we need to resend the command byte setting the address to 0x14 each time we read from the chip; the datasheet says that it will always use the address specified in the last command byte, not the address of the last byte read.
Further note that the resolution of the data we read back will be limited by the integration time. At an integration time of 2.4 ms (the smallest, and the default) the max value will be 1024.
After getting the test code working, generalize it to a library. See the motors library for guidance if necessary.
platform_sensor_get_data
to obtain the latest data.sensor_tick
to be called in the systick handler; this will read data from the sensor (rate limit this based on the integration time - reading 8 bytes over I2C already takes nearly a whole millisecond) and keep it somewhere to be e.g. returned byplatform_sensor_value
.sensor_init
to be called by platform_init (in lib/platform/init.c) for the code corresponding to the first two bullet points above.This is just a rough outline and will probably evolve as it's being implemented.