Any Atmel CPU can integrate with a Data flash memory with FAT?

Started by anht...@yahoo.com December 7, 2009
I would like to use an Atmel CPU with a Flash memory (ie: DataFlash AT45DB161D) that some how using FAT16/32 to be able to put files to & from the Flash memory. Is it available? If YES, please provide the related links

Note: I can't use SD card nor IDE drive for this because of the size, even parallel Flash memory is also involved larger size & a lot of address pins

Thanks in-advanced for any help
--- In a..., anhtruong52@... wrote:
>
> I would like to use an Atmel CPU with a Flash memory (ie: DataFlash AT45DB161D) that some how using FAT16/32 to be able to put files to & from the Flash memory. Is it available? If YES, please provide the related links

Why does the DataFlash have to have FAT16/32.

Unless its plugged into a PC, the file structure does not mean much.

don

PS: Google is your friend

>
> Note: I can't use SD card nor IDE drive for this because of the size, even parallel Flash memory is also involved larger size & a lot of address pins
>
> Thanks in-advanced for any help
>

I guess this is already explained for an AT45DB642 however I might be
mistaken.

Please see:

http://www.atmel.com/dyn/products/tools_card.asp?tool_id879

Best regards,

Javier

On Mon, Dec 7, 2009 at 5:12 PM, wrote:

> I would like to use an Atmel CPU with a Flash memory (ie: DataFlash
> AT45DB161D) that some how using FAT16/32 to be able to put files to & from
> the Flash memory. Is it available? If YES, please provide the related links
>
> Note: I can't use SD card nor IDE drive for this because of the size, even
> parallel Flash memory is also involved larger size & a lot of address pins
>
> Thanks in-advanced for any help


Hi,

I am regret that I forgot to mention that I also can't use USB either, but thank for the link I will use it as a reference
--- In a..., Javier Chavez wrote:
>
> I guess this is already explained for an AT45DB642 however I might be
> mistaken.
>
> Please see:
>
> http://www.atmel.com/dyn/products/tools_card.asp?tool_id879
>
> Best regards,
>
> Javier
>
> On Mon, Dec 7, 2009 at 5:12 PM, wrote:
>
> >
> >
> > I would like to use an Atmel CPU with a Flash memory (ie: DataFlash
> > AT45DB161D) that some how using FAT16/32 to be able to put files to & from
> > the Flash memory. Is it available? If YES, please provide the related links
> >
> > Note: I can't use SD card nor IDE drive for this because of the size, even
> > parallel Flash memory is also involved larger size & a lot of address pins
> >
> > Thanks in-advanced for any help
> >
> >
>
>

My task is some how to use the Flash memory for transfer files to another unit through its interface (without using USB) and I think to do that, might be I have to use some thing like FAT to be able to copy/delete files from & to other interface (Serial, SPI)

Might be my thought is wrong, any suggestion?

--- In a..., "Donald H" wrote:
>
> --- In a..., anhtruong52@ wrote:
> >
> > I would like to use an Atmel CPU with a Flash memory (ie: DataFlash AT45DB161D) that some how using FAT16/32 to be able to put files to & from the Flash memory. Is it available? If YES, please provide the related links
>
> Why does the DataFlash have to have FAT16/32.
>
> Unless its plugged into a PC, the file structure does not mean much.
>
> don
>
> PS: Google is your friend
>
> >
> > Note: I can't use SD card nor IDE drive for this because of the size, even parallel Flash memory is also involved larger size & a lot of address pins
> >
> > Thanks in-advanced for any help
>

--- In a..., "anhtruong52" wrote:
>
> My task is some how to use the Flash memory for transfer files to another unit through its interface (without using USB) and I think to do that, might be I have to use some thing like FAT to be able to copy/delete files from & to other interface (Serial, SPI)
>
> Might be my thought is wrong, any suggestion?

Your thought is not wrong, but a little mis-guided.

Getting FAT to work is a lot of work.

A long linear string of bytes, sent out the serial port from one device to another is a lot simpler. Consecutive 512 byte blocks is far easier to work with.

How is the second device going to store the bytes sent from the first device ?

How many "files" do you need ?

good luck

don

PS: Google is your friend

Hi Doham,

Yes, I know that it very very dificult to do what I was aked to do, that is why I have tried to get help through forum. The problem is I have to transfer files from the PC Host (through Serial) & put back those files into another PC Host (through Serial) without using USB connector

I know that we can perform copy 512 bytes as you mentioned, but it isn't the case here, because some how my device must see the Host using FAT to select files & vice-versa

I am searching & searching for related links, but only find that 'might be' I have to use with Micro SD card for this, because SD support FAT ... the problem is even the Micro SD required the connector and it takes some places & its interface area

It is very tough for me & I am not sleeping well for now

