The New Bradford Embedded

Come join me at the new home for Bradford Embedded at BradfordEmbedded.com. After 24 January 2012, there won't be any new posts on the Blogger version.

If you're following me via RSS, you can get the new RSS, too.

Tuesday, January 24, 2012

Moving Day!

This is the last post to Bradford Embedded on the Blogger platform.

Come on over to the new BradfordEmbedded.com hosted on GitHub Pages. It has a full back-catalog.

I won't be removing my Blogger blog, it'll stay here since a lot of people find it via Google. There just won't be any new posts.

Wednesday, January 18, 2012

Moving Day Is Coming!

Shortly, Bradford Embedded will be moving away from Blogger!

The exact timing isn't set yet but I will be sure to post the new home prominently when it happens. I'm moving to a Jekyll generated blog hosted on GitHub pages. The goal is to have the transition go as smoothly as possible, so I'm taking it slow. Until I've fully switched over, all posts will show up on both platforms.

To see my progress - and the full archive of posts imported from Blogger - head on over to the new BradfordEmbedded.com.

Monday, January 16, 2012

Open Hardware Innovation - It's Coming...

I predict that within the next 2 years, open hardware designs really start giving semi-commodity hardware a run for its money.

Things like wifi routers, Ethernet switches, add-in cards, and input devices. The time of the somewhat specialty non-open hardware design is coming to an end.

Given the capabilities of the BeagleBoards and the neTV, Shapeways, lower cost FPGAs, open source micro controller development environments, and lower cost hardware design tools: there's going to be a really fun shake up the hardware landscape. Combine this low cost (to develop) tech with KickStarter type funding and I expect a large number of open hardware companies will emerge in the next few years.

The early adopters will be power users who don't mind a few inconveniences at first in order to support awesome products (just like on the web or with software). After about a year of an open hardware product being out, it'll start leaking into the masses. Then it will all be over. There will be a commoditization of hardware in the same way open / free software has commoditized a huge swath of the software landscape (open / free web servers run a HUGE portion of the web). Traditional vendors of hardware will start using the open / free hardware as a basis for their designs because it will be cost prohibitive to do otherwise.

We've seen this before with software. It's to the point now where if you're building a product with an embedded computer in it, you pick GNU/Linux (or Android which uses Linux, the kernel at least). It's too expensive to do otherwise, there's just such an awesome set of base open / free software available.

I'd love to be on the forefront of the open hardware wave. I'm not, yet. It's just starting now. I better get crackin'...

Friday, January 13, 2012

More BeagleBone USB Based Serial Port Rambling

I'm somewhat disappointed with the BeagleBone's USB based serial port setup to connect to a host PC. I've written about some of my frustration before, but it's only getting worse for me.

Now, sometimes (although not that often) when I plug the mini-USB cable into the BeagleBone while holding the reset button (to prevent booting) and open my serial terminal, when I release the reset I get garbage on the terminal and the Bone won't boot. Resetting the board a few times often fixes this, but is very annoying. Also, sometimes if I already have the Bone running with external power and then attempt to connect the mini-USB cable, I still sometimes get garbage in the terminal.

I'm not sure of the root cause, but it affects at least one of the BeagleBones I have on my desk (I have 3 total). It could very well be that minicom is somewhat to blame, I'm switching to picocom to see if that helps. Regardless, I'm now very much desiring a real serial port that avoids this whole FTDI chip business. It'd be nice to have a "real serial port cape" that provides DB9 connectors for one or two of the serial ports that are exposed through the expansion headers. Modifying the SPL, u-boot, and kernel to use a different UART isn't hard...

The main issue would be getting the boot loaders to read the cape I2C memory and realize that it should change the default UART output automatically. That's doable if people are willing to rebuild the bootloader (or download a precompiled version) and use it. It would be handy if the default BeagleBone bootloader supplied with the kit did this, but maybe that's asking a bit much. I should probably write up this idea on the BeagleBoard mailing list...

