HY28A-LCDB, ili9320 (working)

[notro]

So I am working on a test program in python, but in order to use the touchpanel, you need to know which /dev/eventX is associated with it. We can manually guess of course, but X will change depending on which other input devices are fitted at the time. Is there are way of finding which eventX is used and importing it into python?

Doesn't X windows respond to all eventX devices? I think I had mouse and touchpanel working at the same time.

If you're looking to find which eventX is the touchpanel, I see two solutions:

* Search through /dev/input/by-id or /dev/input/by-path to find the one you're looking for

Code: Select all

$ ls -l /dev/input/by-id/
total 0
lrwxrwxrwx 1 root root 9 Jan  1  1970 usb-LITEON_Technology_USB_Multimedia_Keyboard-event-if01 -> ../event2
lrwxrwxrwx 1 root root 9 Jan  1  1970 usb-LITEON_Technology_USB_Multimedia_Keyboard-event-kbd -> ../event1
lrwxrwxrwx 1 root root 9 Jan  1  1970 usb-Microsoft_Basic_Optical_Mouse-event-mouse -> ../event0
lrwxrwxrwx 1 root root 9 Jan  1  1970 usb-Microsoft_Basic_Optical_Mouse-mouse -> ../mouse0

$ ls -l /dev/input/by-path/
total 0
lrwxrwxrwx 1 root root 9 Jan  1  1970 platform-bcm2708_usb-usb-0:1.2:1.0-event-mouse -> ../event0
lrwxrwxrwx 1 root root 9 Jan  1  1970 platform-bcm2708_usb-usb-0:1.2:1.0-mouse -> ../mouse0
lrwxrwxrwx 1 root root 9 Jan  1  1970 platform-bcm2708_usb-usb-0:1.3:1.0-event-kbd -> ../event1
lrwxrwxrwx 1 root root 9 Jan  1  1970 platform-bcm2708_usb-usb-0:1.3:1.1-event -> ../event2

* Use python-evdev: http://pythonhosted.org/evdev/

Code: Select all

>>> from evdev import InputDevice, list_devices

>>> devices = map(InputDevice, list_devices())

>>> for dev in devices:
...    print( '%-20s %-32s %s' % (dev.fn, dev.name, dev.phys) )
/dev/input/event1    Dell Dell USB Keyboard           usb-0000:00:12.1-2/input0
/dev/input/event0    Dell Premium USB Optical Mouse   usb-0000:00:12.0-2/input0

[texy]

Thankyou

Probably not the most elegant, but this works :

Code: Select all

from evdev import InputDevice, list_devices
devices = map(InputDevice, list_devices())
eventX=""
for dev in devices:
    if dev.name == "ADS7846 Touchscreen":
        eventX = dev.fn
print eventX

Texy

[Jim Manley]

Can someone confirm that this will not display any OpenGL/OpenVG/EGL/etc., output, since this is based on bit-mapped display memory driven by the ARM CPU and not the GPU?

Also, is the best frame rate achieved still about 20 fps?

Can this work be readily extended to any other larger displays?

Even with those limitations, this is really nice work - thanks very much!

[notro]

Can someone confirm that this will not display any OpenGL/OpenVG/EGL/etc., output, since this is based on bit-mapped display memory driven by the ARM CPU and not the GPU?

I have no experience here, but I answer based on help by google:
This indicates that OpenGL/Mesa works if used inside X: http://www.mesa3d.org/xlibdriver.html
This says that direct fbdev support is deprecated: http://www.mesa3d.org/systems.html

The native Pi display is accessed through a framebuffer right? So I guess everything that works with /dev/fb0 should work with /dev/fb1.
Or am I missing something here?

Also, is the best frame rate achieved still about 20 fps?

The limitation is the SPI bus (LCD controller, wiring and SOC). Running the bus @32MHz gives 20fps.
See this and the following posts on SPI speed: http://www.raspberrypi.org/phpBB3/viewt ... 33#p377633

Can this work be readily extended to any other larger displays?

