New Part Day: ATtiny102 And 104

August 1, 2016 by Elliot Williams 89 Comments

Atmel put out some new, small microcontroller chips early this year, and we’re just now starting to think about how we’d use them. The ATtiny102 and ATtiny104 (datasheet) sell for about a buck (US) and come in manageable SOIC packages with eight and fourteen pins respectively. It’s a strange chip though, with capabilities that fit somewhere between the grain-of-rice-sized ATtiny10 and the hacker-staple ATtiny25-45-85 series.

The ATtiny104 has a bunch of pins for not much money. It’s got a real hardware USART, which none of the other low-end AVRs do, and it’s capable of SPI in master mode. It has only one counter, but it’s a 16-bit counter, and it’s got the full AVR 10-bit ADC instead of the ATtiny10’s limited 8-bit ADC. The biggest limitation, that it shares with the ATtiny10, is that it has only 1 KB of program flash memory and 32 bytes (!) of RAM. You’re probably going to want to program this beast in assembler.

Read on for more reviews, and check out [kodera2t]’s video review at the end.

Continue reading “New Part Day: ATtiny102 And 104” →

Encrypted USB Bootloader For AVRs

July 23, 2016 by Elliot Williams 13 Comments

It probably doesn’t matter much for the hacker who sleeps with a bag of various microcontroller flash programmers under the pillow, but for an end-user to apply a firmware upgrade, convenience is king. These days that means using USB, and there are a few good AVR USB bootloaders out there.

But [Dmitry Grinberg] wanted more: the ability to encrypt the ROM images and verify that they haven’t been tampered with or otherwise messed up in transit. Combined with the USB requirement, that meant writing his own bootloader and PC-side tools. His bootloader will take unencrypted uploads if it doesn’t have a password, but if it’s compiled with a key, it will only accept (correctly) encrypted hex files.

Since the bootloader, including the USB firmware, is on the hefty side at 3.3 kB, [Dmitry] included hooks to re-use the bootloader’s USB code from within the target application. So if you were going to use V-USB in your program anyway, it doesn’t actually take up that much extra space. It’s a cute trick, but it ties the bootloader and user program together in a way that gives us the willies, without specifically knowing why. Perhaps we can debate this in the comments.

If you need an AVR USB bootloader, but you don’t need the encryption, we like Micronucleus. But if you need to deliver updates to users without them being able to modify (or screw up) the code in the middle, give [Dmitry]’s setup a try.

Binary Keyboard Is The Purest Form Of Input Device

July 20, 2016 by Jenny List 55 Comments

You may be a hardcore keyboard aficionado whose buckled-spring switches will be pried from your cold dead hands, but there is a new model on the street that relegates your blank-key Das Keyboard or your trusty IBM Model M to the toy chest.

The new challenger comes from Reddit user [duckythescientist], who has created a minimalist three-key binary keyboard. It features a 0 key, a 1 key, a return key, and nothing else. Characters are entered as ASCII or Unicode, and the device emulates either a QWERTY or Dvorak keyboard layout to the host computer’s USB interface. It couldn’t be a simpler layout to learn, though we’d concede that not everyone has the entire binary Unicode table memorised.

The keys are mounted in a custom 3D printed case, and the electronics come from the creator’s own “tinydev” board based on an ATtiny85. All the code is available in a GitHub repository, and there is a very short video of its Unicode ability below the break.

Continue reading “Binary Keyboard Is The Purest Form Of Input Device” →

I2C Bit Injection Adds Memory Banks To Everything

July 12, 2016 by Moritz Walter 18 Comments

[Igor] wished to upgrade his newly acquired radio — a Baofeng UV-82 — with a larger memory for storing additional scanning channels, and came up with a very elegant solution: Replacing it’s EEPROM with a larger one and injecting the additional memory address bits into the I2C data line.

Continue reading “I2C Bit Injection Adds Memory Banks To Everything” →

Interactive WeddingBots Built Into Nespresso Capsules

July 1, 2016 by Moritz Walter 2 Comments

Today is a very special day for [Mandy and Sebastian], as they conclude the sacred solder joint of marriage. We send our sincerest congratulations and best wishes to the bridal couple, and can’t help but envy the guests of their ceremony, who received a very special wedding favor: A WeddingBot.

For their wedding party, [Mandy and Sebastian] created a little game on their own (translated). Each guest would receive a unique, little WeddingBot. Each of these is individually tailored for a certain guest and features a fitting look, a characteristic behavior and would play a special melody or jingle meaningful to this guest. However, the guests don’t get their WeddingBot, they get the WeddingBot of another guest – and the challenge to find this guest on the party. Guests would then exchange their WeddingBots, which also makes a great occasion to introduce themselves to each other. If the clues given by the WeddingBots themselves would not suffice to find the right owner, guest could place a WeddingBot on a clue station, which then would provide further hints by displaying images, texts or even riddles.

