Yes, that is the code I’m referring to.
I’m also going to be looking at adding one or two more PCF GPIO expanders to
the system, not LCD, but they will certainly need to live with the LCD backpack.
I’ll have a look at a PR.
Regards,
Mark
_
Blog: blog.thepcsite.co.uk
Ideally, I’d have configured this from the user application. As they are
embedded within the board startup I’d have thought they would have been
configurable through kconfig.
I assume you are referring to the following in
boards/arm/rp2040/common/src/rp2040_common_bringup.c:
#ifdef CO
This is not so much about a board configuration, it is about a driver
configuration.
So the PCF driver is just a GPIO expander which in this case is driving a LCD.
My question really is about the integration of very specific configuration
information into the OS.
From a high level view, the dr
On Sun, Jul 23, 2023 at 6:44 PM Mark Stevens wrote:
> Had some fun and games today working with the SLCD example on the Pico W.
> It appears that the example has hard wired parameters for
> I2C bus
> Number of characters
> Number of rows
> Is it supposed to work like this or should these parameters
Hi Mark,
In fact some examples are ("incorrectly") hard-code to some I2C Bus or
uses #ifdef to compile only if that I2C Bus is enabled in the
menuconfig.
There are pros and cons of using this approach:
PROS:
- 'Guarantee' that such config works (dev tested it);
- Developer doesn't need to test
Had some fun and games today working with the SLCD example on the Pico W.
It appears that the example has hard wired parameters for
I2C bus
Number of characters
Number of rows
Is it supposed to work like this or should these parameters be configurable?
Regards,
Mark
