How to integrate TouchGFX in a custom board (The long way round) 

thank you for those kind words!

Thanks man :) Some interesting things are coming to the tGFX system - stay tuned!

Thanks! But be aware that the documentation for the SPI driven displays can be a bit hard to work with

Sure, I'd love to :) is there anything in particular you would like to see?

@@banjohat currently I am trying to get into custom boards and touchGFX gui design. I thought it would be smart to get a dedicated display running on a disco board as a first step after just using the disco itself. Before I have already fiddled with a basic touch gui and afterwards with a menu like gui controlled by physical buttons. In that process I found that the STM tutorials are kinda weird structure wise because they copy code into the project ignoring the correct programming order, at least I felt that way. So for now I am just sucking up any good information on that topic until I get it up running myself. I may update this in the next few days hopefully. 🙂

@@banjohat Update: Alright, so I have run into my first problem. My cheap 2,4" display with it's ST7789Vi controller only supports 8080-I/II parallel interface. My old STM32F429I-DISCO I had lying around and STM32s in general support this type of interface by configuring the FMC in LCD interface mode. But I did not figure out all the details yet. The ST forum has a solution dating back about 3 years but the current version of CubeMX is even featuring a ST7789V FMC driver, though I am not sure what to do with this. If you have experience with this, a tip about what to do would be highly appreciated. However I'll fiddle around with this anyways.

@@MarcoCargnelutti-h6x i think it is the best way to give the user free control over how they want to allocate resources for the tGFX. But it was not straight forward the first time I did it 😅

yeah, one do get the impression sometimes that cubeMX is a wide mix of different wants and wishes. It does a good job for most of the generations but does lack some particularities..

thank you very much! Well, the long way gives you a bit more flexibility I think. but the templates can get you started faster

Ouch, sounds like a real pain! The right datasheet will definitely help ;)

you will be happy to know that I made a video about that as well ;) ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-majcfxr3u2E.html

No files available, this is for information only. You should be able to create your own setup using the instructions provided

That's an interesting thought - I have considered it a number of times but didn't go into much detail on constructing the Application template needed. For my particular application the hardware haven't really changed in the 4 iterations that I have run so I haven't had the need for the AT. Also I do most of the work in CubeIDE since the designer is just for the GUI stuff (obviously). It's done so quickly that it doesn't make sense yet. However, I have thought of making a board for props that require displays to sell. If I do that an AT will make so much sense beacuse then the end-users can do almost all of the GUI design in the designer only and don't care about the underlying hardware... uuh.. another project :D The Amp Hour - Sounds really cool! Didn't know about that, would be amazing to talk about this :)

Thank you for the kind words! I'm happy that you found it useful :) Well, you're right - CubeMX does set up RTOS and the other things BUT! a lot of people had the idea that by using CubeMX everything would be done. Like the timing and config of SDRAM. It does not. Likewise the timing configuration of QSPI memory is also up to the user. This have historically resulted in a lot of frowning and confused forum posts :)

to answer your first question - there are 4 types of memory all mapped into the same space, hence the different starting addresses. There really isn't more to say about that - but if you place your framebuffer in 0x20000000 then you are using internal RAM - which you don't have much of. depending on your bit depth and resolution you might not have enough to run a double buffered setup which you need in order to do animations (sometimes even triple buffers) For the polarity - the hint is to try out different settings here. a key tip is that even at a breakpoint you can tweak the polarity settings and see the difference live.

sorry, this video is for educational purposes - the design is not available for free. however, the design is closely based on the STM32F746-Disco board so you have a pretty nice starting point there. The display is parallel RGB so no chip on it

I'm using the same touch driver as the evaluation board but you have to i clause it manually. It should be in the video how to add the appropriate files for the touch support

Sorry I was mistaken. It's in the next video: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-ELMK35I86QE.html

I have a few parallel RGB displays that are 7" and 10" - they are completely the same, connectionwise. I have bought my displays from buydisplay.com

I have been happy with buydisplay.com - They sell in single pieces and you can get a price up front.

You're right, the discovery board have the st-link built in. When you're designing your own board, just break out the swdio and swclk pins along with power. Those can be connected to an external st-link. Just not the one on the 746-disc0 board. All the nucleo boards should work

I am using the winbond W9864G6KH-6 it can be hand-soldered and is 16-bits :)

