因为最近新坑（RP）的原因终于是有机会来点了点这个屏幕。讲一讲这个屏幕和其它之前遇到过的屏幕不一样的地方。首先屏幕是FSTN但是却是负高压。这两者本身并不冲突，只是通常而言FSTN的屏幕出现晚于STN，倾向于使用正高压而非负高压。其次是这个屏幕的扫描和行锁存分别有两个信号控制，一个为S，另外一个为CPL，目前并不清楚区别。再次是这个屏幕有一个叫CPG的信号，每一行会脉冲四次，第二次脉冲紧接着第一次，而第三次和第四次则是相隔较远。经测试该信号与PWM灰度有关，如调节第三次脉冲的位置即可调节较浅一级灰度的深度。向前会变淡，而向后会变浓。第四次脉冲则是控制较深灰度的深度。如果两个脉冲的位置不变而行长度增长，同样也会使两个灰度变淡。

刷新方法的话，这里采用MCU软件刷新。软件刷新目前的代码可以达到约153Hz的刷新率，那么为了节约电力大约有以下三种方案：

• 基准：MCU持续刷新
• 场待机：MCU刷完每一场后WFI待机，保持垂直刷新率85Hz。这种做法的问题在于MCU刷完待机期间屏幕也不显示内容，相当于占空比增加，为了达到同样亮度需要提高驱动电压，可能会带来额外的功耗开销。
• 行待机：MCU刷完每一行后WFI待机，保持水平刷新率13.6kHz，垂直刷新率85Hz。

在当前的硬件下测试结果如下：

• 基准：125mW
• 场待机：117mW
• 行待机：106mW

基本信息

• 类型：单色点阵STN
• 模式：FSTN Reflective
• 分辨率：320x320
• 灰度：2bpp
• 驱动器：不详
• 尺寸：2.6"
• 背光：无

啊 CCD味（玄学现场？

Specifications

• CPU：MCIMX6Y2DVM05AB（528MHz，Cortex A7）
• RAM：H5TQ2G63GFR（256MB，DDR3）
• Flash：H27U4G8F2D（512MB，3.3V）
• PMIC：PF1550
• LCD：GPM1006（320xRGBx240，Serial-RGB，ILI9322B）
• TSC：GT9288

Boot Mode

The following test points are present on the PCB:

• BT0L - Boot Mode 0 Low
• BT0H - Boot Mode 0 High
• BT1L - Boot Mode 1 Low
• BT1H - Boot Mode 1 High

Circuits nearby: (front side)

GND  T1H  T1H  GND
10K  10K   0R   NC
TMOD 3V3  T1L  T1L

GND  T0H  T0H  GND
4K7   NC   NC   NC
TCK  3V3  T0L  T1L

To enter USB DFU mode:

• Remove the 10K resistor between T1H and 3V3
• Solder a 10K resistor between T0H and 3V3
• Solder a 0R resistor between T0H and T0L (not sure if necessary)

There should be (lot of) other possible ways to change the bootmode or force it to fallback to the DFU mode.

Note: It is technically not a USB DFU (Device Firmware Upgrade) mode as it does not utilize the standard DFU protocol. It uses the i.MX Serial Download Protocol. I call it DFU as this is a more common term for such things.

I promised that there would be an update about the USB, here it is. This update would only talk about the USB 2.0 Host on the Pano Logic G1 devices with ISP1760 USB host controller, so it is probably not applicapable to other platforms. The goal here is to write a set of RTL and software stack, so it is possible to use USB HID joystick/ gamepad and USB mass storage devices on the Pano G1. Speed would not be the concern here.

Hardware Connections

On the Pano G1, an USB 2.0 high-speed host controller (Phillips ISP1760) is connected to the FPGA via 16-bit parallel memory bus. To mitigate one of the controller’s errata, an USB high speed hub (SMSC USB2513) is connected to one of the downstream port of the controller, and all user accessible ports are connected to the USB hub.

