FPGA Central

Hi, I'm undergrad working on project that invovles data transfering from a PCB to computer using removable media.

I had been studying the smartMedia format for some time now. I think I can write a custom VHDL firmware that will work on one type of SmartMedia card(8mb)
1. write the serial input command to the command latch
2. sets up the col and row address to the address register(starting from the very first byte of the first block of the first page)
3. left the program in a waiting state
4. once the write enable signal is triggered, output the actual data(ascii decimal) to the card
5. once the write enable signal is dropped, terminate the writing action
6. now that the raw data is in the chip, I use the unix utility dd (disk dump) to convert this raw data to an ascii file...

I know that the SSFDC forum has the full functional firmware for free, but I don't want to use it since we do not all the *junk features, like the ECC and power code.
I don't even have a proper smartmedia card connector. I'm just going to connect 22 wires to the card...

I will be using Xilinx foundation to implment my design. The PCB is already set up. Hardware shouldn't be an issue. The clk is definitely fast enough for smartmedia

what I want to know is:
1. has someone done something similar before. If so, does what I'm about to do sound feasible? Am I overlooking any issue?
2. if you know a better way to transfer data from a PCB to computer using standard removable media(can be non-smartmedia), what is it?
3. tips?

Thanks for any input!

>2. if you know a better way to transfer data from a PCB to computer
> using standard removable media(can be non-smartmedia), what is it?

The usual way to get data from a random project to a PC is over
a serial port. (RS-232)

I haven't worked with Smart Media. They are used in digital cameras.
The usual way to get pictures from a camera is via USB where the
storage device looks like a disk. That means you (probably) have
to write things in a file-system format. Is your software going
to support that?

I don't know why you want to use Smart Media. I'll assume you want
to put it where a serial cable won't reach.

If the file system software turns out to be too complicated, you might
be able to build a chunk of hardware that reads the SM card and sends the
bits out a serial port. Mostly the reverse of writing it. (Or you
could add a serial port to your existing board and load new firmware.)

--
The suespammers.org mail server is located in California. So are all my
other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's. I hate spam.

you idea is quite interesting...last time i had an idea of writing some
codes to R/W FAT file systems as
this will make life easier I can read it in Windows directly. of course, i
have only one file on this card...
of course I never did it...

MMC/SD is easier in terms of hardware...as there is only three active
wires...saves a lot of soldering time.
i guess u can write to individual addresses in the memory array at a time
via serial interface...SM requires
writing one sector at a time...

I don't know what disk dump does...in my mind, unix is something in the
server room I can Exceed across
but never know it can handle flash disks...

Correct me if I am wrong.

Kelvin




<[email protected]> wrote in message
news:uPV_b.595937$JQ1.75324@pd7tw1no...
> Hi, I'm undergrad working on project that invovles data transfering from a
PCB to computer using removable media.
>
> I had been studying the smartMedia format for some time now. I think I can
write a custom VHDL firmware that will work on one type of SmartMedia
card(8mb)
> 1. write the serial input command to the command latch
> 2. sets up the col and row address to the address register(starting from
the very first byte of the first block of the first page)
> 3. left the program in a waiting state
> 4. once the write enable signal is triggered, output the actual data(ascii
decimal) to the card
> 5. once the write enable signal is dropped, terminate the writing action
> 6. now that the raw data is in the chip, I use the unix utility dd (disk
dump) to convert this raw data to an ascii file...
>
> I know that the SSFDC forum has the full functional firmware for free, but
I don't want to use it since we do not all the *junk features, like the ECC
and power code.
> I don't even have a proper smartmedia card connector. I'm just going to
connect 22 wires to the card...
>
> I will be using Xilinx foundation to implment my design. The PCB is
already set up. Hardware shouldn't be an issue. The clk is definitely fast
enough for smartmedia
>
> what I want to know is:
> 1. has someone done something similar before. If so, does what I'm about
to do sound feasible? Am I overlooking any issue?
> 2. if you know a better way to transfer data from a PCB to computer using
standard removable media(can be non-smartmedia), what is it?
> 3. tips?
>
> Thanks for any input!
>
>

