Joel Bodenmann

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

We are currently searching for some volunteers to test our FreeRTOS port... anyone? ~ Tectu

Issue fixed: https://bitbucket.org/Tectu/ugfx/commit ... ?at=master Thanks for reporting. ~ Tectu

Thank you very much for the detailed bug report. I'll take a look as soon as possible. ~ Tectu

Any updates on this? Cannot wait for it as well ~ Tectu

Hello Jörg, I am successfully running uGFX on FreeRTOS. This means that the port already exists and runs. It would only require some cleanup to include it into the repository. If you're intetesed, I can send it to you. It would be nice if you could clean it up and contribute it back. It should not take any longer than 30 minutes to complete the job. Please send an e-mail to the adress listed on the website. ~ Tectu

I am not sure if you can really use the SPI interface on that board. I'd recommend to use the driver in the ChibiOS/RT repository until you get it working - from there it should only be a matter of changing a few intialization parameters to use the uGFX one. ~ Tectu

What exactly did you do? I recommend you to use the provided driver until you get it working. After you got uGFX working, you can use the ILI9341 driver from the uGFX repository. This keeps out problems ~ Tectu

I tried the demo from the ChibiOS/RT community repo myself two weeks ago and it worked just fine. From there it should be easy to create a board file. Keep us up to date ~ Tectu

Sounds good. Note that you have to use the ChibiOS/RT community repository in order to have the LTDC HAL. It's still the better option to use the git repository as many changes happen to the project. You are always on the latest 'version' that way. It also simplifies the contribution process especially if you change files, rather than adding new ones. If you need any help, let us know. Otherwise adding the works as a .zip here or send it per e-mail will always do the trick. Thank you very much in advance for your work. Please let me know about any progress, I can't await it! :shock: ~ Tectu

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