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””
A few weeks ago we featured the McHck project (pronounced McHack), a $5 Cortex M4 based platform which can be directly plugged into one’s computer. Recently, [Simon] announced that he made a firmware allowing a McHck to behave as a SWD adapter and also detailed his flashing rig.
Therefore, those who’d want to build their own McHck would only need to borrow an SWD programmer once to get started. When the first platform has been programmed with the SWD firmware, it can be used to flash and debug applications on the second McHck. Consequently, the microcontroller flashing rig [Simon] designed (shown in the picture above) is based on this. The few core elements are a TQFP48 ZIF programming socket, a push button and two LEDs. Simply push the Kinetis in the programming socket, close it and press the button. Success of the operation is indicated by the two LEDs. [Simon] used the Ragel State Machine Compiler to generate his flashing program and all the code he made can be downloaded from his github.
If you missed the original McHck post now’s your chance to go back and see what it is all about.