Espruino Pico, Javascript On A USB Stick

October 29, 2014 by Brian Benchoff 39 Comments

There are probably very few official numbers for this, but web developers at least seem to outnumber the amount of people who regularly poke pins and registers with C. For them, the embedded world must be a scary and foreboding domain, full of bitwise operations and dynamic types. [Gordon] figured there was another way and built a Javascript interpreter for a microcontroller. The latest board built around this interpreter is up on Kickstarter, and its even smaller and more capable than his earlier version.

This isn’t [Gordon]’s first rodeo; last year he launched the (full-sized) Espruino, featuring an ARM Cortex M3 and his very own Javascript interpreter. The large-scale Espruino was a rousing success, and now he’s moving on to a smaller thumb drive-sized footprint for the Pico. The hardware is a bit better, relying on the ARM Cortex M4 STM32F4 with a bit more RAM, and this time the board is slightly cheaper. It still runs the same Javascript interpreter, though, so all the code is exactly what you’d expect.

We haven’t seen many projects using this tiny Javascript of Things, but the new layout does make it fantastically useful. Depending on how the crowd funding campaign turns out, [Gordon] might be adding socket, and USB HID support, along with inline C functions.

A Single Pixel, Color Digital Camera

October 20, 2014 by Brian Benchoff 29 Comments

[Ben] has written all sorts of code and algorithms to filter, sort, and convolute images, and also a few gadgets that were meant to be photographed. One project that hasn’t added a notch to his soldering iron was a camera. The easiest way to go about resolving this problem would be to find some cardboard and duct tape and built a pinhole camera. [Ben] wanted a digital camera. Not any digital camera, but a color digital camera, and didn’t want to deal with pixel arrays or lenses. Impossible, you say? Not when you have a bunch of integral transforms in your tool belt.

[Ben] is only using a single light sensor that outputs RGB values for his camera – no lenses are found anywhere. If, however, you scan a scene multiple times with this sensor, each time blocking a portion of the sensor’s field of view, you could reconstruct a rudimentary, low-resolution image from just a single light sensor. If you scan and rotate this ‘blocking arm’ across the sensor’s field of view, reconstructing the image is called a Radon transform, something [Ben] has used a few times in his studies.

[Ben]’s camera consists of the Adafruit RGB light sensor, an Arduino, a microSD card, a few servos, and a bunch of printed parts. The servos are used to scan and rotate the ‘blocking arm’ across the sensor for each image. The output of the sensor is saved to the SD card and moved over to the computer for post-processing.

After getting all the pixel data to his laptop, [Ben] plotted the raw data. The first few pictures were of a point source of light – a lamp in his workspace. This resulted in exactly what he expected, a wave-like line on an otherwise blank field. The resulting transformation kinda looked like the reference picture, but for better results, [Ben] turned his camera to more natural scenes. Pointing his single pixel camera out the window resulted in an image that looked like it was taken underwater, through a piece of glass smeared with Vaseline. Still, it worked remarkably well for a single pixel camera. Taking his camera to the great outdoors provided an even better reconstructed scene, due in no small part to the great landscapes [Ben] has access to.

Reverse Engineering Altium Files

October 15, 2014 by Brian Benchoff 71 Comments

Several times in the last few weeks, I’ve heard people say, ‘this will be the last PCB I design in Eagle.’ That’s bad news for CadSoft, but if there’s one thing Eagle has done right, its their switch to an XML file format. Now anyone can write their own design tools for Eagle without mucking about with binary files.

Not all EDA softwares are created equally, and a lot of vendors use binary file formats as a way to keep their market share. Altium is one of the worst offenders, but by diving into the binary files it’s possible to reverse engineer these proprietary file formats into something nearly human-readable.

[dstanko.au]’s first step towards using an Altium file with his own tools was opening it up with a hex editor. Yeah, this is as raw as it can possibly get, but simply by scrolling through the file, he was able to find some interesting bits hanging around the file. It turns out, Altium uses something called a Compound Document File, similar to what Office uses for Word and PowerPoint files, to store all the information. Looking through the lens of this file format, [dstanko.au] found all the content was held in a stream called ‘FileHeader’, everything was an array of strings (yeah, everything is in text), and lines of text are separated by ‘|’ in name=value pairs.

With a little bit of code, [dstanko] managed to dump all these text records into a pseudo plain text format, then convert everything into JSON. You can check out all the code here.

Playing StarCraft On An ARM

July 31, 2014 by Brian Benchoff 25 Comments

Starcraft

Except for the really terrible Nintendo 64 port, StarCraft has always been bound to desktop and laptop PCs. Blizzard could take the code for StarCraft, port it to an ARM platform, put a version on the Google Play an iTunes store, and sit there while the cash rolls in. This would mean a ton of developer time, though, and potentially years tracking down hard to find bugs.

Or one random dude on the Internet could port StarCraft to an ARM platform. Yes, this means all the zerg rushes and dark templar ambushes you could possibly want are available for tablets and Raspberry Pis.

