Let’s Make Robots Changes Hands: Kerfuffle Ensues

There’s been a bit of a shakeup at Let’s Make Robots (LMR).

LMR is possibly the most popular DIY robotics website around and was started up by a fun-loving Dane, [Frits Lyneborg]. It grew a large community around building up minimal robots that nonetheless had a lot of personality or pushed a new technical idea into the DIY robotics scene. [Frits] says that he hasn’t had time for DIY robotics for a while now, and doesn’t have the resources to run a gigantic web forum either, so he worked out a deal to let the Canadian hobbyist supply company Robot Shop take it over.

LMR has always been a little bit Wild-West, and many of the members quite opinionated, and that’s been part of its charm. So when the new corporate overlords came in, set up “Rules” (which have seemingly been downgraded to “suggestions”) and clarified the ownership of the content, some feathers were ruffled.

A few weeks later, everything looks to be settling back down again. (Edit: Or has it?!? See the comments below.) We wish LMR all the best — everyone loves robots, and LMR is a tremendous resource for the newbie interested in getting into DIY robotics on the cheap. More than a few LMR posts have been featured here at Hackaday over the years. Among our favorites are this drumming rovera clever 3D printed gripper, and this wicked bicycle-style balancer.

Embed With Elliot: Interrupts, The Bad

We love interrupts in our microcontroller projects. If you aren’t already convinced, go read the first installment in this series where we covered the best aspects of interrupts.

But everything is not sunshine and daffodils. Interrupts take place outside of the normal program flow, and indeed preempt it. The microcontroller will put down whatever code it’s running and go off to run your ISR every time the triggering event happens. That power is great when you need it, but recall with Spider-Man’s mantra: With great power comes great responsibility. It’s your responsibility to design for the implicit high priority of ISRs, and to make sure that your main code can still get its work done in between interrupt calls.

Put another way, adding interrupts in your microcontroller code introduces issues of scheduling and prioritization that you didn’t have to deal with before. Let’s have a look at that aspect now, and we’ll put off the truly gruesome side-effects of using interrupts until next time.

Continue reading “Embed With Elliot: Interrupts, The Bad”

Transparent ESP8266 WiFi-to-Serial Bridge

These days, connecting your microcontroller project to a WiFi network is pretty easy — you connect up an ESP8266 to your microcontroller project and pretend it’s a WiFi modem, using these old-school-style AT commands. But what do you do if you need to flash new code into the microcontroller? You can’t reprogram the micro remotely through the ESP8266 because those stupid AT commands get in the way.

The solution? By flashing the esp-link firmware into your ESP8266, you talk directly to the microcontroller over WiFi as if it were connected by a serial cable: the ESP8266 becomes a totally transparent WiFi-serial bridge. Now, with a serial bootloader and an ESP8266 in Wifi-to-serial bridge mode, you can reflash your microcontroller wirelessly, and then telnet in to interact with and debug the system remotely. Once you’ve fixed the bugs, you can re-flash the microcontroller: all over WiFi, without having to climb up a ladder to reach your IoT attic-temperature sensor.

To flash a connected Arduino, for instance, all you need to do is convince AVRDUDE to use the network instead of a locally-connected USB-serial cable: avrdude -p m328p -c arduino -b 115200 -P net:192.168.1.123:23 -U:yourHexFile.hex. The ESP8266 passes the data straight through its TX and RX lines to your microcontroller and everything works as if it were wired.

Configuration to allow the ESP8266 to join your WiFi network takes place on a self-hosted webpage that uses [Sprite_tm]’s esp-httpd standalone server, which makes setup pretty painless. And then after that you can simply telnet to the ESP8266 at port 23 and type away, or do anything else you would with a wired serial connection.

Although the simple bridge mode came first, esp-link looks like it’s growing to be a one-stop shop for all your IoT or microcontroller + WiFi needs. In addition to the serial bridge code, there is also a REST-based microcontroller-to-internet mode and there is bi-directional MQTT support in the wings. We haven’t had a chance to dig into these yet, so if you have, let us know in the comments.

If you want to dig in deeper, head over to [Jeelabs]’ blog for a slightly outdated tour of the project written by the code’s author, [Thorsten von Eicken]. For the most up-to-date development news, follow the very active development of esp-link in this thread on the esp8266 forums.

