LPC4088 QuickStart Board - Software Information
Libraries
EA Library
The LPC4088 QuickStart Board contains a number of on-board peripherals which doesn't have a corresponding driver implementation in the mbed SDK. Embedded Artists has developed a separate library with drivers for those peripherals as well as other related components.
- SDRAM initialization
- QSPI File System for the 8 MB QSPI flash (see section "File System on QSPI Flash" below for a more detailed description of this file system).
- MCI File System for MMC/SD card interface
- LCD Controller interface for the LPC4088 on-chip LCD controller
- Driver for Embedded Artists 4.3 inch and 7 inch displays (LCD Board)
- Driver for Texas Instruments TSC2046 touch screen controller. This touch screen is mounted on the 4.3 inch and 7 inch displays.
- A light-weight graphical library based on Adafruit's GFX.
Import libraryEALib
A library with drivers for different peripherals on the LPC4088 QuickStart Board or related add-on boards.
Import programapp_gfx
Example using the GFX graphical library, EaLcdBoard, TSC2046 touch screen and SDRAM initialization
Import programapp_qspi_format
Example showing how to create a file system on the QSPI flash.
Import programapp_qspi_memstick
The purpose of this application is to allow easy manipulation of the QSPI file system from a PC
USB Device
The mbed official USB device library has been ported to the LPC4088 QuickStart Board. There are several USB device class implementations available. Please visit the USB device page in the handbook for more details.
The micro-B connector used for USB device is shown in the picture below.
USB Host
The mbed SDK contains a USB host library. Currently this library is NOT supported by the LPC4088 QuickStart Board. The reason is that the implementation mix the use of main SRAM (where stack and heap are located) and peripheral SRAM. On the LPC1768 microcontroller this is okay since the USB Host block has access to both these memory regions. On the LPC4088 microcontroller main SRAM is however not accessible by the USB host block.
The USB host implementation must be modified to only use one memory region in order for it to work on the LPC4088 microcontroller. This is currently being investigated, but there is no date when it is planned to be fixed.
emWin GUI Library
Segger's graphical library emWin can be used free of charge with NXP's microcontrollers. More information about how to use this library can be found on the emWin page.
Memory Model
External SDRAM
The LPC4088 has a SDRAM that must be initialized before use:
main.cpp
#include "mbed.h" #include "sdram.h" int main() { if (sdram_init()) { printf("Failed to initialized SDRAM\n"); } }
By default the SDRAM is attached to the heap and thus allowing malloc()
, realloc()
and free()
functions to use it, see the example below.
main.cpp
#include "mbed.h" #include "sdram.h" int main (void) { void* a, b, c, d, e; if (sdram_init() == 1) { printf("Failed to initialize SDRAM\n"); return 1; } a = malloc( 1024); // will be from internal RAM b = malloc( 1024*1024); // will be from SDRAM as it is too large c = malloc(15*1024*1024); // will be from SDRAM d = malloc(15*1024*1024); // will be from SDRAM e = malloc(15*1024*1024); // will fail as there is not enough heap left // deallocation goes here... }
Troubleshooting!
The code that hands over the SDRAM to the heap is very toolchain dependant and if it causes you problem then comment out the two functions at the top of the sdram.cpp file in EALib.
QSPI
The LPC4088 has an SPI Flash Interface (SPIFI) allowing external serial flash memories to be connected with low performance penalties. A driver API included in on-chip ROM handles setup, programming and erasure and after initializing the SPIFI driver, the flash content is accessible as normal memory (in the 0x28000000..0x28ffffff memory range) using byte, halfword, and word accesses by the processor and/or DMA.Programming (i.e. writing data to the flash) is supported for up to 256 bytes at a time (which is the size of a "page" in the flash). Programming means that a bit can either be left at 0, or programmed from 1 to 0. Changing bits from 0 to 1 requires an erase operation.While bits can be individually programmed from 1 to 0, erasing bits from 0 to 1 must be done in larger chunks (manufacturer dependant but typically 4Kbyte to 64KByte at a time).
The SPIFI driver handles flash memories connected via standard SPI as well as Dual I/O and Quad I/O with Quad I/O SPI (or QSPI for short) being the fastest. See the User's Manual for LPC4088 for a list of compatible memories.
The LPC4088 Quick Start Board has 8 MByte of QSPI FLASH from Winbond. This particular memory allows programming of up to 256 bytes at a time and erasing is done in 4KByte blocks.
Information
To make the use of QSPI flash as easy as possible the linker scripts for the online compiler automatically places read-only parts of the code in QSPI FLASH if the space in the internal flash is too small. As for normal compiling, the online compiler will generate one binary even if both internal flash and QSPI FLASH is used. The mbed HDK is responsible for writing the binary to the correct memory addresses so no special user action is needed when flashing.
It is possible to execute code directly from the QSPI FLASH and/or put a file system on it (see next section below).
File System on QSPI Flash
One way to utilize the 8MByte of QSPI FLASH on the LPC4088 QuickStart Board is to place a file system on it. The QSPIFileSystem is using mbed's FileSystemLike interface making using it is as simple as:
main.cpp
#include "mbed.h" #include "QSPIFileSystem.h" QSPIFileSystem qspifs("qspi"); int main() { if (!qspifs.isformatted()) { qspifs.format(); } FILE* fh = fopen("/qspi/hello.txt", "w"); if (fh != NULL) { fwrite("Hello World!", 12, 1, fh); fclose(fh); } }
The file system can be formatted to a specific size in increments of 1MByte and will allways be placed at the top of the address range. For the 8 MByte memory on the LPC4088 QuickStart Board this means:
0x28000000 0x28800000 |------|------|------|------|------|------|------|------| qspifs.format(1) | available for program | FS | |------|------|------|------|------|------|------|------| |------|------|------|------|------|------|------|------| qspifs.format(2) | available for program | FileSystem | |------|------|------|------|------|------|------|------| |------|------|------|------|------|------|------|------| qspifs.format(7) | PROG | FileSystem | |------|------|------|------|------|------|------|------| |------|------|------|------|------|------|------|------| qspifs.format(8) | FileSystem | |------|------|------|------|------|------|------|------|
The file system must be placed at the top of the memory because the linker scripts places your program at the bottom of the memory (if needed).
Limitations
The QSPIFileSystem has some limitations:
- The file system uses at least one block (same size as the erase block) per file. For the 8 MByte Winbond flash which has 4 KByte erase blocks this limits the number of files to ca 2000.
- The file system doesn't support empty directories. The reason for this is that directories are never stored on the file system - instead each file is stored with it's absolute path.
- The file system doesn't store date/time information and the attributes (hidden/system/read only).
Background
The QSPIFileSystem class is a subclass of FileSystemLike and not the FatFileSystem as a FAT file system has some disadvantages:
- A FAT file system stores it's FAT table (i.e. the table of content) near the start of the file system which for for the memory layout shown above would mean that the FAT table could be located in eight different locations depending on the size of the file system. The QSPIFileSystem stores it's table of content at the end of the file system, which means it is always at the top of the memory regardless of how large the file system is.
- When a FAT file system is formatted it will write zeroes in all the writable area. As described above in the SPIFI description this is not ideal as it requires an erase operation each time something should be stored. The QSPIFileSystem formats the writable area only when needed and always as 0xff, reducing the number of times a block must be erased.
- In a FAT file system the FAT table (i.e. the table of content) is located in a fixed place and it must be modified each time a file is added/modified/removed or its size is increased. This causes a lot of writing/erasing of the exact same sector(s) over and over again. The QSPIFileSystem has a small "pool" of table of contents to use which reduces the wear.
- In a FAT file system the content of a file might be spread out in multiple locations on the file system (i.e. it gets fragmented). The QSPIFileSystem always stores the entire file in a sequence. This means that if you know where a file is located it is possible to access the files content (read only) direcly in memory without copying.
A FAT file system has some features that the QSPIFileSystem hasn't:
- A FAT file system treats a folder as a file with special properties. Each folder is stored even if it is empty. The QSPIFileSystem handles this differently. A file is stored with its absolute name (i.e. including folders) but a folder is never stored in the file system. It is still possible to open a folder and to read it's files and sub folders as with a FAT file system. The big drawback to this is that the QSPIFileSystem cannot have empty folders. If a folder becomes empty it will disappear. If you absolutely need to have an empty folder (e.g. to show where the user should put his files) then you have to put a readme file or something else in it.
- A FAT file system supports additional properties for each file: access rights (read only, hidden, system), creation date and last modified date. None of those properties are available in the QSPIFileSystem. This is however no big issue as the FileSystemLike interface doesn't expose them anyway.
- A FAT file system can easily be exposed as a USB Memory Stick - QSPIFileSystem requires an a workaround to achieve it (see app_qspi_memstick below)
- The FAT file system can cause fragmentation as described above, but that is also one of it's strengths. If you first fill a 8 MByte file system with eight 1 MByte files and then remove every other one you will get a file system that has 4 MByte free, divided into four 1 MByte blocks. If you then attempt to create a 4 MByte file the FAT file system will split it into the four free blocks and is able to on comple the operation The QSPIFileSystem cannot handle this as each file must be stored in sequence and there is no 4 MByte block free so the operation will fail.
Tools
The QSPIFileSystem can be manipulated using one of the two sample apps or by directly downloading one of the prepared image files.
Import programapp_qspi_format
Example showing how to create a file system on the QSPI flash.
Import programapp_qspi_memstick
The purpose of this application is to allow easy manipulation of the QSPI file system from a PC
Name | File System Size |
---|---|
qspifs_erase.fs1 | 1 MByte |
qspifs_erase.fs2 | 2 MByte |
qspifs_erase.fs3 | 3 MByte |
qspifs_erase.fs4 | 4 MByte |
qspifs_erase.fs5 | 5 MByte |
qspifs_erase.fs6 | 6 MByte |
qspifs_erase.fs7 | 7 MByte |
qspifs_erase.fs8 | 8 MByte |
By flashing one of these images you will get an empty file system of the desired size in MBytes as indicated by the last number in the file extension, i.e. qspifs_erase.fs3 will create a 3MByte file system leaving the first 5MBytes of the QSPI free for program download.
The *.fsX files can be drag-n-dropped on the MBED drive in the same way as the *.bin files are. A *.fsX file will not overwrite the program stored in internal flash (if any).
Please log in to post comments.