“DB” = Abbreviated Microcontroller Debugging

December 20, 2018 by Drew Risinger 19 Comments

We’ve all been there. When debugging a microcontroller project, we just want to put in a print statement to figure out what’s going on with the microcontroller in real time. However, advanced embedded programmers know that printf statements are verboten: they’re just too SLOW. While not fixing this plight entirely, [Atakan Sarioglu] has come up with a clever way to create readable debug messages with minimal runtime overhead.

[Atakan Sarioglu]’s innovation, called BigBug (Github), is a dynamically-generated codebook. The codebook translates abbreviated messages sent over serial (UART here) to longer-form human-readable messages. To generate the codebook, BigBug automatically parses your comments to create a lookup between an abbreviation and the long-form message. When you are running your program on the microcontroller, BigBug will translate the short codes to long messages in real-time as you send log/debug data over serial. Continue reading ““DB” = Abbreviated Microcontroller Debugging” →

A Scratch Instrument For Ants

December 20, 2018 by Bryan Cockfield 2 Comments

If you think that this scratch instrument looks as though it should be at least… three times larger in order to be useful, you’d be wrong. This mighty pocket-sized instrument can really get the club hopping despite its diminuitive size. Despite that, the quality of the build as well as its use of off-the-shelf components for almost every part means that if you need a small, portable turntable there’s finally one you can build on your own.

[rasteri] built the SC1000 digital scratch instrument as a member of the portabilist scene, focusing on downsizing the equipment needed for a proper DJ setup. This instrument uses as Olimex A13-SOM-256 system-on-module, an ARM microprocessor, and can use a USB stick in order to load beats to the system. The scratch wheel itself uses a magnetic rotary encoder to sense position, and the slider is miniaturized as well.

If you want to learn to scratch good and learn to do other things good too, there’s a demo below showing a demonstration of the instrument, as well as a how-to video on the project page. All of the build files and software are open-source, so it won’t be too difficult to get one for yourself as long as you have some experience printing PCBs. If you need the rest of the equipment for a DJ booth, of course that’s also something you can build.

Continue reading “A Scratch Instrument For Ants” →

From SPIDriver To I2CDriver

December 9, 2018 by Bryan Cockfield 30 Comments

Communicating with microcontrollers and other embedded systems requires a communications standard. SPI is a great one, and is commonly used, but it’s not the only one available. There’s also I2C which has some advantages and disadvantages compared to SPI. The problem with both standards, however, is that modern computers don’t come with either built-in. To solve that problem and allow easier access to debugging in SPI, [James Bowman] built the SPIDriver a few months ago, and is now back by popular demand with a similar device for I2C, the I2CDriver.

Much like the SPIDriver, the I2C driver is a debugging tool that can be used at your computer with a USB interface. Working with I2C is often a hassle, with many things going on all at once that need to sync up just right in order to work at all, and this device allows the user to set up I2C devices in a fraction of the time. To start, it has a screen built in that shows information about the current device, like the signal lines and a graphical decoding of the current traffic. It also shows an address space map, and has programmable pullup resistors built in, and can send data about the I2C traffic back to its host PC for analysis.

The I2CDriver is also completely open source, from the hardware to the software, meaning you could build one from scratch if you have the will and the parts, or make changes to the code on your own to suit your specific needs. If you’re stuck using SPI still, though, you can still find the original SPIDriver tool to help you with your debugging needs with that protocol as well.

Low-energy ESP8266-based Board Sleeps Like A Log Until Triggered

November 13, 2018 by Brian Boucheron 32 Comments

Given the popularity of hacking and repurposing Amazon Dash buttons, there appears to be a real need amongst tinkerers for a simple “do something interesting on the internet when a button is pressed” device. If you have this need but don’t feel like fighting to bend a Dash device to your will, take a look at [Kevin Darrah]’s trigBoard instead.

The trigBoard is a battery-powered, ESP8266-based board that includes some clever circuitry to help it barely sip power (less than one microamp!) while waiting to be triggered by a digital input. This input could be a magnetic reed switch, push button, or similar, and you can configure the board for either normally open or normally closed switches.

The clever hardware bits that allow for such low power consumption are explained in [Kevin]’s YouTube video, which we’ve also embedded after the break. To summarize: the EPS8266 spends most of it’s time completely unpowered. A Texas Instruments TPL5111 power timer chip burns 35 nanoamps and wakes the ESP8266 up every hour to check on the battery. This chip also has a manual wake pin, and it’s this pin – along with more power-saving circuitry – that’s used to trigger actions based on the external input.

