Author Archives: Brian Benchoff

Apple Introduces Their Answer To The Raspberry Pi

via hardware – Hackaday

Today, Apple has announced their latest bit of hardware. Following in the tradition of the Raspberry Pi, BeagleBone, and the Intel Edison, Apple have released a single board computer meant for embedded and Internet of Things applications. It’s called the Apple Device, and is sure to be a game changer in the field of low-power, Internet-enabled computing.

First off, some specs. The Apple Device uses Apple’s own A8 chip, the same dual-core 64-bit CPU found in the iPhone 6. This CPU is clocked at 1.1 GHz, and comes equipped with 1GB of LPDDR3 RAM and 4GB of eMMC Flash. I/O includes a Mini DisplayPort capable of driving a 4k display, 802.11ac, Bluetooth, and USB. In a massive break from the Apple zeitgeist of the last decade or so, the Apple Device also includes a forty pin header for expansion, much like the Raspberry Pi, BeagleBone, and Edison.

Although Apple’s first foray into the embedded computing market is a shocker, in retrospect it should come as no surprise; the introduction of HomeKit in iOS 9 laid the groundwork for an Internet of Apple Devices, embedded into toasters, refrigerators, smart homes, and cars. The Apple Device lives up to all these expectations, but what is the hands-on experience like?

See our review of the Apple Device after the break.

Hero

The first question anyone should ask when discussing an Apple Internet of Things board is, ‘what operating system does it run?’ This is, by far, the most pressing concern – you don’t need a purely graphical OS with a headless machine, and you don’t want an OS that is locked down with proprietary cruft.

Of course. the idea that Apple is built upon proprietary and locked down operating systems is a myth. iOS and Mac OS are built on Darwin, an open source kernel based on BSD. This is the core of the DeviceOS, and booting the device (through a terminal, no less!) provides everything you could ever need in a tiny, single board computer.

Apple isn’t committing themselves to a purely command line board here, though. Apple hasn’t built a computer like that for more than 30 years. There’s a Mini DisplayPort on the Apple Device, and of course that means a GUI. It’s obviously not as capable as the full feature OS X, but it is very useful. It’s not iOS, either; I’d compare it to a Chromebook – just enough to do the job, and not much else.

User Experience

Using the Apple Device is dead simple. Just plug in a USB cable, open up a terminal, and you're in.
Using the Apple Device is dead simple. Just plug in a USB cable, open up a terminal, and you’re in.

While the Apple Device is intended to run headless most of the time, in fact it’s how Apple expects you to set this device up.

To power the device, all you need to do is connect the Device to a computer and open up a terminal. This drops you into the Device’s shell, with access to the entire unix-ey subsystem. Once the WiFi credentials are set, just unplug the device from the computer, plug it into a micro USB charger, and the Device is connected to the Internet.

This USB port isn’t just for power – it’s also the way to connect keyboards, mice, peripherals, and USB thumb drives. You will, however, need the Apple Powered Device USB Hub (sold separately), that breaks out the USB into four USB Type A ports while backpowering the Apple Device. It’s a brilliant physical user interface for a device that will run headless most of the time, but still requires a few ports to be useful.

Of course, if you’re not running the Apple Device headless, you’ll need to connect a monitor. This is where the Mini DisplayPort comes in. Boot the device with the Powered Device USB Hub, plug in a monitor, and you’re presented with a ‘desktop’ that’s not really OS X, and it’s not really iOS, either. It’s  minimal, and almost chromebook-esque.

The OS looks a little bit like OS X, but it’s not. Right now, the only programs available for the DeviceOS are the HomeKit app, the Safari browser, and playing around with the settings. If you want to look something up on the Internet, just click on the Safari icon. If you want to change the WiFi address or the device name, just go into the settings.

Configured as a Desktop, you can see the brilliance of Apple in the Device. It’s not a desktop computer, but neither is a Chromebook. Considering most people can do most of their work on the web, this is a game-changing device. Combine it with Apple’s iCloud, and you have something that will be exceptionally popular.

The Downside of Apple

