The Inner Machinations Of The Arduino Are An Enigma

September 19, 2022 by Bryan Cockfield 88 Comments

Arduinos have been the microcontroller platform of choice for nearly two decades now, essentially abstracting away a lot of the setup and lower-level functions of small microcontrollers in favor of sensible IDEs and ease-of-use. This has opened up affordable microcontrollers to people who might not be willing to spend hours or days buried in datasheets, but it has also obscured some of those useful lower-level functions. But if you want to dig into them, they’re still working underneath everything as [Jim] shows us in this last of a series of posts about interrupts.

For this how-to, [Jim] is decoding linear timecodes (LTCs) at various speeds. This data is usually transmitted as audio, so the response from the microcontroller needs to be quick. To make sure the data is decoded properly, the first thing to set up is edge detection on the incoming signal. Since this is about using interrupts specifically, a single pin on the Arduino is dedicated to triggering an interrupt on these edges. The rest of the project involves setting up an interrupt service routine, detecting the clock signal, and then doing all of the processing necessary to display the received LTC on a small screen.

The project page goes into great detail about all of this, including all of the math that needs to be done to get it set up correctly. As far as general use of interrupts goes, it’s an excellent primer for using the lower-level functionality of these microcontrollers. And, if you’d like to see the other two projects preceding this one they can be found on the first feature about precision and accuracy, and the second feature about bitbanging the protocol itself.

Diagram of the LTC protocol, showing the difference between 1 bits and 0 bits - both transmitted using one up and one down pulse, but with '1' bit pulses being half as short.

Animate Arcane Protocols With Interrupt-Backed Bitbanging

June 19, 2022 by Arya Voronova 10 Comments

We often take our “SoftwareSerial” libraries for granted, and don’t investigate what goes on under the hood — until they fail us, at least. Would you like to learn how to harness the power of interrupt-driven bitbanging? [Jim Mack] teaches us how to make our protocol implementations fly using the LTC protocol as a springboard.

LTC (Linear/[Longitudinal] TimeCode) is a widely-used and beautifully-crafted protocol that tends to fly under our radar, and is one that hackers could learn plenty from. It’s used for synchronization of audio/video devices during media production and playback. LTC’s signal is almost digital but not quite: it doesn’t need a clock, and it has no polarity. Additionally, it mimics an audio signal really well, you can decode it at any playback speed, and many other benefits and quirks that [Jim] outlines. You do need to maintain the timings, though, and [Jim]’s article shows us how to keep them right while not inconveniencing your primary tasks.

Continue reading “Animate Arcane Protocols With Interrupt-Backed Bitbanging” →

A graph visualising approximation errors - the specific principle pictured is described well by the linked article

Time And Accuracy In Las ATMegas

January 31, 2022 by Arya Voronova 4 Comments

Do you ever have to ensure that an exact amount of time passes between two tasks in your microcontroller code? Do you know what’s the difference between precision and accuracy? Today, [Jim Mack] tells us about pushing timers and interrupts to their limits when it comes to managing time, while keeping it applicable to an ever-popular ATMega328P target! Every now and then, someone decides to push the frontiers of what’s possible on a given platform, and today’s rules is coding within constraints of an Arduino environment. However, you should check [Jim]’s post out even if you use Arduino as a swearword – purely for all of the theoretical insights laid out, accompanied by hardware-accurate examples!

This will be useful to any hacker looking to implement, say, motor encoder readings, signal frequency calculations, or build a gadget processing or modifying audio in real time. To give you a sample of this article, [Jim] starts by introducing us to distinctions between precision and accuracy, and then presents us with a seemingly simple task – creating exactly 2400 interrupts a second. As much as it might look straightforward, problems quickly arise when clock crystal frequency doesn’t cleanly divide by the sampling frequency that you have to pick for your application! This is just a taste of all the examples of hidden complexity presented, and they’re accompanied with solutions you can use when you eventually encounter one of these examples in your hacker pursuits. In the end, [Jim] concludes with links to other sources you can study if you ever need to dig deeper into this topic.

Keeping our projects true to the passage of time can be an issue, and we’ve been at it for ages – calibrating your RC oscillator is a rite of passage for any ATTiny project. If you ever decide to have an interrupt peripheral help you with timing issues, we’ve gone in-depth on that topic in the past, with a three-part series describing the benefits, the drawbacks and the edgecases of interrupts. Going for a more modern target? Our piece on using interrupts with STM32 is a great path for trying out tools of the modern age.

Solder Paste Dispenser Without Giant Compressor

November 26, 2021 by Bryan Cockfield 25 Comments

We have certainly all had our moments with solder paste. Some of us hate it; it’s sticky and gooey, and it gets everywhere. That is, unless you have a solder paste dispenser. The trouble with these is that they typically require the use of an air compressor, which can be cumbersome to haul around in certain situations. If you need a solder paste dispenser that fits conveniently where air compressors won’t, take a look at this small one from [Nuri Engineer] called the solderocket.

This design foregoes the traditional compressor in favor of pressurized carbon dioxide canisters. These are common enough and used for things like rapidly inflating bicycle tires, but for this more delicate procedure the pressurized gas needs to be handled more daintily. A rotary knob is attached to the canister to regulate pressure, and a second knob attached to a microcontroller adjusts the amount of time the air pressure is applied to the solder paste. With this small compact setup, any type of paste can be delivered to a PCB without needing to use messy stencils or needing larger hardware like a compressor.

