"C" source code for I2C slave PIC16F81x

On 16 Feb 2005 10:23:36 -0800, Tesvit wrote:

>> Check out application note AN734 "Using the PICmicro SSP for Slave I2C
>> Communication" at www.microchip.com. Good description of the SSP and C
>> source code example.
> 
> Hi Bob,  
> Thank you for URL.  I checked it:
> http://ww1.microchip.com/downloads/en/AppNotes/00734a.pdf but there is
> just assembler source.  I need "C" one...
> 
> Regards,
> tesvit.

The MPLAB C18 C compiler Library has several I2C functions in C. Don't know
about Hi-Tech.


Bob

Tesvit wrote:
>>Check out application note AN734 "Using the PICmicro SSP for Slave I2C
>>Communication" at www.microchip.com. Good description of the SSP and C
>>source code example.
> 
> 
> Hi Bob,  
> Thank you for URL.  I checked it:
> http://ww1.microchip.com/downloads/en/AppNotes/00734a.pdf but there is
> just assembler source.  I need "C" one...
> 
> Regards,
> tesvit.

So what?

Just rewrite it in C, if you prefer. You cannot avoid at least
reading assembler code if you will to get anywhere in the small
controller world. It pays to get the assembler listings of the
compiler output and have a look at surprises in code generation.
A seemingly innocent C construction can expand to a machine
code monster, and you'll notice where to improve.

-- 

Tauno Voipio
tauno voipio (at) iki fi

John Temples wrote:
> In article <4213783E.1A578224@yahoo.com>, CBFalconer wrote:
> 
>> Then I suspect you should not be using any PIC.  Their capabilities
>> do not include executing standards conforming C code, and anything
>> you do is pure guesswork.
> 
> That's a bit of an exaggeration.  The PIC C I use has one deficiency
> from the standard:  support for recursion.  That does not render the
> rest of what I do as "pure guesswork."

Is it?  Let's just take the 15 year old C90 standard.  Can it build
an object of 32767 byte size?  Can it do long arithmetic (32 bit
minimum).  Can it do int arithmetic (16 bit minimum).  Note I am
not asking for anything from the standard library, or to do with
files.  I realize that recursion is impossible on a PIC.

The point is not whether a C system that misses such attributes is
useful (it is), but that without an understanding of assembly the
OP cannot evalueate what code is generated for his source, and has
no clue of what sort of things to avoid.  If you can generate
assembly for the basic operations you have a good idea of what the
compiler has to juggle.

PIC assembly is so simple that anyone should be able to pick it up
in a few days.  This doesn't mean they will be facile in it.

-- 
"If you want to post a followup via groups.google.com, don't use
 the broken "Reply" link at the bottom of the article.  Click on 
 "show options" at the top of the article, then click on the 
 "Reply" at the bottom of the article headers." - Keith Thompson

In article <4213D109.6B16BC12@yahoo.com>, CBFalconer wrote:
>> That's a bit of an exaggeration.  The PIC C I use has one deficiency
>> from the standard:  support for recursion.  That does not render the
>> rest of what I do as "pure guesswork."
> 
> Is it?  Let's just take the 15 year old C90 standard.  Can it build
> an object of 32767 byte size? 

That is not a requirement for a freestanding implementation; but in
any event, it can:

$ cat t.c

const unsigned char array[32767] = { 0 };

void main(void)
{
}

$ picc18 -18f6720 t.c
HI-TECH PICC-18 COMPILER (Microchip PIC18) V8.35PL2

[...]

Program statistics:

Total ROM used    32783 bytes (25.0%)
Total RAM used        0 bytes (0.0%)   Near RAM used        0 bytes (0.0%)

> Can it do long arithmetic (32 bit minimum).
> Can it do int arithmetic (16 bit minimum).

Yes, as well as 24- and 32-bit floats.  From limits.h:

#define INT_MAX     32767       /* max for int */
#define INT_MIN     (int)-32768 /* min for int */
#define UINT_MAX    65535       /* unsigned int */
#define LONG_MAX    2147483647  /* max value of long */
#define LONG_MIN    (long)-2147483648   /* min value */
#define ULONG_MAX   4294967295  /* unsigned long */

> Note I am not asking for anything from the standard library

It has a fairly complete implementation of the standard library.
About all that's missing is the malloc() family.

> I realize that recursion is impossible on a PIC.

