Observatoire du Prieuré Gradignan

Prolegomena

The i2c bus invented by Philips is a simple and elegant way to have electronics systems (integrated circuits, modules, etc) talk together and cooperate .

At any one time, one item on the bus is the "master", and this master talks to one or more "slaves"; the master generates the clock and controls the timing of reads and writes.

Many useful chips, such as boolean I/O interfaces, analog to digital converters and many other functions are being produced and can be added nearly at will to the bus architecture.

Very often there is one master and a few such slaves on the bus, and the master is a microcontroller. Most microcontrollers now have specialized pins that are devoted to the i2c bus signals SDA (data) and SCL (clock),  and the compilers used to program them have instructions or "macros" that make it easy to control slaves through the bus.

As an example, the basic compiler I use to program Pics, Melab's PicBasic Pro, has the following instructions for sending or receiving data from a slave:

• I2CREAD
• I2CWRITE

These functions are easy to use and also powerful, but their use is limited to the situation where the Pic is a master.

Why would a Pic behave as an i2c slave?

There is more than one answer to this question:

• If one want to link two different microcontrollers with an i2C bus, then obviously one of them must behave as a master and the other as a slave.

• If one wants to implement a special function for which no i2C chip exists, a good idea is to use a microcontroller to this end: complex logics are easy to implement using one; obviously again, this microcontroller will have to behave as an i2c slave.

• if one wants to control a microcontroller in a simple way from a PC, and since a PC has no built-in i2c bus, the best thing to do is to "synthesize" one using the printer port; for various  reasons, the PC will be a master so the Pic will have to be a slave...

The Quest

The switching power supply I have designed and of which 75 were distributed in the last year has the capability to shelter an Ethernet to Parallel port interface called Ethernaude that has been designed by an other team. This I/F allows control of the telescope, the CCD camera, and the AlAudine NT power supply itself.

Ethernaude uses a SX52 fast microcontroller and supplies an i2c bus; In order for AlAudine to be controlled by Ethernaude via this i2c bus it was necessary for me to program i2c slave routines in my existing power supply control software which has been running flawlessly for over a year now.

So I had to read thoroughly the PIC 16F87x and 18Fx52 datasheets in order to understand how the hardware for serial communications (i2c, SPI) that has been compiled into the silicium for these chips work; i searched the internet for the "savoir faire" that is necessary to implement the necessary routines, knowing that I had to run under interruptions.

I quickly found what follows:

It is my experience that nearly everything can be found on the internet if you look for it hard enough and long enough; playing with search engines is an art that I fully master.

However, I must say that no example code is (or was) available so far that would allow a beginner (I mean someone without experience in that precise sub-field of microcontrollers programming) to build  a working and testable application, even a basic "do nothing" one.; by "working" I specifically mean "reliably working in a way that can be repeated"; more specifically, what can be found does not work (more on this later).

This is true even for examples such as the one here, even if it is proposed by the firm that makes the compiler and looks simple; there are others, I could compile a full list.

Also, it is notable that keyword searches unveil a lot of messages in various forii and mailing lists where a lot of people have searched for the very same know-how I have seeked.

Some very interesting messages explain that Microchip never made a priority of i2c (SPI is better supported apparently); also some silicium revisions have been plagued by bugs and glitches, as the available errata information confirms; one message on the "Piclist" makes a reference to the Microchip application not AN734, saying, in a non-explicit way that it is in error at some point (see below)

Basically, all the available information (including examples mentionned above) on how to use the Pic's "MSSP" hardware either in the "polled" or" interrupts" modes is a variation on the theme of Microchip Application Note AN734 in one of its avatars (AN734, AN734a), the last one being available here.

I began my search in may 2003 and worked on it for a few evenings (this is a hobby) until I had to work on something else. I restarted this activity at the beginning of december 2003 and began testing various software prototypes, some closely related to the "state machine" described by AN734, which in "interrupt mode" (i.e. there is an interrupt for each byte in an exchange, be it a read or a write), some working in "polled mode", where all necessary byte exchanges are done in a single subroutine.

All my attempts lead to the conclusion that my routines "basically worked" (though it seems to be a paradox, I was able to implement the whole logics pertaining to my rather big application and make sure it was fully debugged, which it is) , but it did not work reliably, and I had no idea why, no intuition. I even built a second i2c adapter because I wondered whether the Ethernaude adapter software had a bug; also I had no control on its speed and monitoring signals on a cheap oscilloscope was close to impractical.

