View previous topic :: View next topic |
Author |
Message |
Guest 1 Guest
|
kbhit problem |
Posted: Tue May 26, 2009 1:31 pm |
|
|
Hi all,
I'm having trouble using the kbhit function. For some reason it does not see a keyboard hit. Here's a snippet of code:
Code: | #use rs232(baud=19200,xmit=pin_a1,rcv=pin_a0,bits=8, parity=n, errors)
while(kbhit())
{
printf("\nok");
delay_ms(1000);
menu_screen();
}
void menu_screen(void)
{
key_pressed = 1; // flag set
while(key_pressed == 1)
{//while
// hyper terminal screen
printf("\033[2J'r'eset timer, 'l'ist user time, 's'et user time, 'e'xit");
// wait for character from keyboard
download = getc();
etc.........
}
|
I've tried moving the kbhit into the function, using different baud rates, pretty much everything I can think of. I know the code gets there as I've used a printf statement. I also know the hardware works ok as it has been working on the odd occasion. Strange but true!!
So, is it a buffer problem? if so, how can I check this?
The chip is a 12F629 and the compiler version is 3.230. I'm using the 4MHz internal clock and am using timers 0 and 1 (if thats any help!).
One more point - sometimes the printf text is a bit corrupt.
Thanks in advance!!! |
|
|
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
Posted: Tue May 26, 2009 1:57 pm |
|
|
You are using a software UART. The CCS library code for a software
UART looks for the start bit (kbhit) of an incoming byte by polling the
'rcv' pin in a software loop. If your code is doing some lengthy, time-
consuming operation such as a printf, the PIC won't be able to poll the
rcv pin at the required time. It will miss the incoming byte. Or it will
detect a false 'start' bit, by sensing a low bit in the middle of an incoming
byte.
Sending data with printf with a software UART, is done by "bit banging"
the 'xmit' pin. The out-going bits are set high or low, and a software
delay loop provides the time interval between bits, for your specified
baud rate. The PIC can't do anything else while it's transmitting the
bytes. It can't poll the rcv pin for an incoming start bit (kbhit). |
|
|
Guest
|
|
Posted: Tue May 26, 2009 2:07 pm |
|
|
Hi,
Thanks for the prompt reply.
How can I get around this problem? Do I have to structure my code in a different fashion? To be honest it's quite short due to the size of the memory on the chip. I do, however, need to have communincation with the rs232 to load in different values to the eeprom hence the requirement for the prinf.
Thanks again, any help is welcome!! |
|
|
asmboy
Joined: 20 Nov 2007 Posts: 2128 Location: albany ny
|
this may help |
Posted: Tue May 26, 2009 2:37 pm |
|
|
the following ref has code to use the interrupt feature for RECEIVE
and a simple - timer based method to improve your XMIT integrity odds ,
by only XMITting when no receive data is happening. ( more or less)
http://www.ccsinfo.com/forum/viewtopic.php?t=38922&highlight= |
|
|
Guest
|
|
Posted: Tue May 26, 2009 3:22 pm |
|
|
Hi all,
The problem is becoming more clear now.
Unfortunately, I can't use the ext int pin as it's already being used. Every pin on the chip is being used due to the amount of io available.
Should I change PIC processors? Or should I stop using the kbhit command?
Cheers. |
|
|
asmboy
Joined: 20 Nov 2007 Posts: 2128 Location: albany ny
|
rearrange IO? |
Posted: Tue May 26, 2009 4:28 pm |
|
|
is this a locked down bit o hardware ?
i don't quite understand - since per the spec sheet - ANY pin can interrupt
quoting:
Quote: | 3.2 Additional Pin Functions
Every GPIO pin on the PIC12F629/675 has an
interrupt-on-change option and every GPIO pin, except
GP3, has a weak pull-up option. |
|
|
|
Guest
|
|
Posted: Wed May 27, 2009 1:51 am |
|
|
Hi,
I'm using GP2, the EXT_INT pin, as a counter via TOCK1. At the moment the RS232 is configured to GP0 - rcv and GP1 - xmit. When they talk about pins being configured as int's does this an interrupt-on-change? Sorry if I'm being a little vague but this is a bit new for me |
|
|
|