[PATCH] Add lvgl_hello: Sample Hello world app using littleVGL and libbsd

Chris Johns chrisj at rtems.org
Tue Sep 3 06:22:52 UTC 2019

On 3/9/19 3:30 pm, Christian Mauderer wrote:
> On 03/09/2019 01:46, Chris Johns wrote:
>> On 2/9/19 5:42 pm, Vijay Kumar Banerjee wrote:
>>> On Mon, Sep 2, 2019 at 4:34 AM Chris Johns <chrisj at rtems.org
>>> <mailto:chrisj at rtems.org>> wrote:
>>>     > +     puts("\nRTEMS I2C TEST\n");
>>>     > +     exit_code = bbb_register_i2c_0();
>>>     > +     assert(exit_code == 0);
>>>     Is this needed for the display to work?
>>> Yes. We need to register the rtems i2c device in order to work with the TDA driver
>>> as libbsd uses rtems i2c driver. The bbb_register_* is making it bbb specific, what
>>> do you suggest to make it more generic? 
>> Should the I2C be registered during the BSP initalisation? This would remove the
>> need for this type of call being spread across all applications on the BBB. The
>> BBB has a lot of resources and the I2C is part of the SoC and so always present.
>> I cannot think of a way to have a sysinit entry that installs the driver when
>> the I2C bus used.
>> Chris
> Hello Chris,
> I would also prefer that the I2C is initialized during BSP init. But
> note that this opens the same discussion we had with Joel when I
> suggested the FDT support as a project: It links in the Support for
> every BSP. I don't really think it hurts for a small driver like I2C on
> a big target like BBB but we should make sure that everyone is OK with that.

I suggest the I2C driver init is part of the BBB BSP and not part of every BSP.
I do not see this as the same as the FDT code then again I have not looked at
the detail.

> What might could be a problem: Is there something in the initialization
> that might is application specific? The still bad solution for pin
> config for example? (@Vijay: Bad because it's hard coded in I2C driver
> and not due to the double init.)

Maybe I am not understanding the issue. I thought there is I2C code is present
in libbsd for the BBB frame buffer so when the frame buffer is initialised some
I2C activity happens. If the BBB I2C is not initialised the driver will fail or
the display will not be initialised and this is why the example has the code to
initialise the bus.

Examples should not contain BSP specific initialisations or we have to manage
specific builds of the examples and that is problematic.


More information about the devel mailing list