zontar
Posts: 148
Joined: Sun Mar 05, 2017 7:14 pm

[SOLVED] basic testing of DPI interface

Sun Apr 05, 2020 2:39 pm

Hi,

in my long quest (search the forum) to connect a low power display to the Raspberry I am moving from a 3 bit SPI display (which in the end worked) to something more colorful, i.e. an Ortustech Blanview 18 bit (3 x 6 bit) parallel display which I hope to drive via DPI. If you are interested, data sheet is here

What I have done so far is following more or less these docs
https://www.raspberrypi.org/documentati ... /README.md
http://blog.reasonablycorrect.com/raw-dpi-raspberry-pi/
https://www.raspberrypi.org/forums/view ... ource Labs and I've started checking basic signals, i.e. clock and h/v sync.
As I suspected, nothing appears. They are stable 1 (or 0 depends).. but nothing alternates as was expected.
I've tried driving the pins directly with some python scripts or with the gpio command from WiringPi and I can see signals on the same pins, so the logic analyzer setup seems correct.

I'm connecting to the Raspberry via wifi and Ssh.

So my questions are many, in growing order of basicness

1) Is it correct to try to display an image with sudo fbi -T 1 colorbars.gif and expect it, if the correct overlay is loaded, to make some signal appear on the relevant pins? I don't want an image now, I'd be happy to see some clock.

1.1) would signals appear even if the magic numbers in config.txt are wrong? In some forums someone suggested that the clock must be at least 32K for the raspberry to drive DPI, but then it was contradicted in other messages.

2) I then discovered that dtoverlay -l listed that there was no dpi18 overlay so I've tried loading it at runtime via dtoverlay dpi18
and got this error

Code: Select all

dtoverlay dpi18
* Failed to apply overlay '0_dpi18' (kernel)
. I then remove it from config.txt, rebooted and added this manually ]dtoverlay dpi18 this time with no errors, and it appears in overlay listing.
root@raspberrypi(ro):~# dtoverlay -l
No overlays loaded
root@raspberrypi(ro):~# dtoverlay dpi18
root@raspberrypi(ro):~# dtoverlay -l
Overlays (in load order):
0: dpi18
root@raspberrypi(ro):~#
HAving done so, should I reasonably expect something to work (signal wise, and using FBI?). Are the other DPI related params in config.txt taken into account? How can I check? using *gpio readall* I see that every pin is in IN mode, and not in ALT2, but I don't know how to change mode apart from enabling the device tree overlay

3) regarding this doc here https://www.raspberrypi.org/documentati ... /README.md, many assumptions are made regarding default polarities, pixel clock and enable disable, that may be trivial to most of the HW specialists, but certainly not to me..
hsync/vsync/output_enable_polarity:
0: default for HDMI mode
1: inverted
what is default for HDMI mode?

or
<v_sync_polarity> = invert vsync polarity
invert with respect to what?
This is in order to help me get the magic numbers and output format correctly.. but of course I will get there once I've solved steps 1) and 2).

Thanks to any pointer in the right direction.
Regards
Z

btw this is my original config.txt

Code: Select all


gpu_mem_256=128
gpu_mem_512=256
gpu_mem_1024=256
overscan_scale=1

dtparam=i2c_arm=off
dtparam=spi=off


[all]
dtoverlay=dpi18

overscan_left=0
overscan_right=0
overscan_top=0
overscan_bottom=0

enable_dpi_lcd=1
display_default_lcd=1
dpi_group=2
dpi_mode=87

framebuffer_width=320
framebuffer_height=240


dpi_timings=240 0 0 1 2 320 0 0 1 2 0 0 0 60 0 4608000 1
dpi_output_format=393237

boot_delay=0
Last edited by zontar on Sat Apr 25, 2020 3:07 pm, edited 1 time in total.

aBUGSworstnightmare
Posts: 2316
Joined: Tue Jun 30, 2015 1:35 pm

Re: basic testing of DPI interface

Sun Apr 05, 2020 7:05 pm

Magic number is essential, as well as DPI timings.

I also tested a Ortustech quite q while ago https://www.raspberrypi.org/forums/view ... h#p1002475, the config.txt is in this post (forget the blob; simply use the 18bit dpi overlay (or test with your custom blob) https://www.raspberrypi.org/forums/view ... ch#p929338

Your dpi_timings is incorrect, check your spec again.

Test with dpi24 overlay; maybe there is still a bug in the dpi18 (as 24-bit overlay was also incorrect when RPi4 was released; due to different drive strength)

