One area that has not had enough development at this point is the ability to read and process the event log and data log EEPROM devices. This will, once the system is fully on-line allow us to display the events and data in a human readable form.
The system writes on a circular buffer basis all significant events to the event log, it also writes all key parameters such as temperature, current, voltage, key systems states, etc. on a 15 second basis.
The events and logs are to be collected by the main Raspberry Pi before they are overwritten the following day. This is because the Pi has far more storage than the Arduino. the Pi has 16Gb of SD card and the option to have another 16Gb+ or so of USB memory stick, whereas the Arduino has only 2 x 128Kb data logging EEPROM's and one 4K event log EEPROM.
During some debugging of the event log and log data, I wanted to see what was going into the EEPROM's and where. Whilst its easy to write another serial debugging command into the serial console on the Arduino, the main human interface will be via the iPad, so it made sense to be able to at least obtain the data from the EEPROM, even if I manually process and dump that data until the main web user interface is available.
As all the storage is on the I2C bus, it can be accessed by either the Pi or the Arduino, either can assume the role of bus master. The Pi can even address the Arduino as its slave, but not vice-versa due to limitations in the Pi firmware.
The Raspberry Pi has the standard I2C tools of i2cdetect and i2cget and i2cset, however when attempting to access the data within the EEPROM, it was not possible to get the data in the logical manner that the EEPROM uses. The I2C protocol does not easily allow larger devices to be handled, 64k is the maximum. To work around this, Microchip have implemented the 128K device as two 64K devices at the address of the chip and the address+4.
We needed a way to read, write, verify and test the EEPRROM devices. Luckily, I have some history in the testing of memory devices and this would be helpful now. After some digging around, I didn't find anything that does what I need, so I decided to write my one. This is called i2ceeprom and its available on GitHub.
The tool allows you to read a device on the I2C bus to a file, write a file to an I2C device, verify a file to a device, test an I2C device with some basic diagnostic test patterns). You can also set the page size to ensure the lowest processing time for the operation and to reduce in necessary wear on the chip with extra writes. You need to be careful however, since this tool can use a lot of the very limited I2C bus bandwidth, which can cause problems for other devices, if they are chatty, so use with care.
During the creation of this code and whilst using the standard OS I2C utilities (i2cdetect, etc) I found a bug in the Arduino I2C library that will cause the Arduino to either hang or reset he current sketch, this is because if a sketch attempts to perform an I2C event and the bus is busy, it will simply wait for an indefinite time to complete the action. If you are using the watchdog timer (as I am), then this will expire and the microcontroller will be reset by its internal circuitry. At this point, it will hang the I2C bus whilst it boots since the I2C pins are not in the right mode until after the bootloader has exit.
This seems to be a known issue that others have identified. The problem goes back to the following code in the twi.c library that creates and endless loop.
// wait until twi is ready, become master receiver while(TWI_READY != twi_state){ continue; }
Here's a link to the Arduino forums
The code therefore has to be modified to write data, wait for a bit and retry. This is done in my code, but is not performed in the standard Linux I2C libraries.
