Jump to content

Joel Bodenmann

Administrators
  • Posts

    2,620
  • Joined

  • Last visited

  • Days Won

    2

Posts posted by Joel Bodenmann

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

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

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

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

  5. Helped:

    GDISP_REG = 0x0003;

    GDISP_RAM = 0x1030; // for GDISP_DEFAULT_ORIENTATION == GDISP_ROTATE_PORTRAIT

    immediately after

    gfxInit();

    with GDISP_ROTATE_LANDSCAPE and 0x1038 -- image flipped vertically.

    I'm a bit confused - Does this mean that you got it working?

    ~ Tectu

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

  7. Good and bad accessing the SPI registers directly.

    On one hand it is operating system independent (a good thing for uGFX), but on the other hand that then makes it CPU specific.

    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

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

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

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

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

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

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

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

  15. In this case we have to use "vTaskSuspend(NULL)" I think. Then the task is not deleted, but sleep forever. Do you think so too?

    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

×
×
  • Create New...