Apple has their hands in a lot of cookie jars. The Apple TV is their device for streaming videos and music to a TV. Giving the Apple Device this functionality would cut into sales of the Apple TV. Since the Apple Device sells for $100 less than the Apple TV, this would be a bad move, even if Apple is sitting on Billions in cash.

Also, even though the Apple Device has a 40-pin header right on the board, there is no documentation anywhere of what these pins can be used for. The Raspberry Pi’s 40-pin header is well documented and can be used for everything from environmental sensors to VGA and audio output. Apple makes no mention of what these pins can do, although we do expect a few ‘shields’ to be released in short order.

Benchmarks

Built around the Apple A8 chip, the Apple Device is extremely capable, especially compared to its assumed competitors, the Raspberry Pi and Intel Edison.

Geekbench-3SALTmarkPassmark-Disk-IO

In terms of raw horsepower, the Apple Device handily beats out the Raspberry Pi 2 and the Intel Edison. This should be expected. The A8 chip in the Apple Device is extremely powerful and beats the other single board computers handily.

But what about graphics? The GPU in the Raspberry Pi is a huge reason why that board is popular, and being able to stream a few movies to the Apple Device would mean the Apple TV will be quickly taken out of production.

3D-MarkH.264

3D acceleration is better, but when it comes to h.264 encoding, the Apple Device falls a little short. Even compared to the rather sluggish Raspberry Pi Zero, the Apple Device is no match for the berry boards.

This is purely speculation, but I suspect h.264 encoding is disabled in the Apple Device. The reason is clear – Apple already sells a single board computer meant for streaming video to a TV. Giving the Apple Device the same capabilities as the Apple TV would cut into that market. Sadly, it looks like the video capabilities of the Apple Device are limited to digital signage. That’s disappointing, but given Apple’s strategy for the last twenty years, not unexpected. We do look forward to the eventual hack, root, or exploit that will unlock the powerful graphics capabilities the A8 chip already has.

Verdict

Right off the bat, the Apple Device is an amazing piece of hardware. It’s incredibly small, has a lot of computational power, and works with all the HomeKit devices you already own. The ability to just plug it into a computer and have a tiny *nix device connected to the Internet is great, and comparing the user interface to the Raspberry Pi, Beaglebone, or any of the Intel offerings isn’t even a fair comparison. Apple has taken the best design from their entire product line that anyone – including engineers and the tech literati – would find useful.

However, there are a few glaring limitations of the Apple Device. h.264 decoding is a big one, as the most popular use case of the Raspberry Pi seems to be setting up retro game emulators and streaming video from a network. Apple does what Apple will do, and the Device would probably cut into the market for the Apple TV.

Another shortcoming is the issue of the 40-pin header. Right now, there is no documentation whatsoever for the very small pin header located on the board. I couldn’t find anything in the *nix system relating to peripherals that might be connected to those pins. In any event, the pins are on a 1.0 mm pitch, making it very hard to plug a scope or meter onto one of those pins if you don’t have the mating connector. If anyone has seen this connector in the wild, I’d love to hear about it in the comments.

What Apple has done here is no different from the Raspberry Pi or any of the other ARM-powered single board computers released in recent years. They’ve taken a CPU from a smartphone that is now a few years old, added a few peripherals, and slapped it on a board. By itself, this is nothing new. That’s exactly what the Raspberry Pi is, and what all of the Raspberry Pi ‘clones’ are, from the Banana Pi to the Odroid.

While the hardware is somewhat predictable, the software is where this really shines. It’s not built for iOS, given this device is designed to run headless most of the time. It can be used purely through a command line, making this the perfect device for the Internet of Things. It’s also a tiny desktop computer, and somewhat usable given the power of the A8 chip. Since the Apple Device sells for about $50, Apple really hit it out of the park with this one, despite the obvious and not so obvious shortcomings. We’re really looking forward to Apple taking the popularity of the Raspberry Pi and other single board computers to the next level, and this is the device that will do it.

