Thursday, April 17, 2014

Inklings of a project

Does anyone care to venture a guess?


To state the obvious, there are many LEDs, an ATmega chip, and there are the beginnings of a charlieplexed arrangement...

It still has a long way to go, though!

Thursday, March 20, 2014

Tooting my own horn for just a bit...

I forgot to post here back in February that, once again, yours truly won yet another hackathon!  This time, I took the title of "Best M2M App" at the AT&T M2X Hackathon at the AT&T Foundry back on Feb. 22.  I'm splitting a $500 prize with my partner who provided a robot and programmed it to accept letters as serial inputs in order to drive it back, forth, left, right, stop, and do all sorts of things.

The app is called SpeechPipe, and utilizes the text-to-speech function on your Android-powered device.  You can send the text to any Internet-connected or Bluetooth-connected device.  Thus, your Android can now be used as a microphone to take dictation for emails, Word documents, or controlling the screen if you have a program that will map certain commands to screen actions.  Of course, we also used it to control Jeff's Bluetooth-connected robot.  The implementation done for the Hackathon was written from scratch to use the MQTT protocol (the most popular protocol driving the Internet of Things), but originally I had made a similar app that uses TCP sockets to send messages to Windows and Mac clients, Linux GUI applications, and even a Linux console.  However, TCP sockets aren't very effective to set up when you've got one device behind a NAT firewall and another with an IP address coming from the cellular network.  This is why MQTT saved the day.  Nevertheless, imagine a blind sysadmin able to shout out commands! "rm -rf *"!  Make sure that pipe is secure!!!

Since then, my life has been consumed by not just regular work, but sourcing components from Chinese suppliers (like I alluded to in my previous post), and assisting the LEDgoes manufacturing effort, while trying to stay on top of updates to the LEDgoes firmware and software.  It's nice to say you're going to make a Displayboard and four Partnerboards, but designing four Partnerboards and sourcing the parts for all of them isn't easy to do in the short amount of time you have between work and sleep.  (The Chinese suppliers all believe I don't sleep as it is. :-P)

Here's what I've purchased recently:

  • 250 LiPo batteries from Kamcy sourced on Tuesday night
  • 2,000 LED panels from Shenzhen Liang Jia Liang last week
  • 800 Displayboards (200 each) from Texas Circuitry at some point... last Friday, Monday, or tomorrow, not exactly sure when they're starting :-P
  • 150 Bluetooth Bees purchased within the last few minutes
Not to mention all the stuff I've ordered in the past, and we're still working on sourcing the rest of the items on the BOMs (bills of materials) that we haven't purchased yet.  (Hopefully we haven't missed anything!  It sucks paying twice for shipping.)

Speaking of which, one of my suppliers in Shenzhen told me that several of her classmates went on to work for Foxconn after college.  The environment there seemed very impersonal, and it was not easy to be noticed, much less appreciated.  Most of them have already left Foxconn because they are burnt out.

Specifically, I submitted final board designs to TX Circuitry, finished Production Rev 1.0 of the LEDgoes firmware, sat with the assembly team twice (including right now) to facilitate testing, fixed the errors that were preventing the LEDgoes PC control software from working reliably, and did the ordering I mentioned above.  Texas Circuitry complemented me on my "beautiful" Gerber files, which was a relief since that was the first time I had produced Gerber files for 3rd-party manufacturing use.  Lots of the final work products will be posted on our GitHub repositories once I make it back home.

The production hasn't been going well as I'd hoped.  I thought we would have shipped the early backers' boards out by now, but the assembly team wasn't able to finish assembling the 62 boards due to severe illness requiring hospitalization.  Now that I'm here helping out, they are running so many things (I mean, racks of servers requiring 220V) on regular household power somehow; needless to say, it's hard to test more than 6 LEDgoes boards connected to each other without them acting really touchy.  I'm hoping that isn't some kind of manufacturing issue that wasn't apparent in the prototypes!

Thursday, February 13, 2014

