Bug fix in 'apbuart_cons.c' file ?
Charles INGELS
charles.ingels at syderal.ch
Mon Apr 24 11:58:02 UTC 2017
Hi Daniel,
thanks for your answer. The version I use is from the master branch and
the checkout has been done the 7th of march. It is definitely not the
latest release because I need to freeze one version that I use to
compile against the software applications I am currently developing.
This is mainly because each time I make an "update", I have to go
through a new integration test cycle for each of the software apps,
which can become very time consuming, at least for the moment.
However, since that work is on the go, I might in a near future update
my RTEMS working copy and then go again into a hopefully final test
campaign, before releasing the latest final version of the software apps.
Regards,
Charles
Le 24.04.2017 à 12:41, Daniel Hellstrom a écrit :
>
> Hi Charles,
>
> Sorry I missed to reply on your email. Thanks for reminding me. Which
> codebase do you use, is it the current RTEMS master or RCC-1.2?
>
> /Daniel
>
>
> On 2017-04-24 07:50, Charles INGELS wrote:
>>
>> Hi Joel,
>>
>> until now, I did not receive any answer from Daniel. I do not know if
>> my feedback has been taken into account, maybe for other users if
>> they have the same issue.
>>
>> Nevertheless, the fix seems to work fine with no apparent side effects.
>>
>> Regards,
>>
>> Charles
>>
>>
>>
>> Le 11.04.2017 à 03:29, Joel Sherrill a écrit :
>>> I'm going to assume that Daniel didn't see this since he didn't comment.
>>>
>>> On Apr 10, 2017 2:41 AM, "Charles INGELS" <charles.ingels at syderal.ch
>>> <mailto:charles.ingels at syderal.ch>> wrote:
>>>
>>> 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 <mailto:charles.ingels at syderal.ch>
>>> Phone /+41 (0)32 338 99 10 <tel:+41%2032%20338%2099%2010>/
>>> iNum /+883 5100 0902 7759/
>>>
>>> *SYDERAL SA*
>>> Neuenburgstrasse 7
>>> CH-3238 Gals (Suisse)
>>> Desk /+41 (0)32 338 98 00 <tel:+41%2032%20338%2098%2000>/
>>> Fax /+41 (0)32 338 99 34 <tel:+41%2032%20338%2099%2034>/
>>> Web site http://www.syderal.ch
>>>
>>>
>>>
>>> _______________________________________________
>>> users mailing list
>>> users at rtems.org <mailto:users at rtems.org>
>>> http://lists.rtems.org/mailman/listinfo/users
>>> <http://lists.rtems.org/mailman/listinfo/users>
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20170424/2f414c12/attachment-0004.html>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20170424/2f414c12/attachment-0005.html>
More information about the users
mailing list