Memos From the Cube

A weekend without internet has given me a lot of time to work on the code, which is still shaping up quite nicely.

I had an epiphany while browsing through my Mass Storage demo application code, which seems obvious now that I’ve worked it all out. It also explains what Atmel were trying to achieve with all the dataflash page translation routines they’ve written for their own demo.

Previously, the pages of the dataflash ICs were merged together in a continuous stream by the MyUSB Dataflash API, so that there was a virtual Dataflash of twice the single IC capacity. This way arranged in the following manner:

[Chip 1, Page 0][Chip 1, Page 1][...][Chip 1, Page n][Chip 2, Page 0][Chip 2, Page 1][...][Chip 2, Page n]

That was the most logical system to myself when I first started. Writing to the dataflash was done as follows:

1) Select dataflash IC for the current page address

2) Send buffer write command

3) Write data to buffer

4) Send page write from buffer command

5) Wait while operation completes

However, this was grossly inefficient; for each page, the device has to wait until the page has completed writing before it continues on to the next page. Solving this involves interleaving the dataflash pages, using the LSB of the page address to indicate which chip to use:

[Chip 1, Page 0][Chip 2, Page 0][...][Chip 1, Page n][Chip 2, Page n]

Which means that since each consecutive page address is in a different dataflash IC, the busy-wait loop can be moved to the start of the process, after the chip select. Now the wait only occurs after both dataflash chips have been writing, and the first (still busy) chip has been selected again. This results in a good speed increase for consecutive page writes.

1) Select dataflash IC for the current page address

2) Wait while any oustanding operation complete

3) Send buffer write command

4) Write data to buffer

5) Send page write from buffer command

New are two unfinished demonstration applications; a USB Mass Storage Host demo (which will eventually read out the first logical block of an attached device, and could be expanded with a file system driver to read/write data on an attached disk) and a USB Audio Output Device. I’m hoping to complete the Mass Storage Host demo application in the next few days.

The last day and a half I’ve been working on improving (and writing!) the remainder of the MyUSB API, and I’m happy to announce that it’s just about ready for a stable 1.0 release.

I’ve added in a remote wakeup API, for managing suspended state wakeup requests in both device (to host) and host (to device) request transfers. That should allow for USB devices to wake up the host (or allow host apps to acknowledge a wakeup request from a device) which wasn’t possible before the API was implemented.

Also added is two more host examples, MouseHostViaInt and KeyboardHostViaInt, which are very similar to the mouse and keyboard host examples. The big difference is that the pipes in the new examples are interrupt-driven via the real pipe/endpoint management interrupt, instead of polled. I’ve also added in the remained of the endpoint/pipe interrupt API to facilitate this.

Today I was busy working on creating a host mode Configuration Descriptor processing API. I think it’s quite neat; a host application can now request the total configuration descriptor size from a device, allocate memory to hold it, fill the memory with the configuration descriptor then process each sub-descriptor it contains, extracting data as needed. All MyUSB host examples now use the new API, and extract interface and endpoint configuration right out of the device’s Configuration descriptor rather than being hard-coded.

I hope to receive some feedback about the library (and the new API sections) from users soon. Let me know what you love/hate/want!

Well, it was all worth it. The Mass Storage demonstration application in MyUSB is now finished, commented and uploaded into the MyUSB archive. The demo provides a 16MB mass storage disk device which can be read and written to (albeit very slowly) like a normal USB flash disk.

Remember to keep updating your code with the latest library versions!

Today marks some real progress with the Mass Storage code - it’s almost finished. With the latest code I can now format a 16MB flash disk, give it a name and drop very small files onto it (less than 64KB or so each). For some reason folders or any files larger than about 64KB aren’t reading (or writing) correctly, and have the data above the ~64KB mark all repeating garbage. I’ll have to look into that and try to suss out the source of the problem.

My previous problems with the formatting was down to a few mis-calculations in the MODE SENSE command, as well as a few bugs in the READ/WRITE command (one of which was a missing check for the endpoint recieved flag, resulting in writing and reading before the host was ready). Tests show that the host doesn’t seem to use the READ SENSE (10) command at all, so I’ve thrown all that code away in favor of just the MODE SENSE (6) command, which is definitely used and required.

With any luck the example will be finished by Friday, when I get my second semester University exam results.

It’s now 2AM, and I’m wrecked - off to bed. I’ve just been involved in a marathon coding and debugging session on the Mass Storage driver, with promising results.

With the latest code, Windows shows up a new external removable disk, unformatted. Formatting the disk doesn’t work yet, giving a generic “can’t format the disk” error.

It seems Atmel’s implementation of the MODE SENSE command isn’t superfluous, as it first seemed. Without the command Windows won’t even *try* to format the disk. I’ve written my own implementation which allows the format process to start (but fail), although the ALL PAGES sense page command causes the host to NAK the data. Lots more debugging yet to do.

Once the disk is formatted correctly, the existing read/write routines *should* work. Time will tell, but for now I’m getting some sleep.

As always, I’ve been busy coding. I’ve progressed with the Mass Storage demo to a point where it is almost finished; the last part to implement is the virtual blocks to read dataflash interface code. Atmel’s dataflashes are great, but they always seem to use horribly sized pages - 1056 bytes for the ones on the USBKEY board. There is an option to switch them to 1024 bytes, a page size that would make my life significantly easier - however this is a write-once option and I don’t want any of my code to make any irreversable changes to the board.

Plugging in the board using the latest unreleased code causes the host to give up after querying the block size, due to the odd-size. Changing that over to a standard 512 bytes causes the device to freeze up on the READ (10) command, since the expected data sizes are different. All issues should be resolved with the new virtual memory layer, which will manage translating the logical device blocks over to physical dataflash pages on the two USBKEY dataflash chips and vice-versa.