Overall Architecture

Though it might be possible to write a FSM to implement some basics of the USB host protocol stack, it is just not very practical. (Device side might be more practical, though). The solution I have here is to continue use the PicoRV32 soft-core processor on the FPGA. The host controller would be mapped to PicoRV32’s memory space as MMIO, then software driver and protocol stack can run on the PicoRV32. When needed, certain outputs can be achieved by using MMIO GPIO (for example, output the currently pressed keys). Hopefully, debugging software would be much easier than debugging hardware.

Generally, there would be several layers. The bottom part is called as the HCD (Host Controller Driver), which is specific to particular hardware, like the controller chip being used. Then it comes the HD (Host Driver), this is the part handles device enumeration and USB Hub communication, this layer is no longer specific to the platform. Higher than that is the class driver, as name suggests this is specific to a device class, for example, HID class or audio class. The driver might be generic to the whole class, or it might just support one of few specific USB devices. Higher than that, usually it is operating system, or in our case, user application.

In conclusion, there are 5 things I need to do:

1. Write the RTL to interface ISP1760 with PicoRV32
2. Port or write the HCD for ISP1760
3. Port some appropriate host driver over
4. Port or write the class driver for HID gamepad and mass storage devices
5. Write some application code to use the driver

Let’s discuss all these parts.

前言

MIPI-DSI接口因为需要更少的IO数量，能够提供连接器体积和布线难度上的一些优势，而被广泛应用于手机和手表屏幕上。显然作为一个点屏爱好者我也不可能忽略这种常见的屏幕接口，只是之前一直没有机会亲自研究一番，这次借着VerilogBoy的机会也算是大致了解了一下。考虑到MIPI为私有接口，对于其具体的描述在网上并不多，这里就具体介绍一下我对MIPI DSI的了解。需要注意的是，文中所有内容均基于互联网上可以找到的文档编写，并不可能完整描述MIPI DSI标准，甚至可能存在偏差或错误。本文仅供需要调试MIPI屏幕的工程师或业余爱好者入门参考。

基本概念

需要知道的是，MIPI DSI仍然只是一种用于连接屏幕的接口，而不是连接显示器的接口。前者常见的例子如DBI（包括8/16位并口和SPI）、DPI（也称为TTL，RGB和PixelBus等）和LVDS（也称为FlatLink），而后者常见的例子如VGA、DVI、HDMI和DP。前者的特点就是，通常驱动是和屏幕具体参数相关的，不同的屏幕需要不同的驱动程序。而后者的特点是，通常驱动是通用的，显示器可以通过DDC/CI或其它方式将相关的参数（如EDID）传输给驱动，驱动根据得到的信息产生需要的信号。通常来说，前者多用于嵌入式场景。不过现在后者中也出现了eDP专用于嵌入式，也许在以后能代替掉一部分现有的DSI使用场景。本文还是只讨论DSI。既然这么分类了，也就很明确，DSI也是一种不同屏幕不同驱动的接口，“DSI”其实大部分只是对于物理层和传输层的定义，具体的屏幕操作其实更往上还是以前DBI和DPI那一套。不如说，DSI其实就是把DBI和DPI打了一个包，让他们能共享几对差分线一起传输。以下所有讨论的内容仅考虑从主机到屏幕的单向传输。

低功耗模式与高速模式

DSI的物理层传输有两种模式，一种是1.2V CMOS电平的低功耗单端（LP）模式，另外一种是高速差分（HS）模式。在单端模式下，时钟线并不被使用，D0+和D0-用于传输数据和时钟，最大速度为10Mbps，其它的数据线不被使用。在差分模式下，时钟线用于传输差分时钟，最多可以有四对数据线用于传输数据，最大速度为每对数据线1Gbps。

屏幕上电后默认情况下数据线和时钟线都处于LP模式下（CLK+/CLK-均为高电平）。在LP模式下时钟线可以使用如下的系列进入HS模式：