zontar
Posts: 148
Joined: Sun Mar 05, 2017 7:14 pm

Re: basic testing of DPI interface

Tue Apr 07, 2020 10:14 am

Thanks!
so if the timings are wrong, the DPI circuit won't even start issuing wrong signals but will stay dead. That's what you are telling me?

And, hoping to get timing right, is it correct to use fbi to send an image to the panel (remeber, I'm on ssh)? I.e. is this the simplest way to test if the DPI settings are correct? I am just referring to the signal coming out from the GPIO pins on the raspberry.. (then if they are alive I will start debugging the circuit to the actual panel).

Now I've solved some problems with my logic analyser and I will start all over again.

One last thing: I've tried compiling the dpi18.dts from source and it seems different from the one inside Buster. It even sets the GPIO mode to ALT2. Why are you suggesting me to use dpi24 if in the next sentence you hint there was an error whene Raspi4 was released)? I've also read about it being busted in Buster (!), but has it been corrected?

Btw I think I've already read your post, now that I have the hardware in place it looks all the more interesting and I will dive into it. Thanks for all the effort and help you give to the community.

Best regards.
Z

zontar
Posts: 148
Joined: Sun Mar 05, 2017 7:14 pm

Re: basic testing of DPI interface

Tue Apr 07, 2020 2:34 pm

Well,

some updates but no good news.

First, it seems that the command dtoverlay just lists overlays loaded from the command line, or using the command itself, and not the ones loaded with the dtoverlay=xxx syntax inside config.txt. Can anybody confirm?

Second, I can load overlays on the command line, i can load some overlays (dpi18, dpi24 and a modified, simpler dpi18). After loading each one the command gpio readall lists at least the PINs in ALT2 mode.

But with everyone of them if I try the output via fbi command, I don't have nothing in the CLK, HSYNC and VSYNC pins (i.e. physical pins number 27, 3,5).

I've corrected the timings (but they didn't seem to me so wrong) and the magic number:

Code: Select all

 # Additional overlays and parameters are documented /boot/overlays/README
overscan_left=0
overscan_right=0
overscan_top=0
overscan_bottom=0
framebuffer_width=320
framebuffer_height=240

dtparam=i2c_arm=off
dtparam=spi=off
dtparam=i2c_vc=off

enable_dpi_lcd=1
display_default_lcd=1
dpi_group=2
dpi_mode=87


#h_active_pixels = 240      data sheet: 2.7 inch diagonal display, 720 [H] x 320 [V] dots. 240RGB x 320 pixel.
#h_sync_polarity = 0        0: active low 	  1: active high data sheet: HSYNC (Negative polarity)
#h_front_porch =   2        cannot find in data sheet
#h_sync_pulse = 1           data sheet: HSYNC pulse width: min 1
#h_back_porch = 2           data sheet: H Back Porch, min 2 max 14
#v_active_lines = 320       data sheet: 2.7 inch diagonal display, 720 [H] x 320 [V] dots. 240RGB x 320 pixel.
#v_sync_polarity = 0        0: active low  data sheet: VSYNC Negative Polarity
#v_front_porch = 2          data sheet: cannot find
#v_sync_pulse = 1           data sheet: 1H
#v_back_porch = 8           data sheet: H Back Porch, min 2 max 14
#v_sync_offset_a = 0        leave at zero
#v_sync_offset_b = 0        leave at zero
#pixel_rep = 0              leave at zero
#frame_rate = 60            screen refrech rate (50/60Hz supported only!)#
#interlaces = 0             leave at zero!
#pixel_freq = 16670000      calculates as: <h_active_pixels> * <v_active_lines> * <frame_rate>
#aspect_ratio = 1           4/3 as per lookup table.

dpi_timings=240 0 2 1 2 320 0 2 1 8 0 0 0 60 0 4608000 1

# CLK frequency  as per datasheet: fCLK min 4.4 typ 5.6  max 7.0 MHz CLK, so 4.6MHz is in range

dpi_output_format=459285

boot_delay=0
Still missing some info, such as the front porch, I could not find them at least not explicitly, in the data sheet. Or don't know what to put in back porch, when the data sheets states only min and max value, but not the typical one.


and this is what I've used for the magic numbero

Code: Select all

