Smartmedia (NAND flash) interface.

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

Reply to
Joseph Casey
Loading thread data ...

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

formatting link
(916) 780-7623

----------------------------------------------------------------------

Reply to
Albert Lee Mitchell

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

BASIC, also a

take about

experience

the work,

I've written a couple of FAT-16 based embedded-systems and your figures are 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

Reply to
Andrew Jackson

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 ;)))

Reply to
Lewin A.R.W. Edwards

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.

Reply to
Tech Support for IDE-CF

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.
Reply to
Hans-Bernhard Broeker

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

Reply to
Joseph Casey

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

Reply to
Joseph Casey

Just found this:

formatting link

here:

formatting link

Joseph Casey wrote:

Reply to
hamilton

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
 Click to see the full signature
Reply to
Ulf Samuelsson

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.