ARM Dev Board With USB Uploading

July 31, 2013 by Brian Benchoff 42 Comments

[George and Bogdan] wrote in to tell us about a cool Kickstarter they’ve been working on. It’s called the MatchboxARM, and like other tiny-yet-powerful ARM dev boards floating around, this one features a very fast and capable processor and more than enough pins for just about any project. One interesting feature of this board, however, makes it stand out from the pack: it has a USB mass storage-based bootloader, meaning uploading new code is as easy as a drag and drop.

This isn’t the first dev board we’ve seen to sport this feature: the Stellaris Launchpad has had this for a while and even the lowly ATtiny85, in the form of a Digispark has a mass storage-based bootloader. The MatchboxARM, though, brings this together with a very powerful ARM microcontroller with enough I/Os, ADCs, PWM pins, and I2C and SPI ports for the most complicated projects.

Text Editor Running On Your ARM Project

July 11, 2013 by Mike Szczys 15 Comments

bare-metal-elua-text-editor

Tired of flashing your embedded project over and over just to tweak a few values? So was [Karl], so he wrote a text editor that runs on his ARM dev board.

Having trouble wrapping your mind around the need for this kind of thing? He’s actually playing around with eLua, the embedded version of the Lua programming language. In this case the program files are being stored on an SD card. But still, moving that back and forth between computer and embedded project gets old quickly. So he invested the time to write a rudimentary text editor that he interfaces through this terminal window. Above you can see the help screen which lays out all of the applications features. Right now it sounds like the only gotcha for this is the amount of RAM it needs to run. As it stands, the editor will now work an mbed board, but it works just fine on an STM Discovery.

Ambilight Clone Uses Video Pass-through; Needs No Computer

July 10, 2013 by Mike Szczys 54 Comments

To the best of our knowledge all of the Ambilight clones we’ve covered over the years have one thing in common. They need a computer to do the image processing. This one is different. The PCB seen on the ~~left~~ right is all you need for the video processing. The project is called SCIMO and is the handiwork of a hacker named [Keiang].

There are only few times that the DRM built into the HDMI standard has pissed us off. This is one of them. Because of HDCP and licensing issued revolving around HDMI [Keiang] didn’t use HDMI pass through. Instead he uses an HDMI to S-Video converter. This board acts as an S-Video pass through, analyzing the signal using an STM32 ARM chip before the video signal continues on to the television. It still produces a respectable picture, but wouldn’t it have been cleaner if he could have gone with the HDMI standard?

UPDATE: Thanks for the comments on this. It looks like the TV is getting an HDMI signal. The board is fed by the HDMI to S-Video converter which itself is getting HDMI in parallel with the television thanks to a splitter.

Where other examples use Boblight on a PC for processing this manages to do so as a standalone embedded system. It also offers quite a bit of flexibility when it comes to choosing the LEDs, supporting pixels that use DMX512, WS28xx, or TM18xx protocols.

Continue reading “Ambilight Clone Uses Video Pass-through; Needs No Computer” →

Simon Says Learn How To Program ARM Chips

July 5, 2013 by Mike Szczys 8 Comments

This breadboard version of a Simon Says game is a great way to try your skills on a new microcontroller platform. The eight-pin chip seen in the center of the board is an LPC810 microcontroller which [Hartmut Wendt] is just getting started with. It’s a rare example of a low-pin count DIP package for an ARM device (Cortext M0). The breadboard friendly footprint makes it easy to work with, but you could pull off the same build with a dev board like one of the STM discovery offerings or the Stellaris Launchpad boards.

Why is this a good way to learn? It involves input, output, and generating waveforms which we’d assume means timers (we didn’t dig through the source code which is available form the page linked above). Each colored button has a matching LED which blinks out the pattern which you must replicate to keep the game going; you know how Simon Says works, right?. At the same time a different pitch is played by the speaker on the right.

Another good exercise would be to take [Hartmut’s] code and port it for a different chip, be it ARM or otherwise.

