HC11 FAT16 SD Card

[mot_monkey]

I am kicking around the idea of using an SD Card with an HC11 and having a PC read data logged on the SD card using FAT16. Has anyone had any success doing a similar project with this hardware setup? Thanks.

[RHA]

This is a small training that shows how to use and SD Card with an 8bit 

http://www.freescale.com/webapp/sps/site/training_information.jsp?code=WBNR_SDCARDREADER_S08JM&fsrch... 

[mke_et]

Wow, you don't want simple tasks, do you?

First off, you have to decide EXACTLY how you want to access your FAT16 device. That means are you going to start with virgin media and put down the template of the image you eventually want? Even then, if you create the perfect blank template card and then let something else touch it... If not, and you use a card that ANYONE touched in another machine, you could get screwed with a double 00 lag bolt in the base of your spine. You'll have to be 100% compliant in order to handle all the things a PC might do to the card if it's inserted. Not to mention a MAC.

But... Assuming you restrict yourself to a BLANK card inserted, and a SINGLE file placed on the card, and the file is contiguous with no 'jumping around' in sector allocation (you are going to write this as 'sector allocation' and not memory location, right?) then there shouldn't be anything to prevent your '11 from talking to the card. Mostly...

While the project the way you mentioned it is do-able, I'm not sure you appreciate the magnatude of the task.

[tonyp]

I mostly agree with mke_et, and I did mention "if all goes well" exactly because of the various details that must be in place for this trick to work.  It certainly isn't a production solution, only a little hack to get you by for 'quick-n-dirty' prototyping, or hobby projects for which you have full control.  Certainly though, not something you'd give your customers, and continue sleeping well at night.

As mke_et said, any uncontrolled operation done by third parties will most certainly mess things up.  But the PC by itself will not do anything naughty to the card upon insertion (as mke_et seems to imply, if I understood correctly).  And, I didn't quite follow the 'MAC' thing (we're still talking about FAT16, aren't we?).  What do you mean by that and how is it relevant when  we have a read-only operation on the PC at all times (except for the initialization)?

All we achieve is mark a (hopefully -- and there are ways to ensure this before using) contiguous area on the card for our dummy file(s) which we can use any way we like, we can erase the blocks, re-write the blocks, mark them any way we like, it's just data within a file as far as the PC is concerned.  Just have to be careful of two things.  Not let anyone re-arrange the initial layout of the card, and not use any area outside the dummy file(s).

By the way, you can actually have more than a single file but I wanted to keep the original description simpler, as there are extra considerations to work with multiple files, but a single file is good enough in most situations because you can still logically subdivide it into multiple files, anyway.  And the header section can be made smarter than just include a search string (e.g., it can keep the number of total usable blocks in the file so that the device can dynamically handle different file sizes, etc.)

If you were to use the card for raw data (not with a filesystem), you'd still have to come up with some data verification and/or recovery techniques in case something goes wrong (e.g., bad blocks).  You can still implement these techniques, only this time they will be within the framework of the dummy file.

Bottom line: The correct solution to have a filesystem is to implement a filesystem.  A quick and dirty solution is have someone else create it for you (the PC) and use it (albeit, at your own risk).

Message Edited by tonyp on 2006-12-0612:45 PM

[mke_et]

When I said 'MAC' thing, I was refering to a card or other device inserted into a MAC to be examined.

When I did the ATADRV program I ran into an issue where inserting rotating media (or really any ATA media that emulated rotating media) into MACs would come back changed. Not corrupted, but an image of the drive would NOT match what was originally on the media. I never investigated if it was something in MAC OS or something that was from popular add-on drivers, but the bottom line was the card structure was not the same when I got it back and it was only 'read' from from the MAC users point of view.

To be fair though, I ALSO saw this kind of behavior with WIN9x systems with certain antivirus software installed and running on the machines. One more gotcha to consider.

Mike

[tonyp]

You don't give many details about your hardware setup, so I'm guessing you mean if an HC11 can manipulate SD cards.  It certainly can do MMC in SPI (I've done it) and I believe SD can be run in SPI mode, also (not sure).

But writing a complete FAT16 driver for simple data-logging maybe more work than its worth.  You can do the following little trick, instead: Format the card on your PC and copy a single dummy (i.e., header + all ones or zeros -- depending on erased state of Flash) file that you have prepared in advance with a size as big as the worst case log file you need to get (or as big as your card will allow).  Put some header in the beginning of the file so you can easily locate it inside the Flash (e.g., 'MY LOGFILE BEGINS HERE').  Next, write simple block read/write routines for the reading from or writing to the card from the HC11.  Search for the the header string and use the following block to start saving you log data.  If all goes well, you'll be filling into the area already occupied by the dummy file you copied from the PC.  When done (making sure you don't go beyond the pre-allocated end of the file), simply put the card back in the PC and read the dummy file.  You'll just have to clean-up the head block and any trailing $FF's (or zeros) and you'll be left with your log file.  A couple of little utilities to prepare the empty file, and clean up the filled file will be needed on the PC side, but you shouldn't have trouble with that.

Hope this made some sense.

Message Edited by tonyp on 2006-10-2111:04 PM

[ReyLear]

TonyP:
I'm working with SD Card too, and now I'm reading the ProductManual (hard to find with all details and commands), but I'll have the same problem.
So, I think that the solution that you suggest sounds good to make fast-prototypes (even final products).

Thanks.