Joel Bodenmann

Hello Dmytro, Beside the leading dashes in line 26 and 27 I cannot find any issue in your Makefile so far. I just synced the FreeRTOS to the current master branch and then tried to rebuild my SSD1289 project and everything works just fine. As you might be on the old FreeRTOS branch, could you please pull the latest one? I tried it with ChibiOS/RT instead of FreeRTOS but I am pretty sure the GOS port is not the problem here. ~ Tectu

I took a look and I couldn't find any obvious error so far. I assume that you have some build issue. Are you sure that you properly include everything into your projects Makefile? I know that you're not using ChibiOS/RT but you can still take a look here to see which parts are uGFX relevant. They have been hilighted. Don't forget to include GFXSRC and GFXINC. Can you please attach your entire Makfile (or even the entire project) and the compiler output log? Hint: Somebody just pull requested fixes to the FreeRTOS port ~ Tectu

I will take a look at this in a few hours. I am currently on the road. Are you using the current FreeRTOS branch? Make sure you merge it to the master first, it hasn't been synced for quite a while. Talking about this: I am reworking the FreeRTOS port right now. It is very dirty and incomplete. However, as our website states we are searching for testers. We'd be very thankful if you could help us getting this port ready so FreeRTOS can be officially supported by the 2.1 release which should come up in a few weeks. ~ Tectu

Hey Dmytro, nice to hear from you again The SSD1289 driver appears to build correctly with all my boards here. Can you please show your complete board.mk? I assume that you don't include the driver code correctly. Your board.mk should look like this: GFXINC += $(GFXLIB)/boards/base/Land-Tiger-LPC1768-LCD GFXSRC += GFXDEFS += -DGFX_USE_CHIBIOS=TRUE include $(GFXLIB)/boards/base/Land-Tiger-LPC1768-LCD/chibios_board/board.mk # This is optional, remove if unneeded. include $(GFXLIB)/drivers/gdisp/SSD1289/gdisp_lld.mk include $(GFXLIB)/drivers/ginput/touch/ADS7843/ginput_lld.mk You can zip and attach the whole board directory and I'll have a look at it. ~ Tectu

Hi radiotech, The bare metal port has been finished and is available from the repository. You can enable it by setting #define GFX_USE_OS_RAW32 to TRUE in your gfxconf.h. Please feel free to open a new thread should you face any problem. ~ Tectu

Hello, I just took out my hardware and tried it out with the current code. I couldn't find any issue, everything seems to be working as expected. Can you please describe the problem that you are facing a bit more detailed - probably include a test case code snipped? Probably I'm not understanding your problem correctly. ~ Tectu

This feature has finally been added: https://bitbucket.org/Tectu/ugfx/commit ... 5cc557c2f7 As we couldn't come up with any usecase for other widgets than the list, it has been implemented directly into the list widget API. ~ Tectu

Thank you very much for reporting this bug. I'll take a loot at this tonight. ~ Tectu

Thank you very much for all your time and effort. ~ Tectu

Sounds good to me! Every new driver adds value to the project as it helps especially new comers to get their projects worked more quickly. ~ Tectu

Shilow, I've reviewed and added your driver to the repository. Can you please get to the latest master and try the integrated driver out and report any issues? I assume that this driver now works with all four orientation modes. I've also added you to the contributors list. Should you want to get your full name listed, please PM it to me. ~ Tectu

I checked your permission and I don't see any problem there. I even tried it out myself (with your permission and it seems to work). Don't you find the necessary button/link or do you get any error message? ~ Tectu

What's exactly the problem? ~ Tectu

I recommend you to send a private message to zump so he gets an e-mail notification. You can do that by clicking on the username. ~ Tectu

Well in that case we're going to need two separate drivers indeed. Could you guys provide a working drives which works correctly in all four orientations so they can be added to the repository? Please find out the correct controller name and revision. ~ Tectu

If it's only about a few register values due to different revisions of the chip, we can also just read out the chip ID and handle it differently. Here's an an example. ~ Tectu

Hello Florian and welcome! It is possible to use the internal controller of the STM32F4x9. However, there is no official support yet so you would have to write the board files yourself. The board file is that part where the uGFX library can say "hey man, draw a green pixel at the coordinates 13/37!" - inside that file you'll have to talk to your LTDC peripheral. The LTDC is then responsible to drive the display panel. If you plan to use ChibiOS/RT, one of the guys there already wrote a HAL and got the display working. The board file is really nothing but a wrapper around that. Note that there's already a driver for the ILI9481 display from our side as well. I hope that helps. ~ Tectu

Glad to hear that you got it working! Shilow, could you give the driver attached in xlh1460s post a final try? We'll replace the one in the repository then. ~ Tectu

Hello ellboy and welcome to our community! It really depends on your application. The best performance is delivered by the RA8875 as it provides hardware acceleration for drawing circles, lines etc. However, this is an industrial grade controller and therefore it's not easy to find cheap modules that come with it. The most used and best supported drivers are the SSD1289 and SSD2119. The SSD1963 is used for displays with a higher resolution but it can be tricky to get it running as you have to manually enter the panel data (how the signals should look like). But as most suppliers give those values, it's still not too much of trouble. To summarize: Go for an SSD1289 or SSD2119 if you're in the lower resolution segment and choose an SSD1963 for higher resolutions. I hope that this answers your question. Feel free to ask any further ones. ~ Tectu

I don't understand why it doesn't compile for you either as the file includes the same headers. I'm sadly not able to compile it myself before the weekend and I still couldn't try it as I don't have such a display. However, when I understand you guys correctly - we need two separate drivers? ~ Tectu

You should take your current working project and just replace the gdisp_lld_ILI9325.c file inside /drivers/gdisp/ILI9325 (You should back up your current one). Everything should compile just fine then assuming that your current project with the current driver compiles as well (Is that the case?). I'm currently not able to test it. Probably shilow can help. Thank you very much for your time guys. It helps us a lot to improve the quality of the project. ~ Tectu

What exactly was the issue with the PM? Thank you very much for trying the driven is advance. ~ Tectu

I sadly don't have any ILI9325 display myself. I'll PM the guy from the other thread so he can give your reworked driver a try. If it doesn't work for him, we'll have to create two drivers as you suggested. Thank you very much for your contribution! ~ Tectu

There are two bits (AM and I/D) which control the orientation of the display. You can find them in the datasheet (PDF) on page 54. It looks like they have not been set correctly. Can you please change them and report the correct settings back to us / pull request a patch? Edit: Have you seen this? ~ Tectu

I'm a bit confused - Does this mean that you got it working? ~ Tectu