首先复读去年的话：
大致都是一些无聊的日常？因为确实算不上是个年终总结，所以也没有必要在标题中冒充是篇总结。
至于为什么要写，因为去年写了所以今年也写一写好了。
但是关于2019年，首先放四个大字：摸得透彻。
去年一月的话，已经是在波士顿了，当时因为时差的原因晚上睡不着，就坐在床上用X201s写去年的流水账。起床之后，因为刚刚搬到波士顿住，家里还什么都没有，就赶紧出门办了张地铁卡，然后去超市买了些吃的。随后就是开始了全新的工作日常。
嗯……去掉教程这个月只写了个流水账，毕竟啥都还没开始嘛（大概）
去年的时候还在纠结选哪张照片才能代表一月，然而今年……其实根本没有拍多少照片所以没有什么好找的（尴尬）。以及今年所有的照片都是从手机拍摄的照片里面选的，iPhone SE弱弱摄像头也就只有这样了。照片是公司下班之后在公司门口拍的，所以其实画面下方是停着的车子。初入公司，感觉其实工作意外的顺利呢。
因为最近新坑（RP）的原因终于是有机会来点了点这个屏幕。讲一讲这个屏幕和其它之前遇到过的屏幕不一样的地方。首先屏幕是FSTN但是却是负高压。这两者本身并不冲突，只是通常而言FSTN的屏幕出现晚于STN，倾向于使用正高压而非负高压。其次是这个屏幕的扫描和行锁存分别有两个信号控制，一个为S，另外一个为CPL，目前并不清楚区别。再次是这个屏幕有一个叫CPG的信号，每一行会脉冲四次，第二次脉冲紧接着第一次，而第三次和第四次则是相隔较远。经测试该信号与PWM灰度有关，如调节第三次脉冲的位置即可调节较浅一级灰度的深度。向前会变淡，而向后会变浓。第四次脉冲则是控制较深灰度的深度。如果两个脉冲的位置不变而行长度增长，同样也会使两个灰度变淡。
刷新方法的话，这里采用MCU软件刷新。软件刷新目前的代码可以达到约153Hz的刷新率，那么为了节约电力大约有以下三种方案：
在当前的硬件下测试结果如下：
啊 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.