Antti Lukats wrote:
>>what I want to know is:
>>1. has someone done something similar before. If so, does what I'm about
>
> to do sound feasible? Am I overlooking any issue?
>
>>2. if you know a better way to transfer data from a PCB to computer using
>
> standard removable media(can be non-smartmedia), what is it?
>
>>3. tips?
>
>
> smartmedia has to many wires.
> reading FAT16 is real simple, connecting to MMC is real simple.
> you can get some old PC monetherboard for 1 $ and cut the ISA socket, or use
> the old floppy cable if you have one there you MMC socket.
> reading MMC required only 4 lines.
>
> xilinx.openchip.org
>
> there is source code in C for microblaze to read 1 file from FAT16 on
> compact flash card, it can be modified to read from MMC. there is also
> simple half made routine to talk to MMC card (connected to MicroBlaze GPIO
> pins).
>
> you can of course use smartmedia, but it way more wires!
>
> antti
>
>
Yes, FAT16 reader is very simple to implement. But the original message
is about writing in FAT16 format. FAT16 writer is much more complex. And
you need to have a processor to do the JOB, an FPGA will be to expensive
for this JOB, for this *sequential* JOB.

Some month ago, we designed a datalogger with an FAT16 writer to a
compactFlash. We did the JOB with a PIC up for the FAT16 format, and a
small CPLD for the AD dialog and some pre-processing data JOB (some mA
for all the JOB ...)

Laurent
www.amontec.com

> what I want to know is:
> 1. has someone done something similar before. If so, does what I'm about
to do sound feasible? Am I overlooking any issue?
> 2. if you know a better way to transfer data from a PCB to computer using
standard removable media(can be non-smartmedia), what is it?
> 3. tips?

smartmedia has to many wires.
reading FAT16 is real simple, connecting to MMC is real simple.
you can get some old PC monetherboard for 1 $ and cut the ISA socket, or use
the old floppy cable if you have one there you MMC socket.
reading MMC required only 4 lines.

xilinx.openchip.org

there is source code in C for microblaze to read 1 file from FAT16 on
compact flash card, it can be modified to read from MMC. there is also
simple half made routine to talk to MMC card (connected to MicroBlaze GPIO
pins).

you can of course use smartmedia, but it way more wires!

antti

It is true that it is more difficult to write to FAT16. However, we can
simplify it.

Format the SM/MMC/SD with FAT16, and write an empty file to this card. Then,
with the same FAT16 reader to
get the addresses. Thirdly, write to this file...do I sound right?

Best Regards,
Kelvin




Amontec Team, Laurent Gauch <[email protected]> wrote
in message news:403c921a$[email protected]..
> Antti Lukats wrote:
> >>what I want to know is:
> >>1. has someone done something similar before. If so, does what I'm about
> >
> > to do sound feasible? Am I overlooking any issue?
> >
> >>2. if you know a better way to transfer data from a PCB to computer
using
> >
> > standard removable media(can be non-smartmedia), what is it?
> >
> >>3. tips?
> >
> >
> > smartmedia has to many wires.
> > reading FAT16 is real simple, connecting to MMC is real simple.
> > you can get some old PC monetherboard for 1 $ and cut the ISA socket, or
use
> > the old floppy cable if you have one there you MMC socket.
> > reading MMC required only 4 lines.
> >
> > xilinx.openchip.org
> >
> > there is source code in C for microblaze to read 1 file from FAT16 on
> > compact flash card, it can be modified to read from MMC. there is also
> > simple half made routine to talk to MMC card (connected to MicroBlaze
GPIO
> > pins).
> >
> > you can of course use smartmedia, but it way more wires!
> >
> > antti
> >
> >
> Yes, FAT16 reader is very simple to implement. But the original message
> is about writing in FAT16 format. FAT16 writer is much more complex. And
> you need to have a processor to do the JOB, an FPGA will be to expensive
> for this JOB, for this *sequential* JOB.
>
> Some month ago, we designed a datalogger with an FAT16 writer to a
> compactFlash. We did the JOB with a PIC up for the FAT16 format, and a
> small CPLD for the AD dialog and some pre-processing data JOB (some mA
> for all the JOB ...)
>
> Laurent
> www.amontec.com
>

Kelvin wrote:
> It is true that it is more difficult to write to FAT16. However, we can
> simplify it.
>
> Format the SM/MMC/SD with FAT16, and write an empty file to this card. Then,
> with the same FAT16 reader to
> get the addresses. Thirdly, write to this file...do I sound right?
>
> Best Regards,
> Kelvin

Yes, this sounds about right.

A few things to be aware of:

