STM32f429 disco1 LCD driver (mbed os 6)

Custom and community boards
1

Hi !

I am lost.
Can anybody helps me how can I use LCD display on STM32f429 disco1 board with mbed os 6 ?

Thank you !

2

Hello,

Did you check examples from board’s page ? It contain examples like - DISCO-F429ZI_LCDTS_demo and more. These examples are obsolete but appear to be still compilable with the online compiler.

Replace the old Mbed lib with the new Mbed OS. Then is also necessary to replace some old functions in the main.cpp and also in the whole library.

  • old wait(1) to new thread_sleep_for(1000) or HAL function HAL_DELAY(1000)
  • old wait_ms(1) to new thread_sleep_for(1) or HAL function HAL_DELAY(1)

It is only a theory I can not test it (I do not have the hardware), so I do not say that will working but it is good point where you can start.

Typ: I had a problem with usage of the thread_sleep_for() between BPS functions and the program was not working correctly. It was solved with implementation of HAL_DELAY() function.

I hope that will help you to start.

BR, Jan

3

Can you give us a little more detailed here? I think I’m running into the same issue. How did you solve this?

4

Hello @ladislas,

I discovered this problem while trying to help with this topic Blank display if S1820 probe enabled and how I wrote in my last post, I hoped about someone more clever/experienced, will able to explain it. I not tried to debug it.

I know only how to reproduce it and how to work around it.

LCD demo for F746 in original state (Mbed 2) is working and also when you replace the HAL_DELAY() to old wait(). With the MbedOS 6.2.1 it is also working with HAL_DELAY(); but how you change it to ThisThread::sleep_for() or thread_sleep_for() the display do nothing (it doesn’t matter if it’s RTOS or baremetal).

During my testing I found you can not have Mbed’s delay functions in the loop where you run the BSP functions.
So I solved it so that display handling runs in one thread and the rest of the program in another.

BR, Jan

5

Hi,

Thank you for your answer. After all, I finished working with Mbed studio. Online Mbed works well and it seems everything is flawless (so far)

Laci

6

We had the same issues! Thanks for the feedback.

Do you know if HAL_DELAY() is blocking? or can it be used just like sleep_for?

7

To answer my own question, yes HAL_DELAY seems to be a busy wait thus blocking. But it’s defined as __weak so it could be overridden.

Has you tried providing your own HAL_DELAY with ThisThread::sleep_for?

@jeromecoutant - Do you have any recommandation to handle this kind of use case? :slight_smile: Your help would be greatly appreciated!

8

Nope, I not tried my own implementation.

9

Hi
To be honest I never tried as well…
BSP code from ST Drivers are not really tested on top of mbed.

Maybe before overriding HAL_Delay in mbed code, you could replace some specific lines in BSP code ?
Or override HAL_Delay with something like:
if delay > 500 (??), use sleep_for,
else, keep busy wait implementation
?

Jerome

1 Like
10

I like this approach. I’ve used it when porting other libraries from AVR to ARM.

@jeromecoutant follow up question: will mbed adjust when using HAL_Delay or will it cause synchronisation and timing issues and shift all “events” in time?