difference between Streams and Buffers in RS232(UART) librar

[abbas14]

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.

[Ttelmah]

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:

[abbas14]

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.

[Ttelmah]

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.).

[abbas14]

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.

[Ttelmah]

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.

[abbas14]

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

[Ttelmah]

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.

[qasimimran]

IF we CANNOT access Transmit buffer directly for loading data then what is the purpose of TXIRS and INT_TBE?

[jeremiah]

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.

[Ttelmah]

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.