Apparently the microcontroller can somehow distinguish between being woken up for a battery check versus a button press, so you needn’t worry about accidentally sending yourself an alert every hour. The default firmware is set up to use Pushbullet to send notifications, but of course you could do anything an EPS8266 is capable of. The code is available on the project’s wiki page.

The board also includes a standard micro-JST connector for a LiPo battery, and can charge said battery through a micro-USB port. The trigBoard’s full schematic is on the wiki, and pre-built devices are available on Tindie.

[Kevin]’s hardware walkthrough video is embedded after the break.

Continue reading “Low-energy ESP8266-based Board Sleeps Like A Log Until Triggered” →

Trials And Tribulations In Sending Data With Wires

September 25, 2018 by Kerry Scharfglass 14 Comments

When working on a project that needs to send data from place to place the distances involved often dictate the method of sending. Are the two chunks of the system on one PCB? A “vanilla” communication protocol like i2c or SPI is probably fine unless there are more exotic requirements. Are the two components mechanically separated? Do they move around? Do they need to be far apart? Reconfigurable? A trendy answer might be to add Bluetooth Low Energy or WiFi to everything but that obviously comes with a set of costs and drawbacks. What about just using really long wires? [Pat] needed to connect six boards to a central node over distances of several feet and learned a few tricks in the process.

When connecting two nodes together via wires it seems like choosing a protocol and plugging everything in is all that’s required, right? [Pat]’s first set of learnings is about the problems that happen when you try that. It turns out that “long wire” is another way to spell “antenna”, and if you happen to be unlucky enough to catch a passing wave that particular property can fry pins on your micro.

Plus it turns out wires have resistance proportional to their length (who would have though!) so those sharp square clock signals turn into gently rolling hills. Even getting to the point where those rolling hills travel between the two devices requires driving drive the lines harder than the average micro can manage. The solution? A differential pair. Check out the post to learn about one way to do that.

It looks like [Pat] needed to add USB to this witches brew and ended up choosing a pretty strange part from FTDI, the Vinculum II. The VNC2 seemed like a great choice with a rich set of peripherals and two configurable USB Host/Peripheral controllers but it turned out to be a nightmare for development. [Pat]’s writeup of the related troubles is a fun and familiar read. The workaround for an incredible set of undocumented bad behaviors in the SPI peripheral was to add a thick layer of reliability related messaging on top of the physical communication layer. Check out the state machine for a taste, and the original post for a detailed description.

The Smaller, Tinier Arduino Platform

July 4, 2018 by Bryan Cockfield 34 Comments

While many of the Arduino platforms are great tools for gaining easy access to microcontrollers, there are a few downsides. Price and availability may be the highest on the list, and for those reasons, some have chosen to deploy their own open-source Arduino-compatible boards.

The latest we’ve seen is the Franzininho, an Arduino Gemma-like board that’s based on the ATtiny85, a capable but tiny microcontroller by Atmel in a compact 8-pin configuration. This board has everything the Gemma has, including a built-in LED and breakout pins. One of the other perks of the Franzininho over the Gemma is that everything is based on through-hole components, making the assembly much easier than the surface mount components of the Gemma.

It’s worth noting that while these boards are open source, the Arduinos are as well. It’s equally possible to build your own 100% identical Arduino almost as easily. If you want more features, you can add your own by starting from one of these platforms and do whatever you want with it, like this semi-educational Atmel breakout board.

Thanks to [Clovis] for the tip!

General Purpose I/O: How To Get More

June 14, 2018 by Inderpreet Singh 28 Comments

The first program anyone writes for a microcontroller is the blinking LED which involves toggling a general-purpose input/output (GPIO) on and off. Consequently, the same GPIO can be used to read digital bits as well. A traditional microcontroller like the 8051 is available in DIP packages ranging from 20 pins to 40 pins. Some trade the number of GPIOs for compactness while other devices offer a larger number of GPIOs at the cost of complexity in fitting the part into your design. In this article, we take a quick look at applications that require a larger number of GPIOs and traditional solutions for the problem.

A GPIO is a generic pin on an integrated circuit or computer board whose behavior, including whether it is an input or output pin, is controllable by the user at runtime. See the internal diagram of the GPIO circuit for the ATmega328 for reference.

Simply put, each GPIO has a latch connected to a drive circuit with transistors for the output part and another latch for the input part. In the case of the ATmega328, there is a direction register as well, whereas, in the case of the 8051, the output register serves as the direction register where writing a 1 to it sets it in output mode.

The important thing to note here is that since all the circuits are on the same piece of silicon, the operations are relatively fast. Having all the latches and registers on the same bus means it takes just one instruction to write or read a byte from any GPIO register.
Continue reading “General Purpose I/O: How To Get More” →