Observatoire du Prieuré Gradignan
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:
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:
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:
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.
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:
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 à
firstname.lastname@example.org pour toute
question ou remarque concernant ce site Web.