Bug fix in 'apbuart_cons.c' file ?

[Charles INGELS]

Hello,

By using the APB Uart BSP on a SPARC LEON3 target, I think that I have
found something which seems to be incorrect.

In my RTEMS app, I just want to receive data through the UART1. Such
data are then echoed on the same interface.

When I want to open the '/dev/apbuart1' descriptor, I get a 'No such
file or directory' error message. I get the same error message whatever
is the descriptor I try to open ('/dev/apbuart0', ...).

I am using the driver manager and I have defined the
CONFIGURE_DRIVER_AMBAPP_GAISLER_APBUART to have the driver manager
create the device descriptors. However, the descriptors are not created.

I had a look at the content of the following file :

U:\rtems\src2\rtems\c\src\lib\libbsp\sparc\shared\uart\apbuart_cons.c

On line #278, the if statement does not explicitly test the value
returned by the call to function 'drvmgr_get_dev_prefix()'.

Since such function returns 0 in case of success, the content of the if
statement is never executed. Consequently, the variable 'priv->devName'
is never initialized to the right string '/dev/apbuart%d', it is always
empty which seems to explain why the device descriptor is not not created.

I have slightly modified the test with the following code :

if (drvmgr_get_dev_prefix(dev, prefix) != -1)
{
...
}

I explicitly test the returned value against -1 (which is considered as
an error). With that code, the '/dev/apbuartX' device descriptors are
successfully created and communicate with the UART.

So is it a known bug ? Will it be fixed in the next releases ? Is the
way I fixed it correct, or no ?

Such fix works for me but are there some side effects that shall be
taken into account ?

Thanks for your answers,

Regards,

Charles




-- 
*Charles INGELS*
Embedded software expert
charles.ingels at syderal.ch
Phone /+41 (0)32 338 99 10/
iNum /+883 5100 0902 7759/

*SYDERAL SA*
Neuenburgstrasse 7
CH-3238 Gals (Suisse)
Desk /+41 (0)32 338 98 00/
Fax /+41 (0)32 338 99 34/
Web site http://www.syderal.ch
	

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20170410/1b3969dd/attachment.html>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20170410/1b3969dd/attachment-0001.html>