Joel Bodenmann

Hello Thanos, Sadly we didn't find any time to create any board files for that board yet. However, somebody of the ChibiOS/RT community already contributed the LTDC HAL. Therefore it shouln't be too hard for you to wrap the HAL around the GDISP board file interface. If you created the board files, please share them to the community. We would LOVE to officially include the support for the STM32F429i-Discovery board into the repository. ~ Tectu

Nice to heard that you got your display working! We already had several times the issue with the initialization sequence of the ILI9320 driver. There were already plans to move the initialization to the board file, but as this only happened in a small amount of cases, it seemed to be like killing a fly with a bazooka. Please let me know if you need a different initialization code for the new display again. ~ Tectu

This may take some time... Please be patient. ~ Tectu

I'm seeing several things there that are not the way they are supposed to be (not in any order of importance): What is handle_lcd? Refering to your lcd_init(&handle_lcd); You never call the board_init(). This is the place where you are supposed to set up your pin configuration and other peripherals. You do not reset your display after you called your board_init() (which you currently don't). Even if your LCD does require a non-value based initialisation, it's supposed to be inside gdisp_lld_init(). If you need to set different pins like the enable one, just add those calls to the board file. The driver must be as generic as possible. The command byte to draw a line is supposed to be send through the write_cmd() call in your board file. Please refer to the SSD1306 driver to see how it's supposed to be done properly. In your write_data() routine, you unselect the SPI slave, write to it and then select it. It's supposed to be the other way around. Please refer to the ChibiOS/RT HAL documentation for further information. All of the points above are without looking at your actual algorithms or the datasheet. Please check those points first (most likely they won't solve your issue, but it's hard to debug your code in this "messy" state). I suggest you to take a close look the the existing SSD1306 driver as that one is VERY similar to yours. You shouldn't have to change a lot from there. ~ Tectu

Okay, I put it on my ToDo list, but I cannot tell you when I get to it as I am currently in heavy exams trouble. I assume just disable the scroll macro should work out for you in the meantime. ~ Tectu

Did you have any luck to read out the LCD controllers version number so far? ~ Tectu

Hello Smd, It will take some time until I can take care of this. Could you please leave some more information in the meantime: Which µGFX version/git master are you using? What is your hardware setup? (board/MCU, display controller) What compiler are you using? (inc. version) ~ Tectu

There are currently no board files for the STM32373C-EVAL board. You have to create them yourself. If the drivers for your screen already exist, it's simply a matter of linking the stuff in the board makefile and create the appropriate board files. Please take a look at one of the many pre-made ones you can find in /boards/base. Otherwise you first have to create your display driver. At least the initialisation routine can be taken from the STM demo code. Feel free to ask when you face any problems. Most people get their drivers work in one or two days. However, proper C skills are required, of course. But as you are dealing with that kind of board, that shouldn't be any problem. ~ Tectu

Note that you can also change the GDISP worker thread priority in your gfxconf.h. ~ Tectu

Hello madokapeng and welcome to the µGFX community! What you want is the 2.0 release of µGFX (ugfx-release-20.zip). ChibiOS/GFX was the previous name of the project and hence the 1.7 release was before the current 2.0. However, it's recommended to use the git repository master, as there are lots of bug fixes happening after each new release. The 2.0 is a bit unstable as every .0 release is (classing software designer issue). If you take a look at the git history, you can clearly see that there are a lot of bug fixes since the release. ~ Tectu

NEVER put debugging data on an LCD. As soon as you remove it again (once your systems appears to do what you want it to), you change the entire behaviour of the system. Debug data is supposed to be retrieved through your controller debugging port or through any other suited interface. Only put stuff on your LCD that you eventually want on it once you finished your project. ~ Tectu

According to this picture there is an A and a B version of this board where the A only works with the parallen interface and B only with SPI. Are you 100% sure that you have the SPI version? Two things to do: First, check out their example code and replace the initialisation routine of the µGFX driver by theirs (just the register values). Probably the initialisation code for the SPI mode is different. If that does still not work, you might want to try to use the parallel interface by connecting it to the FSMC peripheral of the STM32F4. There's a guide on the µGFX site that tells you what to do. Do you have a scope accessible so you can check for proper SPI signals? ~ Tectu

