Jump to content

Joel Bodenmann

Administrators
 View Profile  See their activity

  • Posts

    2,620

  • Joined

  • Last visited

  • Days Won

    2

 Content Type 

Posts posted by Joel Bodenmann

  2. FreeRTOS

    in Support

    Posted

    The problem for me is the "TIME_INFINITE" define. I think that FreeRTOS has not such a functionality.

    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.

    Function gfxThreadCreate(): Why do you have a for-loop after the call of xTaskCreate() (if the return value is pdTRUE)?

    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

  6. FreeRTOS

    in Support

    Posted

    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

  7. Online fontconvert not functioning

    in Support

    Posted

    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

  8. FreeRTOS

    in Support

    Posted

    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

  13. FreeRTOS

    in Support

    Posted

    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

  14. 32F429IDISCOVERY board file

    in Support

    Posted

    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

  17. 32F429IDISCOVERY board file

    in Support

    Posted

    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

  18. 32F429IDISCOVERY board file

    in Support

    Posted

    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

  19. Unable to get ILI9320 display driver working on STM32F

    in Support

    Posted

    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

  20. TDISP removal

    in Announcements

    Posted

    The TDISP module will be removed within this week for the following reasons:

    • The main goal of the project changed - We moved from a display driver library to an embedded GUI toolkit. It does simply not fit the project anymore.
    • Therefore the TDISP module requires an unproportional amount of effort to keep it up to date, supported and tested.
    • As we asked our users, nobody ever used the TDISP module.
    • The current TDISP drivers are not working anymore as they havent been updated (See point 2).
    • The TDISP module is the only module not starting with the capital letter 'G' (This is more a bit of a joke).

    Edit: Module removed: https://bitbucket.org/Tectu/ugfx/commit ... 48a6a617a3

    ~ Tectu

  22. Difficulty with Sharp LCD

    in Support

    Posted

    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

×
×
  • Create New...