Page 1 of 1


Posted: Wed 2020-12-16 20:46
by stanton

In a VS1010 application I would like to uniquely identify an attached USB key.

On a computer I might do something like this:

Code: Select all

>> diskutil info disk4s1 |grep UUID
Volume UUID:              5453EF0C-773E-3495-AC89-6ABB38BA62F4
and then use this UUID as the key to store some relevant data.

What would be the best approach to uniquely identifying an attached USB key in a VS1010 application?

Thanks in advance


Posted: Tue 2021-01-05 19:43
by Panu

Hmm, I'm not quite sure if I understand what you mean exactly. Do FAT32 volumes have UUIDs? I have no idea.

That said, I might have some ideas on how to set the USB drive's serial number, that's done in USB level. But I don't know if that has anything to do with your actual problem..

Hmm2, what is your actual problem :D



Posted: Wed 2021-01-06 14:03
by stanton
Hi Panu

Thanks for the reply, I will try to clarify...

I am working on an audiobook player where VS1010 is the basis of the player and books consisting of MP3 files are attached via USB keys/sticks/drives to the player.

The goal is to bookmark the last known play positions of each book.

I want to be able to start play of a file on a USB device, picking up from where it left off when it was last removed by storing a bookmark per USB device. If a bookmark is not present, play starts from the beginning.

I imagine storing a bookmark/timestamp of the play position when a USB device is removed so that play can resume from that point when it is next inserted and maintaining a list of (say 50) last bookmarks on storage on the player.

(I would also like to avoid having to rely on writing a UUID myself if possible)

What would be the best approach to uniquely identifying an attached USB key in a VS1010 application so that I can store a bookmark for it?


(FWIW my understanding is that FAT32 does not create a UUID but the OS mounting it does so I was wondering is VSOS does anything like this and if not what approach to take)


Posted: Wed 2021-01-06 16:19
by Panu

Ok, I see. Hmm, FAT32 formatter generates a 32-bit ID starting at byte 39 of the filesystem descriptor at sector 0 of the partition. For most disks, you could do a blockread of sector 0 and get that ID. For device D (SD card), you could do
u_int16 buf[256];
VODEV('D')->BlockRead(VODEV('D'), 0, 1, buf);
and get the ID plus a few surrounding bytes there, around buf[20], I'd imagine. That should work for most cases, at least if the disk has just the FAT and no partition table. Usually SD cards and USB sticks don't have partition tables.(if they do, you need to follow the entry for partition 1 to the first sector of the partition that holds the FAT32 BPB info)

VSOS does no such tracking, it manages to manage the entire filesystem with something like 16 words of info in RAM :lol:


PS. Where do you intend to hold the information? Be extra careful if you intend to write the SPI flash that holds your firmware. Don't write to the root, make a subdirectory for your info so that you don't lose your firmware in the inevitable case where power runs out in the middle of a write and you end up with a corrupted directory.

Personally my vote is to use one fixed 4K block in the SPI flash and erase and write raw data there for stuff that needs updating. This way there's no FAT directory writing ever happening without explicit user interaction. You can do a BlockRead and BlockWrite of negative sector numbers of the S: disk if it's a SPI flash. You can read and write sectors -8 to -1, e.g. the 8 sectors (4 kilobytes) immediately before the start of the FAT S: system disk. Just do a read of sector 0 after the blockwrites to commit the write from RAM buffer to the flash proper.

For the book currently being listened, you can use the 32 bits in the RTC shifter (use RTC battery) to hold immediate information about where you are playing or about volume setting or other such small information.


Posted: Fri 2021-01-08 12:07
by stanton
Thanks Panu, that gives me some things to get started with.