output_format	5	0101	
rgb_order	1	0001	
output_enable_mode	0	0	0: Enable data valid / 1: Combined sync
invert_pixel_clock	1	1	Invert (0:Stable high / 1:Stable low)
hsync_disable		0	0	Disable hsync
vsync_disable		0	0	Disable vsync
output_enable_disable	0	0	Disable DEN pin
hsync_polarity		0	0	Invert (0:Normal / 1:Inverted )
vsync_polarity		0	0	Invert (0:Normal / 1:Inverted )
output_enable_polarity	0	0	Invert (0:Normal / 1:Inverted )
hsync_phase		1	1	0: Rising / 1: Falling edge triggering
vsync_phase		1	1	0: Rising / 1: Falling edge triggering
output_enable_phase	1	1	0: Rising / 1: Falling edge triggering
I still cannot find an official voice as to what "normal" is for HDMI/DPI. I remember reading somewhere something that suggested that for HDMI "normal" is low polarity for syncs but that's all.
The datasheet is like this
Screenshot 2020-04-07 at 16.31.36.png
Screenshot 2020-04-07 at 16.31.36.png (75.05 KiB) Viewed 1190 times
What bothers me is that I cannot have a signal, not even the clock signal on the pin. I suspect I am doing something totally stupid and wrong (or missing one big step).

Z

zontar
Posts: 148
Joined: Sun Mar 05, 2017 7:14 pm

Re: basic testing of DPI interface

Thu Apr 09, 2020 3:52 pm

Still trying, no progress.

I've pored over the thread by aBUGSworstnightmare and seen that the display he used 5 years ago is very similar to the one I'm using now. I have thus changed the timings and the flags in config.txt to match his, with the obvious differences. SOme flags puzzel me but I've followed the example.

I've also changed the magic number.

I've decided that the DPI overlays on my Pi Zero W do not work, since neither dpi18 nor dpi24 seems to put the GPIO pins in the ALT2 mode. [edit indeed they seem to work right now, maybe the order of params in config.txt was wrong>] Following another thread by aBUGSworstnightmare I've put explicitly the pins in config to ALT, no pullup mode. This way I can have the configuration correct *at least using "gpio readall").

But if I try to display an image with

Code: Select all

sudo fbi -T 1 image.gif
i still don't have signals on the pins.

What bothers me is
  • the problems with the stock Buster dpi18 and dpi24 overlays on my Raspberry Pi Zero
  • the fact that I don't have a single clock/sync signal on the pins.. it seems so strange that no signals are output
Anyway I'll try to post on the device tree board.
Thanks
Z

PS this is my config now

Code: Select all

  # Additional overlays and parameters are documented /boot/overlays/README
dtparam=i2c_arm=off
dtparam=spi=off
dtparam=i2c_vc=off
dtparam=audio=off

dtoverlay=dpi18

overscan_left=0
overscan_right=0
overscan_top=0
overscan_bottom=0
framebuffer_width=240
framebuffer_height=320

dtparam=i2c_arm=off
dtparam=spi=off
dtparam=i2c_vc=off

enable_dpi_lcd=1
display_default_lcd=1
dpi_group=2
dpi_mode=87

#gpio=0-21=a2,np

# 0101 = rgb666 config 1, 5
# 0001 = 1   (RGB order)
# output_enable_mode      0  ok
# invert_pixel_clock      0  ok
#   hsync disable         0  ok
#   vsync disble          0  ok
#   output enable disable 0  ok
# hsync polarity          0  ok
# vsync polarity          0  ok
# output_enable_polarity  0  ok
# hsync phase             1
# vsync phase             1
# output_enable phase     1

dpi_output_format=458773

#h_active_pixels = 240      data sheet: 2.7 inch diagonal display, 720 [H] x 320 [V] dots. 240RGB x 320 pixel.
#h_sync_polarity = 1        0: active low 	  1: active high data sheet: HSYNC (Negative polarity)
#h_front_porch =   0        cannot find in data sheet
#h_sync_pulse = 1           data sheet: HSYNC pulse width: min 1
#h_back_porch = 2           data sheet: H Back Porch, min 2 max 14
#v_active_lines = 320       data sheet: 2.7 inch diagonal display, 720 [H] x 320 [V] dots. 240RGB x 320 pixel.
#v_sync_polarity = 1        0: active low  data sheet: VSYNC Negative Polarity
#v_front_porch = 0          data sheet: cannot find
#v_sync_pulse = 1           data sheet: 1H
#v_back_porch = 2           data sheet: H Back Porch, min 2 max 14
#v_sync_offset_a = 0        leave at zero
#v_sync_offset_b = 0        leave at zero
#pixel_rep = 0              leave at zero
#frame_rate = 60            screen refrech rate (50/60Hz supported only!)#
#interlaces = 0             leave at zero!
#pixel_freq = 240x320x60    calculates as: <h_active_pixels> * <v_active_lines> * <frame_rate>
#aspect_ratio = 1           4/3 as per lookup table. It's 3/4 in reality

