STM32F429 Disc

[MobileWill]

Hi,

I am trying to get uGFX to work with the STM32F429 discovery board. My first issue which I think is a ChiBiOS issue is support for SPI5. But it seems everyone else is able to get it working so not sure what is up. I have ChibiOS 16. It looks like SPI5 is not setup for this board.

As for uGFX I am bit confused on the difference between boards base which has a set of drivers for this board and the gdisp drivers which I noticed in the latest version has just the generic LTDC driver.

Which files should I be including? I haven't been able to find clear directions on which files are what and what to include between the too folders.

I have everything working for the STM32F411 so I know how a working setup is.

On a side note of temporaly disable SPI5 and enable SPI1 I can get past that error but I get FMC_bank undefined errors and other LTDC errors.

Also I would like to ask if uGFX is capable of the windowing graphics as seen on the STemWin demo that comes on the discovery board? It looks like Win95ish type UI.

Thanks for the help. I have starting a big project that I am leaning torwards the 429 and uGFX.

[king2]

As I in same situation as you (writing project based on uGFX on STM32F429), let me try to answer some of your questions.

SPI is a not part uGFX responsible for in your case, so this is question about ChibiOS HAL.

To make LTDC working, I was copied board_STM32LTDC_template.h into $PROJ_DIR$/board_STM32LTDC.h, and added some defines into it:

#define SDRAM_DEVICE_ADDR 0xd0000000
#define STM32F4 TRUE

I have changed driverCfg in this file, because I'm using 800x480 display.

Also, I included gdisp_lld_STM32LTDC.c into my project.

I have not used file from demos, and in my case everything works fine with generic driver.

What about win95-like interface, uFGX have widgets that looking better than Win95's (in my opinion), so I used them as is.

You can use Studio as visual designer and get some files to start with.

Note that Studio can be used not just as example generator, but as designer in full life cycle of application, so you can add or change something in your app, generate code and just recompile your application.

Tectu told that 0.13 version of Studio (will be available ~15th of Feb) will allow to use custom fonts, this also will help (now you can use in Studio only fonts embedded into uGFX).

So, you need:

- uGFX gfx_mk.c file, to compile entire lib in your firmware

- LTDC display driver as was mentioned above

- gui.c, gui.h gfxconf.h and other files that will make Studio for you

I'm not developer of uGFX, just a user, so everything above is just my opinion.

[MobileWill]

Thank you, maybe at least I can get something going on the 429. I was just going with the demo files since I thought it would be complete. So your setup works with the SDRAM? I have included _sdram with the _fmc drivers.

I take it you are not using ChibiOS?

Do you know which displays work with the hardware acceleration?

[Joel Bodenmann]

Hello MobileWill and welcome to the community!

king2 has already answered most of your questions so I'm just being a bit more specific here:

1. The /boards directory doesn't contain any drivers. It only contains what we call board files. The board files contain functions which uGFX uses to communicate with your hardware. For example, there can be a function to write a byte, another to read a byte and another function to change the intensity of the backlight. These are things that we can't do for you because it heavily depends on the user hardware. The board files are a very flexible way of providing the user with the possibility to run the same software on any platform.

So in you case, if you have a look at /boards/base/STM32F429i-Discovery you will see that it doesn't contain a single line of actual uGFX code. The code in there is mostly 3rd party code to work with the RAM and so on. The board.mk Makefile includes the actual drivers which are located in /drivers.

2. The last time we checked the examples for ChibiOS/RT 2.6 and ChibiOS/RT 3.x that are located in the board directory of the STM32F429i-Discovery board worked out of the box. ChibiOS 16 just seems to be a new way to give the entire bundle (HAL, OS, ...) a version number so you are still using ChibiOS/RT 3.x and therefore the examples should work. Sadly we can't test that right now.

3. Regarding your question about the window stuff: uGFX comes with a full window manager. We also provide widgets to create dialog boxes and so on. Furthermore, it's possible to completely modify how a widget looks from the actual user space application code. This means that you can change the default look of our slider widget without modifying the actual uGFX library code. Most widgets also come with a built-in rendering function that can handle images in case of you have some more advanced needs. It is also possible (and comparably quite easy) to write your own widgets. You can read more about this stuff in the following locations:

• http://wiki.ugfx.org/index.php/GWIN
  
• http://wiki.ugfx.org/index.php/Widgets
  
• http://wiki.ugfx.org/index.php/Creating ... ng_routine

You might also want to talk to king2 about that as he recently worked a lot with modifying how widgets look

4. Any display panel will work with the hardware acceleration provided by the STM32F429 microcontroller as long as you can hook it up to the LTDC interface. This means that in general any panel with an RGB interface will work.

I hope that helps a bit. Please do not hesitate to ask any further questions.

And let us know when you had any issues getting the examples for ChibiOS that are located in the board directory for the STM32F429i-Discovery working.

~ Tectu

[MobileWill]

I think the first issue I need to overcome is the SPI5 missing. It looks like it is setup in ChibiOS but it still doesn't know where to fine SPI5 when it sets it up.