Continue reading “Simon Says Learn How To Program ARM Chips” →

Bringing ELua To The Mbed

June 28, 2013 by Brian Benchoff 18 Comments

[Karl] loved his mbed – a tiny little ARM-powered microcontroller platform – but he wanted an interactive programming environment. BASIC just wasn’t cutting it, so he decided to bring eLua to his mbed.

When choosing an interactive development environment for microcontrollers, you generally have two choices: old or huge. Sure, there is a middle ground with Python on an ARM, but why not use something explicitly designed for microcontrollers?

To get eLua running on his mbed, [Karl] downloaded the latest version and plopped it on his mbed. The current version, 0.9, doesn’t have support for an SD card, severely limiting its usefulness. [Karl] got around this by wiring up an SD card to the mbed, giving him gigabytes of space for all his development work.

While the AVRs and PICs of the world are stuck with languages like C or worse, the new ARM boards available are more than capable of running a complete eLua development environment, with everything accessible through a terminal. [Karl] even wrote his own editor for the mbed and he’ll shortly be working on a few dozen embedded projects he has in mind.

HackIt: Sony Invites You To Hack Its SmartWatch Firmware

June 14, 2013 by Mike Szczys 63 Comments

This is Sony’s smart watch, which has been around for a while now. It’s designed for use with your Android phone, and has always included an SDK that allows app developers to interact with it. But now Sony is taking it one big step further. They’ve published everything you need to know to hack your own firmware for the SmartWatch.

The navigation scheme for that articles includes five menu items at the bottom which you’ll want to dig through. The most interesting to us was the one labeled “SmartWatch hacker guide”. It lays bare the hardware used in the watch and how it’s peripheral component connect to each other. This starts with the STM32 (ARM) microcontroller that drives the watch. It goes on to document how the screen is addressed (SPI1) including the pin to turn it on and off. The same goes for the Bluetooth, accelerometer, buzzer, and touch sensors.

Firmware is updated via USB using Device Firmware Upgrade (DFU) mode. We don’t don’t see any way to connect an on-chip debugger. We searched to see if there is a JTAG port on the circuit board and it sounds like getting the watch apart without breaking it is pretty tough.

Now that you don’t need to stick to what Sony had planned for the device, what do you want to do with your strapless wristwatch?

[Thanks Brian]

Benchmarking USB Transfer Speeds

June 3, 2013 by Brian Benchoff 46 Comments

boards

[Paul Stoffregen], creator of the Teensy series of microcontroller dev boards, noticed a lot of project driving huge LED arrays recently and decided to look into how fast microcontroller dev boards can receive data from a computer. More bits per second means more glowey LEDs, of course, so his benchmarking efforts are sure to be a hit with anyone planning some large-scale microcontroller projects.

The microcontrollers [Paul] tested included the Teensy 2.0, Teensy 3.0, the Leonardo and Due Arduinos, and the Fubarino Mini and Leaflabs Maple. These were tested in Linux ( Ubuntu 12.04 live CD ), OSX Lion, and Windows 7, all running on a 2012 MacBook Pro. When not considering the Teensy 2.0 and 3.0, the results of the tests were what you would expect: faster devices were able to receive more bytes per second. When the Teensys were thrown into the mix, though, the results changed drastically. The Teensy 2.0, with the same microcontroller as the Arduino Leonardo, was able to outperform every board except for the Teensy 3.0.

[Paul] also took the effort to benchmark the different operating systems he used. Bottom line, if you’re transferring a lot of bytes at once, it really doesn’t matter which OS you’re using. For transferring small amounts of data, you may want to go with OS X. Windows is terrible for transferring single bytes; at one byte per transfer, Windows only manages 4kBps. With the same task, Linux and OS X manage about 53 and 860 (!) kBps, respectively.

So there you go. If you’re building a huge LED array, use a Teensy 3.0 with a MacBook. Of course [Paul] made all the code for his benchmarks open source, so feel free to replicate this experiment.