啊 CCD味（玄学现场？
啊 CCD味（玄学现场？
The following test points are present on the PCB:
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:
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.
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.
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:
Let’s discuss all these parts.
嗯……受邀去做了一下演讲，懒得翻译了，就发生肉了，中式英语大家都听得懂吧（笑） 大致介绍了一下我设计GameBoy掌机项目的一些经历。完整的项目相关的东西可以见这里：VerilogBoy项目页。
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模式：