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

[Christian Mauderer]

Sorry for the late reply. This mail slipped my attention.

On 03/09/2019 08:22, Chris Johns wrote:
> 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.

Clearly I used the wrong terms. Sorry for the confusion. I meant that it
will link in the I2C support for every application regardless whether
I2C is used or not. Joel mentioned that he would prefer it if not all
drivers are linked in automatically during the FDT support discussion. See:

https://lists.rtems.org/pipermail/devel/2019-August/027265.html

Joel wrote there: "I think this is a good idea if we can still avoid
bloating apps with all drivers."

Like I said: I wouldn't mind a small driver like I2C but we should have
all agree to it.

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

Right.

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

Fully agreed. Just not sure how that could be solved (without adding the
I2C driver).

> 
> Chris
> 

Best regards

Christian
-- 
--------------------------------------------
embedded brains GmbH
Herr Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email: christian.mauderer at embedded-brains.de
Phone: +49-89-18 94 741 - 18
Fax:   +49-89-18 94 741 - 08
PGP: Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.