SmartMedia writer (implments using VHDL)....

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!

 

[Hal Murray]

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.

 

[Kelvin]

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




<someone@somedomain.com.invalid> 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!

 

[Amontec Team, Laurent Gau]

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

 

[Antti Lukats]

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

 

[Kelvin]

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 <laurent.gauch@amontecDELETEALLCAPS.com> wrote
in message news:403c921a$1@news.vsnet.ch...

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

 

[hamilton]

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

 

[p]

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" <hmurray@suespammers.org> wrote in message
news:103olioln4u5cd0@corp.supernews.com...

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.

 

[p]

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" <hamilton@deminsional.com> wrote in message
news:403d82ad$1_4@omega.dimensional.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

 

[Jan Panteltje]

On a sunny day (Thu, 26 Feb 2004 09:59:07 GMT) it happened "p"
<chaosdynasty@hotmail.com> 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

 

[p]

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" <pNaonStpealmtje@yahoo.com> wrote in message
news:1077817576.568943@news-01.evisp.enertel.nl...

On a sunny day (Thu, 26 Feb 2004 09:59:07 GMT) it happened "p"
chaosdynasty@hotmail.com> 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

 

[hamilton]

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

 

[Kelvin]

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

Kelvin



p <chaosdynasty@hotmail.com> 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" <pNaonStpealmtje@yahoo.com> wrote in message
news:1077817576.568943@news-01.evisp.enertel.nl...
On a sunny day (Thu, 26 Feb 2004 09:59:07 GMT) it happened "p"
chaosdynasty@hotmail.com> 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

 

[rob d]

"Kelvin" <kelvin8157@hotmail.com> wrote in message news:<403d4dfb$1@news.starhub.net.sg>...

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

 

[Jan Panteltje]

On a sunny day (Fri, 27 Feb 2004 03:21:31 GMT) it happened "p"
<chaosdynasty@hotmail.com> 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