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
Problems with CC5X
Moderator: phalanx
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
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
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');
}
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');
}
You've got some really funny bugs going on.
I would replace the putc('x') with:
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 replace the putc('x') with:
Code: Select all
while(TXIF == 0);
TXREG = 'x';
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
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
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...
)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
-
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
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
-
MJ
Could you post your I2C routines?
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
Any sample code postings would be appreciate for use of the F88 with an external eeprom--written in cc5x, that is.
Thanks!
Jeff