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

[Christian Mauderer]

On 11/09/2019 10:48, Vijay Kumar Banerjee wrote:
> 
> 
> 
> On Thu, Sep 5, 2019 at 3:08 PM Christian Mauderer
> <christian.mauderer at embedded-brains.de
> <mailto:christian.mauderer at embedded-brains.de>> wrote:
> 
>     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>
>     >>>> <mailto: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).
> 
> Hi,
> 
> Since adding I2C in BBB initialization seems like the right solution,
> should we ask
> in devel and user lists in a separate thread, to know if anyone is
> opposed to this change?

Hello Vijay,

just send a patch. That will start the discussion if someone objects to it.

> 
> Where should I be looking for to add i2c in BBB initialization?

Please take a look at the dependencies. If there are any (like clocks or
similar) you have to add it afterwards.

Take a look at some other BSPs where similar hardware (like I2C, SPI,
some external chips, ...) is initialized. For example the mvme3100 uses
a RTEMS_SYSINIT_ITEM to pick a random sample. But I think most BSPs use
a special init function similar to the one in BBB.

Best regards

Christian

> 
> Regards,
> Vijay 
> 
>     >
>     > Chris
>     >
> 
>     Best regards
> 
>     Christian
>     -- 
>     --------------------------------------------
>     embedded brains GmbH
>     Herr Christian Mauderer
>     Dornierstr. 4
>     D-82178 Puchheim
>     Germany
>     email: christian.mauderer at embedded-brains.de
>     <mailto: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.
> 

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