Microcontrollers are small, no one is arguing that. On a silicon wafer the size of a grain of rice, you can connect a GPS tracker to the Internet. Put that in a package, and you can put the Internet of Things into something the size of a postage stamp. There’s one microcontroller that’s smaller than all the others. It’s the ATtiny10, and its brethren the ATtiny4, 5, and 9. It comes in an SOT-23-6 package, a size that’s more often seen in packages for single transistors. It’s not very capable, but it is very small. It’s also very weird, with a programming scheme that’s not found in other chips from the Atmel/Microchip motherbrain. Now, finally, we have a great tutorial on using the ATtiny10, and it comes from none other than [Ben Heck].
The key difference between the ATtiny10 and other AVRs is that the tiny10 doesn’t use the standard AVR ISP protocol for programming. Instead of six pins for power, ground, MISO, MOSI, SCK, and RST, this is a high-voltage programming scheme that needs 12 Volts. The normal AVR programmer can do it, but you need to build an adapter. That’s exactly what [Ben] did, using a single-sided perf board, a lot of solder, and some headers. It looks like a lot, but there’s really not much to this programmer board. There’s a transistor and an optocoupler. The only thing that could make this programmer better is an SOT-23 ZIF socket. This would allow bare tiny10s to be programmed without first soldering them to a breakout board, but ZIF sockets are expensive to begin with, and the prices on SOT-23 sockets are absurd.
Programming the device was a matter of loading Atmel Studio and going through the usual AVR rigamarole, but Ben was eventually able to connect a light sensor to the tiny10 and have it output a value over serial. This was all done on a device with only 32 Bytes of RAM. That’s impressive, and one of the cool things about the smallest microcontroller you can buy.
Interfacing with the outside world is a fairly common microcontroller task. Outside of certain use cases microcontrollers are arguably primarily useful because of how easily they can interface with other devices. If we just wanted to read and write some data we wouldn’t have gotten that Arduino! But some tasks are more common than others; for instance we’re used to being on the master side of the interface equation, not the slave side. (That’s the job for the TI engineer who designed the temperature sensor, right?) As [Pat] discovered when mocking out a missing SPI GPIO extender, sometimes playing the other role can contain unexpected difficulties.
The simple case for a SPI slave is exactly that: simple. SPI can be wonderful in its apparent simplicity. Unlike I2C there are no weird addressing schemes, read/write bits, stop and start clock conditions. You toggle a clock line and a bit of data comes out, as long as you have the right polarity schemes of course. As a slave device the basic algorithm is of commensurate complexity. Setup an interrupt on the clock pin, wait for your chip select to be asserted, and on each clock edge shift out the next bit of the current word. Check out [Pat]’s eminently readable code to see how simple it can be.
But that last little bit is where the complexity lies. When you’re the master it’s like being the apex predator, the king of the jungle, the head program manager. You dictate the tempo and everyone on the bus dances to the beat of your clock edge. Sure the datasheet for that SRAM says it can’t run faster than 8 MHz but do you really believe it? Not until you try driving that clock a little quicker to see if there’s not a speedier transfer to be had! When you’re the slave you have to have a bit ready every clock edge. Period. Missing even a single bit due to, say, an errant print statement will trash the rest of transaction in ways which are hard to detect and recover from. And your slave code needs to be able to detect those problems in order to reset for the next transaction. Getting stuck waiting to send the 8th bit of a transaction that has ended won’t do.
Check out [Pat]’s very friendly post for a nice refresher on SPI and their discoveries working through the problems of building a SPI slave. There are some helpful tips about how to keep things responsive in a device performing other tasks.
We live in a day when it is very inexpensive to buy an oscilloscope, especially one with modest performance that hooks to a laptop. However, there was a time when even a surplus scope was out of reach for many people who liked to build things. A common alternative was the logic probe. At the low end, this could be an inverter and an LED, although it was more common to have a little extra circuitry to actually do a comparison to a reference voltage and present some indication of fast pulses — you might not be able to tell the frequency of a clock, but you could tell it wasn’t stuck. Of course, today with a microcontroller you can make a very sophisticated probe with less circuitry than a classic probe. We’ve seen a few takes on this and the latest is the DigiLogicProbe from [TheRadMan].
The probe is just a ATtiny85 board with a handful of components. A resistor and diode help protect the probe and the circuit under test. There are also a few LEDs and a buzzer. The rest of the project is software.
Over the last year or so, cordless portable soldering irons have become all the rage. In fact, at this point a good number of Hackaday readers out there have likely traded in their full-size AC irons for a DC iron that’s only slightly larger than a pen. But before the big boom in portable irons, in the ye olden days of 2014, we brought you word of the open source Solderdoodle created by [Isaac Porras]. Based upon the Weller BP645 and featuring a 3D printed case, the DIY iron was designed to be charged from a standard USB port.
Now, [Isaac] is back with an updated version he calls the Solderdoodle Plus. It’s still based on the heating element from the Weller BP645, but now boasts twice the power, an improved 3D printed case, an intuitive touch-based user interface, and even some LED blinkenlights for good measure. As with the original Solderdoodle the hardware and software for the device are open source and you’re invited to build your own, though kits are also available through an already fully-funded Kickstarter campaign.
[Isaac] says that the temperature control functions on traditional corded soldering irons waste energy due to the large thermal mass they have to bring up to temperature. But with less thermal mass and a system of variable duty cycle pulsed power, he says the Solderdoodle Plus can do the same work as an old-school 60 watt iron while only consuming 10 watts. This allows the iron to maintain a constant 500°C for over an hour on the dual internal Panasonic NCR18500A lithium-ion batteries, and means you can charge it up with nothing more exotic than a micro USB cable.
Entries into the Circuit Sculpture Contest tend to be pretty minimalist by nature, and this LED candle by [Amal Mathew] is a perfect example. The idea here was to recreate the slim and uncomplicated nature of a real candle but with a digital twist, and we think he’s pulled it off nicely with a bare minimum part count and exaggerated wire length that gives it the look of a thin pillar candle.
To give the LED a fading effect, [Amal] uses a ATtiny85 programmed with the Arduino IDE. His code uses the analogWrite() in a loop to gradually increase and then decrease the PWM frequency. With the LED connected directly to one of the pins on the ATtiny85, the simple program achieves the fading effect without needing any additional components.
On the opposite side of the candle, connected by long copper wires, is the single CR2032 which provides power for the circuit. In a nice touch, [Amal] has turned the battery 90 degrees relative to the rest of the circuit, so it can serve as a weighted base. We imagine getting it to stand up might be a little fiddly from the looks of it, but once it’s up and merrily fading in and out, it really helps sell the candle idea.
The finished product might look fairly straight-forward, but in his write-up on Hackaday.io, [Amal] gives detailed instructions on how to build your own version if you’re not a bare microcontroller wizard. This includes direction on how to program the ATtiny85 using an Arduino Uno; a neat trick to know even if you aren’t planning on making any candles in the near future. The next logical step is making it so you can “blow out” the LED, which should only take the addition of a resistor and some updated code.
[Robson Couto] recently found himself in need of MIDI interface for a project he was working on, but didn’t want to buy one just to use it once; we’ve all been there. Being the creative fellow that he is, he decided to come up with something that not only used the parts he had on-hand but could be completed in one afternoon. Truly a hacker after our own hearts.
Originally written for the ATtiny2313, [Robson] first had to change around the pin configuration so it would work on the ATmega8 in the USBASP, and also updated the USB-V implementation to the latest version. With the code updated, he programmed one of the USBASP adapters with a second one by connecting them together and putting a jumper on the J2 header.
He had the software sorted, but there was still a bit of hardware work to do. To provide isolation for the MIDI device, he put together a small circuit utilizing a 6N137 optoisolator and a couple of passive components on a piece of perf board. It’s not pretty, but it does fit right into the programming connector on the USBASP. He could have fired up his PCB CNC but thought it was a bit overkill for such a simple board.
[Robson] notes that he hasn’t implemented MIDI output with his adapter, but that the code and the chip are perfectly capable of it if you need it for your project. Finding the schematic to hook up to the programmer’s TX pin is left as an exercise for the reader.
Small I2C OLED displays are common nowadays, and thanks to the work of helpful developers, there are also a variety of graphics libraries for using them. Most of them work by using a RAM buffer, which means that anything one wants to draw gets written to a buffer representing the screen, and the contents of that buffer are copied out to the display whenever it is updated. The drawback is that for some microcontrollers, there simply isn’t enough RAM for this approach to work. For example, a 128×64 monochrome OLED requires a 1024 byte buffer, but that’s bad news if a microcontroller has only 512 bytes of RAM in total like the ATtiny85. [David Johnson-Davies] has two solutions: a Tiny Graphics Library that needs no RAM buffer and an even slimmer Tiny Function Plotter, which we’ll discuss in order.
[David]’s Tiny Graphics Library works by taking advantage of a feature of SH1106 driver-based displays: the ability to read the display over I2C as well as write to it. With the ability to perform read-modify-write on a section at a time, using a large RAM buffer can be avoided. The only catch is that the library only works with OLEDs using the SH1106, but the good news is that these are very common at the usual Chinese resellers. ([David] notes that SH1106 is sometimes misspelled as “SSH1106”, so keep that in mind when searching.)
What about all those other SSD1306-based OLED displays out there? Are they out of luck? Not quite. [David] has one more trick up his sleeve: his Tiny Function Plotter works on the SSD1306 and also requires no RAM buffer. It’s unable to write text, but it can easily handle drawing graphs plotting things like values over time while needing very little overhead.
Another approach we’ve seen for using OLEDs driven by microcontrollers with limited memory is the solution [Michael] used in Tiny Sideways Tetris, which was done in part by realizing the smallest screen element he needed was a 4×4 block, and using that premise as the basis of a simple compression scheme.
By using our website and services, you expressly agree to the placement of our performance, functionality and advertising cookies. Learn more