teux
Posts: 9
Joined: Fri Jan 10, 2020 11:51 pm

DPI Specifics

Sat Jan 11, 2020 12:10 am

Hi all, I'm laying out a PCB to interface a CM3+ to an OLED display, specifically NHD-1.69-160128G.

The controller has an 18 bit RGB 666 mode that takes two sequential nine bit data writes. See diagram below.

I've read the documentation located here along with anything else I can find online more times than I'd like to admit. What I'm curious about is whether the DPI_OUTPUT_FORMAT_9BIT_666 mode does what I think it does? (Write two successive 9-bit chunks over 9 GPIOs to the display, for a total of 18 bits.) and if so, which pins will those be on?

Right now I'm assuming it will use DPI_D0 - DPI_D8 (GPIO 4 - 12) but I'm not sure, and can't find verification anywhere. Confirmation on this as well as any info on timing between the chunks would be wonderful and greatly appreciated. Thank you!
Screen Shot 2020-01-10 at 3.56.54 PM.png
Screen Shot 2020-01-10 at 3.56.54 PM.png (109.66 KiB) Viewed 593 times

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

Re: DPI Specifics

Sat Jan 11, 2020 4:18 pm

I did not check your OLED data sheet, but DPI is as the name says a parallel interface.

Look here for details https://www.raspberrypi.org/documentati ... /README.md

Look at the picture how mode 5 outputs 18bit data , and how GPIO is used dor output

teux
Posts: 9
Joined: Fri Jan 10, 2020 11:51 pm

Re: DPI Specifics

Sat Jan 11, 2020 9:26 pm

With all due respect I linked that exact page and said that I've read it multiple times. I'm sorry if my post was unclear.

It doesn't explain which gpios mode 1, (9BIT_666) uses or how that mode operates, which is my question. I believe it's the mode I want but I can't find any documentation on it.

I need 9 gpios to send 18 bits of RGB data in two chunks.

Thanks again for your time.

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

Re: DPI Specifics

Sun Jan 12, 2020 8:07 am

DPI is a parallel display interface which outputs image data as shown in the picture below:
Image

Let's have a look at mode5 which is 18-bit color (mode 7 is 24-bit color).
GPIO4 to 9 are for blue, GPIO10 to 15 will output green and GPIO16 to 21 red color data. Sure, this assignment can be change by using 'rgb_order'.
teux wrote: It doesn't explain which gpios mode 1, (9BIT_666) uses or how that mode operates, which is my question. I believe it's the mode I want but I can't find any documentation on it.
Details on mode 1 have never been mentioned somewhere, but when I look at your displays data sheet I'm pretty sure it will not be what you're looking for!
DPI always outputs all pixel data parallel. What you need is two consecutive parallel transfers.

I think you're better off connecting your display via SPI interface.

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

Re: DPI Specifics

Mon Jan 13, 2020 2:33 pm

Yes, mode 0 is listed as "9bit 666 RGB data" in our datasheet, which does imply 2 9bit transfers to make an 18bit RGB666 sample. However I'm afraid I have no further information as to exactly how that is achieved.
I can ask a couple of questions internally, but I'm not sure who would have more details.
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.

teux
Posts: 9
Joined: Fri Jan 10, 2020 11:51 pm

Re: DPI Specifics

Mon Jan 13, 2020 6:33 pm

Awesome, thank you 6by9! I would greatly appreciate that. I'm happy to help write up a PR to update the documentation too if you can find anything. I'm also getting my scope back next week so I can just reverse engineer the pins (which I've been trying to avoid having to do. :lol: )

This is for an open source / open hardware project, so I'll be posting results and any code/drivers I come up with on github when it's working.

Also @aBUGSworstnightmare thank you again but I understand all that. I'm only asking about 9BIT_666 mode, which is undocumented. I could fall back on SPI but I would prefer not to. Using DPI would also save me from having to write a custom display driver for the SPI interface.

trejan
Posts: 1112
Joined: Tue Jul 02, 2019 2:28 pm

Re: DPI Specifics

Mon Jan 13, 2020 6:36 pm

teux wrote:
Mon Jan 13, 2020 6:33 pm
I'm also getting my scope back next week so I can just reverse engineer the pins (which I've been trying to avoid having to do. :lol: )
No logic analyser? A dirt cheap USB connected one would be sufficient for this.

teux
Posts: 9
Joined: Fri Jan 10, 2020 11:51 pm

Re: DPI Specifics

Mon Jan 13, 2020 6:49 pm

Oh do they make cheap usb logic analyzers? I should probably pick one up then. I'm a firmware engineer by day and do most of my hardware stuff at home, so I have a (moderately) limited budget.