It seems like the board_STM32LTDC_template needs more than the defines. The board_STM32LTDC from the base folder has more code and that is the ome that has includes for _fmc and _sdram and setups up SPI5.

If I use the tamplate do I not need to add the rest of the functions or can it talk to the display without doing SPI first?

Thanks.

Edited February 2, 2016 by Guest

[king2]

Sorry, I have no 429 discovery, so I can only guess.

I'm working with WaveShare Open429-I kit with 7-inch capacitive display, that works by LTDC only, without any needs to setup it via SPI.

Yes, i using 8M SDRAM embedded into main CPU module of Open429, so I cannot use full power of STEmWin's double layers (STM32F429 cannot use double layers on 800x480 with SDRAM due to bus bandwidth limitation). I have tried STemWin, and it works, but as I tried to ask questions in their forum and got no answer, and I see that developers of uGFX really wants to make uGFX better, so I decided to switch to uGFX (except this, I can see uGFX sources ).

About hardware acceleration.. I simply do not know. STM32F429 have DMA2D accelerator, and my display (and LTDC itself) cannot be used without videobuffer, so all acceleration can work with memory (video) buffer only. uGFX's LTDC driver uses DMA2D to fill areas.

[Joel Bodenmann]

If I use the tamplate do I not need to add the rest of the functions or can it talk to the display without doing SPI first?

This is a bit a problem with the STM32F429i-Discovery board: The people who designed this board decided to use a display that has an internal controller (ILI9341). The entire purpose of having the LTDC (and DMA2D) peripherals is that you can directly hook up the bare display panel without any dedicated controller in between. The ILI9341 can do this but it needs to be put into this mode first. This is a configuration step that happens through the SPI interface. So when uGFX is initializing the driver, it will first tell the ILI9341 display driver via SPI that it should stop bothering and just directly route the RGB interface through.

This is why the board file of the STM32F429i-Discovery is so cluttered and full of stuff. You can compare it to other board files. Usually its just a matter of a couple of lines of code.

I have no idea what the issue with SPI5 would be. Maybe ChibiOS/HAL changed something. As mentioned I currently can't give it a try as I am on the road and most likely I won't find time for this before next week. All I can tell you is that the Makefile based example projects that can be found in the STM32F429i-Discovery board directory were known to work very well.

Yes, i using 8M SDRAM embedded into main CPU module of Open429, so I cannot use full power of STEmWin's double layers (STM32F429 cannot use double layers on 800x480 with SDRAM due to bus bandwidth limitation). I have tried STemWin, and it works, but as I tried to ask questions in their forum and got no answer, and I see that developers of uGFX really wants to make uGFX better, so I decided to switch to uGFX (except this, I can see uGFX sources ).

Very happy to hear that We are indeed very keen to make uGFX become the best embedded GUI library available while keeping the sources open and maintaining an active community. Actually those where some of the main reasons why I started uGFX.

About hardware acceleration.. I simply do not know. STM32F429 have DMA2D accelerator, and my display (and LTDC itself) cannot be used without videobuffer, so all acceleration can work with memory (video) buffer only. uGFX's LTDC driver uses DMA2D to fill areas.

DMA2D is supported by uGFX. If you have a look at the STM32LTDC driver you can see that the driver config has a corresponding define for that to enable or disable DMA2D. The performance gains are HUGE!

As of now you can't use the second LTDC layer, that is correct, but the DMA2D hardware acceleration works on one layer.

Adding support for the second layer is fairly easy and it's on our ToDo list, just currently not that high important. What basically needs to be done is initializing the second layer. Then, use a gdispControl() command to return a GDisplay* pointer of the second layer and you're done. Now you have two separate displays you can talk to. Once can then proceed by adding more API to switch the currently active layer and so on.

~ Tectu

[king2]

Adding support for the second layer is fairly easy

Not in case of my config. STM32F429 while working with LTDC and SDRAM at one time simply cannot display both layers right way.

I think that bus bandwidth is limited more than this is mentioned in documentation, so LTDC cannot access to new pixels to be displayed at same time when it wants to read them from both layer's SDRAM addresses.

As result I have sync problems, snow on screen or something like this (each next line was shifted to right by few pixels), depending on third thing who want to access to SDRAM - my application writing to display layers

[Joel Bodenmann]

Very interesting. I guess we have some reading ahead of us I guess that this will depend a lot on the used memory (speed) and the used resolution.

Anyway, my statement "Adding su pport for the second layer is fairly easy" was from the actual implementation point of view. uGFX already implements everything required to handle a second layer. The required changes only have to happen in the STM32LTDC driver.

But let's not get too off-topic in MobileWill's thread. We can always open a new discussion thread in the Development section

~ Tectu

[inmarket]

Let me reiterate what Tectu said earlier - the best place to start is with the example project in /boards/base/stm32f429-discovery/example_chibios3 directory.

It should work out of the box with your board.

If you are having trouble with SPI5 under chibios have a look in the halconf.h or mcuconf.h and similiar chibios configuration files.

[MobileWill]

I think I figured it out. I started a fresh project on my laptop on a fresh VM with Embitz. But I just so happen to noticed the community folder in ChiBiOS. So it turns out there are additional drivers for the 429 which looks to support all the SPI and FMC. So it looks to have complied. I will have to do further testing when I get home.

