After the release of Mortal Kombat X, [Zachery’s] gaming group wanted to branch out into the fighter genre. They quickly learned that in order to maximize their experience, they would need a better controller than a standard gamepad. A keyboard wasn’t going to cut it either. They wanted a fight stick. These are large controllers that look very much like arcade fighting controls and include a joystick and large buttons. [Zachery’s] group decided to build their own fight stick for use with a PC.
[Zachery] based his build around the TeensyLC, which is a 32 bit development board with an ARM processor. It’s also compatible with Arduino. The original version of his project setup the controller as a HID, essentially emulating a keyboard. This worked for a while until they ran into compatibility issues with some games. [Zachery] learned that his controller was compatible with DirectInput, which has been deprecated. The new thing is Xinput, and it was going to require more work.
Using Xinput meant that [Zachery] could no longer use the generic Microsoft HID driver. Rather than write his own drivers, he decided to emulate the XBOX 360 controller. When the fight stick is plugged into the computer, it shows up as an XBOX 360 controller and Windows easily installs the pre-built driver. To perform the emulation, [Zachery] first had to set the VID and PID of the device to be identical to the XBOX controller. This is what allows the Microsoft driver to recognize the device.
Next, the device descriptor and configuration descriptor had to be added to the Teensy’s firmware. The device descriptor includes information such as USB version, device class, protocol, etc. The configuration descriptor includes additional information about the device configuration. [Zachery] used Microsoft Message Analyzer to pull the configuration descriptor from a real XBOX 360 controller, then used the same data in his own custom controller.
[Zachery] programmed the TeensyLC using the Arduino IDE. He ran into some trouble here because the IDE did not include the correct device type for an Xinput device. [Zachery] had to edit the boards.txt file and add three lines of code in order to add a new hardware device to the IDE’s menu. Several other files also had to be modified to make sure the compiler knew what an Xinput device type was. With all of that out of the way, [Zachery] was finally able to write the code for his controller.
In this post on the Arduino.cc forums and this blog post, [Majek] announced that he had fooled the AVR microcontroller inside and Arduino into writing user data into its own flash memory during runtime. Wow!
[Majek] has pulled off a very neat hack here. Normally, an AVR microcontroller can’t write to its own flash memory except when it’s in bootloader mode, and you’re stuck using EEPROM when you want to save non-volatile data. But EEPROM is scarce, relative to flash.
Now, under normal circumstances, writing into the flash program memory can get you into trouble. Indeed, the AVR has protections to prevent code that’s not hosted in the bootloader memory block from writing to flash. But of course, the bootloader has to be able to program the chip, so there’s got to be a way in.
The trick is that [Majek] has carefully modified the Arduino’s Optiboot bootloader so that it exposes a flash-write (SPM) command at a known location, so that he can then use this function from outside the bootloader. The AVR doesn’t prevent the SPM from proceeding, because it’s being called from within the bootloader memory, and all is well.
The modified version of the Optiboot bootloader is available on [Majek]’s Github. If you want to see how he did it, here are the diffs. A particularly nice touch is that this is all wrapped up in easy-to-write code with a working demo. So next time you’ve filled up the EEPROM, you can reach for this hack and log your data into flash program memory.
Thanks [Koepel] for the tip!
[Daniel] found himself with a need to connect a single USB device to two Linux servers. After searching around, he managed to find an inexpensive USB switch designed to do just that. He noticed that the product description mentioned nothing about Linux support, but he figured it couldn’t be that hard to make it work.
[Daniel] started by plugging the device into a Windows PC for testing. Windows detected the device and installed an HID driver automatically. The next step was to install the control software on the Windows system. This provided [Daniel] with a tray icon and a “switch” function. Clicking this button disconnected the HID device from the Windows PC and connected the actual USB device on the other side of the USB switch. The second computer would now have access to the HID device instead.
[Daniel] fired up a program called SnoopyPro. This software is used to inspect USB traffic. [Daniel] noticed that a single message repeated itself until he pressed the “switch” button. At that time, a final message was sent and the HID device disconnected.
Now it was time to get cracking on Linux. [Daniel] hooked up the switch to a Linux system and configured a udev rule to ensure that it always showed up as /dev/usbswitch. He then wrote a python script to write the captured data to the usbswitch device. It was that simple. The device switched over as expected. So much for having no Linux support!
The ESP8266 is the answer to “I want something with Wifi.” Surprisingly, there are a number of engineers and hobbyists who have not heard of this chip or have heard of it but don’t really understand what it is. It’s basically the answer to everything IoT to so many engineering problems that have plagued the hobbyist and commercial world alike.
The chip is a processor with integrated RAM, some ROM, and a WiFi radio, and the only external components you will need are 4 capacitors, a crystal and an external flash! It’s CHEAP, like $4/ea cheap! Or $5 if you want it on a nice, convenient carrier board that includes all these components. The power consumption is reasonable (~200mA)1, the range is insane ~300m2 without directional equipment, and a PCB trace antenna and ~4km if you want to be ridiculous.
One place thing that more people need to know about is how to program directly for this chip. Too many times projects use it as a crutch via the AT commands. Read on and find out how to hello world with just this chip.
Continue reading “How to Directly Program an Inexpensive ESP8266 WiFi Module”
[Eberhard] needed to flash several hundred ATMegas for a project he was working on. This was a problem, but the task did have a few things going for it that made automation easy. The boards the ‘Megas were soldered to weren’t depanelized yet, and he had a neat and weird bed of nails programming connector. There was also a CNC machine close by. This sounds like the ideal situation for automation, and it turns out the setup was pretty easy.
The boards in question were for FPV/radio control telemetry adapter and thankfully the assembly house didn’t depanelize the 40 PCBs on each board before shipping them out. A very cool ATMega flashing tool handled the electrical connections between the computer and the microcontroller, but a real, live human being was still required to move this flashing tool from one chip to the next, upload the firmware, and repeat the process all over again.
The solution came by putting a few metal pins in the bed of a CNC mill, 3D print an adapter for the flashing tool, and writing a little code to move the flashing tool from one chip to the next. An extremely simple app takes care of moving the programmer to an unflashed chip, uploading the firmware, and continuing on to the next chip.
There’s still some work to be done that would basically tie together the Gcode and AVRdude commands into a single interface, but even now a complete panel of 40 PCBs can be programmed in a little over 10 minutes. You can check out a video of that below.
Continue reading “Flashing Chips With A CNC”
When the 4D Systems display first arrived in the mail, I assumed it would be like any other touch display – get the library and start coding/debugging and maybe get stuff painted on the screen before dinner. So I installed the IDE and driver, got everything talking and then…it happened. There, on my computer screen, were the words that simply could not exist – “doesn’t require any coding at all”.
I took a step back, blinked and adjusted my glasses. The words were still there. I tapped the side of the monitor to make sure the words hadn’t somehow jumbled themselves together into such an impossible statement. But the words remained… doesn’t.require.any.coding.at.all.
Continue reading “Making Embedded GUI’s Without Code”
While it may not look like much, the image above is a piece of the original email where [Ken Thompson] described what would become the implementation of UTF-8. At the dawn of the computer age in America, when we were still using teletype machines, encoding the English language was all we worried about. Programmers standardized on the ASCII character set, but there was no room for all of the characters used in other languages. To enable real-time worldwide communication, we needed something better. There were many proposals, but the one submitted by [Ken Thompson] and [Rob ‘Commander’ Pike] was the one accepted, quite possibly because of what a beautiful hack it is.
[Tom Scott] did an excellent job of describing the UTF-8. Why he chose to explain it in the middle of a busy cafe is beyond us, but his enthusiasm was definitely up to the task. In the video (which is embedded after the break) he quickly shows the simplicity and genius of ASCII. He then explains the challenge of supporting so many character sets, and why UTF-8 made so much sense.
We considered making this a Retrotechtacular, but the consensus is that understanding how UTF-8 came about is useful for modern hackers and coders. If you’re interested in learning more, there are tons of links in this Reddit post, including a link to the original email.
Continue reading “UTF-8 – “The most elegant hack””