Embed With Elliot: Interrupts, The Good…

What’s the biggest difference between writing code for your big computer and a microcontroller? OK, the memory and limited resources, sure. But we were thinking more about the need to directly interface with hardware. And for that purpose, one of the most useful, and naturally also dangerous, tools in your embedded toolchest is the interrupt.

Interrupts do exactly what it sounds like they do — they interrupt the normal flow of your program’s operation when something happens — and run another chunk of code (an interrupt service routine, or ISR) instead. When the ISR is done, the microcontroller picks up exactly where it left off in your main flow.

Say you’ve tied your microcontroller to an accelerometer, and that accelerometer has a “data ready” pin that is set high when it has a new sample ready to read. You can wire that pin to an input on the microcontroller that’s interrupt-capable, write an ISR to handle the accelerometer data, and configure the microcontroller’s interrupt system to run that code when the accelerometer has new data ready. And from then on everything accelerometer-related happens automagically! (In theory.)

This is the first part of a three-part series: Interrupts, the Good, the Bad, and the Ugly. In this column, we’ll focus on how interrupts work and how to get the most out of them: The Good. The second column will deal with the hazards of heavyweight interrupt routines, priority mismatches, and main loop starvation: the Bad side of interrupts. Finally, we’ll cover some of the downright tricky bugs that can crop up when using interrupts, mainly due to a failure of atomicity, that can result in logical failures and corrupted data; that’s certainly Ugly.

Continue reading “Embed With Elliot: Interrupts, The Good…”

Tiny Headless Servers Everywhere

Quick, what do “cloud compute engines” and goofy Raspberry Pi Internet of Things hacks have in common? Aside from all being parody-worthy buzzword-fests, they all involve administering remote headless (Linux) installations. It’s for exactly that reason that a new Ubuntu distribution flavor, Ubuntu (Snappy) Core, targets both the multi-bazillion-dollar Amazon Elastic Compute Cloud and the $55 BeagleBone Black.

If that combination seems unlikely to you, you’re not alone. But read on as we hope to make a little more sense of it all.
Continue reading “Tiny Headless Servers Everywhere”

Strange Signals? Sigidwiki!

If you’ve gotten into software-defined radio (SDR) in the last five years, you’re not alone. A lot of hackers out there are listening in to the previously unheard. But what do you do when you find an interesting signal and you don’t know what it is? Head on over to the Signal Identification Wiki! You’ll find recordings and waterfall plots for a ton of radio signals categorized by frequency band as well as their use.

Or, conversely, maybe you’ve just got a new radio and you want to test it out. What would be a fun challenge to receive? Signals in the catalog range from the mundane, like this smart home energy meter from California, or a Chrysler tire-pressure monitoring system to (probably) secret military or intelligence transmissions.

If you’re looking at a waterfall plot and you’re not sure what to make of it, the sigidwiki is worth a look. And it’s a wiki, so if you’ve got a cool signal and you want to add it, create an account and get to it!

Thanks to [mkie] for the tip!

Logic Noise: Playing In Tune With An Exponential VCO

Last session, we use the cheap and cheerful 4046 Phase-locked Loop chip as a simple voltage-controlled oscillator (VCO). It was dead simple, in fact, because the chip has a VCO already built in. There’s one big drawback of the 4046’s VCO; the pitch changes linearly with the control voltage. Ideally, as we’ll discuss in the next sections, we’d like the frequency to be an exponential function of the control voltage (CV), and that’s going to mean a little bit of analog circuitry.

René Schmitz has a fantastic exponential VCO design that’s almost a perfect fit for the Logic Noise series — it’s built with a minimum of parts, it’s a little bit rough around the edges, and at its core is a 4000-series CMOS chip that’s normally used for digital logic applications. The only drawback, from our perspective, is that it uses a dual (positive and negative) power supply. We’ll hack our way around that, and ignore some of René’s otherwise worthwhile refinements in the name of doing something truly quick and dirty. We’ll get 95% of the results with 70% of the work, although it’s easy enough to add on the rest if it strikes your fancy.

Continue reading “Logic Noise: Playing In Tune With An Exponential VCO”