Searching \ for '[PIC:] Pic as an i2c slave' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/i2cs.htm?key=i2c
Search entire site for: 'Pic as an i2c slave'.

Exact match. Not showing close matches.
PICList Thread
'[PIC:] Pic as an i2c slave'
2004\01\05@165410 by Robert Soubie

flavicon
face
Happy new year, Bonne année nouvelle,

Has anyone written a working (tested and testable)
application programmed either in asm, Basic or C where the
PIC would be used as an i2c slave?

Despite much reading and testing in numerous attempts and
some partial positive results, I am unable to have my own
application work reliably;
Specifically some calls from the master, a PC using two
different i2C interfaces, are not "seen"; I do not have the
least idea of why...

I program in Basic and use interrupt routines on a 16F876
that save compiler's internal variables, and I have
explored, with no great success, the two main routes,
i.e. either all exchanges are processed in the same routine
starting at the first interrupt occurence (receiving a
command byte and two parameters, processing then resending
two result bytes) or as an alternatively I have implemented
a state machine as per AN734x.

The processing logics have been tested for all the
occurences where the interrupts are "seen" and processed,
i.e. 3 out of four times; they work ok.
Thanks in advance for any help, for I do not know what to
try next... I know I am looking for something that is far
for obvious, as the paucity of information on the net
testifies...

* spam_OUTXrobert.soubieTakeThisOuTspamfree.frX (veuillez supprimer les "X")
* http://www.astrosurf.com/soubie
* Au royaume des aveugles, les borgnes sont mal vus... - P.Dac

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email .....listservKILLspamspam@spam@mitvma.mit.edu with SET PICList DIGEST in the body

2004\01\05@170908 by Paul James E.

picon face
Robert,

I have setup a PIC as an I2C Slave and as an I2C Master several times.
They have all been very reliable, but unfortunately, I can't share the
code with you because they were written for my employer.  I wrote all of
my routines in Assembler, but I think I could follow BASIC too. I would  be willing to go over your problems with you and possibly offer some
suggestions, if this would be helpful?   Let me know.

                                            Regards,

                                              Jim


{Quote hidden}

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email EraseMElistservspam_OUTspamTakeThisOuTmitvma.mit.edu with SET PICList DIGEST in the body

2004\01\05@172527 by Olin Lathrop

face picon face
Robert Soubie wrote:
> Has anyone written a working (tested and testable)
> application programmed either in asm, Basic or C where the
> PIC would be used as an i2c slave?

Yes, several times.

> Specifically some calls from the master, a PC using two
> different i2C interfaces, are not "seen"; I do not have the
> least idea of why...

Then find out why.  Put the master (the PC apparently) into a loop send the
address byte of the slave that is not responding.  Look at the result on a
scope.  Since it should be just a start, address byte, NACK, and stop, it
should fit nicely on one screen with one trace showing the clock and the
other the data.  Does everything look right?  This will differentiate the
problem to the PC or the PIC.  Particularly make sure the address is right,
proper timing is observed, etc.

> I program in Basic

Any further help is a waste of time until you get the compiler out from
between you and the hardware.  It's tough enough trying to remotely debug
somebody's setup without added uncertainty about what some bugware compiler
is doing.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listservspamspam_OUTmitvma.mit.edu with SET PICList DIGEST in the body

2004\01\05@180232 by Robert Soubie

flavicon
face
On Mon, 5 Jan 2004 17:23:15 -0500, Olin Lathrop wrote on Re:
[PIC:] Pic as an i2c slave:

>Robert Soubie wrote:
>> Has anyone written a working (tested and testable)
>> application programmed either in asm, Basic or C where the
>> PIC would be used as an i2c slave?
>
>Yes, several times.
>
>> Specifically some calls from the master, a PC using two
>> different i2C interfaces, are not "seen"; I do not have the
>> least idea of why...
>
>Then find out why.  
Thank you for your kind answer: I am not requesting help at
that level, because I have had a full 26 years to debug
microprocessor apps starting with things like 8080, 6800 and
6809.

At the moment I am looking for something really elusive, and
I am specifically searching for a source of inspiration that
would help me discover whether it is me, the compiler and
relevant interrupt routines, the litterature, or the stupid
silicium that is the problem.

So far and with help of an oscilloscope I have been unable
to eliminate any of these four potential culprits (PIC
silicium has had bugs in the MSSP for some revisions and
chips, Microchip documentation has had flaws, Application
notes code my Microchip have bugs etc), but from my
extensive searches in the litterature I have acquired a
strong feeling that I am not the first by far to stumble
over the PIC i2c slave problem: there is simply no working
example in any language available for testing or as a
starting point. You only find people that say "I've beeen
there and it worked" but they don't show code. There has to
be a reason for that paucity, because implementing i2C slave
functions in a PIC is obviously very useful.

The waste of time you are mentionning has been mine for days
and weeks now (in fact I began my search in may then stopped
after a couple of weeks and restarted at the beginning of
december).

This is why I am seeking here a higher and hopefully
friendlier level of help, in the form of working, true and
tested example code.

No less.

Please pardon my bad english, thanks in advance and bonne
année 2004!

* @spam@Xrobert.soubieKILLspamspamfree.frX (veuillez supprimer les "X")
* http://www.astrosurf.com/soubie
* Au royaume des aveugles, les borgnes sont mal vus... - P.Dac

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email KILLspamlistservKILLspamspammitvma.mit.edu with SET PICList DIGEST in the body

2004\01\05@183005 by Richard Kendrick

flavicon
face
Square 1 has downloadable source code in assembly on their web site
supporting their book "Serial Communications" by Roger Stevens. Their
url is http://www.sq-1.com

They have code for I2C master and slave communications using the MSSP
port and bit banged methods.

Usual disclaimer: I don’t work for Square 1 but am a satisfied customer.

{Original Message removed}

2004\01\05@185041 by Olin Lathrop

face picon face
Robert Soubie wrote:
> Thank you for your kind answer: I am not requesting help at
> that level, because I have had a full 26 years to debug
> microprocessor apps starting with things like 8080, 6800 and
> 6809.
>
> At the moment I am looking for something really elusive, and
> I am specifically searching for a source of inspiration that
> would help me discover whether it is me, the compiler and
> relevant interrupt routines, the litterature, or the stupid
> silicium that is the problem.

But that's exactly what the test I recommended would do.  Since you don't
know the answer, it still seems like a useful thing to do.

> So far and with help of an oscilloscope I have been unable
> to eliminate any of these four potential culprits (PIC
> silicium has had bugs in the MSSP for some revisions and
> chips, Microchip documentation has had flaws, Application
> notes code my Microchip have bugs etc),

If you do what I suggested, you will be able to tell whether the IIC bus is
being driven incorrectly, or the correct signals are being interpreted
incorrectly.  That would be a very useful thing to know, as it would
eliminate large chunks of your system from suspicion.

> You only find people that say "I've beeen
> there and it worked" but they don't show code.

OK, how much is such code worth?  I've got plenty of it.

> The waste of time you are mentionning has been mine for days
> and weeks now

If this is a commercial project, then it sounds like a proper solution has
some real worth.  I and several others here could probably give you a fixed
price for a complete solution given a proper specification and verification
procedure.

> This is why I am seeking here a higher and hopefully
> friendlier level of help, in the form of working, true and
> tested example code.
>
> No less.

Oh, I see.  You've got a problem which you've wasted days and weeks on, but
are demanding a free solution for?  How much were those days and weeks
worth?  How much is it worth to have everything just work?  Is the answer to
that really $0?


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email RemoveMElistservTakeThisOuTspammitvma.mit.edu with SET PICList DIGEST in the body

2004\01\05@190325 by Bob Blick

face
flavicon
face
Robert Soubie said:
> Happy new year, Bonne annie nouvelle,
>
> Has anyone written a working (tested and testable)
> application programmed either in asm, Basic or C where the
> PIC would be used as an i2c slave?

Hi Robert,

After reading some of the replies, it never ceases to amaze me what a
bunch of wankers people can sometimes be.

Anyway, happy new year, here's a snippet of C that does work on a 16F876.
It is by no means perfect, just something that was easy to cut and paste,
but it has been tested and does work:

// here's the relevant part of the interrupt routine

void interrupt isr() {

if(SSPIF) {
               SSPIF = 0;
               RB7=1;
               i2cticker++;
               junque = SSPSTAT & 0b00100101;  //only care about DA, RW, BF
               switch(junque) {
                       case 0b00000001:        // write, last byte addr, buffer full
                               RA1=1;
                               i2chaveaddr = 0;
                               if(!SSPBUF)             // node is zero = general call
                                       general_call = 1;
                               break;
                       case 0b00100001:        // write, buffer full, last was data
                               RB6=1;
                               if (i2chaveaddr) {
                                       //FSR = i2caddr;
                                       //INDF = SSPBUF;
                                       *i2caddr = SSPBUF;
                                       i2caddr++;
                               } else {
                                       i2chaveaddr = 1;
                                       i2caddr = (byte *)SSPBUF;
                               }
                               break;
                       case 0b00000100:        // read, last byte addr, buffer empty
                               //FSR = i2caddr;
                               //SSPBUF = INDF;
                               SSPBUF = *i2caddr;
                               CKP = 1;
                               break;
                       case 0b00100100:        // read, last byte data, buffer empty
                               i2caddr++;
                               //FSR = i2caddr;
                               //SSPBUF = INDF;
                               SSPBUF = *i2caddr;
                               CKP = 1;
                               break;
                       default:                // NACK from master or error
                               RA3=1;
                               break;
               }
       }
}


// call this once

void I2cSlaveSetup(byte node) { //I2C setup as slave, insert node address
       SSPCON  = 0b00110110;
       SSPSTAT = 0b00000000;
       //SSPCON2 = 0b01100000; // this is without general call support
       SSPCON2 = 0b11100000;   // bit 7 enables general call support
       SSPADD  = node & 0b11111110;
       SSPIF = 0;              // clear any pending interrupt, enable interrupt
       SSPIE = 1;
}


Cheerful regards,

Bob

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email spamBeGonelistservspamBeGonespammitvma.mit.edu with SET PICList DIGEST in the body

2004\01\05@190738 by Bob Blick

face
flavicon
face
Sorry I forgot to note that all the RA3 = 1, i2cticker++, etc were all
just for diagnostics at the time I wrote it, you can remove them.

-Bob

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email TakeThisOuTlistservEraseMEspamspam_OUTmitvma.mit.edu with SET PICList DIGEST in the body

2004\01\05@195347 by Bob Axtell

face picon face
I have a lot of experience with the PIC in I2C applications, but always when the PIC was the Master, because of timeout issues with the ACK in slave mode, and of course the problem that START and STOP events are difficult to detect; you can't respond fast enough to satisfy a hardware-driven MASTER.

To do this well, the PIC would have to be almost dedicated to ONLY servicing the I2C Master and doing nothing else. And it would still be too slow. While the C873 and F873/876 families have an I2C START/STOP interrupt, it is still too slow for most applications. In a nutshell, Microchip isn't very sold on I2C and has no interest in designing in a
proper I2C engine in the PIC product line.

The BEST way to make the PIC a slave is by using the UART in addressable
mode. This works VERY well; I have several products out with this scheme.

The NEXT best way is to use the SPI channel, as a slave. In this mode, the PIC can decide if the data is for HIM and then respond.

Good luck.

--Bob

Robert Soubie wrote:
{Quote hidden}

--               --------------
               Bob Axtell
       PIC Hardware & Firmware Dev
         http://beam.to/baxtell
             1-520-219-2363

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email EraseMElistservspammitvma.mit.edu with SET PICList DIGEST in the body

2004\01\06@021517 by tin=22?=

picon face
part 1 2371 bytes content-type:text/plain; (decoded quoted-printable)

hi
i once used a 16f872 as i2c slave.
look at the c code attached:
i2chw is the i2c slave code.
iic2lcd is the main code, just to show how routines of i2chw are called.
this approach is based on a microchip application note (assembler) with some modifications.
let me know if this works for you.
tino





>{Original Message removed}
part 2 1491 bytes content-type:application/octet-stream; (decode)

part 3 4824 bytes content-type:application/octet-stream; (decode)

part 4 3008 bytes content-type:application/octet-stream; (decode)

part 5 5183 bytes content-type:application/octet-stream; (decode)

2004\01\06@031653 by Robert Soubie

flavicon
face
On Mon, 5 Jan 2004 18:49:47 -0500, Olin Lathrop wrote on Re:
[PIC:] Pic as an i2c slave:

>> The waste of time you are mentionning has been mine for days
>> and weeks now