As a quick aside, it should be noted the Apple Device is technically Apple’s second single board computer. The first Apple product, the Apple I, released in 1976, would today fall into the same market as the Raspberry Pis, Beaglebones, and now the Apple Device. If you take the launch of the Apple I to be the date Apple was founded (April 1, 1976), today is the 40th anniversary of the first Apple product. The Apple I is now a museum piece and the finest example of Apple’s innovation over the years. The Apple Device follows in this tradition, and is nearly guaranteed to be held in as high regard as the board that came out of the [Steve]s’ garage.


Filed under: Featured, hardware, iphone hacks

Winning the Console Wars – An In-Depth Architectural Study

via Hackaday » hardware

From time to time, we at Hackaday like to publish a few engineering war stories – the tales of bravery and intrigue in getting a product to market, getting a product cancelled, and why one technology won out over another. Today’s war story is from the most brutal and savage conflicts of our time, the console wars.

The thing most people don’t realize about the console wars is that it was never really about the consoles at all. While the war was divided along the Genesis / Mega Drive and the Super Nintendo fronts, the battles were between games. Mortal Kombat was a bloody battle, but in the end, Sega won that one. The 3D graphics campaign was hard, and the Starfox offensive would be compared to the Desert Fox’s success at the Kasserine Pass. In either case, only Sega’s 32X and the British 7th Armoured Division entering Tunis would bring hostilities to an end.

In any event, these pitched battles are consigned to be interpreted and reinterpreted by historians evermore. I can only offer my war story of the console wars, and that means a deconstruction of the hardware.

An Architectural Study of the Sega Genesis and Super Nintendo

The traditional comparison between two consoles is usually presented as a series of specs, a bunch of numbers, and tick marks indicating which system wins in each category. While this does illustrate the strengths and weaknesses of each console, it is a rhetorical technique that is grossly imprecise, given the different architectures. The usual benchmark comparison is as follows:

Specs

Conventional wisdom – and people arguing on the Internet – tells you that faster is better, and with the Sega console having a higher clock speed it’s capable of doing more calculations per second. Sure, it may not be able to draw as many sprites on the screen as the SNES, but the faster processor is what allowed the Genesis / Mega Drive to have ‘faster’ games – the Sonic series, for example, and the incredible library of sports games. It’s an argument wrapped up in specs so neatly this conventional wisdom has been largely unquestioned for nearly thirty years. Even the Internet’s best console experts fall victim to the trap of comparing specs between different architectures, and it’s complete and utter baloney.

Let’s take a look at one of these numbers – the CPU speed of the SNES and the Genesis/Mega Drive. The SNES CPU, a Ricoh 5A22 is based on the 65C816 core, an oft-forgotten 16-bit offshoot of the 6502 and related chips found in everything from the Apple II, Commodore 64, and even the original Nintendo NES. The 5A22 inside the SNES is clocked at around 2.68 MHz for most games. The Sega used a 68000 CPU clocked at 7.67 MHz. By comparing just these two numbers, the SNES wins, but this isn’t necessarily the truth.

In comparing the clock speed of two different CPUs, we’re merely looking at how frequently the bus is accessed, and not the number of instructions per second.

In the 68000, each instruction requires at least eight clock cycles to complete, whereas the 65C816 – like it’s younger 6502 brother – could execute an instruction every two or three clock cycles. This means the Sega could handle around 900,000 instructions per second, maximum. The SNES could compute around 1.7 Million instructions per second, despite it’s lower clock speed.

Even though the Sega console has a faster clock, it performs fewer instructions per second.

And so we come to the crux of the argument; the statistics of the great console wars, while not wrong, are frequently misinterpreted. How then do we decide an outcome?

The Architecture of the Sega Genesis / Mega Drive

genesis_block_diagram
While the Sega Genesis/Mega Drive is usually cited as having a 68000 CPU, this isn’t a complete picture of what’s going on inside the Sega console. In effect, the Genesis is a dual-processor computer with two CPUs dedicated to different tasks. The 68000 handles game logic and graphics, but surprisingly not much else. A Z80 — a CPU introduced a decade before the Genesis/Mega Drive — is used for reading the state of the game pads, and playing audio.

