1. Home
  2. Electronics Design
  3. Need help regarding flash memory options

Need help regarding flash memory options

I have an embedded application where I want to add up to 1GByte of non-volatile memory. The first product offering will require 256MByte but I need room to expand. The whole assembly must be extremely small in size.

My first thought was to use NAND flash. However, the micro I must use does not have an external memory interface. As far as I know this rules out NAND flash.

The micro does have a SPI buss. I tried looking for serial memories designed to communicate over the SPI buss. The problem is, the largest memory I can find is 64Mbit (8MByte). I would have to add numerous devices on the SPI buss to obtain the memory density I require. This is not an option.

I recently found that SD Flash cards can communicate over a SPI buss in the SPI/MMC mode. I realize I could simply place a card reader slot on the board and add a SD memory card. However, I see this approach adding un-necessary cost. I would like to manufacture quite a few of these devices. I wish to keep cost down by any means possible. I tried searching for design information regarding what is inside a SD memory card but come up with nothing. My thought is that I would buy whatever chip/chipset that is on the card and place this directly on my board. This would save the cost of the plastic case and circuit board inside a SD flash card. It would also save me the cost of the card reader slot. However, days of searching google has not yeilded the information I need.

Do you have any ideas where I might start my search? Are the contents of a SD flash card proprietary or does someone sell the chip/chipset? Is a SD flash card simply a NAND flash cell plus some memory controller? Can you think of a better option? Any help you could offer would be deeply appreciated.

Gerb

Reply to
Ge0rge Marutz
Loading thread data ...

It's been a while since I've looked but check the NAND flash specs -- they don't have a "normal" memory interface; what they have requires 11 lines or so (8 data & command, a few control lines). You'll have to bit-bang it anyway, so you don't have to feel bad about the lack of a "real" interface.

They'll require software to talk to -- they're more like disks in that they'll ship with bad sectors and it's up to you to format. Furthermore they expect you to implement error correcting codes, but when I was looking there weren't any white papers (at least not in English) on how to do it.

For the "chipset" a small PIC, AVR, or 8051 variant with SPI, a few GPIO lines, and some code ought to reduce the problem to mere software :).

--

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com
Reply to
Tim Wescott

It it really feasible to bit bang this interface? Talk about putting the programmer through living hell...

Do you have any leads on a small, inexpensive, microcontroller that has a SPI port and hardware based SD memory controller? I've come across a few with a hardware controller but they were not economical options. IMO the more software overhead I can eliminate the better.

Gerb

Reply to
Ge0rge Marutz

If you think bit-banging that interface is a living hell you've led a protected life! It looks like it couldn't be easier, to me.

Now, dealing with the formatting and error correction issues would take some work, but nothing that's not fairly direct, I don't think.

No, I don't know of someone who makes a pre-programmed processor, or one with a hardware interface. Might be a good cottage-industry product, though.

--

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com
Reply to
Tim Wescott

It's more like byte-banging multiword accesses.

What you want is a micro with some general purpose I/O pins... maybe 12 or so, 8 of which could be shared with another function (since they'd be validated by the remaining ones that you'd use for control signals).

Reply to
cs_posting

The micro I am using has many available port pins that could be used for data/control. It's just that writing the memory interface sounds kind of scarey. As a hardware engineer I want to give the programmer something he can work with and feel comfortable about. I'll have to address "byte-banging multiword accesses" with him. It is quite possible he will not have a clue on how to do this. He's a great PC level programmer but I'm not sure about embedded. I'd hate to throw in a ton of confusion by having to perform memory read/write management.

Ge0rge

Gerb

Reply to
Ge0rge Marutz

The micro I am using has many available port pins that could be used for data/control. It's just that writing the memory interface sounds kind of scarey. As a hardware engineer I want to give the programmer something he can work with and feel comfortable about. I'll have to address "byte-banging multiword accesses" with him. It is quite possible he will not have a clue on how to do this. He's a great PC level programmer but I'm not sure about embedded. I'd hate to throw in a ton of confusion by having to perform memory read/write management.