It's funny when a non-white person says these things...

I was requesting quotes from some Chinese suppliers for parts we need that they just don't make in the US.  Everyone knows the stories about why so much of the US manufacturing sector moved to China; they can build stuff much cheaper than we can.  They are known for being frugal.  Thus, I got a pretty good laugh when I saw this message from a supplier:

3)For the brightness, the type we quot you is for ultra brightness. We only send products with low brightness to india market. I think you understand their need is always with very low price and normal quality.

There!  I didn't say it originally nor alter the text, I'm just passing it onto you verbatim as it appeared in my inbox.  Many cultures love to point out differences in other cultures, and it's not meant to be racist in a hurtful or derogatory way; many times, it's simply stating facts.  I think Americans go too far with what is defined as racist, and are too quick to censure someone simply for pointing out cultural differences.  It's insane to cast the same light on someone who makes such statements as someone else who's committed genocide or any other sort of hate crime.

Also, by purchasing from the manufacturer directly, typically you can't get better than a 50% discount.  Sometimes it's cheaper to just buy from the retailers anyway, especially when there are so many possible customizations you could order on the part.

Thursday, February 6, 2014

Getting An Option Assignment Isn't Such A Scary Thing

Publicly-traded stocks and other equities often feature options, which are essentially derivatives of the motion of the underlying equity.  Stock options are also publicly-traded (unless you're at a company that still gives stock options as performance bonuses).  They allow individuals to reduce risk in their portfolio, or (infinitely more fun) to speculate on the movement of the underlying stock or equity.  There are two forms of options, and just like regular equities, two ways to play them.  In American-style markets, you are free to exercise options at any point prior to expiration.  I'll spare you a crash-course in options, since you can get the jist of how they work in many other places.

However, many tutorials gloss over a glaringly obvious fact that must not be intuitive to many people, based on my personal experience.  It's also extremely simple:  It is never optimal to actually exercise a call early, unless the underlying stock is about to pay a dividend.  That is, never elect to buy the underlying stock using the option at the price you selected, unless the stock is going to pay a dividend that is so big that the payout exceeds the remaining time value on the option.

The Two Faces (Values) of Options


There are two values that ultimately comprise the price of an option: its intrinsic value and its time value.  The intrinsic value is simply how "in the money" the option is, and is calculated by the difference between the option's strike price and the actual stock price at that very moment.  Upon expiration, the only value left in an option is its intrinsic value.  The time value, on the other hand, is based on a calculation of how much the stock would reasonably move given the amount of time left until expiration and its past history of volatility.  Thus, volatile stocks always carry hefty time premiums, but my little ol' NMM stock doesn't tend to carry rich option valuations.

It's this bit of time premium that you will never be able to capture if you simply exercise the option.  You are better off selling the option and making a few dollars more than if you exercised the option and immediately liquidated your position.  Plus, in the real world, it's probably far cheaper to pay the commission to sell the option than it is to pay the commission to exercise the option and then pay yet more commission to liquidate the position you just incurred from exercising the option.  For instance, it would be $20 or $25 to exercise and liquidate with my broker (I've never actually done it :-P), but only $2.95 to sell the option itself.  Here's another extreme example: let's say you just bought (for real cheap) the right to buy the VXX at $53 when it is still at $49, because you're expecting the market at large to take a dump.  The stock indeed pops to $52, and so the options premiums skyrocket, even on the $53 call, which still doesn't have any intrinsic value but is now carrying an epic time value of $1.50 (thus pricing the VXX at $54.50).  You would still be foolish to exercise the $53 call; why buy the stock at $53 when it's selling at $52 on the market, and when you could just sell the option as if the stock were at $54.50?

(Note from the School of Reality: Only the VXX and biotech firms reliably behave like this.  Most of the time, when a stock pops or drops big, it's the result of an earnings announcement.  In this case, any options that are still out of the money after the market has reacted to that announcement essentially become worthless, as it's unlikely the stock will incur any additional movement.  However, as a result, it can still be fun to gamble on a 1-2% swing on the day after earnings are announced, as I've actually recovered completely from incorrect directional bets on the actual earnings report doing this myself.)

So What?


The reason I write about this today is that on this very day, according to my records, someone actually assigned a call to me!  Properly!  For the first time ever!  I've been assigned on various options I've sold against NMM three times in the last three years, including today.  Prior to my easily-accessible records, I may have been "called away" on NMM before, and I've certainly been called away on other holdings like ELN.  It's worthwhile to me to hedge the risk when the stock drops, though usually what happens is I hang on to that short call position a little bit too long and they snag it from me at a "discount" before I get a chance to buy the option back for cheaper.  Thus, this is definitely not my first time to the assignment rodeo.  (Though I can say I've never shown up "naked" to that rodeo. :-P -- that is, not owning the underlying stock at the time someone wants to buy it from me.)

Usually what happens is some nitwit decides to exercise the call option early in order to purchase the stock at a nice discount from its market price, not realizing they'd be better off simply selling the option.  Based on what I can tell, prior to today, I was never assigned on an NMM option on the ex-dividend date (the last day on which you can put in an order to buy the stock and collect its dividend), so I'm not sure what those other two fools who exercised early were doing -- obviously not trying to capture a dividend.  ELN never paid a dividend the whole time I owned them, so I was shocked to ever see any kind of assignment notice on that position.  We must have fourth-graders trying to play options out there.  If I'm going to be called away on a position, it's refreshing to at least see it done right and correctly thought-out!

How I Made Money Off The Assignment


Nevertheless, seeing the assignment notice was definitely a suitable substitute for coffee for me this morning.  I had other short options in my portfolio on the VXX and on UNG.  I was afraid someone picked one of those to exercise, and I definitely don't have enough money to cover those.  Luckily, either people are too smart to exercise those early, or the system always assigns early exercises to those who actually own the underlying, so I was relieved to see an extra $1,750.00 in my account from the sale of NMM.  I knew what I needed to do then; find out if today is the ex-dividend date (it is), and then re-purchase the 100 shares for myself so I too can capture the dividend.  This is where it gets amusing; I'm pretty sure every time I've been assigned, I've always made money off the assignment.  If I buy the option back, OTOH, I'm historically more likely to lose money.  I originally sold the $17.50 call for 80 cents, less a $2.95 commission.  Then, the assignment fee was $14.99, IIRC.  It cost $5 to buy back the 100 shares at a price of $18.03/share.  All in all, I made about $4 from the exercise, after commission. :-P  That made me feel a lot better about being assigned!  At least I didn't lose any money on the hedge.

Post-Mortem


I should have known February would have the ex-dividend date.  After all, it was in February 2011 that I bought NMM in the first place in order to capture their insane 9% dividend yield.  It dipped briefly in the interim, only increasing the dividend yield.  The stock is, to this day, a bit beneath what I bought it at originally, but I've made quite a nice double-digit return on it since I bought it anyway.

Thursday, January 16, 2014

SuSE... Might as well be called SuCKE

Or ShiTTE... >-D

Last month, I was looking to install an operating system besides Windows that would be compatible with my wonderful nVidia 650-something-or-other graphics card and 4K display.  (4K = 4 times the resolution of 1080p HD.  Booyah!)  Windows 8 is nice, and handles this display wonderfully, but for optimal enjoyment of Android Studio, you should really run Linux (or possibly Mac OS too).  Plus, having Linux around on a dedicated disk is never a bad idea.  Having heard from some of my friends about how they think everything Canonical (makers of the very popular Ubuntu Linux) touches is evil, I figured I'd try a different distribution.  Stacy loves Linux Mint, but I can't wrap my head around some of its strange idiosyncrasies.  Maybe it doesn't help that she gave me an old version on a thumbdrive, but it was slow, would freeze up when I wanted to get serious with it, and there are icons that look like folder icons that you can't click on to explore its contents.  I mean, how stupid is that?  Doesn't that completely fly in the face of all the design dogma over the last 30 years?

As such, I gave SuSE a shi... er... a shot.  It's a flavor I hadn't had much experience with, so I figured I'd try it out.  After loading it onto a USB thumbdrive with UNetbootin, I proceeded to run the installer.  Little did I know, but an hour later, I'd be going to bed without seeing it finish because it was getting to be about 1 AM.  During that hour, I had almost managed to convince myself the installation had finished when the monitor inexplicably shut itself off.  After not having heard any of the usual aberrations in the fan noises, or the standard BIOS beep, or my hard drives making noises as if they were floppy drives (?!?) -- all these things are indicative of a reboot on my system --, I became skeptical and started moving the mouse and hitting the keyboard.  It turns out that the SuSE installer has a screen saver consisting of a blank screen.  What other installer does that?  I almost yanked out the USB drive, thinking I needed to remove that so my computer wouldn't boot back into the installer; had I done that, I would have screwed up the whole installation!  Oh, and one more dumb thing about this installer: after the screen saver was aborted, the progress bar did not move.  I can't vouch for what it did after I went to bed, but about 8 hours later, I finally woke up to a new Linux distro.

It was very difficult for me to begin using the OS, and in fact, I wasn't completely convinced it was done installing because the default video drivers overscanned my TV to the point where I couldn't see the corner edges (including their useless menu bar) for the first few minutes until I changed the TV itself to "Just Scan." (Just as an aside, whatever useless OS the Udoo shipped with from its Kickstarter does the same crappy behavior.)  This is something Windows fixes for me automatically; it has never overscanned my monitor unless I was using an old tube TV, and even then, I had drivers to tweak the scan and shrink it back to size.  Thus, I tried to seek new Linux drivers for my video card, only for another ugly problem to rear its head: it can't get online right out of the box!

First thing was it didn't recognize any of my on-board networking hardware.  I had to go into the Terminal & write sudo /usr/bin/NetworkManager . just to get it to recognize my ethernet ports. Once I did that, it let me on the network with an IP address from the router, but it still couldn't visit any Web sites for no apparent reason!  At least not in the traditional way; out of the box, when you're on an IPv4 network, it doesn't handle DNS properly.  I figured out how to get to Web pages from my SuSE install eventually, but I had to know their IP address ahead of time!  Most sites don't even let you type in http://[ip address] anymore in order to navigate to them, so this was useless.  Long story short, I had to hack resolv.conf to get it going with some kind of phony "8.8.8.8" entry so it would actually do DNS properly.  It seems like the SuSE people insist the IPv4 people are just doing it wrong and need to move onto IPv6; well for us home users, that might not necessarily be an option.  How about just build a better, more resilient OS?

Once I got online, it took about 9 years just for Firefox to open a Web page, and for no apparent reason, I could hear the hard drive clunking away constantly.  What the hell is it doing to my drives?  The Internet does not exist on them!  And my computer is an Intel i7 920 with 12GB of DDR3-1066 RAM (yes, very 2008--but still, not bad specs), so why is it taking this long?!?  I tried typing "twtr" in the Google search bar just to see if Firefox & the Internet connection was alive; it took about a minute for anything after the first T to show up because evidently it took that long for it to fix its DNS entries and actually get on the Internet like a functional OS can.

I'm also particular about my user interfaces.  I hate customizing them, but I expect them to be the way I like them right out of the box.  Anything else and I will incessantly bitch and moan.  I get paid to write and test software and file bugs, not to dick around with setting up OSes and do menial IT tasks.  Oh, and Heaven forbid I find a bug I'm not getting paid to find.  I'm your worst nightmare of a consumer because it'd better be right or else I'll ditch it (hence my brief foray into Windows Phone until I found a decent version of Android).  Nevertheless, any decent Linux OS would allow you to right click and open a Terminal window; not SuSE.  Every time I wanted to open a terminal (which is by far the most important feature of the Linux OS), I had to go into their equivalent of a Start menu and type "T"... wait 9 years for the keyboard to start responding again... then go along with "e", "r", "m", etc.  Then, it'll show me all the music I can buy where the band's name has those letters in it.  Wait a minute now, I'm here to launch a program!  If I wanted music, I'd just use Spotify!  Finally after clicking on Programs, it shows me Terminal.  Phew.

The rest of the apps docked in the taskbar are useless to me, the settings are far away (on a 39" 4K monitor)--oh, and speaking of that 4K monitor, it didn't support 4K right off the bat.  Well, if it can't even find the proper way to scan my display so I can actually see all the sides & corners, why should I have expected 4K to work?  Wait, this is what I was getting drivers for.  I'd almost forgotten about that after just trying to get the Internet going.  

I went around trying to research whether the drivers listed in YaST (their software package installer) would actually support 4K, and came to the conclusion I needed to download the latest distributions straight from some website only to find out these were actually the same distributions YaST featured.  It's always nice to use the GUI package installer, until you realize it suffers from the same problems the OS installation does.  Once again, it took an absurd amount of time to install video drivers.  It's like watching CentOS boot up; the progress bar is like following a square-root curve as it asymptotically approaches x.  It makes a lot of headway in the beginning, only to baffle and frustrate you towards the end.  And once again, that stupid screen saver kicked on again, freezing my progress bar at 76% this time while installing the video drivers.  Well I had actual work to do, so I turned to another machine and hit my nose to the grindstone for another 4 hours, after which time I checked my video driver install; it had completed, but the OS was still incapable of taking full advantage of my 4K monitor.

That's it; time to kill it with fire.  However, I still had stuff to do for real to make myself money, so I ignored this system for a little while.  When it was time to come back to it... well... most of the GNOME desktops I've ever experienced show you a password prompt after you shake the mouse so you can get back onto your system after the monitors have fallen asleep/hit the screensaver.  Not this one; I had to swipe my mouse upward (yes, click & drag) before I could reveal the password box.  MY DESKTOP ISN'T A PHONE!  DON'T GIVE ME THAT CRAP!  I couldn't find a way to change it, except possibly to switch to a different desktop or an older version of Gnome.  Still, I haven't seen this with any other Linux installation I've played around with, so I'm still going to blame it on SuSE.  

SuSE is evidently an OS for people who want to/like to customize everything, and boy, do they force you to!  Right off the bat, it's very uncomfortable and nothing works.  Maybe I should have tried it before I installed it.

To this day, I still haven't actually killed it with fire, but the hard drive I installed it on is sitting on a table on the opposite side of my house.  Someday, when I'm up for attempting to install Linux on my PC again, I'll probably just stick with Ubuntu and call it a day.

Thursday, January 9, 2014

Mixing Logic With ISP Circuitry For Programming Firmware

For the LEDgoes manufacturing & assembly stage, it would be desirable to simply secure each board to a programming jig, and the jig would be able to program both chips without hassle or confusion.  This means that we will need to insert a switching mechanism somewhere in between the ISP (in-system programmer) headers and the actual programming pins on the board so only one board at a time gets programmed.  I am quite familiar with digital logic, but don't have a knack for understanding other types of circuitry, so it struck me as a possibility to use some 74-logic to route the signals sent from the ISP to one chip at a time.

The 7400 series of transistor-transistor logic (TTL) gates date back to the mid-1960s, shortly after the invention of the transistor itself.  Some chips in this series provide basic Boolean operations, others are counters or shift registers, and still others are flip-flops and latches (memory).  Over the last 50 years, this series has been tweaked to possess many different characteristics and one can choose optimizations between power consumption and speed, not to mention optimized size and cost.

The first step in this journey was to make a connector to go from my USBtinyISP to the breadboard.  Wiring up a 3x2-pin female header to the breadboard with long, brittle wires that have a tendency to fall out before the rest have been planted in place is tedious.  It requires some patience to set up, and since leaving the equipment in that configuration for more than a few hours isn't desirable (I usually want to do other things with it after a while), I ended up using some spare ribbon cable plus some of my own headers and blank DIP sockets lying around to make my own connector.  After a couple hours of soldering and tedious testing of every pin and its neighbor, I finished this project.  However, I had to cut the male headers on top later on since there wasn't enough clearance between pins to secure the USBtinyISP's header in place.

The custom cable.  No, I do not sell these.


Once the connector was made, I picked a spot on the breadboard for it to go, and planted a 74LS08 (quad AND gate) next to it.  The '08 chip has four "A" inputs, four "B" inputs, and four "Y" outputs.  If A and B are both logic level high (5 volts), then Y will output high as well; otherwise, Y will be low (0 volts).  If any of the inputs are left floating (not necessarily set to logic level high or low), then the Y output will also be high.  Thus, it is important to add pull-up or pull-down resistors to enforce a particular state when the pin is not being driven by the ISP programmer.  You will see which type I chose later on in the schematic.
Looks like fun to try and route!

The quad AND gate is perfect because the ISP utilizes four different signals: MISO (master input slave output), MOSI (master output slave input), SCK (serial clock), and RESET (for synchronization).  It also provides 5V and 0V (ground), but I use an external power source to provide those to the circuit.  Therefore, each of these signals was wired up to each "A" input on one of my '08 chips.  Each "B" input was wired up to a common signal, the chip select.  The chip select consists of an SPDT (single-pole double-throw) switch that can connect to either 5V or ground; the output from this switch goes into all the B inputs on the first '08 chip.  However, this is only enough to program one ATmega microcontroller on the LEDgoes board; since we need to program both microcontrollers on the board, we will need a second '08 chip.  The switch output needs to be inverted to the second chip so that the second microcontroller is not being programmed at the same time as the first one.  Luckily, I happened to have some transistors lying around, and the Internet proved to be a useful guide for constructing a single-input "NOT" gate using one PNP transistor and a few resistors.  I could have used the 74LS04 (6 inverters) part, but it takes up quite a bit of space and provides many more inverters than I need for this application.

With my circuit completely built on the breadboard, I went on to mate the USBtinyISP with my special connector and, alas, it failed to synchronize with the ATmega chip on my board.  Perplexed, I checked on the USBtinyISP by wiring the output from my connector straight to my board's headers using jumper wires, and that worked fine.  I played with various combinations of pull-up and pull-down resistors on the gate's inputs and outputs, and nothing seemed to do the trick.  I checked on the timing of the 7400-series chips, and all the ones I have are designed to typically operate at 50MHz.  This is many times faster than the USBtinyISP operates, and more than 3x faster than even my ATmega chips.  Therefore, it couldn't have been a timing issue; I had to assume it was an issue with the internal circuit.

Not being much of a circuit man myself, I attempted to jettison the '08 with another logic chip: the 74LS373 (octal D-latch).  This chip features eight "D" inputs and eight "Q" outputs.  As long as /OE is attached to ground (since it's active low, hence the slash) and L (the latch) is high, the signals going into D pass straight through Q.  However, once L is set to low, the values of Q freeze to whatever values D had right at the falling edge of the L signal (essentially, the very nanosecond L goes from high to low).  With L at ground, the inputs D can change all day long and never affect the outputs Q, so in essence, this chip is a (comparatively very expensive) form of memory.  For 1GB worth of RAM using standard DIP-socket '373 chips, it would cost you on the order of $100 million, even when buying in bulk from an electronics retailer.  That and I doubt there are even 1 billion of these chips in service or ready to be sold.  DRAM found in computers as conventional "memory" is far more efficient, but would be substantially more difficult to incorporate into this application (plus, it's really the latch behavior we're looking for anyway).

Now, I would need two '373 chips (because unfortunately there's no way to latch only 4 of the 8 outputs at a time), and would wire the switch output to the L pin on one '373 and the inverted switch output to the L pin on the other.  The four ISP signals would be routed into each D, and the output from this gate would be wired from Q into the headers on my LEDgoes panels.  There was just one problem; this approach failed too.  Even when wiring the special connector's outputs directly to my board, that failed.  I panicked, and it was getting late, so I simply called it a night.

Starting fresh the next day, I wired up each signal individually to the D-latch, and left the others passing straight through to the LEDgoes board.  I also found some wiring errors, and after correcting those, I was back on track with successful programming each time.  After hooking up just MOSI, testing it, and then adding SCK and RST successfully into the gate and seeing that programming still worked, I had real trouble with the MISO signal.  Every time I wired this signal from my special connector through the gate, programming would fail.  I tried various combinations of pull-up and pull-down resistors, and even load resistors.  I searched for schematics that might indicate how others corrected this problem, and without knowing what the impedance is on that particular signal compared to the others (and not finding any schematics with the answer), I had an epiphany:

You need all four signals present and synchronized for the ATmega chip to be programmed!

As such, it's OK if we just let MISO go straight through to both chips without passing through the gates first.  Without the presence of the other three signals, any fluctuations on MISO are meaningless.  Heck, even with two pins connected straight to both microcontrollers, it still shouldn't affect their contents anyway.  With this realization, I eliminated the need for a second 7400-series chip, and took the design back to a single '08 (quad AND) chip to do the job.  MOSI and MISO are both going straight through from the USBtinyISP to the pin headers on the boards, and only SCK and RST are getting toggled by the '08 chip.  Two of the gates are controlling SCK, two are controlling RST; and each of those gates receives input from either the switch or the inverted switch signal, thus only one chip at a time is seeing the SCK and RST signals.


Here's the jig I ended up designing.  I'll use the toner-transfer method to produce a PCB (with the top/red layer only) once I get approval from the "this makes sense" committee.


As a future project, it would be nice to ditch the physical switch and substitute that action for something the USBtinyISP could directly control.  What I envision would consist of perhaps an I2C-addressable register that would be set or cleared based on some combination or pattern of signals from the USBtinyISP.  With such a register, I could write a program to bit-bang the appropriate data from the USBtinyISP to switch that bit.  Or, perhaps I could use the GPIO pins on the Raspberry Pi to provide the whole feature set I need.  Once the electronics are done, I would write a script that incorporates the appropriate avrdude commands to write the firmware and check for validity of the output.  AVRdude outputs error messages when appropriate, but if it's something like a "Byte mismatch at 0x308: 0xFF != 0x37", then I tend to miss it (since it's not highlighted a different color on the terminal) and continue to work with the board, wondering why it's screwing up.

The circuit in a form that actually works.  Only MOSI & RST are going through the AND gates.

Thursday, January 2, 2014

Unboxing the Quo Computer

As fate would have it, I'm back to a nice pace of posts on the blog, especially since I've had a logjam of topics -- a bunch of ideas all came in at once.  This also means I get to usher my blog into 2014 on the very first Thursday of the new year, just in time for all the robots & spiders to come looking for new posts. ;)

Shortly before Christmas, I finally (and unexpectedly) received a Quo computer in the mail shortly before Christmas, just in time to install an ESX server right before the whole family came so they could have their own VMs on our server.  (They ended up bringing all their computers anyway, and used more electricity in 6 days than Stacy & I use by ourselves in a month. :-P)  Stacy pledged for this Kickstarter project back in March 2013, and for our particular system, the delivery date was expected to be June.  It still seems like we were one of the lucky ones to have received it by now.  The "unexpectedly" part comes in when, in early November, they finally sent us a tracking number, but the shipping company was waiting for the associated package for such a long time that we stopped even looking for updates there.  I was very surprised when it showed up at my door!

The biggest draw to the Quo computer is the relatively open firmware and UEFI BIOS, which facilitates the installation of Mac OSX and any other x86-compatible operating system onto the machine.  The Quo implementation of UEFI features not quite a graphical BIOS, but still keyboard and mouse-compatible, to facilitate setting up your boot order, chipset settings, and all those other goodies in the desired manner. It also provides the stock UEFI Shell for maximum flexibility and control, though it is a bummer to not have the scrollback capability to look at those extra-long printouts (like if you have a ton of hard drives and run the "map" command).

The legacy BIOS became obsolete probably 20 years ago, and a redesign was way overdue.  The mission-critical and enterprise space has seen UEFI going back at least 15 years with high-end HP/Intel servers, but it has only trickled down into the consumer space within the past couple years.  I could go on a pretty long diatribe about how UEFI is far superior to legacy BIOS (when done right, but it seems like most consumer hardware manufacturers were paid off quite nicely by Microsoft).  For one, you'll never have to tell the BIOS which drive to boot from; just set the UEFI Shell as the first boot option and go from there.  I'm sure most people like to configure GRUB to boot whatever OS they choose at that time, but I've always preferred changing that setting directly on the silicon.  Even better, though, is now you can choose your OS on the fly by simply navigating to the desired bootloader (yes, you can have multiple bootloaders), or even set up an "autoboot" to skip the UEFI Shell altogether and go directly into your OS of choice.  Autoboot was very easy for me to configure in my favorite flavor of Unix back in my days of messing around on big servers, but I haven't played around with setting it up in Windows, RHEL, Ubuntu, or any others.  (Granted, as a BIOS tester myself for enterprise servers at a very large computer company, I can attest to the many bugs Intel has in their UEFI reference code.  Oh well, we'll save that plus how to write UEFI Shell apps for another day as I haven't really put the UEFI Shell on the Quo through its paces yet.)  Though the UEFI Shell is basically its own OS, offering a robust command prompt, one of its few downsides is it's only single-threaded; you would need at least a very light operating system in order to take full advantage of your hardware.  Nevertheless, porting an NES emulator to UEFI is on my bucket list. :-D

I'll leave it to you to look at the specs of the "New Collector" edition that we pledged for, but we did ask for some additional upgrades including 16GB of DDR3 1600MT/s RAM and a nice Cooler Master(R) case.  The additional upgrades may have added to our wait time.  So, without further ado, here are pictures of the unboxing:

Not the box it was shipped in. :-P  I peeled that layer off first since it wasn't interesting.  However, as extra padding, they did box up the whole finished computer into the Cooler Master case box.

Also included was a pamphlet plus a T-shirt.  I think we already gave away the T-shirt to a relative.

Here's the top view of the system, now pulled out of the box.

The system has been removed from the wrapping.  This is not a small case.  The motherboard is laying flat toward the bottom of the grated area, and below it are four drive bays plus some additional 2.5" drive bays around the left side.  The system was pre-populated with an optical media drive plus a 1TB HDD.

Looking down from the top, you can easily see the motherboard.

This is a glimpse inside the case, where you can see the memory, CPU, and connectors.

Here's that UEFI Shell I was raving about earlier, complete with my little "UEFI Hello World" binary.  Even though there's definitely enough of UEFI that's open-sourced (through the EDK project), the toolchain to build UEFI binaries pretty much requires Microsoft Visual Studio.  Previously, I would test my binaries inside a special VirtualBox instance, but this ought to do me better.

And for those of you who were looking for a nice screenshot of this computer running OSX, perhaps with the results from some compelling benchmark test, sorry I made you read this far down only to tell you now that's not happening.  >-D  While I'm a supporter of running OSX on non-Apple hardware, I no longer have a reason to; in August, while awaiting this machine, my wife purchased this other computer at DEFCON for a very competitive price:

My real Macintosh

So there, the Quo will only be used for virtualization and UEFI experimentation.  Now, to just choose between Ubuntu Server Edition and Windows Server 2008, and which hypervisor to install underneath...