drivers/lcd: support MCU 8080 8-bit parallel mode #19915

gschorcht · 2023-09-06T15:07:45Z

Contribution description

LCD driver ICs usually support

SPI serial mode,
MCU 8080 8-bit parallel mode and
MCU 8080 16-bit parallel mode.

This PR extends the LCD display driver API to support the MCU 8080 8-/16-bit parallel modes and implements a GPIO-driven MCU 8080 8-bit parallel mode.

The following features are already working locally and will be provided as follow-on PRs for which this PR is a prerequisite.

GPIO-driven bit-banging implementation of the 16-bit mode of the MCU 8080 parallel interface
Enabling the display on stm32f723e-disco and stm32l496g-disco using the feature above
Definition of a low-level API for the parallel modes using the LCD controller of the MCU
Using FMC for the display on stm32f723e-disco and stm32l496g-disco
Using LCD controller for the display of esp32-wt32-sc01-plus (PR boards: add support for ESP32-S3 WT32 SC01 Plus board #19917)

Testing procedure

The PR can be tested with PR #19917 on top of this PR.

BOARD=esp32s3-wt32-sc01-plus make -j8 -C tests/drivers/st77xx flash

The following video shows the test.

Please note The test is pretty slow because the display has 480 x 320 pixels and the MCU 8080 8-bit parallel interface is realized by a GPIO-driven bit-banging implementation where each GPIO of the data bus is set separately. A follow-up PR will use the ESP32-S3 LCD controller and DMA for this board. This PR just defines the extension of the driver by the parallel interface and provides the bit-banging implementation for MCUs that don't have a LCD controller on chip.

output.mp4

Issues/PRs references

riot-ci · 2023-09-07T11:54:32Z

Murdock results

✔️ PASSED

b0ec24b drivers/st7735: add MCU 8080 8-/16-bit parallel mode support

Success	Failures	Total	Runtime
7937	0	7937	13m:12s

Artifacts

Documentation preview

To be clear that the functions are low-level functions, they are renamed to `lcd_ll_*`.

drivers/include/lcd.h

benpicco

Looks pretty straightforward, just some small things

benpicco · 2023-09-15T15:54:57Z

drivers/include/lcd.h

    disp_dev_t *dev;                /**< Pointer to the generic display device */
 #endif
    const lcd_driver_t *driver;     /**< LCD driver */
    const lcd_params_t *params;     /**< Device initialization parameters */
+#if MODULE_LCD_PARALLEL || DOXYGEN
+    mutex_t lock;                   /**< Mutex used to lock the device in


Do we really need this?
I think if there are two threads trying to access the display, this would lead to chaos either way.

Good question 🤔 I have already discussed this with @aabadie and @bergzand and we basically agreed that mutual exclusion should be handled by the high-level driver, e.g. disp_dev. However, since disp_dev doesn't do this and the device driver implicitly uses mutual exclusion in SPI mode, I decided to implement mutual exclusion by the driver in parallel mode as well.

I don't see a use case where we would ever have multiple threads access the low-level driver, so I'd just avoid the added complexity.

But please document explicitly, that it is not thread safe. (I do agree with delegation of thread safety to upper layers - if needed at all. But being upfront about that may prevent long debugging sessions.)

Hm, I'm not really sure. The execution of a function like lcd_fill at low level looks like this:

lcd_ll_acquire(dev); lcd_ll_set_area(dev, x1, x2, y1, y2); lcd_ll_cmd_start(dev, LCD_CMD_RAMWR, true); for (int i = 0; i < (num_pix - 1); i++) { lcd_ll_write_bytes(dev, true, (uint8_t *)&color, sizeof(color)); } lcd_ll_write_bytes(dev, false, (uint8_t *)&color, sizeof(color)); lcd_ll_release(dev);

That is, we always acquire the device, execute some low-level transfers and releases the device. This is necessary in SPI mode to avoid that each low-level transfer acquires and release the SPI device.

But what does lcd_ll_acquire and lcd_ll_release mean in parallel mode if we don't use a mutex? lcd_ll_acquire and lcd_ll_release are not internal function but part of the documented low-level API and suggest that the driver realizes mutual exclusion.

benpicco · 2023-09-15T15:55:11Z

drivers/include/lcd.h

    disp_dev_t *dev;                /**< Pointer to the generic display device */
 #endif
    const lcd_driver_t *driver;     /**< LCD driver */
    const lcd_params_t *params;     /**< Device initialization parameters */
+#if MODULE_LCD_PARALLEL || DOXYGEN
+    mutex_t lock;                   /**< Mutex used to lock the device in


Do we really need this?
I think if there are two threads trying to access the display, this would lead to chaos either way.

Without it, we wouldn't have to drop the const

Without it, we wouldn't have to drop the const

Exactly.

drivers/include/lcd.h

benpicco · 2023-09-15T16:01:22Z

drivers/lcd/Makefile.include

@@ -1,4 +1,8 @@
 PSEUDOMODULES += lcd_multi_cntrl

+PSEUDOMODULES += lcd_spi
+PSEUDOMODULES += lcd_parallel


lcd_parallel_gpio?
I suppose if we have a native LCD interface we would need a different module name for that.

If have already defined a number of further pseudomodules for follow-up PRs that will control which data struct members and what code will be compiled in:

lcd_parallel just enables the parallel mode support, no matter whether 8-bit or 16 bits are used

lcd_parallel_16bit will enable 16-bit support in addition to the 8-bit-parallel support

lcd_parallel_ll_mcu will enable the low-level MCU driven interface that has to be implemented by the respective MCU

lcd_parallel uses the bit-banging implementation if the board doesn't enable the MCU driven implementation by lcd_parallel_ll_mcu.

To be it would feel cleaner if lcd_parallel were just a pseudo-module and each implementation had it's own name. Or is there a reason why you chose to do it that way?

lcd_parallel is already a pseudomodule which is only intended to enable the parallel interface support, i.e. to declare the required additional members of the device data structure like the GPIOs which are needed independently of the parallel interface implementation and to define functions to use the parallel interface.

Since this PR is only a evolutionary step in a series of follow-on PRs for the final implementation, the GPIO-driven bit-banging implementation is the only implementation for now and is therefore an integral part of the driver. In the final implementation, the GPIO-driven implementation will be moved to a separate file and will be only the default or fallback implementation if no other implementation is enabled.

Instead of trying to explain it in detail, please have a look at the final implementation https://github.com/gschorcht/RIOT-Xtensa-ESP/tree/drivers/lcd_work. Due to its size, I have split it into several steps as separate PRs, so naming the module may not seem reasonable for now. There will be at least 4 follow-up PRs to reach the final implementation.

benpicco · 2023-09-20T09:30:23Z

Please squash

For the parallel interface support the following changes were made: 1. Additional `lcd_*` pseudomodules are defined to control whether SPI serial or MCU 8080 8-/16-bit parallel interface is used. 2. The low level function implementation was extended for parallel interfaces so that the now can use either the SPI serial interface or the MCU 8080 8-/16-bit parallel interface. Using the `lcc_*` modules, either the SPI serial interface or the MCU 8080 8-/16-bit interface or even both for multiple display can be used simultaneously.

benpicco · 2023-09-20T11:35:20Z

bors merge

19914: boards: complete SD Card MTD definition for several bords r=benpicco a=gschorcht ### Contribution description This PR completes the MTD definition for the following boards: - `seeedstudio-gd32` - `sipeed-longan-nano` including `sipeed-longan-nano-tft` - `waveshare-nrf52840-eval-kit` - ESP32x boards that have an SPI SD Card interface and use `mtd_sdcard_default` ### Testing procedure Green CI ### Issues/PRs references#19465 Prerequisite for PR #19465 19915: drivers/lcd: support MCU 8080 8-bit parallel mode r=benpicco a=gschorcht ### Contribution description LCD driver ICs usually support - SPI serial mode, - MCU 8080 8-bit parallel mode and - MCU 8080 16-bit parallel mode. This PR extends the LCD display driver API to support the MCU 8080 8-/16-bit parallel modes and implements a GPIO-driven MCU 8080 8-bit parallel mode. The following features are already working locally and will be provided as follow-on PRs for which this PR is a prerequisite. - GPIO-driven bit-banging implementation of the 16-bit mode of the MCU 8080 parallel interface - Enabling the display on `stm32f723e-disco` and `stm32l496g-disco` using the feature above - Definition of a low-level API for the parallel modes using the LCD controller of the MCU - Using FMC for the display on `stm32f723e-disco` and `stm32l496g-disco` - Using LCD controller for the display of `esp32-wt32-sc01-plus` (PR #19917) ### Testing procedure The PR can be tested with PR #19917 on top of this PR. ``` BOARD=esp32s3-wt32-sc01-plus make -j8 -C tests/drivers/st77xx flash ``` The following video shows the test. **Please note** The test is pretty slow because the display has 480 x 320 pixels and the MCU 8080 8-bit parallel interface is realized by a GPIO-driven bit-banging implementation where each GPIO of the data bus is set separately. A follow-up PR will use the ESP32-S3 LCD controller and DMA for this board. This PR just defines the extension of the driver by the parallel interface and provides the bit-banging implementation for MCUs that don't have a LCD controller on chip. https://github.com/RIOT-OS/RIOT/assets/31932013/c1e3e3d7-05d9-4ca5-8fff-9a5eaca50fba ### Issues/PRs references 19919: drivers/st77xx: introduce rotation defines r=benpicco a=gschorcht ### Contribution description The PR introduces counterclockwise rotations for the definition of parameter `ST77XX_PARAM_ROTATION`. It is more intuitive and universal to use `ST77XX_ROTATION_{0,90,180,270}` instead of `ST77XX_ROTATION_{ST77XX_ROTATION_{VERT,VERT_FLIP,HORZ,HORZ_FLIP}`, especially because the orientation of the display may vary with respect to the orientation of the board. ### Testing procedure `tests/drivers/st77xx` should still work, for example: ``` BOARD=adafruit-pybadge make -C tests/drivers/st77xx flash ``` ``` BOARD=esp32s3-usb-otg make -j8 -C tests/drivers/st77xx flash ``` ### Issues/PRs references 19931: boards: fix documentation for GD32V boards and doxygen 1.9.4 r=benpicco a=gschorcht ### Contribution description This PR fixes some small problems in documentation of `sipeed-longan-nano`, `sipeed-longan-nano-tft` and `seeedstudio-gd32` for doxygen 1.9.4 that is used on `doc.riot-os.org`. Doxygen version 1.9.4 doesn't like anymore - single double quotes as symbol for the inches unit in the text - line breaks in `[]()` to avoid exhausting the 100 characters per line. See https://doc.riot-os.org/group__boards__sipeed__longan__nano.html for example. Doxygen 1.9.1 which is part of `riot-docker` container didn't have theses problems 😟 ### Testing procedure Documentation should be fixed. ### Issues/PRs references 19935: boards/nucleo64: fix SPI Arduino mapping for most boards r=benpicco a=maribu ### Contribution description Before, the Arduino SPI mapping for all Nucleo-64 boards was incorrect. With this, the situation improves to the following: - [x] nucleo-f030r8 - [ ] nucleo-f070rb - No SPI buses provided. - [x] nucleo-f072rb - [x] nucleo-f091rc - [x] nucleo-f103rb - [ ] nucleo-f302r8 - No SPI bus at D11, D12, D13 provided - [x] nucleo-f303re - [x] nucleo-f334r8 - [x] nucleo-f401re - [x] nucleo-f410rb - [x] nucleo-f411re - [x] nucleo-f446re - [x] nucleo-g070rb - [x] nucleo-g071rb - [x] nucleo-g431rb - [x] nucleo-g474re - [x] nucleo-l053r8 - [x] nucleo-l073rz - [x] nucleo-l152re - No SPI bus at D11, D12, D13 provided - [x] nucleo-l452re - [x] nucleo-l476rg - [x] nucleo-wl55jc The remaining offenders still need to be fixed, but that is better done one PR at a time. ### Testing procedure - Check if the SPI device provided in the given `boards/<BOARD_NAME>/incude/periph_conf.h` is indeed `SPI_DEV(0)`, or in `periph_conf.h` the correct SPI dev is found - this should be fine for all boards above, except for the unchecked ones or: - run #19932: The SPI test should pass now ### Issues/PRs references Bug found in #19932 (comment) Co-authored-by: Gunar Schorcht <gunar@schorcht.net> Co-authored-by: Marian Buschsieweke <marian.buschsieweke@posteo.net>

bors · 2023-09-20T11:40:25Z

Build failed (retrying...):

Murdock

19914: boards: complete SD Card MTD definition for several bords r=benpicco a=gschorcht ### Contribution description This PR completes the MTD definition for the following boards: - `seeedstudio-gd32` - `sipeed-longan-nano` including `sipeed-longan-nano-tft` - `waveshare-nrf52840-eval-kit` - ESP32x boards that have an SPI SD Card interface and use `mtd_sdcard_default` ### Testing procedure Green CI ### Issues/PRs references#19465 Prerequisite for PR #19465 19915: drivers/lcd: support MCU 8080 8-bit parallel mode r=benpicco a=gschorcht ### Contribution description LCD driver ICs usually support - SPI serial mode, - MCU 8080 8-bit parallel mode and - MCU 8080 16-bit parallel mode. This PR extends the LCD display driver API to support the MCU 8080 8-/16-bit parallel modes and implements a GPIO-driven MCU 8080 8-bit parallel mode. The following features are already working locally and will be provided as follow-on PRs for which this PR is a prerequisite. - GPIO-driven bit-banging implementation of the 16-bit mode of the MCU 8080 parallel interface - Enabling the display on `stm32f723e-disco` and `stm32l496g-disco` using the feature above - Definition of a low-level API for the parallel modes using the LCD controller of the MCU - Using FMC for the display on `stm32f723e-disco` and `stm32l496g-disco` - Using LCD controller for the display of `esp32-wt32-sc01-plus` (PR #19917) ### Testing procedure The PR can be tested with PR #19917 on top of this PR. ``` BOARD=esp32s3-wt32-sc01-plus make -j8 -C tests/drivers/st77xx flash ``` The following video shows the test. **Please note** The test is pretty slow because the display has 480 x 320 pixels and the MCU 8080 8-bit parallel interface is realized by a GPIO-driven bit-banging implementation where each GPIO of the data bus is set separately. A follow-up PR will use the ESP32-S3 LCD controller and DMA for this board. This PR just defines the extension of the driver by the parallel interface and provides the bit-banging implementation for MCUs that don't have a LCD controller on chip. https://github.com/RIOT-OS/RIOT/assets/31932013/c1e3e3d7-05d9-4ca5-8fff-9a5eaca50fba ### Issues/PRs references Co-authored-by: Gunar Schorcht <gunar@schorcht.net>

bors · 2023-09-20T11:41:20Z

This PR was included in a batch that was canceled, it will be automatically retried

19915: drivers/lcd: support MCU 8080 8-bit parallel mode r=benpicco a=gschorcht ### Contribution description LCD driver ICs usually support - SPI serial mode, - MCU 8080 8-bit parallel mode and - MCU 8080 16-bit parallel mode. This PR extends the LCD display driver API to support the MCU 8080 8-/16-bit parallel modes and implements a GPIO-driven MCU 8080 8-bit parallel mode. The following features are already working locally and will be provided as follow-on PRs for which this PR is a prerequisite. - GPIO-driven bit-banging implementation of the 16-bit mode of the MCU 8080 parallel interface - Enabling the display on `stm32f723e-disco` and `stm32l496g-disco` using the feature above - Definition of a low-level API for the parallel modes using the LCD controller of the MCU - Using FMC for the display on `stm32f723e-disco` and `stm32l496g-disco` - Using LCD controller for the display of `esp32-wt32-sc01-plus` (PR #19917) ### Testing procedure The PR can be tested with PR #19917 on top of this PR. ``` BOARD=esp32s3-wt32-sc01-plus make -j8 -C tests/drivers/st77xx flash ``` The following video shows the test. **Please note** The test is pretty slow because the display has 480 x 320 pixels and the MCU 8080 8-bit parallel interface is realized by a GPIO-driven bit-banging implementation where each GPIO of the data bus is set separately. A follow-up PR will use the ESP32-S3 LCD controller and DMA for this board. This PR just defines the extension of the driver by the parallel interface and provides the bit-banging implementation for MCUs that don't have a LCD controller on chip. https://github.com/RIOT-OS/RIOT/assets/31932013/c1e3e3d7-05d9-4ca5-8fff-9a5eaca50fba ### Issues/PRs references Co-authored-by: Gunar Schorcht <gunar@schorcht.net>

benpicco · 2023-09-20T15:55:14Z

bors cancel
bors merge

bors · 2023-09-20T15:55:16Z

Canceled.

bors · 2023-09-20T19:56:45Z

Build succeeded!

The publicly hosted instance of bors-ng is deprecated and will go away soon.

If you want to self-host your own instance, instructions are here.
For more help, visit the forum.

If you want to switch to GitHub's built-in merge queue, visit their help page.

19917: boards: add support for ESP32-S3 WT32 SC01 Plus board r=benpicco a=gschorcht ### Contribution description This PR provides support for the [Wireless Tag WT32-SC01 Plus with ESP32-S3](http://en.wireless-tag.com/product-item-26.html) board. The board has the following main features: - ESP32-S3 SoC - 16 MB Flash - 2 MB QSPI RAM - 3.5" LCD Display 480 x 320 with ST7796UI - Capacitive Touch Panel with FT6336U - SD Card SPI mode - USB Type-C **Please note**: The ST7796UI display uses the MCU8080 8-bit parallel interface which require the changes in PR #19915. ### Testing procedure 1. `tests/drivers/st77xx` should work on top of PR #19915. ``` BOARD=esp32s3-wt32-sc01-plus make -j8 -C tests/drivers/st77xx flash ``` 2. `tests/drivers/ft5x06` should work with `stdio_uart` and the debugging tool. ``` USEMODULE=stdio_uart BOARD=esp32s3-wt32-sc01-plus make -j8 -C tests/drivers/ft5x06/ flash term ``` ``` main(): This is RIOT! (Version: 2023.10-devel-245-g55bd7-boards/esp32s3-wt32-sc01-plus) FT5x06 test application +------------Initializing------------+ Initialization successful 1 touch detected Touch 1 - X: 177, Y:96 Touch 1 - X: 177, Y:96 Touch 1 - X: 177, Y:96 Touch 1 - X: 177, Y:97 Touch 1 - X: 178, Y:99 Touch 1 - X: 180, Y:102 Touch 1 - X: 184, Y:106 Touch 1 - X: 190, Y:110 Touch 1 - X: 197, Y:116 Touch 1 - X: 204, Y:122 Released! ``` ### Issues/PRs references Co-authored-by: Gunar Schorcht <gunar@schorcht.net>

gschorcht requested review from leandrolanzieri, jia200x and MrKevinWeiss as code owners September 6, 2023 15:07

github-actions bot added Area: drivers Area: Device drivers Area: Kconfig Area: Kconfig integration labels Sep 6, 2023

benpicco requested review from aabadie and maribu September 6, 2023 16:46

gschorcht mentioned this pull request Sep 7, 2023

boards: add support for ESP32-S3 WT32 SC01 Plus board #19917

Merged

gschorcht added Type: new feature The issue requests / The PR implemements a new feature for RIOT CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR labels Sep 7, 2023

drivers/lcd: rename low-level functions

f03bc33

To be clear that the functions are low-level functions, they are renamed to `lcd_ll_*`.

gschorcht force-pushed the drivers/lcd_parallel_mode_8bit branch from f5e86aa to 60ae751 Compare September 8, 2023 06:23

aabadie reviewed Sep 8, 2023

View reviewed changes

drivers/include/lcd.h Outdated Show resolved Hide resolved

gschorcht added this to the Release 2023.10 milestone Sep 15, 2023

benpicco reviewed Sep 15, 2023

View reviewed changes

benpicco approved these changes Sep 20, 2023

View reviewed changes

gschorcht added 4 commits September 20, 2023 13:03

drivers/lcd: remove const for dev due to the mutex

9dde49d

drivers/ili9341: add MCU 8080 8-/16-bit parallel mode support

10122a7

drivers/st7735: add MCU 8080 8-/16-bit parallel mode support

b0ec24b

gschorcht force-pushed the drivers/lcd_parallel_mode_8bit branch from 8f90597 to b0ec24b Compare September 20, 2023 11:04

gschorcht added the CI: ready for merge train 🚃 PR is ready to be merged and awaiting the next merge train label Sep 20, 2023

bors bot merged commit 1691dbe into RIOT-OS:master Sep 20, 2023
24 checks passed

gschorcht deleted the drivers/lcd_parallel_mode_8bit branch September 20, 2023 23:03

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

drivers/lcd: support MCU 8080 8-bit parallel mode #19915

drivers/lcd: support MCU 8080 8-bit parallel mode #19915

gschorcht commented Sep 6, 2023 •

edited

Loading

riot-ci commented Sep 7, 2023 •

edited

Loading

benpicco left a comment

benpicco Sep 15, 2023

gschorcht Sep 17, 2023

benpicco Sep 17, 2023

maribu Sep 17, 2023

gschorcht Sep 17, 2023 •

edited

Loading

benpicco Sep 15, 2023

gschorcht Sep 17, 2023

benpicco Sep 15, 2023

gschorcht Sep 17, 2023 •

edited

Loading

gschorcht Sep 17, 2023

benpicco Sep 17, 2023

gschorcht Sep 17, 2023 •

edited

Loading

benpicco commented Sep 20, 2023

benpicco commented Sep 20, 2023

bors bot commented Sep 20, 2023

bors bot commented Sep 20, 2023

benpicco commented Sep 20, 2023

bors bot commented Sep 20, 2023

bors bot commented Sep 20, 2023

drivers/lcd: support MCU 8080 8-bit parallel mode #19915

drivers/lcd: support MCU 8080 8-bit parallel mode #19915

Conversation

gschorcht commented Sep 6, 2023 • edited Loading

Contribution description

Testing procedure

Issues/PRs references

riot-ci commented Sep 7, 2023 • edited Loading

Murdock results

Artifacts

benpicco left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

gschorcht Sep 17, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

gschorcht Sep 17, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

gschorcht Sep 17, 2023 • edited Loading

Choose a reason for hiding this comment

benpicco commented Sep 20, 2023

benpicco commented Sep 20, 2023

bors bot commented Sep 20, 2023

bors bot commented Sep 20, 2023

benpicco commented Sep 20, 2023

bors bot commented Sep 20, 2023

bors bot commented Sep 20, 2023

gschorcht commented Sep 6, 2023 •

edited

Loading

riot-ci commented Sep 7, 2023 •

edited

Loading

gschorcht Sep 17, 2023 •

edited

Loading

gschorcht Sep 17, 2023 •

edited

Loading

gschorcht Sep 17, 2023 •

edited

Loading