Interestingly, the Sega Genesis / Mega Drive contains most of the components of Sega’s earlier console, the Sega Master System. With the addition of a Power Base Converter, Master System games can be played while the 68000 CPU is in idle.

The  Architecture of the Super Nintendo

SNES-BLOCK-DIAGRAM

The SNES is a different beast entirely. Everything is controlled through the 5A22 / 65816 CPU. The controllers are fed right into the data lines of the 5A22, and DMA instructions are able to shuttle data between the two slightly different Picture Processing Units.

An interesting difference between the two consoles are the connections between the cartridge slot and various peripheral chips. Nearly the entire cartridge connector of the Sega machine is dedicated to the address and data lines for the 68000 CPU. While there are a few control signals thrown in, it’s not enough to allow the cartridge direct access to the video display unit or the FM synthesis chip.

The cartridge connector for the SNES, on the other hand, has direct access to one picture processing unit and the audio processor. The exploitation of this capability was seen in games ranging from Star Fox with it’s SuperFX chip, to Mega Man X games with its math coprocessor, to Super Mario RPG: Legend of the Seven Stars and its Super Accelerator 1 chip that is basically an upgraded version of the main SNES CPU, the 5A22.

Comparative designs, and who won the console wars

Time to make a holistic analysis of each competing platform. By far, the SNES is a more capable console; its cartridges are able to send data directly to the PPUs and audio processors, it’s faster, and there’s more work RAM, vRAM, and audio RAM.

The Sega 'Tower of Power'. Image credit /u/bluenfee
The Sega ‘Tower of Power’. Image credit /u/bluenfee

The Genesis / Mega Drive may be seen as more expandable thanks to the Sega CD (the first CD-ROM based game console, the Sega 32X), an upgraded coprocessor for the Genesis, backwards compatibility with a Master System Power Base converter, and a number of strange cartridges like Sonic and Knuckles with ‘lock-on’ technology. However, it’s actually the SNES that is more expandable. This is most certainly not the conventional wisdom, and the difference is due to how expandability was implemented in each console.

To add additional capabilities to the SNES, game designers would add new chips to the game cartridge. Star Fox famously exploited this with the SuperFX chip, and the list of SNES enhancement chips is deserving of its own entry in Wikipedia.

In comparison, the Genesis / Mega Drive could only be expanded through kludges – either through abusing the ASIC chip between the 68000 and Z80 CPUs, or in the case of the 32X add-on, bypassing the video display unit entirely.

In any event, this is purely an academic exercise. Games sell consoles, and Nintendo’s IP portfolio – even in the early 90s – included characters that had their own cartoons, live action movies, and cereals.

While this academic exercise is completely unimportant today – there probably won’t be a game console that ships with cartridges any more – it is an interesting case study on extendable computer design.


Filed under: computer hacks, Featured, hardware

Becoming A Zombie with the Hackable Electronic Badge

via Hackaday » hardware

Last week, Parallax released an open hackable electronic badge that will eventually be used at dozens of conferences. It’s a great idea that allows badge hacks developed during one conference to be used at a later conference.

[Mark] was at the Hackable Electronics Badge premier at the 2015 Open Hardware Summit last weekend, and he just finished up the first interactive hack for this badge. It’s the zombie apocalypse in badge form, pitting humans and zombies against each other at your next con.

The zombie survival game works with the IR transmitter and receiver on the badge normally used to exchange contact information. Upon receiving the badge, the user chooses to be either a zombie or survivor. Pressing the resistive buttons attacks, heals, or infects others over IR. The game is your standard zombie apocalypse affair: zombies infect survivors, survivors attack zombies and heal the infected, and the infected turn into zombies.

Yes, a zombie apocalypse is a simple game for a wearable with IR communications, but for the Hackable Electronics Badge, it’s a great development. There will eventually be tens of thousands of these badges floating around at cons, and having this game available on day-one of a conference will make for a lot of fun.


Filed under: cons, hardware, wearable hacks

