[PATCH] Add lvgl_hello: Sample Hello world app using littleVGL and libbsd
christian.mauderer at embedded-brains.de
Tue Sep 3 05:30:52 UTC 2019
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.
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.
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.)
embedded brains GmbH
Herr Christian Mauderer
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.
More information about the devel