Some notes during my own RT board bring up process.

QSPI XIP

QSPI XIP is the recommended way to run the code. Critical sections could be loaded to ITCM if needed. Will compare the performance difference later.

NXP AN12183 gives a good overview about the XIP boot flow, and provided several configurations for other Flash devices. However, the provided configurations were wrong. When using these configurations, the processor would stuck in the Boot ROM area (0x20000) after the image is loaded. The best approach is still to read the datasheet for the specific device used (including all suffix in the model number). Here is my configuration for W25Q32JV:

// Configuration for W25Q32
const flexspi_nor_config_t qspiflash_config = {
    .memConfig =
        {
            .tag                = FLEXSPI_CFG_BLK_TAG,
            .version            = FLEXSPI_CFG_BLK_VERSION,
            .readSampleClkSrc   = kFlexSPIReadSampleClk_LoopbackFromSckPad,
            .csHoldTime         = 3u,
            .csSetupTime        = 3u,
            .columnAddressWidth = 0u,
            .configCmdEnable    = 0u,
            .controllerMiscOption = 0u,
            .deviceType = kFlexSpiDeviceType_SerialNOR,
            .sflashPadType = kSerialFlash_4Pads,
            .serialClkFreq = kFlexSpiSerialClk_30MHz,
            .lutCustomSeqEnable = 0u,
            .sflashA1Size  = 4u * 1024u * 1024u,
            .lookupTable =
                {
                    // Read LUTs
                    FLEXSPI_LUT_SEQ(CMD_SDR, FLEXSPI_1PAD, 0xEB, RADDR_SDR, FLEXSPI_4PAD, 0x18),
                    FLEXSPI_LUT_SEQ(MODE8_SDR, FLEXSPI_4PAD, 0xFF, DUMMY_SDR, FLEXSPI_4PAD, 0x04),
                    FLEXSPI_LUT_SEQ(READ_SDR, FLEXSPI_4PAD, 0x04, STOP, 0, 0),
                },
        },
    .pageSize           = 256u,
    .sectorSize         = 4u * 1024u,
    .blockSize          = 64u * 1024u,
    .isUniformBlockSize = false,
};

The read LUT should match the timing diagram given in the datasheet:

The RADDR (row address) is 24 bits (0x18), there is a 8-bit Mode (MODE8), needs to be 0xFx, followed by 4 dummy cycles (DUMMY), finally it reads data.

Note: my board design didn't leave the DQS pad floating, so I had to loopback from SCK. For optimal performance, leave the DQS pad floating, and use DQS loopback.

Introduction

I recently bought few Plannar EL640.480-AM series panels. They are monochrome 10.4" 640x480 TFEL panels with an STN LCD interface. It is similar to DPI (sometimes called RGB), the screen is timed with HVSync signals, and needs to be continuously refreshed. But, as a monochrome screen, the pixel is 1bpp, so the data bus transmits multiple pixels at a time. These screens are also dual-scan: there are two "raster beams" at the same time, one refresh from the top of the screen, the other one refreshes from the middle of the screen. They are supposed to be refreshed at 120 Hz.

This creates some interesting challenges: It expects to be driving with an STN LCD controller. However, where can I find one?

• There used to be dedicated graphics controllers such as NM128 or CT65530 that could drive STN LCDs directly. But they have been long obsolete.
• ARM SoCs from the early 2000s typically has an LCD controller that is capable of driving STN LCDs. However many of these SoCs are also being deprecated or obsolete.
• There used to display controller chips that could convert VGA into STN LCD signals. But I don't know any specific models. I suspect they are also being deprecated.

If not using dedicated hardware (and I am not too interested in buying one anyway), there are several alternative ways to drive it:

• Use a really fast microcontroller with a large SRAM to Bit-Bang the GPIO to generate the video signal.
• Use a CPLD/FPGA to generate the timing

I have used both methods before. The first method:

• https://www.zephray.me/post/anxin_320160

The second method:

• https://hackaday.io/project/160738-cstron-cstn-lcd-monitor/log/160613-cstron-monitor-powered-by-an-ancient-cstn-screen

I am going to use the microcontroller way this time again. But this time I am going to use the RP2040, which has a very powerful IO engine called PIO. We will see how it would help us with driving the screen and offload the CPU core.

Claimer: The methods described here are provided as-is. Use at your own risk.

I am new to RP2040, this is the first time I use the PIO. So the program provided here is likely not optimal.

Note: Translated with www.DeepL.com/Translator (free version)

Introduction

Xserve is Apple's long-discontinued line of servers, powered by the Mac OS X Server operating system. After Xserve was discontinued, OS X Server slowly became just an app. In 2019 Apple introduced a new rackmount Mac Pro, which can also be used as a rackmount server. But the price is not something I can justify spending for fun. The other thing is that with ARM Mac releases coming soon, the x86-64 based Mac Pro will be obsolete in few years. It may not make sense to spend a lot of money on a Mac Pro at this point in time. On the other hand, the old Xserve is already very cheap, with similar performance and price to the contemporaneous Dell PowerEdge R610. Unlike the 2009 Mac Pro, which for some reason still costs a lot now. For this reason as a Mac homelab or for desktop use, the last generation Xserve can be considered a good choice. The following are the main specs of the last Xserve.

Xserve 3,1 (Xserve 2009)

• CPU: 2x Intel Xeon E/X/W5500 series
• RAM: 12x DDR3 REG ECC (Up to 192GB)
• HDD: 3x SAS/SATA
• GFX: nVIDIA GeForce GT120 (MXM-A upgradable)

Xserve in 2020

Here are some concerns when using Xserve in home settings:

As a server

• Too few hard drive bays and SATA hard drive capacity limited to 1TB

As a workstation

• The performance of the 5500 series of processors is seriously outdated
• Severe fan noise
• Weak GPU

Common issues

• No longer supports the latest macOS, if you need to use macOS

This article is about fan noise only.

注：本文内容主要在LPC5528上测试，同样适用于55S2x和55S6x，不确定将来推出的其它系列是否也会同样适用。

高速USB

高速USB需要外部晶振才能使用，外部晶振频率可以在12\16\19.2\20\24\30\32MHz之间选择。由于官方开发板使用的是16MHz的晶振，所有例程和库也是使用16MHz的。如果使用了其它频率的晶振，可以通过设置PLL_SIC寄存器修改。官方库中设置的代码位于fsl_clock.c中：

USBPHY->PLL_SIC     = (USBPHY->PLL_SIC & ~USBPHY_PLL_SIC_PLL_DIV_SEL(0x7)) | USBPHY_PLL_SIC_PLL_DIV_SEL(0x06);

其中0x06即为PLL分频器设定值。以下为可选的值：

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.