Exact match. Not showing close matches.
'[PIC] PIC32 and i2c project'
The "project" is to have one PIC32 talking to another over i2c. Something I
have done many times over the years. The "new thing" is the PIC32
hardware. As usual, I'm not sure where to post, since the intersection of
knowledgeable people, PIC32, and i2c is pretty small. But I like you guys
the most. And this will probably end up as documentation, more than help.
A "project" or "adventure" is usually a clear idea of steps to take, with
the expectation that it will take a few days; but then insert some problems
or issues, and each of those will take a day (or more) in itself.
A word about the PIC32 i2c engine. They have a Master and a Slave, both of
which operate simultaneously. On the same pair of pins (thus, on the same
bus). This could be construed as a feature. For one thing, you can write
master and slave code and do all your testing without having to wire up
anything (except two pullup resistors). It has some interesting
implications if you get involved with multi-master devices, and want to try
making a device that can be a master and a slave at the same time. The
downside is that you cannot turn off one side or the other, and if you have
a problem, you can't separate the blame by disconnecting the suspect side.
The first adventure went like this: I worked up some master code (always
easier) that would poll all the addresses from 0x10 to 0xEE. This is
tradition, and it's a very valuable exercise. "Polling" means you send a
start, an address, get the ack, and then stop. No data is sent, and the ACK
tells you if there is anything at that address. So far, so good. Now I
start to work on the slave. Getting an interrupt routine to execute is an
adventure in itself, and not part of this discussion. Let's just say I got
that to happen.
The problem then was, I would get one interrupt (when the slave saw its
address) and then nothing afterward.
I enabled the "bus collision" interrupt. I also examined the error bits.
No answers appeared.
The only clue that I had was that after halting the program (to look at
registers), and then hitting continue, it would then receive one more
interrupt before disappearing again. (Disappearing = not ACKing its
address). In the old days, this meant "R/M/W bug". Good guess, but not
this time. The other thing that it means is "When you stop, you read all
Turns out, I have to read the "received byte". Remember I said no data was
- Even though it's just an "address match", the 8 bits from that address
byte went into the I2C_RCV register.
- This also sets BF (buffer full).
- The slave hardware refuses to do anything else until you read that
--Even after successive attempts to address that slave:
- No collision errors are set, and no collision interrupts are generated.
- The I2COV (overflow) bit never sets.
- The reception of a STOP does not clear the character, reset BF, or free
up the slave in any way.
The solution is as simple as making sure to check BF and read whatever got
received, but getting there was tricky. I also surmise that this "poll"
packet is not usually thought of, considered, or otherwise documented. It
is real, though. This is, for example, how you're supposed to determine
that an EEPROM is done writing.
I have to go work on the current problem...
Barry Gershenfeld wrote:
> The problem then was, I would get one interrupt (when the slave saw
> its address) and then nothing afterward.
What did you expect? You only addressed the slave once, so got one
> Turns out, I have to read the "received byte".
Of course, especially with slaves that do clock stretching. How else would
the hardware know you got it and it was OK to proceed? I'm pretty sure
other IIC implementations work similarly, although I often do IIC in
firmware. It's one of the first things to give up in hardware if you need
the dedicated pins for something else. If I remember right, your PIC has
remappable pins, so that's less of a issue.
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014. Gold level PIC consultants since 2000.
|On Sat, Jul 10, 2010 at 4:55 AM, Olin Lathrop <embedinc.com>wrote:olin_piclist
> Barry Gershenfeld wrote:
> > The problem then was, I would get one interrupt (when the slave saw
> > its address) and then nothing afterward.
> What did you expect? You only addressed the slave once, so got one
I wasn't clear on this, but the scanning cycle was set up to repeat itself
after 100 ms. So the slave got addressed periodically. I expected
"something"; either another interrupt, or an error indication.
> > Turns out, I have to read the "received byte".
> Of course, especially with slaves that do clock stretching. How else would
> the hardware know you got it and it was OK to proceed?
Clock stretching is intended for data reads only. But this was a poll. The
only exchange of practical information that happens is, the master sees an
ACK, revealing the presence of a device at that address.
I'm pretty sure
> other IIC implementations work similarly, although I often do IIC in
> firmware. It's one of the first things to give up in hardware if you need
> the dedicated pins for something else. If I remember right, your PIC has
> remappable pins, so that's less of a issue.
We have been bit-banging IIC all along (via the CCS compiler or by my own
hand). But when you want a PIC as a slave, then the hardware engine makes
the most sense. (Studiously avoiding saying "required" but probably close
enough in an application that has the slave plus other things to do.)
More... (looser matching)
- Last day of these posts
- In 2010
, 2011 only
- New search...