Modern home cinema equipment is well-equipped with features for interoperability and convenience, but in practice, competing standards and arcana can make it fall over. Sometimes, you’ve gotta do a little work on your own to glue it all together, and that’s what led [Victor] to develop a little utility of his own.
ChromecastControls is a tool that makes controlling your home cinema easier by improving Chromecast’s integration with the CEC features of HDMI. CEC, or Consumer Electronics Control, is a bidirectional serial bus that is integrated as a part of the HDMI standard. It’s designed to help TVs, audio systems, and other AV hardware to communicate, and allow the user to control an entire home cinema setup with a single remote. Common use cases are TVs that send shutdown commands to attached soundbars when switched off, or Blu-Ray players that switch the TV on to the correct output when the play button is pressed.
[Victor]’s tool allows Chromecast to pass volume commands to surround sound processors, something that normally requires the user to manually adjust their settings with a separate remote. It also sends shutdown commands to the attached TV when Chromecast goes into its idle state, saving energy. It relies on the PyChromecast library to intercept traffic on the network, and thus send the appropriate commands to other hardware. Simply running the code on a Raspberry Pi that’s hooked up to any HDMI port on a relevant device should enable the CEC commands to get through.
It’s a project that you might find handy, particularly if you’re sick of leaving your television on 24 hours a day because Chromecast never bothered to implement a simple CEC command on an idle timeout. CEC hacks have a long history, too – we’ve been covering them as far back as 2010!
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.
Speak with those who consider themselves hardcore engineers and you might hear “Arduinos are for noobs” or some other similar nonsense. These naysayers see the platform as a simplified, overpriced, and over-hyped tool that lets you blink a few LEDs or maybe even read a sensor or two. They might say that Arduino is great for high school projects and EE wannabes tinkering in their garage, but REAL engineering is done with ARM, x86 or PICs. Guess what? There are Arduino compatible boards built around all three of those architectures. Below you can see but three examples in the DUE, Galileo, and Fubarino SD boards.
Arduino DUE uses Atmel ARM
Arduino Galileo uses Intel x86
Fubarino SD uses PIC32
This attitude towards Arduino exists mainly out of ignorance. So let’s break down a few myths and preconceived biases that might still be lurking amongst some EEs and then talk about Arduino’s ability to move past the makers.
Arduino is NOT the Uno
When some hear “Arduino”, they think of that little blue board that you can plug a 9v battery into and start making stuff. While this is technically true, there’s a lot more to it than that.
An Arduino Uno is just an AVR development board. AVRs are similar to PICs. When someones says “I used a PIC as the main processor”, does that mean they stuck the entire PIC development board into their project? Of course not. It’s the same with Arduino (in most cases), and design is done the same way as with any other microcontroller –
Use the development board to make, create and debug.
When ready, move the processor to your dedicated board.
What makes an Arduino an “Arduino” and not just an AVR is the bootloader. Thus:
An Atmega328P is an AVR processor.
An Atmega328P with the Arduino bootloader is an Arduino.
The bootloader allows you to program the AVR with the Arduino IDE. If you remove the bootloader from the AVR, you now have an AVR development board that can be programmed with AVR Studio using your preferred language.
There Is No Special Arduino Language
Arduino “blink” sketch should run on any Arduino compatible board.
Yes, I know they call them sketches, which is silly. But the fact is it’s just c++. The same c++ you’d use to program your PIC. The bootloader allows the IDE to call functions, making it easy to code and giving Arduino its reputation of being easy to work with. But don’t let the “easy” fool you. They’re real c/c++ functions that get passed to a real c/c++ compiler. In fact, any c/c++ construct will work in the Arduino IDE. With that said – if there is any negative attribute to Arduino, it is the IDE. It’s simple and there is no debugger.
The strength comes in the standardization of the platform. You can adapt the Arduino standard to a board you have made and that adaptation should allow the myriad of libraries for Arduino to work with your new piece of hardware. This is a powerful benefit of the ecosystem. At the same time, this easy of getting things up and running has resulted in a lot of the negative associations discussed previously.
So there you have it. Arduino is no different from any other microcontroller, and is fully capable of being used in consumer products along side PICs, ARMs etc. To say otherwise is foolish.
What is the Virtue of Arduino in Consumer Products?
This is Ask Hackaday so you know there’s a question in the works. What is the virtue of Arduino in consumer products? Most electronics these days have a Device Firmware Upgrade (DFU) mode that allows the end user to upgrade the code, so Arduino doesn’t have a leg up there. One might argue that using Arduino means the code is Open Source and therefore ripe for community improvements but closed-source binaries can still be distributed for the platform. Yet there are many products out there that have managed to unlock the “community multiplier” that comes from releasing the code and inviting improvements.
What do you think the benefits of building consumer goods around Arduino are, what will the future look like, and how will we get there? Leave your thoughts below!
[Valkyrie-MT] was frustrated by the inability to control TrueHD audio volume from his computer. That’s because digital audio passes through the cable to the receiver where the volume adjustments are done. This meant that his RF computer remote was no good because the receiver uses an IR remote. He set out to find a way to get around this and ended up working with the Consumer Electronics Control (CEC) protocol.
The CEC protocol is a 1-wire serial bus built into the HDMI standard. The solution he settled up required one solder connection on the motherboard as well as the internal USB translator module seen above. That translator box, called the RainShadow, is a PIC 18F87J50 controlled board that translates incoming commands from the USB connection and sends them out as CEC hex codes. A bit of code writing and [Valkyrie-MT] is in business. You can see in the video after the break that it’s not just controlling audio, he can now control the entire entertainment center including turning on the TV and setting it to the appropriate input.