dpi_timings=240 1 0 1 2 320 1 0 1 2 0 0 0 60 0 4608000 1

# CLK frequency  as per datasheet: fCLK min 4.4 typ 5.6  max 7.0 MHz CLK

boot_delay=0
Last edited by zontar on Thu Apr 09, 2020 4:02 pm, edited 1 time in total.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 9923
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: basic testing of DPI interface

Thu Apr 09, 2020 3:58 pm

Start with one of the known to work sets of timings and dpi_output_format value. Check you get signals on your 'scope then.

NB If DPI is configured then the signals will always be active, not just when you display something on it.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

aBUGSworstnightmare
Posts: 2316
Joined: Tue Jun 30, 2015 1:35 pm

Re: basic testing of DPI interface

Thu Apr 09, 2020 4:09 pm

Dpi24 overlay is working; using it each and every day on zero, A+, 3, 4, CM3 ..

Do as suggested by 6by9. Good starting point is Adafruit 4.3in timings 480x272pixels. Check your GPIo

zontar
Posts: 148
Joined: Sun Mar 05, 2017 7:14 pm

Re: basic testing of DPI interface

Thu Apr 09, 2020 4:58 pm

6by9 wrote:
Thu Apr 09, 2020 3:58 pm
Start with one of the known to work sets of timings and dpi_output_format value. Check you get signals on your 'scope then.

NB If DPI is configured then the signals will always be active, not just when you display something on it.
Nice suggestion, should have followed it before. I've tested with a 640x480 dpi18 screen that somebody on this forums certified it worked perfectly, and at least I could get the signals on the analyser! Whoa! Wonderful.

I've also tried with the lines that aBUGSworstnightmare used in its experiments (linked in his first reply) and it doesn't show anything on the lines. Weird. Of course I've also set framebuffer sizes accordingly.
But, interestingly enough, if I just raise the clock timing to 32MHz (32000000) without touching other data, I can see some clock signals as well as HSYNC and VSYNC.
I've read somewhere in the forums that clock speed can (or cannot, depend of whom you are reading) be anyvalue or must be greater than 32MHz..

But i was also wondering wether the DPI logic in the SOC does some coherence test before issuing signals.
Anyway..I will keep exploring.

Thanks!
Z

zontar
Posts: 148
Joined: Sun Mar 05, 2017 7:14 pm

Re: basic testing of DPI interface

Mon Apr 20, 2020 12:39 pm

Just to keep the thread updated: I've managed to get signals on the relevant GPIO pins. still no image though.
So far:

Clock, VSYNC, HSYNC, DE, Standby, reset and MSb for Red seem to follow more or less the data sheet:
this is the config I've used. The big leap was starting from some working config and then working out the clock.
As far as my testing goes with the PiZero W, not every clock works, but so far:
  • 32MHz works
  • 19.2MHz and subsequent integer dividers work.
These confirm the theory that I've read somewhere that only integers dividers can be used with internal clocks to get the clock you want. I know that others respected members says different, but I don't know how to make it work for example with 5.8MHz. The internal circuitry seems to refuse to start up. I've even tried by dividing 32K but it does not work (at least for me)
The other great suggestion was that the DPI signals are always present, regardless of the image you show. This speed up testing a lot.

For me 19.2MHz/4=4.8MHz is pretty much in range as per data sheet

Code: Select all

dpi_output_format=24597
dpi_timings=240 1 6 1 2 320 1 2 1 4 0 0 0 60 0 4800000 1
I found some help here https://nerdhut.de/2020/03/17/raspberry ... ntrol-crt/ and explanations on the timings and units of measurement to use.

I've struggled a bit to have VSYNC and HSYNC enabled low. After trial and error I got the combination of timings and magic number correct.
So in the timings, polarity must be inverted (1), also in output format must invert (1) and of course SYNC must be not disabled. The two values should be coherent in dpi_timings and dpi_output_format. Seems a bit redundant to me.

Another curious thing is that in the data sheet some values seem to have the wrong unit, but after a while all makes sense.

Now all I have to do is discover why there is no image and no sign of life. I've also tried driving the backlight LEDs but also here, no sign of life whatsoever (truth be told, I've tried using 5V from the raspberry with a little resistor, but the specs say 8.5V.

I'll keep trying and post results here.
Z

zontar
Posts: 148
Joined: Sun Mar 05, 2017 7:14 pm