I cannot see anything obvious there as you are using the same board file. I PM'ed uweng14 so let's hope he looks by soon. Probably he has a newer version of those files. What exactly do you see on your screen? Do you see random data (like colored snow?). That would mean that the controller has been initialised properly so far. P.S.: Try to call a gdispClear(Black); right after the gfxInit();. ~ Tectu

Hello erwinkendo and welcome to the community! What problems are you facing? Could you give some more information about your setup i.e. if you're using the STM32F407-Discovery board too and what interface you're using? The ILI9320 driver itself seems to work properly (just tried myself). ~ Tectu

Nice to hear that you did some progress! Feel free to ask whenever a question rises. What's exactly the issue that you cannot send PMs? ~ Tectu

Thanks for fixing, inmarket. @rabryan: Could you share any videos or pictures of your work? It would be nice to fill up our demos section a bit. ~ Tectu

Hello rabryan, We have indeed changed the algorithm of gdispDrawArc(). I'll forward this to inmarket as he was the one who "invented" the new algorithm. You can copy the gdispDrawArc() routine of the old state which still worked for you and replace it with the new one - that should fix it for now. ~ Tectu

Thank you very much for your support. From my own experience (mainly as a user), I agree that x.0 releases are always a bit tricky as there are some major restructurings happening It would be nice if you could contribute a boards/base directory for the Open407V-D to the community. ~ Tectu

Fixed. Thank you very much, we appreciate these bug reports a lot. One of our major problems is that we can't test every possible case with the settings in the gfxconf.h as they are just too nested. ~ Tectu

I don't see any problem there. The provided Makefiles within the example directories are of course supposed to include the board files for the board they are written for. You are of course not supposed to include the board files of a board you do not own in your project directory, hence the # your board comment. The guide states this: If you're using some well known dev board, it's very likely that there are already board files for this board. Inside the /boards/base/ directory, you can find the supported boards. Simply include the board.mk for the appropriate board in your Makefile. I will try to rewrite the "Get µGFX" guide within the following week - there was just too little time. Long story short: Don't include board files of a board you do not want to use. ~ Tectu

I have fixed the wrong /boards/base/xxx/chibios_board/board.mk files. What was the small modification you had to make? ~ Tectu

You are right - there's a problem. I'll fix that as soon as I get time (won't be before wednesday, I'm afraid). Thank you very much for finding and reporting. If you have any other issues by compiling µGFX 2.0, please open a new thread. ~ Tectu

Can you please give some more information about bad paths etc? We built every single /boards/base/ before the release and it seemed to work fine. Please open a new thread with an appropriate thread name in the development & feedback section. ~ Tectu

Hello steved and welcome to the community. The major performance "issue" you will face is the actual interface speed between you and your display controller. 800x480 are quite a lot of pixels that need to be handled. Within our algorithms, we try to just modify the area which needs to be (no complete screen redrawings). However, if you build some GUI inteface like where you clear the complete screen often, you will still observe quit a long build-up time if you use a slow interface. The display controller used in the video is an SSD1963 as well, but in 8-bit mode. Using the 16-bit mode instead would lead to a very big performance gain.Long story short: Choose a microcontroller which provides a fast parallel interface to talk to your SSD1963. Every STM32F1xx and STM32F4xx MCU does provide a 16-bit FSMC interface. Make sure you get a package with enough pins for all your stuff as the FSMC will eat up 20 pins (watch out for pin collisions!) If you can afford it (no mass production etc), go for some STM32F407 instead of an STM32F1xx as that one runs on a frequency twice as high. Also, more RAM and FLASH is never a bad option anyway. You might just need the basic elements like buttons and check boxes, but the GUI will look A LOT nicer if you blit some custom bitmaps (images) over them. With 1MB of flash, you can store a lot of bitmaps I hope that answers your question a bit - feel free to ask any further. ~ Tectu

That sounds about right. However, you'll have to create a file called board_KS108 instead of the gdisp_lld_board.h when you're using the new GDISP structure - which I highly recommend (you'll see that by looking at the SSD1306 from the GDISPStreaming branch as well). When you don't use that branch, your driver won't work with anything after µGFX v1.9. The project you linked seems about right to get some information about how to talk to the display. However, make sure you're not violating any licenses. ~ Tectu