Networking and Communications
For my planned final project ther are a few different networks that I will need to be familar with. The main two are I2C and SPI, and hopefully I will be able to find time to impement a wireless link between the bike and rider sensor boards
The goal for this week as to get a small remote sensor board working to be able to offload the tracking of wheel rotation from the main board. The primary reasons I have for doing this are the sensitivity of the hall effect sensor in the fab inventory is 1.3mV/G and because of the mounting positions I am likely to only have a 7G-10G field which means in the best case I only get a 13mV signal. Since these sensors are going to be mounted quite far away from the main board it makes more sense to put a small MCU with the sensor and then only have to worry about transmitting digial data rather than a small analog signal. Also the sensor needs 5V and I would like to run the main board at 3.3V so I would need a separate ADC in anycase. This way I can just have 3.3V to 5V level conversion on the i2c bus.
I opted to leave the ISP header off the sensor board as I was planning on just using the SOIC 8 test clip for programming. This was quite a pain to get seated properly and needed to be removed to use the i2c bus. So I just opted to solder some wires out to a 2x3 pin header to make the repeated programming easier.
While working on the sensor i2c code I used a bus pirate to interact with the sensor board as this let me manually stimulate the board in a flexible way and gave me a known good working state from the master side of the i2c bus rather than trying to get both sides of the commuication bus working at once.
Getting the I2C bus working using the USI module on the ATTiny45 took a lot more effort than I initially planned. The code from the app note is broken in some subtle ways, there are lots of open source implementations that are lacking for what I wanted in different ways. It was a great learning experience going though the datasheets and not I feel I really understand the I2C bus, rather when I have just used it from a high level library previously.
Main sensor board
Problems with the PDI interface with my AVR programmer waiting on another one that supports PDI to arrive.
Version 2 with 3.3 to 5V level conversion for the I2C bus
Unedited notes... Ignore...
There are serveral communication busses that I need to use for my project. Mainly for communication with periferials. To talk to the SD Card I need to use SPI. The GPS module need UART TTL http://www.adafruit.com/datasheets/GlobalTop-FGPMMOPA6H-Datasheet-V0A.pdf. The IMU can use either SPI or i2c. I would like to use i2c for my own sensors. It would also be nice to have wireless communication between the bike and human components of the system. I quite like the look of the nRF24L Series transivers https://www.nordicsemi.com/eng/Products/2.4GHz-RF https://www.nordicsemi.com/eng/Products/2.4GHz-RF/nRF24L01P From the lecture using sound the network sounded like a neat thing to look into, especially doing MIMO with sound to locate them in space. The https://www.nordicsemi.com/eng/Products/2.4GHz-RF/nRF24LE1 looks really neat for doing sensor networks. Fun things for wired networks, logic analyser and bus pirate Found app note AVR312 which documents using the USI module as a TWI client. The reference code is for IAR studio and doesn't compile off the bat with gcc. In order to understand what is going on better I am going to attempt to translate it into my prefered c style. http://www.atmel.com/Images/doc2560.pdf http://www.atmel.com/images/AVR312.zip https://learn.sparkfun.com/tutorials/i2c https://www.das-labor.org/svn/microcontroller/src-atmel/lib/i2c/trunk/usi-twi_slave/usiTwiSlave.c https://www.das-labor.org/svn/microcontroller/src-atmel/lib/i2c/trunk/usi-twi_slave/ Implementation from das labor doesn't seem to work. After putting the logic analyser on the bus it appears that the clock isn't being released by the twi client. Interesting the implementation of i2c on the bus pirate is incompelete and doesn't support clock stretching. To double check that it wasn't related to pullups I added external pull ups to SDA and SCL but the behaviour still exists. Was tring to run the i2c at 400kHz on a 1MHz clock. I2C special addresses http://www.esacademy.com/en/library/technical-articles-and-documents/miscellaneous/i2c-bus/general-introduction/special-addresses-and-exceptions.html http://www.engbedded.com/fusecalc/ Seemed increasing the clock speed seemed to fix most of the issues, not sure exactly why to fix most of the issues as it was a much bigger delay than that 8 times delay introduced by the clockspeed speed up. left adjust and just reading ADCH to though away the bottom 2 bits.