Problems with CC5X

[upand_at_them]

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. If I put the putc() in the init() function right after the printf() it works.

Mike

[sparky]

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: http://www.sparkfun.com/tutorial/coding/5-i2c.htm. 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. 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.

-Nathan

[upand_at_them]

I modified the CC5X library to handle the two-byte address of the 24C256, but it still didn't work. I'll take a look at the I2C stuff you have, thank you.

As for the putc() problem...my code looks like this:

void init(void)
{
...code for setting up UART and TRISB...

printf("balloon/r/n", 0);
}

void main(void)
{
init();
putc('Q');
}


The first printf() works, and I don't do anything to the UART or the TRIS registers after that. The putc() doesn't work no matter how many times I call it. If I use a printf() instead of a putc(), however, it does print.

I know that printf() uses putc() which is what makes this bizarre.

And I've witnessed strange behavior with putc() before. I have one program that does something like this:

for (i=0; i<8; i++)
{
putc('X');
}

and it only printed 5 X's.

Mike

[upand_at_them]

Okay, here is an example of the putc() problem. This output should look like this:

Hello
QAX

But instead it looks like this:

Hello
Q

That's it. The putc() calls in main don't work.

Mike



#include "c:\Program Files\cc5x\hdr\16F88.h"
#pragma origin 4
#include "c:\Program Files\cc5x\lib\Stdio.c" // serial IO library

void init()
{
PORTB = 0b.0000.0000;
TRISB = 0b.0000.0100;

SPBRG = 51;
TXSTA = 0b.0010.0100; //8-bit asych mode, high speed uart enabled
RCSTA = 0b.1000.0000; //Serial port enable, 8-bit asych non-continous receive mode

printf("Hello\r\n", 0);
putc('Q');
}


void main()
{
init();

putc(65);
putc('X');
}

[sparky]

You've got some really funny bugs going on.

I would replace the putc('x') with:

Code: Select all

    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

[upand_at_them]

Nathan,

Did you try the code I posted above? It uses the stdio.c library of yours and defines putc() as:

void putc(uns8 nate)
{
while(TXIF == 0);
TXREG = nate;
}

so it is the correct definition. I tried replacing putc() with the definition and got the same results. I don't think that necessarily means a hardware problem. I tried it with large delays between putc()'s and got similar results.

Mike

[pittuck]

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. I hope... Next its onto the bootloader. Thinking of not using CRC and manchestering...

[upand_at_them]

I got my I2C routines written and working late last night.

Now if I could just figure out that nasty putc() problem.

Mike

[upand_at_them]

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 removed the SLEEP command from my test ASM file and used a forever loop instead. Problem solved.

Although, I think going into the SLEEP mode is alright as long as it first handles the data waiting to be transmitted.

Mike

[sparky]

Wow! Nice job.

I think I do remember having that problem as well. I now have a habbit of putting a while(1); statement at the end of the main loop to prevent the PIC from ever getting out of the main loop or going to sleep.

-Nathan

[MJ]

I've wrastled with the same issue you did before and can't seem to figure it out;.. I've used Nathan's code (making the appropriate changes for the F88), and also the built-in CC5X i2c routine, IICBUS.c--both without success.

Any sample code postings would be appreciate for use of the F88 with an external eeprom--written in cc5x, that is.

Thanks!
Jeff