I think the goal of having one connection for USB, JTAG, and power was a good goal for the BeagleBone team. It's just that I don't really want that. Apparently I'm special :). Otherwise I do really like the BeagleBone. I'd personally prefer a real RS232 levels serial port, external power adapter (or PoE!), and a JTAG header (dedicated FTDI JTAG devices are under $100 from many vendors).

Thursday, January 12, 2012

Justifying Good Chairs

Good chairs aren't cheap. We're talking $800 for a high quality, new, warrantied, chair from a good supplier like Steelcase or Herman Miller.

But those same chairs, in great condition, on the used market generally can be had for $400 to $500. $400 isn't that expensive for a chair when you think about it.

Let's assume a quality engineer costs $100,000 per year (pay, benefits, taxes, and insurance) for a business. With 260 working days in a year (5 days per week, 52 weeks per year), that's $385 per day that the business is paying for the engineer's time.

What does that mean for chairs? It means that over the course of a 3 year span where a quality engineer works for you, it's cheaper to buy a $400 chair than it is to have that engineer miss 1/3 of one day of work (that's 3 hours) per year.

Or think of it this way, if having a good $400 chair makes your engineer 0.13% more efficient over 3 years, the chair pays for itself. That's 3 minutes more output per week! 3 minutes!

Or, brand new $800 chairs mean you need to get 6 minutes more work out of your 3 year engineer per week. Still not crazy, just over 1 minute per day more work to break even.

Fuck You, Windows!

Probably overheard at Microsoft during Windows 7 development due to security issues Microsoft has experienced in the past, "I've got an awesome idea for updates!"

That exclamation was probably quickly followed by, "Let's have Windows 7 default to automatically downloading any new updates over the internet and applying those updates in the middle of the night! It can even reboot, without prompting or authorization, if a reboot is needed!" And the Land of Microsoft rejoiced.

Then users who don't expect their machine to reboot at 3am arrive at work and their computer has decided to reboot, possibly losing work, and at the very least moving windows, forgetting current location in very long Word documents, and generally making the user feel like they've lost control.

So: Fuck You, Windows. Your shit stinks.

Side note: I don't mean to offend with my profanity. The title is literally what came out of my mouth when I arrived at work this morning and my Windows 7 VM had decided to reboot on its own.

Wednesday, January 11, 2012

HP Letting Us Down

I've written about my experiences with my EliteBook 8560w a few times. Two other guys in the office also got 8560ws around the same time I got mine. They both run Windows 7 (I know! The horror! :) and have the AMD graphics option. Overall, nice machines, but there's one little gotcha:

HP's 27" IPS monitor, the ZR2740w, refuses to be driven by the AMD chipset, with Windows 7 Pro 64 bit, over DisplayPort. We and HP have no idea why. I can plug my 8560w with NVIDIA graphics and Debian 6 into the ZR2740w, restart X (so it detects the monitor correctly instead of thinking it's my ZR2440w), and BAM!, I get the full 2560x1440 pixel glory.

My office mate has been on the phone with HP support for hours trying to get this fixed. So far, no dice. And we're not the only ones with issues.

It boggles my mind why this isn't a plug-n-play type operation. Especially if an NVIDIA card, on 64 bit Linux (Debian Stable no less!), can drive the monitor just the way it is supposed to be driven. HP's really disappointing with this one.

Side note: My ZR2440w and the ZR2740w are both "anti-glare" type monitors. There's a coating on the screen to disperse the light and make it matte. My ZR2440w has a pretty nice coating, I don't really notice it. The ZR2740w coating is much easier to notice, solid colors on the display look off, just not the solid single color I'd expect, almost like they're shimmering. I'm not a huge fan, but it's probably just something to get used to. I wonder, are other 27" panels with anti-glare the same? Or is HP's anti-glare somehow different than, say, Dell's?

UPDATE 20120111 4:00pm - HP's now saying it's an ATI driver issue and that ATI will have an updated driver by the end of January.