[En-Nut-Discussion] NutOS serial driver

Ulrich Prinz uprinz2 at netscape.net
Sun Nov 1 00:01:50 CET 2009


Jason Bourne schrieb:
> Hi,
> I am using the NutOS v4.8.0. The application that I am writing needs
> to received 2070 bytes in one shot and also transmit 4096 bytes in
> one shot via RS232, I enabled interruptions to detect the end of the
> packet when I received data. If I increase the USART_RXBUFSIZ to 3072
> bytes and the USART_TXBUFSIZ tp 5120. Do I have to have any
> considerations? Will The nutOS v4.8.0 crush due to this changes?
Hard to tell, as you don't tell on what target you're running that.
If you use an ATmega128 it will crash as there is not enough memory. If 
you use an ARM7 based system with 32k+ memory it should work.

I never saw a serial protocol that needed to be read at once in such a 
big trunk. Normally you need data part by part and can work with each 
part. If the data is not to be interrupted by buffer full conditions, 
you only have to ensure, that the primary serial buffers are big enough 
to fetch data without overrun while you work with the already received 
data elsewhere before you pick the next part from the input buffer.

So you can interpret the data as it comes in part by part and sort it to 
the structs where it should go. The input buffer takes care, that you 
don't loose anything while you're busy decoding it.

Same with the output. If you send data, it will be placed into the 
output buffer. If the buffer is full, your sending thread will be 
blocked until there is some space in the buffer again ( look at high an 
low watermark settings). If you'd like to have a continuous flow of 
data, lower the output buffer size and set the output thread to a higher 
priority and it will keep the output buffer full.

If you have an idea of how long your output thread needs for preparing 
the data, you can use the high- and low-watermark system to. Let one of 
these guys trigger your thread to prepare the next data just in time.

With that you need only small buffers and keep up a continuous data flow.


More information about the En-Nut-Discussion mailing list