There is work going on using a CPLD to convert SPI to 16-bit parallel databus for use with 4.3" and larger displays. See the above mentioned thread.

Another possibility is to use an latched 8-bit or 16-bit bus directly, with the drawback of loosing many gpios.
See: http://www.raspberrypi.org/phpBB3/viewt ... 50#p364650
No reported results so far.

Even with those limitations, this is really nice work - thanks very much!

Thanks.

[Jim Manley]

I have no experience here, but I answer based on help by google:
This indicates that OpenGL/Mesa works if used inside X: http://www.mesa3d.org/xlibdriver.html
This says that direct fbdev support is deprecated: http://www.mesa3d.org/systems.html

Unfortunately, the Pi only supports OpenGL ES, not OpenGL, and IIRC, Mesa hasn't been made to work with the ES flavor the Pi supports, at least not in a substantial way. I should have made ES clear in my post.

The native Pi display is accessed through a framebuffer right? So I guess everything that works with /dev/fb0 should work with /dev/fb1.
Or am I missing something here?

The framebuffer is shared by the CPU and GPU, where each operates in its own plane with the GPU overlaying the CPU frames, but transparency and clipping work, so you can see around/through GPU graphics. If the CPU is the only thing driving the touchscreen display, there won't be any related GPU graphics overlaid, AIUI.

There is work going on using a CPLD to convert SPI to 16-bit parallel databus for use with 4.3" and larger displays. See the above mentioned thread.

Another possibility is to use an latched 8-bit or 16-bit bus directly, with the drawback of loosing many gpios.
See: http://www.raspberrypi.org/phpBB3/viewt ... 50#p364650
No reported results so far.

OK, thanks for the links!

[ThomasG]

Hi TomasG,
I think that you must install xinput

sudo apt-get -y install xinput

thanks to notro that made this huge work!!!
Now for me works everything perfectly.

That I already did.

After a few more days of fiddling, reading the source, and a lot of experimenting it turned out that the one display where I had the problem was acutally faulty on the hardware level somehow.

With another display of the same type it works flawlessly.

[theandreas]

Hi notro,
resolved...
I used the same software that I wrote before for not fb lcd version and access to fb using a pointer.
when finished I'll post code.
Once again thanks

Hello,

Have you already finished? I'm very interested in your solution.
Yesterday I downloaded your library at github, it works great. Thanks for your work.
But unfortunately it's a little too slow for my usage.
Is it faster with the fb?

[topogigio]

Yes! You can use the framebuffer made by notro and the driver of graphic environment made by me... I'll post the graphic drivers on Tuesday...

[topogigio]

as promises...
https://github.com/topogigio/HY28A-LCDB-GUIFB

[theandreas]

Thank you, it looks good.
I will try it the next days.

[theandreas]

as promises...
https://github.com/topogigio/HY28A-LCDB-GUIFB

When I try this command: "sudo ./fblcd /dev/fb1 /dev/input/event2",
I always get: "Error: cannot open pointing device"

What does it mean?

[texy]

..it means the touch panel is not associated with /dev/input/event2, so it may be event0, or event1. It depends on if you have a keyboard and/or a mouse connected to the Pi.
Texy

[notro]

You can use evtest to find which /dev/input/eventX to use.

Code: Select all

$ sudo apt-get install evtest

$ sudo evtest
No device specified, trying to scan all of /dev/input/event*
Available devices:
/dev/input/event0:      Microsoft Basic Optical Mouse
/dev/input/event1:      LITEON Technology USB Multimedia Keyboard
/dev/input/event2:      LITEON Technology USB Multimedia Keyboard
Select the device event number [0-2]:

See further up the thread for a way do this in python: http://www.raspberrypi.org/phpBB3/viewt ... 63#p380163

[topogigio]

In readme file you can find the requirement, notro's wheezy version is required.
I think that you must also install xinput. My software provide calibration first time running and until cal file is present in same directory of the executable.

[theandreas]

Yes I'm using notro's wheezy version.
I installed evtest and xinput.


