Greetings.
As background we sell several types of datatalogger and we would like to
have a Smartmedia adaptor which works with all of them. The best way of
interfacing seems to be the RS232 port because it is common to all our
DLs. The cards must be readable on ordinary USB adaptors. Our
dataloggers wouldn't have to format the cards - just write data to them.
I have not been able to find a suitable adaptor or a design for one.

It looks as though we would have to design a microcontroller circuit and
write software to handle the FAT16 file format on the cards. This would
be a substantial project.

What size is the task likely to be? what sort of issues would we have to
deal with? Are there any ways we can save time eg by adapting an
existing unit? using existing software etc?

Any advice appreciated.
JC

On Mon, 01 Dec 2003 10:43:19 +0000, Joseph Casey wrote:

What operating system does your datalogger use? If *nix or Windows then
you can simply use builtin drivers but from the tone of your post that
doesn't appear to be the case.

I don't know of a serial smartmedia interface although the converse, usb
to serial, is fairly common however designing such a module with an
embedded microcontroller should be fairly straight forward. We've used
SmartMedia cards independent of an operating system for data storage,
using a FAT16 protocol is just another layer of abstraction.

-- Regards, Albert
----------------------------------------------------------------------
AM Research, Inc. The Embedded Systems Experts
http://www.amresearch.com (916) 780-7623
----------------------------------------------------------------------

We get the dataloggers from a supplier. They run their own version of BASIC, also a
scheduler for multitasking. There are no other OS type functions.

If I go the RS232- flash route, I expect to write the flash interface and
filesystem layer to run on the microller based adaptor. I expect it to take about
2K lines of C giving about 16K bytes of machine code. With my level of experience
it would probably take me 200 hrs! I haven't ruled out subcontracting out the work,
but at this stage doing it myself is preferred option.
Regards,
JC

about right. The best reference for FAT16 is Microsoft's whitepaper on FAT
(available on their web-site); it covers all the expectations of Windows,
etc. Do you require long filename support or plain old DOS like names? From
your description you seem to have failrly simple requirements (only one file
open at once, etc. which can simplify the coding). Its a good idea to be
able to buffer at least two sectors (one data, the other FAT) since FAT16
requires that you refer to the FAT structure frequently; this may affect
your choice of micro-controller.

You don't say how fast you expect to be able to write to your FAT disc: any
idea of rate? This may affect how you choose to interface with the
SmartMedia itself. I've found that, in practice, NAND flash is fairly
reliable but you may get one or two bad blocks on "new" media. The
SmartMedia Forum has wealth of information but you have to become a member
for some specifications, etc.

There are a number of (read-only) FAT implementations which can help you.

Andrew

The problem with SmartMedia is that you need to perform physical
format functions (including defect management) in your firmware. If
you're not wedded to SSFDC, bear in mind it's much easier to work with
CompactFlash, which does all the magic for you. And CF is available in
larger capacities.

You can run any filesystem on top of your physical layer driver, but
you will get best results (fastest/lowest sector wear) if you use a
FAT12/FAT16 [depending on card size] filesystem _specifically_
designed with SSFDC in mind. The SSFDC spec tries to keep FAT clusters
assigned to SSFDC hardware blocks 1:1 so there are no overlaps, which
makes writing files faster and reduces flash wear.

You can, of course, also use the old wrinkle of pre-creating a file on
the card, covering the entire card contents, and simply writing
sequential data sectors on your embedded device. Further, if you use
this system you can exploit a feature of SSFDC; just write the
redundant info area for all the data clusters (don't write the data
area), leave the data sections in "erased" state, and you'll never
need to perform a read-erase-write or erase-write cycle in your
firmware. You'll need to build a special "card formatter" appliance to
make cards like this, though, because creating your dummy file on a
computer will put data in the data area of the block.

I'd be happy to develop you an SSFDC storage peripheral as a
consulant, of course ))

Joseph Casey <long@distance.man> wrote in message news:<3FCB1B47.4356A600@distance.man>...
Perhaps an RS232 to IDE or RS232 to USB convertor would help.

Easier if you per-format the file systems and only update the size and
time stamps. But if you use FAT16, you are limited to 32M only.

Tech Support for IDE-CF <tech@ide-cf.info-for.us> wrote:

Sure? Unless I misremember terribly, FAT16 does go all the way up to
2GB (at a homongous 32 KB of cluster size, but fine otherwise). Only
if you limit yourself to clusters of 512 bytes you would end up with
32 MB max file system size.

--
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

Performance requirements are modest - capacity of 10MB min. Data transfer
would be 10 x 50 byte records/sec. 8.3 filenames. Readable on stock
readers. Media cost is not very important. My main concern is getting it
built and debugged with least possible amount of programming. Compact Flash
seems to have distinct advantage of simpler interface and hence less
software overhead on my adaptor, so I am investigating a CF +
microcontroller solution.
Thanks for replys.
JC

I am investigating Compact Flash because of simpler interface and therefore
less software for me to write and debug. There seem to be IDE and FAT
libraries available for lots of microcontrollers.
Thanks for replies,
JC

Just found this:

http://www.samsung.com/Products/Semi...ationNotes.htm

here:

http://www.maushammer.com/systems/da...ge-format.html





Joseph Casey wrote:

"Joseph Casey" <long@distance.man> wrote in message
news:3FCB1B47.4356A600@distance.man...
Why not an Atmel Dataflash.
Simple SPI interface and up to 16 MB of Flash.
Nor flash, so it will work of the shelf (no bit level testing).
You can find a low cost 32/40 pin device without memory bus that can handle
what you need. The ATmega16 could be a good choice.
If you need more than 16 MB, then only add chips.
SCK,MOSI,MISO is common, and a chip select for each flash device.

The disadvantage of the dataflash is that it is not directly readable
on "stock readers"

The AT89C51SND1 MP3 player has UART + SPI + USB
and there is already FAT file system source code with the development board.
A USB Mass Storage driver is also available.
The smaller brother (AT89C5131) should be able to run the same code
with very little modifications.

Thus you can use the UART to store data and USB to retrieve the data without
a "stock reader". All this while playing "Money for nothing" in the
background :-)



--
Best Regards
Ulf at atmel dot com
These comments are intended to be my own opinion and they
may, or may not be shared by my employer, Atmel Sweden.