Q: I can't get my PIC running as an I2C slave. Why?
This topic has driven many engineers to distraction. One colleague took over a project where the original designers had given up in despair and kludged together some 4-bit wide bus communication system.
There's a major bug in the documentation. I read it and realised there was no way for it to properly handle the Acknowledge bit of I2C messages. I pestered the distributor's tech support crew, who were totally clueless, and eventually spoke to someone at the chip fabrication plant in the USA. There's one bit in the SSP registers that is documented as the R/W flag for the message. It certainly is valid for the address byte reception, but for incoming bytes after that, it flags the ACK or NACK bit.
What you have to do is to copy the R/W flag somewhere safe to remember the message direction for the next poll or interrupt, and remember to use the flag for its ACK/NACK purpose on later bytes.
The PIC's I2C slave interface is very unfriendly. If you don't use it just right, it can lock up in a fault state. It sets a bit to flag the error condition, but I couldn't see anyway of clearing the condition. I talked to Microchip USA again and they confirmed that this amazingly stupid behaviour is indeed the case!
Q: I need a multi-master, multi-slave I2C system. How hard is this?
It's no walk in the park! I know, I did one! In that project, it was decided (before I started the job) that such a system would be used. They read the I2C spec and saw that it discussed arbitration, collision detection, etc. But although the spec describes how to detect collisions and resolve them, it doesn't tell you what your system should do about them. Nor should it, as this is an application specific detail.
In effect, you have a miniature ethernet-like system. Although it is only small and just travels round inside a single box, it still has all the issues that its larger relation has. If two masters do try to grab the resources of one slave, how will the one that backs off cope with this? Does it sit there trying forever? If not, how many times should it try before giving up? If it ever does have to give up, what should it do? How does it handle the failure? It is essential to ask these questions before commiting to a design. DO NOT sweep it under the carpet for later - by that time the hardware may be too far advanced or expensive to change!
Just as having the RS232 specification does not mean you have a TCP/IP data transfer protocol stack, it is equally true that having the I2C spec does not mean you have a multi-master network of microcontrollers. Thrashing out a practical network protocol requires careful thought about the data packet structure. I would suggest that a good structure would be to have the slave address (obligatory in the I2C spec) followed by the master's address (so the slave can see who is talking to it - it may need to ignore some masters), a message type identifier byte (what kind of data packet it is), a payload size byte (so the master can see how much data there is too read), followed by the data bytes themselves.
Q: What bit rates can I get from the I2C?
The I2C specification allows up to 100 kbits/second, but in practice you probably won't achieve this. Firstly, the slave interface hardware can handle incoming bits at this rate but it will assert a wait state while your PIC CPU comes to read the byte form the SSP and act upon it. Secondly, the PIC has to bit-bash I2C master data bits out of the PIC. I wrote assembly code as tight as I could, but even so I could see by looking at the scope trace that the bits were not as tightly packed as the bits from an I2C master that was hardware-driven (by an Hitachi H8).
Q: What other problems has the PIC?
It was only designed to address a small (2K word) address space and small (128 byte) register space. Therefore when your code overflows the 2K program space and you have to move from say a 16C64 to a 16C65, you have to go though all your carefully debugged code making sure it has the correct page management instructions. During which time your superiors will be saying things like "but you said it was working okay yesterday!" and thinking your code has collapse due to shoddy programming!
A good tip: start off from day one writing your code with page management and a >2K chip, and then if you eventually find your code using less than 2K you can easily remove the page management instructions. It is not easy or quick to put page management in.
Q: What about compilers?
They are woefully inadequate. One salesman sold a young workmate a £100 C compiler for the PIC, and said it produced more efficient code than hand assembly. This raised my eyebrow, but £100 is very cheap. Unsurprisingly, I put some code through it and it was appalling inefficient despite my best hints to the compiler. I suppose the salesman had his fingers crossed and was thinking "hand assembled... by insane baboons or salesmen". Not that there is much difference IMHO. The C compiler is okay if you want some code quick and you are not pushed for code space, but in real commercial projects you generally are!
Q: How can I speed up the development cycle?
The hardware emulators are only about £600. Cheap, as emulators go. A Hitachi H8 emulator costs around £5000, and so do most emulators.
Q: What about in-site programming?
This is desirable but it isn't as simple as making sure the programming pins are available at test points (as one of my ex-colleagues assumed). The PIC has to be powered up, and thus the circuitry it attaches to will also be powered. You have to make sure at the design stage that programming pins won't be driven as inputs by your application circuit, and that programming pins used as outputs don't cause application circuitry to do anything damaging.
In site programming is handy for production, but it won't allow field upgrades if you don't have in-site erasability. Most PICs use EPROM process technology, and the PICs with quartz windows are too expensive for production use. So it is best to have the PIC socketed where it can be removed and fitted without too much mechanical disassembly. This saves time and therefore cost of upgrades.
Some of the newer larger PICs have Flash ROM, which is great if your application warrants them. Atmel specialise in Flash ROM, so their micros controllers have it across the range.
Q: Is there a standard in-circuit serial programming connector pinout?
No. A 2x5 pin bergstick is most convenient to me, because
cabling is easy to make.
Fortunately there is one used by Microprocessor
Engineering Labs EPIC programmer.
Available from Mecanique
in the UK.
It costs about £50 for the parallel port version, or £60 for
the serial port version (excl. VAT).
Both come with software.
Q: What tools are there?
Microchip's MPLAB is about 32 Mbytes of zip file, producing about 75 Mbytes of files.