Duo 256M: VDP i80 pins?

Duo
1

I’m investigating using the second core on Duo 256M to control small displays using ILI9341, ST7789, and similar display controllers via an 8-bit 8080-style parallel bus (8 data bits, cs, wr, rd, d/c). I’m only a hobbyist on the electronic side, but I do put all my designs under CC0-1.0 / Public Domain. I do have a full-stack software development background over three decades, mostly low-level and systems integration stuff in Linux, so the software side is not a problem for me. I’m most often over at EEVblog forums discussing similar things.

(I use these devices to add non-technical human readable displays to Linux-based appliances like routers, switches, NASes, security camera servers, and so on. The idea is to let nontechnical users (like elders) know if the service/appliance is working or if there is a problem, with no way of messing anything up via the display interface. These are always connected to a Linux host via USB. Because of the use case, SPI is simply not fast enough, and I haven’t yet found a MIPI DSI panel I’d like without it costing over twice my preferred EastRising/BuyDisplay 2.4"/2.8"/3.2" ISP displays.)

The SG2002 TRM says the VDP supports “MCU i80” output, with 8 data pins and 4 control pins. I know the data pins are VO_D[0] through VO_D[7], but I cannot find any information on what the control pins might be. The TRM does refer to these control pins (for example on page 476: wrx, rdx, cdx, csx), but there is no mention how these are connected. I suspect they could be VO_D[28] through VO_D[31], or selectable (within VO_D outputs) using an undocumented register, but if anyone knows for sure, I’d be very grateful.

I can bit-bang the parallel bus on Duo and Duo 256M using XGPIOA[22]…XGPIOA[29] (GP18, GP16, GP17, GP19, GP21, GP20, GP0, GP1), and the control pins on XGPIOA[14]…XGPIOA[17] (GP14, GP15, GP12, GP13), and on Duo S using XGPIOC[16]…XGPIOC[23] by desoldering C36 and C37 for XGPIOC[22] and XGPIOC[23] access, thus disabling audio input.
As I understand it, only Duo 256M and Duo S (SG2002 and SG2000) might support this parallel video output.

Obviously, Duo Module 01 would be optimal for me, but I cannot find a single no-Wifi, no-eMMC version sold anywhere. :cry:

Voltage level translation is not a problem, because I’ll need a larger carrier PCB anyway for the connections to the display. (I prefer 74LXC1T45/74LXC2T45/74LXC8T245 translators with Schmitt trigger inputs, but might use e.g. TXU0104 for the control signals.)

I do have ordered a Duo, a Duo 256M, and a Duo S, so I can try and find out for myself, but that will be slow going.

1 Like
2

MCU i80 is used ?

sorry for this “kind of answer”

In my “spare” time I almost read the “video layer” from MIPS CSI trough VDP (or whatever name this is) to video output, which is awfull to read.

For MIPI DSI, there is some pincontrol config “hidden “somewhere in the code”, also for MIPS CSI and some BT609 or so interface.

For i80 interface they might be also some pincontrol config. I said “might”, because I diddn’t found this configuration, maybe they use default configuration from the SoC, wriiten in the TRM,

The whole pincontrol is poorly written down in upstram linux, only the driver exists, but without the definition.

For the “i80 protocol” itself, inside the vo (video out) driver a so called layer, to drive the “i80 pins”.

But I didn’t dig deeper in this area, because look at the “first” question.

Mabye they are more, but I currently (as always) too layzy to look into my notes.

So I have some questions, to understand i80

  • is this a “charater” only interface, or can transter “binary” picture data
  • how many colors ? I saw in the code some LUT (look up tabele), I don’t know the purpose
  • size of the display in pixel, fixed or variable
1 Like
3

My favourite small display is EastRising/BuyDisplay ER-TFT028A2-4, a 2.8” (57.6mm × 43.2mm active area) display with a 320×200-pixel ISP panel (and thus wide viewing angles), with or without a I2C-connected capacitive touch panel. It uses a very common Ilitek ILI9341 display controller. One can use these displays via SPI, 8080 or 6800 command/data parallel bus (they only differ by bit/pin order), or RGB interface. I recommend you take a look at ILI9341 datasheet to understand how it can be controlled using these different interfaces. Again, these controllers contain an internal framebuffer with 18-bit color for each pixel, although reading data back is slow. Writing via SPI is slow (slower than display update, so you’ll get tearing or can only update a smaller region of the display at a time without tearing), but the parallel data bus is fast. ST7789 and variants are very similar, with only minor differences (in initialization, updates use basically the same commands).

Simply put, a 8080 (or 6800) bus has 8, 9, 15, 16, 18, or 24 parallel data bits and four control signals: WRX, RDX, CDX (aka D/CX), and CSX. CSX is an active low select, so when high, all the other signals are ignored. WRX is the active-low write strobe signal, idling high. Host sets the data lines on falling edge of WRX, and displays read the data lines on the rising edge of WRX. RDX is the active-low read strobe signal, idling high. Displays set the data lines (slightly after) falling edge of RDX, and the host reads the data lines on rising edge of RDX. D/CX = CDX is a command/data selector. When it is low when WRX rises, the first eight data lines define a command; otherwise it is data (or command parameter). It is not usually used with RDX.

RGB, or what the SG2002 TRM calls “TTL”, on the other hand is a real-time parallel data bus, and bypasses any video buffer on the display. It uses the same number of data and control pins, but the control pins are pixel clock, display enable, vsync, and hsync. It is essentially a digital version of a video signal as used in old analog computer displays.

If I’ve understood the stuff from SG2002 TRM and the Duo buildroot SDK middleware, CV1800B/SG2000/SG2002 supports both 8080- and RGB parallel output with 8 data bits, with a programmable clock. RGB is limited to 3 or four clocks per pixel, so basically RGB666 and RGB888 modes are supported (and only requires ten signals: clock, vsync, hsync, de, d2, d3, d4, d5, d6, d7). “i80” should support RGB565 (two clocks per pixel), RGB666 and RGB888 (three clocks per pixel), and requires twelve signals (since commands do need the two least significant data bits, even if they are always zero for the color components).

Depending on the controller, I’d say sizes up to 480×480 pixels at RGB565, and up to 400×400 or 320×480 pixels at RGB666 or RGB888, are useful with an 8080 bus. Any larger, and MIPI DSI is a better choice.

As it is, the TRM does not fully document the VDP DISP registers. The registers that define the pins used for 8080/”i80” or RGB/”TTL” output are not defined, nor are the related clock control (only MIPI TX clock control is documented). Obviously emphasis was on getting MIPI stuff working, which saddens me, because these cheaper small displays are much more suited for appliances.

As the Buildroot SDK middleware shows, all this should work on Duos (CV1800B, SG2000, SG2002), with minor differences (pin selection, RGB888 support). However, I do intend to use the second core for all this (and more), so the middleware kernel modules are of no use to me as-is.

1 Like
4

Now I getting some “picture” about I80 …

For the “protocol” on i80, I will look later on.

I know for RGB “interface” some SoC or LCD support from RGB565 up to RGB888 i.e. sunxi aka Allwinner.

The TRM documents “most” of the VDP register. Registers for RGB or i80 interface are defined

For full docomention, with horrible source code, I use

https://github.com/sipeed/LicheeRV-Nano-Build.git

Be warned, they use “global” functions for vi, vpss, vo, mipi rx, mipi tx and other parts of the SoC.Also they are some “hidden” global io-register changes, i.e for pinmux or clocking or other stuff.

MIPI DSI

It is possible to use 4 lanes, with SG2000, for SG2002 only 3 lanes are “exported” via pincontrol, maybe they are deticated pins for the 4th line. I don’t know, because I didn’t create a proper pinctrl cfg.

The whole MIlkv or LicheeRV uses ioctl, thus the “userpace” middleẃare, or whatever the name it is, is needed.

1 Like