| View previous topic :: View next topic |
| Author |
Message |
aerodactyl
Joined: 22 Feb 2008
Posts: 14
Location: Germany
|
| Reading string via RS232 into PIC |
 Posted: Tue Oct 21, 2014 10:40 am |
 |
|
Hello world,
I have problem in understanding some things around the RS232.
In the past I read only single characters via RS232 into the PIC and sent out some strings without any problem.
for reading the characters I used
| Code: | if (kbhit())
{
ASCII = getc();
} |
Sending was done by "printf() function. All good so far.
Now I want to receive data via the RS232. Therefore the transmitter sends numbers e.g. "123" as a string to the PIC.
During debugging I saw that the kbhit() will read each single character, but only the first two. Third character got lost somewhere.
I saw in the compiler book that the RS232 can also handle a parameter called STREAM.
After studying half of the internet I gave up because I couldn't find any useful explanation for me.
The nomenclature seems to be | Code: | | #USE RS232 (....,...,....,STREAM = x) |
and
reading the buffer
| Code: |
if (kbhit(x))
{
...
} |
Please can somebody explain this a little bit?
My idea is to send the data to the PIC as 123$. When receiving the $ I know the data is complete and I can send the string (without $) into ATOI ()or ATOL() function to convert it into a int or long variable.
So my questions are:
_ is the STREAM parameter necessary for reading more tha a character via RS232?
_ does the kbhit(x) function looks only for strings then?
_ what happens if I want still receive also single characters for controlling some functions inside the PIC?
PIC: 16F1829
CCS:PCM Version 5.0.0.448
MPLAP 8.92 IDE
Test environment: HTerm Terminal program
Hope somebody can help me in this matter.
Best regards
Uwe |
|
 |
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Tue Oct 21, 2014 12:27 pm |
|
|
| Quote: | | _ is the STREAM parameter necessary for reading more tha a character via RS232? |
No.
| Quote: | | _ does the kbhit(x) function looks only for strings then? |
No. It tells you that the UART has received a character, and is ready
for you to read it with getc().
| Quote: | | _ what happens if I want still receive also single characters for controlling some functions inside the PIC? |
You can always do this.
Look at the CCS example file, ex_Sisr.c, in this directory:
| Quote: | | c:\program files\picc\examples\ex_sisr.c |
|
|
|
aerodactyl
Joined: 22 Feb 2008
Posts: 14
Location: Germany
|
|
| Posted: Tue Oct 21, 2014 2:43 pm |
|
|
Got it work now 
My problem was the overrun error!
It seems it occurs because the terminal program send the character without any delay and the 2 character FIFO buffer overflows as the main loop is slower.
In reality this can not happen since the PC will send data with a minimum gap of 10 ms.
Still my question:
_ What is the meaning of this STREAM parameter for the RS232?
Best regards
Uwe |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Tue Oct 21, 2014 3:14 pm |
|
|
"Streams" are just names for UARTs. If your PIC has two UART modules,
how do you tell the difference between them when you are writing code ?
You give each uart a different stream name, and then use that name as
a parameter when you call fgetc, fputc, or fprintf, etc. |
|
|
aerodactyl
Joined: 22 Feb 2008
Posts: 14
Location: Germany
|
|
| Posted: Tue Oct 21, 2014 3:26 pm |
|
|
Easy to understand and logical. Thanks |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19552
|
|
| Posted: Wed Oct 22, 2014 12:23 am |
|
|
and on the main loop being slower than characters are arriving, look at ex_sisr.c
This shows how to use the hardware interrupt, to put the received characters into a buffer.
Then instead of using kbhit you use 'bkbkit' to test for data being in the buffer, and bgetc to get the characters. This buffer (with the supplied code), should be a 'binary' size (8, 16 etc. characters), but then means that provided your main loop services 'at times' fast enough, to keep ahead of the characters arriving, you have several characters extra time to cope.
It can very easily be modified to handle streams, and I have in the past posted code that allows non binary sizes, and multiple buffers for several UARTs to be 'in use' at once if needed. However if only one of the serial streams is likely to be giving this problem, just buffer this one, with the supplied code. |
|
|
asmboy
Joined: 20 Nov 2007
Posts: 2128
Location: albany ny
|
|
| Posted: Thu Oct 23, 2014 11:33 am |
|
|
| Quote: |
When receiving the $ I know the data is complete |
a more common convention is to use ASC(13),
the carriage return instead of '$'
this has the benefit of being very displayable too,
which it will not be when using $. |
|
|
aerodactyl
Joined: 22 Feb 2008
Posts: 14
Location: Germany
|
|
| Posted: Thu Oct 23, 2014 3:08 pm |
|
|
Thanks to all
Your input helped alot.
Best regards from Germany
Uwe |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