Evtest says:

Code: Select all

pi@raspberrypi ~/HY28A-LCDB-GUIFB-master $ sudo evtest
No device specified, trying to scan all of /dev/input/event*
Available devices:
/dev/input/event0:      LITEON Technology USB Multimedia Keyboard
Select the device event number [0-0]: 

Should the Touchscreen also appear?

The wiring is the same as in your other driver (HY28A-LCDB-Drivers) or not?

[topogigio]

I don't remember but is notro's image defaults. I'am outside home, but if you look at #define section of main.c...

[theandreas]

I don't remember but is notro's image defaults. I'am outside home, but if you look at #define section of main.c...

Now it' running .
The https://github.com/topogigio/HY28A-LCDB ... Wiring.txt is not correct.
Maybe you could modify it.

And I didn't know, that I had to setup the touchpanel driver before I could use your library.

Thanks for the help.

[topogigio]

Yes... I'll do it asap... The file comes from the previous project.

[topogigio]

Wiring file corrected

[bts]

Hello guys. I've written some code for this LCD recently... main difference between mine and all these mentioned before is that mine is aimed to work on bare metal. I created it mainly for educational purposes, but in case somebody finds it useful I share it here. Feel free to use that code.
Link (on the bottom)

[BrendonShaw]

I have this display and really keen to understand how it works from a driver level, I was trying to use the initial code from Okin but even with the changes it still does not work. Does any one know if the finial working code from Okin is anywhere I could look at just to understand the bare bonds of the code with the fixes?

Many thanks

[notro]

Interface details for the HY28A display with an ILI9320 controller.

Hardware

The IM[3:0] pins decide the interface mode of the controller. On the HY28A this is: 0100
According to 7.2. Input Interfaces in the datasheet, this means:
Interface mode: Serial Peripheral Interface (SPI), ID=0

The SPI interface consists of the following pins:
SCK - clock
SDI - Serial Data In, which corresponds to MOSI (Master Out Slave In)
SDO - Serial Data Out, which corresponds to MISO (Master In Slave Out)
CS - Chip Select, which corresponds to CE (Chip Enable)

SDO is not needed for driving the display, only for reading status registers etc.
SPI_MODE_3 must be used: http://en.wikipedia.org/wiki/Serial_Per ... _and_phase

In addition to those pins we also need this:
nRESET - Hardware Reset active low

Many controllers need the reset signal to be pulsed low before operation. I haven't tried to see if just pulling it high with a 10k resistor will work (saving a gpio).

This display also has a BL_CTRL pin that controls backlight. It is tied high, so backlight is on by default. Drive this low, to turn off backlight.
See schematic for details: http://www.haoyuelectronics.com/ebay/NX ... 8A_SCH.pdf


In SPI mode the ILI9320 needs a special start byte in each transmission. This byte contains the ID and info about the operation.
From 7.3. Serial Peripheral Interface (SPI):
Start byte[7:0]: 0 1 1 1 0 ID RS RW
ID - 0 for HY28A
RW - 0/1 - Write/read operation
RS - 0/1 - Index/data

Registers are 16-bit wide, big endian (Raspbery Pi is little endian, at least from kernel space).

GRAM - Graphics RAM
The controller contains memory (framebuffer) that is used to refresh the display. The refresh rate is set through a register.


Software

After a hardware reset the driver must initialize the registers to match the needs of the display panel. This sequence is often provided in an example code, or in the display datasheet.

Now the controller is ready to receive the pixels that will be displayed.
Before sending the pixels, the controller needs to know where in GRAM those pixels should go (set_addr_win() in FBTFT, setxy() in the UTFT library).
This is done with these three registers:
GRAM Horizontal/Vertical Address Set (R20h, R21h)
Write Data to GRAM (R22h)

Now the pixels can be sent.


To show some transfer details, I have used FBTFT with all debugging turned on:

Code: Select all

$ sudo modprobe fbtft_device name=hy28a debug=7
$ dmesg