The design is based on the ATtiny45 microcontroller, with LEDs for the eyes, a light sensor, and a piezo disc for the sound as the main components. As an enclosure, they chose to repurpose empty Nespresso® capsules, which look nice and adds volume to the PCBs. The smiley face silk screen on the PCBs was then individualized with a black marker and packed in a beautiful hand-crafted box. The little fellows communicate with the Raspberry Pi based clue station by flashing their LEDs in a certain pattern. A light sensor hooked up to the Pi lets the station identify the bot and display the corresponding clue on a screen. Check out the video below to see how it works:

Continue reading “Interactive WeddingBots Built Into Nespresso Capsules” →

AVR Vs PIC, Round 223: Fight!

June 28, 2016 by Elliot Williams 91 Comments

Get ready to rumble! [Thierry] made the exact same Hello-World-esque project with two microcontrollers (that are now technically produced by the same firm!) to see how the experience went.

It’s not just an LED-blinker, though. He added in a light-detection function so that it only switches on at night. It uses the Forest Mims trick of reverse-biasing the LED and waiting for it to discharge its internal capacitance. The point is, however, that it gives the chip something to do instead of simply sleeping.

Although he’s an AVR user by habit, [Thierry] finds in favor of the PIC because it’s got a lower power draw both when idling and when awake and doing some computation. This is largely because the PIC has an onboard low-power oscillator that lets it limp along at 32 kHz, but also because the chip has a lower power consumption in general. In the end, it’s probably a 10% advantage to the PIC on power.

If you’re competent with one of the two chips, but not the other, his two versions of the same code would be a great way to start familiarizing yourself with the other. We really like his isDarkerThan() function which makes extensive use of sleep modes on both chips during the LED’s discharge period. And honestly, at this level the code for the two is more similar than different.

(Oh, and did you notice [Thierry]’s use of a paper clip as a coin-cell holder? It’s a hack!)

Surprisingly, we’ve managed to avoid taking a stray bullet from the crossfire that occasionally breaks out between the PIC and AVR fans. We have covered a “shootout” before, and PIC won that round too, although it was similarly close. Will the Microchip purchase of Atmel calm the flames? Let’s find out in the comment section. We have our popcorn ready!

Ask Hackaday: Whatever Happened To LED Light Sensors?

June 17, 2016 by Elliot Williams 17 Comments

If you’re a long-time Hackaday reader like we are, you’ll certainly remember a rash of projects from around ten years ago that all (mis-)used an LED as a light sensor. The idea wasn’t new, but somehow it made the rounds and insinuated itself into our collective minds. Around the same time, a cryptographic cipher with an exceptionally small memory footprint was also showing up in hacker projects: TEA (Tiny Encryption Algorithm).

This old project by [Marcin Bojanczyk], [Chris Danis], and [Brian Rogan] combines both the LED-as-light-sensor meme and TEA to make a door-entry keyfob that works over visible light. And they do so using almost nothing — a few LEDs and just over 2Kb of code. It’s pretty sweet.

Which brings us to the question: where are they (LED-sensors and TEA) now?

LED-as-light-sensor was just cool. We certainly loved the idea back in 2006. But [Forrest Mims] had been using the phenomenon for decades back then. It certainly makes sense when you’re trying to squeeze as much as possible out of as little as possible, or when budget is a main concern and you just can’t afford an extra photodiode.

But our own experience with LEDs as light sensors is that the results are extremely variable across different LEDs. Code that works with water-clear red LEDs might not work with the ones that come in red-tinted plastic, for instance. Is that why they went extinct?
Similarly, the TEA family of ciphers showed up in a bunch of projects around this time, from the badge for the HOPE conference in 2010 to a widely used RFM12B radio library. There are a couple of attacks on XXTEA, but they only affect reduced-round versions of the cipher, and rely on a tremendous amount of intercepted data — more than we’d see in a home-automation network over years.

Over the last five years or so, there’s been a lot more Internet of Things, which means using standard Internet-style encryption methods (AES and so on) that are widespread on non-memory-constrained computers. Is that what happened to XXTEA?

Anyway, we got tipped off to a project that combined a few of our favorite (old) ideas in one, so we thought that we’d share. Thanks [Blue Smoke] for the walk down memory lane. Any of you out there keeping the flame(s) alive? Have you used sensing LEDs or XXTEA? Are those projects still going, or do you have any future projects planned with these tricks still up your sleeve? Let us know in the comments below.