Problem with a delay before a getc() function

[Mustang1945]

Hi, i am from Ecuador, South America, i am working on a project but i have a strange problem here:

Does not work because i have a delay before getc() and kbhit().

#include <16F877A.h>
#include <string.h>
#include <stdlib.h>

#FUSES NOWDT //No Watch Dog Timer
#FUSES XT
#FUSES NOPUT //Power Up Timer
#FUSES NOPROTECT //Code not protected from reading
#FUSES NOBROWNOUT //No brownout reset
#FUSES NOCPD

#use delay(clock=4000000)

#use rs232(baud=9600, xmit=PIN_C6,rcv=PIN_C7,bits=8,parity=n,ERRORS)


void main()
{
char a;
set_tris_b(0b00000000);

while(true)
{

output_b(0b00001000); //this on and off sequence makes the program
delay_ms(1000); //not work....but why????
output_b(0b00000000); //if i delete this sequence all is ok,but i need to
delay_ms(1000); //include this on and off led

if(kbhit()==1)
{
a=getc();

if(a=='a')
{
output_b(0b00000001);
delay_ms(1000);
}

else if(a=='b')
{
output_b(0b00000010);
delay_ms(1000);
}

else if(a=='c')
{
output_b(0b00000100);
delay_ms(1000);
}
}

else
{
output_b(0b00001000);//when the program not work only this is executed
}

}
}

[drolleman]

Depending on your compiler version, it used to only allow a max of delay_ms(256); i'm not sure when the 65535 became legal.

drolleman

[Ttelmah]

His UART has overflowed.

Data has been received while waiting.
kbhit does not return 'TRUE' when the UART is locked (overrun error).
getc will clear this error, but won't be called.
However if you test 'RS232_ERRORS' you can call getc to clear the problem.

Replace the line:

if(kbhit()==1)

with:

if(kbhit() || (bit_test(RS232_ERRORS,1)))

[Mustang1945]

Thanks for your answers
Ttelmah... i tried to do that but nothing happens, remember that i am already using ERRORS.

drolleman...I use a delay of 100 ms and works better...
but my project has changed a little.
Now i must use get_string and not getc, because i am trying to get a string, but kbhit() and ERRORS doesn't work with get_string.

With this program works fine, but if i uncomment the red lines, doesn't work.
kbhit() always is 0, i think its because now i am trying to get a string and not just a character and if i add ERRORS not work.

#include <16F877A.h>
#include <string.h>
#include <stdlib.h>

#FUSES NOWDT //No Watch Dog Timer
#FUSES XT
#FUSES NOPUT //Power Up Timer
#FUSES NOPROTECT //Code not protected from reading
#FUSES NOBROWNOUT //No brownout reset
#FUSES NOCPD

#use delay(clock=4000000)

#use rs232(baud=9600,xmit=PIN_C6,rcv=PIN_C7,bits=8,parity=n)//,ERRORS)

#include <INPUT.C>

void main()
{
char string[11];
signed int8 i;
char password[11]="SPITFIRE\r\n";

set_tris_b(0b00000000);
output_b(0b00000000);
while(true)
{


//if(kbhit() || (bit_test(RS232_ERRORS,1)))
//{


output_b(0b00010000);
delay_ms(1000); //the objective is that the program accept this
output_b(0b00000000); //delays, but how?...i cant use kbhit to know for
delay_ms(1000); //new data and cant use error to prevent the
//buffer overflow


/**
i have been a long time in this problem and my program works fine without the delays, but i need to put delays, thats the problem, and i have seen some examples about compare strings using rs232 but all
them don't have delays,if you could show me an example ....thanks*/

get_string(string,11);
i=strncmp(string, password,8);

if(i==0)
{
output_b(0b00000001);
delay_ms(1000);
}

else if(i==1)
{
output_b(0b00000010);
delay_ms(1000);
}

else if(i==-1)
{
output_b(0b00000100);
delay_ms(1000);
}

//}
else
{
output_b(0b00001000);
delay_ms(1000);
}

}
}

[guy]

I have 2 ideas for you:
1. I see that your main loop keeps running (testing for new char etc.) and you need to toggle PIN_B4 . How about handling the pin with a timer (that works in the background) ?
2. Another option, similar to #1 is to add a 100us delay in the loop. This way you will not miss new chars, and you can use a counter to measure time (each loop takes slightly more than 100us, and after 10000 loops you know that 1 seconds passed and toggle PIN_B4)

[Ttelmah]

No.

You need ERRORS in the #use RS232, _and_ to be testing RS232_ERRORS. Both.

'ERRORS' tells the compiler to add code to getc, to clear the error condition.

Problem is that because you do not call 'getc', if there is an error, the clearing code in getc will never be called.....

The bit test, tells the compiler if there is an error, to call the getc anyway. This then clears the error.

[guy]

Ttelmah, your answer made me think again about the open issue I have in another thread: http://www.ccsinfo.com/forum/viewtopic.php?t=53846
This is with a PIC24. Could be that there is an error happening, no interrupt to catch the error and therefore the receive mechanism is 'jammed' ?
I do have

[Ttelmah]

Yes.

The way the code works, is that a routine is added to getc to clear the error. Obviously getc has to be called for this to happen.
In the older PIC's if you use an interrupt driven handler, then normally getc will be called. If however (as this poster), you test with 'if kbhit()', this does not return true when there is an overrun, so getc does not get called.
On the newer PIC's with bigger buffers, it is common to include a kbhit in the handler (to deal with the situation where multiple characters are in the buffer), and this will prevent the getc being reached (unless you are careful and use a 'do..while', so getc is always called once).
The receive interrupt should be called for the overrun character, but for you, I'd say the safest way would be to enable the overrun error interrupt, and then just read characters till the buffer is empty.

I actually tested the code posted here. You can hang the UART, if you send a number of characters and then use kbhit with the buffer overrun.
Then testing RS232_ERRORS, allows getc to be called.

The alternative for him would be:

[guy]

I'm trying to keep up but it's not easy :-)
There is no kbhit() in my code. The ISR is:

[Ttelmah]

There should be.....

[Mustang1945]

[guy]

[Ttelmah]

Would do....

Thing is that what is happening is you are getting an overflow during the delays (and possibly during the other delays later). Now when you get an overflow, the character that overflowed is lost. The extra code allows the program to recover from the overflow, but the character is still lost. So the strings will have characters missing....

There are multiple ways round this, but the easiest (assuming you have a recent compiler), is:

[guy]

the Transmit program sends SPITFIRE endlessly. This will send almost 1000 characters during the delay_ms(1000) (at 9600 baud). Buffer is not enough for that, characters lost, overflow, no sync etc.

[Ttelmah]

Aargh....


I hadn't looked at the transmitter (didn't even realise it was there).
Not only in the start delays, but in the delays when the code has identified the string as well.

Overkill!....

No more than once per second, would be reasonable (this was what I assumed hence enough space to store 'Spitfire' once and a few characters spare).