Jump to content

JakeSays

Members
  • Posts

    11
  • Joined

  • Last visited

Posts posted by JakeSays

  1. Thanks much for the code.

    It was educational but not complete enough to work.

    But it was very helpful in writing my own driver.

    So as it stands I now have both the display and touch working!

    Would you be interested in a pull request for this specific card?

    Thanks again for all your help :)

    -Jake

  2. You might want to store your calibration values once you performed the calibration. This way you can 'boot up' (starting uGFX by calling gfxInit()) without the need to calibrate again.

    Information on how to use the calibration interface can be found here: http://wiki.ugfx.org/index.php?title=To ... alibration

    ~ Tectu

    Now that I have the framebuffer working I've gone back to using the adafruit kernel drivers. The drivers handle calibration so I think I'm ok there.

    However the next issue I'm facing is how do I read the touch screen values?

    From what I've gathered from the ugfx source I'll need to write a ginput driver that pulls events from /dev/input/touchscreen, which is how the adafruit stmpe driver exposes events.

    The format of the events is straight forward. Here's sample output from evtest /dev/input/touchscreen:

    Event: time 1451488716.725099, type 3 (EV_ABS), code 0 (ABS_X), value 1925
    Event: time 1451488716.725099, type 3 (EV_ABS), code 1 (ABS_Y), value 2226
    Event: time 1451488716.725099, type 3 (EV_ABS), code 24 (ABS_PRESSURE), value 137
    Event: time 1451488716.725099, type 1 (EV_KEY), code 330 (BTN_TOUCH), value 1
    Event: time 1451488716.725099, -------------- EV_SYN ------------
    Event: time 1451488716.781826, type 3 (EV_ABS), code 24 (ABS_PRESSURE), value 0
    Event: time 1451488716.781826, type 1 (EV_KEY), code 330 (BTN_TOUCH), value 0
    Event: time 1451488716.781826, -------------- EV_SYN ------------

    Am I on the right track? Also, what is a toggle input device?

    Thanks,

    -Jake

  3. The uGFX framebuffer does support RGB565 - in fact it is the most commonly used format pixel format for the framebuffer. The framebuffer is capable of supporting any non-palletised pixel format with 8 to 32 bits per pixel.

    The framebuffer driver is actually used by the raspberry pi HDMI display by default in RGB565 format! See boards/base/RaspberryPi/board_framebuffer.h

    I tried using the frame buffer, but when it ran I got an incompatible color format error. I should mention though that I'm using the custom framebuffer (fbtft) from adafruit.

    Note that when running multiple displays there is no problem with the multiple displays having different pixel formats. In a multiple display situation the system pixel format is chosen separately from the hardware display formats and the hardware drivers convert the pixel format as needed. For efficiency it is however best to use a system pixel format common to at least one of the displays. For single display systems the system pixel format always matches the display pixel format.

    I only need to support the PiTFT as the environment is embedded.

    1. The usage of the same SPI port by the lcd and the touch panel. This is solved using the aquirebus/releasebus mechanism described in the previous post.

    I added a mutex and locked/unlocked in aquirebus/releasebus, but ran in to huge lock contention issues when I enabled the touch screen. Drawing speed slowed to the point where there was seconds between each pixel being rendered while drawing the calibration screen.

    2. The compile errors you are getting. This is caused by using the single file build mechanism along with multiple display functionality. The ONLY way to solve this if you want to drive both the pi HDMI display and the Ardafruit display is to use the makefile build method. Of course if you turn off the pi HDMI display you could continue to use the single file build mechanism.

    A lot of those errors were unrelated. I should've cleaned it up before posting. I was in experiment mode.

    In conclusion,

    • the problems you are seeing with "RGB565" and the pixmap errors are all related to #2 above.
    • The problems to do with a single SPI port being used by the lcd and touch are related to #1 above.
    • Pixmaps are really nothing to do with what you are trying to achieve here. They are only confusing the real issues. Please turn them off until you have the displays working properly and then only turn them on if you really want the functionality pixmaps provide.

    I'm going to give these a try with a fresh code base.

    Thanks! :)

  4. Ok I think I may have coded myself in to a rat hole here. I'll explain what it is I'm trying to do and perhaps you guys could provide some guidance?

    I have a Raspberry Pi 2 B and an adafruit 2.8" lcd/touch screen. The lcd is controlled by an ILI9341, and the ts by an STMPE610. The device also exposes the STMPE610 interrupt line.

    My goal is to get uGFX to work with both the lcd and ts. Also I cannot use the framebuffer because the uGFX framebuffer driver does not support RGB565.

    What would be the suggested way to proceed?

    I really appreciate all your help :)

    -Jake

  5. Actually its not a missing header issue. It's related to the single file build method.

    For some reason GDISP_DRIVER_VMT is undefined when gdisp_driver.h is included in gdisp_pixmap.c

    If I comment out gdisp_pixmap.c from gdisp_mk.c and add gdisp_pixmap.c directly to my project the GDISPVMT_pixmap related errors go away.

    However now I'm getting "GDISP: Unsupported color system for low level drivers" :( it appears RGB565 is not supported in a lot of places.

  6. Using the uGFX ILI9341 driver I can draw on the LCD just fine.

    here is line 33 of gdisp_pixmap.c: #define GDISP_DRIVER_VMT GDISPVMT_pixmap

    GDISPVMT_pixmap is not defined anywhere, which causes the compile error.

    My environment is:

    Host:

    Windows 10, VisualGDB, Visual studio 2015. Using visualgdb. I cross compile using their raspberry pi toolchain. This works fine as I have written several apps using it.

    Target:

    Raspberry Pi2, Raspbian jessie.

    Also, I'm using the all-in-one build method (ie no make files)

    I tried using acquire/release_bus() to isolate the two controllers from each other (using a gfxMutex), and change speed. When I do this drawing performance tanks and then eventually stops all together.

    The bitbucket repo (https://bitbucket.org/jakesays/ugfx is public, but currently it is a direct mirror of yours.

    One more thing: the motivation for going down the direct SPI route is the linux framebuffer driver doesn't support RGB565. If it did I'd use that.

    Thanks :)

    -Jake

  7. Hey thanks for the response :)

    Here's a link to my compiler output: http://pastebin.com/62YQYDuZ

    Also I do have GDISP_NEED_PIXMAP defined to TRUE.

    My target environment is a raspberry pi via direct SPI access to an Adafruit PiTFT 2.8" display. Both the LCD and touch screen use SPI.

    I can get the basic demo to work just fine using the ILI9341 driver. My bigger issue is getting the touch screen to work. The driver is an STMPE610, so I've been trying to get the '610 support in uGFX to work. Using a pixmap as an intermediate framebuffer is an experiment to work around the two controllers fighting over the SPI bus.

    In regard to GDISPVMT_pixmap and LLDSPEC missing, I cannot locate them in the source tree using grep.

    Thanks,

    -Jake

×
×
  • Create New...