DEF CON: HDMI CEC Fuzzing

via Hackaday » hardware

HDMI is implemented on just about every piece of sufficiently advanced consumer electronics. You can find it in low-end cellphones, and a single board Linux computer without HDMI is considered crippled. There’s some interesting stuff lurking around in the HDMI spec, and at DEF CON, [Joshua Smith] laid the Consumer Electronics Control (CEC) part of HDMI out on the line, and exposed a few vulnerabilities in this protocol that’s in everything with an HDMI port.

CEC is designed to control multiple devices over an HDMI connection; it allows your TV to be controlled from your set top box, your DVD player from your TV, and passing text from one device to another for an On Screen Display. It’s a 1-wire bidirectional bus with 500bits/second of bandwidth. There are a few open source implementations like libCEC, Android HDMI-CEC, and even an Arduino implementation. The circuit to interface a microcontroller with the single CEC pin is very simple – just a handful of jellybean parts.

[Joshua]’s work is based off a talk by [Andy Davis] from Blackhat 2012 (PDF), but greatly expands on this work. After looking at a ton of devices, [Joshua] was able to find some very cool vulnerabilities in a specific Panasonic TV and a Samsung Blu-ray player.

A certain CEC command directed towards the Panasonic TV sent a command to upload new firmware from an SD card. This is somewhat odd, as you would think firmware would be automagically downloaded from an SD card, just like thousands of other consumer electronics devices. For the Samsung Blu-Ray player, a few memcpy() calls were found to be accessed by CEC commands, but they’re not easily exploitable yet.

As far as vulnerabilities go, [Joshua] has a few ideas. Game consoles and BluRay players are ubiquitous, and the holy grail – setting up a network connection over HDMI Ethernet Channel (HEC) – are the keys to the castle in a device no one  would ever think of taking a close look at.

Future work includes a refactor of the current code, and digging into more devices. There are millions of CEC-capable devices out on the market right now, and the CEC commands themselves are not standardized. The only way for HDMI CEC to be a reliable tool is to figure out commands for these devices. It’s a lot of work, but makes for a great call to action to get more people investigating this very interesting and versatile protocol.


Filed under: cons, hardware

BeagleBone Green Hands-On: Lower Price, Same Horsepower

via Hackaday » hardware

Although the BeagleBone Green was announced at the Bay Area Maker Faire last May, there hasn’t been much said about it on the usual forums and IRC channels. Now, it’s finally out and I got my hands on one of them. Through a cooperation between the BeagleBoard foundation and Seeed Studios, the best small Linux board for doing real work with small Linux boards is now cheaper, a little more modern, and green.

The BeagleBone Green is an update to the venerable BeagleBone Black, the dev board based on a TI ARM Cortex-A8. It’s an extremely capable machine with a few interesting features that make it the perfect device for embedded applications. With the BeagleBone Green, the BB Black gets a small hardware refresh and a drastic reduction in price. If you want to do real work on a Linux board, this is the one to get. Check out the review below for everything that’s been updated, everything that’s the same, and why this is one of the most interesting developments in small Linux boards in recent memory.

The Differences From The BeagleBone Black

BlackVGreen
The BeagleBone Black and BeagleBone Green back to back

The BeagleBone Black has been around for more than two years now, but it’s still an extremely capable machine. The BeagleBone Green borrows heavily from the Black, with a few changes to satisfy the cost-reduction goal, and to make the BB Green slightly more accessible.

By far the largest change is the removal of the microHDMI connector. This is accompanied by a large bare spot on the board where the NXP HDMI Framer chip once was on the BB Black. When I talked to [Jason Kridner] his justification for the removal of the HDMI capability of the Green was that ‘nobody used it.’ This is fair and true; if you want a media server, you get a Raspberry Pi, and if you want a tiny Linux box to toggle pins very quickly, you get a BeagleBone. The removal of HDMI plays to the BeagleBone’s strengths, and makes it a less expensive board. You can’t argue with that.

