Termios: Non-blocking read() working? .-

[Sebastian E. Garcia]

[CLOSED]

This message is just to close this thread, at least from its RTEMS side, 
and give feedback to the list.

The cause of the problem is a miss-configuration of the mentioned 
"resource" structs for apbuart in the header of the application.
I've built Gaisler's RTEMS BSP , hardcoding the use of interrupts 
[apbuart_cons.c] and now the non-blocking read() seems to work OK.
So right now I'm looking at why that configuration fails.

Thanks and regards,
Sebastian.



On 06/11/2012 12:16 PM, Sebastian E. Garcia wrote:
> On 06/11/2012 05:55 AM, Joris van Rantwijk wrote:
>> On Monday 11 June 2012 10:09 Sebastian E. Garcia wrote:
>>> 1. Gaisler's UART ISR and rtems_termios_enqueue_raw_characters function
>>> seems OK at first glance.
>>
>> That stuff is inside "#if CONSOLE_USE_INTERRUPTS".
>> Are you sure it is enabled?
>
> (This applies to Gaisler's port). The last RCC compiler enables the use
> of APBUART individual configuration of interrupt or polling mode without
> needing to rebuild the kernel, configuring this struct in the
> application code:
>
> /* APBUART1 */
> struct drvmgr_key grlib_drv_res_apbuart1[] =
> {
> {"mode", KEY_TYPE_INT, {(unsigned int)1}}, /* IRQ mode */
> {"dbgcon", KEY_TYPE_INT, {(unsigned int)0}}, /* debug out disabled */
> {"syscon", KEY_TYPE_INT, {(unsigned int)0}}, /* sys console disabled */
> KEY_EMPTY
> };
>
>
>>> Without having so much experience with Termios, the behavior I expect
>>> when VTIME==VMIN==0, is to read at once (non-blocking):
>>> Min{No. of bytes requested by read(); No. of bytes in the raw buffer}
>>> , and return ASAP.
>>
>> That is also what I would expect.
>>
>>> But in this code, when VMIN==0, only one char from the raw buffer gets
>>> copied.
>>
>> I don't see that.
>> The line marked "SG" causes the outer loop to exit ASAP, i.e. no
>> waiting for more data to come in.
>  > In the mean time, the inner loop can still collect multiple bytes if
>  > they are available in the queue. Right?
>  >
>  > Joris.
>
>
> You are right, I've overlooked that. It was the perfect bug for need :)
>
> Thanks again for your reply. Regarding leonuart, it seems that many data
> objects have changed since then (not only their name but structs fields,
> etc.).
>
> Best regards,
> Sebastian.
>
>
>
>
>
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-users
>