External Flash Interface

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

I'm gearing up for a project where I'm planning to give myself some elbow room by incorporating additional eeprom space by means of SPI. . .I'll be using the mega128 and I see hardware provisions for an external [parallel] memory interface. . . I believe that with the mega128 and my I/O requirements, I'll have more than enough pins to go the brute-force method of giving every data/address bit it's on line to the uC. . .my question is, are there any subtle concerns that are easy to overlook[trying to avoid landmines here]. . .

I'm interested in using the extended memory capability so that the uC handles memory management. . .it appears I'm limited to 64k flash

and that PORTA is the Address[lower byte] and Databits; PORTC is the upper Address byte and PORTG 0-2 are control bits.

. . .with everything mentioned above, what guidance would anybody be willing to share?

Has anybody successfully worked with atmel external flash? Did you use "DataFlash" or "Parallel Flash". . .

Any input would be much appreciated

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

Quote:
I'm interested in using the extended memory capability so that the uC handles memory management. . .it appears I'm limited to 64k flash

You realise that flash is going to be read-only on the ext-mem interface?

If you want to have writeable flash then AT45 Dataflash or an SD/MMC memory card on SPI is an easy way to do it. In fact (for large amounts of storage) SD/MMC is a really nice option and it's very easy to then share the data with a PC

You could "bit bang" NAND or even NOR flash on mega128 pins but the devices with wear levelling/bad block remapping intelligent controllers and simple interfaces (ie SD/MMC) take a lot of the responsibility off your hands.

I guess the first question you need to ask yourself is what capacity are you looking for? (and what speeds of access?)

Cliff

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

This is my effort to answer my first question by first realizing the limits when interfacing with external flash capability of the chip. . .looking at the datasheet, 64k appears to be the max if I were to go the route of having extmem defined. . .looking at atmel parallel chips available, I noticed 70ns 512k flash available, and I'd figure that 448k would go unused, but at ~$2 that isn't a concern.

I can see myself able to complete this project without the use of external eeprom or flash, but then it would be too easy, lol. . .I'm using this as an opportunity to shoot myself in the foot. . .meanwhile I create threads asking how to not shoot myself in the foot...go figure

at any rate. . .I'm interested in using the hardware external flash capability if it delegates the memory management to the uC whereas if I were to use spi flash, I'd have to figure out how the ram management would be handled[variable space would be in the flash, and not in the uC]. . .seems like a bigger scope, but possibly a better lesson to be learned. . .[that's almost a question]

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

I guess you decided to overlook Cliff's response. The parallel external memory interface is for SRAM ONLY

I have used it off and on and that's all it can do. If you are looking into external flash/eeprom, then use spi/microwire/I2C.

Jim

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

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

Yes but the extmem is really aimed at adding 64K (or banked, more than that) of SRAM not NOR flash. Is this memory for pre-programed 'const' data or are you using it for non volatile data back up? I think you might want to rethink the design but, like I say, the first consderations are how much data and how often/fast does it need to be written?

Cliff

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

ohHHhh, well, that could have gotten lame quick. . .I'm looking for [non] volatile data space. . .I think I have an incorrect understanding. . .with additional[external] sram, I can manipulate more variables are runtime correct?[ie larger buffers etc]

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

Even if you whack an SRAM on the ext-mem interface you, the programmer, have to manually do something to ensure it gets used. (apart from anything else the init code needs to enable the ext-mem interface before it might be used). In various C compilers there are various ways to get any/al of (a) stack, (b) .data/.bss and (c) malloc() heap located into the ext-mem. You'll need to read the manual for your compiler to work out how to do that. Or, in C, you can just make use of an absolutely addressed pointer.

But if it's NV storage you are looking for then an AT45 or an SC/MMC card might be a lot easier way to add storage and forget ext-mem all together.

Again, how big a data storage is required and what speed of access does it need?

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

I'll be using Avrstudio. . .my previous designs[which this new design will be strongly based on] were fine with just the onboard flash and I expect updates to be - at worse - every iteration of a loop[ie: often]. . .I wouldn't say adding sram is needed; I'm simply implementing it now when I don't need it to get ahead of the curve so I stress less when it's absolutely necessary[worse case scenario is I don't populate the part if interfacing begins to slow me down]. . .*shrugs*

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

The SRAM I plan to use[purchased] appears to have a pin for write only[active low]. . .when high, it's in read mode.

I notice the atMega has pins for both read and write. . .Any reason why just connecting the write pin wouldn't be sufficient? It's either this or using discretes for account for the two pins from the atMega and output the logic to the one pin on the SRAM. . .or I can just shop for different sram. . .hmmm?

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

No, you would need some external logic to convert the two signals correctly.

If you could let me know where in the world you live, I could send you a few 32k SRAMS I have in stock that interface to the extmem interface.

Also,
You still have not answered how much memory you plan to address

Jim

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

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

sending me chips isn't necessary, though I would appreciate a part number:-)

. . .size isn't a concern, at the moment, any size sram will work just as long as it works