Joel Bodenmann

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

Hello Anna, Please sent the font file to the e-mail listed in the imprint of the webpage and include the details you left here as well. We are sorry for the issue with the online font converted but I'm currently too busy to handle this. I'll try to fix it over the weekend! ~ Tectu

Looks absolutely correct to me. Note that you have to add a macro check for INCLUDE_vTaskSuspend at the top of the freertos.c file just as we already check for the mutexes and semaphores. ~ Tectu

Converted fonts have been sent to you. ~ Tectu

The delay functions provided by FreeRTOS do indeed not provide such a thing, but this is also not vital. If TIME_INFINITE is passed to the gfxSleepXxx() function, this means that the thread should never continue at all. You'd either let the task sleep forever using the FreeRTOS API or you'd simply call delays of 100ms or something in an infinite loop. You can take a look at the ChibiOS/RT port for the former solution. If xTaskCreate() does return something other than pdPass, this means that the thread could not be created. Therefore µGFX can simply not run at all. The for(; is a simple infinite loop so the program will not continue to execute. Debugging of the application is easier this way because inifinite loops can be spotted easily. ~ Tectu

It's nice to see that you got uGFX working that quickly. Feel free to ask questions when you stumble upon any issues. ~ Tectu

I understand the problem that you are describing. I'll try to come up with a solution asap. ~ Tectu

Glad to hear that everything is working as it should We'd be happy to add some more projects to our demos page. ~ Tectu

The following functions in src/gos/freertos.c need to be modified/implemented to fit your setup (we didn't had time to provide a generic solutions so far): gfxSleepMilliseconds() gfxSleepMicroseconds() MS2ST() Make sure you get the latest repository state before you start working on anything. ~ Tectu

I just tried it myself and the font converter does indeed not work as intended. There was a PHP upgrade on our server and this seems to cause some problem. I'll try to fix it ASAP. If you want, you can mail me the font and I'll convert it manually for you until the font converter is up and running again. Please note the required parameters somewhere in that mail. Sorry for the issue. ~ Tectu

Hello Florian, There's a branch called freertos in the git repository. In there you will find src/gos/freertos.c and include/gos/freertos.h. These files are included in src/gos/gos.mk and in include/gos/gos.h. This way you can either pick them into your current repository or simply use the branch as it is. The only thing that you should have to modify are the delay functions inside the freertos.c file. Everything else should work as it is there. Just one question: Did you ever run FreeRTOS successfully on your hardware before? Otherwise I would suggest you to start with that. Note that FreeRTOS does not come with any HAL like ChibiOS/RT comes. Therefore you'll have to include your own! Please keep us up to do date ~ Tectu