0
Test writing to SPI 4Mbit Flash memory
Posted by Chris
on
Saturday, October 31, 2009
After making up a board for our ScoreSure game score keeping device, and while waiting for the new QVGA LCD screens from Xing at NuElectronics we put together some code to try reading/writing to the new AT45DB041D 4Mbit flash memory.
As this will be a major part of the ScoreSure v2.0 device, we had to put a bit of thought into it.
The Flash memory organises data into sectors, blocks and pages and supports FAT file systems. It was very tempting to use this - to store bitmap images as JPEGs so that data can be easily dropped onto the device - but decoding images on the PIC so that they can be displayed one pixel at at time would take up a large part of the program space in the mcu. We decided in the end to use a relatively simple storage format, and use a header byte to tell the PIC which method to use to decode the image data.
For example, data could be stored in a palletised sort-of-gif format (albeit slightly different as GIF images need to be licenced!).An alternative method might be RLE (run length encoded) image formats - ideas for images with large blocks of colour. We may yet discover another (simple) way of compressing image data (JPEG is far too complicated to achieve decoding on a PIC) so the first byte of any image "file" stored in Flash memory will be a marker to tell the PIC how to decode it. This should give us plenty of flexibility to use different image storage methods.
The fastest way to get data in and out of the flash memory is serially - set a memory location, then clock the data in one byte after another. The PIC will be running at 20Mhz, and the Flash memory supports clocking data as this speed, so getting images out of RAM should be almost instantaneous.
Our first test will be to retrieve data for a bitmap 320x240 pixels wide.
We will do something simple like flash an LED on at the start of data retrieval, then off once all data has been dragged out. This should give us an idea about how long it would take to retrieve the image data for a full screen, full colour image.
Because we expect our images to be less than 320x240 and to use some form of compression for storing them, this test will give us absolute worst-case scenario values to work from....
As this will be a major part of the ScoreSure v2.0 device, we had to put a bit of thought into it.
The Flash memory organises data into sectors, blocks and pages and supports FAT file systems. It was very tempting to use this - to store bitmap images as JPEGs so that data can be easily dropped onto the device - but decoding images on the PIC so that they can be displayed one pixel at at time would take up a large part of the program space in the mcu. We decided in the end to use a relatively simple storage format, and use a header byte to tell the PIC which method to use to decode the image data.
For example, data could be stored in a palletised sort-of-gif format (albeit slightly different as GIF images need to be licenced!).An alternative method might be RLE (run length encoded) image formats - ideas for images with large blocks of colour. We may yet discover another (simple) way of compressing image data (JPEG is far too complicated to achieve decoding on a PIC) so the first byte of any image "file" stored in Flash memory will be a marker to tell the PIC how to decode it. This should give us plenty of flexibility to use different image storage methods.
The fastest way to get data in and out of the flash memory is serially - set a memory location, then clock the data in one byte after another. The PIC will be running at 20Mhz, and the Flash memory supports clocking data as this speed, so getting images out of RAM should be almost instantaneous.
Our first test will be to retrieve data for a bitmap 320x240 pixels wide.
We will do something simple like flash an LED on at the start of data retrieval, then off once all data has been dragged out. This should give us an idea about how long it would take to retrieve the image data for a full screen, full colour image.
Because we expect our images to be less than 320x240 and to use some form of compression for storing them, this test will give us absolute worst-case scenario values to work from....
Posts
Post a Comment