Fsrw Femto question

BigFoot

Does anyone have a way to perform the BootSDCard() routine from fsrwFemto in the new version fsrw routine? We need to perform
the same function with SDCards formatted for FAT32.

Russ

Mike Green

As far as I know, the new FSRW routines do not have a boot capability. It's possible to use the new FSRW routines to get the sector address of the start of the file to be loaded, then stop the new FSRW routines and start up the low level older sdspiFemto bootSDCard routine with this sector address and it will load and start the program.

I think Kye's FAT32 SD card routines include a boot function, but I'm not sure. It's also possible to use the older sdspiFemto low level I/O routines with the new FSRW routines, but it would take a little modifying to do so. That would make it possible to add a high level bootSDCard routine to the new FSRW routines, but I don't know if that's been done yet.

BigFoot

Thanks Mike,

We need to store more files in the root directory on the SD Cards than Fat16 will handle.

Russ

Kye

I'll be posting a file system that will address your issues in a few weeks.

Thanks,

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,

rokicki

FAT16 can store an almost arbitrary count of files in the root directory. You just need to make the
root directory larger when you initially format the card.

BigFoot

Kye, we are looking forward to seeing your new driver's, it will be nice to finally access sub-directory's.

rokicki, We didn't know this, but it might be kinda difficult for our customers to format the cards in the field.
Nice work on your drivers though, they work great.

Russ

BigFoot

How do you change the size of the root directory ?

We are working with 2 Gig cards and I tried overriding the default allocation unit
size to different values (/A:size), but could still only store a little more than 400
files in the root directory.

Russ

rokicki

Right, it's not the allocation unit. Looking at the various options for formatting on Windows
(Vista 64-bit in this case) I don't see anything to change the size of the root directory.

Reading around the web at random it seems pretty much everyone assumes the root directory
is always the same size. The format of FAT16 itself *does* allow a root directory to be larger,
but if we don't have tools to support that, then it's probably not worth using.

We could make our own format utility that would do this, but we risk incompatibility with
Windows and the like.

Sorry for misleading you. It may be time to add subdirectory support.

BigFoot

Sub directories would be great for us.

We develop Point of Sale terminals for school cafeterias. Our newest product displays a
photo of the student when they enter a pin number, scan a bar code or place there finger
on a Bio Metric finger scanner.

We store the photos locally on an sd card, and there can be thousands of kids in the school.
The bitmaps are stored in large files that we can index into, we added a seek function to
fsrw femto to do this but it is time consuming.

Russ

rokicki

You might try fsrw2.6 in the obex; this includes what should be a pretty reliably fast seek function.
It's also a fair bit faster. It's not as good as having subdirectory support, but it should be better
than what you're using now.

lonesock

rokicki said...
You might try fsrw2.6 in the obex; this includes what should be a pretty reliably fast seek function.
It's also a fair bit faster. It's not as good as having subdirectory support, but it should be better
than what you're using now.

Since 2.6 supports FAT32, does that increase the number of files Russ can have in the root directory?

Jonathan

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lonesock
Piranha are people too.

pullmoll

lonesock said...
Since 2.6 supports FAT32, does that increase the number of files Russ can have in the root directory?

With FAT32 also the root directory is a cluster chain, unlike FAT16, so in theory the size of the FAT32 root directory is only limited by available space. I wouldn't store more than 1000 files in a FAT directory, though, because traversing the entries naturally becomes slower and slower with every new entry.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pullmoll's Propeller Projects

lonesock

BigFoot said...
Sub directories would be great for us.

We develop Point of Sale terminals for school cafeterias. Our newest product displays a
photo of the student when they enter a pin number, scan a bar code or place there finger
on a Bio Metric finger scanner.

We store the photos locally on an sd card, and there can be thousands of kids in the school.
The bitmaps are stored in large files that we can index into, we added a seek function to
fsrw femto to do this but it is time consuming.

Russ

If your files are contiguous (e.g. you could format the card, then copy the files on, no deletions), you could pretty simply jump directly to a location in the file without doing the seek. Just get the starting block ID when you open the file in FSRW, then you could use the low-level routines to read the data directly. Just make sure your images are aligned on 512-byte multiples.

Out of curiosity, do you use a hash-map for your index-to-location-in-file directory?

Jonathan

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lonesock
Piranha are people too.

lonesock

pullmoll said...

lonesock said...
Since 2.6 supports FAT32, does that increase the number of files Russ can have in the root directory?

With FAT32 also the root directory is a cluster chain, unlike FAT16, so in theory the size of the FAT32 root directory is only limited by available space. I wouldn't store more than 1000 files in a FAT directory, though, because traversing the entries naturally becomes slower and slower with every new entry.

Ah, thanks!

Jonathan

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lonesock
Piranha are people too.

rokicki

lonesock said...

rokicki said...
You might try fsrw2.6 in the obex; this includes what should be a pretty reliably fast seek function.
It's also a fair bit faster. It's not as good as having subdirectory support, but it should be better
than what you're using now.

Since 2.6 supports FAT32, does that increase the number of files Russ can have in the root directory?

Jonathan

Unfortunately not. fsrw2.6 will not follow a directory cluster chain (yet).

BigFoot

lonesock, We don't use hash maps in our seek function because we cant depend on the files being contiguous.

Russ

rokicki

Well, if you use fsrw2.6 seek, you will get pretty fast seek, so you can maybe consider random-access-based location.

One layout might fill the first part of the file with (name,offset) pairs, scan that for the right picture, then quickly seek
to the given offset and you're done.

If the pictures are all the same size, you might just use name,name,name,name... at the front.

All told, using seek, this should be super fast; the time will probably be dominated by Spin code that scans the names.
You could even address this by using a binary tree or hash, as lonesock suggested.

-tom

BigFoot

rokicki, does fsrw2.6 have a way to perform the BootSDCard() routine like fsrw femto does. The
propellers memory is not large enough to hold our whole program so we have to load parts in
when we need them. Most of our stuff is written in assembly and this happens fairly quickly.

All the photos are 120 x 160 x 16 bits and are identified by a student ID number. Our high
level cafeteria management software (WebSmartt) scans the schools data base and assembles
the bitmaps, class rooms, keyboard, prices and other things then writes all of this to the
SD Card's.

Every night the school servers send out an update to the PoS terminals with new photos,
finger scan templates and prices thus updating the SD Cards. We are really looking forward
to the Propeller II chip [noparse]:([/noparse]

Russ

Post Edited (BigFoot) : 5/3/2010 7:21:39 PM GMT

rokicki

I don't believe fsrw2.6 has a BootSDCard routine. This would probably have to live in the low-level
driver. I have no idea how complicated it would be, but I think I know how to find out.

This might actually be a fairly trivial addition.

Problem is, as always, finding a round tuit.

Sounds like you have quite a setup, all in all.

Kye

Booting is easy if you have space in your code for it. You'll need atleast 100+ registers open if you do it·perfectly or 20+ registers open if you do it not so perfectly.

For example in my filesystem I load all 64 sector addresses into cog memory of the eeprom/bin file so that I can load it without any problems.

If you use the femto approach however the file has to be allocated in linear order on the SDcard because the femto loader only knows where to start at and then just goes from there.

So if the file system had small cluster sizes (smaller than 32KB which is common) then there could be problems

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,