Skip to main content

Posts

What's next for Beagleboard.org and the Beaglebone Black?

The Beaglebone Black, Raspberry Pi, and other low cost SBCs have altered the embedded computing landscape with high end capabilities and low price points. It has been amazing to watch the shift from systems like the Arduino in 2005 (16MHz cpu, 2k of ram), to the Pi in 2012 (700MHz cpu, 256MB of ram). I've been working with the Beaglebone Black (BBB) for a few years now, almost since it was released in 2013. While the Raspberry Pi is the volume leader by far, and has been around for longer, since 2012, the Pi uses a Broadcom SoC that isn't available through low volume distribution channels. The BBB on the other hand uses the TI Sitara AM335x which can be had through common enough places as DigiKey . This availability means that the BBB can be an ideal prototype platform for both hobby and commercial use. You can begin with the off the shelf BBB and then build a custom board around the AM335x SoC or, because the design files for the BBB are open, customize the BBB's desig...

Test driving the BMW i3

I had an opportunity to test drive the BMW i3 while attending CES 2015. The i3 is an electric vehicle (ev) with the option for a small gas engine generator that can extend its driving range. The ev model has an estimated range of ~80 miles while the range extender model ( REx ) a range of ~150 miles, with an electric range dropping to ~70 miles due to the extra weight of the gas engine, generator, and fuel. As an owner of a poor mans partial ev, the Toyota Plug-in Prius with ~10 miles of ev range, I was interested in driving an i3. I also haven't had the opportunity to drive any of the other EVs on the market. The BMW exhibit was outside of the south hall of the convention center. i3s were readied for the test drive after self-driving at 1 mph down a corridor. The self-driving demo wasn't very impressive, especially after watching Tesla's self-driving demo at speed, lane changes, and stopping behind a parked car. In my opinion the i3 isn't a good lookin...

doxie go goes from awesome to meh

I purchased a Doxie Go with Eye-fi Connect X2 SD card in November of 2012. The Doxie Go is a small, usb rechargeable document scanner with an SD card slot in the back. As the scanner saves files to the SD card, t he Eye-fi SD card  pushes the files to web services like Evernote, Flickr and others via wifi. The Eye-fi card enables a user to add wifi-support to existing devices, like the Doxie, cameras, and other devices that use an SD card. Imagine being able to scan documents and have them go directly to a cloud service, without having to receive them through your computer and then push them out to the cloud. We've been able to scan probably close to a thousand documents with Doxie in the last couple of years. Our workflow was pretty simple. We kept the Doxie on the counter in the kitchen. - Open mail - Power on Doxie - Feed the document through - Put the document into the recycling bin We had the Eye-fi configured to push directly to Evern...

From iPhone to Samsung's Galaxy S5

Samsung Galaxy S5 Impressions and experiences I've been a long time iPhone user, from the iPhone 2G , to the 3GS, 4 and then the 5, I've been almost exclusively using iPhones for the past several years. For nearly all of this time an iPhone has been my only Apple product. It's difficult to think back to a time before the iPhone. Smart phones had resistive touch screens, you had to push hard and use a stylus to get reasonable touch precision. PDAs typically didn't have Internet connectivity and data plans from cell carriers were expensive. Voicemail was something you dialed in to check. Apple's iPhone changed the definition of what it meant to be a smartphone. This was so disruptive that it basically drove Blackberry, Nokia, Ericsson and Sony out of the smart phone business. I've been quite happy with the iPhone. It's simple, reliable and relatively extendable via apps. Apple does restrict what you can do to the iPhone. You won't have full co...

Drupal 7 multi-site installation

Background This is a guide for setting up a multi-site Drupal configuration that I put together when re-installing a hosted server. I'm using Fedora 20 on the server so there are F20 specific individual instructions and commands. You may have to adjust these steps slightly for your specific distribution. This multi site installation is a bit of a different approach from the official Drupal 7 (the version currently released) INSTALL.txt . Drupal does have a bunch of documentation around multi-site installations that you might want to look at. The approach of this multi-site drupal configuration is to set up a series of per-site directories, databases and configurations. Some other approaches use a single database but this approach was chosen to make it easier to move or migrate a site from one server to another as well as to simplify upgrading Drupal with new releases. For the purposes of this guide I’ve used {site1} and {site2} for the two sites. You can have as many s...

Memory efficient queuing of variable length elements

In embedded environments memory can be a critical driver of the design of data structures and containers. Computing resources have been expanding steadily each year but there are still a wide range of systems with far less than a megabyte of memory. On systems with tens of kilobytes of memory, structures are often designed to be compact to maximize data density. Rather than splurging on memory aligned elements that would be faster for the processor to access, a developer will typically use types with minimal sizes based on the known range of values that the element is intending to hold. Fixed sized buffers At my day job a fixed size pool of messages was implemented to hold message data. While this achieved one design goal of using statically allocated buffers, avoiding dynamic allocations that might fail at runtime, it isn't efficient if there is a wide range of message sizes. It isn't efficient because each message uses a message buffer. With small message sizes the buff...

Yocto recipe SRC_URI for a BitBucket / GitHub ssh git repository

This is a particularly geeky post but because Google searches didn't turn up any information I thought it would be helpful to document the issue and solution for others. I was writing  Yocto recipes that pulled from BitBucket git repositories in ssh form and ran into several issues getting a SRC_URI that worked. GitHub uses the same syntax for their ssh repositories. A BitBucket / GitHub git url, in ssh form, looks like: < username >@bitbucket.org:< account name >/< repository name >.git a more concrete example for a git repository in one of my BitBucket accounts looks like: git@bitbucket.org:cmorgan/somerepository.git Yocto recipes can pull from git repositories by setting the SRC_URI variable appropriately. Unfortunately you can't just do: SRC_URI = "git@bitbucket.org:cmorgan/somerepository.git You'll get errors because the Yocto won't know what kind of url this is. You need to specify the protocol for Yocto to k...