drivers/lcd: add MCU-driven low-level parallel interface #19941

gschorcht · 2023-09-22T09:14:09Z

Contribution description

The PR extends the LCD driver by a low-level interface for MCU-driven implementations of the MCU 8080 16-/8-bit parallel interface, allowing the MCU to use special peripherals for the interface, such as the FMC for STM32 MCUs, which is significantly faster than the integrated GPIO-driven parallel interface implementation of the LCD driver.

Testing procedure

~~Once PR #19938 and PR #19939 are merged, a PRs for these board can be pushed that allow to test this PR.~~

Use either PR #19943 or PR #19944 on top of this PR to test, e.g. with PR #19943:

BOARD=stm32f723e-disco make -j8 -C tests/drivers/st77xx flash

Issues/PRs references

riot-ci · 2023-09-22T09:19:32Z

Murdock results

✔️ PASSED

e0a76c5 drivers/lcd: add MCU-driven low-level parallel interface

Success	Failures	Total	Runtime
7937	0	7937	14m:58s

Artifacts

Documentation preview

benpicco · 2023-09-22T13:26:39Z

drivers/lcd/lcd.c

+        if (lcd_ll_par_driver.init) {
+            lcd_ll_par_driver.init(dev);
+        }
+        else {
+           lcd_ll_par_gpio_init(dev);
+        }


Can we have a lcd_parallel_gpio or lcd_parallel_periph pseudo-module so we can have this check compile-time const if only one of the two is used - and don't have to include all the bit-banging code when a periph implementation is used.

Makes sense.

actually, why have the switch at all instead of

lcd_ll_par_driver.init = lcd_ll_par_gpio_init;

for the bit-banging case

It is not necessary that the MCU implements all low-level functions. For example, the ESP32 implementation doesn't define the init and cmd_start driver functions. If the MCU-driven low-level implementation doesn't define them, the corresponding lcd_ll_par_gpio_* functions are used instead.

Alternatively, we could set those members of the driver structure to the lcd_ll_par_gpio_* functions in the MCU-driven low-level implementation.

I'm still not really happy having only one low-level driver instance. This avoids to use multiple displays with parallel interface but different low-level implementations. Ideally, each display device should point to it's own low-level implementation. But the configuration via the constant LCD display parameter set seems to be too complicated. Doing it in RAM during the initialization of the device would cost a lot of RAM.

On the other hand, the question arises whether there will ever be a board with two or more displays and whether multiple displays with different low-level implementations would then be used. Parallel interfaces occupy soooooo many GPIOs that we can probably assume that if we used the parallel interface, all displays would use the same interface but with different select signals. If this assumption is true, only one low-level driver instance is sufficient.

MrKevinWeiss · 2023-09-26T18:34:01Z

Anything blocking this?

gschorcht · 2023-10-03T11:53:57Z

Anything blocking this?

Not from point view.

benpicco

Looks good from my side too, sorry for the delay

benpicco · 2023-10-05T09:29:24Z

bors merge

bors · 2023-10-05T13:41:30Z

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.

gschorcht · 2023-10-05T16:39:38Z

Thanks

19943: cpu/stm32: FMC used for low-level LCD parallel interface r=aabadie a=gschorcht ### Contribution description This PR provides the implementation of the LCD low-level MCU 8080 parallel interface using the FMC peripheral. ### Testing procedure ``` BOARD=stm32f723e-disco make -C tests/drivers/st77xx flash ``` and ``` BOARD=stm32l496g-disco make -C tests/drivers/st77xx flash ``` should work on top of PR #19941. Drawing operations should be much faster. ### Issues/PRs references Depends on PR #19941 Co-authored-by: Gunar Schorcht <gunar@schorcht.net>

19943: cpu/stm32: FMC used for low-level LCD parallel interface r=MrKevinWeiss a=gschorcht ### Contribution description This PR provides the implementation of the LCD low-level MCU 8080 parallel interface using the FMC peripheral. ### Testing procedure ``` BOARD=stm32f723e-disco make -C tests/drivers/st77xx flash ``` and ``` BOARD=stm32l496g-disco make -C tests/drivers/st77xx flash ``` should work on top of PR #19941. Drawing operations should be much faster. ### Issues/PRs references Depends on PR #19941 Co-authored-by: Gunar Schorcht <gunar@schorcht.net>

