Design and Implementation of a PMP System Based on Embedded Linux
2026-04-06 02:05:26··#1
PMP System Introduction Portable multimedia players (PMPs), commonly known as MP4 players, have become a new hot consumer product after MP3 players. The main advantages of PMPs are: portability, direct playback of high-quality audio/video files; image browsing; and use as a portable hard drive and digital banking device; in addition, they also offer FM radio and gaming functions. PMP players not only need to be limited in size, but more importantly, they require a video compression technology with higher compression efficiency and image quality, as well as related codec chips. This article introduces the software and hardware design of this PMP system, focusing on the software design. This PMP system solution has now entered the mass production stage. PMP System Hardware Design Currently, most PMPs use a CPU paired with a DSP in their core architecture. The DSP handles encoding/decoding, while the CPU handles file management, access, and control of interfaces and peripheral components. Furthermore, it is necessary to consider the integration of components such as hard drives, memory cards, and LCD displays, as well as compatibility with external USB interfaces and control buttons. To meet these requirements, the PMP design needs to incorporate a built-in video codec chip for converting between analog and digital signals. In addition, the design also needs to consider: the bus used to connect the video decoder and the DSP; the driving circuit for the LCD display; and the communication between the IDE interface and the hard drive controller chip. [ALIGN=CENTER] Figure 1 Structure diagram of DM320[/ALIGN] The overall system solution is based on the TI DM320. The DM320 is a dual-CPU processor that supports video encoding/decoding. It is specifically designed for multimedia devices, directly supporting video input/output and easily expanding audio input/output. It supports USB, SDRAM, FLASH, and CF/SD/MMC/MS/MS Pro interfaces. The structure diagram of the DM320 is shown in Figure 1. The TI DM320 integrates the C5409 and ARM926, that is, the CPU and DSP are integrated into the DM320 core. The chip uses 32MB or 64MB of SDRAM and 4MB of flash memory for loading and storing the operating system. The DM320 integrates an LCD controller and a USB 2.0 OTG interface controller, while also allowing CCIR-656 format signals to be transmitted between the video decoding chip and the DM320 via a bus. Since the NTSC/PAL encoder is also integrated, composite video output can be directly performed. [ALIGN=CENTER] Figure 2 Overall framework diagram of the DM320 hardware system[/ALIGN] Furthermore, the DM320 supports the connection of CCD/CMOS image sensors, making it easier for future PMPs to incorporate DSC, DV, etc. Regarding memory card compatibility, in addition to the currently mainstream CF, SD, and MMC cards, it also supports Memory Stick. In addition, this chip provides two RS232 serial ports and one JTAG interface, supporting a wider range of peripheral devices. The overall framework diagram of the DM320 hardware system is shown in Figure 2. [ALIGN=CENTER] Figure 3 PMP Software Design Block Diagram[/ALIGN] PMP System Software Design Because it needs to balance high-quality audio and video effects, various peripherals, and limited system resources, the design of the PMP software system becomes relatively complex. The system design divides the software into a three-layer structure, as shown in Figure 3. The bottom layer of the system is the operating system layer, which includes the bootloader, mainly responsible for booting the system from FLASH, displaying the logo, and booting the OS. Embedded Linux mainly includes a Linux operating system suitable for running on the TI DM320, as well as drivers for various peripheral devices. The second layer is the CODEC and MMI kernel layer. The MMI kernel includes the third-layer main GUI and various framework structures and data structures that various applications depend on, such as window management and timer management. The CODEC part includes audio encoding and decoding programs (mainly implemented by ARM) and image encoding and decoding programs (mainly implemented by DSP). The top layer is the main GUI and various applications. Applications include: FileManager (for browsing files in storage), VideoPlayer (for playing video files), AudioPlayer (for playing audio files), ImageViewer (for browsing images), FM (for radio), Games (for games), and Resumes (for replaying audio/video files). Embedded Linux Operating System This system uses a modified Arm-Linux kernel downloaded from the Internet, and drivers for related peripheral devices have been written to make it a suitable operating system environment for TI DM320 development. It is called embedded because its operating system does not run on a regular PC, but is embedded in a non-PC-based electronic device. Regarding kernel modifications, the Kconfig file is used to configure the kernel content you want to load. For example, typing `make menuconfig` on the console will bring up the kernel configuration window, where you can select options. Selecting [*] means compiling this content into the kernel, and selecting [M] means compiling this content as a module. Linux supports dynamically loading kernel modules, even after the operating system has been running for a while. Since the DM320 framework is not included in the kernel, we need to add it. First, we need to add the DM320 configuration options to `./arch/arm/Kconfig` in the kernel directory. This will ensure that the DM320 framework is visible when executing `make menuconfig` to configure the kernel. The modifications are shown below: `choice prompt "ARM system type" default ARCH_DM320_20 file://` This is the default framework when configuring an ARM system. `source "arch/arm/mach-dm320-20/Kconfig"` This imports the configuration options under the DM320 framework. Simultaneously, remove other CPU frameworks. For example: `#source "arch/arm/mach-clps711x/Kconfig" #source "arch/arm/mach-integrator/Kconfig"` Here, "#" indicates that this line is commented out. Finally, we need to select the kernel configuration options that are useful for DM320 development. For example: `source "drivers/char/Kconfig" if (!ARCH_DM320_20) source "sound/Kconfig" endif` // Select to develop a driver for character devices, without needing sound support. Because we need to compile CODEC into the kernel, we also need to add configuration options to support CODEC: `source "codecs/modules/Kconfig"` Similarly, if we want to add a new peripheral device, we also need to add the corresponding content to the Kconfig file. For example, to add a driver for a Samsung 4-inch TFT LCD, we can modify the `./drivers/char/Kconfig` file and add the following: `config DM320_SAMSUNG_4_LCD tristate "DM320 SAMSUNG 4.0 inch 16:9 TFT LCD" depends on ARCH_DM320_20 && BOARD_400H default y help This driver provides support for SAMSUNG 4.0' 16:9 TFT LCD for DM320`. Here, `config DM320_SAMSUNG_4_LCD` indicates the addition of a new configuration entry. Once this configuration option is selected, it will be defined as `#define CONFIG_DM320_SAMSUNG_4_LCD 1` in `./include/Linux/autoconf.h`. This allows us to use `CONFIG_DM320_SAMSUNG_4_LCD` for specific selections throughout the kernel source tree. In the tristate "DM320 SAMSUNG 4.0 inch 16:9 TFT LCD", the content within the quotation marks is the prompt text appearing in the configuration options. "Tristate" indicates three states, meaning that in addition to selecting [*] and [ ], you can also select [M], indicating that the current content should be compiled as a module. "depends on ARCH_DM320_20 && BOARD_400H" indicates that if ARCH_DM320_20 was selected when configuring the platform framework and BOARD_400H was selected when choosing the model, we can see this configuration option for the Samsung 4-inch TFT LCD. "default y" indicates that this driver is compiled into the kernel by default. The "help" content is what you see when configuring the kernel using the help option. Makefile Simply put, the Makefile is used for project configuration and management. To compile and link Linux to finally generate an executable kernel image, the Makefile is indispensable. In this PMP design and development, you only need to add the peripheral driver module to the corresponding kernel source tree to complete the modification of the Makefile. Taking adding a Samsung 4-inch TFT LCD driver as an example, you only need to add the following content to ./drivers/char/Makefile: obj-$(CONFIG_DM320_SAMSUNG_4_LCD)+= dm320_lcd_samsung4.o Two Essential Drivers and Issues to Note in PMP System Design An LCD driver is essential in a PMP device. In designing an LCD driver, the main tasks are to select the appropriate clock source, divider, and clock polarity. For example, in the DM320, the clock controller has the following external inputs: PCLK, SYSCLK, MXI, and M48XI. Except for M48XI, all others use a 27MHz external crystal oscillator. The LCD clock frequency DCLK in this system is determined by VENC (Video Encoder Clock), which can be determined by dividing the system's PLL. Therefore, you must first select the appropriate clock source and divider, and then set the clock polarity by configuring the VENC register. The FrameBuffer driver abstracts video memory into a device, making reading and writing to this device equivalent to directly manipulating video memory. This operation is abstract and unified. Users don't need to worry about the physical location of video memory, paging mechanisms, or other specific details; these are handled by the FrameBuffer device driver. The source files for FrameBuffer are located in the Linux/drivers/video/ directory. All abstract device files, such as fbcon.c, and various graphics card driver-related source files are placed in this directory, such as the FrameBuffer source file dm320fb.c for the DM320. In the source file, we need to set the screen's length, width, and the number of bits per pixel, as well as some settings related to the DM320 OSD (On-Screen Display) registers. Due to the large amount of content involved, it will not be elaborated here. Conclusion The product designed with this PMP solution has entered the mass production stage. After extensive user testing, the entire design has been proven to be feasible. Furthermore, its design concept has certain reference value for other similar products, such as in-vehicle GPS. References: 1. Jonathan Corbet, Alessandro Rubini, and Greg Kroah-Hartman, LINUX DEVICE DRIVERS. O'REILLY, Southeast University Press (reprinted edition), 1st edition, June 2005. 2. Texas Instruments, TMS320DM320 CPU and Peripherals Vol-1a. 3. Tan Lei, Smartphone System Design Based on Embedded LINUX, Electronic Technology Application, No. 12, 2004. 4. Ni Jili, Linux Kernel Analysis and Programming, Electronic Industry Press, 1st printing, September 2005.