As a follow-up to Adam’s posts on getting SPI working on the Orangutan’s ISP port (THANKS, ADAM!) I figured I’d ask about the X2.
Far as I can tell the pins for the hardware I2C port are tied up. For SPI, the onboard ATmega168 is using the 644’s hardware SPI port for communication. I remember seeing somewhere else that the 168’s !SS line is tied low to make it active all the time. (I haven’t checked the schematic on this, so if I’m dead wrong, bear with me.) I’m guessing this also means soldering an ISP header on the bottom of the board wouldn’t let someone use Adam’s method of doing SPI through that header. (Let me know if I’m wrong on this!)
The other way to get at SPI is to use the hardware USART in SPI master mode, but that requires the serial clock be available. TX and RX come out to the general I/O header, but as far as I can tell the serial clock is also tied up by the X2’s LCD.
I’m looking into bit-banged I2C and SPI routines for the X2, but I’d love it if someone could tap me on the shoulder and tell me I don’t have to. (With so much stuff offloaded onto the 168, I’d hate to tie up the 644’s pristine timers to do software SPI routines.)
The mega168 !SS pin is pulled low through a resistor, so you can use it if you want to use SPI for other purposes. Be careful with your other device so that it does not interfere with the mega168 programming the mega644, though.
Part of the reason for making the LCD removable was to make it less of a commitment. If you need the LCD, too, and you really want nothing else on the I2C pins, you could use the LCD in 4-bit interface mode.
Just to double-check: So long as I had !SS for the other device tied to one of the general purpose I/O pins, and hooked into the X2’s ISP header, I should be ok, right? (The device shouldn’t care so long as !SS is held high, so I might need an external pull-up for that, I’m guessing.)
I hadn’t looked at WHICH pins on the LCD were getting the I2C pins. DOH! So the pins for driving it in 4-bit mode aren’t part of that set. That works for me!
Think a similar trick could be used for doing I2C with 8-bit LCD as what Adam did for SPI on the Orangutan? Basically make a breakout board that would plug into the X2 on one end, let the LCD plug in on the other, and bring the I2C pins out? I know that works for SPI because as long as the device’s !SS isn’t pulled low, it really doesn’t care. But I get the feeling the I2C bus would see LCD traffic as noise.
I haven’t actually tried this, but I would expect that an I2C slave device would just ignore signals on the data and clock lines that didn’t match the I2C protocol, just like they ignore communication with other devices on the bus when they haven’t been addressed.
I recently added some information about this to the X2 SPI command documentation, but it sounds like you already have a handle on it. Would it be helpful if I included some X2 I2C info to the documentation, or is figuring that out straightforward from the datasheet and the schematic?
If it’s not too much work, I’d rather see the I2C info added to the docs. Until I asked here, I had the impression doing I2C on the X2 would be difficult at best (losing the LCD) or impossible at worst. Glad I was wrong on both counts! But having that information explicitly in the documentation avoids all confusion on that point.
Here’s another reason I’d add it: A lot of sensors are starting to show up with I2C and/or SPI interfaces on them. Sensors from Devantech, Maxbotix, and a lot of stuff I’ve picked up off Digikey and Mouser work that way. If someone’s planning out a robot and already has their sensors picked out, when it comes to choosing a processor it helps to know that everything they have in-hand can be interfaced with the controller they’re reading about. Even better, it helps to see HOW it will all interface.
Slaves should ignore signals unless they have been addressed.
Though it should be noted that there are several special addresses. esacademy.com/faq/i2c/general/i2cexcep.htm
A series of totally random signals can generate one of this special addresses.
Not only would the LCD signals need to accidentally generate either an I2C device address, or one of the reserved addresses on the SDA line, but it would need to be properly aligned with another signal interpreted as clock pulses on the SCL line. I wouldn’t bet my life on it, but I wouldn’t worry about it either.
If this does somehow turn out to be a problem, maybe with one particular I2C device that freezes up if it recieves noise, and if you’re building a daughter board anyway, you could always throw in a chip full of OR gates, and use a spare IO line to keep your I2C breakout pins high during LCD commands.