19943: cpu/stm32: FMC used for low-level LCD parallel interface r=maribu a=gschorcht ### Contribution description This PR provides the implementation of the LCD low-level MCU 8080 parallel interface using the FMC peripheral. ### Testing procedure ``` BOARD=stm32f723e-disco make -C tests/drivers/st77xx flash ``` and ``` BOARD=stm32l496g-disco make -C tests/drivers/st77xx flash ``` should work on top of PR #19941. Drawing operations should be much faster. ### Issues/PRs references Depends on PR #19941 19978: treewide: fix typos to make codespell happy r=maribu a=maribu ### Contribution description - fixes typos in comments and docs (no generated firmware changes expected) - fixes a typo in a string in a GUI of a utility program - add some false positives to the ignore list ### Testing procedure - No generated binaries (except for the GUI version of the utility program to flash the MSB-A2) should change - The diff should not look too scary ### Issues/PRs references None Co-authored-by: Gunar Schorcht <gunar@schorcht.net> Co-authored-by: Marian Buschsieweke <marian.buschsieweke@posteo.net>

19546: Enable compile_and_test_for_board to skip if nothing changed r=benpicco a=MrKevinWeiss ### Contribution description The overall goal of this PR is to be able to keep running the `compile_and_test_for_board.py` script without destroying ones boards. Useful if you are a board owner that wants to keep testing on master (say with nightlies, say in a CI). For example, I could now just run and rerun the following: ``` ./dist/tools/compile_and_test_for_board/compile_and_test_for_board.py . <MY_BOARD> -c ``` and monitor the results, even after updating a branch. This is because the hashes now get stored with the results (thanks to the `RIOT_TEST_HASH_DIR` var) which means cleaning will not wipe them out. Specifically in (`<results_base>/<board>/hashes/<app_dir>/test-input-hash.sha1`) I tried to do as much as I could with make and only alter the python script when needed. ### Testing procedure Clear results folder and run: ``` ./dist/tools/compile_and_test_for_board/compile_and_test_for_board.py . native --applications tests/shell -c ``` <details> ``` INFO:native:Saving toolchain INFO:native.tests/shell:Board supported: True INFO:native.tests/shell:Board has enough memory: True INFO:native.tests/shell:Application has test: True INFO:native.tests/shell:Run compilation **INFO:native.tests/shell:Hashes match: False** INFO:native.tests/shell:Run test INFO:native.tests/shell:Run test.flash INFO:native.tests/shell:Success INFO:native:Tests successful ``` </details> it should execute the test... Then the same command again should skip it. <details> ``` INFO:native:Saving toolchain INFO:native.tests/shell:Board supported: True INFO:native.tests/shell:Board has enough memory: True INFO:native.tests/shell:Application has test: True INFO:native.tests/shell:Run compilation **INFO:native.tests/shell:Hashes match: True** INFO:native.tests/shell:Success INFO:native:Tests successful ``` </details> Try changing something (say the `tests/shell/01-run.py`) and rerun, it should trigger the test again. <details> ``` INFO:native:Saving toolchain INFO:native.tests/shell:Board supported: True INFO:native.tests/shell:Board has enough memory: True INFO:native.tests/shell:Application has test: True INFO:native.tests/shell:Run compilation **INFO:native.tests/shell:Hashes match: False** INFO:native.tests/shell:Run test INFO:native.tests/shell:Run test.flash INFO:native.tests/shell:Success INFO:native:Tests successful ``` </details> ...finally, running without the changes check should run the test as usual, even if nothing changes: ``` ./dist/tools/compile_and_test_for_board/compile_and_test_for_board.py . native --applications tests/shell ``` <details> ``` INFO:native:Saving toolchain INFO:native.tests/shell:Board supported: True INFO:native.tests/shell:Board has enough memory: True INFO:native.tests/shell:Application has test: True INFO:native.tests/shell:Run compilation INFO:native.tests/shell:Run test INFO:native.tests/shell:Run test.flash INFO:native.tests/shell:Success INFO:native:Tests successful ``` </details> ### Issues/PRs references Might help the surprises we got with #19469 19944: cpu/esp32: add low-level LCD parallel interface using LCD peripheral r=benpicco a=gschorcht ### Contribution description This PR the implementation of the LCD low-level MCU 8080 parallel interface using the LCD peripheral for ESP32, ESP32-S2 and ESP32-S3 or `periph_gpio_ll` for the ESP32-C3. ### Testing procedure ``` BOARD=esp32s3-wt32-sc01-plus make -C tests/drivers/st77xx flash ``` should work on top of PR #19941. Drawing operations should be much faster. ### Issues/PRs references Co-authored-by: MrKevinWeiss <weiss.kevin604@gmail.com> Co-authored-by: Gunar Schorcht <gunar@schorcht.net>

