|
|
View previous topic :: View next topic |
Author |
Message |
bertronicom
Joined: 17 Nov 2004 Posts: 26 Location: University of Cantabria -SPAIN
|
Cannot working without RS232 wire |
Posted: Mon May 09, 2005 2:43 am |
|
|
I have my program running well when I've connected my 18f452 to my laptop.
But if I remove RS232 serial wires from laptop my program is always waiting for incoming bytes from fgets().
How I could work with my program with or withouth serial connection?
while (1) {
if ( kbhit( HOST_id ) ) {
Disable_Interrupts (INT_TIMER1);
Output_High ( BT_CTS ); // DesHabilita BT Rx data
fgets (Rx_Str , HOST_id);
Len_Rx_Host = StrLen ( Rx_Str );
if ( Len_Rx_Host ) {
Rx_Str[Len_Rx_Host++] = 0;
Decode_Host_Commands (); //Rx_Str
}
Output_Low ( BT_CTS ); // Habilita BT Rx data
Enable_Interrupts (INT_TIMER1);
}//end kbhit host
}
Thanks in advance |
|
|
Ttelmah Guest
|
|
Posted: Mon May 09, 2005 4:11 am |
|
|
There are a number of possibilities, and which is 'best', will depend on your hardware/software.
The problem is that a disconnected RS232 connection, is seen as sending a 'break' condition (low voltage at the TTL serial input on the processor chip). The simple code in fgets, does not understand this, and since it sits waiting for a line feed character, will never return. Kbhit, sees such a continuous low, as a stream of characters, so the result is a hang.
Solutions are numerous. One is to add flow control to the serial link, then a broken connection does not make the flow control conditions. The second is to implement your own replacement for the fgets function. Input.c, contains an example of a 'better' version, and this will return after a number of characters, preventing the hang. This could be further improved, by checking the incoming character for the value returned by the broken connection, and ignoring this. A third alternative, is to use an interrupt driven receive routine, putting the data into a circular buffer, and again have the routine check for the broken connection, and not return any character in this case. With either of these approaches, the 'fgetc' routine, will also have a framing error reported, and this can be used as the 'detector', rather than looking for a '0xff' byte. Another alternative, is to add a _tiny_ resistive 'pull down' on the RS232 input, which prevents the break condition from ever being seen.
Best Wishes |
|
|
|
|
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
|