I'm glad it helped you! Remember that the Cube code only initialize hardware. Of your system requires some register setup you still need to do that yourself - that's what the code does. Think of it like this: the cube gives you the keys to a car - you still need to turn it on to drive

@@banjohat Thank you sir, another unrelated question if you don't mind please. do you have any idea of the correct way to interact with SDMMC within FreeRTOS?, something is wrong with my program, and I still can't figure it out.

@@mehdisehlouli4645 sorry, i haven't worked with RAM more than just setting it up for tGFX

You will have to implement a SPI driver that can push the framebuffer to the display. tGFX does not care about which display you're using it just maintains the framebuffer. What you do with it and how you do it is entirely up to you. With that said pushing a specific area of memory to your display should be relatively straight forward :)

Oh that was a tough one! I haven't had any problem the even remotely resemble that situation. You will be better off asking in the tGFX forum - the dev team have people there so you should get some insightful answers (hopefully)

yes it is. If you try to compile the code without the linker script modified so it supports external RAM you'll get an error. you can reduce the bit depth and the number of framebuffers to fit into the internal RAM but you will use most of it and loose some animation features

unfortunately. I would like to try it out but I haven't had the courage yet :)

sounds more like a power supply issue. you're losing connection to the debugger so the whole system is resetting.

It's Happening only when Iám using the Backlight driver MIC2287. If I don't turn HIGH the Backlight GPIO for MIC2287, the MCU is working fine. I checked by simply toggling a GPIO and its works fine without loosing connection to the debugger. The issue starts when I change the status of backlight GPIO to HIGH . Is it something with the Schottky Diode thing?? Iam using SS14 Schotky diode with a 10uH Inductor on my PCB as I Could get the STPSL140M Diode that is used in the Disco Board.. Is there any particular Diode to be used

@@sumitmourya6528 I think the best way forward is to check with the datasheet and have the backlight running before you attempt running it combined with the STM32. you should be able to see the backlight and determine if it works :)

@@banjohat Yes, I figured out the problem. The output of my Schottky Diode is unstable. I need a more faster switching diode(faster than my current diode) . Not all Schottky Diodes would work here. I tried using SS14,SS16, but They are not capable of fast switching. I tried IN4007, though it is a general Schottky diode but at least it keeps the supply stable, The TFT works fine with IN4007 but with a very low brightness , Maybe because the IN4007 diode has a large voltage drop. Can You tell me Which Diode you used? I mean the diode number. Would just save me some time.

@@sumitmourya6528 I have been using the ROHM RB501VM-40TE-17 I just now see that it has been discontinued :(

Sorry, I'm Using STM32H7A3VI! 2Mb Flash, 1.4mb of RAM , but 1.1Mb of SRAM at the end, if you any suggestion, please let me know

Just skip the init on those parts

I'm pretty sure the F429i board is using a resistive touch interface - but with an extra touch controller chip IIRC. At least that's a good starting point :)

@@banjohat thanks for your interest. I ll examine it.

yellow only implies a partial error. it might not affect your situation or configuration

@@banjohat thank you 🌹🌹🌹🌹🌹🌹

If you have altium, yes :) i opted to go with KiCAD since a friend of mine started the layout. The problem with the application templates is that they are specific for the dev-kits. So as soon as you make custom firmware you are likely to change a lot of parameters anyway. I have not made a custom board using the designer as a starting point because my own HW differs too much.

I have tried both ways (for the dev kit). When using ready made hardware you can get up and running REALLY fast using the AT. But I think you are supposed to make it from scratch when developing real stuff

@@banjohat I had a thread/discussion on the forum about this last year. "You are supposed to" build from scratch seems wrong. If I use the DISCO kit, build up test circuits on Arduino type hardware, get it 95%+ to my target config, at what point to I throw away my project and start it from scratch, (and then port my own work back in). Seems like most users will do as much development on the dev kits as possible to reduce iterations of final hardware. The tools should embrace that process.

@@TurboBobBailey You're right - but in fact I think they do a fair job. think about this: the people working on GUI and graphical stuff can use the AT's to get started and going real easy using the designer approach. the HW guys will have to do a lot of wiggling anyway and the custom method allows for a fairly quick integration of peripherals. tGFX is XML/JSON based (or something very similar) so it's quick to change the files. Of course it would be nice to be able to have support for different chips along with FW init but I don't think that is a feasible way to do it for ST.

