Joel Bodenmann

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

This happens sometimes. Please try the following three things in that order: Try all four orientations using gdispSetOrientation(). It already occurred several times that suppliers used different versions of the ILI93xx chip. For example, some claimed to sell ILI9325 displays but what was really delivered was an ILI9320. Please make sure that you got the correct one. You can read out the display controllers revision register (datasheet). Usually you get some demo code shipped with the display. If none of the above lead to a positive result, please swap the initialisation code inside /drivers/gdisp/ILI9325/gdisp_lld_ILI9325.c with the one from the demo code. Look for the gdisp_lld_init() function. One more thing: How does your hardware setup look like? Is it a PCB or some breadboard setup? I'm curious that the filling options appear to work correctly. This could mean that there is noise on the bus. Are you using SPI or FSMC? You could also try to lower your bus frequency should the points above not work. ~ Tectu

I agree on your points but keep in mind that the driver does include ChibiOS/RT specific HAL functions such as palSetPadMode() in some other places. Whilst I fully agree to your points, I think keeping it consistent is more important. ~ Tectu

Thank you very much for sharing your work! It will be reviewed and eventually included into the repository. Why does the output only work in main()? Did you enable the MULTITHREAD macro? One more question: Why do you directly access the registers of the SPI peripheral? You shouldn't mix the ChibiOS/RT HAL with your own implementation as this can cause problems. ~ Tectu

The interface is abstracted inside the board file. They are named as board_XXX.h where XXX is the controller type and they can be found in the /boards directories. You can take a look at some of the existing SPI board files to see how it could or should be done (They are currently all ChibiOS/RT only). Assuming you're familiar with SPI, it shouldn't take too much effort. Feel free to ask any questions should you face problems. ~ Tectu

I can confirm that there's a build error with the FIXED_* fonts. I'll fix it tomorrow. Please use either a custom or another built-in font at the mean time. ~ Tectu

We are aware of this issue that has something to do with our hoster. It should be working again for the moment. We'll try to fix this soon... Should you still keep running into the same problem, please send us the *.ttf file together with information about size etc. in a mail. We'll then convert it manually for you. ~ Tectu

Thank you very much for finding and reporting this bug. I'll take a look and fix it as soon as possible. ~ Tectu