I have to write an PIC16F819 based application that act as I2C slave device. As for compiler I will use HI-TECH PICC together with MPLAB. Could anyone, please, send me sample "C" code for that. I have no assembler knowledge :-( Any link/source/hint would be appreciated.
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...
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.
"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
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.
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.
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...