Interface design between OLED display module and AT91RM9200

OLED stands for Organic Light-Emitting Diode, which refers to the technology that organic semiconductor materials and luminescent materials can emit light and realize display under the drive of electric current. Compared with LCD, OLED has many advantages: ultra-light, ultra-thin (thickness can be less than 1 mm), high brightness, large viewing angle (up to 170°), light emitted by the pixel itself without the need for a backlight, low power consumption, fast response speed (about 1,000 times the speed of LCD), high clarity, low heat generation, excellent shock resistance, low manufacturing cost, and bendability. Therefore, OLED is more capable of displaying perfect videos, and with low power consumption, it can be used as a display screen for mobile phones, digital TVs and other products. It is recognized by the industry as the most promising next-generation display technology.

1 Characteristics of P13501 display module

The P13501 launched by Taiwan ReTron Corporation is a 128×64 dot matrix monochrome, character, and graphic display module. It has the following main features: blue luminous color; 128×64 dot matrix; built-in driver IC is SSD1303; contrast ratio is 500:1; viewing angle is 160°; interface is 6800 series parallel interface, 8-bit Intel 8080 series parallel interface and serial external interface; operating temperature is -20～+70℃.

2 Controller and structure block diagram of display module

OLED display screen P13501 mainly includes SSD1303 built-in controller and OLED display panel produced by Solomon Company in Taiwan.

The controller is an OLED driver chip integrating row driver, column driver and controller. The driver is designed for 132×64 dot matrix OLED graphic display, including row driver, column driver, current reference generator, contrast control, oscillator and several MCU interface modes. The operating logic voltage is 2.4 to 3.5 V; it has rich software functions, supports 4 color selections and 64-level control for each color, and its software contrast has 256-level control; the embedded 132×64-bit graphic dynamic random access memory (GDDRAM) provides row remapping, column remapping, vertical scrolling and partial display functions, making the driver suitable for a variety of OLED displays with different pixel sizes and colors. The

SSD1303 controller has two sets of timing circuits in the interface control circuit, and the corresponding settings of the timing adaptation circuit are used to meet different timing requirements. The setting ends of the timing adaptation circuit are BS1 and BS2, and its timing settings are listed in Table 1.

The structural block diagram of the module is shown in Figure 1.

3 Interface design between display module and AT91RM9200

The interface of SSD1303 includes data input buffer, data output latch, instruction register and decoder, busy state trigger and timing control circuit, etc. It has high-performance interface control circuit. The computer can access SSD1303 at any time without judging its current state. Since OLED adopts Intel 8080 timing, BS1 and BS2 are both connected to high level; and since there is no command/data selection line in AT91RM9200, one line PB10 in its general port PB is used as the command/data selection line of OLED. When PB1O is low level, it means that the data written to OLED is a command word; when it is high level, it means that the data written to OLED is a data word. OLED's 16-pin RES is the reset pin, which can be directly connected to the reset circuit of ARM, but in order to facilitate the reset control of OLED, another line PB11 is used as its reset control. The chip select signal USER1_CS of OLED is generated by 38 decoder decoding of NCS4 and address lines A25, A23, A22 of AT91RM9200. Its physical address is 0x52800000 after calculation. The interface circuit design of OLED and AT91RM9200 is shown in Figure 2. [page]

4 OLED driver programming

One of the functions of the operating system is to shield the particularity of the hardware from the user, so that the application has nothing to do with the underlying specific physical devices. The device driver is the bridge between the application and the specific hardware. Linux supports three types of hardware devices: character devices, block devices and network devices, and their writing methods are roughly the same. Among them, character devices and block devices can be accessed like files. The main difference between character devices and block devices is that every I/O operation of the application on the character device will be directly passed to the corresponding driver of the system kernel; while the operation of the application on the block device must be passed to the driver for processing indirectly through the system buffer management. Here, OLED belongs to the character device.

Usually, the character device provides a process control interface to the application, mainly including open, close (or release), read, write, ioctl, poll and mmap. Adding a character device driver to the system is actually adding corresponding code to the above operations. For character devices and block devices, the Linux kernel has unified these operations and defines them in the structure file_operations. For most character devices, only some of the operations need to be completed for the driver to work well.

As required, the OLED device driver only implements some device operations and declares its file_operations structure in a tokenized format, as follows:

oled_write is responsible for displaying the data to be displayed on the OLED screen; oled_ioctl is used to implement various control commands for the OLED; oled_open is responsible for opening the OLED display; oled_release is responsible for closing the OLED display. Here we mainly introduce the specific implementation of oled_write. Other implementations can refer to oled_write according to actual needs. The specific procedures for implementing oled_write are as follows:

5 Compilation of

driver program After the driver program is written, it needs to be compiled. There are generally two ways to compile the driver in the Linux operating system, namely static compilation and dynamic compilation. In static compilation, the driver program is directly compiled into the kernel and can be freely cut when configuring the kernel. Assuming that the driver program of P13501 is myoled.c, the specific operations to compile it statically into the kernel are as follows: [page]

① Copy myoled.c to the drivers/char directory and modify the drivers/char/Config.in file. Add the following code to it:
dep_tristate my oled support\' CONFIG_MY_OLED
$CONFIG_ARCH_AT91RM9200
The meaning is: as long as CONFIG_ARCH_AT91RM9200 is defined as y or m, when configuring the kernel (such as "make menuconfig"), the my oled support option will appear under the Character devices category, which corresponds to the definition of CONFIG_MY_OLED. In order to link the driver program to the kernel, CONFIG_MY_OLED should be defined as y.
② Add the following code to the Makefile in the drivers/char directory:
obj-$(CONFIG_MY_OLED)+=myoled．o
Makefile will compile and link the corresponding code according to obj-m and obj-y.
During dynamic compilation, the driver is compiled into a module, and then the device driver module is dynamically loaded and unloaded. By using the module loading method, the module can be repeatedly debugged and modified without restarting the system, which can conveniently and effectively debug the driver. In practice, in the initial stage of writing a driver, it is often compiled into a module, repeatedly loaded and unloaded, and the original code of the driver is modified until the entire driver meets the requirements, and then it is statically compiled into the kernel. During dynamic compilation
, the method is as follows:
/usr/local/arm/2.95.3/bin/arm-linux-gcc-O2-DMODULE-D__KERNEL__-I/home/sum/linux-2.4.19/include-c myoled．c
Here, it is assumed that the cross compiler path is: /usr/local/. The storage path of the kernel is: /home/sum/linux-2.4.19. If there is no error during compilation, the myoled.o file will be generated after completion. Copy it to a directory in the embedded system (for example: /home), and then it can be dynamically loaded:
insmod myoled.o
Generate device number:
mknod/dev/fftoled c 254 O
In this way, the driver of P13501 is dynamically loaded into the kernel, and the application can display output on the OLED.
The operation when the module is unloaded is as follows:
rmmod myoled
Repeated loading and unloading can complete the debugging of the OLED driver.

6 Conclusion

This paper introduces the interface circuit design of the OLED display module P13501 and AT91RM9200, as well as the writing, compilation and loading of the OLED driver under embedded Linux. The circuit and driver have been successfully applied to the display of system parameters in a control system with good results; with a simple matrix scanning keyboard, related parameter settings can also be performed. Due to the many characteristics of Linux and the many advantages of OLED display technology, I believe that their combination will have broad application prospects in consumer electronics, industrial control, and even all aspects of life.