Any suggestions? Thank for trying help
--- In a..., "Donald H" wrote:
>
> --- In a..., "anhtruong52" wrote:
> >
> > My task is some how to use the Flash memory for transfer files to another unit through its interface (without using USB) and I think to do that, might be I have to use some thing like FAT to be able to copy/delete files from & to other interface (Serial, SPI)
> >
> > Might be my thought is wrong, any suggestion?
>
> Your thought is not wrong, but a little mis-guided.
>
> Getting FAT to work is a lot of work.
>
> A long linear string of bytes, sent out the serial port from one device to another is a lot simpler. Consecutive 512 byte blocks is far easier to work with.
>
> How is the second device going to store the bytes sent from the first device ?
>
> How many "files" do you need ?
>
> good luck
>
> don
>
> PS: Google is your friend
>

On Wed, Dec 09, 2009 at 03:20:49PM -0000, anhtruong52 wrote:
> Hi Doham,
>
> Yes, I know that it very very dificult to do what I was aked to do,
> that is why I have tried to get help through forum. The problem is I
> have to transfer files from the PC Host (through Serial) & put back
> those files into another PC Host (through Serial) without using USB
> connector
>
> I know that we can perform copy 512 bytes as you mentioned, but it
> isn't the case here, because some how my device must see the Host
> using FAT to select files & vice-versa
>
> I am searching & searching for related links, but only find that
> 'might be' I have to use with Micro SD card for this, because SD
> support FAT ... the problem is even the Micro SD required the
> connector and it takes some places & its interface area
>
> It is very tough for me & I am not sleeping well for now

You are having a rough time because your understanding is off quite a
bit.

First, your SD card does not "support" FAT, it just so happens to come
from the factory formatted with a FAT filesystem. You could put NTFS,
FFS, or HFS+ filesystems on it. Could partition and run multiple
filesystems.

Second, to communicate a file structure through traditional serial ports
either you have to write applications for the PC's that mate with
whatever protocol you invent for your AVR board, or you have to write
code for the AVR that speaks protocols supported by existing
applications.

For file transfer the first thing that comes to mind is XMODEM (and
ZMODEM). Make your AVR board "look" like a traditional dial-up BBS. Use
[XZ]MODEM protocol to upload and download files. How you store the files
on the AVR (plus SD card) is totally up to you but if you happen to use
an established file system then one might be able to pull the card and
use the contents traditionally.

Much more difficult solution would be to implement PPP on your serial
link. Then emulate a file server or FTP server. If you start now you
might finish in a year or two. A quick way to solve this problem would
be to grab an ARM or AVR32 board and install embedded Linux. You will
already have FAT filesystem support, SD support, and PPP. All you have
to do is configure and test.

--
David Kelly N4HHE, d...@HiWAAY.net
=======================================================================Whom computers would destroy, they must first drive mad.
As David has stated, your project seems a little dis-jointed.

I see you have an idea for a solution to a problem.

But, your not thinking it all the way through.

We would like to help you, but we need to understand your project fully.

The fact that you want to transfer files is small compared to the rest of your project.

Lets make a few assumption:

1) The USER interface will be on serial-port.
2) There will be more than one file saved on the storage device.
3) The USER must be able to select which file is on the storage device.
4) start a transfer to/from the storage device.

Ok, how does the USER access the file names and start a transfer ?
How does the PC know there is a file system on the serial port ?

The PC normally accesses the directories and FAT tables on anyh kind of media.

If you have a PC driver that looks at the serial port as an disk drive, the PC will handle the FAT for you.

The storage device does not need to know that the memory is formatted as FAT or anything else.

Your AVR code is a block device.
The PC will ask for block 123 or 456 and your code will read or write block 123 or 456.

The PC will control the FAT, you control reading and writing 512 byte blocks.

don

On Dec 9, 2009, at 6:42 PM, Donald H wrote:

> As David has stated, your project seems a little dis-jointed.
>
> I see you have an idea for a solution to a problem.

My suspicion is that its a homework assignment that is due very soon
resulting in loss of sleep.

[...]

> Lets make a few assumption:
>
> 1) The USER interface will be on serial-port.

It might not. It might be that he expects to push/pull files between
two PC's completely under the control of the AVR. Was very unclear.

Appeared to me that somehow he thought an SD card wrote files in FAT
filesystem format automagically. That from the AVR one could instruct
the SD card to "write the following data in a file" rather than the
reality where one must manipulate the file allocation table directly,
and from that write the data into the designated locations in the SD.

Perhaps the O.P. will have learned something from this about planning,
and of estimating level of effort.

Am a bit afraid that those of the past who hated flow charting as
students, are now teachers.

--
David Kelly N4HHE, d...@HiWAAY.net
=======================================================================Whom computers would destroy, they must first drive mad.