[Dhole], like the fox, isn’t the first to connect his computer to a Game Boy printer but he has done a remarkable job of documenting the process so well that anyone can follow. The operation is described well enough that it isn’t necessary to scrutinize his code, so don’t be put off if C and Rust are not your first choices. The whole thing is written like a story in three chapters.
The first chapter is about hacking a link cable between two Game Boys. First, he explains the necessity and process of setting the speed of his microcontroller, a NUCLEO-F411RE development board by STMicroelectronics. Once the rate is set, he builds a sniffer by observing the traffic on the cable and listens in on two Game Boys playing Tetris in competition mode. We can’t help but think that some 8-bit cheating would be possible if Tetris thought your opponent instantly had a screen overflowing with tetrominoes. Spying on a couple of Game Boys meant that no undue stress was put on the printer.
Chapter two built on the first chapter by using the protocol to understand how the printer expects to be spoken to. There is plenty of documentation about this already, and it is thoughtfully referenced. It becomes possible to convince a Game Boy that the connected microcontroller is a printer so it will oblige by sending an image. Since there isn’t a reason to wait for printing hardware, the transfer is nearly instantaneous. In the image above, you can see a picture of [Dhole] taken by a Game Boy camera.
The final chapter, now that all the protocols are understood, is also the climax where the computer and microcontroller convince the printer they are a Game Boy that wants to print an image. In the finale, we get another lesson about measuring controller frequency without an oscilloscope. If you are looking for the hack, there it is. There is a handful of success in the form of old receipts with superimposed grayscale images since virgin thermal printer paper by Nintendo costs as much as a used printer.
This story had a happy ending but grab your reading glasses for the smallest Game Boy and here’s someone who wrote their own Game Boy color game.
For anyone with interest in electric vehicles, especially drives and control systems for EV’s, the Endless-Sphere forum is the place to frequent. It’s full of some amazing projects covering electric skateboards to cars and everything in between. [Marcos Chaparro] recently posted details of his controller project — the VESC-controller, an open source controller capable of driving motors up to 200 hp.
[Marcos]’s controller is a fork of the VESC by [Benjamin Vedder] who has an almost cult following among the forum for “creating something that all DIY electric skateboard builders have been longing for, an open source, highly programmable, high voltage, reliable speed controller to use in DIY eboard projects”. We’ve covered several VESC projects here at Hackaday.
While [Vedder]’s controller is aimed at low power applications such as skate board motors, [Marcos]’s version amps it up several notches. It uses 600 V 600 A IGBT modules and 460 A current sensors capable of powering BLDC motors up to 150 kW. Since the control logic is seperated from the gate drivers and IGBT’s, it’s possible to adapt it for high power applications. All design files are available on the Github repository. The feature list of this amazing build is so long, it’s best to head over to the forum to check out the nitty-gritty details. And [Marcos] is already thinking about removing all the analog sensing in favour of using voltage and current sensors with digital outputs for the next revision. He reckons using a FPGA plus flash memory can replace a big chunk of the analog parts from the bill of materials. This would eliminate tolerance, drift and noise issues associated with the analog parts.
[Marcos] is also working on refining a reference design for a power interface board that includes gate drivers, power mosfets, DC link and differential voltage/current sensing. Design files for this interface board are available from his GitHub repo too. According to [Marcos], with better sensors and a beefier power stage, the same control board should work for motors in excess of 500 hp. Check out the video after the break showing the VESC-controller being put through its paces for an initial trial.
Continue reading “Open Source High Power EV Motor Controller”
Here’s a DEF CON talk that uses tools you likely have and it should be your next hacking adventure. In their Saturday morning talk [Mark Williams] and [Rob Stanely] walked through the process of adding their own custom code to a gaming mouse. The process is a crash course in altering a stock firmware binary while still retaining the original functionality.
The jumping off point for their work is the esports industry. The scope of esporting events has blown up in recent years. The International 2016 tournament drew 17,000 attendees with 5 million watching online. The prize pool of $20 million ($19 million of that crowdfunded through in-game purchases) is a big incentive to gain a competitive edge to win. Contestants are allowed to bring their own peripherals which begs the questions: can you alter a stock gaming mouse to do interesting things?
The steelseries Sensei mouse was selected for the hack because it has an overpowered mircocontroller: the STM32F103CB. With 128 KB of flash the researchers guessed there would be enough extra room for them to add code. STM32 chips are programmed over ST-Link, which is available very inexpensively through the ST Discovery boards. They chose the STM32F4DISCOVERY which runs around $20.
Perhaps the biggest leap in this project is that the firmware wasn’t read-protected. Once the data, clock, and ground pads on the underside of the board were connected to the Discovery board the firmware was easy to dump and the real fun began.
They first looked through the binary for a large block of zero values signifying unused space in flash. The injected firmware is designed to enumerate as a USB keyboard, open Notepad, then type out, save, and execute a PowerShell script before throwing back to the stock firmware (ensuring the mouse would still function as a mouse). Basically, this builds a USB Rubber Ducky into stock mouse firmware.
There are a few useful skills that make taking on this project a worthwhile learning experience. To compile your custom code correctly you need to choose the correct offset address for where it will end up once pasted into the firmware binary. The vector table of the original code must be rewritten to jump to the injected code first, and it will need to jump back to the mouse execution once it has run. The program flow on the left shows this. Both of these jumps require the program counter and registers to be saved and restored. The ARM stack is subtractive and the address will need to be updated to work with the added code.
The talk ended with a live demo that worked like a charm. You can check out the code in the MDHomeBrew repo. In this case the PowerShell script adds keyboard shortcuts for DOOM cheats. But like we said before, the experience of getting under the hood with the firmware binary is where the value will be for most people. With this success under your belt you can take on more difficult challenges like [Sprite_TM’s] gaming keyboard hack where the firmware couldn’t easily be dumped and an update binary was quite obsfucated.
[Mario] wrote us with his synthesizer project that’s currently up on Kickstarter. It looks like a good amount of fun to play with, as you can see in the video on the Kickstarter page. But it’s also built to be easily hackable.
On the hardware front, it’s a tiny four-layer board that’s crammed with parts. At the core is an STM32F4 microcontroller and a DAC. Indeed, the build was inspired by other folks’ work on the STM32F4 Discovery dev kit that has been used to make some pretty interesting synthesizer devices. [Mario]’s version adds two stereo headphone outputs, two microphone inputs, two IR reflective distance sensors used as control inputs, some buttons, and a ton of LEDs. And then it makes good use of all of them.
The firmware isn’t open source yet (poke! poke!) but it looks like it’s going to be. On his blog, [Mario] works through an example of adding a drum machine into the existing firmware, so it looks like it’ll be hackable.
Squeezing a lot of DSP functionality out of a single microcontroller is a feat. On a similar chip from a different manufacturer, [Paul Stoffregen]’s Teensy Audio Library could also be made to do a lot of the same things. But the real beauty of the Gecho project is that it has some interesting hardware features already built in and ready to go. It wouldn’t be a bad launching pad for your own musical or audio explorations.
There are a few 32-bit ARM-based 3D printer controller boards out there such as the Smoothieboard, the Azteeg X5 mini, [Traumflug]’s Gen5 electronics, whatever board is in the Monoprice MP Mini Select, and several others I will be criticized for not mentioning. All of these ARM boards provide smoother acceleration, better control, and ultimately better prints from whatever 3D printer they’re controlling. Now, out of the blue, there’s a new board. It’s an evaluation board from ST — much like those famous Discovery boards — that sells itself as a plug and play solution for 3D printers.
The heart of this board is an STM32F401 — not the king of the STM32 line or the fastest ARM microcontroller, but anything faster or more capable will add considerably more to the BOM for this board. This controller board features six of ST’s L6474 motor drivers with enough current for some beefy NEMA 23 stepper motors , a multi-zone heated bed, and connections for a WiFi module and external LCD and keypad. You can buy this board right now for $118. This board isn’t a game changer, but it is evidence the game has been changed.
As with all 3D printer controller boards, there are a few aspects that will leave users wanting more. This is a board meant for 12V heaters (except for the bed, which has a 24V, 20A output), and the stepper drivers can only go up to 16 microsteps. That said, there’s not much else to complain about. This offering comes with a 32-bit firmware called Marlin4ST. From a quick perusal, it looks like the familiar configuration.h is still there, and still does what it’s supposed to do.
This ST Discovery board is extremely capable, available now, and relatively cheap, but that’s not really the big story here. What this board represents is a reference design and working firmware for a 32-bit ARM-based printer controller. That’s the future, and with this board the future might come a little sooner.
Thanks [jagerboots] for sending this one in.
[Tom] sent this in to be filed under the ‘not a hack’ category, but it’s actually very interesting. It’s the User’s Guide for the Falcon 9 rocket. It includes all the data necessary to put your payload on a Falcon 9 and send it into space. It’s a freakin’ datasheet for a rocket.
A year ago in Japan (and last week worldwide), Nintendo released Pokkén Tournament, a Pokemon fighting game. This game has a new controller, the Pokkén Tournament Pro Pad. There were a few cost-cutting measures in the production of this game pad, and it looks like this controller was supposed to have force feedback and LEDs. If any Pokemon fans want to take this controller apart and install some LEDs and motors just to see what happens, there’s a Hackaday write up in it for you.
The STM32F4 is an extremely capable ARM microcontroller. It can do VGA at relatively high resolutions, emulate a Game Boy cartridge, and can serve as the engine control unit in a 1996 Ford Aspire. There’s a lot of computing power here, but only one true litmus test: the STM32F4 can run Doom. [floppes] built this implementation of Doom on the STM32F429 Discovery board to run off of an external USB memory stick. The frame rate is at least as good as what it was back in 1993.
The Oculus Rift has just come to pass, but one lucky consumer got his early. The first person to preorder the Rift, [Ross Martin] of Anchorage, Alaska, got his facehugger directly from [Palmer Luckey] in a PR stunt on Saturday afternoon. Guess what [Ross] is doing with his Rift?
To wrap up my quick tour through the wonderland of
make and makefiles, we’re going to look at a pair of possible makefiles for building ARM projects. Although I’m specifically targeting the STM32F407, the chip on a dev board that I have on my desk, it’s reasonably straightforward to extend these to any of the ST ARM chips, and only a bit more work to extend it to any ARM processor.
If you followed along in the first two installments of this series, I demonstrated some basic usages of
make that heavily leveraged the built-in rules. Then, we extended these rules to cross-compile for the AVR series of microcontrollers. Now we’re going to tackle a more complicated chip, and that’s going to mean compiling with support libraries. While not required, it’s a lot easier to get an LED blinking on the ARM platforms with some additional help.
One of the main contributions of an IDE like Arduino or mbed or similar is the ease of including external libraries through pull-down menus. If you’ve never built a makefile-based project before, you might be surprised how it’s not particularly more difficult to add libraries to your project.
Continue reading “Embed with Elliot: ARM Makefile Madness”