|
|
View previous topic :: View next topic |
Author |
Message |
Jon Fick
Joined: 09 Dec 2003 Posts: 5
|
ERROR keyword and RS232_ERROR variable |
Posted: Sat Dec 27, 2003 10:26 pm |
|
|
Searched the archives and can't find any relavent posts...
In the 18F252 I'm using the hardware UART (using the Rx and Tx pins) and a software UART (using another set of pins,) thus I have two #USE RS232 statements.
For the hardware UART I need to know framing errors, etc, so I inclue the ERROR keyword on the #USE RS232 statement, and therefore any errors are written to the variable called RS232_ERRORS.
For the software UART I need to read the ninth bit for the particular protocol I'm using, so I again need to use the ERROR keyword and examine the RS232_ERRORS variable.
I'm thinking that there is only one variable that ERRORS sets and that I will have conflicts.
Does anyone have experience with this? Thanks. _________________ Jon Fick |
|
|
ttelmah Guest
|
Re: ERROR keyword and RS232_ERROR variable |
Posted: Sun Dec 28, 2003 7:40 am |
|
|
Jon Fick wrote: | Searched the archives and can't find any relavent posts...
In the 18F252 I'm using the hardware UART (using the Rx and Tx pins) and a software UART (using another set of pins,) thus I have two #USE RS232 statements.
For the hardware UART I need to know framing errors, etc, so I inclue the ERROR keyword on the #USE RS232 statement, and therefore any errors are written to the variable called RS232_ERRORS.
For the software UART I need to read the ninth bit for the particular protocol I'm using, so I again need to use the ERROR keyword and examine the RS232_ERRORS variable.
I'm thinking that there is only one variable that ERRORS sets and that I will have conflicts.
Does anyone have experience with this? Thanks. |
The RS232_ERRORS byte, will refer to the last getc, and next putc. This does imply, that when dealing with a combined hardware/software system, you would need to disable the hardware receive (if using interrupt driven code), while doing a software receive (but this is normally necessary anyway, in order to maintain the required timing accuracy).
You really have to only use the streams 'one at a time', or the serial handler won't work. Hence the shared nature of the variable is not a problem. If you want completely seperate UARTs, with buffering etc., look instead at a chip with dual hardware UARTs, or consider using an SPI UART (such as the MAX3110).
Best Wishes |
|
|
Guest
|
|
Posted: Sun Dec 28, 2003 7:48 am |
|
|
That's more or less what I thought might be the case...use one at a time. And, that's not an issue. When using the software UART, I can disable the hardware UART interrupt and clear the error variable. I'm only doing one thing at a time anyway. Thanks. |
|
|
|
|
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
|