Using DiskOnChip in the 8051 microcontroller application system (1)

Single chip microcomputer STM32L151CCU6

1206RGB (single)

Crystal patch 2520 2.5*2.0MM 16MHZ 16.000MHZ 1.6V~3.6V universal OSC

Foreword

As the functions and performance of various 8051-compatible microcontrollers become stronger and stronger, the degree of intelligence and complexity of their application systems is also increasing. In some cases, the capacity requirements for non-volatile storage of data have far exceeded 64KB. To this end, the usual solution is to use NOR-type flash memory and use segmented memory access technology to extend the addressing space of the 8051. This method increases the complexity of the hardware and software design and is less reliable and costly. DiskOnChip (DOC for short) is a large-capacity solid-state memory series based on NAND-type flash memory. It integrates a large-capacity NAND Flash Memory and a NFDC (Nand Flash Disk Controller) that operates on Flash in a single package. Its storage capacity ranges from 8MB up to 1GB. All capacities are in a unified DIP32 package with fully compatible pinouts and a consistent external hardware interface. If it can be directly applied to the 8051 microcontroller system, it will not only expand the application range of DiskOnChip, but also be an ideal large-capacity, non-volatile data storage solution for such systems. To this end, this paper discusses the feasibility and software and hardware implementation of DiskOnChip in the 8051 microcontroller application system.

Hardware connection

Since the external hardware interface of the DOC is very simple, the DOC 2000 is taken as an example. It is similar to a standard SRAM, and only takes up 8 KB of address space in the system, and does not exceed the addressing range of the 8051 MCU 64 KB. Therefore, the 8051 microcontroller can be easily connected directly to DOC 2000 of various capacities without expanding its addressing range.

In the actual system, the model and manufacturer of the selected 8051 MCU are not limited, but must have an external data bus, an address bus, and read and write signal lines to connect with the DOC 2000. Figure 1 is a schematic diagram of Atmel's 8051-compatible microcontroller AT89C55 and a DOC 2000 connection example, where DOC 2000 occupies the address range of 8000H~9FFFH in the data storage space of AT89C55.

Software porting

This is the focus of this article. M-Systems organizes the DOC internal Flash storage media in the form of "partitions." There are two types of partitions: binary partitions and file partitions. Binary partitions, also known as BDK (Boot Developers Kit) partitions, can be used to store binary images (Image) and other binary data for embedded operating systems, but do not support bad block management and Wear-Leveling techniques. The application cannot access the data in the BDK partition as a file, and can only read/write the BDK partition through the BDK API provided by M-Systems. The BDK API is provided in C source code and can be used by the bootloader of the embedded system. The file partition is also called the TrueFFS (True Flash File System) partition, which allows the application to access the disk file through the file system of the operating system. Read/write DOC, and use bad block management, wear leveling and other means to achieve higher storage reliability and longer flash life. TrueFFS is pure software technology and is implemented by drivers. M-Systems provides the TrueFFS driver for Windows, WinCE, Linux, VxWorks and other common operating systems, and provides the TrueFFS SDK in C source code for developers to port TrueFFS to a new operating system or no operation. The environment of the system.

The 8051 MCU similarly stores and accesses data in the DOC in two cases, one in binary form and the other in file form. The TrueFFS SDK from M-Systems implements a simplified file system, FAT-Lite, that can be ported to an operating system-free environment. However, the program memory and data memory of the 8051 MCU are only 64 KB at most, and the TrueFFS SDK is more complicated and difficult to port to the 8051. Therefore, for the 8051 system, it is more suitable to access the DOC 2000 directly in binary form. In order to program access to the DOC 2000 on the 8051 microcontroller, you must understand the technical details of the DOC 2000 software interface. As mentioned above, DOC 2000 occupies 8KB of address space in the system. The microprocessor accesses the DOC internal control register and transfers data through the 8KB window. However, M-Systems does not disclose the definition of the register and the operation flow. The technical details, so can only be transplanted from the BDK API source code provided by M-Systems to the application developer. Since the newer version of the BDK API uses a more complex software architecture, it is more difficult to port to the 8051. Therefore, this article uses the earlier version of BDK 1.25. This version can only support DOC 2000 and DOC Millennium (8MB) below 128MB. However, it can meet the capacity requirements of the 8051 application system for non-volatile memory in most cases.

BDK 1.25 provides developers with a set of API functions for reading/writing BDK partitions. The source code is written in ANSI C and is conditionally compiled to suit various hardware platforms and operating systems. It is very portable. This article has designed an API function library for the 8051 MCU with reference to these source code. It is written in Keil C51 and provides the functions of reading, writing and erasing the basic memory cells (blocks and pages) of DOC 2000 or DOC Millennium. The 8051 MCU is used to read and write DOC 2000 or DOC Millennium in binary form.

Due to space limitations, this article does not detail the specific porting process. Here are just a few of the main issues to consider when porting:

* The source code of the BDK API defaults to X86 processors and DOS environments. To do this, you need to modify the relevant conditional compilation options to make it suitable for the 8051 system;

* Minimize and customize the source code. Some data types have been modified to reduce RAM usage, simplify some data structures, rewrite some of the code, and remove unnecessary conditional compilation and redundant code;