The ones I'm used to are the 50lb monsters with a CRT that cost thousands of dollars.

trejan
Posts: 1112
Joined: Tue Jul 02, 2019 2:28 pm

Re: DPI Specifics

Mon Jan 13, 2020 7:16 pm

The original Saleae Logic was cloned as it is basically a Cypress EzUSB chip on a PCB and they're all over eBay and Amazon for under £10. They're fully supported by Sigrok so you can completely avoid the Saleae software if you prefer.

Those clone units max out at 24MHz though so you won't be able to actually capture the data but you should be able to see which GPIOs have a signal on. If you want to actually capture the data then you'd need something more expensive like a DSLogic Plus or splurge for a higher end Saleae Logic.

User avatar
HermannSW
Posts: 1874
Joined: Fri Jul 22, 2016 9:09 pm
Location: Eberbach, Germany
Contact: Website Twitter YouTube

Re: DPI Specifics

Mon Jan 13, 2020 7:53 pm

I have a 7" DPI display, and it is 1024×[email protected]:

Code: Select all

[email protected]:~ $ tail /boot/config.txt 
#dtoverlay=dpi24
#enable_dpi_lcd=1
#display_default_lcd=1
#dpi_group=2
#dpi_mode=87
#dpi_output_format=0x6f005
#hdmi_cvt 1024 600 60 6 0 0 0
#disable_overscan=1

disable_camera_led=3
[email protected]:~ $ 

100Msps will not suffice to capture the data (2 9bit words per pixel):

Code: Select all

$ echo $((1024*600*60*2))
73728000
$

A 400Msps logic analyzer should do, I have this 60$ DSLogic one and am happy with it:
https://www.aliexpress.com/wholesale?Se ... Logic+400M

https://forum.arduino.cc/index.php?topi ... msg3159785
Image
⇨https://stamm-wilbrandt.de/en/Raspberry_camera.html

https://github.com/Hermann-SW/Raspberry_v1_camera_global_external_shutter
https://stamm-wilbrandt.de/github_repo_i420toh264
https://github.com/Hermann-SW/fork-raspiraw
https://twitter.com/HermannSW

teux
Posts: 9
Joined: Fri Jan 10, 2020 11:51 pm

Re: DPI Specifics

Mon Jan 13, 2020 8:35 pm

Fantastic, thank you all for the info. I have one of the 24MHz clones on the way. Unless I'm mistaken I should be able to manually set the DPI timings with the below parameters to a slower clock and get it captured. My display is only 160x128 and has no lower bound specified for the pixel clock frequency.

It should be able to handle 15-30 FPS just fine, and even if not, I image the DPI peripheral should still output to the pins.

I'll post an update when I get it figured out if anyone wants to use this display in the future. It really is a nice little oled for embedded systems.

Code: Select all

dpi_timings=<h_active_pixels> <h_sync_polarity> <h_front_porch> <h_sync_pulse> <h_back_porch> <v_active_lines> <v_sync_polarity> <v_front_porch> <v_sync_pulse> <v_back_porch> <v_sync_offset_a> <v_sync_offset_b> <pixel_rep> <frame_rate> <interlaced> <pixel_freq> <aspect_ratio>

teux
Posts: 9
Joined: Fri Jan 10, 2020 11:51 pm

Re: DPI Specifics

Sat Feb 15, 2020 2:20 am

Hello all, I'm back after finally getting some time to investigate. Unless anyone has any other info, I'm inclined to believe DPI_OUTPUT_FORMAT_9BIT_666 is a non-functioning mode, hence the lack of documentation. I'd love input from anyone at the foundation though, if at all possible.

Next step for me if this doesn't work is to pick a different display (which I really don't want to do) or get a small fpga to split up an 18 bit chunk into two 9 bit samples.

Starting with a known good 18 bit DPI configuration I hooked up my shiny new logic analyzer (thanks @trejan!) and looked at the first 16 pins of the DPI display (labeled in the screenshot). This was configured with a dpi_output_format of 0x6016, so using DPI_OUTPUT_FORMAT_18BIT_666_CFG2. I see data that indicates it's operating correctly.
18_bit_666.png
18_bit_666.png (33.86 KiB) Viewed 75 times

Changing dpi_output_mode to 0x6011 (DPI_OUTPUT_FORMAT_9BIT_666) the clocks and syncs seem to stay active, but no matter how I tweak the dpi_timings parameter I can't get anything to show up on the data pins (I checked D0 - D23):

9_bit_666.png
9_bit_666.png (33.59 KiB) Viewed 75 times

If we can confirm this is non functioning it might be nice to mention on the documentation page. :P

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