Clever way of dealing with Dataflash page size = 264

Log in or register to post comments
Go To Last Post
13 posts / 0 new
Author
Message
sgomes
sgomes's picture
Level: Resident
Joined: Wed. Feb 19, 2003
Posts: 920 View posts
#1
Posted by sgomes: Sun. Jan 29, 2006 - 12:15 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Does anyone have a clever way of dealing with dataflash's odd page size? I'm finding myself trying to convert between (absolute byte address) and (page address + byte offset).

Is there an easy way to convert between the two other than something like:
x=(absolute address)PAGE_SIZE;
page=floor(x);
byte=mod((absolute address),PAGE_SIZE);

UGLY!!!! There has GOT to be a better way. My brain is mush right now and I just can't see it. I guess I could just never use (absolute address) anywhere and always work in terms of (page + offset) but that doesn't seem very clever either.

Any ideas from those out there that have used Atmel's DataFlash?

Go electric!
Happy electric car owner / builder

Tags:

AVR Microcontrollers, megaAVR and tinyAVR
Top
abcminiuser
abcminiuser's picture
Level: Raving Lunatic
Joined: Fri. Jan 23, 2004
Posts: 9856 View posts
Location: Melbourne, Australia
Posted by abcminiuser: Sun. Jan 29, 2006 - 03:36 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I use that method; I made a routine to take a 16-bit address, and then divide by PAGE_SIZE for the page address and mod by PAGE_SIZE for the byte adress. You could probably use the div command and the div_t structure in stdlib.h to neaten it up.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

Top
JimW52
JimW52's picture
Level: Hangaround
Joined: Tue. Jun 1, 2004
Posts: 329 View posts
Location: Brisbane, Australia
Posted by JimW52: Sun. Jan 29, 2006 - 06:15 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Use 256 byte page size and ignore the extra bytes. You could of course use the extra bytes for a checksum. or whatever.

Jim

Your message here - reasonable rates.

Top
Alan69
Alan69's picture
Level: Rookie
Joined: Wed. Nov 9, 2005
Posts: 33 View posts
Posted by Alan69: Sun. Jan 29, 2006 - 08:39 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

JimW52 wrote:
Use 256 byte page size and ignore the extra bytes. You could of course use the extra bytes for a checksum. or whatever.

Jim

Yep, likely what it's there for..

If there isn't a huge speed penalty for accessing different blocks, you could just have 32 blocks of 256, and a hidden extra block of 256 that is the upper 5 bits for the block, and the 8 extra bytes per block on the lower 3 bits..

Top
sgomes
sgomes's picture
Level: Resident
Joined: Wed. Feb 19, 2003
Posts: 920 View posts
Posted by sgomes: Sun. Jan 29, 2006 - 04:35 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I conscidered this idea however it makes the Continuous Array Read function very difficult. You have to skip eight bytes after every 256. And that assumes you start on a page boundary..if you don't well then you need to figure out where those eight bytes are in order to skip them! This doesn't seem easier!

Go electric!
Happy electric car owner / builder

Top
sgomes
sgomes's picture
Level: Resident
Joined: Wed. Feb 19, 2003
Posts: 920 View posts
Posted by sgomes: Sun. Jan 29, 2006 - 04:40 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I've been thinking about a way to do this without all the div and mod. Maybe there is a way to do it by dividing by 256 (>>8 ) then do something with the left over 8 bytes/page... if there is more than 33 of them, you're off by one page.... you see where I'm going. I'd just like to get the nasty math out of there. I'm doing all this work during a somewhat tight loop and I'd like it to be a bit less math intensive.

Good ideas though! keep 'em coming! I KNOW there are some clever people out there who have found a way! :)

Go electric!
Happy electric car owner / builder

Top
c_oflynn
c_oflynn's picture
Level: Raving Lunatic
Joined: Fri. Mar 23, 2001
Posts: 2013 View posts
Location: Halifax, NS
Posted by c_oflynn: Sun. Jan 29, 2006 - 08:06 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
Any ideas from those out there that have used Atmel's DataFlash?

Not a solution to the problem posted, but redesign your system to use the odd page sizes. Is there a specific reason you need to have both absolute addresses along with page + addresses?

I had everything start on a page boundry, so the absolute address *is* the page address. If your system deals with chunks of data that will work, otherwise it's not as elegent...

-Colin

VA3 YHZ - http://www.newae.com

Top
clawson
clawson's picture
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 97530 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
Posted by clawson: Mon. Jan 30, 2006 - 01:03 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