The Realm

I finally requested help on the internet, both on the PicBasic mailing list hosted by Crownhill and also on the Piclist. I explained what my problem was, and requested (the term is important, as you will see) help.

This was the right thing to do, since it finally lead me (after a number of days and many messages)  to the solution of the problem. Anwers came, and they ranged from very nice (the most frequent case indeed) to agressive and insulting (from one individual who appears to be a pathologic multi recidivist of such deeds).

I want to express my gratitude to the following persons, that have been nice with me and sincerely -sometimes efficiently- tried to help me; their names are sorted in the order of appearance on stage, as seen from my email program; they are:

Gordon Hardman, Dennis Saputelli, Ron Mistaki, Paul James E.,  Richard Kendrick, Alan B. Pearce, Russell McMahon, Bob Axtell, Bob Blick, Martin Bühler, Michael Rigby-Jones, Jan-Erik Soderholm, John N. Power, Josh Koffman. I hope I forgot noone!

Alan B. Pearce sent me some code that allowed me to finally find out where the error was (previous information on the existence of the error did not allow to determine where a fix was in order) and what the correction was.

 In fact Alan did what I had requested since the beginning, i.e he sent me some example code he wrote that had the necessary correction in it; this allowed me to modify some of my previous ill-working code and have it work reliably AT LAST! ; it also confirmed that I had done the right thing when I specifically asked for help in the form of a true and tested example of an i2c slave; other people had given me allusive information that make a lot of sense now that I know what the problem was, but did not at the time it was presented to me.

Bob Blick and Martin Bülher sent me code that was said to work (and may be did at times) but, being directly derived from AN734 it had the error, so like me they were "victims" of AN734.

John N. Power pointed me at some interesting application note information; Josh Koffman and Paul James E. pointed me at the Square 1 book on Pic communications. I have ordered it.

Microchip Application Note AN734

Microchip application note AN734 has errors

Though it has had two versions, Microchip application note AN734 still has errors

Ironically , the current version (AN734a, 2002) is said to be "preliminary"

Sure thing, the example code in such an application note is not ment to be used as "copy and paste"  information: its role is rather pedagogic; as such, it should keep things simple, but IT SHOULD IN NO WAY BE MISLEADING, even for the sake of pedagogic efficiency, concision and  simplicity.

In fact AN734 IS MISLEADING IN MORE THAN ONE WAY:

• It has an error that makes the code completely unusable: the error is a missing instruction in state 5 whose role is to set the clock signal (CKP = 1).

 

• The code comments are misleading because they do not explain readily (nor does the accompanying text) what that state is and what should be done about it (namely one should add the CKP = 1 instruction, something I admit I still do not understand fully now)..

 

• The error processing code (or absence thereof since it is a "loop forever" trap) is misleading because it makes believe that if you get there, your only choice in life is to reset the processor, which is stupid and bad practice.

Since I program in PicBasic Pro, I have done two things:

I have translated the AN734 routines to the Basic language, and fully corrected the errors: they can be found in file I2cInt.pbp.

I have included some instructions in this file that test  whether the 3-bytes receive buffer is full, and if so, process the command (first byte) and parameters (second and third byte), then update the two bytes  that the master will read from the slave as an answer to the command; please note that in my power supply many commands do not need an answer, however I have decided  that all the exchanges would have this 3 + 2 bytes fixed format.

The actual processing takes place in file proc_i2c.pbp and could be replaced by your personnal code.

A last word: i2cInt contains an initialisation routine to be called at the beginning of your application's main code, and the ISR handler itself; in the main code, this handler is called from either Timothy Box's "Fast Interrupt Routines" if you use a 16F87x microcontroller, or from Darrel Taylor's equivalent routines for a 18Fx52 chip. These routines allow immediate reaction to interrupts, whereas PicBasic Pro's software interrupts have a latency that would preclude any use of a Pic as an i2c slave.

 These files may be downloaded from this page

Envoyez un courrier électronique à robert.soubie@free.fr pour toute question ou remarque concernant ce site Web.
copyright © 2001-2010 robert soubie ; dernière modification le 30 janvier 2010 00:08