Jump to content

Joel Bodenmann

Administrators
 View Profile  See their activity

  • Posts

    2,656

  • Joined

  • Last visited

  • Days Won

    2

 Content Type 

Posts posted by Joel Bodenmann

  3. 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

  4. 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

  5. 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

  6. 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

  8. 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

  12. STM32373c-eval evaluation board TFT LCD driving

    in Support

    Posted

    There are currently no board files for the STM32373C-EVAL board. You have to create them yourself.

    If the drivers for your screen already exist, it's simply a matter of linking the stuff in the board makefile and create the appropriate board files. Please take a look at one of the many pre-made ones you can find in /boards/base.

    Otherwise you first have to create your display driver. At least the initialisation routine can be taken from the STM demo code.

    Feel free to ask when you face any problems. Most people get their drivers work in one or two days. However, proper C skills are required, of course. But as you are dealing with that kind of board, that shouldn't be any problem.

    ~ Tectu

  14. STM32373c-eval evaluation board TFT LCD driving

    in Support

    Posted

    Hello madokapeng and welcome to the µGFX community!

    What you want is the 2.0 release of µGFX (ugfx-release-20.zip). ChibiOS/GFX was the previous name of the project and hence the 1.7 release was before the current 2.0.

    However, it's recommended to use the git repository master, as there are lots of bug fixes happening after each new release. The 2.0 is a bit unstable as every .0 release is (classing software designer issue). If you take a look at the git history, you can clearly see that there are a lot of bug fixes since the release.

    ~ Tectu

  15. Want to do lazy display output computation (printf... )

    in Support

    Posted

    Right now, what I do is saving timestamps and doing no GUI output when events happen, e.g. start_of_measurement notification. This is not ideal since I want to put out lots of debug data.

    NEVER put debugging data on an LCD. As soon as you remove it again (once your systems appears to do what you want it to), you change the entire behaviour of the system. Debug data is supposed to be retrieved through your controller debugging port or through any other suited interface. Only put stuff on your LCD that you eventually want on it once you finished your project.

    ~ Tectu

  16. Unable to get ILI9320 display driver working on STM32F

    in Support

    Posted

    According to this picture there is an A and a B version of this board where the A only works with the parallen interface and B only with SPI. Are you 100% sure that you have the SPI version?

    Two things to do: First, check out their example code and replace the initialisation routine of the µGFX driver by theirs (just the register values). Probably the initialisation code for the SPI mode is different. If that does still not work, you might want to try to use the parallel interface by connecting it to the FSMC peripheral of the STM32F4. There's a guide on the µGFX site that tells you what to do.

    Do you have a scope accessible so you can check for proper SPI signals?

    ~ Tectu

  17. Unable to get ILI9320 display driver working on STM32F

    in Support

    Posted

    I cannot see anything obvious there as you are using the same board file. I PM'ed uweng14 so let's hope he looks by soon. Probably he has a newer version of those files.

    What exactly do you see on your screen? Do you see random data (like colored snow?). That would mean that the controller has been initialised properly so far.

    P.S.: Try to call a gdispClear(Black); right after the gfxInit();.

    ~ Tectu

  18. Unable to get ILI9320 display driver working on STM32F

    in Support

    Posted

    What was you final configuration and your wiring? I am facing the same problems and your experience could serve useful for fixing my own problem

    Hello erwinkendo and welcome to the community!

    What problems are you facing? Could you give some more information about your setup i.e. if you're using the STM32F407-Discovery board too and what interface you're using? The ILI9320 driver itself seems to work properly (just tried myself).

    ~ Tectu

  24. How To Start

    in Support

    Posted

    I don't see any problem there. The provided Makefiles within the example directories are of course supposed to include the board files for the board they are written for.

    You are of course not supposed to include the board files of a board you do not own in your project directory, hence the # your board comment. The guide states this:


    If you're using some well known dev board, it's very likely that there are already board files for this board. Inside the /boards/base/ directory, you can find the supported boards. Simply include the board.mk for the appropriate board in your Makefile.

    I will try to rewrite the "Get µGFX" guide within the following week - there was just too little time.

    Long story short: Don't include board files of a board you do not want to use.

    ~ Tectu

×
×
  • Create New...