AT45DBxxx, to binary or not to binary?

Go To Last Post
3 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I always asked myself why the pages from the mentioned DataFlash chips, are not(standard) binary sized, but have eight more bytes every 256 bytes?

Is it a physical/production side effect, or are those bytes meant for storing some "˜file system' data, what's the use for it?

I'm using these chips in combination with a FAT file system, for storing logged data, and thus use/need "˜binary' ordered page/buffer byte addresses. Now as people know, for those that use these chips, that to obtain a "˜binary' page and buffer byte addresses, some left and right shifting is needed on the page and buffer byte address bits, to gain access to the correct bytes. Not really a big deal, but for one, the extra bytes are not used anyway, second, one cannot use the "˜continuous read' commands in a binary way, thus when reading sequential data, each time a page has been read, one must stop reading, send a new address command(and shifting address bits again), and start reading again, a lot of overhead when reading big sequential files on one DF chip.

Fortunately, there is the possibility to order the page/buffer addresses in a "˜binary' way(although, once programmed for "˜binary' addresses, you cannot go back), then no(special) bit shifting is needed to obtain the correct page/buffer byte address, and one can use the "˜continuous read' commands in a "˜binary' way(which speeds up the transfers a lot, Dean could use this in he's LUFA projects, when using only one DF chip), it also simplifies the coding.

This is what I've done, programmed the DataFlash for binary use, the only drawback is that I lose , in my case(AT45DB642D), 256KB of flash space.

So what's the reason why these DataFlash chips use, standard, non binary sized pages?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

I always asked myself why the pages from the mentioned DataFlash chips, are not(standard) binary sized, but have eight more bytes every 256 bytes?

Is it a physical/production side effect, or are those bytes meant for storing some ‘file system’ data, what’s the use for it?


The extra bytes are there for the file system implementor to implement an ECC. This is true on things like SD/MMC cards (and indeed anything using Nand where bits can "wear out" and stick at 1). With SD/MMC you don't see this because the ARM chip on the card is doing ECC and bad block remapping behind your back. In the case of the AT45 you don't have this luxury - it's a "raw" Nand array and it's up to you to implement things like wear levelling and bad block remapping.

In this day and age - when SD/MMC comes free in a box of cereal I don't see much point in taking on this headache yourself, just add an SD/MMC connector (or even direct connection to the card) into your design and use the luxury of economies of scale that has driven SD/MMC to lower prices than AT45 even with it's added intelligent controller doing all the work for you.

BTW later models of AT45 have a one-time burn option to switch sector sizes from 264/528 to 256/512. Alternatively, if you are very clever, you could spread some data over the additional 8/16 bytes per sector. Or you could use it for the intended purpose of an ECC Hamming code: http://en.wikipedia.org/wiki/Err... - note however that the calcultion of ECC at sector write time is pretty compute intensive (yet another reason to hand this job off to the ARM on an SD/MMC card!)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks clawson, I knew there was a good reason for it.

clawson wrote:
BTW later models of AT45 have a one-time burn option to switch sector sizes from 264/528 to 256/512.

Well yes, that’s what I’m doing, but I’m using the AT45DB642D, which has 1024/1056 bytes per page.
clawson wrote:
Alternatively, if you are very clever, you could spread some data over the additional 8/16 bytes per sector. Or you could use it for the intended purpose of an ECC Hamming code: http://en.wikipedia.org/wiki/Err... - note however that the calcultion of ECC at sector write time is pretty compute intensive (yet another reason to hand this job off to the ARM on an SD/MMC card!)

Unfortunately, that is not possible in my case, and the reason for me to use the DF in a binary fashion, having an as fast as possible DF interface(using one chip only). It’s for an upgrade of an existing project, where data logging has been added. In this project I’m reading 5980 bytes of raw data every second from the uart at 57600 baud with CRC check, converting it to user selected units, formatted and then displaying parts of this data at 10 hz on the screen(OLED). Having also alarm set point checking on user selected data, which is displayed on the screen or on a led bar(using the same SPI lines as the DataFlash), and saving a maximum of 800 bytes of that same data, every second, is nearing the limits of the AVR running at 8Mhz. It works now, but I’m giving priority to the data collection and logging, the displaying part has the lowest priority.

This is where an RTOS could come in handy, but the overhead of it would slow up things again.

Will have to alert the users for eventual corrupted data, although the logging is done in a circular way, so the flash should wear out evenly on the logging part.

Anyway, for my new projects, I’m using an CORTEX-M3 now, and will use SD/MMC cards for logging in the future.