19944: cpu/esp32: add low-level LCD parallel interface using LCD peripheral r=benpicco a=gschorcht ### Contribution description This PR the implementation of the LCD low-level MCU 8080 parallel interface using the LCD peripheral for ESP32, ESP32-S2 and ESP32-S3 or `periph_gpio_ll` for the ESP32-C3. ### Testing procedure ``` BOARD=esp32s3-wt32-sc01-plus make -C tests/drivers/st77xx flash ``` should work on top of PR #19941. Drawing operations should be much faster. ### Issues/PRs references Co-authored-by: Gunar Schorcht <gunar@schorcht.net>

gschorcht requested review from leandrolanzieri, jia200x, MrKevinWeiss, smlng, aabadie, MichelRottleuthner and fjmolinas as code owners September 22, 2023 09:14

github-actions bot added Area: tests Area: tests and testing framework Area: drivers Area: Device drivers Area: Kconfig Area: Kconfig integration labels Sep 22, 2023

gschorcht added Type: enhancement The issue suggests enhanceable parts / The PR enhances parts of the codebase / documentation CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR labels Sep 22, 2023

gschorcht added CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR and removed CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR labels Sep 22, 2023

gschorcht force-pushed the drivers/lcd_ll_mcu branch 2 times, most recently from 8e41e49 to abfbfa4 Compare September 22, 2023 12:53

benpicco reviewed Sep 22, 2023

View reviewed changes

gschorcht added 3 commits September 22, 2023 17:00

drivers/st77xx: fix compilation with NDEBUG

4ae2e65

drivers/lcd: expose lcd_ll_set_area function

8306838

tests/drivers/st77xx: read ID and status

a73ff74

gschorcht force-pushed the drivers/lcd_ll_mcu branch 2 times, most recently from c1c98a9 to 0851952 Compare September 23, 2023 05:48

gschorcht added 2 commits September 23, 2023 08:03

drivers/lcd: move GPIO low-level interface to separate file

0353e05

drivers/lcd: add MCU-driven low-level parallel interface

e0a76c5

gschorcht force-pushed the drivers/lcd_ll_mcu branch from 0851952 to e0a76c5 Compare September 23, 2023 06:04

This was referenced Sep 23, 2023

cpu/stm32: FMC used for low-level LCD parallel interface #19943

Merged

cpu/esp32: add low-level LCD parallel interface using LCD peripheral #19944

Merged

benpicco approved these changes Oct 4, 2023

View reviewed changes

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

bors bot merged commit dd62f41 into RIOT-OS:master Oct 5, 2023

MrKevinWeiss added this to the Release 2023.10 milestone Nov 17, 2023

gschorcht deleted the drivers/lcd_ll_mcu branch November 22, 2024 06:46

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

drivers/lcd: add MCU-driven low-level parallel interface #19941

drivers/lcd: add MCU-driven low-level parallel interface #19941

gschorcht commented Sep 22, 2023 •

edited

Loading

riot-ci commented Sep 22, 2023 •

edited

Loading

benpicco Sep 22, 2023

gschorcht Sep 22, 2023

benpicco Sep 22, 2023

gschorcht Sep 22, 2023

gschorcht Sep 22, 2023

MrKevinWeiss commented Sep 26, 2023

gschorcht commented Oct 3, 2023

benpicco left a comment

benpicco commented Oct 5, 2023

bors bot commented Oct 5, 2023

gschorcht commented Oct 5, 2023

drivers/lcd: add MCU-driven low-level parallel interface #19941

drivers/lcd: add MCU-driven low-level parallel interface #19941

Conversation

gschorcht commented Sep 22, 2023 • edited Loading

Contribution description

Testing procedure

Issues/PRs references

riot-ci commented Sep 22, 2023 • edited Loading

Murdock results

Artifacts

benpicco Sep 22, 2023

Choose a reason for hiding this comment

gschorcht Sep 22, 2023

Choose a reason for hiding this comment

benpicco Sep 22, 2023

Choose a reason for hiding this comment

gschorcht Sep 22, 2023

Choose a reason for hiding this comment

gschorcht Sep 22, 2023

Choose a reason for hiding this comment

MrKevinWeiss commented Sep 26, 2023

gschorcht commented Oct 3, 2023

benpicco left a comment

Choose a reason for hiding this comment

benpicco commented Oct 5, 2023

bors bot commented Oct 5, 2023

gschorcht commented Oct 5, 2023

gschorcht commented Sep 22, 2023 •

edited

Loading

riot-ci commented Sep 22, 2023 •

edited

Loading