Print PDF
Favorite
Email
Step 8Notes for Geeks
For the true geek who wants to know the details, here are some things to keep in mind if you look at the Atmel Apps Notes and driver code:
- The method of addressing and commanding an I2C device is not part of the spec! Other than the slave address and read/write bit, commands, modes, etc. are not specified and are specific to a given device. To make this very clear, note that the scheme used in the Atmel example only applies to that example, and is pretty much non-standard.
- The USI implementation differs from the TWI implementation in a few important ways.
+ With USI, clocking is provided by software; with TWI it is provided by a Bit Rate Generator.
+ The USI method does not use interrupts; the TWI does. This makes a certain amount of sense since the Mega family (using TWI) could be doing lots of other things and shouldn't be hogged by I2C transfers. An interrupt driven version for USI is certainly possible, it's just not implemented in this Instructable.
+ The USI hardware is not optimized for I2C and can only handle 8 bit transfers. This means that two transfers are required to send the ninth bit (either NACK or ACK). The TWI hardware handles this automatically. This makes the USI driver implementation a little more complicated.
+ Error detection for the TWI is handled in hardware. The USI requires handling in software which complicates things somewhat.
+ The TWI hardware controls the configuration of the port directly. The USI hardware requires that the port bits be configured before the port can be used. You'll see this in the Master_Initialize routine for the USI.
- Atmel claims it's possible to use AVR port pull-ups for the I2C bus pull-ups. I haven't figured out a way to make that approach work. Using two external resistors seems like a pretty simple scheme, so I didn't spend a lot of time on this.
- The method of addressing and commanding an I2C device is not part of the spec! Other than the slave address and read/write bit, commands, modes, etc. are not specified and are specific to a given device. To make this very clear, note that the scheme used in the Atmel example only applies to that example, and is pretty much non-standard.
- The USI implementation differs from the TWI implementation in a few important ways.
+ With USI, clocking is provided by software; with TWI it is provided by a Bit Rate Generator.
+ The USI method does not use interrupts; the TWI does. This makes a certain amount of sense since the Mega family (using TWI) could be doing lots of other things and shouldn't be hogged by I2C transfers. An interrupt driven version for USI is certainly possible, it's just not implemented in this Instructable.
+ The USI hardware is not optimized for I2C and can only handle 8 bit transfers. This means that two transfers are required to send the ninth bit (either NACK or ACK). The TWI hardware handles this automatically. This makes the USI driver implementation a little more complicated.
+ Error detection for the TWI is handled in hardware. The USI requires handling in software which complicates things somewhat.
+ The TWI hardware controls the configuration of the port directly. The USI hardware requires that the port bits be configured before the port can be used. You'll see this in the Master_Initialize routine for the USI.
- Atmel claims it's possible to use AVR port pull-ups for the I2C bus pull-ups. I haven't figured out a way to make that approach work. Using two external resistors seems like a pretty simple scheme, so I didn't spend a lot of time on this.
| « Previous Step | Download PDFView All Steps | Next Step » |
Have you tried setting the pin and then twiddling the DDR instead of the actual pin. ISTR that being the usual way to do open collector-ish lines.