Ge0rge

Gerb

Reply to
Ge0rge Marutz

If he chokes on this he'll never manage embedded stuff. I would put the level of difficulty of actually talking to the flash chip in the same class as getting an SPI interface working correctly.

And since when have hardware engineers succeeded by looking out for the poor bastards who have to make their hardware actually work?

--

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com
Reply to
Tim Wescott

I'm not concerned about actually communicating with the chip. I'm confident this can be done to some extent. I'm more concerned about how fast this can be done and the CPU time I'd be using to do it.

I'd like to read/write at 12Mbit/s (limit of full speed USB). I'm not sure this can be accomplished if all memory management is done through software alone.

Then there is writing data and keeping proper buss timing, learning how to format the memory and treat it like a disk, and of course error correction (which is not well documented). This seems like a lot of extra effort.

Can anyone think of an application note that might go over how to do all this? Some other source?

All may not be lost. Let me run this by you. It might be about the only computationally intensive task the CPU might have to do is memory management. Data will enter the application via an on board USB controller. An on chip DMA controller will send the data directly to a hardware based signal processor. From there the DMA controller can route data back out the USB port or write it to RAM. Hypothetically, all without a significant amount of the microcontroller CPU's intervention. The microcontrollers CPU can then fetch data from the RAM and use its memory management routine to write to flash.

What do you think?

Gerb

Reply to
Ge0rge Marutz

Without an external memory interface you don't actually have any choice !

It's not really very hard.

Graham

Reply to
Pooh Bear

Hmm, topic seemed to have died off.

Say I was to try bit banging using general purpose I/O. Are there certain types of ports that would work better than others for this application?

Gerb

Reply to
Ge0rge Marutz

Ones where you can control individual bits would be a good idea.

How many "types" of ports do you know of?

Good Luck! Rich

Reply to
Rich Grise

What's reading this? Why not simply plug the incoming USB thing into the PC, and eliminate all the hardware.

Reply to
Ian Stirling

Huh?

Gerb

Reply to
Ge0rge Marutz

Perhaps I oversimplified the question. I was thinking more along the lines of:

Timer counter SPI ports USART ports Ethernet TWI PWM channels etc...

These features are unused. Could I hack features of these interfaces to make external NAND flash memory control less software intensive?

Gerb

Reply to
Ge0rge Marutz

Well, I don't really know that much about flash, but if it's serial, I'm pretty sure you'd use the SPI port. If it's parallel, you'd have to dedicate as many plain old ordinary outputs as you need for address and data.

Have you already decided on a flash chip, or are you still doing research to find a suitable one?

Thanks, Rich

Reply to
Rich Grise

The description as I understood it was USB-input-device (webcam/...) -> device -> USB input to a PC.

Why not simply remove the device from the middle, and plug it straight into the PC?

Reply to
Ian Stirling

No. Access to the flash device is not really all that software intensive - at least not much more so than talking to a serial one over SPI. Parallel access off general purpose ports is going to require something like three or four port accesses per read or write. Access to SPI is going to require one to set it up, but then you have to wait for it to finish.

That's just communicating with the chip. To accomplish anything meaningful like reading data, or writing it, or erasing blocks, or mapping around errors, is going to require about the same amount of work either way. Regardless if the interface is SPI or parallel, you are going to have to issue commands to the chip to do each of these things - command, address, data, in some cases a whole block of data without more command or address.

Parallel access is no harder to code than getting the SPI ports on an unfamiliar micro up and running. It's likely faster at run time, or at least not appreciably slower. And the complexities of software to do anything usefull with the flash are the same, because the command sets and underlying NAND cell behaviour are pretty similar regardless of the physical interface used.

If you really want to avoid all of this, buy an embedded O/S with flash routines.

Reply to
cs_posting

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.