1) a newly formatted SM/MMC/SD or CF for that matter will not have a
fragmented FAT table.

2) a new file written to the media should have the FAT table in
sequencal order. ( this is a good thing )

3) Finding the start cluster and start sector will be different with
different cluster sizes. ( I know you knew that )

So if the embedded code can find this information, over writting the
clusters in order should take care of any problems.

But, if your going to ASSUME that much, why not write a real FAT file
handler and assume nothing.

This trick is also useful to help preventing a corrupt FAT table.

hamilton

Hi, sorry, I'm going to stick to external removable media.

serial port would make my life easier but it's too common.

One of the goal of this project is to test my endurance. The other one is to
make data transfering as painless as possible.

Thanks!


"Hal Murray" <[email protected]> wrote in message
news:[email protected]..
> >2. if you know a better way to transfer data from a PCB to computer
> > using standard removable media(can be non-smartmedia), what is it?
>
> The usual way to get data from a random project to a PC is over
> a serial port. (RS-232)
>
> I haven't worked with Smart Media. They are used in digital cameras.
> The usual way to get pictures from a camera is via USB where the
> storage device looks like a disk. That means you (probably) have
> to write things in a file-system format. Is your software going
> to support that?
>
> I don't know why you want to use Smart Media. I'll assume you want
> to put it where a serial cable won't reach.
>
> If the file system software turns out to be too complicated, you might
> be able to build a chunk of hardware that reads the SM card and sends the
> bits out a serial port. Mostly the reverse of writing it. (Or you
> could add a serial port to your existing board and load new firmware.)
>
> --
> The suespammers.org mail server is located in California. So are all my
> other mailboxes. Please do not send unsolicited bulk e-mail or
unsolicited
> commercial e-mail to my suespammers.org address or any of my other
addresses.
> These are my opinions, not necessarily my employer's. I hate spam.
>

Hi guys,

thanks for your input

I did spend a lot of time studying the SM FAT12 implmentation (<8 mb = FAT
12). Theoretically, the sequentially step would be

1. set address to the 1st sector, the FAT area
2. write the filename, attribute, extension, etc. to FAT
3. set address to the root directory sector
4. write the filepath to the root directory
5. set address to the 2nd sector, the data area
6. stream the data, compute the total number of bytes written
7. jump back to the FAT area and add the length value

if a blank file is already created, then step1-5 can be skip, however, a new
step is needed
1. search the entire FAT for the file entry. I heard that the file entry in
FAT is random. 2. read the entry and set the pointer to that data area

so no matter what the design becomes too complicated. In the end I designed
it doesn't worth the trouble...

Good to know that I'm right about this issue.

So I guess I will stick with no file system, raw data, and use disk dump as
the bridge between the two. I will ask around and see if unix/linux can read
SM format (using those 9in1 card reader). Also, if the guy who ported dd to
windows did a good job, then a batch file is probably all I need to read
back the data.

Regarding to the numerous lines on SM chip, I agree they are a pain.
However, I have a bunch of SM specification (by Toshiba). There is a timing
diagram that has all the programmable lines for Serial Data input(data
streaming with auto address increment). So if I recreate that waveform in
VHDL, something will get into the chip right? Anyways, MMC seems to be a
pretty good alternative, I will probably dig into it a bit. But the SM
wiring is already completed, so without any documententation on MMC
programming, I can't justify the trouble of rewiring the chip and getting
new components.

By the way, if anyone wants the SM specifications, I can put them on my site
for download


Thanks guys!


"hamilton" <[email protected]> wrote in message
news:403d82ad$[email protected]..
>
>
> Kelvin wrote:
> > It is true that it is more difficult to write to FAT16. However, we can
> > simplify it.
> >
> > Format the SM/MMC/SD with FAT16, and write an empty file to this card.
Then,
> > with the same FAT16 reader to
> > get the addresses. Thirdly, write to this file...do I sound right?
> >
> > Best Regards,
> > Kelvin
>
> Yes, this sounds about right.
>
> A few things to be aware of:
>
> 1) a newly formatted SM/MMC/SD or CF for that matter will not have a
> fragmented FAT table.
>
> 2) a new file written to the media should have the FAT table in
> sequencal order. ( this is a good thing )
>
> 3) Finding the start cluster and start sector will be different with
> different cluster sizes. ( I know you knew that )
>
> So if the embedded code can find this information, over writting the
> clusters in order should take care of any problems.
>
> But, if your going to ASSUME that much, why not write a real FAT file
> handler and assume nothing.
>
> This trick is also useful to help preventing a corrupt FAT table.
>
> hamilton
>