This godlike demonstration of compiler wizardry is a months-long project of [notaz] over on the OpenPandora team. Without the source for StarCraft, [notaz] was forced to disassemble the Win32 version of the game, convert the disassembly to C with some custom tools, and recompile it for ARM while linking in all the necessary Win32 API calls from the ARM port of Wine. Saying this was not easy is an understatement.

If you have an OpenPandora and want to relive your heady days of youth, you can grab everything you need here. For anyone without an OpenPandora that wants to play StarCraft on a Raspi, you might want to get working on your own recompiled port. Video below.

Continue reading “Playing StarCraft On An ARM” →

Programming Pi Games With Bare Metal Assembly

June 23, 2014 by Brian Benchoff 21 Comments

pifox While the most common use for a Raspberry Pi is probably a media center PC or retro game emulator, the Pi was designed as an educational computer meant to be an easy-to-use system in the hands of millions of students. Team 28 at Imperial College London certainly living up to the Raspberry Pi Foundation’s expectations with their bare metal assembly clone of Star Fox, aptly titled PiFox.

This isn’t the first time a college course has taken up the task of developing software for the Pi without an operating system; a few years ago, Cambridge University started that off with a series of bare metal tutorials for the Pi that included drawing graphics on the screen and playing around with USB keyboards. PiFox greatly expands on what those early tutorials could do, reading an NES joystick from the GPIO pins, sound with DMA, and rendering 3D objects.

If you’d like to build PiFox for yourself, or better yet, expand on the existing build, all the code is up on Github. There’s also a Raspberry Pi emulator for Linux, just in case you have an ARM assembly bug you just can’t scratch with a Raspberry Pi.

Continue reading “Programming Pi Games With Bare Metal Assembly” →

The Sega Mega Drive Dev Kit

June 18, 2014 by Brian Benchoff 13 Comments

sega While most homebrew video game development has focused on the original NES, Atari consoles, and has produced a few SNES games, there is another console out there that hasn’t seen much love. Sega’s classic console, the Genesis or Mega Drive, depending on where you’re from, was an extremely capable machine with amazing capabilities for its time. [Chris] figured the Mega Drive would make a good target for an all-in-one development kit, and with a lot of work he managed to put one together.

The standard cartridge for the Genesis or Mega Drive is just a simple ROM chip wired directly into the console’s address space. [Chris] took a cheap FPGA and some dual port ram to create a seamless interface between the modern world and the inside of this ancient console, allowing him to load every Mega Drive game off an SD card, as well as use modern tools to modify old games, or even create new ones.

To demonstrate his dev kit, [Chris] took a copy of Sonic 1, and using the debugger and GDB, gave himself infinite lives. It’s a very cool demonstration, searching through all the commands executed by the Megadrive CPU with the standard Linux debugging tools.Going through the trace, [Chris] found the instruction that decremented that value representing Sonics lives, replaced it with NOPs, in effect giving himself infinite lives. This is a lot like how the Game Genie works, only using much, much better tools.

Of course a USB dev kit wouldn’t be much use if it could only modify existing games. The real power of [Chris]’ work comes from being able to develop your own demos, games, and homebrew apps.

[Chris] needed to write a small homebrew Mega Drive app for the ROM loader portion of his dev kit using SGDK. Disassembling his own code with the dev kit, he was able to take a look at the instructions, and potentially even modify his loader.

It’s a really impressive technical accomplishment, and something that could be a boon to the extremely small homebrew scene for the Mega Drive. All the boards, code, and everything else are available over on [Chris]’ github, with the entire project written up on hackaday.io. Videos below.

Continue reading “The Sega Mega Drive Dev Kit” →

MiniBloq IDE, Graphical Programming For Robots Of All Sizes

May 8, 2014 by Brian Benchoff 8 Comments

MiniBloq

The Arduino IDE only brings the ire of actual EEs and People Who Know Better™, but if you’re teaching robotics and programming to kids, you really don’t want something as simple as a text editor with a ‘compile’ button. For that educational feat, a graphical system would be much better suited. [Julián] has been working for months to build such a tool, and now miniBloq, the graphical programming tool for just about every dev board out there, has a new release.

The idea of a graphical programming language for robotics has been done before, most memorably with the Lego Mindstorms programming interface. That was closed source, of course, and only worked with the magical Lego brick that allowed you to attach motors and sensors to a child’s creation. miniBloq takes the same idea and allows the same programming environment to work with dozens of dev boards for robots of every shape and size. Already, the Pi-Bot, SparkFun RedBot, Maple, Multiplo DuinoBot, and anything based on an Arduino Leonardo works with miniBloq, as will any future dev boards that understand C/C++, Python, or JavaScript. It’s not just for powering motors, either: there’s a few Python and OpenCV tutorials that demonstrate how a robot can track a colored object with a camera.

The current version of miniBloq can be downloaded from the gits, with versions available for Windows and *nix. The IDE is written with wxWidgets, so this could also be easily ported to OS X.