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!

Reply to
<someone
Loading thread data ...

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
 Click to see the full signature
Reply to
Hal Murray

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

PCB to computer using removable media.

write a custom VHDL firmware that will work on one type of SmartMedia card(8mb)

the very first byte of the first block of the first page)

decimal) to the card

dump) to convert this raw data to an ascii file...

I don't want to use it since we do not all the *junk features, like the ECC and power code.

connect 22 wires to the card...

already set up. Hardware shouldn't be an issue. The clk is definitely fast enough for smartmedia

to do sound feasible? Am I overlooking any issue?

standard removable media(can be non-smartmedia), what is it?

Reply to
Kelvin

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

formatting link

Reply to
Amontec Team, Laurent Gauch

to do sound feasible? Am I overlooking any issue?

standard removable media(can be non-smartmedia), what is it?

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

Reply to
Antti Lukats

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

using

use

GPIO

Reply to
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

Reply to
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!

unsolicited

addresses.

Reply to
p

Hi guys,

thanks for your input

I did spend a lot of time studying the SM FAT12 implmentation (

Reply to
p

On a sunny day (Thu, 26 Feb 2004 09:59:07 GMT) it happened "p" wrote in :

Yes please. JP

Reply to
Jan Panteltje

Hi,

formatting link

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...

site

Reply to
p

The 1st sector is NOT the FAT area

These things go into the directory area not the FAT area

Huugh, I don't understand what this means.

The 2nd sector is NOT the data area

You can only write 512 bytes at a time, no streaming

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:

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

Good Luck

Reply to
hamilton

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

Kelvin

Reply to
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

Reply to
rob d

On a sunny day (Fri, 27 Feb 2004 03:21:31 GMT) it happened "p" wrote in :

Thank you, got the .pdfs appreciated :-) lots of info, presented in a nice way too. JP

Reply to
Jan Panteltje

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.