CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to CCS Technical Support

RS232 comm problems.

 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
greg shipley
Guest







RS232 comm problems.
PostPosted: Fri Aug 17, 2007 9:58 am     Reply with quote

I am using a 16F876 to receive and send data to a AT compatable PC port at 19200Baud 8-N-1.
I am using the KBHIT() to get the char. If another char comes in before the first one is read, it locks up my communication and the PIC is not able to get data until power is cycled.
Is there a way to get around this without using interrupts? Ignoring the extra char would be ok.

Greg
Ttelmah
Guest







PostPosted: Fri Aug 17, 2007 10:07 am     Reply with quote

Add 'ERRORS' to your RS232 dclaration. The compiler wll then automatically clear the 'overrun' error which otherwise will hang the UART.

Best Wishes
PIT
Guest







A problem.
PostPosted: Tue Sep 11, 2007 8:14 am     Reply with quote

I have the same problem.

But when I add the ERRORS on my program, every time the 'overrun' error comes in, it resets my program!

Is this normal?

If it´s not, is there a way to solve this?

I´m using PIC16F877.

Thanks.
Ttelmah
Guest







PostPosted: Tue Sep 11, 2007 9:24 am     Reply with quote

No, it is not 'normal'.
Write your program so it works!..... Smile
Seriously, how do you know an overrun error is occuring?.
I'd guess, you are probably actually getting a watchdog timout, because your comms cannot handle losing a character.
The only things that will 'normally' cause a reset, are a stack overflow, watchdog timeout, or external electrical noise.

Best Wishes
PIT
Guest







PostPosted: Tue Sep 11, 2007 9:44 am     Reply with quote

But i don´t use watchdog...


#include <16F877.h>
#fuses HS,NOWDT,NOPROTECT,NOLVP,NOBROWNOUT
#use delay(clock=20000000)

#use rs232 (baud=9600, xmit=pin_c6, rcv=pin_c7, parity=n, bits=8, errors)

.....


This is how I get the data....

I THINK it´s overrun because it makes my serial connection with a TouchScreen stop, when I click twice, and the Touch tries to send me data while I´m sending data to a LCD.

My comm with the Touch is a 13 byte string, that works fine if i wait the pic write on a LCD.

Thanks
Ttelmah
Guest







PostPosted: Tue Sep 11, 2007 12:36 pm     Reply with quote

How would your code deal with a missing character?.
Buffer overruns?. Possible memory leak?.
Logic failure, leading to a stack overflow?.
Consider interrupt driven comms.

Best Wishes
PIT
Guest







PostPosted: Wed Sep 12, 2007 5:25 am     Reply with quote

Ok... I must be doing something really worng...


Code:

void trata_serial()
{
      for (t=0; t<13; t++)
      {
            if (kbhit()==1)
            {
                 pal[i]=getc();
                 i++;
            }
            if (i>9)
            {
                 t=13;
            }
      }
}



This is how I get the characters... I have only 10 bytes comm on this other Touch.

In my main program, I have something like this:

Code:

void main(void)
{
         variable declarations;
         variable sets, for first time the program passes;

          for ( ; ; )
          {
                   trata_serial();
                   many other things on program loop;
           }
}



So, it makes sense that it's 'overrun' error, because if he sends data to me while I'm on the loop, it will get buffer 'overrun'.

I really don't care about the data that comes in while I'm on the loop.

I thought that if I put errors, it would just clear the buffer and the 'overrun' bit when it gets busy. I even tried not to put errors and manually clear and set the CREN when it get's 'overrun' bit, but every time I do that, it goes back to the 'variable set' part of my program, meaning he broke the loop.

Sorry about not being so clear about the problem, hope you understand!


Thanks
SET



Joined: 15 Nov 2005
Posts: 161
Location: Glasgow, UK

View user's profile Send private message Send e-mail Visit poster's website

PostPosted: Wed Sep 12, 2007 7:19 am     Reply with quote

Quote:
Code:
{
void trata_serial()
{
      for (t=0; t<13; t++)
      {
            if (kbhit()==1)
            {
                 pal[i]=getc();
                 i++;
            }
            if (i>9)
            {
                 t=13;
            }
      }
}


Where do you initialise i? I think your overwriting memory somewhere..

Also, more normal to write:

Code:
for (t=0; t<13; t++)
      {
            if (kbhit()==1)
            {
                 pal[i]=getc();
                 i++;
                 if (i>9)
                       break;
            }
       }
Ttelmah
Guest







PostPosted: Wed Sep 12, 2007 7:48 am     Reply with quote

The problem is that I'd suspect you are actually getting a handler error, which then confuses the code. You read ten bytes (why the 13 counter?.), but suppose some characters are still in the input buffer from an earlier transaction that was missed. You then receive some characters from the last packet, and some more from the next one. How is the code ever going to synchronise back to the 'packet'?. What happens in the main, if the block contains data 'out of order' like this?. This is why packet based comms, normally has a definition, with a 'header', and a 'tail' character, and/or a pause between packets, with the handler writen to timout.

Best Wishes
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group