> It seems that the UART will work independently of the so-called > MSSP module. Yup. > Within the MSSP you can use i2c or 4-wire, but > not both. So I am going to enlist the magic (meaning firmware > sequencer) of i2c, and bit-bang the 4-wire off another port. This means your "4-wire" needs to be SPI. My initial reaction would be to do the IIC in software and the SPI using the MSSP module, but there should be nothing wrong with doing it the other way around. My preference for software IIC is because it seems simpler, and devices that talk SPI generally do so because they want a little more speed. I've done software IIC a few times, and it's pretty straight forward. > The baud rate for i2c is set by writing a number to SSPADD. Even > though i2c claims a very few specific rates, this seems to allow > any baud rate you want. What's not clear is what the clock source > is (I'm assuming the processor clock or the pclock divided by some > small number like 4, 16, or 64. A scope should help answer this > one.) What's also not clear is if this baud clock is separate > from the one driving the UART. It would almost have to be, to make > any sense, but for some reason I don't like to trust the chip > makers sight-unseen. :) The docs don't make much effort to > differentiate between their BRG (SPBRG) and our BRG (no special name). Yes, the two baud rate generators are completely separate. In IIC, the master always controls the clock. IIC is defined right down to static operation, so the clock can go as slow as you want and is limited on the other end by min/max high/low times and setup/hold requirements. The bus itself has a maximum slew rate because of the passive pullups. In practise, 400KHz is usually fine. > "Control of the I2C bus may be taken when bit P (SSPSTAT<4>) is set, or > the bus is idle with both the S and P bits clear. " > > So if P is set the bus is idle? Does P "go away" if someone else > starts transmitting? If P is clear and S is clear at the same time > then the bus may also be idle, but only if the bus is idle...go read > it again...Here I would feel better hearing from somebody who has > actually thrashed this one through. A lot of this complexity in the docs is because you could be using a multi-master configuration. Lots of stuff gets simpler when you have only the one master. In that case you have to do a START at the beginning of the message, and a STOP at the end. You don't have to worry about the bus being idle or not, because you are the only possible cause of it not being idle. Note that slaves can extend a bit and "hang" the bus indefinitely during read (slave to master), but in that case you master code will still know it is in the middle of a message. ***************************************************************** Olin Lathrop, embedded systems consultant in Devens Massachusetts (978) 772-3129, olin@cognivis.com, http://www.cognivis.com -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.