Elegant Invention Blog

I’ve recently begun moving a large portion of the isostick code from C to C++, since much of it would benefit from object orientation.

In the case of isostick I have lots of strings, vectors, and file handles being tossed around. Making them objects reduces the amount code and simplifies memory management, which can be moved to constructors and destructors for example.

In my opinion, if you find yourself writing a lot of boilerplate just to do what C++ would do implicitly then perhaps you should consider C++, but it’s important to understand what exactly C++ is doing behind the scenes, as with any language or tool.

Anyway, this is just going to be a brief overview of some things I’ve done in order to reduce code size when using C++ on baremetal.

Disclaimer: I’m by no means an expert on the topic. These tips may only apply to g++, I do not use any other compilers so I can’t be sure. Please feel free to point out errors by dropping a note in the comments section.
[Read the rest of this entry...]

Thanks very much to Nuno Brito of reboot.pro for hosting the official isostick forums!

This will serve as the official venue for ideas, suggestions, feature requests, and most importantly support!

It’s really neat to see an entire community dedicated to booting computers. I hope isostick can benefit the reboot.pro community, and I know their experience and expertise will benefit isostick!

The Kickstarter project for the isostick is up: http://www.kickstarter.com/projects/elegantinvention/isostick-the-optical-drive-in-a-usb-stick

Just a little reminder: follow us on Twitter to get more frequent updates, or check out our Twitter stream over on the right-hand side of this page.

I have twenty-five of the production boards on hand and they are all tested and functional! Some will be used for in-house testing, the remainder are available through the Early Adopter tier on the Kickstarter (more about that below). They are all functional and I am extremely happy with the PCB fabrication and assembly quality, which was handled by MyRO PCB. MyRO has done an exceptional job at an exceptional price, they’ve been cooperative at every step of the way and I highly recommend them.

So you may be wondering, what the heck happened to the public beta!?
Let me start by saying you can still be an early adopter on the Kickstarter page! The Early Adopter tier is the same pricing and specifications as the beta units would have been, and they will ship out as soon as the Kickstarter is funded. Non-early-adopter purchases will be shipped out some weeks later as we ramp up production and such

Originally the public beta was to be paid for by private funding, and I was expecting to sell the units at a slight loss. Unfortunately there was some confusion between myself and the enclosure manufacturer regarding the minimum order quantity. Because of some of my specifications, there is a minimum order of 250 units. I’d like to be clear that this is a reasonable figure and I am not in disagreement with this. However, this is outside the realm of possibilities with the shoestring budget I had set aside for the beta, and I simply cannot handle the cost alone.

Up to this point the isostick has been developed on a shoestring budget, which has been tricky to manage, to say the least. The budget just wasn’t big enough to cover 250 enclosures plus setup fees plus the first production isostick boards.

So anyway, that’s where we’re at. I have to thank everyone in #sparkfun on Freenode IRC for their continued support and encouragement, my good friend Stephen for his mad coding skills on isosel, Mike P. for letting me borrow his JTAGICE mkII which is absolutely invaluable. If I forgot your name I apologize, thanks to everyone, really!

Please help by funding the Kickstarter so we can get the isostick into full production and start making life easier for computer technicians and geeks everywhere!!

Recently I announced the possible move from 32-bit AVR to Atmel’s SAM3U ARM Cortex-M3 series. Soon after, I tweeted that I’m sticking with 32-bit AVR and mentioned that I would write a blog post explaining what happened. As promised, here is the post. Fair warning: long post is long.

Way back when I first started looking around for microcontrollers to do the isostick project I had a few requirements:

• High-Speed USB
• SD Card controller
• Internal program memory
• Enough internal SRAM to get the job done

The HS USB was needed for reasonable transfer speeds, as was the SD Card controller (bit-banging SD or using the SPI interface is insufficient). Internal program memory and SRAM reduces overall part count and board size, so I can fit it all on a conveniently tiny board.

It turns out finding a combination such as this was quite difficult at the time (though this is becoming easier with time). First I came across the now-obsolete LPC2888 from NXP, a spiffy little chip with 1MegaByte of internal flash — MASSIVE! Unfortunately the price tag was equally massive, so I set it aside and kept searching.

Next I came across the SAM3U series of Cortex-M3 microcontrollers from Atmel. They seemed great, meeting all my requirements and more! Alas, they were just recently announced at the time and weren’t available other than samples. Knowing that it may be a very long time before they’re in mass production, I set them aside as well.

While perusing Atmel’s website for other suitable microcontrollers, I recalled their 32-bit AVR AP7 series, which I thought may meet my requirements. Atmel had discontinued the AP7 series, although it lacked internal flash so it was off the list anyhow. Poking around the 32-bit AVR section, I noticed the UC3A3 series with HS USB and SD Card controllers. They had internal flash, an abundance of SRAM, and I knew if they were anything like the 8-bit AVR series they would be easy to develop for, too!

The next few days were spent digging around the interwebs for alternatives; not because I didn’t like the AVR, but simply because I wanted to make an informed decision. There were dozens of possible contenders, but most were missing the crucial combination of internal flash and HS USB.

There’s an interesting divide in the embedded micro world: microcontrollers versus microprocessors. A microprocessor historically is a CPU and a simple bus interface. Today, however, it is more common in the embedded arena to find a CPU surrounded by a plethora of amazingly useful peripherals and all sorts of fun interfaces, all in the same package. So, what differentiates a microcontroller from a microprocessor today? Internal flash and SRAM seem to be the delta, based on my own experience. Devices billed as microcontrollers tend to run at lower clock speeds and focus less on complex caching schemes and multimedia/SIMD instructions and instead put the flash and SRAM right on the die and run them at or near CPU clock rate. They compromise clock speed in exchange for a simpler device and lower external part count; a true System-on-Chip in many cases.

Getting back to the tale of part selection, I had settled on the 32-bit AVR. The feature set is impressive for such a small device. The cost is higher than competing ARM devices, but they generally lacked HS USB and so they weren’t an option for me. I set out learning the SD protocol, SCSI SPC SBC and MMC, FAT Filesystem, et al. Over the next few months much code was written!

The AVR32 Studio development environment was pretty amazing. I’m not a huge fan of Eclipse (which AVR32 Studio is built upon), but it certainly has features that made the job easier. Atmel’s integration of their libraries and programmers was impressive to say the least, and the debugger was fantastic.

Fast-forward to a few months ago: AVR Studio 5 goes into beta, and wow what an amazing application that is. It is built upon Visual Studio, so *nix folk will need to try wine or run a Virtual Machine. That said, it’s entirely worth the effort to get this running if you’re not a Windows user — AVR Studio 5 is simply awesome. It’s hard to believe it’s free given how great it is.

Fast-forward a little further: the SAM3U series goes into production. It was one of my first choices, and I wanted to go back and try it for a number of reasons. Primarily speed: I want to deliver a good experience to the end user, the faster the better. A week later a SAM3U-EK Eval Kit arrived at my doorstep. Porting of the code began. Admittedly I was disappointed with the complexity of the USB Mass Storage stack Atmel provided. The SD stack was equally spaghettified, with lots of asynchronous code and layer upon layer of oniony state machines. If you were doing time-critical/realtime system design, this might be nice — it tries as best it can to avoid monopolizing the CPU for any amount of time, and I’m sure it does that well.

The tools: I learned a very hard lesson when trying the SAM3U. I’m spoiled. AVR Studio 5 and even AVR32 Studio have seriously skewed my perception of other embedded IDEs. Atollic TrueSTUDIO seemed pretty good, almost on par with the old AVR32 Studio, but I couldn’t afford to purchase a license. ARM/Keil have their own offerings but again my research showed insane pricing. Eventually I settled on using YAGARTO / GNU toolchain with vanilla Eclipse. After much frustration and heads colliding with desks, it was working.

The port: In lieu of the Atmel-supplied SAM3U USB Mass Storage and SD libraries, I ported over the AVR Software Framework (ASF) libs. The SAM3U USB libs stayed in place and I spliced the ASF’s Mass Storage drivers on top of them. I did a complete port of the ASF’s SD/MMC libs including the low-level MCI portion, because the MCI silicon used in the SAM3U and UC3A3 is largely the same (the VERSION register shows the SAM3U is a variant of an older revision than that used in UC3A3, if I recall correctly).

By porting over the ASF’s Mass Storage drivers, my SCSI stack fell right into place. Likewise, by porting the ASF’s SD/MMC services I was able to drop my filesystem code in easily. After patching up a few spots where I made assumptions about endianness (32-bit AVR is Big Endian, whereas SAM3U is Little Endian), I had things up and running.

The problem: Testing, testing testing. I was seeing relatively slow read speeds. The SAM3U’s MCI can run at up to half the CPU clock. The CPU clock is 96MHz, so the MCI is 48MHz. The SD bus transfers 4bits/cycle, so 4bits/cycle * 48Mcycle/second * 1byte/8bits = 24MByte/s. There’s a bit of overhead to account for, but I should realistically have seen speeds in the ballpark of 20MB/s. Instead I was seeing closer to 15MB/s. For reference, the 32-bit AVR UC3A3′s MCI, running at the top speed of 33MHz, has a theoretical transfer rate of 33Mcycle/second * 4bits/cycle * 1byte/8bits = 16.5MB/s, and I see sustained throughput in the area of 12.5MB/s. The discrepancy here is likely due to the latency of issuing the command over USB (which is half-duplex), parsing that, issuing a command to the SD card, and so on.

It dawned on me that I had only been testing with a single card, so I pulled out some others I had, and behold! One card did in fact achieve around 18MB/s, the others hovered between 13MB/s and 15MB/s. Testing with other commercial readers, indeed it appeared to be the cards that were at fault. Some Googling revealed this seems to be commonplace. It’s also interesting to note that the microSD cards I have that are of Class 2 and 4 actually perform better for reading and writing than the Class 6 card I have, though the Class 6 does meet its specification. Go figure!

The decision: There were other subtle bugs in the SAM3U port (it was, after all, quickly hacked together over a week or two). So I decided to go with 32-bit AVR UC3A3, based on: the real speed gain of the SAM3U was much less than predicted, the subtle bugs in the port that had marginal benefit now, my deep familiarity with the 32-bit AVR UC3 series, and finally the amazing ease of use and integration of AVR Studio 5.

Phew, this has been a long post. I hope this has been an interesting or at least informative insight into the decision-making that went into designing the isostick.

The first post explaining the isostick is obscenely long, so I thought it may be a good idea to write a brief summary of what it is and who might want one!

What is the isostick?

The isostick is a USB flash memory stick that likes to pretend it is also an optical (CD/DVD) drive. As far as the computer knows, there’s two things in that little device: some flash storage, and an optical drive.
The idea is to put CD/DVD images, also known as ISO9660 files or “iso” files for short, on the flash memory drive and then you’re able to “insert” any one of those files into the optical drive. The computer will think there is a real optical drive sitting there with a disc in it!

So, can I only put iso files on this thing?

Nope! You can put any files you want on isostick, it doesn’t care! You can even format it to any filesystem you want. Note, however, that currently it can only read iso files from FAT32 partitions. We are investigating the possibility of supporting NTFS, HFS+ and ext2/3/4.

What else does this cool device do?

Well, it’s got a read-only switch. Flip it into read-only mode to protect your precious data. This is especially handy for technicians who need to run anti-virus on infected machines; now you can know your flash drive is safe from infection.

Oh, and it has this nifty bootloader called isosel being developed by my good friend Stephen. What’s it do? I’m glad you asked! You can always change the currently-loaded iso file via some software [or by editing a config file if that's your cup of tea]. But let’s look at a worst-case scenario: you’re helping a friend reload Windows 7 on their machine, but you left the Windows XP iso loaded by accident and the only working machine is your friend’s non-booting Win7 box. What to do!? Simply boot from the isostick’s optical drive and instead of whatever iso you had loaded previously, you will be presented with isosel. It will appear somewhat like Grub, NTLDR, or any other standard bootloader. It gives you a list of all the iso files on your isostick, simply pick the one you want and it will be loaded and booted straight away!

You might be concerned that the aforementioned isosel will cause problems when booting from certain discs. Let me assure you that great care has been taken to ensure this is not the case. When you boot from the optical drive you first get isosel, but if nothing happens for some [configurable] amount of time isosel will go ahead and boot the previously-loaded iso. Also note that isostick will remember your last choice, even when that choice was made from isosel.

Also it has a white green LED, who doesn’t love LEDs? The original description mentions an RGB LED, however this was ditched in the final design for cost reasons. But trust me, you’ll love this green LED! It blinks and fades and stuff!

Who would want one?

The isostick is targeted at computer technicians, IT people, and geeks in general.

Common usage scenarios include technicians who frequently need to reload machines in a mixed environment, or boot a variety of different CD/DVDs. With isostick you can just toss all your isos on the stick and take it with you, no more annoying CD cases, scratched or lost CDs, etc!

Maybe you work at a datacenter and frequently need to burn and insert CDs into machines that don’t have management cards to handle that sort of thing.
Or perhaps you, for whatever reason, have a constantly-changing disc image that you need to burn frequently, isostick could save you lots of time and hassle — just copy the iso to the stick and plug it into the target machine!

We think you’ll find the isostick to be a valuable tool in your geek arsenal!

Just a quick status update on the isostick. Presently the isostick uses the Atmel AVR32 UC3A3 microcontroller, which is an excellent chip indeed! However, the maximum CPU and bus frequency for the AVR32 UC3 is 66MHz, and the maximum MCI (SD/MMC Controller) clock speed is half that, so 33MHz. Each clock cycle the microSD cards transfer 4bits, so 8bits (1 byte) every 2 cycles, or 33/2 = 16.5MByte/s theoretical transfer speed. I see real-world transfer speeds around 12.5MByte/s.

The Atmel SAM3U series of ARM Cortex-M3 micros caught my eye early in the development process when first hunting for a suitable MCU. They remained in the sampling phase for quite some time however, and I decided to go with the aforementioned AVR32. Recently the SAM3U has gone into production and begun popping up at the usual distributors.

Why go SAM3U? It’s faster! I expect to see real-world transfer speeds of around 20MByte/s on the SAM3U-based design, which is almost double what I’m seeing on AVR32. Note that the SAM3U can run the microSD card at 48MHz, and the SD Specification 2.0 has a maximum of 50MHz, so it doesn’t get much faster than that! The SAM3U is also less expensive in volume and physically smaller, making the PCB layout much less cramped.

What problems may arise? The code may be difficult to port in the time I have allotted. It is highly abstracted, however, and I feel it can be fully ported in a week’s time. Failing that, I will continue forward with the AVR32 solution, for which beta (and barring any hardware flaws, production) PCBs are ready to go. An eval kit is on its way to me as I write this, and should arrive on Monday, April 4th. In the mean time I will continue work on the AVR32 firmware and investigate points of difficulty for the port.

What does this mean for you? I won’t delay the beta more than 2 weeks to investigate this. I plan on having the beta boards in hand and ready to distribute by the end of April, worst-case. The final board design using the AVR32 is done and ready to be used in case I do not use the SAM3U.

Thank you all for your patience and understanding as I refine the isostick design!

Good news: the isostick is well on its way!

I’ve been working so much I forgot to blog! The most recent hold-up has been raw sector support, which required implementing Reed-Solomon encoding, something I had never done before. After looking for some license-compatible example code and coming up dry, I ended up grabbing some books on the topic and after a couple weeks of hard study we now have our own RS encoder.

Shortly after the public beta (it’s coming! I promise!) I plan to do informative blog posts detailing what I’ve learned in building isostick. It has turned out to be far more massive than I could’ve ever anticipated, and the experience I’ve gained is certainly worth it. I will likely start with Galois Fields, work into CRC (used for EDC, Error Detection Codes, in CDROM), then extended Galois Fields and Reed Solomon encoding, then tie all that together by talking about the CDROM specification, ECMA-130. Later I may also write about the workings of the FAT filesystem, and perhaps others.

It’s worth noting that Atmel has released a new AVR Studio 5 beta and it’s friggin’ beautiful. Simultaneously they released a new AVR Software Framework (included in the AVR Studio download), and it is leaps and bounds ahead of their previous library. Sorry Atmel, the old lib was practically write-only. The new library is nothing short of elegant.

That said, I should get back to hacking on this code!

Neither I, nor the isostick, are dead! Things have been moving at a reduced pace due to some health problems and the holiday festivities, but they are still moving! Isostick is still my full-time job; it will be released “when it is done.” Unfortunately that’s the best I can do for now, life has a habit of getting in the way of these things, and I want isostick to be the best product it can be

Back to work!

Elegant Invention now has a twitter account for announcing products and stuff, or whatever the cool kids do these days. Check it out!

So the contract work that shall not be named has been taking significantly longer than expected. On the bright side, it’s nearing a close and I’ve begun shifting gears back to isostick!

Down to the nitty-gritty, the changes:
The isostick will no longer feature a removable microSD card — instead it will have internal storage, likely either 8GB or 16GB. I know for some people this will be a big let-down and I apologize, I want the removable card as well! This decision is due to the extreme cost and expertise involved in designing and producing a reliable injection-molded case. Other case types were looked at, but I’ve decided that to bring the best product to market a prefab case will be used, probably one from the fine folks at New Age Enclosures.

As to the time line, we are leaning toward a second beta due to issues with yield on the first beta. This time the beta units will be assembled in the same place as the production units to eliminate the uncertainty of my lovely, non-temperature-controlled toaster oven. The second beta may also consist of a switch to an ARM9 MCU to get the highest speed possible: the AVR32 UC3A currently being used has a max SD bus frequency of 33MHz, whereas SDHC cards themselves (and the proposed ARM9 MCU) max out at 50MHz. Still, the AVR32 provides respectable maximum throughput of around 12MiB/s. We’ll see

That’s all for now, time to get back to work!