We like [Tim’s] drive for improvement. He wrote a WS2812 driver library that works with AVR and ARM Cortex-M0 microcontrollers, but he wasn’t satisfied with how much of the controller’s resources the library used to simply output the required timing signal for these LED modules. When he set out to build version 2.0, he dug much deeper than just optimizing his own code.
We remember [Tim] from his project reverse engineering a candle flicker LED. This time, he’s done more reverse engineering by comparing the actual timing performance of the WS2812(B) module with its published specs. He learned that although several timing aspects require precision, others can be fudged a little bit. To figure out which ones, [Tim] used an ATtiny85 as a signal-generator and monitored performance results with a Saleae logic analyzer. Of course, to even talk about these advances you need to know something about the timing scheme, so [Tim] provides a quick run-through of the protocol as part of his write-up.
Click the top link to read his findings and how he used them to write the new library, which is stored in his GitHub repository.
[Tyson’s] family went with creating rather than buying Christmas presents last month, which gave him the opportunity to build some electronic fireflies for gifts. He drew inspiration from a similar firefly project we featured last year, but expanded on the original model by designing dedicated PCBs and housings for each of his firefly pieces.
Although he’d settled on using ATTiny85’s for this project, [Tyson] was fresh out of through-hole versions. He decided to skip the prototyping phase and go right for fabrication, cranking up the laser-jet printer for some toner-transfer, which successfully produced 4 functioning boards (and 3 failures). The fireflies were [Tyson’s] first attempt at SMD soldering, and we’d have to say it’s a job well done; he reflowed each board with a cheap-o heatgun from Harbor Freight.
After some hiccups with fuse programming, [Tyson] got the code uploaded and the fireflies illuminated. Swing by his site for the nuts and bolts on construction, then snag the project files here. (Direct .zip download)
We’ve seen a lot of Trinket builds over the past few months, but so far few people have capitalized on the Trinket’s minimalism. It’s a fairly simple circuit, as far as dev boards go, and with careful planning can be built entirely on perfboard. That’s what [villeki] did, with a project he calls Shrinket.
After looking at the schematic for the Trinket, [villeki] figured he could best the very small footprint of this ATtiny85 board. To do this, he mounted the uC on the bottom side of the board, bending the pins so they could be easily soldered to the pins. The only real challenge in building this tiny board was the USB connector. To fit this connector on board, the copper pads were carefully scraped off the protoboard and wires run to the zeniers.
The Shrinket is impressively small – only 0.6″x 0.9″ – and a very impressive example of soldering skills. If you’re looking for a project to hone your free-form soldering skills, this is a great way to spend an hour or two. Bonus, you probably already have the parts required (or a reasonable substitute) sitting around.
Why would you clone something as cheap as the adafruit Trinket? Well, because you can, of course. And that’s exactly why [Ray] started to build a clone two days after his Trinket came in the mail. He encourages you to support adafruit by buying at least one Trinket before attempting a clone, and we agree. Besides, you’ll be able to use the support forum with a clear conscience.
[Ray]’s design uses an 1800Ω pull-up resistor rather than the 1500Ω in the Trinket. He made this change based on his experience with V-USB and the ATtiny85. He has a lot more information on his build on the Arduino forum. Check out a short video of Chachka responding to a Sony-esque remote control after the break.
Need an application for your Trinket clone? Check out this incredibly well-built USB volume knob.
Continue reading “Chachka: A Trinket Clone”
In case you weren’t aware, that little ‘write protect’ switch on your SD cards probably doesn’t do anything. It’s only a switch, really, and if an SD card reader doesn’t bother to send that signal to your computer, it’s completely ineffective. Then there’s the question of your OS actually doing something with that write protect signal.
The better way to go about write protecting an SD card is using the TMP_WRITE_PROTECT bit on the SD card’s controller. [Nephiel] came up with an amazingly small device to set that bit, with the entire circuit fitting inside an old Playstation memory card.
[Nephiel] based his project on [Karl Lunt]’s SD Card Locker we saw late last year. [Karl]’s SD Locker uses an ATMega328 microcontroller, a pair of AA batteries, and an SD card socket to perform the bit toggling. This is still a very small device that fits inside an Altoids tin, but [Nephiel] thought he could make it smaller.
The new and improved version uses an ATTiny85 for SPI access to the SD card. A single button and LED serves as the user interface: with the LED off, the SD card is writable. Press the button, the card is locked, and the LED lights up.
It may not look like much, but the above pictured device is [qquuiinn’s] handy little watch that indicates time through pulsed vibrations. Perhaps we should refrain from labeling it as a “watch,” however, considering it’s [qquuiinn’s] intention to remove the need to actually look at the thing. Vibrations occur in grandfather clock format, with one long vibration for each hour, accompanied by one, two, or three short pulses for the quarter-hour increments.
The design is straightforward, using an ATTiny85 for the brains along with a few analog components. The vibration motor sticks to the protoboard with some glue, joining the microcontroller, a coin cell battery, and a pushbutton on a small protoboard. The button allows for manual time requests; one press responds with the current time (approximated, probably) in vibrations. The build is a work in progress, and [qquuiinn] acknowledges the lack of an RTC (real-time clock) causes some drift in the timepiece’s accuracy. We suspect, however, that you’d address that problem—twice daily—when you replace the battery: it only lasts ten hours.
[Ralph] has been working on an extraordinarily tiny bootloader for the ATtiny85, and although coding in assembly does have some merits in this regard, writing in C and using AVR Libc is so much more convenient. Through his trials of slimming down pieces of code to the bare minimum, he’s found a few ways to easily trim a few bytes off code compiled with AVR-GCC.
To test his ideas out, [Ralph] first coded up a short program that reads the ATtiny85’s internal temperature sensor. Dissassembling the code, he found the a jump to a function called __ctors_end: before the jump to main. According to the ATtiny85 datasheet, this call sets the IO registers to their initial values. These initial values are 0, so that’s 16 bytes that can be saved. This function also sets the stack pointer to its initial value, so another 16 bytes can be optimized out.
If you’re not using interrupts on an ATtiny, you can get rid of 30 bytes of code by getting rid of the interrupt vector table. In the end, [Ralph] was able to take a 274 byte program and trim it down to 190 bytes. Compared to the 8k of Flash on the ‘tiny85, it’s a small amount saved, but if you’re banging your head against the limitations of this micro’s storage, this might be a good place to start.
Now if you want to hear some stories about optimizing code you’ve got to check out the Once Upon Atari documentary. They spent months hand optimizing code to make it fit on the cartridges.