>If this is a commercial project, then it sounds like a proper solution has
>some real worth.  
There is nothing confidential in what I am doing, so here
goes: it is a project that I delopped in an
amateur/professionnal astronomer association (600 members in
the world and counting) called Aude
(http://www.astrosurf.com/aude).
We build and use CCD cameras for astronomy; in fact we
invented them, or rather one of our amateur members called
Christian Buil (http://www.astrosurf.com/buil) did eons before
professionnal astronomers even considered using them; he
wrote a book on this (http://www.willbell.com/ccd/ccd4.htm).

Given that the license for building those cameras was free,
our work have given birth to a *for-profit* US firm and
camera system called Genesis, which is basically a clone of
our Audine camera.

It is well known that a ccd camera is more useful when the
sensor's temperature is regulated; also amateur astronomers
are famous for blindly wandering at night in the
countryside, far from any source of energy; so, starting in
1999, I built a range of battery-fed, switching power
supplies that provide, from a single 12VDC source, all
tensions that are necessary for the camera, including a
regulating voltage source for a Peltier module; I have
programmed a PID regulator in a 18F876, using a DS1820
Dallas Semiconductors Onewire sensor that allows better that
0.1 K regulation. From a fully charged battery, one can
image for a full three nights without recharging. Which is
what people needed.

We have also explored the future of CCDing by building an
Ethernet to parallel converter
(http://www.astrosurf.com/ethernaude/) that allows one to
image from a remote location: no PC is required at the
telescope, only a battery and my power supply
(http://www.mecastronic.com/AlAudine_NT.htm) containing an
Ethernaude interface.
As an example, I have in september installed such a
configuration on a telescope that is managed by us on top of
Pic du Midi (http://www.bdl.fr/s2p) in the french Pyrenees
mountains, and requested a friend in Paris to image from his
home through the internet, using the UDP protocol.
A US commercial builder, Santa Barbara Group
(http://www.sbig.com/), sells an equivalent, though less
efficient I/F (http://www.sbig.com/sbwhtmls/ethernet.htm).
Our I/F is available for a slight amount above the price of
construction (see mecastronic link above).

Now why do I need i2c? The Ethernaude I/F uses an SX
microcontroller and has an i2c bus that seems to work (it
works with standard slaves such as PCF8574, and I have
checked that my i2c problems happen either with this I/F or
with a // port I/F I have built, which seems to rule out a
problem on the I/F side).
We need to control my power supply from the Ethernaude I/F
through the I2C bus, knowing that Ethernaude is an i2c
master and this cannot be modified. Also we need to use a
pic, programmed as a slave, as an i2C to RS232 symmetrical
interface that will allow us to remotely control the
telescope through its RS232 own interface.

The fact that for any reason and after much debugging, I
have been so far unable to ***reliably*** operate (basically
it works, it is just not reliable and I do not know why) a
PIC as an i2c slave precludes such goals.

Please note that all of those activities (there are others,
such as managing said telescope (http://www.astrosurf.com/t60), one
of my responsabilities), are strictly performed in a non for
profit context, because our association does not have any
R&D budget (which means that each and every "researcher"
among us pays good euros from his pocket for prototypes
etc).

>I and several others here could probably give you a fixed
>price for a complete solution given a proper specification and verification
>procedure.

I suppose so, and it certainly looks as if you could. There
are also such solutions available around us; none of them we
can afford.
>> This is why I am seeking here a higher and hopefully
>> friendlier level of help, in the form of working, true and
>> tested example code.
>>
>> No less.
>
>Oh, I see.  You've got a problem which you've wasted days and weeks on, but
>are demanding a free solution for?  
Correct. I do not see why anyone should be shocked by such a
request; I have monitored Melabs PicBasic Pro mailing list
for months now, it is full of professionnals that provide
free help to beginners and confirmed people alike, and go to
great extents to this end, including spending time to
actually "prototype" and solve other's problems.
Names that come to mind (this list is not exhaustive by far)
are Melanie Newman, Timothy Box, Darrel Taylor, Bruce
Rentron, Dennis Saputelli, modestly myself, some of them are
present on this list also...
I may have been spoiled, but this is the kind of behaviour I
am prepared to find on this list also. And I can't suppose
people are on this list chasing customers...

>How much were those days and weeks worth?  
They were lost to me; if I had not stumbled, maybe for the
first time in my "enlightened amateur" life <grin>, on
something I cannot solve, I would have put them to better
use in some other projects I (we) have in mind, that require
my competences, such as e.g.:

- GPS-based or otherwise-based datation system for asteroïd
occultations, precise to better that 0.01 second WRT GMT
time (this is a crucial need for amateur and professionnals
alike, nothing available on the market at realistic prices,
which excludes IRIG-B type clocks and such)

- Precision focusing system for telescope with CCD cameras
(there are some on the market that need be improved) .

- 3-axis Motion Control card for "GOTO" telescope control.

- etc.

>How much is it worth to have everything just work?  
Do you live in a world where everything has a commercial
price? Or, as others on the internet do, do you have a
secret "not for profit" garden?

>Is the answer to that really $0?

The answer here is a qualified "Yes". After all Socrates did
not have a commercial stand on the agora...

Thanks for your time reading this.

* RemoveMEXrobert.soubieEraseMEspamEraseMEfree.frX (veuillez supprimer les "X")
* http://www.astrosurf.com/soubie
* Au royaume des aveugles, les borgnes sont mal vus... - P.Dac

--
http://www.piclist.com hint: To leave the PICList
RemoveMEpiclist-unsubscribe-requestspam_OUTspamKILLspammitvma.mit.edu

2004\01\06@034217 by hael Rigby-Jones

picon face
{Quote hidden}

It sounds like you haven't thoroughly investigated the datasheet regarding
the MSSP peripheral.  All the components are provided to provide a high
speed (400kbit/s) I2C slave.

A correctly implemented MASTER device will respond to clock stretching by
the slave, so the time taken to process each byte by the slave should not
matter within reason.  Most bit bashed I2C masters do not implement clock
stretching however.

Regards

Mike




=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================
Any questions about Bookham's E-Mail service should be directed to
RemoveMEpostmasterKILLspamspambookham.com.

--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-requestSTOPspamspamspam_OUTmitvma.mit.edu

2004\01\06@035915 by Robert Soubie

flavicon
face
On Mon, 5 Jan 2004 19:06:44 -0500, Bob Blick wrote on Re:
[PIC:] Pic as an i2c slave:

>Sorry I forgot to note that all the RA3 = 1, i2cticker++, etc were all
>just for diagnostics at the time I wrote it, you can remove them.
>
>-Bob

Thanks indeed Bob for your friendly answer, I'll study this
code carefully in the evening and compare it to my own
implementation of the same state machine, whose origin is
Microchip's AN734 application note in one of its numerous (3
I think) avatars.

My hope (not much of it though given the time I have spent
digging that problem) is to find a discrepancy between yours
and my own code (and microchip's printed example, which is
known not to be working as messages archived on this very
list show).

If I do not find anything significant, then I'll have to
work on the assumption that the routines I use (see below)
have a flaw. Looking at them and at the asm code the
compiler provides, they seem to be correct though... But
this does not prove a thing at my point...

'***********************************************
'*  Name    : INT_CTRL.BAS                     *
'*  Author  : Tim Box                          *
'*  Notice  : Copyright (c) 2002 TJBSYSTEMS    *
'*          : All Rights Reserved              *
'*  Date    : 28-Sep-02                        *
'*  Version : 1.0                              *
'*  Notes   :                                  *
'*          :                                  *
'***********************************************

'***********************************************
'*
'*      Declare variables
'*
'***********************************************




   wsave       VAR BYTE    $20     SYSTEM              ' Save location for the W register if in bank0
   wsave1      VAR BYTE    $A0     SYSTEM              ' Save location for the W register if in bank1
   wsave2      VAR BYTE    $120    SYSTEM              ' Save location for the W register if in bank2
   wsave3      VAR BYTE    $1A0    SYSTEM              ' Save location for the W register if in bank3
   ssave       VAR BYTE    Bank0   SYSTEM              ' Save location for the STATUS register
   psave       VAR BYTE    Bank0   SYSTEM              ' Save location for the PCLATH register
   fsave       VAR BYTE    Bank0   SYSTEM              ' Save location for the FSR register
       ' PBP VARS TO SAVE
   R0_2        var WORD    BANK0                       R1_2        VAR WORD    BANK0
   R2_2        VAR WORD    BANK0
   R3_2        VAR WORD    BANK0
   R4_2        VAR WORD    BANK0
   R5_2        VAR WORD    BANK0
   R6_2        VAR WORD    BANK0
   R7_2        VAR WORD    BANK0
   R8_2        VAR WORD    BANK0
   FLAGS_2     VAR BYTE    BANK0
   GOP_2       VAR BYTE    BANK0
   RM1_2       VAR BYTE    BANK0
   RM2_2       VAR BYTE    BANK0
   RR1_2       VAR BYTE    BANK0
   RR2_2       VAR BYTE    BANK0
   'T1_2        VAR BYTE    BANK0
   'T2_2        VAR BYTE    BANK0        'DEBUG_ADDRESS_2 VAR BYTE    BANK0
   'DEBUG_STACK_2   VAR BYTE    BANK0


   DEFINE INTHAND INT_CODE                             'Tell PBP Where your code starts on an interrupt

   GOTO OVER_INT_CODE

asm
INT_CODE
   IF (CODE_SIZE <= 2)
       movwf   wsave                                   ; copy W to wsave register
       swapf   STATUS,W                                ; swap status reg to be saved into W
       clrf    STATUS                                  ; change to bank 0 regardless of current bank
       movwf   ssave                                   ; save status reg to a bank 0 register
       movf    PCLATH,w                                ; move PCLATH reg to be saved into W reg
       movwf   psave                                   ; save PCLATH reg to a bank 0 register
   EndIF

   movf    FSR,W                                       ; move FSR reg to be saved into W reg
   movwf   fsave                                       ; save FSR reg to a bank 0 register

   MOVF    R0,W
   MOVWF   _R0_2
   MOVF    R0 + 1,W
   MOVWF   _R0_2 + 1         MOVF    R1,W
   MOVWF   _R1_2         MOVF    R1 + 1,W
   MOVWF   _R1_2 + 1

   MOVF    R2,W
   MOVWF   _R2_2     MOVF    R2 + 1,W
   MOVWF   _R2_2 + 1
       MOVF    R3,W
   MOVWF   _R3_2
   MOVF    R3 + 1,W
   MOVWF   _R3_2 + 1
       MOVF    R4,W
   MOVWF   _R4_2
   MOVF    R4 + 1,W
   MOVWF   _R4_2 + 1
       MOVF    R5,W
   MOVWF   _R5_2
   MOVF    R5 + 1,W
   MOVWF   _R5_2 + 1
           MOVF    R6,W
   MOVWF   _R6_2
   MOVF    R6 + 1,W
   MOVWF   _R6_2 + 1            MOVF    R7,W
   MOVWF   _R7_2
   MOVF    R7 + 1 ,W
   MOVWF   _R7_2 + 1         MOVF    R8,W
   MOVWF   _R8_2
   MOVF    R8 + 1 ,W
   MOVWF   _R8_2 + 1             IFDEF   T1
       MOVF    T1,W
       MOVWF   _T1_2        ENDIF
   IFDEF   T2
       MOVF    T2,W
       MOVWF   _T2_2        ENDIF
   IFDEF   FLAGS
       MOVF    FLAGS,W
       MOVWF   _FLAGS_2        ENDIF
   IFDEF   GOP
       MOVF    GOP,W
       MOVWF   _GOP_2        ENDIF
   IFDEF   RM1
       MOVF    RM1,W
       MOVWF   _RM1_2        ENDIF
   IFDEF   RM2
       MOVF    RM2,W
       MOVWF   _RM2_2        ENDIF
   IFDEF   RR1
       MOVF    RR1,W
       MOVWF   _RR1_2        ENDIF
   IFDEF   RR2
       MOVF    RR2,W
       MOVWF   _RR2_2        ENDIF
   IFDEF   DEBUG_ADDRESS
       MOVF    DEBUG_ADDRESS,W
       MOVWF   _DEBUG_ADDRESS_2        ENDIF
   IFDEF   DEBUG_STACK
       MOVF    DEBUG_STACK,W
       MOVWF   _DEBUG_STACK_2        ENDIF
endasm

   goto MY_INT_HANDLER

INT_RETURN:
ASM

   MOVF    _R0_2,W
   MOVWF   R0
   MOVF    _R0_2 + 1,W
   MOVWF   R0 + 1
       MOVF    _R1_2,W
   MOVWF   R1
   MOVF    _R1_2 + 1,W
   MOVWF   R1 + 1
       MOVF    _R2_2,W
   MOVWF   R2
   MOVF    _R2_2 + 1,W
   MOVWF   R2 + 1
       MOVF    _R3_2,W
   MOVWF   R3
   MOVF    _R3_2 + 1,W
   MOVWF   R3 + 1
       MOVF    _R4_2,W
   MOVWF   R4
   MOVF    _R4_2 + 1,W
   MOVWF   R4 + 1
       MOVF    _R5_2,W
   MOVWF   R5
   MOVF    _R5_2 + 1,W
   MOVWF   R5 + 1
       MOVF    _R6_2,W
   MOVWF   R6
   MOVF    _R6_2 + 1,W
   MOVWF   R6 + 1
       MOVF    _R7_2,W
   MOVWF   R7
   MOVF    _R7_2 + 1,W
   MOVWF   R7 + 1
       MOVF    _R8_2,W
   MOVWF   R8
   MOVF    _R8_2 + 1,W
   MOVWF   R8 + 1
       IFDEF   FLAGS
       MOVF    _FLAGS_2,W
       MOVWF   FLAGS        ENDIF
    IFDEF   GOP
       MOVF    _GOP_2,W
       MOVWF   GOP
   EndIF
   IFDEF   RM1
       MOVF    _RM1_2,W
       MOVWF   RM1        ENDIF
   IFDEF   RM2         MOVF    _RM2_2,W
       MOVWF   RM2        ENDIF
   IFDEF   RR1
       MOVF    _RR1_2,W
       MOVWF   RR1        ENDIF
   IFDEF   RR2
       MOVF    _RR2_2,W
       MOVWF   RR2      ENDIF
   IFDEF   T1         MOVF    _T1_2,W
       MOVWF   T1        ENDIF
   IFDEF   T2
       MOVF    _T2_2,W
       MOVWF   T2
   ENDIF     IFDEF   DEBUG_ADDRESS
       MOVF    _DEBUG_ADDRESS_2 ,W
       MOVWF   DEBUG_ADDRESS
   ENDIF
   IFDEF   DEBUG_STACK
       MOVF    _DEBUG_STACK_2,W
       MOVWF   DEBUG_STACK        ENDIF

   MOVF    fsave,W                                     ; Restore the FSR reg     MOVWF   FSR

   Movf    psave,w                                     ; Restore the PCLATH reg
   Movwf   PCLATH
   swapf   ssave,w                                     ; Restore the STATUS reg                    
   movwf   STATUS
   swapf   wsave,f
   swapf   wsave,w                                     ; Restore W reg
   Retfie                                              ; Exit the interrupt routine        
 ENDASM

OVER_INT_CODE:

* spamBeGoneXrobert.soubieSTOPspamspamEraseMEfree.frX (veuillez supprimer les "X")
* http://www.astrosurf.com/soubie
* Au royaume des aveugles, les borgnes sont mal vus... - P.Dac

--
http://www.piclist.com hint: To leave the PICList
KILLspampiclist-unsubscribe-requestspamBeGonespammitvma.mit.edu

2004\01\06@040123 by Alan B. Pearce

face picon face
> Thank you for your kind answer: I am not requesting help at
> that level, because I have had a full 26 years to debug
> microprocessor apps starting with things like 8080, 6800 and
> 6809.
>
> At the moment I am looking for something really elusive, and
> I am specifically searching for a source of inspiration that
> would help me discover whether it is me, the compiler and
> relevant interrupt routines, the litterature, or the stupid
> silicium that is the problem.
>
> So far and with help of an oscilloscope I have been unable
> to eliminate any of these four potential culprits (PIC
> silicium has had bugs in the MSSP for some revisions and
> chips, Microchip documentation has had flaws, Application
> notes code my Microchip have bugs etc),

hang on a minute. Are you really telling us that the code in Microchip
Application Note AN734 doesn't work? I used this code to make my interrupt
driven I2C slave module quite satisfactorily. If you have a look in the
PICList archive for messages with the subject line "I2C Troubles" you will
find all the info you need on this.

--
http://www.piclist.com hint: To leave the PICList
EraseMEpiclist-unsubscribe-requestspamEraseMEmitvma.mit.edu

2004\01\06@044551 by Russell McMahon

face
flavicon
face
> > This is why I am seeking here a higher and hopefully
> > friendlier level of help, in the form of working, true and
> > tested example code.

> > No less.

> Oh, I see.  You've got a problem which you've wasted days and weeks on,
but
> are demanding a free solution for?


I think you MAY be misunderstanding the meaning of the phrase "no less"
here.
(He suggests immediately after this that English is not his 1st language.
This is, however, proper English).

I would have read that to say that anything less than a working code
solution is unlikely to be useful to him as he has attempted to apply less
complete solutions without success. To me this doesn't say anything about
whether he would be willing to pay for such a solution (although I'm sure
he'd be pleased and grateful if it was free). But, of course, I may be
wrong.

Fortunately, it sounds like Allan Pearce's offered solution meets his needs
and is free.



       RM

--
http://www.piclist.com hint: To leave the PICList
@spam@piclist-unsubscribe-request@spam@spamspam_OUTmitvma.mit.edu

2004\01\06@074404 by Olin Lathrop

face picon face
Bob Axtell wrote:
> To do this well, the PIC would have to be almost dedicated to ONLY
> servicing the I2C Master and doing nothing else.

That depends.  The MSSP in slave mode can do clock stretch on a read, so
there is a means of flow control in that direction.  Unfortunately Microchip
didn't implement clock stretch for writes, although there are other ways to
deal with this.  Data coming into the slave IIC port is not that much
different than data coming into the UART.  Eventually you still have to
handle it at the speed it decides to come at.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

--
http://www.piclist.com hint: To leave the PICList
spamBeGonepiclist-unsubscribe-requestspamKILLspammitvma.mit.edu

2004\01\06@082324 by Olin Lathrop

face picon face
Robert Soubie wrote:
> We build and use CCD cameras for astronomy; ...

It would have been helpful to explain this from the start.  Your original
post gave the impression you were a clueless bozo.  First, it sounded like
you were trying to blame the PIC for your troubles, then you were using
Basic on top of that.  Since it seemed I was talking to an idiot I gave a
very basic answer, which was to look at the signals on a scope to decide if
the signals are wrong or their interpretation wrong (not a bad idea in any
case).

Then you made matters worse by taking offense at that advice, although you
didn't seem actually carry out the test.  Instead, you whined about lost
time and demanded someone else supply you working code!

>> You've got a problem which you've wasted days and weeks
>> on, but are demanding a free solution for?
>
> Correct.

This is absolutely the height of arrogance.  Someone asking for free help is
hardly in a position to demand anything.

> I do not see why anyone should be shocked by such a
> request;

A request, no, but a demand is way out of line.

> I have monitored Melabs PicBasic Pro mailing list
> for months now, it is full of professionnals that provide
> free help to beginners and confirmed people alike, and go to
> great extents to this end, including spending time to
> actually "prototype" and solve other's problems.

Lots of people here will help if you are polite, humble, and show that
you've taken reasonable steps to solve the problem yourself.  Much fewer are
willing to help a clueless arrogant jerk.

I've probably got more example code and other PIC related stuff on the web
for free than most people.  See http://www.embedinc.com/pic.  However, I've
never gotten around to packaging up any of the IIC code into a form suitable
for public distribution.  Each implementation is a little different and has
some of the customer's app mixed in with it.  You probably don't understand
why it can't just be handed over for free, but it would take some careful
removal from the app, generalize the IIC part into a more generic form,
write an example test app and make sure the whole thing still works,  create
the release procedures, etc.  It's something I had been thinking of doing in
the back of my mind, but so far haven't gotten around to it.  However, some
arrogant prick demanding I do it pretty much guarantees it won't happen
anytime soon.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

--
http://www.piclist.com hint: To leave the PICList
.....piclist-unsubscribe-requestspam_OUTspammitvma.mit.edu

2004\01\06@090526 by

picon face
> ...if you are polite, humble,...

Now, how is it written in "The Book" ?

"Do to others as you'd like other to do to you"

Not a bad thought...

And I think it was highly unnecessary to use words
as "clueless bozo", "an idiot", "clueless arrogant jerk"
and "arrogant prick" *after* the well written
description of his actual project, which, IMHO,
showed something completely different...

Best Regards !
Jan-Erik.

--
http://www.piclist.com hint: To leave the PICList
TakeThisOuTpiclist-unsubscribe-request.....spamTakeThisOuTmitvma.mit.edu

2004\01\06@090721 by

picon face
Robert Soubie wrote:

> There is nothing confidential in what I am doing, so here
> goes: it is a project that I delopped in an
> amateur/professionnal astronomer association (600 members in
> the world and counting) called Aude
> (http://www.astrosurf.com/aude).

Hi !

A little of-topic, but...

As beeing an amateur astronomer myself (and also
a great fan of anything French, well not *anything* :-) ),
I read your post with great interest. Merci !!

I'll see if anything of these stuff could be of use in our
local astronomy club :-)

Regards
Jan-Erik.
PS. I'm sorry I know close to nothing about I2C :-)

--
http://www.piclist.com hint: To leave the PICList
TakeThisOuTpiclist-unsubscribe-requestKILLspamspamspammitvma.mit.edu

2004\01\06@144939 by James Newton, webhost

face picon face
Olin, olin, olin: You know... if you had handled that a bit differently, you
might have had a paying customer...

Now, your bitching him out publicly pretty much guaranties that not only
will he NEVER buy anything from you, but also will reduce the probability
that anyone else on the list will ever attempt to work with you on a paying
job.

I do agree with Herb. If you must call people "pricks" on the list, then
please leave. If you can find a way to say it a little nicer... like "I was
going to look into this for you, but since you are demanding that I work for
free, and are not willing to take the advice I have offered so far, I will
no longer be responding to unpaid questions on this issue." then I hope you
can stay. Notice how that example very clearly explains how you feel, is not
a personal attack, and leaves the door open for him to PAY you.

I'm sending this directly to the public list for the following reasons:
A) I'm tired of trying to calm you down privately
B) You have objected many times to off list emails, e.g. emails sent
directly to you.
C) I know this is going to generate a ton of emails from other members
asking that I kick you off the list (at the least! <GRIN>) and I want
everybody to see how it is being handled.

FINAL WARNING: Keep it polite or shove off.

---
James Newton, webhost piclist.com (former Admin #3)
.....jamesnewtonspamRemoveMEpiclist.com 1-619-652-0593 fax:1-208-279-8767
PIC/PICList FAQ: http://www.piclist.com or .org

----Original Message----
From: Herbert Graf [RemoveMEmailinglist2spamspamBeGonefarcite.net]
Sent: Tuesday, January 06, 2004 10:07 AM
To: spamBeGoneolin_piclist@spam@spamspam_OUTEMBEDINC.COM
Cc: PICLIST-request
Subject: RE: [PIC:] Pic as an i2c slave

{Quote hidden}

>> {Original Message removed}

2004\01\06@145600 by Robert Soubie

flavicon
face
On Tue, 6 Jan 2004 09:00:19 -0000, Alan B. Pearce wrote on
Re: [PIC:] Pic as an i2c slave:

>> At the moment I am looking for something really elusive, and
>> I am specifically searching for a source of inspiration that
>> would help me discover whether it is me, the compiler and
>> relevant interrupt routines, the litterature, or the stupid
>> silicium that is the problem.
>>
>> So far and with help of an oscilloscope I have been unable
>> to eliminate any of these four potential culprits (PIC
>> silicium has had bugs in the MSSP for some revisions and
>> chips, Microchip documentation has had flaws, Application
>> notes code my Microchip have bugs etc),
>
>hang on a minute. Are you really telling us that the code in Microchip
>Application Note AN734 doesn't work?
I am saying that it does not work reliably (i.e. on every
occurence) in my context, that is as an assembler routine
inserted in my Basic application, with use of preamble and
postamble routines to the effect of saving and restoring the
PIC's registers and the compiler internal variables.

>I used this code to make my interrupt driven I2C slave module quite satisfactorily.
This information is valuable indeed, because it seems to
show that the logics are OK (they seem to be when analysed
with the PIC's reference book as a bible) and work for some
people in some contexts.
Would you care indicate whether yours was a large
application (how busy the PIC was when not managing i2c),
and whether the i2c was managed in the program's main loop
or as a real interrupt service routine?

>If you have a look in the PICList archive for messages with the subject line "I2C Troubles" you will
>find all the info you need on this.

I have found this message a long time ago and taken note
that some people had had problems running that AN734 code
until it apparently was corrected. The message (by Bob
Blick) says this:

***
On Sun, 24 Mar 2002, Claudio Tagliola wrote:

> Now I'm confused too, I am working with that appnote and the sample code
> works correctly, even after the first transfer. Does this behaviour only
> pop up on specific I2C master devices?

Hi Claudio,

The sample works except when you read from the slave. In the
example they forgot to set CKP after the slave is done
transmitting.

Cheers, Bob
***

Apparently , a "CKP = 1" instruction, or rather, in
assembler,

       bsf     SSPCON,CKP      ; Release the clock.

was missing.

Problem is this instruction is present in the "Doi2cWrite"
sub, which is called every time the slave is read by the
master (states 3 and 4). So my question is "where is (or
was) that instruction missing?".
Also, if it is not missing in the version I have, why does
it basically work, but unreliably?

More mysteries...

For reference, here is the AN734 routine I used:

************************************************
;-----------------------------------------------
;                Software License Agreement
;
; The software supplied herewith by Microchip Technology
Incorporated ;(the “Company”) for its PICmicro® Microcontroller is
intended and ; supplied to you, the Company’s customer, for use solely
and ; exclusively on Microchip PICmicro Microcontroller
products. The ; software is owned by the Company and/or its supplier, and
is ; protected under applicable copyright laws. All rights are
reserved. ;  Any use in violation of the foregoing restrictions may
subject the ; user to criminal sanctions under applicable laws, as well
as to ; civil liability for the breach of the terms and conditions
of this ; license.
;
; THIS SOFTWARE IS PROVIDED IN AN “AS IS” CONDITION. NO
WARRANTIES, ; WHETHER EXPRESS, IMPLIED OR STATUTORY, INCLUDING, BUT NOT
LIMITED ; TO, IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
A ; PARTICULAR PURPOSE APPLY TO THIS SOFTWARE. THE COMPANY
SHALL NOT, ; IN ANY CIRCUMSTANCES, BE LIABLE FOR SPECIAL, INCIDENTAL OR
; CONSEQUENTIAL DAMAGES, FOR ANY REASON WHATSOEVER.
;
;---------------------------------------------------------------------
;       File:           an734.asm
;
;       Written By:     Stephen Bowling, Microchip Technology
;
;       Version:        1.00
;
;       Assembled using Microchip Assembler ;
; Functionality:
;
; This code implements the basic functions for an I2C slave
device
; using the SSP module.  All I2C functions are handled in an
ISR.
; Bytes written to the slave are stored in a buffer.  After
a number
; of bytes have been written, the master device can then
read the
; bytes back from the buffer.
;
; Variables and Constants used in the program:
;
; The start address for the receive buffer is stored in the
variable
; 'RXBuffer'.  The length of the buffer is denoted by the
constant
; value 'RX_BUF_LEN'.  The current buffer index is stored in
the ; variable 'Index'.
;
;--------------------------------------------------------------------
; ; The following files should be included in the MPLAB
project:
;
;       an734.asm-- Main source code file
;
;       16f872.lkr-- Linker script file
;                  (change this file for the device
;               you are using)
;
;---------------------------------------------------------------------
;---------------------------------------------------------------------
; Include Files
;---------------------------------------------------------------------

#include <p16f872.inc>  ; Change to device that you are
using.


;---------------------------------------------------------------------
;Constant Definitions
;---------------------------------------------------------------------

#define  NODE_ADDR      0x02    ; I2C address of this node
                               ; Change this value to address that
                               ; you wish to use.
;---------------------------------------------------------------------
; Buffer Length Definition
;---------------------------------------------------------------------

#define  RX_BUF_LEN     32      ; Length of receive buffer

;---------------------------------------------------------------------
; Variable declarations
;---------------------------------------------------------------------
       udata

WREGsave        res     1
STATUSsave      res     1
FSRsave               res     1
PCLATHsave      res     1

Index           res     1               ; Index to receive buffer
Temp            res     1               ;
RXBuffer        res     RX_BUF_LEN      ; Holds rec'd bytes from master
                                       ; device.
       
;---------------------------------------------------------------------
; Vectors
;---------------------------------------------------------------------

STARTUP  code
       nop                    
       goto    Startup         ;         nop                     ; 0x0002
       nop                     ; 0x0003
       goto    ISR             ; 0x0004

PROG code

;---------------------------------------------------------------------
; Macros
;---------------------------------------------------------------------

memset  macro   Buf_addr,Value,Length

       movlw   Length          ; This macro loads a range of data memory
       movwf   Temp            ; with a specified value.  The starting
       movlw   Buf_addr        ; address and number of bytes are also         movwf   FSR             ; specified.
SetNext movlw   Value
       movwf   INDF
       incf    FSR,F
       decfsz  Temp,F
       goto    SetNext
       endm


LFSR    macro   Address,Offset  ; This macro loads the correct
value
       movlw   Address         ; into the FSR given an initial data         movwf   FSR             ; memory address and offset value.
       movf    Offset,W
       addwf   FSR,F
       endm

;---------------------------------------------------------------------
; Main Code
;---------------------------------------------------------------------

Startup
       bcf     STATUS,RP1
       bsf     STATUS,RP0
       call    Setup

Main    clrwdt                  ; Clear the WDT                
       goto            Main    ; Loop forever.        


;---------------------------------------------------------------------
; Interrupt Code
;---------------------------------------------------------------------

ISR
       movwf   WREGsave        ; Save WREG
       movf    STATUS,W        ; Get STATUS register
       banksel STATUSsave      ; Switch banks, if needed.
       movwf   STATUSsave      ; Save the STATUS register
       movf    PCLATH,W        ;
       movwf   PCLATHsave      ; Save PCLATH
       movf    FSR,W           ;
       movwf   FSRsave         ; Save FSR

       banksel PIR1
       btfss   PIR1,SSPIF      ; Is this a SSP interrupt?        
       goto    $               ; No, just trap here.
       bcf     PIR1,SSPIF
       call    SSP_Handler     ; Yes, service SSP interrupt.
       
       banksel FSRsave
       movf    FSRsave,W       ;
       movwf   FSR             ; Restore FSR
       movf    PCLATHsave,W    ;         movwf   PCLATH          ; Restore PCLATH
       movf    STATUSsave,W    ;
       movwf   STATUS          ; Restore STATUS
       swapf   WREGsave,F      ;
       swapf   WREGsave,W      ; Restore WREG
       
       retfie                  ; Return from interrupt.
       
;---------------------------------------------------------------------
Setup
;
; Initializes program variables and peripheral registers.
;---------------------------------------------------------------------

       banksel PCON
       bsf     PCON,NOT_POR
       bsf     PCON,NOT_BOR

       banksel Index           ; Clear various program variables
       clrf    Index

       clrf    PORTB
       clrf    PIR1
       banksel TRISB
       clrf    TRISB

       movlw   0x36            ; Setup SSP module for 7-bit         banksel SSPCON
       movwf   SSPCON          ; address, slave mode
       movlw   NODE_ADDR
       banksel SSPADD
       movwf   SSPADD
       clrf    SSPSTAT
       
               
       banksel PIE1            ; Enable interrupts
       bsf     PIE1,SSPIE
       bsf     INTCON,PEIE     ; Enable all peripheral interrupts
       bsf     INTCON,GIE      ; Enable global interrupts

       bcf     STATUS,RP0
       return

;---------------------------------------------------------------------
SSP_Handler
;---------------------------------------------------------------------
;       The I2C code below checks for 5 states:
;---------------------------------------------------------------------
;       State 1:        I2C write operation, last byte was an address
byte.
;
;       SSPSTAT bits:   S = 1, D_A = 0, R_W = 0, BF = 1
;
;       State 2:          I2C write operation, last byte was a data
byte.
;
;       SSPSTAT bits:     S = 1, D_A = 1, R_W = 0, BF = 1
;
;       State 3:          I2C read operation, last byte was an address
byte.
;
;       SSPSTAT bits:     S = 1, D_A = 0, R_W = 1, BF = 0
;
;       State 4:          I2C read operation, last byte was a data byte.
;
;       SSPSTAT bits:     S = 1, D_A = 1, R_W = 1, BF = 0
;
;       State 5:  Slave I2C logic reset by NACK from master.
;        
;       SSPSTAT bits:  S = 1, D_A = 1, R_W = 0, BF = 0
;
; For convenience, WriteI2C and ReadI2C functions have been
used.
;----------------------------------------------------------------------

       banksel SSPSTAT
       movf    SSPSTAT,W       ; Get the value of SSPSTAT
       andlw   b'00101101'     ; Mask out unimportant bits in SSPSTAT.
       banksel Temp            ; Put masked value in Temp
       movwf   Temp            ; for comparision checking.

State1:                         ; Write operation, last byte was an
       movlw   b'00001001'     ; address, buffer is full.
       xorwf   Temp,W          ;         btfss   STATUS,Z        ; Are we in State1?
       goto    State2          ; No, check for next state.....
       
       memset  RXBuffer,0,RX_BUF_LEN   ; Clear the receive buffer.
       clrf    Index           ; Clear the buffer index.
       call    ReadI2C         ; Do a dummy read of the SSPBUF.
       return
       
State2:                         ; Write operation, last byte was data,
       movlw   b'00101001'     ; buffer is full.
       xorwf   Temp,W
       btfss   STATUS,Z        ; Are we in State2?
       goto    State3          ; No, check for next state.....
               
       LFSR    RXBuffer,Index  ; Point to the buffer.
       call    ReadI2C         ; Get the byte from the SSP.
       movwf   INDF            ; Put it in the buffer.
       incf    Index,F         ; Increment the buffer pointer.
       movf    Index,W         ; Get the current buffer index.
       sublw   RX_BUF_LEN      ; Subtract the buffer length.
       btfsc   STATUS,Z        ; Has the index exceeded the buffer
length?
       clrf    Index           ; Yes, clear the buffer index.
       return
       
State3:                         ; Read operation, last byte was an
       movlw   b'00001100'     ; address, buffer is empty.
       xorwf   Temp,W
       btfss   STATUS,Z        ; Are we in State3?
       goto    State4          ; No, check for next state.....
       
       clrf    Index           ; Clear the buffer index.
       LFSR    RXBuffer,Index  ; Point to the buffer
       movf    INDF,W          ; Get the byte from buffer.
       call    WriteI2C        ; Write the byte to SSPBUF
       incf    Index,F         ; Increment the buffer index.
       return
       
State4:                         ; Read operation, last byte was data,
       movlw   b'00101100'     ; buffer is empty.
       xorwf   Temp,W
       btfss   STATUS,Z        ; Are we in State4?
       goto    State5          ; No, check for next state....
       
       movf    Index,W         ; Get the current buffer index.
       sublw   RX_BUF_LEN      ; Subtract the buffer length.
       btfsc   STATUS,Z        ; Has the index exceeded the buffer
length?
       clrf    Index           ; Yes, clear the buffer index.
       LFSR    RXBuffer,Index  ; Point to the buffer
       movf    INDF,W          ; Get the byte
       call    WriteI2C        ; Write to SSPBUF
       incf    Index,F         ; Increment the buffer index.
       return

State5:
       movlw   b'00101000'     ; A NACK was received when transmitting
       xorwf   Temp,W          ; data back from the master.  Slave logic
       btfss   STATUS,Z        ; is reset in this case.  R_W = 0, D_A = 1
       goto    I2CErr          ; and BF = 0
       return                  ; If we aren’t in State5, then something is                                 ; wrong.

I2CErr  nop
       banksel PORTB           ; Something went wrong!  Set LED
       bsf     PORTB,7         ; and loop forever.  WDT will reset
       goto    $               ; device, if enabled.
       return

;---------------------------------------------------------------------
; WriteI2C
;---------------------------------------------------------------------

WriteI2C
       banksel SSPSTAT
       btfsc   SSPSTAT,BF      ; Is the buffer full?
       goto    WriteI2C        ; Yes, keep waiting.
       banksel SSPCON          ; No, continue.
DoI2CWrite
       bcf     SSPCON,WCOL     ; Clear the WCOL flag.
       movwf   SSPBUF          ; Write the byte in WREG
       btfsc   SSPCON,WCOL     ; Was there a write collision?
       goto    DoI2CWrite
       bsf     SSPCON,CKP      ; Release the clock.
       return

;---------------------------------------------------------------------
ReadI2C
;---------------------------------------------------------------------
       
       banksel SSPBUF
       movf    SSPBUF,W        ; Get the byte and put in WREG
       return
       
       end                     ; End of file

* TakeThisOuTXrobert.soubiespamspamfree.frX (veuillez supprimer les "X")
* http://www.astrosurf.com/soubie
* Au royaume des aveugles, les borgnes sont mal vus... - P.Dac

--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-requestEraseMEspammitvma.mit.edu

2004\01\06@151056 by Robert Soubie

flavicon
face
On Tue, 6 Jan 2004 08:09:17 +0100, Bühler, Martin wrote on
Re: [PIC:] Pic as an i2c slave:

>hi
>i once used a 16f872 as i2c slave.
>look at the c code attached:
>i2chw is the i2c slave code.
>iic2lcd is the main code, just to show how routines of i2chw are called.
>this approach is based on a microchip application note (assembler) with some modifications.

Thanks indeed!

>let me know if this works for you.

I sure will.

* RemoveMEXrobert.soubieEraseMEspamspam_OUTfree.frX (veuillez supprimer les "X")
* http://www.astrosurf.com/soubie
* Au royaume des aveugles, les borgnes sont mal vus... - P.Dac

--
http://www.piclist.com hint: To leave the PICList
@spam@piclist-unsubscribe-requestRemoveMEspamEraseMEmitvma.mit.edu

2004\01\06@152131 by Robert Soubie

flavicon
face
On Tue, 6 Jan 2004 08:41:25 -0000, Michael Rigby-Jones wrote
on Re: [PIC:] Pic as an i2c slave:

>>{Original Message removed}

2004\01\06@154012 by Robert Soubie

flavicon
face
On Tue, 6 Jan 2004 15:03:02 +0100, Jan-Erik Soderholm XA
(TN/PAC) wrote on Re: [PIC:] Pic as an i2c slave:

>> ...if you are polite, humble,...
>
>Now, how is it written in "The Book" ?
>
>"Do to others as you'd like other to do to you"
>
>Not a bad thought...

That's ok with me, Jan-Erik, I am a tad too old to take
offence from that kind of incrimination and deep
misunderstanding of what I meant in my first and subsequent
messages. Just another case of uncommunicability I guess.

>And I think it was highly unnecessary to use words
>as "clueless bozo", "an idiot", "clueless arrogant jerk"
>and "arrogant prick" *after* the well written
>description of his actual project, which, IMHO,
>showed something completely different...

8-) I basically agree, but after all he improved my english,
and this is a blessing.
Also, every forum has at least one such personnality. You
have to take people as they come by, and there is magic in
their mere diversity... That is what the internet is about!

Yours humbly,
Robert

* EraseMEXrobert.soubiespam@spam@free.frX (veuillez supprimer les "X")
* http://www.astrosurf.com/soubie
* Au royaume des aveugles, les borgnes sont mal vus... - P.Dac

--
http://www.piclist.com hint: To leave the PICList
@spam@piclist-unsubscribe-requestspam_OUTspam.....mitvma.mit.edu

2004\01\06@163750 by Royce Simmons

flavicon
face
AMEN!!!!!

Royce Simmons

----- Original Message -----
From: "James Newton, webhost" <spamBeGonejamesnewtonEraseMEspamPICLIST.COM>
To: <PICLISTspamBeGonespamMITVMA.MIT.EDU>
Sent: Tuesday, January 06, 2004 2:41 PM
Subject: Re: [PIC:] Pic as an i2c slave


> Olin, olin, olin: You know... if you had handled that a bit differently,
you
> might have had a paying customer...
>
> Now, your bitching him out publicly pretty much guaranties that not only
> will he NEVER buy anything from you, but also will reduce the probability
> that anyone else on the list will ever attempt to work with you on a
paying
> job.
>
> I do agree with Herb. If you must call people "pricks" on the list, then
> please leave. If you can find a way to say it a little nicer... like "I
was
> going to look into this for you, but since you are demanding that I work
for
> free, and are not willing to take the advice I have offered so far, I will
> no longer be responding to unpaid questions on this issue." then I hope
you
> can stay. Notice how that example very clearly explains how you feel, is
not
{Quote hidden}

> >> {Original Message removed}

2004\01\06@170450 by Bob Axtell

face picon face
Pretty much agree, Olin...

Olin Lathrop wrote:

{Quote hidden}

I've ALWAYS been disappointed with MC on not implementing a PROPER I2C
port. I THINK they didn't want to pay the Phillips royalty.

More serious with the MSSP unit is that it mixes I2C and SPI. The SPI
portion of the MSSP is a wonderful piece of hardware, and I love it.
There is no real speed restriction in SPI slave mode; when you receive
a frame, you get an interrupt, then go read it. But, the I2C...

Really, look at it; the I2C portion of MSSP is really limp. First, you
can do either I2C OR SPI on the same chip, not both. Then, you get an
interrupt on START and STOP, and the ACK is OK- fine; but you don't get
much more than that. Everything else you do has to be heavily "tinkered
with".

A proper I2C hardware engine would operate seamlessly. The slave engine
would know when a start bit is expected, and properly turn on WHEN THE
ADDRESS MATCHES and proceed to accept data, with a status byte somewhere
keeping up with what kind of data was coming in. Even the 7-bit/10-bit
address could be handled. It would then be reset when the STOP bit
occurred. Even an 8-byte I/O FIFO would be nice...

BTW, Happy New Year! to Olin, Wouter, James, and everyone! Its fun
sparring with you guys; you are a tough act to follow...

--Bob



> *****************************************************************
> Embed Inc, embedded system specialists in Littleton Massachusetts
> (978) 742-9014, http://www.embedinc.com
>
> --
> http://www.piclist.com hint: To leave the PICList
> .....piclist-unsubscribe-requestSTOPspamspam@spam@mitvma.mit.edu
>


--
             --------------
               Bob Axtell
       PIC Hardware & Firmware Dev
         http://beam.to/baxtell
             1-520-219-2363

--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-requestEraseMEspam@spam@mitvma.mit.edu

2004\01\06@172603 by Olin Lathrop

face picon face
Bob Axtell wrote:
> I THINK they didn't want to pay the Phillips royalty.

It was my understanding they DID pay.  Note that you don't need a separate
IIC license for your design as long as a PIC is part of the IIC bus because
of an agreement between Microchip and Phillips.

I think the problem is that the smart people were off doing something else
when the IIC module was designed.  It seems to have more than its share of
difficult to use "features" and a few outright bugs.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

--
http://www.piclist.com hint: To leave the PICList
RemoveMEpiclist-unsubscribe-requestspamspamBeGonemitvma.mit.edu

2004\01\06@215649 by Colin Constant

picon face
PICrom: Robert Soubie <spamBeGonerobert.soubieKILLspamspam@spam@FREE.FR>
>
>As an example, I have in september installed such a
>configuration on a telescope that is managed by us on top of
>Pic du Midi (http://www.bdl.fr/s2p) in the french Pyrenees

Wow! They named a mountain after your (mid-range) PIC project? Awesome!

Seriously, that was very informative.  Thanks,

Colin

_________________________________________________________________
Add photos to your messages with MSN 8. Get 2 months FREE*.
http://join.msn.com/?page=dept/features&pgmarket=en-ca&RU=http%3a%2f%2fjoin.msn.com%2f%3fpage%3dmisc%2fspecialoffers%26pgmarket%3den-ca

--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-requestspam_OUTspam@spam@mitvma.mit.edu

2004\01\07@032507 by GVH Unnau

flavicon
face
>
> Also, every forum has at least one such personnality. You
> have to take people as they come by, and there is magic in
> their mere diversity... That is what the internet is about!


Yes, Robert

And a real blessing is, that the internet is between all of us,
which carries only bits and no BITES.

Gerd

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2004\01\07@040938 by Alan B. Pearce

face picon face
>>hang on a minute. Are you really telling us that the code in
>>Microchip Application Note AN734 doesn't work?
>
>I am saying that it does not work reliably (i.e. on every
>occurence) in my context, that is as an assembler routine
>inserted in my Basic application, with use of preamble and
>postamble routines to the effect of saving and restoring the
>PIC's registers and the compiler internal variables.

OK, this is more info than you have given up till now. If you had said this
at the start, you may have even avoided most of Olin's diatribe.

>>I used this code to make my interrupt driven I2C slave module quite
satisfactorily.
{Quote hidden}

It is done as a real interrupt service routine that puts the received bytes
into a FIFO buffer. The code is exactly as in the application note with two
modifications, one to correct the error that Bob reports below, and the
other to handle a status byte that I wanted the master to be able to poll,
and is handled totally within the interrupt routine without dropping out to
background code.

...

>I have found this message a long time ago and taken note
>that some people had had problems running that AN734 code
>until it apparently was corrected. The message (by Bob
>Blick) says this:

...

{Quote hidden}

I suspect that the unreliability is for the reason that Bob states. I took
Bobs statement literally, and put the instruction you note in the code that
handles the end of transmission situation, where the one you are looking at
is in the middle of the message handling. Just looking through the code I
have, it looks like it goes at the beginning of I2CErr, where the NOP
instruction is.

If this does not fix the code I will send you my code, but it is a module
designed around Olin's development environment, so is a linkable module.

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2004\01\07@045337 by hael Rigby-Jones

picon face
>-----Original Message-----
>From: Bob Axtell [spamBeGonecr_axtell@spam@spamYAHOO.COM]
>Sent: 06 January 2004 21:50
>To: RemoveMEPICLISTEraseMEspamKILLspamMITVMA.MIT.EDU
>Subject: Re: [PIC:] Pic as an i2c slave
>
>Really, look at it; the I2C portion of MSSP is really limp.
>First, you can do either I2C OR SPI on the same chip, not
>both. Then, you get an interrupt on START and STOP, and the
>ACK is OK- fine; but you don't get much more than that.
>Everything else you do has to be heavily "tinkered with".
>
It has it's faults but I don't think it's anywhere near as bad as you are
saying.  I have thousands of product in the field working perfectly with the
MSSP configured as slaves and interfacing to customers equipement.

You don't get an interrupt on start and stop, at least I've never used it in
this way.  The PIC simply provides an interrupt whenever a byte has been
sent to the master (and acknowledged) or when a byte has been received from
the master.  There are status bytes (SSPSTAT/SSPCON) that can be used to
tell if the incomming byte is an address or data byte, whether there has
been a buffer overflow etc.  Once the operation of the MSSP module is fully
understood, writing the code to implement a robust slave is not very
difficult.


>A proper I2C hardware engine would operate seamlessly. The
>slave engine would know when a start bit is expected, and
>properly turn on WHEN THE ADDRESS MATCHES and proceed to
>accept data, with a status byte somewhere keeping up with what
>kind of data was coming in.

This is more or less exactly what the MSSP does.

>Even the 7-bit/10-bit address
>could be handled. It would then be reset when the STOP bit
>occurred. Even an 8-byte I/O FIFO would be nice...
>

The MSSP does handle 10 bit addressing, but some software intervention is
required.  It's a no-brainer though.

Regards

Mike




=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================
Any questions about Bookham's E-Mail service should be directed to
spamBeGonepostmasterspam_OUTspamRemoveMEbookham.com.

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2004\01\07@045338 by Robert Soubie

flavicon
face
On Wed, 7 Jan 2004 09:09:13 -0000, Alan B. Pearce wrote on
Re: [PIC:] Pic as an i2c slave:

>>>hang on a minute. Are you really telling us that the code in
>>>Microchip Application Note AN734 doesn't work?
>>
>>I am saying that it does not work reliably (i.e. on every
>>occurence) in my context, that is as an assembler routine
>>inserted in my Basic application, with use of preamble and
>>postamble routines to the effect of saving and restoring the
>>PIC's registers and the compiler internal variables.
>
>OK, this is more info than you have given up till now. If you had said this
>at the start, you may have even avoided most of Olin's diatribe.

Sorry, but the facts are the facts and this is precisely
what I have said in previous message:

Quote:

"Despite much reading and testing in numerous attempts and
some partial positive results, I am unable to have my own
application work reliably; "

Please reread the whole thread and particularly the messages
I authored with the new understanding you now have of the
situation and I am pretty confident that you will be
prevented from granting me *any* responsability in what
happened with that person.

Please also remember that even as I have been speaking
fluently english since the age of 12 (I am now 55), I learnt
the language in the industrial suburbs north of London
where, as a paying guest, I shared the life of modest but
generous british workers; this may explain why my english
has nothing to do with Oxford's or Cambridge dialects.
FYI I also speak fluently, though far from perfectly, two
other languages: Italian and Greek. This greatly increases
reciprocal understanding of others, but also the statistics
of misunderstanding 8-).

By the way someone has just explained to me that the term
"demand" (which is fully french by the way) has a strong
meaning in english, whereas in french it just means
"request", and a polite and humble at that.

So we now have the beginning of an explanation of the rude
and insulting "diatribe", as you call it (you know what a
litotes is, don't you?).
Of course, it remains to be seen why Mister Lathrop used
that term in the first place, but here we are leaving the
terrain of philology and linguistics to enter that of
psychiatry.

I simply think he had unwillingly decided beforehand I was
an arrogant moronic englishly illetirate frenchie (the times
are hard for us you know 8-) and that my humble and polite
request *had* to be an unacceptable demand.
Which you know by now (and probably knew by then) is not
true...
There is more than one way to make a fool of oneself.

Back on track...

{Quote hidden}

Fine and usable information.

{Quote hidden}

Fine. You suggest adding the bsf SSPCON, CKP instruction
there, don't you? If so this is new information to me, and
none of my many previous testes tests took it into account,
so this may be a solutions to my woes.

I still have to fully understand why CKP should be set at
that point, but of course I'll believe the gurus...
A code comment here says that we should never get to that
state; having to add that instruction at that place implies
that for the whole thing to consistantly succeed afterwards
it first has to fail once and reach this uncontrolled
state... Strange...

Thanks anyway. I *also* had stressed that concern about
AN734 correctness in previous messages. If you, or others
for that matter, had given me that answer sooner, probably
we would have avoided that kind of rough relations.

There is a lesson there: do to yourself what you are
inclined to impose on others...

>If this does not fix the code I will send you my code, but it is a module
>designed around Olin's development environment, so is a linkable module.

Please do, I'll keep that private.

Friendly, Robert

* .....Xrobert.soubiespamRemoveMEfree.frX (veuillez supprimer les "X")
* http://www.astrosurf.com/soubie
* Au royaume des aveugles, les borgnes sont mal vus... - P.Dac

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2004\01\07@051208 by Alan B. Pearce

face picon face
>I still have to fully understand why CKP should be set at
>that point, but of course I'll believe the gurus...
>
>A code comment here says that we should never get to that
>state; having to add that instruction at that place implies
>that for the whole thing to consistantly succeed afterwards
>it first has to fail once and reach this uncontrolled
>state... Strange...

Umm, not sure about never getting there. I haven't refreshed myself properly
about how the code works, but from the quick glance through on writing the
previous message, it will get there if the master sends back a NAK when the
slave is sending data to the master. The result is that there is no release
of the clock by the slave for the master to do the next message - i.e. the
slave is doing a permanent clock stretch. Is this what you see on the scope
when your system gives up?

Will organise the module for you, I have to go turn on a machine on another
floor to get the most current version.

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2004\01\07@123813 by Robert Soubie

flavicon
face
On Wed, 7 Jan 2004 10:11:53 -0000, Alan B. Pearce wrote on
Re: [PIC:] Pic as an i2c slave:

>>I still have to fully understand why CKP should be set at
>>that point, but of course I'll believe the gurus...
>>
>>A code comment here says that we should never get to that
>>state; having to add that instruction at that place implies
>>that for the whole thing to consistantly succeed afterwards
>>it first has to fail once and reach this uncontrolled
>>state... Strange...
>
>Umm, not sure about never getting there.

Here is what I am referring to, copied ans pasted from
AN734a.pdf:

State5:
movlw b’00101000’; A NACK was received when transmitting
xorwf Temp,W     ; data back from the master. Slave logic
btfss STATUS,Z   ; is reset in this case. R_W = 0, D_A = 1
goto I2CErr      ; and BF = 0
return           ; If we aren’t in State5,                  ; then something is wrong.
I2CErr:
nop
banksel PORTB    ; Something went wrong! Set LED
bsf PORTB,7      ; and loop forever. WDT will reset
goto $           ; device, if enabled.
return

This comment "something went wrong" seems to imply that the
current state, that leads to i2cErr has no meaning there and
in fact should never happen; it appears to be confirmed by
the pathetic attempt to have the watchdog reboot the PIC by
executing a goto $ instruction...

>I haven't refreshed myself properly
>about how the code works, but from the quick glance through on writing the
>previous message, it will get there if the master sends back a NAK when the
>slave is sending data to the master. The result is that there is no release
>of the clock by the slave for the master to do the next message - i.e. the
>slave is doing a permanent clock stretch. Is this what you see on the scope
>when your system gives up?

This may be the case and I'll have to investigate into it, I
will try to borrow a storage oscilloscope from my job.

>Will organise the module for you, I have to go turn on a machine on another
>floor to get the most current version.

Many thanks again, Alan

* Xrobert.soubiespam@spam@free.frX (veuillez supprimer les "X")
* http://www.astrosurf.com/soubie
* Au royaume des aveugles, les borgnes sont mal vus... - P.Dac

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2004\01\07@125853 by hael Rigby-Jones

picon face
>-----Original Message-----
>From: Robert Soubie [EraseMErobert.soubieRemoveMEspamSTOPspamFREE.FR]
>Sent: 07 January 2004 17:36
>To: RemoveMEPICLISTKILLspamspamTakeThisOuTMITVMA.MIT.EDU
>Subject: Re: [PIC:] Pic as an i2c slave

          ; then something is wrong.
{Quote hidden}

Out of interest what is pathetic about the attempt to deliberately fire a
watchdog timeout by using an infinite loop?  Surely you agree that it is
good practice to trap invalid states such as this?

Mike




=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================
Any questions about Bookham's E-Mail service should be directed to
spamBeGonepostmasterspam@spam@bookham.com.

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2004\01\07@132759 by Robert Soubie

flavicon
face
On Wed, 7 Jan 2004 17:58:24 -0000, Michael Rigby-Jones wrote
on Re: [PIC:] Pic as an i2c slave:

>Out of interest what is pathetic about the attempt to deliberately fire a
>watchdog timeout by using an infinite loop?  Surely you agree that it is
>good practice to trap invalid states such as this?

Oh yes, that was mere irony on my part, targeted to noone in
particular, or may be to the programmer that wrote this
-supposedly erroneous- piece of code. However it may not be
an efficient trap:

I know it is sound practice to activate a watchdog that will
reset your chip if your program loops forever or otherwise
fails to execute properly, may be because the chip was hit
by a cosmic ray etc.
This of course implies that your program's startup code can
handle such reset conditions and restart (as opposed to
start) gracefully from where it was at the time of the
mishap.

I our case, a watchdog reset is created on purpose because
in our i2C logics we have reached a point that noone should
ever reach. My idea is that proper recovery should be in
order at that point, not just this reset kludge.
I may be wrong but I base this opinion the fact that unless
the cause of the problem was purely random (like a cosmic
ray hit), it is highly probable that the same causes will
lead to the same result sooner or later, which itself will
lead to resetting the part anew.

Hence I would have preferred some garbage collecting routine
to the effect of reinitialising the MSSP, as is described in
one of the errata sheets for this very MSSP: if I remember
well, the trick was to program the MSSP to SPI then to i2c
again, that would fully reset the logics.

I suppose that for the purpose of this application note, the
people with microchip decided to oversimplify the routines
for better pedagogy.

However I still do not know what, according to past messages
on this list, should be (or maybe has been) corrected in
these routines.

Amitiés, Robert

* RemoveMEXrobert.soubiespam_OUTspamfree.frX (veuillez supprimer les "X")
* http://www.astrosurf.com/soubie
* Au royaume des aveugles, les borgnes sont mal vus... - P.Dac

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2004\01\07@135759 by William Chops Westfield

face picon face
>
>> Out of interest what is pathetic about the attempt to deliberately
>> fire a
>> watchdog timeout by using an infinite loop?  Surely you agree that it
>> is
>> good practice to trap invalid states such as this?
>
>
Without commenting on i2c, I think it's bad form form for code that is
essentially an IO library to decide on its own to cause a WDT.  if
some error occurs, that SHOULD be part of the API to whatever app is
using the i2c routines, and then IT can decide whether an
"unrecoverable i2c comm error" is a good reason to reset the entire
chip or not...

BillW

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2004\01\07@153733 by steve

flavicon
face
Robert,

> I suppose that for the purpose of this application note, the
> people with microchip decided to oversimplify the routines
> for better pedagogy.

I think that this is definitely the case and that too much is being read into
the WDT thing.
The writer of the Ap-note is caught between a rock and hard place -
either he provides a complete application and obscures the information
he is trying to explain, or he cuts it down to the bare minimum and gets
complaints that the solution is too simple.

There are obvious symptoms of this in the code itself. For example, the
foreground code is -

Main    clrwdt                  ; Clear the WDT
       goto            Main    ; Loop forever.

Clearly it is not a complete application.

In regards to the comment
; If we aren’t in State5, then something is wrong.

Look at the way you get to that point in the program flow

Is it status 1 ? No, try the next one.
Is it status 2 ? No, try the next one
Is it status 3 ? No, try the next one
Is it status 4 ? No, try the next one
Is it status 5 ?
There are no more situations that are valid, so it's an error.
If it was valid (at status 5), the function returns, ready for the next
transaction. That seems reasonable as a NACK is a valid thing and
there is nothing that needs to be done in response to getting one.

Steve.

==========================================
Steve Baldwin                          Electronic Product Design
TLA Microsystems Ltd             Microcontroller Specialists
PO Box 15-680, New Lynn                http://www.tla.co.nz
Auckland, New Zealand                     ph  +64 9 820-2221
email: stevespamspamtla.co.nz                      fax +64 9 820-1929
=========================================

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2004\01\07@160435 by John N. Power

flavicon
face
{Quote hidden}

     Try these Microchip application notes:

     AN515  "Communicating with I2C bus using PIC16C5X"
     AN541  "Using PIC16C5X as a smart I2C peripheral"
     AN554  "Software implementation of I2C bus master"  (OK, so it's about the master)

     John Power

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2004\01\08@035159 by Alan B. Pearce

face picon face
>>This comment "something went wrong" seems to imply that the
>>current state, that leads to i2cErr has no meaning there and
>>in fact should never happen; it appears to be confirmed by the
>>pathetic attempt to have the watchdog reboot the PIC by
>>executing a goto $ instruction...
>>
>
>Out of interest what is pathetic about the attempt to deliberately fire a
>watchdog timeout by using an infinite loop?  Surely you agree that it is
>good practice to trap invalid states such as this?

It also pays to bear in mind that this code does nothing other than handle
the I2C. The received data goes nowhere, it is "just" example code that will
perform correctly on an I2C system.

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2004\01\08@041521 by

picon face
> Out of interest what is pathetic about the attempt to
> deliberately fire a watchdog timeout by using an
> infinite loop?  Surely you agree that it is
> good practice to trap invalid states such as this?

Now, if your main project (where this example/library code
is used) does *not* use WDT, then it will just hang in an
infinit loop, not ?

Jan-Erik.

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2004\01\08@071612 by hael Rigby-Jones

picon face
>-----Original Message-----
>From: Jan-Erik Soderholm XA (TN/PAC)
>[jan-erik.xa.soderholmspamBeGonespam.....ERICSSON.COM]
>Sent: 08 January 2004 09:12
>To: KILLspamPICLISTspam.....MITVMA.MIT.EDU
>Subject: Re: [PIC:] Pic as an i2c slave
>
>
>> Out of interest what is pathetic about the attempt to deliberately
>> fire a watchdog timeout by using an infinite loop?  Surely you agree
>> that it is good practice to trap invalid states such as this?
>
>Now, if your main project (where this example/library code
>is used) does *not* use WDT, then it will just hang in an
>infinit loop, not ?
>
>Jan-Erik.

Right, but the code wasn't given as a "one size fit's all" solution to
anyones I2C requirements.  I don't know about you, but if I ever use a code
snippet or library written by someone else, I make sure I thoroughly
understand how it works and any requirements it has or assumptions it makes
rather than just relying on faith and plugging it in.

Mike




=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================
Any questions about Bookham's E-Mail service should be directed to
spam_OUTpostmasterspamKILLspambookham.com.

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2004\01\08@081614 by Alan B. Pearce

face picon face
part 1 2322 bytes content-type:text/plain; (decoded 7bit)

Attached is the I2C module that I derived from the AN734 application Note.
It is designed as a module for Olin's Development Environment, and needs the
following bits in the include file. These are an abbreviated set from the
include file that this particular project used. Note that the brd_stat_cmd
will do funny things inside the I2C interrupt on the next master read of the
slave, which is why the flag bits at the bottom are defined the way they
are. For further information on this development environment goto
http://www.embedinc.com/pic/ and download the environment files.

;   equates put here for global use

i2c_buff_size  equ .9             ; one buffer used for both tx & rx
int_buff_size  equ .9

;   Commands issued over I2C interface
brd_stat_cmd    equ 0x10        ; get status of board
brd_dnld_cmd    equ 0x11        ; download FPAA code
brd_send_cmd    equ 0x12        ; sending command from host to slave
brd_ret_data    equ 0x13        ; return data for transfer to host
brd_reset_stat  equ 0x14        ; reset error status ready for next command
brd_revision    equ 0x15        ; request revision information

;   Global flag bits.  As many GFL0 thru GFLn variables as needed are
;   automatically created by the /FLAG preprocessor directive.  After all
;   flags are defined, NFLAGB will be left indicating the number of GFLx
;   variables created.  For each flag, the string substitution macro
;   flag_<name> is defined to be "gfl<n>,<bit>".  The flag_<name> symbol
;   can be used directly with bit instructions.
;

#define main_status GFL0    ; define function of the first global flag byte

/FLAG   slave_OK        ; command processed normally
/FLAG   slave_ER        ; command processing error
/FLAG   slave_NI        ; command not implemented
/FLAG   slave_i2c_err   ; slave had unexplained i2c error in state machine
/FLAG   slave_unused    ; place holder to make this a complete byte
/FLAG   slave_data      ; data to be returned to host available
/FLAG   slave_busy      ; slave busy processing command
/FLAG   slave_dnld      ; slave processor requires code download

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics




part 2 20202 bytes content-type:text/plain;
(decoded quoted-printable)

;       This module is based on a concept developed by Olin Lathrop as outlined
;       in the following copyright notice. All additional code developed for the
;       end use product is Copyright (c) 2002, Rutherford Appleton Laboratory.
;
;   ***************************************************************
;   * Copyright (c) 2001, Embed Inc (http://www.embedinc.com)     *
;   *                                                             *
;   * Permission to copy this file is granted as long as this     *
;   * copyright notice is included in its entirety at the         *
;   * beginning of the file, whether the file is copied in whole  *
;   * or in part and regardless of whether other information is   *
;   * added to the copy.                                          *
;   *                                                             *
;   * The contents of this file may be used in any way,           *
;   * commercial or otherwise.  This file is provided "as is",    *
;   * and Embed Inc makes no claims of suitability for a          *
;   * particular purpose nor assumes any liability resulting from *
;   * its use.                                                    *
;   ***************************************************************
;
;       This code is based on Microchip Application Note AN734 (document
;       number DS00734) available at http://www.microchip.com
;
               include "csk.inc"

;               noexpand        ; turn off macro expansions

;
;***********************************************************************
;
;   Configuration constants.
;
lbank    equ     0      ;register bank for the local state of this module
;
;   Derived constants.
;
lbankadr equ     bankadr(lbank) ;address within local state register bank
;
;***********************************************************************
;
;   Global state.  All this state is assumed to be in the GBANK register
;   bank by other modules.
;
.bank#v(gbank) udata
i2c_count       res     1       ; count of bytes to receive
       global  i2c_count
i2c_address     res     1       ; address we will communicate with
       global  i2c_address

               extern  intr_ret

               extern_flags

;
;***********************************************************************
;
;   Local state.
;
 if lbank != gbank
.bank#v(lbank) udata
   endif

i2c_status      res     1               ; copy of SSPSTAT after address received
;i2c_address    res     1               ; our i2c address
;i2c_count      res     1               ; count of bytes
i2c_data_save   res     1
       fifo_define i2c_buff, i2c_buff_size


;       These port bit definitions are set up in the csk.ins file

;/inbit         i2c_scl portc 3         ; I2C Interface clock line
;/inbit         i2c_sda portc 4         ; I2C Interface data line


.i2c    code
;
;***********************************************************************
;
;   Subroutine i2c_INIT
;
;   Initialize the hardware and software state managed by this module.
;
       glbsub  i2c_init, noregs

       dbankif PCON
       bsf     PCON, NOT_POR
       bsf     PCON, NOT_BOR

       dbankif PORTB
       clrf    PORTB
       clrf    PIR1
       dbankif TRISB
       clrf    TRISB


;       ; <7> WCOL      (0) write collision - write to sspbuf invalid
;       ; <6> SSPOV     (0) overflow bit, new byte rx before holding reg cleared.
;       ; <5> SSPEN     (1)     enables SSP module
;       ; <4> CKP       (1) clock release, 1 = release, 0 = stretch clk
;       ; <3> SSPM3     (0)     } 0110 sets to use i2c 7 bit address with start and stop interrupts
;       ; <2> SSPM2     (1)     }
;       ; <1> SSPM1     (1)     }
;       ; <0> SSPM0     (0)     }

       dbankif SSPCON          ; initialize ports and registers
       movlw   b'00110110'
       movwf   SSPCON

       dbankif SSPCON2

;       ; <7> GCEN              1 = general call address intr enable
;       ; <6> ACKSTAT           not used in slave mode
;       ; <5> ACKDT             not used in slave mode
;       ; <4> ACKEN             not used in slave mode
;       ; <3> RCEN              not used in slave mode
;       ; <2> PEN               not used in slave mode
;       ; <1> RSEN              not used in slave mode
;       ; <0> SEN               not used in slave mode

       clrf    SSPCON2

       movlw   Dig_stat        ; set our address
       dbankif lbankadr
       movwf   i2c_address
       addwf   i2c_address,W   ; double it
       dbankif SSPADD
       movwf   SSPADD          ; and put in address register

       dbankif SSPSTAT

;       ; <7> SMP       (1) slew rate control
;       ; <6> CKE       (0) conforms to i2c specs (1 = SMBus spec)
;       ; <5> D/A       (0)     read only data/address bit
;       ; <4> P         (0) read only stop bit, 1 = stop detected last
;       ; <3> S         (0)     read only start bit, 1 = start detected last
;       ; <2> R/W       (0)     read only read/write bit, 1 = read operation
;       ; <1> UA        (0)     read only update address bit
;       ; <0> BF        (0)     read only buffer full status bit, 1 = buffer full

       clrf    SSPSTAT

       dbank   gbankadr
       bcf     flag_i2c_fifo_full

       dbankif lbankadr
       ibankif lbankadr
       fifo_init i2c_buff




;********************************************
;**********  interrupt stuff                *
;********************************************

; register is set to all 0 in init file

;       INTCON register: bit assignments
;       enables... 1=enable 0=disable
;
;       <7> GIE         = global_int_enable
;       <6> PEIE        = peripheral_int_enable
;       <5> T0IE        = t0_int_enable (enables <2> t0if)
;       <4> INTE        = int_enable (rb0/int) (enables <1> intf)
;       <3> RBIE        = rb_int_enable (enables <0> rbif)
;                                 intcon flags. software reset. 0=reset 1=flagged
;       <2> T0IF        = t0_int_flag
;       <1> INTF        = int_flag (rb0/int)
;       <0> RBIF        = rb_int_flag (rb7-rb4)

       bsf     INTCON,PEIE     ; turn on peripheral interrupts (if not already on)

;       register is set to all 0 in init file
;
;       PIE1/PIR1 peripheral interrupt enable 1 registers
;       bit assignments. 1=enable  0=disable
;
;       <7> PSPIE/PSPIF         = parallel_slave_port_int_enable
;       <6> ADIE/ADIF           = a/d_int_enable
;       <5> RCIE/RCIF           = receiver_int_enable for uart (may use later)
;       <4> TXIE/TXIF           = transmit_int_enable for uart (may use later)
;       <3> SSPIE/SSPIF         = sync_serial_int_enable
;       <2> CCP1IE/CCP1IF       = ccp1_int_enable
;       <1> TMR2IE/TMR2IF       = timer2_int_enable
;       <0> TMR1IE/TMR1IF       = timer1_int_enable

       dbankif PIR1
       bcf     PIR1,SSPIF      ; clear any pending interrupts

       dbankif PIE1
       bsf     PIE1,SSPIE      ; allow i2c interrupts

;********************************************
;**********  interrupt stuff done!          *
;********************************************

       dbankif gbankadr

       bsf     flag_i2c_idle   ; point out we are idle
                               ; all other flags cleared in hkp.init

                               ; Initialisation now complete

       leaverest               ; end of i2c module initialisation code


;********************************************************************
;*                                                                  *
;*      Interrupt driven I2C routine                                *
;*      This code is taken from the AN734 application note published*
;*      by Microchip, with minimal changes to modify it to use the  *
;*      macros and other features being used in this environment.   *
;*                                                                  *
;********************************************************************

       glbent  i2c_intr

       dbankif SSPSTAT
       getf    SSPSTAT

;---------------------------------------------------------------------
;       The I2C code below checks for 5 states:
;---------------------------------------------------------------------
;       State 1:        I2C write operation, last byte was an address byte.
;
;       SSPSTAT bits:   S = 1, D_A = 0, R_W = 0, BF = 1
;
;       State 2:        I2C write operation, last byte was a data byte.
;
;       SSPSTAT bits:   S = 1, D_A = 1, R_W = 0, BF = 1
;
;       State 3:        I2C read operation, last byte was an address byte.
;
;       SSPSTAT bits:   S = 1, D_A = 0, R_W = 1, BF = 0
;
;       State 4:        I2C read operation, last byte was a data byte.
;
;       SSPSTAT bits:   S = 1, D_A = 1, R_W = 1, BF = 0
;
;       State 5:  Slave I2C logic reset by NACK from master.
;
;       SSPSTAT bits:   S = 1, D_A = 1, R_W = 0, BF = 0
;
; For convenience, WriteI2C and ReadI2C functions have been used.
;----------------------------------------------------------------------

       dbankif lbankadr
       ibankif lbankadr

       andlw   b'00101101'         ; Mask out unimportant bits in SSPSTAT.
       movwf   i2c_status          ; for comparision checking.

i2c_State1                          ; Write operation, last byte was
       movlw   b'00001001'         ; an address, buffer is full.
       dbankif lbankadr
       xorwf   i2c_status,W
       skip_z                      ; Are we in State1?
       goto    i2c_State2          ; No, check for next state.....

       mcall   ReadI2C             ; Do a dummy read of the SSPBUF.
       dbankif gbankadr
       bsf     flag_i2c_address_seen
       goto    i2c_exit            ; and return from interrupt

i2c_State2                          ; Write operation, last byte
       movlw   b'00101001'         ; was data, buffer is full.
       dbankif lbankadr
       xorwf   i2c_status,W
       skip_z                      ; Are we in State2?
       goto    i2c_State3          ; No, check for next state.....

       fifo_skip_nfull i2c_buff, i2c_buff_size
       goto    i2c_fifo_overflow

       mcallr  ReadI2C, i2c_data_save  ; Get the byte from the SSP.

       dbankif gbankadr
       btfss   flag_i2c_address_seen
       goto    i2c_State2_put

       bcf     flag_i2c_address_seen   ; clear address seen flag while in bank
       dbankif lbankadr
       movlw   brd_stat_cmd        ; is it a status command
       subwf   i2c_data_save,W
       skip_z                      ; yes, so do special processing
       goto    i2c_State2_put      ; no, so put into buffer

       dbankif gbankadr
       bsf     flag_i2c_status_req ; show we have a status request
       goto    i2c_exit

i2c_State2_put
       dbankif lbankadr
       fifo_put i2c_buff, i2c_buff_size, i2c_data_save ; Put it in buffer.
       dbankif gbankadr
       bsf     flag_i2c_command    ; if there is a byte in buffer, then there is a command to execute
       goto    i2c_exit

i2c_State3                          ; Read operation, last byte was
       movlw   b'00001100'         ; an address, buffer is empty.
       dbankif lbankadr
       xorwf   i2c_status,W
       skip_z                      ; Are we in State3?
       goto    i2c_State4          ; No, check for next state.....

       dbankif gbankadr
       btfss   flag_i2c_status_req ; have we been asked for status ?
       goto    i2c_State3_get

       bcf     flag_i2c_status_req

       dbankif gbankadr
       getf    main_status         ; Yes, get status byte
       dbankif lbankadr
       movwf   i2c_data_save       ; and send it.
       mcall   WriteI2C
       goto    i2c_exit

i2c_State3_get
       dbankif lbankadr
       fifo_skip_nempty i2c_buff
       goto    i2c_State3_ND
       fifo_get i2c_buff, i2c_buff_size, i2c_data_save ; Get byte from buffer.
               goto    i2c_State3_sd

i2c_State3_ND
       clrw
       movwf   i2c_data_save

i2c_State3_sd
       mcall   WriteI2C            ; Write the byte to SSPBUF
       dbankif gbankadr
       bcf     flag_i2c_fifo_full
       goto    i2c_exit

i2c_State4                          ; Read operation, last byte was
       movlw   b'00101100'         ; data, buffer is empty.
       dbankif lbankadr
       xorwf   i2c_status,W
       skip_z                      ; Are we in State4?
       goto    i2c_State5          ; No, check for next state....

       dbankif lbankadr
       fifo_skip_nempty i2c_buff
       goto    i2c_State4_ND
       fifo_get i2c_buff, i2c_buff_size, i2c_data_save ; Get byte from buffer.
               goto    i2c_State4_sd

i2c_State4_ND
       clrw
       movwf   i2c_data_save

i2c_State4_sd
       call    WriteI2C            ; Write to SSPBUF
       dbankif gbankadr
       bcf     flag_i2c_fifo_full
       goto    i2c_exit

i2c_State5
       movlw   b'00101000'         ; A NACK was received when transmitting data
       dbankif lbankadr
       xorwf   i2c_status,W        ; back to the master.  Slave logic reset
       skip_z                      ; in this case.  R_W = 0, D_A = 1 and BF = 0
       goto    I2C_exit            ; If we arenít in State5, must be start or stop bit.

       bsf     SSPCON,CKP          ; Release the clock.
       dbankif gbankadr
       bsf     flag_i2c_wr_term    ; show the write was terminated
       goto    i2c_exit

i2c_fifo_overflow
       dbankif gbankadr
       bsf     flag_i2c_overflow   ; and fall through to interrupt exit.

;********************************************************************
;*                                                                  *
;*      Common exit point for Interrupt routine                     *
;*                                                                  *
;********************************************************************

i2c_exit
;        dbank   SSPSTAT
;        btfss   SSPSTAT,P              ; check stop bit
;       goto    I2C_Exit2               ; no so assume start bit
;
;        dbankif gbankadr
;        bsf     flag_i2c_idle  ; Set flag to show we are now idle
;        dbankif debugbit_reg
;        bsf            debugbit_pin
;        goto    i2c_exit3

;I2C_Exit2
       dbank   SSPSTAT
       btfss   SSPSTAT,S               ; check start bit
       goto    I2C_Exit3

       dbankif gbankadr
       bcf     flag_i2c_idle   ; reset flag to show we are not idle

       dbankif debugbit_reg
       bcf             debugbit_pin

I2C_Exit3
       dbankif PIR1
       bcf     PIR1,SSPIF              ; clear the interrupt that brought us here,
                               ; before starting another event

       gjump   intr_ret        ; to do restore of operating state

;---------------------------------------------------------------------
;               WriteI2C
;---------------------------------------------------------------------

       locsub  WriteI2C, noregs

       dbankif SSPSTAT
       btfsc   SSPSTAT,BF      ; Is the buffer full?
       goto    WriteI2C        ; Yes, keep waiting.

       dbankif SSPCON          ; No, continue.
DoI2CWrite
       bcf     SSPCON,WCOL     ; Clear the WCOL flag.
       dbankif lbankadr
       getf    i2c_data_save
       dbankif SSPBUF
       movwf   SSPBUF          ; Write the byte in WREG

       dbankif SSPCON
       btfsc   SSPCON,WCOL     ; Was there a write collision?
       goto    DoI2CWrite

       bsf     SSPCON,CKP      ; Release the clock.
       leave   noregs

;---------------------------------------------------------------------
;               ReadI2C
;---------------------------------------------------------------------

       locsub  ReadI2C, noregs

       dbankif SSPBUF
       movf    SSPBUF,W        ; Get the byte and put in WREG
       leave   noregs

;************************************************************************
;*                                                                      *
;*      Non Interrupt Interface routines for reading and writing Fifo   *
;*                                                                      *
;************************************************************************

       glbsub  i2c_write_buffer, noregs

;
;       Input
;       Reg0    - character to be transmitted
;       Flag_I2C_Fifo_Full      - if set on entry then char ignored.
;
;       Returns
;       Flag_I2C_Fifo_Full      - set if character fills fifo to limit
;
;       The fifo will be filled until the fifo is full. It is possible to
;       transfer further characters to the Fifo while transmission is in progress,
;       provided the receiving i2c device can handle the data block.
;
;       If the fifo is already full when attempting to send another character,
;       then the character in Reg0 is ignored.
;

       dbankif gbankadr        ; get the register banks right
       ibankif lbankadr

       btfsc   flag_i2c_fifo_full  ; check fifo full flag
       goto    i2c_wr_fifo_full    ; if it was set before do not deal with char.

       dbankif lbankadr        ; fifo's are in lbank
       intr_off                ; disable interrupts while actively dealing with fifo
       fifo_skip_nfull i2c_buff, i2c_buff_size ; check flag not been fiddled
       goto    i2c_wr_fifo_full    ; skip putting character
       dbankif lbankadr            ; fifo's are in lbank
       fifo_put i2c_buff, i2c_buff_size, Reg0
       fifo_skip_full  i2c_buff, i2c_buff_size
       goto    i2c_wr_fifo_exit

i2c_wr_fifo_full
       clrf    Reg0            ; unable to read buffer, so clear Reg0
       intr_on                 ; enable interrupts now round awkward code
       dbank   gbankadr
       bsf     flag_i2c_fifo_full
i2c_wr_fifo_exit
       intr_on                 ; enable interrupts because previous intr_on should get skipped
       leave   noregs

;********************************************************************

       glbsub  i2c_read_buffer, noregs

;       Read a character from the i2c Fifo. If the Fifo is empty, then set
;       the flag_i2c_rd_complete bit. Returns with character in Reg0.
;       Reg0 will be invalid if fifo was empty on entry.

       dbankif lbankadr        ; get the banks set correct
       ibankif lbankadr

       intr_off
       fifo_skip_nempty i2c_buff
       goto    i2c_rd_fifo_empty   ; skip getting character
       fifo_get i2c_buff, i2c_buff_size, Reg0
       fifo_skip_empty i2c_buff
       goto    i2c_rd_buffer_exit

i2c_rd_fifo_empty
       dbankif gbankadr
       bsf     flag_i2c_rd_complete

i2c_rd_buffer_exit
       dbank   gbankadr
       bcf     flag_i2c_fifo_full
       intr_on
       leave   noregs

;********************************************************************

       glbsub  i2c_flush_buffer, noregs

;       Clear the buffer by doing an init to flush any junk left
;       after a timeout on the i2c bus.

       dbankif lbankadr
       ibankif lbankadr

       intr_off
       fifo_init i2c_buff
       intr_on

       leave   noregs
;********************************************************************

       glbsub  i2c_buffer_stat, noregs

;       Return with i2c fifo byte count into Reg0

       dbankif lbankadr
       ibankif lbankadr

       intr_off
       getf    i2c_buff    ; get buffer full count
       movwf   Reg0
       intr_on

       leave   noregs

;********************************************************************

       glbsub  i2c_debug_flag, noregs

;       Flip the debug bit low momentarily to trigger oscilloscope
;       on event.

       dbankif debugbit_reg
       bcf     debugbit_pin
       waitnop 10
       bsf     debugbit_pin

           leaverest


   end


--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics



2004\01\08@093048 by Paul James E.

picon face
All,

If it's assembly you want, have a look at "Serial PIC'n" from
the David Benson collection.  It has all sorts of routines for
hardware based comms to Bit Bang comms.  It's a virtual cookbook
of copy and paste routines for almost any serial communications task.
The book is about $50.00, but it's money well spent.  I wouldn't
trade my copy for anything.

                                               Regards,

                                                 Jim


{Quote hidden}

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2004\01\08@120014 by Josh Koffman

flavicon
face
I second that reccomendation. The Square 1 books (http://www.sq-1.com)
are great, and David is a genuinely nice guy. Plus, it's kinda cool to
be able to call up the company and talk to the author! There are some
that are huge fans of his code, but when used as a starting point, I
think it's excellent.

Josh
--
A common mistake that people make when trying to design something
completely foolproof is to underestimate the ingenuity of complete
fools.
       -Douglas Adams

"Paul James E." wrote:
>  If it's assembly you want, have a look at "Serial PIC'n" from
>  the David Benson collection.  It has all sorts of routines for
>  hardware based comms to Bit Bang comms.  It's a virtual cookbook
>  of copy and paste routines for almost any serial communications task.
>  The book is about $50.00, but it's money well spent.  I wouldn't
>  trade my copy for anything.

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2004\01\17@164205 by Robert Soubie

flavicon
face
On Thu, 8 Jan 2004 13:15:04 -0000, Alan B. Pearce wrote on
Re: [PIC:] Pic as an i2c slave:

>Attached is the I2C module that I derived from the AN734 application Note.

Thanks again for this code, Alan; you did what my initial
humble request to the Piclist implied, i.e. you sent me some
working code, the very first I have seen that had been
corrected for the error in Microchip's application note.

This has allowed me to correct my routines; they work
reliably now with either of my i2c interfaces.

Now that I know what was missing and where, things look as
if that mystery could have been easy to solve; as you know
by now, it was not easy for me, nor was it obviously for
many people who have tried to work their way out of AN734
and miserably failed: as a testimony of this, some people
(from this list) even sent me code that had not been
corrected, saying "this works for me"... Even the people
that wrote my excellent compiler have a non working example
on their site.
I want to thank all those on this list and on the PicBasic
list who tried to help or even did help in a friendly,
ccoperative, and dare I say altruist manner, namely:

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.

I think it is important that the information on how to
implement an i2c slave with a PIC be available in the
future; consequently I have written a page that presents the
working routines in my switching power supply application as
an example that could be modified to suit other needs.

For this same application, which uses a Dallas
Semiconductors DS1820 onewire sensor and a PID algorithm to
regulate the temperature of a CCD camera's Peltier-cooled
sensor, I have written reusable routines that allow
detecting the presence of the sensor, getting its
temperature with the highest level of resolution it allows,
and displaying in one of two units (Celsius and Farenheit)
or one of two scales (Kelvin and Rankine).
These routines answer frequently asked questions on how to
store then display signed values using positive integer
arithmetics, by using offsetting and scaling techniques.

They are available for download from the following URL:

http://astrosurf.com/soubie/microcontroleurs.htm

With minor restrictions (see on download page), they may
freely be used in any context, including "for profit".

* RemoveMEXrobert.soubieRemoveMEspamEraseMEfree.frX (veuillez supprimer les "X")
* http://www.astrosurf.com/soubie
* Au royaume des aveugles, les borgnes sont mal vus... - P.Dac

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2004\01\17@165223 by

picon face
And the screen shows "FIN" in big letter and everyone
leaves the cinema with a big happy smile on there face !

Excellent finish to this thread !!

Merci Robert !

Jan-Erik.


Robert Soubie wrote :

{Quote hidden}

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2004\01\17@171534 by Igor Pokorny

flavicon
face
Hello Jan-Erik,

No one could say it better..

Igor

-----Original Message-----
From: pic microcontroller discussion list
[PICLISTspamspamMITVMA.MIT.EDU] On Behalf Of Jan-Erik Soderholm XA
(TN/PAC)
Sent: Saturday, January 17, 2004 10:52 PM
To: RemoveMEPICLISTspamBeGonespamRemoveMEMITVMA.MIT.EDU
Subject: Re: [PIC:] Pic as an i2c slave


And the screen shows "FIN" in big letter and everyone
leaves the cinema with a big happy smile on there face !

Excellent finish to this thread !!

Merci Robert !

Jan-Erik.

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2004\01\17@171826 by Ken Pergola

flavicon
face
Hi Robert,

I'm just a little confused here. If I understand you correctly, you
mentioned there are two versions of app note AN734.
From what I've been accustom to, Microchip denotes their document revisions
with a letter suffix on their document number.

The only document # I can find on AN734 is '00734A' which would indicate
that this is the first and only version to date.
If there are two versions, I'd like to compare the two, but I can only find
one published version:

Title:          Using the PICmicro SSP for Slave I2C Communication
Name:           AN734
Date:           08/07/2000
Author:         Stephen Bowling
Document #: 00734A


Could you or someone shed light on this?

Thank you kindly.

Best regards,

Ken Pergola

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2004\01\17@182519 by Robert Soubie

flavicon
face
On Sat, 17 Jan 2004 17:18:29 -0500, Ken Pergola wrote on Re:
[PIC:] Pic as an i2c slave:

>I'm just a little confused here. If I understand you correctly, you
>mentioned there are two versions of app note AN734.
>From what I've been accustom to, Microchip denotes their document revisions
>with a letter suffix on their document number.

I am no specialist in Microchip AN numbering, but I have
always believed that an AN with a letter added had to be a
corrected version; further, if you give a look at the list
of ANs at:

http://www.microchip.com/1010/suppdoc/appnote/alpha/index.htm,

you will notice that some of them (00575.pdf, 00584.pdf,
etc) do not have a letter after the number. I suppose they
are the original, uncorrected versions.

{Quote hidden}

I suppose that the thing to do when some documentation is
corrected or complemented, is to get rid of the old,
erroneous information which has just been superceeded.

This could explain why AN734 is nowhere to be found.

* KILLspamXrobert.soubiespamBeGonespamfree.frX (veuillez supprimer les "X")
* http://www.astrosurf.com/soubie
* Au royaume des aveugles, les borgnes sont mal vus... - P.Dac

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2004\01\17@184218 by Ken Pergola

flavicon
face
Hi Robert,

Thanks for your response -- I appreciate your time. Ok, I misunderstood you.
I thought you personally had seen two *different* versions of app note
AN734. This thread piqued my interest and I wanted to see both versions for
myself to see what corrections were made. I archive most data sheets I
download for future reference.

Thanks for the clarification and I'm glad your project is working. I'm all
set on this.

Best regards and take care,

Ken Pergola

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2004\01\19@043802 by Alan B. Pearce

face picon face
>>Attached is the I2C module that I derived from the AN734 application Note.
>
>Thanks again for this code, Alan; you did what my initial

You're welcome. Glad to hear it solved your problem. I hope all the other
project specific bits that I had put in did not confuse you too much.

The thanks also go to those who pointed this error out for me before I got
into the coding of this section of the project I was doing at the time, and
as a result I was saved a fair amount of time.

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

More... (looser matching)
- Last day of these posts
- In 2004 , 2005 only
- Today
- New search...