1. This forum section is a read-only archive which contains old newsgroup posts. If you wish to post a query, please do so in one of our main forum sections (here). This way you will get a faster, better response from the members on Motherboard Point.

"C" source code for I2C slave PIC16F81x

Discussion in 'Embedded' started by Tesvit, Feb 16, 2005.

  1. Tesvit

    Tesvit Guest

    Hi All,

    I have to write an PIC16F819 based application that act as I2C slave
    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.

    Thank you,

    Tesvit, Feb 16, 2005
    1. Advertisements

  2. 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,


    Best Regards,
    Ulf Samuelsson

    This message is intended to be my own personal view and it
    may or may not be shared by my employer Atmel Nordic AB
    Ulf Samuelsson, Feb 16, 2005
    1. Advertisements

  3. Tesvit

    Tauno Voipio Guest

    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.
    Tauno Voipio, Feb 16, 2005
  4. Tesvit

    Wim Guest

    I2C Slave is implemented in hardware on an 18F819/819.
    Which will reduce the complexity of your software
    Wim, Feb 16, 2005
  5. Tesvit

    Bob Stephens Guest

    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.

    Bob Stephens, Feb 16, 2005
  6. Tesvit

    Tesvit Guest

    I2C Slave is implemented in hardware on an 18F819/819.

    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.
    Tesvit, Feb 16, 2005
  7. Tesvit

    CBFalconer Guest

    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.
    CBFalconer, Feb 16, 2005
  8. Tesvit

    John Temples Guest

    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."
    John Temples, Feb 16, 2005
  9. Tesvit

    Tesvit Guest

    Tesvit, Feb 16, 2005
  10. Tesvit

    tesvit Guest

    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).
    tesvit, Feb 16, 2005
  11. Tesvit

    Bob Stephens Guest

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

    Bob Stephens, Feb 16, 2005
  12. Tesvit

    Tauno Voipio Guest

    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, Feb 16, 2005
  13. Tesvit

    CBFalconer Guest

    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.
    CBFalconer, Feb 17, 2005
  14. Tesvit

    John Temples Guest

    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.
    John Temples, Feb 17, 2005
  15. Tesvit

    CBFalconer Guest

    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,

    At any rate, I consider the ability to handle assembly language
    essential in exactly 98.375% of embedded applications. :)
    CBFalconer, Feb 17, 2005
  16. 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.
    Richard Henry, Feb 17, 2005
  17. 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?"
    Richard Henry, Feb 17, 2005
  18. Tesvit

    Tesvit Guest

    At any rate, I consider the ability to handle assembly language
    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.
    Tesvit, Feb 17, 2005
  19. Tesvit

    tesvit Guest

    Well, I read AN734 and rewrite it in C.
    Thank you guys.
    tesvit, Feb 17, 2005
  20. Tesvit

    Bob Stephens Guest

    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

    Bob Stephens, Feb 17, 2005
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.