Re: basic testing of DPI interface

Mon Apr 20, 2020 5:22 pm

Ok, I've managed to make it work!
BTW look hard at a display without the backlight enabled.. colours are nearly indistinguishable from black, but they are definitely there :)
This is my full config.txt

Code: Select all

dtparam=i2c_arm=off
dtparam=spi=off
dtoverlay=dpi18
framebuffer_width=240
framebuffer_height=320
enable_dpi_lcd=1
display_default_lcd=1
dpi_output_format=458773
dpi_timings=240 0 6 1 2 320 0 2 1 4 0 0 0 60 0 4800000  1
dpi_group=2
dpi_mode=87
With reference to this tables inOfficial Raspberry DPI doc for dpi_timings and dpi_output_format:

Code: Select all

output_format          = (dpi_output_format >>  0) & 0xf;  --> 0101
rgb_order              = (dpi_output_format >>  4) & 0xf;  --> 0001

output_enable_mode     = (dpi_output_format >>  8) & 0x1;  --> 0
invert_pixel_clock     = (dpi_output_format >>  9) & 0x1;  --> 0

hsync_disable          = (dpi_output_format >> 12) & 0x1;  --> 0
vsync_disable          = (dpi_output_format >> 13) & 0x1;  --> 0
output_enable_disable  = (dpi_output_format >> 14) & 0x1;  --> 0

hsync_polarity         = (dpi_output_format >> 16) & 0x1;  --> 0
vsync_polarity         = (dpi_output_format >> 17) & 0x1;  --> 0
output_enable_polarity = (dpi_output_format >> 18) & 0x1;  --> 0

hsync_phase            = (dpi_output_format >> 20) & 0x1;  --> 1
vsync_phase            = (dpi_output_format >> 21) & 0x1;  --> 1
output_enable_phase    = (dpi_output_format >> 22) & 0x1;  --> 1
Steps are
  • get the correct clock. It was a bit of guessing, reading and fighting
  • get the correct mix of dpi_output_format and dpi_timings for active hi/low for enable and sync:
    • on the datasheet, the Data enable is active high: I had to put output_enable_polarity to 0 and phase to 1. Thus the signal was correct
    • for HSYNC and VSYNC which are active low (i.e. the signal is most of the time HI, with the sync being LOW), the same. polarity to 0 and phase to 1.
    • output enable mode is 0, i.e. data valid
  • in dpi_timings, (invert) SYNC polarity is 0 for me (but see below how to make it work with 1)
As for the timings they are more straightforward, with the caveat that VSYNC timings are counted in HSYNC cycles, not in clock cycles.

BTW if you invert the values in dpi_timings for SYNC phase (1) and the ones in dpi_output_format (i.e. polarity to 1 and phase to 0), the result is the same!

Code: Select all

# this one works
dpi_output_format=286741
dpi_timings=240 1 6 1 2 320 1 2 1 4 0 0 0 60 0 4800000  1

# this one works also. the same wave forms for DE and SYNC
dpi_output_format=458773
dpi_timings=240 0 6 1 2 320 0 2 1 4 0 0 0 60 0 4800000  1
Of course it would have been nearly impossible without a logic analyzer.

Now I just have to invent a way to drive 8V backlight leds!
Thanks to everyone. It was a bit hard and cryptic but in the end trial and error and reading a lot of forums helped!
Z

aBUGSworstnightmare
Posts: 2316
Joined: Tue Jun 30, 2015 1:35 pm

Re: [SOLVED] basic testing of DPI interface

Sat Apr 25, 2020 7:25 pm

For your backlight issue a XL6009 should get you started (i.e. https://eckstein-shop.de/XL6009-DC-DC-e ... gLYbPD_BwE).
If you develop a product build your own BL driver with constant current DC/DC boost circuit .

zontar
Posts: 148
Joined: Sun Mar 05, 2017 7:14 pm

Re: [SOLVED] basic testing of DPI interface

Sun Apr 26, 2020 8:07 am

Thanks aBUGSworstnightmare,
for this suggestion and also the others, in various threads.

I will buy a couple of these little boost up modules, wait for the multimeter to arrive, and check everything, then I think I will move to the Compute Module and to design the complete PCB myself, integrating power booster maybe.

Since I will need in any case to draw a PCB for the breakout, maybe a couple of transistors to control the backlight as I've done before, a few switches, a few ports, I told myself why not integrate the power modules also? Bit of presumption I know but.. no big risks

Bye
Z

Return to “Interfacing (DSI, CSI, I2C, etc.)”