c_oflynn wrote:
I had everything start on a page boundry, so the absolute address *is* the page address. If your system deals with chunks of data that will work, otherwise it's not as elegent...

That's exactly what I did too. I want to hold 20 to 30 recorded sounds (ADPCM) each of which is anything from 20K to 100K but all I do in my simplistic "filing system" is take note of a page boundary where each starts. As one is received or recorded I then just stream it into 264/528 (depending on device size) pages. To play back I just look up its start page in the "directory" (this is a VERY simplistic file system!) and then start to do a "continuous array read" from that page onwards. The only "wastage" in all this is the fraction of a page at the end of each "file" that is maybe not totally filled. But working on page boundaries does mean I have no need for any /264 or /528 operations to find byte alighed start addresses for data objects.

Cliff

Top
sgomes
sgomes's picture
Level: Resident
Joined: Wed. Feb 19, 2003
Posts: 920 View posts
Posted by sgomes: Mon. Jan 30, 2006 - 02:19 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

That sounds pretty appealing Cliff. Correct me if I'm wrong but FAT16, FAT32, even NTFS all do a similar scheme! That's kinda why file size "grows" when you store it on your hard drive.

I'll give it a try. I'm storing images and audio files so the "continuous array read" is very nice to have.

I'm not giving up on finding a nice way to do this with shifts and addition/subtraction. Whenever I get stuck on a problem like this I always think about those guys back in the day that crammed a chess program into 8k for Atari. THERE IS ALWAYS A BETTER WAY!

Go electric!
Happy electric car owner / builder

Top
clawson
clawson's picture
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 97530 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
Posted by clawson: Mon. Jan 30, 2006 - 04:07 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

sgomes wrote:
That sounds pretty appealing Cliff. Correct me if I'm wrong but FAT16, FAT32, even NTFS all do a similar scheme! That's kinda why file size "grows" when you store it on your hard drive.

Yup it's very like it. For one thing drives tend to have 512 byte sectors so on average there's alswasy a 256byte wastage at the end of the file if files were stored as granular as per sector. However modern drives have so many sectors that its too many to index in a 16 bit (FAT) or 32 bit (FAT32) number so files are actually stored in things called "allocation units" and these are typically 8192, 16384 or 32768 bytes (quite a few sectors in fact!). So the wastage per file (assuming on average the last AU is half filled) is 4096, 8192 or 16384 bytes.

But files systems do this so they can easily locate the start of a file on a sector or allocation unit boundary and don't need to worry about wading part way into a sector or an AU.

When you think about it, when it comes time to erase/re-use some file space the last thing you'd want is a file starting half way through a sector used by another file as you'd then have to cope with just wiping half a sector or dataflash page!

Be thankful that the pages in these AT45s are actually so small (and hence very fine granularity). In Nand flash filing systems we've written in the past the eraseable sectors have been as large as 16K or even more so there is a very coarse granularity in the device

Cliff

Top
sgomes
sgomes's picture
Level: Resident
Joined: Wed. Feb 19, 2003
Posts: 920 View posts
Posted by sgomes: Mon. Jan 30, 2006 - 06:55 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ahhh the satisfaction of something well done.... :) Just finished changing the code over to start each file on a page boundary. Actually it turned out better to start 8bytes in fromt the boundary for reasons that are so obtuse I won't bore you with them. Yeah this is the way to do it. No more crazy dividing and all that.... neat! Thanks Cliff et al!

Go electric!
Happy electric car owner / builder

Top
Mikeharrison
Mikeharrison's picture
Level: Hangaround
Joined: Thu. Jul 26, 2001
Posts: 202 View posts
Posted by Mikeharrison: Mon. Jan 30, 2006 - 11:02 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

..or just use a more sensible, cheaper flash chip like the SGS-Thomson M25Pxx series...

Top
c_oflynn
c_oflynn's picture
Level: Raving Lunatic
Joined: Fri. Mar 23, 2001
Posts: 2013 View posts
Location: Halifax, NS
Posted by c_oflynn: Mon. Jan 30, 2006 - 11:20 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Though that device doesn't have the 2-SRAM buffers that I found critical in choosing DataFLASH in my application, in fact it doesn't seem to have any sort of user accesible SRAM buffer...

So better for a general-purpose flash, but doesn't have the speedy writes the DataFLASH can have.

Regards,

-Colin

VA3 YHZ - http://www.newae.com

Top