For future reference, it is the hal_community.h/c and mcuconf_community but they also some other drivers for crc,nand,onewire,eicu but they are all included. Just copy them over or include them in your project.

Hmm I just noticed while writing this up there are some additional files in community/os/hal/ports/stm32/lld. Wonder if I need them.

I will post pack if it all works.

Is there anything in gfxconf.h I need to enable to make sure I am using 2D acceleration?

[Joel Bodenmann]

Once again: The demo that comes with the uGFX library is supposed to run with the plain, standard ChibiOS/RT that you can download. No special versions, no community stuff, just the plain ChibiOS/RT.

I just took the time to verify whether everything still works and indeed the supplied demo worked out of the box without any problems. I uploaded a ZIP to the uGFX homepage that you can download. The demo contains everything you need (including uGFX and ChibiOS). Just download, unzip and execute 'make' and everything should work out of the box.

Note that ChibiOS 16 is just a bundle that contains ChibiOS/RT, ChibiOS/NIL and ChibiOS/HAL. Therefore, you should be able to run the exact same demo without any modifications by just swapping the ChibiOS directory (and modifying the path in the Makefile if the directory hierarchy changed).

Please give the project that you can download here a try and let us know if it worked.

~ Tectu

[Joel Bodenmann]

Is there anything in gfxconf.h I need to enable to make sure I am using 2D acceleration?

Nope, the hardware acceleration is part of the driver and therfore controlled in the drivers configuration file (/drivers/gdisp/STM32LTDC/gdisp_lld_config.h in your case). You can see that DMA2D is already enabled by default.

The gfxconf.h configuration file only controls application stuff.

~ Tectu

[MobileWill]

Thanks. I will try that as soon as I get home. EmBitz sort of works with make but its external so in my test I lost some of the features and it seemed to break debugging since the paths of the elf doesn't line up. Should this demo work with file inclusion?

[Joel Bodenmann]

The demo uses the Makefile build system. Therefore, it doesn't use the single-file inclusion system. I'd recommend you to try building and running that demo outside of EmBitz first. Then you will have a base project that will help you to understand which files you need. You can then work on creating an EmBitz project from that.

~ Tectu

[MobileWill]

Finally got make working. Just a few warnings but it compiled. Now to try Embitz...

[MobileWill]

I got it all working in Embitz with but still had to use the community drivers to get SPI5 working and such. ChibiOs said there are defines missing so maybe when that is added it will work. Maybe is an issue 3.0.4 vs the demo you sent with 3.0.1. Its just a guess. I search all over to try and find what is different and couldn't find anything. Oh well.

Here is a link to the working project if anyone needs it

https://www.dropbox.com/s/j8k3qsi69nc8a ... X.zip?dl=0

The problem now is the debugger won't connect to the board. It works fine on the Nucleo STm32F411RE but not the STM32F429I-Disc1 which has drag n drop support. It has St-link/v2-1B.

Anyone know if to use the hardware LCD stuff you have to have SDRAM? Trying to keep my design simple. But I can stay this setup is way faster then the F411RE. Its pretty nice. Can't wait to focus on code instead of setup.

Thanks.

Edit: Project attached to this forum post. Please do not upload resources using external services! This helps to keep the information together for the future where the resources might no longer be available through the other hosting platform.

Edited February 3, 2016 by Guest

[Joel Bodenmann]

The problem now is the debugger won't connect to the board. It works fine on the Nucleo STm32F411RE but not the STM32F429I-Disc1 which has drag n drop support. It has St-link/v2-1B.

I'm afraid we can't really help with that. Try the EmBitz forum

Anyone know if to use the hardware LCD stuff you have to have SDRAM? Trying to keep my design simple.

Technically you don't. However, the LTDC needs sufficient memory to put the framebuffer somewhere. For small displays the internal SRAM might be enough, but you won't have much RAM left. But for anything bigger than 320x240 this will most likely not work out. That is the reason why all LTDC designs use external SDRAM: It's a cheap way of adding a lot memory to your design.

So technically no, you don't need external memory but practically you are forced to because you don't have enough internal one.

But I can stay this setup is way faster then the F411RE. Its pretty nice. Can't wait to focus on code instead of setup.

Yeah, LTDC and DMA2D give a huge performance boost!

~ Tectu

[nquantum]

As of question relate to LTDC driver of STM32, i would like to ask.

How about QSPI? Since LTDC call for BSD file that point to hardware-signal in ST board LCD and SDRAM also in my board STM32F469 they also include QSPI too. But it apear that they include only no where to use incode.

Do it use QSPI IN WORKING WITH LCD? Or just only SDRAM for working with LTDC. 

Meaning it I want to use CubeMX from scratch I need setup for LTDC and SDRAM right? Do i need to include QSPI , also DMA2D also?

Basicly i do not QSPI do in this LCD thing.

Edited January 8, 2017 by nquantum

[Joel Bodenmann]

I'm really not sure what your actual question is. Can you try to be more specific and/or to rephrase your actual question?