Also on the list of changes are the addition of two Grove connectors. These connectors are part of a modular system of electronics that put a UART or I2C bus on a single connector. With these connectors and a few modules from the Grove System, building simple projects is a snap. The addition of two Grove connectors – one UART, one I2C – is Seeed’s largest contribution to the BeagleBone Green, and with a large catalog of parts ranging from simple logic gates to OLED displays and GPS modules, it’s pretty handy.

oled
Grove modules, like this OLED display, are plug and play with the BeagleBone Green

Aside from those changes, the BeagleBone Green is pretty much exactly the same as the BeagleBone Black. It has the same amount of RAM, the same processor, the same amount of eMMC Flash, and the same pinout as the BB Black. The Green moves to a USB micro connector for the power and serial connection. This had been USB mini on the BeagleBone Black. That’s a welcome change that’s long overdue. The barrel jack for power has been removed from the BeagleBone Green, and the larger USB port has been moved right next to the Ethernet socket.

As is the case with the BeagleBone Black, the Green comes with the Cloud 9 IDE already installed on the Linux image on the eMMC. This is a cloud-based IDE, but is hosted on the BeagleBone. For a device that really isn’t meant to be a desktop computer, this is the easiest way to get code up and running on a tiny Linux box. Combine this with a serial terminal, and it’s really all you need.

Why It’s Great

Although the BeagleBone Black has been around for a while now, and the BeagleBoard even longer, the Beagles have been playing second fiddle to the Raspberry Pi forever. This is a shame. The Raspberry Pi is not the ideal tool if you want real-time control of a lot of pins, and the GPIO expansion on the Pi is more of a kludge than something it was designed for.

In contrast, the BeagleBone – with its fancy PRUs – is designed for futzing around with GPIOs under Linux very fast. It’s been used as a video card for an old Mac, and to drive an awe-inspiring, blinding amount of RGB LEDs, among thousands of other interesting and hardcore projects.

The removal of the HDMI port in the BeagleBone Green doesn’t make this board any less capable. Like I mentioned above, nobody used it anyway. Add to that the fact you can buy an LCD cape for the BBG – and have it work with the 3D accelerator – and you’re really not losing any capability, just shaving sixteen bucks off the price. The BBG will launch with a $39 price tag, or about the same price as a Raspberry Pi. While it won’t impress many people that want a cheap Linux box for retro video game emulation, it is a great board for anyone who wants to get real work done.


Filed under: hardware, reviews

Learning From Transparent Microchips

via Hackaday » hardware

Microchips and integrated circuits are usually treated as black boxes; a signal goes in, and a signal goes out, and everything between those two events can be predicted and accurately modeled from a datasheet. Of course, the reality is much more complex, as any picture of a decapped IC will tell you.

[Jim Conner] got his hands on a set of four ‘teaching’ microchips made by Motorola in 1992 that elucidates the complexities of integrated circuitry perfectly: instead of being clad in opaque epoxy, these chips are encased in transparent plastic.

The four transparent chips are beautiful works of engineering art, with the chip carriers, the bond wires, and the tiny square of silicon all visible to the naked eye. The educational set covers everything from resistors, n-channel and p-channel MOSFETS, diodes, and a ring oscillator circuit.

[Jim] has the chips and the datasheets, but doesn’t have the teaching materials and lab books that also came as a kit. In lieu of proper pedagogical technique, [Jim] ended up doing what any of us would: looking at it with a microscope and poking it with a multimeter and oscilloscope.

While the video below only goes over the first chip packed full of resistors, there are some interesting tidbits. One of the last experiments for this chip includes a hall effect sensor, in this case just a large, square resistor with multiple contacts around the perimeter. When a magnetic field is applied, some of the electrons are deflected, and with a careful experimental setup this magnetic field can be detected on an oscilloscope.

[Jim]’s video is a wonderful introduction to the black box of integrated circuits, but the existence of clear ICs leaves us wondering why these aren’t being made now. It’s too much to ask for Motorola to do a new run of these extremely educational chips, but why these chips are relegated to a closet in an engineering lab or the rare eBay auction is anyone’s guess.


Filed under: hardware