zephyrproject-rtos / zephyr

Primary Git Repository for the Zephyr Project. Zephyr is a new generation, scalable, optimized, secure RTOS for multiple hardware architectures.
https://docs.zephyrproject.org
Apache License 2.0
10.52k stars 6.45k forks source link

Something is wrong when trying ST7789V sample #20278

Closed zzzh closed 4 years ago

zzzh commented 4 years ago

Describe the bug Hello, I have a ST7789V based LCD module ( a 1.54" one, not TL019FQV01), and nrf52_pca10040 board, so I did a try on ST7789V sample. Unfortunately, I got "display_st7789v: Could not get SPI device for LCD", I checked the code and realize that it can't find it from the inited driver. I don't understand why, any ideas?

To Reproduce Steps to reproduce the behavior: Just follow the readme in ST7789V sample

Expected behavior see something being showed on the LCD

Impact annoyance

Screenshots or console output Booting Zephyr OS build zephyr-v2.0.0-1112-gb71eb71de72f [00:00:00.005,462] display_st7789v: Could not get SPI device for LCD [00:00:00.005,462] app: ST7789V display sample [00:00:00.005,493] app: Device not found. Aborting test.

Environment (please complete the following information):

Additional context nothing more by now

vanwinkeljan commented 4 years ago

@zzzh did you have any chance in testing my responce on your question in the orignal PR https://github.com/zephyrproject-rtos/zephyr/pull/17358#issuecomment-548952628 ?

zzzh commented 4 years ago

@vanwinkeljan Thanks for replying. I did not try that, and don't think that's the way to solve it. Actually, I'd fixed it by adding a line in proj.conf : CONFIG_SPI_x=y, x is the number of SPI channel you chose in the overlay file. @carlescufi I think this is a bug.

vanwinkeljan commented 4 years ago

@zzzh

I did not try that, and don't think that's the way to solve it. Actually, I'd fixed it by adding a line in proj.conf : CONFIG_SPI_x=y, x is the number of SPI channel you chose in the overlay file.

Note that CONFIG_SPI_1 is set by default to y, so that is the reason why asked if you could use SPI 1 instead.

But anyway if it is solved by setting CONFIG_SPI_0=y than it confirms it is a bug.

jfischer-no commented 4 years ago

The sample self is a bug, I suggest to remove this sample from the tree and add a generic shield for arduino spi.

vanwinkeljan commented 4 years ago

@jfischer-phytec-iot I created a PR #20570 to introduce a ST7789V shield and updated the existing sample. I will create a seperate PR to introduce a common sample for display shields.

@zzzh could you verify if the sample is working with PR #20570, I do not have a ST7789V based display?

Example build command: west build -b nrf52_pca10040 samples/display/st7789v -- -DSHIELD=st7789v_generic

vanwinkeljan commented 4 years ago

@jfischer-phytec-iot pushed a PR (#20580) for a generic display shield sample

zzzh commented 4 years ago

@vanwinkeljan

Note that CONFIG_SPI_1 is set by default to y, so that is the reason why asked if you could use SPI 1 instead.

Where's the default CONFIG_SPI_1=y ? I can't find it

zzzh commented 4 years ago

@vanwinkeljan

@zzzh could you verify if the sample is working with PR #20570, I do not have a ST7789V based display?

Example build command: west build -b nrf52_pca10040 samples/display/st7789v -- -DSHIELD=st7789v_generic

Sure, should I pull a branch first?

vanwinkeljan commented 4 years ago

@zzzh yes, you can pull this pr directly, see https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/checking-out-pull-requests-locally#modifying-an-inactive-pull-request-locally on how to do this.

Btw keep in mind that the pin-out changed

zzzh commented 4 years ago

@vanwinkeljan I did the pull and took a look, realize that this test would need an Arduino LCD shield which I don't have..

jfischer-no commented 4 years ago

@vanwinkeljan I did the pull and took a look, realize that this test would need an Arduino LCD shield which I don't have..

How did you connected the display to nrf52_pca10040 board then?

zzzh commented 4 years ago

Using dupond wires

jfischer-no commented 4 years ago

Using dupond wires

Then, you could use the same wires to connect the display to the arduino connector as described in the pull request.

zzzh commented 4 years ago

Sounds good, I'll try it, thank you.

zzzh commented 4 years ago

When I run "west build -b nrf52_pca10040 samples/display/st7789v -- -DSHIELD=st7789v_generic" It says: No shield named 'st7789v_generic' found

Seems some files not ready yet

vanwinkeljan commented 4 years ago

@zzzh are your sure you did checkout the PR branch and have no leftover build directory?

You could try:

 west build -b nrf52_pca10040 samples/display/st7789v --pristine -- -DSHIELD=st7789v_generic
zzzh commented 4 years ago

@vanwinkeljan Maybe I pulled another PR #20580, let me try 20570

zzzh commented 4 years ago

@vanwinkeljan Pulled right PR number this time, but got a lot of errors:

`/home/zhu/workspace/zephyrproject/zephyr/drivers/clock_control/nrf_power_clock.c: In function 'clock_event_check_and_clean': /home/zhu/workspace/zephyrproject/zephyr/drivers/clock_control/nrf_power_clock.c:53:34: error: incompatible type for argument 1 of 'nrf_clock_event_check' bool ret = nrf_clock_event_check(NRF_CLOCK, evt) && ^~~~~~~
In file included from ../include/drivers/clock_control/nrf_clock_control.h:11, from /home/zhu/workspace/zephyrproject/zephyr/drivers/clock_control/nrf_power_clock.c:10: /home/zhu/workspace/zephyrproject/modules/hal/nordic/nrfx/hal/nrf_clock.h:423:61: note: expected 'nrf_clock_event_t' {aka 'enum '} but argument is of type 'NRF_CLOCK_Type ' {aka 'struct '} __STATIC_INLINE bool nrf_clock_event_check(nrf_clock_event_t event)


/home/zhu/workspace/zephyrproject/zephyr/drivers/clock_control/nrf_power_clock.c:53:12: error: too many arguments to function 'nrf_clock_event_check'
  bool ret = nrf_clock_event_check(NRF_CLOCK, evt) &&
            ^~~~~~~~~~~~~~~~~~~~~
In file included from ../include/drivers/clock_control/nrf_clock_control.h:11,
                 from /home/zhu/workspace/zephyrproject/zephyr/drivers/clock_control/nrf_power_clock.c:10:
/home/zhu/workspace/zephyrproject/modules/hal/nordic/nrfx/hal/nrf_clock.h:423:21: note: declared here
 __STATIC_INLINE bool nrf_clock_event_check(nrf_clock_event_t event)
                     ^~~~~~~~~~~~~~~~~~~~~
/home/zhu/workspace/zephyrproject/zephyr/drivers/clock_control/nrf_power_clock.c:54:31: error: incompatible type for argument 1 of 'nrf_clock_int_enable_check'
    nrf_clock_int_enable_check(NRF_CLOCK, intmask);
                               ^~~~~~~~~~~~~~~~~~~~            
In file included from ../include/drivers/clock_control/nrf_clock_control.h:11,
                 from /home/zhu/workspace/zephyrproject/zephyr/drivers/clock_control/nrf_power_clock.c:10:
/home/zhu/workspace/zephyrproject/modules/hal/nordic/nrfx/hal/nrf_clock.h:394:69: note: expected 'nrf_clock_int_mask_t' {aka 'enum <anonymous>'} but argument is of type 'NRF_CLOCK_Type *' {aka 'struct <anonymous> *'}
 __STATIC_INLINE bool nrf_clock_int_enable_check(nrf_clock_int_mask_t int_mask)
                                                ~~~~~~~~~~~~~~~~~~~~~^~~~~~~~
/home/zhu/workspace/zephyrproject/zephyr/drivers/clock_control/nrf_power_clock.c:54:4: error: too many arguments to function 'nrf_clock_int_enable_check'
    nrf_clock_int_enable_check(NRF_CLOCK, intmask);
    ^~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from ../include/drivers/clock_control/nrf_clock_control.h:11,
                 from /home/zhu/workspace/zephyrproject/zephyr/drivers/clock_control/nrf_power_clock.c:10:
/home/zhu/workspace/zephyrproject/modules/hal/nordic/nrfx/hal/nrf_clock.h:394:21: note: declared here
 __STATIC_INLINE bool nrf_clock_int_enable_check(nrf_clock_int_mask_t int_mask)
                     ^~~~~~~~~~~~~~~~~~~~~~~~~~
/home/zhu/workspace/zephyrproject/zephyr/drivers/clock_control/nrf_power_clock.c:57:25: error: incompatible type for argument 1 of 'nrf_clock_event_clear'
   nrf_clock_event_clear(NRF_CLOCK, evt);
                         ^~~~~~~~~~~~~~~~                
In file included from ../include/drivers/clock_control/nrf_clock_control.h:11,
                 from /home/zhu/workspace/zephyrproject/zephyr/drivers/clock_control/nrf_power_clock.c:10:
/home/zhu/workspace/zephyrproject/modules/hal/nordic/nrfx/hal/nrf_clock.h:414:60: note: expected 'nrf_clock_event_t' {aka 'enum <anonymous>'} but argument is of type 'NRF_CLOCK_Type *' {aka 'struct <anonymous> *'}
 __STATIC_INLINE void nrf_clock_event_clear(nrf_clock_event_t event)
                                          ~~~~~~~~~~~~~~~~~~^~~~~
/home/zhu/workspace/zephyrproject/zephyr/drivers/clock_control/nrf_power_clock.c:57:3: error: too many arguments to function 'nrf_clock_event_clear'
   nrf_clock_event_clear(NRF_CLOCK, evt);
   ^~~~~~~~~~~~~~~~~~~~~
In file included from ../include/drivers/clock_control/nrf_clock_control.h:11,
                 from /home/zhu/workspace/zephyrproject/zephyr/drivers/clock_control/nrf_power_clock.c:10:
/home/zhu/workspace/zephyrproject/modules/hal/nordic/nrfx/hal/nrf_clock.h:414:20: note: declared here
 __STATIC_INLINE void nrf_clock_event_clear(nrf_clock_event_t event)
                    ^~~~~~~~~~~~~~~~~~~~~
/home/zhu/workspace/zephyrproject/zephyr/drivers/clock_control/nrf_power_clock.c: In function 'clock_stop':
/home/zhu/workspace/zephyrproject/zephyr/drivers/clock_control/nrf_power_clock.c:99:27: error: incompatible type for argument 1 of 'nrf_clock_task_trigger'
    nrf_clock_task_trigger(NRF_CLOCK, config->stop_tsk);
                           ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~   
In file included from ../include/drivers/clock_control/nrf_clock_control.h:11,
                 from /home/zhu/workspace/zephyrproject/zephyr/drivers/clock_control/nrf_power_clock.c:10:
/home/zhu/workspace/zephyrproject/modules/hal/nordic/nrfx/hal/nrf_clock.h:404:60: note: expected 'nrf_clock_task_t' {aka 'enum <anonymous>'} but argument is of type 'NRF_CLOCK_Type *' {aka 'struct <anonymous> *'}
 __STATIC_INLINE void nrf_clock_task_trigger(nrf_clock_task_t task)
                                           ~~~~~~~~~~~~~~~~~^~~~
/home/zhu/workspace/zephyrproject/zephyr/drivers/clock_control/nrf_power_clock.c:99:4: error: too many arguments to function 'nrf_clock_task_trigger'
    nrf_clock_task_trigger(NRF_CLOCK, config->stop_tsk);
    ^~~~~~~~~~~~~~~~~~~~~~
In file included from ../include/drivers/clock_control/nrf_clock_control.h:11,
                 from /home/zhu/workspace/zephyrproject/zephyr/drivers/clock_control/nrf_power_clock.c:10:
/home/zhu/workspace/zephyrproject/modules/hal/nordic/nrfx/hal/nrf_clock.h:404:20: note: declared here
 __STATIC_INLINE void nrf_clock_task_trigger(nrf_clock_task_t task)
                    ^~~~~~~~~~~~~~~~~~~~~~
/home/zhu/workspace/zephyrproject/zephyr/drivers/clock_control/nrf_power_clock.c:106:26: error: incompatible type for argument 1 of 'nrf_clock_event_clear'
    nrf_clock_event_clear(NRF_CLOCK, config->started_evt);
                          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from ../include/drivers/clock_control/nrf_clock_control.h:11,
                 from /home/zhu/workspace/zephyrproject/zephyr/drivers/clock_control/nrf_power_clock.c:10:
/home/zhu/workspace/zephyrproject/modules/hal/nordic/nrfx/hal/nrf_clock.h:414:60: note: expected 'nrf_clock_event_t' {aka 'enum <anonymous>'} but argument is of type 'NRF_CLOCK_Type *' {aka 'struct <anonymous> *'}
 __STATIC_INLINE void nrf_clock_event_clear(nrf_clock_event_t event)
                                          ~~~~~~~~~~~~~~~~~~^~~~~
/home/zhu/workspace/zephyrproject/zephyr/drivers/clock_control/nrf_power_clock.c:106:4: error: too many arguments to function 'nrf_clock_event_clear'
    nrf_clock_event_clear(NRF_CLOCK, config->started_evt);
    ^~~~~~~~~~~~~~~~~~~~~
In file included from ../include/drivers/clock_control/nrf_clock_control.h:11,
                 from /home/zhu/workspace/zephyrproject/zephyr/drivers/clock_control/nrf_power_clock.c:10:
/home/zhu/workspace/zephyrproject/modules/hal/nordic/nrfx/hal/nrf_clock.h:414:20: note: declared here
 __STATIC_INLINE void nrf_clock_event_clear(nrf_clock_event_t event)
                    ^~~~~~~~~~~~~~~~~~~~~
/home/zhu/workspace/zephyrproject/zephyr/drivers/clock_control/nrf_power_clock.c: In function 'clock_async_start':
/home/zhu/workspace/zephyrproject/zephyr/drivers/clock_control/nrf_power_clock.c:163:28: error: incompatible type for argument 1 of 'nrf_clock_task_trigger'
     nrf_clock_task_trigger(NRF_CLOCK,
                            ^~~~~~~~~~                      
In file included from ../include/drivers/clock_control/nrf_clock_control.h:11,
                 from /home/zhu/workspace/zephyrproject/zephyr/drivers/clock_control/nrf_power_clock.c:10:
/home/zhu/workspace/zephyrproject/modules/hal/nordic/nrfx/hal/nrf_clock.h:404:60: note: expected 'nrf_clock_task_t' {aka 'enum <anonymous>'} but argument is of type 'NRF_CLOCK_Type *' {aka 'struct <anonymous> *'}
 __STATIC_INLINE void nrf_clock_task_trigger(nrf_clock_task_t task)
                                           ~~~~~~~~~~~~~~~~~^~~~
/home/zhu/workspace/zephyrproject/zephyr/drivers/clock_control/nrf_power_clock.c:163:5: error: too many arguments to function 'nrf_clock_task_trigger'
     nrf_clock_task_trigger(NRF_CLOCK,
     ^~~~~~~~~~~~~~~~~~~~~~
In file included from ../include/drivers/clock_control/nrf_clock_control.h:11,
                 from /home/zhu/workspace/zephyrproject/zephyr/drivers/clock_control/nrf_power_clock.c:10:
/home/zhu/workspace/zephyrproject/modules/hal/nordic/nrfx/hal/nrf_clock.h:404:20: note: declared here
 __STATIC_INLINE void nrf_clock_task_trigger(nrf_clock_task_t task)
                    ^~~~~~~~~~~~~~~~~~~~~~
/home/zhu/workspace/zephyrproject/zephyr/drivers/clock_control/nrf_power_clock.c: In function 'hfclk_init':
/home/zhu/workspace/zephyrproject/zephyr/drivers/clock_control/nrf_power_clock.c:209:23: error: incompatible type for argument 1 of 'nrf_clock_lf_src_set'
  nrf_clock_lf_src_set(NRF_CLOCK, CLOCK_CONTROL_NRF_K32SRC);
                       ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from ../include/drivers/clock_control/nrf_clock_control.h:11,
                 from /home/zhu/workspace/zephyrproject/zephyr/drivers/clock_control/nrf_power_clock.c:10:
/home/zhu/workspace/zephyrproject/modules/hal/nordic/nrfx/hal/nrf_clock.h:428:59: note: expected 'nrf_clock_lfclk_t' {aka 'enum <anonymous>'} but argument is of type 'NRF_CLOCK_Type *' {aka 'struct <anonymous> *'}
 __STATIC_INLINE void nrf_clock_lf_src_set(nrf_clock_lfclk_t source)
                                         ~~~~~~~~~~~~~~~~~~^~~~~~
/home/zhu/workspace/zephyrproject/zephyr/drivers/clock_control/nrf_power_clock.c:209:2: error: too many arguments to function 'nrf_clock_lf_src_set'
  nrf_clock_lf_src_set(NRF_CLOCK, CLOCK_CONTROL_NRF_K32SRC);
  ^~~~~~~~~~~~~~~~~~~~
In file included from ../include/drivers/clock_control/nrf_clock_control.h:11,
                 from /home/zhu/workspace/zephyrproject/zephyr/drivers/clock_control/nrf_power_clock.c:10:
/home/zhu/workspace/zephyrproject/modules/hal/nordic/nrfx/hal/nrf_clock.h:428:20: note: declared here
 __STATIC_INLINE void nrf_clock_lf_src_set(nrf_clock_lfclk_t source)
                    ^~~~~~~~~~~~~~~~~~~~
/home/zhu/workspace/zephyrproject/zephyr/drivers/clock_control/nrf_power_clock.c:215:23: warning: passing argument 1 of 'nrf_clock_int_enable' makes integer from pointer without a cast [-Wint-conversion]
  nrf_clock_int_enable(NRF_CLOCK,
                       ^~~~~~~~~~                      
In file included from ../include/drivers/clock_control/nrf_clock_control.h:11,
                 from /home/zhu/workspace/zephyrproject/zephyr/drivers/clock_control/nrf_power_clock.c:10:
/home/zhu/workspace/zephyrproject/modules/hal/nordic/nrfx/hal/nrf_clock.h:384:50: note: expected 'uint32_t' {aka 'unsigned int'} but argument is of type 'NRF_CLOCK_Type *' {aka 'struct <anonymous> *'}
 __STATIC_INLINE void nrf_clock_int_enable(uint32_t int_mask)
                                         ~~~~~~~~~^~~~~~~~
/home/zhu/workspace/zephyrproject/zephyr/drivers/clock_control/nrf_power_clock.c:215:2: error: too many arguments to function 'nrf_clock_int_enable'
  nrf_clock_int_enable(NRF_CLOCK,
  ^~~~~~~~~~~~~~~~~~~~
In file included from ../include/drivers/clock_control/nrf_clock_control.h:11,
                 from /home/zhu/workspace/zephyrproject/zephyr/drivers/clock_control/nrf_power_clock.c:10:
/home/zhu/workspace/zephyrproject/modules/hal/nordic/nrfx/hal/nrf_clock.h:384:20: note: declared here
 __STATIC_INLINE void nrf_clock_int_enable(uint32_t int_mask)
                    ^~~~~~~~~~~~~~~~~~~~
[39/131] Building C object zephyr/CMak.../drivers/display/display_st7789v.c.obj
ninja: build stopped: subcommand failed.
`

I was using 2.0.99, which have no such issue, there must be a lot of changes after that...
vanwinkeljan commented 4 years ago

@zzzh you forgot to run west update, the NRF SDK was recently updated to a new version

zzzh commented 4 years ago

@vanwinkeljan Gotcha, will do that

zzzh commented 4 years ago

@vanwinkeljan It passed compile, but not working, don't understand why

zzzh commented 4 years ago

@vanwinkeljan Got it, some pins have to be changed.

jfischer-no commented 4 years ago

@zzzh ST7789V based LCD module ( a 1.54" which one is it? also take a look at my comment.

zzzh commented 4 years ago

@vanwinkeljan It's working now, but looks a little weird

IMAG0017

zzzh commented 4 years ago

@jfischer-phytec-iot It's called ZJY-1.54, look the picture. You made a 1.3" branch? cool.

jfischer-no commented 4 years ago

@jfischer-phytec-iot It's called ZJY-1.54, look the picture. You made a 1.3" branch? cool.

Yes. Yours looks like 1.54 one from Adafruit

vanwinkeljan commented 4 years ago

@zzzh Note there is a PR correcting an offset in the ST7789 driver (#20691)

zzzh commented 4 years ago

@jfischer-phytec-iot yeah, most LCD modules in same size looks similar

zzzh commented 4 years ago

@vanwinkeljan Yeah, the picture shows 3 differences: offset, screen size and orientation For the ZJY-1.54 module: offset: 0 screen size: 240x240 orientation: 12 o'clock in the picture

zzzh commented 4 years ago

@vanwinkeljan Just notice the conf and overlay file in st7789v_generic folder, 3 questions:

  1. both have screen size?
  2. there's no orientation config?
  3. many same configs in st7789v_generic.overlay and nrf52_pca10040.overlay?
vanwinkeljan commented 4 years ago

@zzzh

  1. both have screen size?

The one in the conf file are specific for the LVGL library. The resolution in the overlay is the one used by the driver.

  1. there's no orientation config?

Correct the driver does not support this for the moment.

  1. many same configs in st7789v_generic.overlay and nrf52_pca10040.overlay?

Bit confused here but there is no nrf52_pca10040.overlay

Btw this PR will not work correctly on the 1.54

zzzh commented 4 years ago

@vanwinkeljan

  1. both have screen size?

The one in the conf file are specific for the LVGL library. The resolution in the overlay is the one used by the driver.

I see

  1. many same configs in st7789v_generic.overlay and nrf52_pca10040.overlay?

Bit confused here but there is no nrf52_pca10040.overlay

Sorry, forgot it's me who added it..

Btw this PR will not work correctly on the 1.54

Yeah, as I tested

vanwinkeljan commented 4 years ago

reopened PR is still pending