fb_ili9320 spi0.0: set_addr_win(xs=0, ys=0
    fb_ili9320 spi0.0: fbtft_write_reg16_bus8: 0020 0000
        fb_ili9320 spi0.0: fbtft_write_spi(len=3): 70 00 20
        fb_ili9320 spi0.0: fbtft_write_spi(len=3): 72 00 00
    
    fb_ili9320 spi0.0: fbtft_write_reg16_bus8: 0021 0000
        fb_ili9320 spi0.0: fbtft_write_spi(len=3): 70 00 21
        fb_ili9320 spi0.0: fbtft_write_spi(len=3): 72 00 00
    
    fb_ili9320 spi0.0: fbtft_write_reg16_bus8: 0022
        fb_ili9320 spi0.0: fbtft_write_spi(len=3): 70 00 22

fb_ili9320 spi0.0: fbtft_write_vmem16_bus8(offset=0, len=153600)
    fb_ili9320 spi0.0: fbtft_write_spi(len=4093): 72 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ...
    ...
    fb_ili9320 spi0.0: fbtft_write_spi(len=2197): 72 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ...

(fbtft_write_spi() transfers a buffer over SPI. CE/CS is low during this transfer.)

First the GRAM address is set to 0,0:
Set index register 0x0020 -> 0b011100000, 0x00, 0x20
Write 0x0000 to that register -> 0b011100010, 0x00, 0x00
Set index register 0x0021 -> 0b011100000, 0x00, 0x21
Write 0x0000 to that register -> 0b011100010, 0x00, 0x00

Then GRAM write is enabled:
Set index register 0x0022 -> 0b011100000, 0x00, 0x22


Now the pixels can be sent (write_vmem), which in this example is all zeroes, turning the display black.
Since the kernel framebuffer memory has the 16-bit pixels (RGB565) stored as little endian (need to swap bytes), and a start byte has to be added to each SPI transfer, a 4k byte transfer buffer is used.


This shows how the device code is read from the controller:

Code: Select all

fb_ili9320 spi0.0: fbtft_write_reg16_bus8: 0000
    fb_ili9320 spi0.0: fbtft_write_spi(len=3): 70 00 00
    fb_ili9320 spi0.0: fbtft_read_spi(len=4) txbuf => 73 00 00 00
        fb_ili9320 spi0.0: fbtft_read_spi(len=4) buf <= 00 93 93 20
fb_ili9320 spi0.0: Device code: 0x9320

[riskpw]

hi ~~ i m korea raspberrypi user. : http://www.rasplay.org

i made in 2.8 -tft LCD :

how to make it.

finaly product : http://www.rasplay.org/?p=6947









this movie play diy tft-lcd : http://www.rasplay.org/?p=6871

how to make it :

step one : http://www.rasplay.org/?p=6839
step two : http://www.rasplay.org/?p=6890

Interface details for the HY28A display with an ILI9320 controller.

Hardware

The IM[3:0] pins decide the interface mode of the controller. On the HY28A this is: 0100
According to 7.2. Input Interfaces in the datasheet, this means:
Interface mode: Serial Peripheral Interface (SPI), ID=0

The SPI interface consists of the following pins:
SCK - clock
SDI - Serial Data In, which corresponds to MOSI (Master Out Slave In)
SDO - Serial Data Out, which corresponds to MISO (Master In Slave Out)
CS - Chip Select, which corresponds to CE (Chip Enable)

SDO is not needed for driving the display, only for reading status registers etc.
SPI_MODE_3 must be used: http://en.wikipedia.org/wiki/Serial_Per ... _and_phase

In addition to those pins we also need this:
nRESET - Hardware Reset active low

Many controllers need the reset signal to be pulsed low before operation. I haven't tried to see if just pulling it high with a 10k resistor will work (saving a gpio).

This display also has a BL_CTRL pin that controls backlight. It is tied high, so backlight is on by default. Drive this low, to turn off backlight.
See schematic for details: http://www.haoyuelectronics.com/ebay/NX ... 8A_SCH.pdf


In SPI mode the ILI9320 needs a special start byte in each transmission. This byte contains the ID and info about the operation.
From 7.3. Serial Peripheral Interface (SPI):
Start byte[7:0]: 0 1 1 1 0 ID RS RW
ID - 0 for HY28A
RW - 0/1 - Write/read operation
RS - 0/1 - Index/data

Registers are 16-bit wide, big endian (Raspbery Pi is little endian, at least from kernel space).

GRAM - Graphics RAM
The controller contains memory (framebuffer) that is used to refresh the display. The refresh rate is set through a register.


Software

After a hardware reset the driver must initialize the registers to match the needs of the display panel. This sequence is often provided in an example code, or in the display datasheet.

Now the controller is ready to receive the pixels that will be displayed.
Before sending the pixels, the controller needs to know where in GRAM those pixels should go (set_addr_win() in FBTFT, setxy() in the UTFT library).
This is done with these three registers:
GRAM Horizontal/Vertical Address Set (R20h, R21h)
Write Data to GRAM (R22h)

Now the pixels can be sent.


To show some transfer details, I have used FBTFT with all debugging turned on:

Code: Select all

$ sudo modprobe fbtft_device name=hy28a debug=7
$ dmesg

fb_ili9320 spi0.0: set_addr_win(xs=0, ys=0
    fb_ili9320 spi0.0: fbtft_write_reg16_bus8: 0020 0000
        fb_ili9320 spi0.0: fbtft_write_spi(len=3): 70 00 20
        fb_ili9320 spi0.0: fbtft_write_spi(len=3): 72 00 00
    
    fb_ili9320 spi0.0: fbtft_write_reg16_bus8: 0021 0000
        fb_ili9320 spi0.0: fbtft_write_spi(len=3): 70 00 21
        fb_ili9320 spi0.0: fbtft_write_spi(len=3): 72 00 00
    
    fb_ili9320 spi0.0: fbtft_write_reg16_bus8: 0022
        fb_ili9320 spi0.0: fbtft_write_spi(len=3): 70 00 22

fb_ili9320 spi0.0: fbtft_write_vmem16_bus8(offset=0, len=153600)
    fb_ili9320 spi0.0: fbtft_write_spi(len=4093): 72 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ...
    ...
    fb_ili9320 spi0.0: fbtft_write_spi(len=2197): 72 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ...

(fbtft_write_spi() transfers a buffer over SPI. CE/CS is low during this transfer.)

First the GRAM address is set to 0,0:
Set index register 0x0020 -> 0b011100000, 0x00, 0x20
Write 0x0000 to that register -> 0b011100010, 0x00, 0x00
Set index register 0x0021 -> 0b011100000, 0x00, 0x21
Write 0x0000 to that register -> 0b011100010, 0x00, 0x00

Then GRAM write is enabled:
Set index register 0x0022 -> 0b011100000, 0x00, 0x22


Now the pixels can be sent (write_vmem), which in this example is all zeroes, turning the display black.
Since the kernel framebuffer memory has the 16-bit pixels (RGB565) stored as little endian (need to swap bytes), and a start byte has to be added to each SPI transfer, a 4k byte transfer buffer is used.


This shows how the device code is read from the controller:

Code: Select all

fb_ili9320 spi0.0: fbtft_write_reg16_bus8: 0000
    fb_ili9320 spi0.0: fbtft_write_spi(len=3): 70 00 00
    fb_ili9320 spi0.0: fbtft_read_spi(len=4) txbuf => 73 00 00 00
        fb_ili9320 spi0.0: fbtft_read_spi(len=4) buf <= 00 93 93 20
fb_ili9320 spi0.0: Device code: 0x9320

[BrendonShaw]

Many thanks for the quick and very detailed response, it seems it's just having the right SPI commands in the right order. Still not working, but I keep working with the BCM SPI commands, I think there is some issues with the sequence.

[BrendonShaw]

I have managed to get the display runnin, but like other people the update is very slow, what is the best way to perform/execute the spi comms to increase the display update?