EmbeddedRelated.com
Forums
Memfault State of IoT Report

"C" source code for I2C slave PIC16F81x

Started by Tesvit February 16, 2005
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

Memfault State of IoT Report