project: PILE1
the base devboard was chosen as it exposes a generous amount of IO, has ethernet fitted and its MCU has a huge amount of SRAM.
it will probably be the machine that fragmented IP packets are developed on
PILE1 is constructed using polycarbonate and matrix PCB held together with standoffs
blog
electronically it all seems reasonable but there have been some issues with the existing i2c and sensor drivers as used in SLAB1, these are:
the I2C mcs register does not always assert the busy flag fast enough to not miss when waited on, leading to missed errors
the environment sensor was either never polled particularly fast on SLAB1 or read errors were ignored; this led to a hang in reads on the PILE1 test code
a sequence of failed I2C repeated start were observed, this is either because of a (potentially long standing) driver issue or a misunderstanding. old pull requests and issues relating to the tivaC_I2C driver did not make any mention of repeated start not working; in fact there was an issue with a lack of stop conditions leading to everything being a repeated start, this makes it more likely that this is a bad oobservation where there was some other behaviour involved...
the environment sensor output revealed a humidity of around 70% which matched the humidity on the day((taken from the met office) this test was performed many times on different days and was always within reasonable bounds of error
the ethernet driver so far initialises using the internel PHY and can read and write packets; these are not error checked.
multicast and broadcast RX currently read the correct packet lengths and the data looks ok. unicast RX is untested.
TX writes the correct data which has been verified in wireshark
a QSSI driver has been written that implements legacy SPI
two SD cards have been connected and function correctly
as with SLAB1, environment is imported from /mnt/SD0p0/env unless SW1 is held during boot