Jump to content

Joel Bodenmann

Administrators
  • Posts

    2,656
  • Joined

  • Last visited

  • Days Won

    2

Posts posted by Joel Bodenmann

  1. You are right - there's a problem. I'll fix that as soon as I get time (won't be before wednesday, I'm afraid).

    Thank you very much for finding and reporting.

    If you have any other issues by compiling µGFX 2.0, please open a new thread.

    ~ Tectu

  2. Can you please give some more information about bad paths etc?

    We built every single /boards/base/ before the release and it seemed to work fine.

    Please open a new thread with an appropriate thread name in the development & feedback section.

    ~ Tectu

  3. Hello steved and welcome to the community.

    The major performance "issue" you will face is the actual interface speed between you and your display controller. 800x480 are quite a lot of pixels that need to be handled. Within our algorithms, we try to just modify the area which needs to be (no complete screen redrawings). However, if you build some GUI inteface like

    where you clear the complete screen often, you will still observe quit a long build-up time if you use a slow interface. The display controller used in the video is an SSD1963 as well, but in 8-bit mode. Using the 16-bit mode instead would lead to a very big performance gain.

    Long story short: Choose a microcontroller which provides a fast parallel interface to talk to your SSD1963. Every STM32F1xx and STM32F4xx MCU does provide a 16-bit FSMC interface. Make sure you get a package with enough pins for all your stuff as the FSMC will eat up 20 pins (watch out for pin collisions!)

    If you can afford it (no mass production etc), go for some STM32F407 instead of an STM32F1xx as that one runs on a frequency twice as high. Also, more RAM and FLASH is never a bad option anyway. You might just need the basic elements like buttons and check boxes, but the GUI will look A LOT nicer if you blit some custom bitmaps (images) over them. With 1MB of flash, you can store a lot of bitmaps :)

    I hope that answers your question a bit - feel free to ask any further.

    ~ Tectu

  4. That sounds about right. However, you'll have to create a file called board_KS108 instead of the gdisp_lld_board.h when you're using the new GDISP structure - which I highly recommend (you'll see that by looking at the SSD1306 from the GDISPStreaming branch as well). When you don't use that branch, your driver won't work with anything after µGFX v1.9.

    The project you linked seems about right to get some information about how to talk to the display. However, make sure you're not violating any licenses.

    ~ Tectu

  5. Welcome to the community and thank you very much for your kind words! Let's keep in mind that the quality and the success of the projects depends a lot on contributions from community members as well :)

    There's currently no driver for the KS108 display controllers. It shouldn't be a big problem to write one yourself. I'd suggest you to take the SSD1306 driver as a template because this is a monochrome display driver as well. I assume that the used interface is similar to the HD44780 (TDISP module) driver (16-bit parallel with WR/RD). Therefore you could have a look at that to get an idea on how to implement the interface.

    The forum is always available for questions, should you face any problems.

    One last thing: µGFX 2.0 is supposed to be released within a week or two. There are critical changes to the GDISP driver structure. Therefore I'd suggest you to directly write your driver for that new structure. For that, just take the GDISPStreaming branch, instead of the master branch from the repository.

    ~ Tectu

  6. I took a quick look at the board_SSD1306_spi.h file of the current GDISPStreaming branch:


    static const SPIConfig spi1config = {
    NULL,
    /* HW dependent part.*/
    SSD1306_MISO_PORT,
    SSD1306_MISO_PIN,
    0
    //SPI_CR1_BR_0
    };

    This is actually the CS, not the MISO port and pin.

    I don't want to touch file in case of inmarket is still working on it - could you please fix this as well?

    Also note that there's a missing (void)g; in the write_cmd() call.

    ~ Tectu

  7. I'm sorry, but I don't really use ChibiStudio myself. I myself develop without any IDE since I got fed up by all this crazy stuff. I wrote this guide back the days in case of you're interested. Using that method, you won't have any problems with the Makefile modifications etc. at all because the Get µGFX Guide is 100% accurate for that method.

    Otherwise I suggest you to take the working F407 Discovery demo and start building your own stuff around it.

    ~ Tectu

  8. See, this is exactly the problem I mentioned ;)

    When you're using Keil as your IDE, you have to add all the used .c and .h files of µGFX to your project path. I did this once for a friend quite a while ago and it was a real pain. Sadly it's not possible to build from an external Makefile out of Keil, so you can simply forget about the Makefile (modification). I'd suggest you to use ChibiStudio. That's a ready-to-use eclipse setup coming with the compiler and flasher already built-in and setup.

    ~ Tectu

  9. There's not much sense in building such a demo for us. There are just too many factors which differ from system to system. Even if we build such a demo, there will be problems regarding toolchains. People use different compilers, different IDEs, different flash tools... As soon as we are through that, we have the problem that the panel settings differ from each display (the gdisp_lld_panel.h).

    However, the STM32F407 discovery board is well supported by ChibiOS/RT and it runs out of the box. The SSD1963 driver of µGFX itself is used by many community members as well and there's even a demo board file for the STM32F407 discovery. Assuming that your toolchain is working fine and that you're able to wire it up correctly, there's really nothing that can go wrong beside the panel config file - and that's where we simply can't give any working demo at all.

    If you have specific questions, please feel free to open up a new thread and ask, we will help you as best as we can.

    ~ Tectu

  10. Nice to hear that you finally got it working! Maybe you could provide a small video once you got something working? It would be nice to have a demo showing cyrillic stuff.

    Why do you use STDperiph lib for the FSMC by the way? There are many example board files showing how to use FSMC within ChibiOS/RT.

    May I ask how much you paid for that board? I cannot find any price information :(

    ~ Tectu

  11. Hello tronicgr and welcome to our forum!

    I tested the SSD1289 driver myself two days ago and it still worked fine, therefore the issue must be somewhere else.

    How is the display connected on your board? Is it a GPIO bit bang or does it use the FSMC interface of the F4? Can you attach the schematics of the board? I have some F4 discovery and an SSD1289 here, so I can try to hook one up to that board.

    Also, what does 'black/white screen' exactly mean? Do you see anything or just a black screen and nothing at all?

    And to answer your question: There are no ChibiStudio examples themself, sorry. But I am sure we can make this working without any problems ;)

    ~ Tectu

  12. This guide should lead you through the process without any problems. In the Integrate µGFX section, you can find a link to a working Win32 Makefile.

    Basic examples can be found under /demos/modules/gdisp/. All these demos are meant to work out of the box just by copying the gfxconf.h and the main.c file from the demo directory to your working project.

    ~ Tectu

×
×
  • Create New...