shields: display: Add Waveshare Pico OLED 1.3

[soburi]

Added Waveshare 1.3inch OLED module for RaspberryPi Pico.

[erwango]

No connector provided, but I guess in specific case of Raspberry Pico (oine single board reference), it is fine. @jfischer-no thoughts ?

[jfischer-no]

There is pico_spi.
https://github.com/zephyrproject-rtos/zephyr/blob/8e7c7c62b15cbc09633e48f95eec6aa9150a4791/boards/arm/rpi_pico/rpi_pico-common.dtsi#L151C1-L151C20
I think it make sense to add pico_i2c.

[soburi]

It makes sense.
For consistency reasons, I added aliases as pico_spi0, pico_spi1, pico_i2c0, and pico_i2c1.

[jfischer-no]

I think we should better group shields by the controller/device it configures. Can it be part of the ssd1306 shield since it already supports multiple controllers from that family?

[soburi]

@jfischer-no

I think we should better group shields by the controller/device it configures. Can it be part of the ssd1306 shield since it already supports multiple controllers from that family?

There is rpi_pico specific problem.

The i2c/spi pins are not fixed.
It requires to include boards/*.overlay file for applying the configuration that suits the shield.

If it puts this shield configuration into boards/shields/ssd1306,
the overlay file will also apply to another configuration.
Of course, It causes a contradiction with another shield.

I think it is good to create the shield configuration separately.

[jfischer-no]

If it puts this shield configuration into boards/shields/ssd1306,
the overlay file will also apply to another configuration.
Of course, It causes a contradiction with another shield.

How?
Just copy overlay files to boards/shields/ssd1306, adapt boards/shields/ssd1306/Kconfig.shield and it should work fine.

[soburi]

@jfischer-no

If it puts this shield configuration into boards/shields/ssd1306,
the overlay file will also apply to another configuration.
Of course, It causes a contradiction with another shield.

How? Just copy overlay files to boards/shields/ssd1306, adapt boards/shields/ssd1306/Kconfig.shield and it should work fine.

I want to use this shield by only adding the -DSHIELD=... option with west build.

For that, rpi_pico needs to configure i2c-pins with pinctrl.
The i2c-pins are not defined in board configurations because rpi_pico's i2c-pins can take several settings.
So, This PR also added boards/shields/waveshare_pico_oled_1_3/boards/rpi_pico.overlay for configure i2c.

I worry that if this PR's changes move into boards/shields/ssd1306/, the rpi_pico.overlay will do something bad in the configuration for other ssd1306....overlays.
(rpi_pico.overlay is specific for waveshare_pico_oled_1_3)
The overlay defined in ssd1306 is for Arduino, so I thought it would be better not to mix them, so I created it separately.

[jfischer-no]

I worry that if this PR's changes move into boards/shields/ssd1306/, the rpi_pico.overlay will do something bad in the configuration for other ssd1306....overlays.
(rpi_pico.overlay is specific for waveshare_pico_oled_1_3)
The overlay defined in ssd1306 is for Arduino, so I thought it would be better not to mix them, so I created it separately.

shield/foobar/boards/rpi_pico.overlay applies only to rpi_pico board, "something bad" is not to be expected. We should not have multiple shield directories with identical Kconfig.shield and similar descriptions about display controller used.

[soburi]

@jfischer-no

I worry that if this PR's changes move into boards/shields/ssd1306/, the rpi_pico.overlay will do something bad in the configuration for other ssd1306....overlays.
(rpi_pico.overlay is specific for waveshare_pico_oled_1_3)
The overlay defined in ssd1306 is for Arduino, so I thought it would be better not to mix them, so I created it separately.

shield/foobar/boards/rpi_pico.overlay applies only to rpi_pico board, "something bad" is not to be expected. We should not have multiple shield directories with identical Kconfig.shield and similar descriptions about display controller used.

I agree that your suggestion works correctly for this shield.
What I'm concerned about case that another ssd1306 shield for rpi_pico is newly added that has a different pin assignment.

For example, in the case the new shield is some_other_1306_shield_for_rpi_pico,
The directory will become as follows.

boards/shields/ssd1306/some_other_1306_shield_for_rpi_pico.overlay
boards/shields/ssd1306/waveshare_pico_oled_1_3.overlay
boards/shields/ssd1306/boards/rpi_pico.overlay

In this case, it uses the same rpi_pico.overlay by both shields.
So, I don't think this strategy will work because you will

Nothing like this is currently on the market, but I think it is a possibility that should be considered.

[jfischer-no]

@jfischer-no

I worry that if this PR's changes move into boards/shields/ssd1306/, the rpi_pico.overlay will do something bad in the configuration for other ssd1306....overlays.
(rpi_pico.overlay is specific for waveshare_pico_oled_1_3)
The overlay defined in ssd1306 is for Arduino, so I thought it would be better not to mix them, so I created it separately.

shield/foobar/boards/rpi_pico.overlay applies only to rpi_pico board, "something bad" is not to be expected. We should not have multiple shield directories with identical Kconfig.shield and similar descriptions about display controller used.

I agree that your suggestion works correctly for this shield. What I'm concerned about case that another ssd1306 shield for rpi_pico is newly added that has a different pin assignment.

For example, in the case the new shield is some_other_1306_shield_for_rpi_pico, The directory will become as follows.

boards/shields/ssd1306/some_other_1306_shield_for_rpi_pico.overlay
boards/shields/ssd1306/waveshare_pico_oled_1_3.overlay
boards/shields/ssd1306/boards/rpi_pico.overlay

In this case, it uses the same rpi_pico.overlay by both shields. So, I don't think this strategy will work because you will

Nothing like this is currently on the market, but I think it is a possibility that should be considered.

Because you configure 4c382cf#diff-868357f0097b87fbdf4a9cada9cbd5b33dfe302b591a24be6197c29625a640f2 for this shield but not at the board level. And whatever you do, it may conflict with any other shield using the same i2c interface.

[soburi]

@jfischer-no

I worry that if this PR's changes move into boards/shields/ssd1306/, the rpi_pico.overlay will do something bad in the configuration for other ssd1306....overlays.
(rpi_pico.overlay is specific for waveshare_pico_oled_1_3)
The overlay defined in ssd1306 is for Arduino, so I thought it would be better not to mix them, so I created it separately.

shield/foobar/boards/rpi_pico.overlay applies only to rpi_pico board, "something bad" is not to be expected. We should not have multiple shield directories with identical Kconfig.shield and similar descriptions about display controller used.

I agree that your suggestion works correctly for this shield. What I'm concerned about case that another ssd1306 shield for rpi_pico is newly added that has a different pin assignment.
For example, in the case the new shield is some_other_1306_shield_for_rpi_pico, The directory will become as follows.

boards/shields/ssd1306/some_other_1306_shield_for_rpi_pico.overlay
boards/shields/ssd1306/waveshare_pico_oled_1_3.overlay
boards/shields/ssd1306/boards/rpi_pico.overlay

In this case, it uses the same rpi_pico.overlay by both shields. So, I don't think this strategy will work because you will
Nothing like this is currently on the market, but I think it is a possibility that should be considered.

Because you configure 4c382cf#diff-868357f0097b87fbdf4a9cada9cbd5b33dfe302b591a24be6197c29625a640f2 for this shield but not at the board level. And whatever you do, it may conflict with any other shield using the same i2c interface.

Yes, it is. rpi_pico has no standard or typical configuration for pins. So, it should not define the default by system. In my understanding, Zephyr defines the default with only the minimum required. This is following the habit. So, I put the settings into the shield.

It's understandable that there is a possibility of collision, but isn't it too unfriendly to the user to have a mismatch happen in the simple case of using a single shield?
I think there are benefits to integrating from the perspective of eliminating duplication, but I feel it has a significant disadvantage in usability.
Also, since ssd1306 is a consistent group as a shield for Arduino, it feels strange to include something for rpi_pico here.

[github-actions]

This pull request has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this pull request will automatically be closed in 14 days. Note, that you can always re-open a closed pull request at any time.