This could be just the tool that you need if you regularly work with surface-mount components. Of course there are other methods of dispensing solder paste that don’t require any compressed gas of any kind, but as long as something is around that gets the job done, we can’t really argue with either method.

DIY I2C Tester

March 23, 2021 by Chris Lott 26 Comments

[Dilshan] built a dedicated I2C tester which allows for I2C bus control over USB using simple commands such as init, read, write, etc. The Linux kernel has had I2C driver support for a couple of decades, but you’ll be hard pressed to find a computer or laptop with a I2C connector (excluding Bunnie Huang’s Novena hacker’s laptop, of course). This tester does require a Linux host, and his programs use libusb on the computer side and V-USB on the embedded side.

[Dilshan] put a lot of time into building this project, and it shows in the build quality and thorough documentation. With its single-sided PCB and all thru-hole construction, it makes a great beginner project for someone just getting into the hobby. At the heart of the tester is an ATmega16A in a 40-pin PDIP package (despite the Microchip overview page calling it a 44-pin chip), supported by a handful of resistors and transistors. Schematics are prepared in KiCad, code is compiled using gcc and avr-gcc, and he provides a label for the enclosure top. The only thing missing is information on the enclosure itself, but we suspect you can track that down with a little sleuthing (or asking [Dilshan] himself).

If you use I2C quite a lot, give this project a look. Easy to build, useful in the lab, and it looks nice as well. We have featured [Dilshan]’s work over the years, including this logic pattern generator and his two-transistor-on-a-breadboard superheterodyne receiver.

AVR Microcontroller Doubles Up As A Switching Regulator

January 9, 2021 by Anool Mahidharia 26 Comments

[SM6VFZ] designed, built and tested a switched-mode DC-DC boost regulator using the core independent peripherals (CIP) of an ATtiny214 micro-controller as a proof of concept, and it looks pretty promising!

A Buck, Boost, or Buck-Boost switching regulator topology usually consists of a diode, a switching element (MOSFET) and an energy storage device (inductor/capacitor) in the power path, and a controller that can measure the output voltage, control the switching element and add safety features such as current limiting and temperature shutdown. A search for switching regulators or controllers throws up thousands of parts, and it’s possible to select one specifically well suited for any desired application. Even so, the ability to use the micro-controller itself as the regulator can have several use cases. Such an implementation allows for a software configurable switch-mode regulator and easy topology changes (boost, buck, fly back etc.).

The “Getting Started with Core Independent Peripherals on AVR®” application note is a good place to get an overview of how the CIP functionality works. Configurable Custom Logic (CCL) is among one of the powerful CIP peripherals. Think of CCL as a rudimentary CPLD — a programmable logic peripheral, which can be connected to a wide range of internal and external inputs such as device pins, events, or other internal peripherals. The CCL can serve as “glue logic” between the device peripherals and external devices. The CCL peripheral offers two LookUp Tables (LUT). Each LUT consists of three inputs, a truth table, a synchronizer, a filter, and an edge detector. Each LUT can generate an output as a user programmable logic expression with three inputs and any device that have CCL peripherals will have a minimum of two LUTs available.

This napkinCAD sketch shows how [SM6VFZ] implemented the boost regulator in the ATtiny214. The AND gate is formed using one of the CCL LUT’s. The first “timer 1” on the left, connected to one input of the AND gate, is free running and set at 33 kHz. The analog comparator compares the boosted output voltage against an internally generated reference voltage derived from the DAC. The output of the comparator then “gates” timer 1 signal to trigger the second “timer 2” — which is a mono-shot timer set to max out at 15 us. This makes sure there is enough time left for the inductor to completely release its energy before the next cycle starts. You can check out the code that [SM6VFZ] used to built this prototype, and his generous amounts of commenting makes it easy to figure out how it works.

Based on this design, the prototype that he built delivers 12 V at about 200 mA with an 85% efficiency, which compares pretty well against regular switching regulators. Keep in mind that this is more of a proof-of-concept (that actually works), and there is a lot of scope for improvement in terms of noise, efficiency and other parameters, so everyone’s comments are welcome.

In an earlier blog post, we looked at how ATmegas with Programmable Logic came about with this feature that is usually found in PIC micro-controllers, thanks to Microchip’s acquisition of Atmel a few years back. But we haven’t seen any practical example of the CCL peripheral in an Atmel chip up until now.

Putting The Firmware In Your Firmware

September 15, 2020 by Kerry Scharfglass 12 Comments

Performing over-the-air updates of devices in the field can be a tricky business. Reliability and recovery is of course key, but even getting the right bits to the right storage sectors can be a challenge. Recently I’ve been working on a project which called for the design of a new pathway to update some small microcontrollers which were decidedly inconvenient.

There are many pieces to a project like this; a bootloader to perform the actual updating, a robust communication protocol, recovery pathways, a file transfer mechanism, and more. What made these micros particularly inconvenient was that they weren’t network-connected themselves, but required a hop through another intermediate controller, which itself was also not connected to the network. Predictably, the otherwise simple “file transfer” step quickly ballooned out into a complex onion of tasks to complete before the rest of the project could continue. As they say, it’s micros all the way down.