"C" source code for I2C slave PIC16F81x

"Tesvit" skrev i meddelandet news: snipped-for-privacy@posting.google.com...

There is an AVR application note written in assembler. - Might be easier to run on an AVR though ;-) I am sure there hsould be something for the PIC though,

google?

An I2C slave is more difficult to implement in software than a master, due to the fact that the master is controlling the timings alone.

You need at least a hardware clock clamp to make sure that the slave can catch up with the master.

See the I2C specifications on clock stretching and bus synchronization.

I2C Slave is implemented in hardware on an 18F819/819. Which will reduce the complexity of your software

Check out application note AN734 "Using the PICmicro SSP for Slave I2C Communication" at

Bob

Hi,

Yes, I found that 16F819 support slave I2C in hardware. But fastest way is modify an working "C" sample. All sources I found are in assembler and are not suitable for me because I can not modify it :-( My assembler knowledge is too poor...

Thank you.

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."

Hi Bob, Thank you for URL. I checked it:

Regards, tesvit.

Hi, As I sent in my first message, I am using HI-TECH's PICC compiler that has just few limitations (lack of recursion and some pointer-to-function issues). Cheers!

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

Bob

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.

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.

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%)

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 */

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

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

^^^^^^^^^^^^^^^

... snip ...

We are not talking about the same PIC. 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. :-)

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.

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?"

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.

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