NutOS serial driver

[Jason Bourne-2]

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?

 

Thank you

 

Juan
     
_________________________________________________________________
Windows 7: It works the way you want. Learn more.
http://www.microsoft.com/Windows/windows-7/default.aspx?ocid=PID24727::T:WLMTAGL:ON:WL:en-US:WWL_WIN_evergreen2:102009
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion

[uprinz]

Hi!

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.

Regards
Ulrich
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion

[Ole Reinhardt-2]

Hi Jason,

> 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?

Some time ago we just had a discussion concerning a bug in the serial
driver implementation triggered when changing the rx / tx buffer size.

If you like to do so you should always also set the hight and low
watermark of the rx an tx buffers. Otherwise you might get corrupted
data.

At least the size of your buffers is only limited by the available free
memory. As Ulrich just mentioned you should better take into account if
you realy need such large buffers.

If you want to check if the buffer is empty (tx as completed) you can
use the following code:

int      cycle = 0;
uint32_t parm;

do {
    _ioctl(_fileno(uart0), UART_GETSTATUS, &parm);
    NutSleep(10);
} while (!(parm & UART_TXBUFFEREMPTY) || (cycle > 1000));

Btw: Instead of sleeping you could do something usefull too...

Bye,

Ole


--
 _____________________________________________________________
|                                                             |
| Embedded-IT                                                 |
|                                                             |
| Ole Reinhardt        Tel. / Fax:        [phone] |
| Luisenstraße 29      Mobil:             [phone] |
| 57076 Siegen         eMail:    ole.reinhardt@... |
| Germany              Web:         http://www.embedded-it.de |
|_____________________________________________________________|

_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion