Elegant Invention Blog

Just a quick status update: the isostick has officially reached beta status!

Support for reading ISO9660 files from FAT16 and FAT32 partitions on the microSD card is complete and the units are ready for [very] preliminary testing. Many features will be added during the beta period.

On that note, some time in the coming weeks I intend to do a full writeup on how the FAT filesystem works. It is targeted at other embedded developers who need to integrate FAT into their devices, as I found Microsoft’s own documentation to be quite obfuscated.

Expect less frequent blog posts during the beta, as I will be working around the clock with the beta testers to create and finalize a lot of really cool features for the isostick!

If you’ve just stumbled upon the isostick and you want to be notified when it is released to the public, sign up for the announcement list!

Things always take longer than planned, and I’m a terrible judge of completion time. I am actively involved in some contract work which takes me away from isostick every so often, and I do apologize that it is taking so long. Fear not, however, for things are progressing quite well! [Insert marketing babble about taking so long in order to deliver the best product to you, the most valuable customer! (yes, you!!)]

My SCSI implementation on the AVR32 is working well! A few optimizations are still on the to-do list, which I plan to roll out during the beta period. Up next is the filesystem drivers (FAT32, first and foremost) and the ISO9660 parser. No idea how long this will take — I sincerely hope to have it done by the coming weekend (July 24th-ish), but other contract which shall not be named is planning to steal a few days from me so we shall see!

It’s been a while since the last post regarding the isostick, so I thought I should give a quick summary of what’s going on. Development is moving along smoothly and I expect to be in beta by the end of June.

Not long after the beta units are distributed (sorry, they’re all spoken for!) I will list the project on kickstarter to obtain funds for the final launch, as costs exceed what I can afford alone. The funding will allow for the units to be fabricated, assembled, and tested at a facility that really knows their stuff. Oh, and a classy (and durable!) clear plastic enclosure.

This is all being done to deliver the best product possible.

For all those interested in hearing new developments about the isostick, I’ve setup an announcement list. Just fill out the form below and you’ll get emails whenever there’s important news!
If you have any questions/comments/etc, direct them to isostick [at] elegantinvention [dot] com, don’t reply to the announcement emails, the bot will eat them.

Now that I’ve got your attention with shiny things..

As an opening note, everything below is what is planned for the isostick. It’s subject to change, blah blah, the firmware is only starting to be written and anything could happen. If you think the firmware could use a feature I haven’t mentioned here, shoot an email to the suggestion line: isostick [at] elegantinvention [dot] com

NEW: Sign up for the announcement list!

What is the isostick?
It’s a USB stick designed for IT professionals and geeks in general. It accepts a microSD card and normally shows up as a USB Mass Storage Device, as you would expect. It also shows up as a USB CD/DVD drive. What witchcraft is this? What purpose could it serve!? Say you put some disk images on the microSD card — an ISO of your super special custom nLite‘d Windows installer, some Linux boot discs, some tools or recovery software (SpinRite, memtest, ntpasswd, DBAN, …) — then you fire up the included isostick software and pick which image you want to show up in the isostick optical drive. Presto! Until you change it again (or move/delete the image file), anywhere you plug in the isostick it will see a Mass Storage Device (the microSD card), AND an optical drive which has the selected image “in the drive.”
Oh and it has a read-only switch to protect the contents of the microSD card, in case you don’t trust your friends’/coworkers’ computers (or just your friends and coworkers…). For those of you always saving the day with anti-virus on a CD or USB stick, or plugging your poor USB stick into machines that tend to be infected with who-knows-what, the read-only switch may come in handy!

How much will it cost and when will it be available?
The plan is to release it next month some time, but don’t quote me on that as soon as possible. Oh, and it will be in a nice plastic enclosure by then. [Note: You may have noticed I increased the price. My previous estimate was too low for the production volume I'm expecting. Sorry!]

How does it work?
The isostick tells the computer it is two devices: a mass storage device and an optical drive. U3 USB sticks use the same trick. You are not restricted in what you can store on the microSD card, it acts just like any other microSD adapter. If you have disk images on there, though, you can put any of them “in” the optical drive. As far as the computer is concerned, there’s a bona fide disc in a drive hanging off its USB socket. You can even boot from it, presuming your BIOS supports that.

But I can just use UNetBootin / grub / etc to boot X iso from USB, why do I need this?
Maybe you don’t! But allow me to entice.. Sure, you can load one iso from a USB stick using UNetBootin, and really I love that program, it’s fantastic! With isostick, however, you can carry many iso files all at once, and switch between them with ease. Grub may allow you to do this with some isos, but as far as I’m aware, there are limits to what you can get grub to boot from a USB stick. For someone not well-versed with grub, it may also be a pain..
Suppose you don’t have a working machine to change the iso — no problem! The isostick can easily present a spare optical drive with a bootable environment to change the active image file. Also, the active image file and all configuration data is saved in a simple text file on the root of the microSD card which can be edited by hand in a pinch, or by scripts/applications to produce complex automated installers that change discs for you… Use your imagination

Still not convinced!?
Some ideas being tossed around, in no particular order:

1. The stick itself has a pushbutton and an RGB LED. I haven’t really found a use for those yet, I just love RGB LEDs and pushbuttons. Someone suggested I add the ability to assign colors to commonly used images, and then the user could plug in the stick and press the button to cycle through colors. For those among us with better memory than I, that seems like it would save some time switching images.
2. A “sandbox” mode, where all modifications to the microSD card are actually written to a file on the card, so other than that file getting bigger nothing actually changes. I can’t think of a specific use case, but it seems like one of those fun little things that will come in handy some day. Depending on firmware constraints, this may appear at some point.
3. An app that would list [user-submitted?] freely available images such as linux livecds, OS installers, tools, etc. Ideally it would allow you to select images in the list and download them for you.
   1. An extension of the above: a community site built around that idea, where people can comment, submit, and rate various images.
4. Disco mode. Come on, you know you want a USB disco ball. RGB LEDs are so much fun.
5. Allow the user to enter a list of images for each drive. Upon receiving an eject command, the drive would switch to the next image in the list. Neat! (Thanks, mpanetta!)

Phew, this is a long post. Time to get back to assembling isostick boards and writing firmware!

Still alive! Another project has kept me very busy as of late.. One that will avoid the undesirable situation of trying to evolve beyond the need to eat.

I’ve been taking a few steps back lately on eiCAD: the shape system was originally designed to be extremely flexible and still fairly simple. As I began moving to C++ using Qt, I changed it around a bit to be less flexible, but more tuned to work with Qt’s built-in graphics handling classes. This made life easier for a lot of things, but as I tried to implement wires (nets / traces / connections / …) — pictured above — I ran into a serious conflict of interest with Qt’s handling of selecting and moving QGraphicsItems. Overriding some default implementations makes everything work in harmony.

P.S. Don’t take this as a posting against Qt — quite the contrary! Qt has made life easy on this project, and as with any project you will probably run into a situation where your tools don’t quite fit the bill. The fun part is the challenge of either changing the tools, or the design, to meet the same goals.

The UI design is coming along. The status bar is pretty well done, the tabs work, and the menus and toolbars are starting to take shape. It doesn’t look like much, but there’s plenty of back-end code making all that work. Short post today, not much to talk about here.. More fun to come soon.

The main window is beginning to take shape! What you’re looking at here is two views into the same “page.” A page, in Qt terms, is a scene which contains items. Changes to the scene are reflected in all views, it is like looking at the same object from multiple points of view.

The main window is now tabbed. Presently each tab is tied to a particular page, which represents either a schematic sheet or a board. You can split the view in the tab numerous ways, vertically and horizontally. Making the addition and removable of splits intuitive won’t be trivial, but hopefully the end result will be simple and easy to use.

I think this feature will be most useful when doing board layout on a large and/or dense board, where you want a “supervisory” zoomed-out view of the entire board, along with a tightly zoomed-in view of what you’re currently working on. I don’t think it will find much use in schematic capture, but it can be used for either.

There’s one philosophy I will try to apply throughout the implementation of eiCAD: Every feature in an application should be intuitive for the novice, but customizable for the expert. That is to say: anyone should be able to start using an application as-is with little or no prior study, but the advanced user should be able to adjust every feature as they see fit, knowing exactly how they want the application to look and behave. Put another way: the application can assume it is smarter than the user, but only so long as its “intelligence” can be modified or disabled.

A good example of this is that modern smartphones, by default, auto-correct typos on the fly. This is a fantastic feature for most people, as those on-screen keyboards can be a bit tough to work with, and the built-in dictionaries are quite good. For some people though, whether it be a frequent use of uncommon words or a general distaste for machines that believe they’re smarter than the user, these automated “corrections” may not seem like corrections at all! In that case the feature should always have the ability to be tweaked (perhaps load a more appropriate dictionary), or disabled entirely.

Ok, so you can’t really tell from the picture, but the items now snap to the grid when moved around (if you enable that feature). Accomplishing that was a lot less trivial than I had hoped.

In short, the way Qt handles moving a QGraphicsItem around is by directing mouseMoveEvent()s to it. The default implementation grabs a list of the initial positions of all selected items in the scene (each movement of the mouse generates a call to this event handler, so this list is kept until the mouse button is released), checks for any necessary transforms, then simply adds the distance the mouse moved to the items’ position(s) and calls setPos() on them to apply the new position.

Unfortunately for me, QGraphicsItem::setPos() is not a virtual function, and since my shape primitive class is inheriting QGraphicsItem, that means when the default mouseMoveEvent() calls setPos() there’s no way for me to intercept it and replace the point with a “snapped” point. Several bottles of Bawls later, I had reimplemented mouseMoveEvent(). My implementation is very similar to the default one with the exception that, if enabled, it will snap the parts to the grid. The snapping is done by the following equation:

qRound(x / gridX) * gridX

Where x is either the x or y coordinate, gridX is the x or y spacing of the grid, and qRound() is a rounding function that returns the nearest integer (round up for ≥0.5, down for <0.5).

Hi everyone! Thanks for visiting.

This is the blog of me, trying to start a company called Elegant Invention. There’s nothing on the main site yet, but when there is I will be sure to mention it here.

To keep things brief, I’m an electrical engineer and software developer. A few years ago, while using CadSoft EAGLE regularly, I realized it’s lacking quite a bit of advanced features that other ECAD programs offer. Things like high-speed design aids, semi-automatic routing (which they have since added!), etc. These may not be a big deal for the hobbyist, and they’re certainly not necessary , but they make life easier. Nothing personal, EAGLE, you’re my favorite ECAD solution.

The exorbitant pricing of more action-packed ECAD solutions like Altium or OrCAD led me to the idea of writing my own electronics design suite. Crazy! But I’m not smart enough to say no to a challenge like that. Already knee-deep in code, I have no intention of turning back. I’ve decided to start this company hoping that the end result of this project will be useful to others, particular those with money.

The name of my design suite is eiCAD, and I began development some months ago. Once the bulk of the back-end code was done I started in with the graphics, screenshots of which can be found in this flickr set. A friend of mine recently suggested that I blag about all this nonsense, so here it is! Future posts will be terse.

Direct all suggestions, questions, comments, etc. to:

eicad [at] elegantinvention [dot] com

Or for personal messages such as death threats, contact me at:

eric [at] elegantinvention [dot] com