teux
Posts: 5
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 318 times

aBUGSworstnightmare
Posts: 1573
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: 5
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: 1573
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: 7707
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: 5
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: 1093
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: 5
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: 1093
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: 1758
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: 5
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>

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