@@banjohat I think they do a fair job also. I just think they are missing the one step. Most likely they are all Graphical/GUI guys on the tGFX team, and thus have not had to make that transition (from AT to custom) themselves. The subject of your last 2 videos, perhaps 3 hours or so video length, probably a day or 2 real time, should have been a couple clicks, automatic, to convert the AT project to a 'custom' project. After all, you had to refer to the AT (or perhaps a previously/painfully converted project). The info/data is there, its just organized strangely due to the new AT organization (sources outside the CubeIDE project). As far as migrating a project to a better chip. I want to be able to do that, as I am developing on F746-DISCO,and want to move to H735. My Freescale stuff can do that in a couple clicks. Currently I am trying to keep all my code out of main.c, and in its own directory, so I can migrate out easily. But I will start with the AT for the 735 disco board, and have the same fight on my hands converting the project (or building from scratch and copying over all the disco code). Of course its always easier the second time thru.

bende aynı sıkıntıyı yaşıyorum (suzan mı susan mı bdckjsdnlkjcş)

Check your clock polarity and consider looking into your framebuffer to see if you are getting content. If that works you need to try and generate some static image. I have a video for that. I suspect that your problem is hardware related

@@banjohat thanks for responding 🤞. I'll try

Hi Marco, unfortunately I don't have much time these days for helping out. I would suggest that you look through some of my other videos to debug each module needed separately

Sure - this one: www.buydisplay.com/low-cost-4-3-inch-480x272-tft-lcd-display-w-optl-capacitive-touch-screen

@@banjohat thank you

Do you have the datasheet of the ST LCD 480X727 which comes along with the evaluvation board . MB1315A

@@sijojohnson No, I haven't got any information on that. It's probably obsolete already ;)

@@banjohat Sorry it's 480x272.

No, sorry. This is one of the many parts you will need to do on your own

buydisplay.com :)

@@banjohat Thanks, was about to ask the same. But then I thought "Read all his answers before you ask, someone might already have asked" And here it is.

Yeah, you should - However performance is limited since you don't have SDRAM or QSPI memory - but that can be added :)

Sorry, I'm not sure what you mean :) (can't remember what I said in the video) I have only worked with the double buffer strategy since I want to do smoothe transitions (should turn on the third buffer as well - I have the space for it). I suspect the single buffer will work just fine, but all changes will be instantaneous. This is actually a nice topic for a video :)

@@banjohat you added the footprint for the RAM as "optional", it sounded like you were planning to use only a single frame buffer. I switched my disco board to single frame buffer and it got very 'flickery' when using the swipe container. I was curious if you had workarounds. Sounds like double/triple buffering is going to be required for my project. You also switched from 144pin to 176 due to pin assignments, I need to re-watch to see what exactly the issue was, since I am at that point and am concerned about availability. I was going to switch to an H7 part for speed, but availability is not as good as the F746

@@TurboBobBailey Ah, yes, well, the external memory IS optional - but you will get the issues you have noticed. if you can fit a double buffer in the internal RAM you could most likely get away with some of it, at least I don't see the tGFX tutorials utilize the 3rd buffer at all. So from a cost perspective it would be interesting to omit the SDRAM but from a performance - not so much. I think my mention was something along the lines of 'Well, the footprint is free, so I just add it and figure out the cost later'. It would definitely be very interesting to test out the visual performance of all solutions!

@@banjohat in my "custom project", similar to yours but I started with the disco application template project's IOC file and copied main.c over completely. My build analyzer is not working (want to watch memory space to see if the 512K parts could be used, thus 1M parts serve as a backup in case of availability issues).

That's actually a very good question! I haven't got the faintest idea.. But my current application does not require the SDRAM at all to work so I might be able to get back to you (at some point) and answer the question with some measurements..

@@banjohat Thanks, I am quite new to SDRAM and how it works. I have a project where I might use SDRAM but I fear that this uses to much current for my battery powered application. I saw numbers of about 180mA while write/read operation but I want to know how much it draws without r/w operation, just to retain data. All those numbers are still too confusing for me :D

Oh yeah. Had to crank mine up to max as well. But then it is just loud enough. Surely it meets the french "ear damage max volume" laws :)