![](templates/subSilver/images/CCSLogo.jpg) |
![CCS C Software and Maintenance Offers](templates/subSilver/images/forumAd6.jpg) |
View previous topic :: View next topic |
Author |
Message |
abbas14
Joined: 05 Sep 2015 Posts: 7
|
difference between Streams and Buffers in RS232(UART) librar |
Posted: Sat Sep 05, 2015 12:31 am |
|
|
hello all.
i am new to pic, and even newer to CCS.
can anyone explain to me the difference between using Streams and Buffers with RS232(UART). i read the CCS c manual, but could not understand the difference upto my satisfaction.
can anyone please help me with that?
i will be really grateful.
best regards. _________________ Long Live My Master. |
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah
Joined: 11 Mar 2010 Posts: 19369
|
|
Posted: Sat Sep 05, 2015 1:05 am |
|
|
Completely unconnected.
A buffer, is just that, A software buffer associated with a particular UART (normally using 'hidden' interrupt handlers to fill/empty), to augment the hardware buffer in the chip.
'Streams' are logical names given to the UART's, allowing you to route data to/from them when required.
So:
Code: |
#use rs232(BAUD=9600, UART1, ERRORS, RECEIVE_BUFFER=16, STREAM=U1)
#use rs232(BAUD=9600, UART1, ERRORS, TRANSMIT_BUFFER=16, TXISR, STREAM=U2)
//Two hardware UARTs - streams U1, and U2. First with receive buffering
//second with transmit.
void main(void)
{
enable_interrupts(GLOBAL); //needed, since the UART's are both
//now using interrupts
while (TRUE)
{
while (kbhit(U1)) //check if the first stream has any data
{
fputc(fgetc(U1),U2); //send the data from U1 to U2
}
}
}
|
The streams are just 'names' to say who the data is to come from, or go to.
Key thing about the buffering, is that if there was a pause in the loop, so several characters had arrived, with the receive buffer these would not have been lost (assuming <16), and with the transmit buffer these could be sent almost instantaneously to the TX buffer, instead of having to wait to transmit them. So the loop could then continue quickly. |
|
![](templates/subSilver/images/spacer.gif) |
abbas14
Joined: 05 Sep 2015 Posts: 7
|
|
Posted: Sat Sep 05, 2015 1:31 am |
|
|
what is the need of logical names?
can't we just use uart1 and uart2?
also, the ccs c manual does not covers the complete documentation on how to access buffers.
say, i need to enable both receive complete and transmit complete interrupts, and use buffers with conjunction with that.
can anyone provide any links to some tutorials or something, with detailed explanation. _________________ Long Live My Master. |
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah
Joined: 11 Mar 2010 Posts: 19369
|
|
Posted: Sat Sep 05, 2015 2:22 am |
|
|
No.
UART1 and UART2, are shorthand names for the physical UARTs. The getc and putc, do not talk directly to the physical UART's, but talk to the driver setup by #USE RS232. There could be several hardware UARTs, and possibly dozens of 'soft' UARTs all setup at the same time, with no connection to the physical UARTs. Then the physical UARTs could have lots of extra features in the driver (handling of RTS/CTS, ENABLE - for RS485, buffering etc.). |
|
![](templates/subSilver/images/spacer.gif) |
abbas14
Joined: 05 Sep 2015 Posts: 7
|
|
Posted: Sat Sep 05, 2015 3:14 am |
|
|
the ccs c manual does not covers the complete documentation on how to access buffers.
say, i need to enable both receive complete and transmit complete interrupts, and use buffers with conjunction with that.
can anyone provide any links to some tutorials or something, with detailed explanation?
thank you. _________________ Long Live My Master. |
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah
Joined: 11 Mar 2010 Posts: 19369
|
|
Posted: Sat Sep 05, 2015 3:27 am |
|
|
You don't really access buffers, just use them!...
If you look at what I posted, I set up an RX buffer on one UART, and the commands remain completely the same as for just talking to the UART. kbhit tells you there is a character waiting, getc gets the character. Nothing else.
For the TX it is basically the same, except they add one function, so you can tell how much space is still in the buffer. The function:
number=tx_buffer_available(STREAM);
tells you how much space is still in the buffer. Allows you to avoid overflows, when putting things into the buffer.
#use rs232(BAUD=9600, UART1, ERRORS, TRANSMIT_BUFFER=16, TXISR, RECEIVE_BUFFER=32, STREAM=U2)
Would setup both transmit and receive buffering on one UART. Nothing more needed.
You seem to be looking for more complexity than there is. Remember the chip has hardware buffering, all the software buffering does, is effectively extend this. |
|
![](templates/subSilver/images/spacer.gif) |
abbas14
Joined: 05 Sep 2015 Posts: 7
|
|
Posted: Sat Sep 05, 2015 5:23 am |
|
|
getc() and putc() send and receive data to the software Rx and Tx buffers, or to the hardware UART buffer RX/TXREG?
may be these functions work on the software buffers when a software buffer is implemented, i.e., when the and fields are specified in , and when these fields are not specified (the compiler takes the default size to be zero), these functions interact with the hardware buffer.
am i right?
but getc(), putc(), gets(), puts(), printf and all such functions interact with the specified(or default) stream, don't they?
ok......
looks like i my brain has started to spin by now....... _________________ Long Live My Master. |
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah
Joined: 11 Mar 2010 Posts: 19369
|
|
Posted: Sat Sep 05, 2015 7:35 am |
|
|
getc and putc, talk to the last defined stream.
fgetc, and fputc, talk to any stream you want.
They talk to the streams _not_ implicitly the hardware. If the stream is set to talk directly to the hardware, then they talk to the hardware. If the stream is set to use a software UART, then they talk to this. If the stream is set to use extra buffers, then they talk to these. |
|
![](templates/subSilver/images/spacer.gif) |
qasimimran
Joined: 08 Sep 2015 Posts: 1
|
Purpose of TXIRS? |
Posted: Tue Sep 08, 2015 10:34 am |
|
|
IF we CANNOT access Transmit buffer directly for loading data then what is the purpose of TXIRS and INT_TBE? |
|
![](templates/subSilver/images/spacer.gif) |
jeremiah
Joined: 20 Jul 2010 Posts: 1329
|
|
Posted: Tue Sep 08, 2015 2:40 pm |
|
|
They are for when you want to do things manually rather than using the buffer option. It's a choice between control and automation of your code. Control involves more work (you create and manage your own buffers using the interrupts) while automation is for when you don't care about the side effects and don't want to manage them yourself (CCS creates the appropriate interrupt code which you don't have direct access too). It's a tradeoff.
I personally don't like using the CCS supplied buffers. Unless things have changed, they completely reset when they fill up (EDIT: see https://www.ccsinfo.com/forum/viewtopic.php?t=54339 ). I prefer to roll ones similar to the compiler provided example files where they simply stop receiving/transmitting when they fill. |
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah
Joined: 11 Mar 2010 Posts: 19369
|
|
Posted: Tue Sep 08, 2015 11:25 pm |
|
|
Exactly.
Hopefully the original poster _has_ looked at ex_stisr.c, and ex_sisr.c, which show a basic approach to _not_ using the 'automatic' buffers for transmit and receive. |
|
![](templates/subSilver/images/spacer.gif) |
|
|
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
|