No, it is not.  Some C compilers for the PIC implement a software
stack, permitting recursion and reentrancy.

-- 
John W. Temples, III

John Temples wrote:
> In article <4213D109.6B16BC12@yahoo.com>, CBFalconer wrote:
> 
>>> That's a bit of an exaggeration.  The PIC C I use has one
>>> deficiency from the standard:  support for recursion.  That does
>>> not render the rest of what I do as "pure guesswork."
>>
>> Is it?  Let's just take the 15 year old C90 standard.  Can it
>> build an object of 32767 byte size?
> 
> That is not a requirement for a freestanding implementation; but
> in any event, it can:
> 
> $ cat t.c
> 
> const unsigned char array[32767] = { 0 };
> 
> void main(void)
> {
> }
> 
> $ picc18 -18f6720 t.c
> HI-TECH PICC-18 COMPILER (Microchip PIC18) V8.35PL2
                            ^^^^^^^^^^^^^^^
> 
... snip ...
> 
>> I realize that recursion is impossible on a PIC.
> 
> No, it is not.  Some C compilers for the PIC implement a software
> stack, permitting recursion and reentrancy.

We are not talking about the same PIC. <grin>  Mine have no more
than 256 bytes of memory, and no way to read the subroutine stack,
etc.

At any rate, I consider the ability to handle assembly language
essential in exactly 98.375% of embedded applications. :-)

-- 
"If you want to post a followup via groups.google.com, don't use
 the broken "Reply" link at the bottom of the article.  Click on 
 "show options" at the top of the article, then click on the 
 "Reply" at the bottom of the article headers." - Keith Thompson

"Tauno Voipio" <tauno.voipio@iki.fi.NOSPAM.invalid> wrote in message
news:8oPQd.687$Mf.467@read3.inet.fi...
> Tesvit wrote:
> >>Check out application note AN734 "Using the PICmicro SSP for Slave I2C
> >>Communication" at www.microchip.com. Good description of the SSP and C
> >>source code example.
> >
> >
> > Hi Bob,
> > Thank you for URL.  I checked it:
> > http://ww1.microchip.com/downloads/en/AppNotes/00734a.pdf but there is
> > just assembler source.  I need "C" one...
> >
> > Regards,
> > tesvit.
>
> So what?
>
> Just rewrite it in C, if you prefer. You cannot avoid at least
> reading assembler code if you will to get anywhere in the small
> controller world. It pays to get the assembler listings of the
> compiler output and have a look at surprises in code generation.
> A seemingly innocent C construction can expand to a machine
> code monster, and you'll notice where to improve.

Agreed.  I wrote my own EEPROM write routine after I saw the assembler
listing of how CCS PICC was doing it.

On the other hand, I converted an 68HC705 assembly program to ByteCraft C
some years ago as the first step in adding some features.  I was surprised
to see that the resulting object code was smaller than the original
assembler.  I studied the assembler listing from the C code to find out how
they did the improvements.

"CBFalconer" <cbfalconer@yahoo.com> wrote in message
news:42145972.AC8AA721@yahoo.com...
>
> At any rate, I consider the ability to handle assembly language
> essential in exactly 98.375% of embedded applications. :-)

As long as you stay away from C++ horrors, C is a convenient shorthand way
to write assembler.  I have found that I can then tweak with #ASM where
needed if the C output is messy.

I guess it depends whether your primary software speed issue is "How fast
will it run?" or "When will you be done?"

> At any rate, I consider the ability to handle assembly language
> essential in exactly 98.375% of embedded applications. :-)

Even if I agree with you I should confess that I belong to those
firmware developers that deal with quoted 1.625% applications.

My previous project has been developed entirely in C and we even did
not consider assembler.  Knowing that our HEX code use 96% of
PIC18F8720 ROM (125830 bytes) and that source code is about 450KB
[O.K. with comments :-)] it is obvious why we decided to use C instead
of assembler.

Again, I agree that it is nice if firmware developer know assembler. 
But...

Well, I read AN734 and rewrite it in C.
Thank you guys.

On Thu, 17 Feb 2005 07:30:30 -0800, Richard Henry wrote:

>> At any rate, I consider the ability to handle assembly language
>> essential in exactly 98.375% of embedded applications. :-)

I used to feel that way, but these days I'd say that at least 98.375% of my
embedded work is handled entirely in C - with occaisional inline assembler
hacks.


Bob