1) Has anyone used the IICBUS.C library? It doesn't work for me. I changed things where appropriate, like the device address, etc., but nothing. Also, nowhere in the library does it set the SCL pin as an output. I made this change and it still doesn't work. 2) The STDIO.C library from Spark Fun has some odd behavior. My Main() function calls an init() function, which as the last thing does a printf().

The next line in Main() does a putc(). The printf() works, but the putc() doesn't. Mp3 songs free download telugu. If I put the putc() in the init() function right after the printf() it works. I haven't used the I2C library for CC5X so I can't be much help there. I wrote software routines for I2C and a tutorial which you can find here:.

Also, the are different ways to talk to different EEProms. If your EEPROM is >= 32kbits in size, you'll have to transmit two address byte to the prom.

Aug 14, 2013  Re:Config word with cc5x compiler 2013/08/14 06:12:05 +1 (1) You don't need to include the header file, it is included automatically from the project settings. Okay, I figured out the putc() problem. It's not a problem with the stdio.c library, but a problem with the CC5X compiler. The compiler is placing a SLEEP command at the end of the program, which prevents the data waiting to transmit, or being transmitted, from completing.

I'm not sure how the CC5X library handles this. As for the printf working and the putc not working - my guess is that you are enabling the UART printf something, and then disabling the UART. Hence, the putc wouldn't work. Printf uses a series of putc's so the putc function is working and then not. Are you setting the TRISB (assuming a 16F628 or F88 chip) bits to 1 for inputs? This would cause the TX pin not to work. Reverse is true for RX.

RX must be set as an input. Code: while(TXIF == 0); TXREG = 'x'; See if you can get that working.

If no, it's a hardware problem. If yes, then its a software problem and you best start diging into those function calls. It just occurd to me that you may be using some other stdio file as opposed to the one I wrote and is found on sparkfun.com In fact, if you DON'T have the while(TXIF == 0); statement in there, you most certainly will get the phenomena you are currently experiencing. If you do a printf, the subroutine has to calculate place holders and load character values, it takes time. Enough time that the TX buffer may be able to send out the characters fast enough you don't need to check if the TX buffer is ready for a new character. If you fire off a bunch of characters via the putc() routine, this is VERY fast and if you are not checking the TX ready bit, then you just keep over-writing whats there and nothing gets sent. My prediction.

Let me know if I'm way off, -Nathan. I would get my i2c routines online, but currently the breadboard is being used for the wireless bits (just to test they work, oh and re-writing ur test routine + making some libaries ) There is also a LCD connected that i am playing with. Its a mess, and only one wireless unit is connected, lol. Oh and i have got 3V - 5V problems sorted. Using dividers and some transistory bits (and a 3V reg) i have everything sorted. Next its onto the bootloader. Thinking of not using CRC and manchestering.