On a sunny day (Thu, 26 Feb 2004 09:59:07 GMT) it happened "p"
<[email protected]> wrote in <Lrj%b.619427$X%5.315413@pd7tw2no>:

>By the way, if anyone wants the SM specifications, I can put them on my site
>for download
Yes please.
JP

Hi,

www.sfu.ca/~pyuan/sm/

enjoy!

All the doc are free. But you need to register in the SSFDC forum to get
them. So I will save everybody the trouble...


"Jan Panteltje" <[email protected]> wrote in message
news:[email protected]..
> On a sunny day (Thu, 26 Feb 2004 09:59:07 GMT) it happened "p"
> <[email protected]> wrote in <Lrj%b.619427$X%5.315413@pd7tw2no>:
>
> >By the way, if anyone wants the SM specifications, I can put them on my
site
> >for download
> Yes please.
> JP

comments embedded

p wrote:
> Hi guys,
>
> thanks for your input
>
> I did spend a lot of time studying the SM FAT12 implmentation (<8 mb = FAT
> 12). Theoretically, the sequentially step would be
>
> 1. set address to the 1st sector, the FAT area
The 1st sector is NOT the FAT area
> 2. write the filename, attribute, extension, etc. to FAT
These things go into the directory area not the FAT area
> 3. set address to the root directory sector
> 4. write the filepath to the root directory
Huugh, I don't understand what this means.
> 5. set address to the 2nd sector, the data area
The 2nd sector is NOT the data area
> 6. stream the data, compute the total number of bytes written
You can only write 512 bytes at a time, no streaming
> 7. jump back to the FAT area and add the length value
The length does NOT go into the FAT area.


I am sorry, you do not understand how FAT file systems work.

Google is your friend. Here, I'll help you out:
<http://www.google.com/search?hl=en&ie=UTF-8&oe=UTF-8&q=fat12&btnG=Google+Search>

Links I have used to decode FAT files are on this list.

Good Luck

yuan r u willing to share with the ng how you wired a smartmedia card?

Kelvin



p <[email protected]> wrote in message
news:%Iy%b.626113$ts4.526502@pd7tw3no...
> Hi,
>
> www.sfu.ca/~pyuan/sm/
>
> enjoy!
>
> All the doc are free. But you need to register in the SSFDC forum to get
> them. So I will save everybody the trouble...
>
>
> "Jan Panteltje" <[email protected]> wrote in message
> news:[email protected]..
> > On a sunny day (Thu, 26 Feb 2004 09:59:07 GMT) it happened "p"
> > <[email protected]> wrote in <Lrj%b.619427$X%5.315413@pd7tw2no>:
> >
> > >By the way, if anyone wants the SM specifications, I can put them on my
> site
> > >for download
> > Yes please.
> > JP
>
>

"Kelvin" <[email protected]> wrote in message news:<403d4dfb$[email protected]>...
> It is true that it is more difficult to write to FAT16. However, we can
> simplify it.
>
> Format the SM/MMC/SD with FAT16, and write an empty file to this card. Then,
> with the same FAT16 reader to
> get the addresses. Thirdly, write to this file...do I sound right?
>
> Best Regards,
> Kelvin
>
>
I have done exactly this, using a PCMCIA flash card hosted by my MACH
(lattice) cpld and c51 micro. I used my host to download via rs232 a
binary dump of the flash after formatting to understand the fat format
and where my data started. It is as easy as it sounds. The newer
standards use the same electrical interface and so my design also
worked with smartmedia inserted into a PCMCIA card converter. I could
save a PAL video image (I forget the number of kilobytes) in half a
second.

Rob

On a sunny day (Fri, 27 Feb 2004 03:21:31 GMT) it happened "p"
<[email protected]> wrote in <%Iy%b.626113$ts4.526502@pd7tw3no>:

>Hi,
>
>www.sfu.ca/~pyuan/sm/
>
>enjoy!
>
>All the doc are free. But you need to register in the SSFDC forum to get
>them. So I will save everybody the trouble...
Thank you, got the .pdfs appreciated :-)
lots of info, presented in a nice way too.
JP