Modern microcontroller platforms spoil us with their performance and expansive spec sheets. These days it’s not uncommon to be developing for a cheap micro that has a clock rate well in excess of 100MHz, with all manner of peripherals baked in. DACs, WiFi, you name it – it’s in there, with a bunch of libraries to boot. It wasn’t always this way, and sometimes you would even find yourself lacking hardware serial support. In these cases, the bitbanged software UART is your friend, and [MarcelMG] decided to document just how it’s done.
The amateur programmer’s first recourse may be to use delays to properly time the output data stream. This has the drawback of wasting processor cycles and doesn’t let the microcontroller do much else useful. Instead, [Marcel] discusses the proper way to do things, through the use of interrupt service routines and hardware timers.
[Marcel]’s implementation is for the ATtiny24A, though it should be easily portable to other AVR8 processors. Taking up just 2 bytes of RAM and 276 bytes of program space, it’s compact – which is key on resource-limited 8-bit devices. The code is available on Github if you fancy trying it out yourself.
It’s a technique that is more than familiar to the old hands, but useful to those new to the art. It can be particularly useful if you need to get data out of a legacy platform with limited options. As times change, it’s important to pass on the techniques of yesteryear to the new generation. Of course, if things are really tight, you can even do a half-duplex UART on a single pin.
Most of us are aware that charlieplexing can drive a large number of LEDs from a relatively small number of I/O pins, but [David Johnson-Davies] demonstrates adding another dimension to that method to create individually controlled PWM outputs as well. His ATtiny85 has twelve LEDs, each with individually-set brightness levels, and uses only four of the five I/O pins on the device.
Each LED can be assigned a brightness between 0 (fully off) and 63 (fully on). The PWM is done by using one of the timers in the ATtiny85 to generate a periodic interrupt, and the ISR for the interrupt takes care of setting the necessary ratios of on and off times for each charlieplexed output. The result? Twelve flicker-free LEDs with individually addressable brightness levels, using an 8-pin microcontroller and just a few passive components on a tiny breadboard. There’s even one I/O pin left on the ATtiny85, for accepting commands or reading a sensor.
[David] really wrings a lot out of the ATtiny series of microcontrollers with his compact projects, like his Tiny Function Generator (which recently got an update.) He also demonstrated that while charlieplexing is usually used with LEDs, charlieplexing can be used with switches just as easily.
[Steve Martin] used to do a comedy act about “Let’s get small!” You have to wonder if [Paul Klinger] is a fan of that routine, as he recently completed a very small 3D printed PC that plays snake. Ok, it isn’t really a PC and it isn’t terribly practical, but it is really well executed and would make a great desk conversation piece. You can see the thing in all its diminutive glory in the video below.
The 3D printer turned out a tiny PC case, a monitor, and a joystick. The PC contains an ATtiny1614, an RGB LED, and some fiber optic to look like case lighting. The monitor is really a little OLED screen. A 5-way switch turns into the joystick.
Continue reading “Ultra Tiny PC plays Snake”
Small microcontrollers can pack quite a punch. With the right code optimizations and proper use of the available limited memory, even small microcontrollers can do things they were never intended to. Even within the realm of intended use, however, there are still lots of impressive uses for these tiny cheap processors like [Lukasz]’s audio amplifier which uses one of the smallest ATtiny packages around in the video embedded below.
Since the ATtiny is small, the amplifier is only capable of 8-bit resolution but thanks to internal clock settings and the fast PWM mode he can get a sampling rate of 37.5 kHz. Most commercial amplifiers shoot for 42 kHz or higher, so this is actually quite close for the limited hardware. The fact that it is a class D amplifier also helps, since it relies on switching and filtering to achieve amplification. This allows the amplifier to have a greater efficiency than an analog amplifier, with less need for heat sinks or oversized components.
All of the code that [Lukasz] used is available on the project site if you’ve ever been curious about switching amplifiers. He built this more as a curiosity in order to see what kind of quality he could get out of such a small microcontroller. It sounds pretty good to us too! If you’re more into analog amplifiers, though, we have you covered there as well.
Continue reading “Tiny Amplifier With ATtiny”
When writing code for the ATtiny family of microcontrollers such as a the ATtiny85 or ATtiny10, people usually use one of two methods: they either add support for the chip in the Arduino IDE, or they crack open their text editor of choice and do everything manually. Plus of course there are the stragglers out there using Eclipse. But [Wayne Holder] thinks there’s a better way.
The project started out as a simple way for [Wayne] to program the ATtiny10 in C under Mac OS, but has since evolved into an open source, cross-platform integrated development environment (IDE) for programming a wide range of ATtiny chips in C, C++, or Assembly. Not only does it integrate the source code editor and programmer, but it even bundles in documentation for common variants of the chips including block diagrams and pinouts; making it a true one-stop-shop for ATtiny hacking.
His IDE runs under Java, including OpenJDK, and [Wayne] provides a stable pre-built executable for those who don’t want to clone the whole GitHub repository. He’s included the GNU/AVR toolchains, though notes that testing so far has been limited to Mac OS, and he’s interested in feedback from Windows and Linux users. Assembly is done either with GNU AVR-AS, or an assembler of his own design, though the latter is currently limited to the ATTiny10.
To actually get the code onto the chip, the IDE supports using the Arduino as a programmer as well as dedicated hardware like the BusPirate or the USBasp. If you go the Arduino route, [Wayne] has even come up with a little adapter board which he’s made available through OSH Park to help wrangle the diminutive chips.
The ATtiny10 might have something of a learning curve, but in exchange this family of tiny microcontrollers offers an incredible amount of capability. When you’re working with what’s essentially a programmable grain of rice, the only limit is your own creativity.
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.
Continue reading “Ben Heck Can Program The Smallest Microcontroller”
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.