Joel Bodenmann

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

Hello and welcome to the community! That is a well known issue with the ILI932x driver. It looks like there are different revisions of this controller and they require different initialization codes when it comes to the orientation. Sometimes, I myself have seen this, sellers tell you it's an ILI9320 but in fact it's an ILI9325 etc. I had struggled a lot with that controller so far. Things to try: First, Try to use the ILI9325 driver instead. If this does not work, please take a look at the initialization routine of the code example that comes with the display. If necessary, replace the initialization routine in /drivers/gdisp/ILI9320/gdisp_lld_ILI9320.c with the 'new' one (Also check the orientation registers in the control routine). If you have any further questions, do not hesitate to ask! ~ Tectu

What were the kinds of problems that you faced? ~ Tectu

Glad to hear that it works. Do you actually write a dedicated widget for the keypad? It would be nice if you'd contribute it so we can include it into the official repository. ~ Tectu

The documentation is not quite accurate at this. You can either use the long or the short name in the open routine. Therefore you can either rename it by hand as you said or just use the other name. I will update the documentation on that ASAP. Fixing the actual problem will be done in the future - there are just more important things at the moment. ~ Tectu

It should work again. I'm not sure why but for some reason the folder permissions get changed every time... I'll try to investigate. I'm sorry for the inconvenience. ~ Tectu

Please but me know whether it worked or not. ~ Tectu

You should be able to retrieve the button information from the gevent structure that you get passed in your callback: void _callback(void* param, GEvent *pe) { ... ((GEventGWinButton *)pe)->button ... } It's exactly the same as you do when handling the returned GEvent from geventEventWait() within the main(). Note that I did not try this code and it comes completely out of my mind. I'm on the bus. I hope that helps a bit. ~ Tectu

The online font converter is working again. Enjoy your fonts. ~ Tectu