We don’t know if this will come as a surprise to the regular Hackaday reader, but a whole bunch of Atmel microcontrollers have a very cool feature hidden away in their datasheets. Most of them – everything from the ATMega 168, 328, 32u4, to the ATtiny85 and 84 have a temperature sensor right on the chip. [Connor] did a little bit of research on this sensor and came up with a little bit of code that spits out the core temperature of these Atmel chips over the serial port.
The temperature sensor on these Atmel chips is accessed by writing a code – ’100111′ for the Mega32u4 and ’100010′ for the tiny84, for example – into the ADMUX register on the chip. According to the datasheet, the returned temperature is accurate to +- 10°C, but that can be easily calibrated by holding an ice cube (in a plastic bag, of course) up to the chip.
With a little more code, [Connor] is able to output the temperature of the microcontroller core over a serial port. In testing, his chip started out at 20°C and reached equilibrium at 24°C after about a minute. Pretty neat, and could be used as a temperature sensor for a project in a pinch.
The advent of the Arduino brought the world of microcontrollers to hobbyists, students, and artist the world over. Right now we’re in the midst of a new expansion in hobbyist electronics with the Raspberry Pi, but we can’t expect everyone to stay in the comfortable, complex, and power-hungry world of Linux forever, can we? Eventually all those tinkerers will want to program a microcontroller, and if they already have a Raspberry Pi, why not use that?
[Kevin] wanted to turn his Raspi into an AVR development workstation, without using any external programmers. He decided to use the Raspi’s SPI port to talk to an AVR microcontroller and was able to make the electrical connections with just a few bits of wire an a handful of resistors.
For the software, [Kevin] added support for SPI to avrdude, available on his git. Theoretically, this should work with any AVR microcontroller with the most popular ATMegas and ATtinys we’ve come to love. It doesn’t support the very weird chips that use TPI programming, but it’s still extremely useful.
[Adam Laurie] spent time tearing into the security of the SAM7XC chip produced by Atmel. Even if he hadn’t found some glaring security holes just reading about his methodology is worth it.
The chip is used in a secure RFID system. The chip is added to the mix to do the heavy lifting required when using encryption. [Adam] grabbed a couple of open source libraries to put it to the test. The firmware is locked down pretty tight, but his explorations into the content of the RAM yield a treasure trove of bits. After investigating the sample code for the chip he’s shocked to learn that it uses RAM to store the keys at one point. The rest of his journey has him dumping the data and sifting through it until he gets to the “Master Diversification Key”. That’s the big daddy which will let him decrypt any of the tags used.
He reported his findings to Atmel in September of 2011. Their response is that they have no way of protecting RAM from exploit. [Adam] asserts that the problem is that the sample software wasn’t designed with the vulnerability of RAM in mind. The keys should never be stored there specifically because it is vulnerable to being dumped from a running system.
[blueHash] uses this cheap development board as an AVR programmer. What’s interesting to us is that it solves the chicken-or-egg problem that is usually encountered when bootstrapping a programmer. We’ve written about this issue before. Most programmers use microcontrollers, which first need to be flashed using a programmer. But it turns out the chip on this dev board has a DFU mode which gets around that conundrum.
He grabbed a uSD dev board for about $6. It’s got a crystal, an ATmega32u4 chip, and on the other side there’s a MicroSD card slot. We looked around and found an Atmel Datasheet (PDF) which describes the Device Firmware Upgrade mechanism. The AVR devices which support DFU are factory configured to use it. This dev board is designed to use DFU so all [blueHash] needed to do is find and configure a ISP firmware package that worked with this chip.
Atmel’s XMEGA series of microcontrollers are neat little pieces of hardware; with a very fast clock, a ton of IO, USB, and up to 8 UART ports, these neat little chips serve as a nice bridge between AVRs and PICs and the very powerful ARM chips coming out on the market. Unfortunately, the XMEGAs don’t use the extremely common ISP programming header found on just about every AVR dev board making them a bear to program. [Szu] over in Poland came up with a very easy way to program these chips, all while using the programming hardware you already have on hand.
[Szu]‘s build uses a few resistors and diodes to break out a USBASP connection to the XMEGA’s PDI interface. On the software side of things, [Szu] wrote an update to the USBASP firmware to allow it to program PDI devices, and also has a patch for AVRdude to allow uploading firmware from the command line.
A very cool build, and one that allows for very, very powerful devices that build on the AVR code you’ve already written.
It’s possible that it was [Matt Meerian]‘s awesome pun that won us over, not his ultrasonic bicycle dog defense system, but that would be silly. [Matt] wanted an elegant solution to a common problem when riding a bicycle, dogs. While, obscenities, ammonia, water, pepper spray, and others were suggested, they all had cons that just didn’t appeal to [Matt]. He liked the idea of using C02 powered high pressure sound waves to chase the dogs away with, but decided to choose a more electronic approach. He used a Atmel ATmega644 as the MCU, four 25kHz transmitters, and two 40kHz transmitters. When the rider sees a dog he simply flips a switch and it activates the transducers (along with, cleverly, a human audible horn so he doesn’t have to look down to know it’s working). So far [Matt] has not had a dog chase him in order to test it’s efficacy, but his cat clearly seems unaffected by the device as you can see after the break. Continue reading “Defense Against the Dog Arts”
[Rupert’s] friend cracked the screen on his beloved Dell Streak 5 phone and handed it off to see if [Rupert] could repair it. He says that the glass replacement was a relatively straightforward affair – a process he documented in thorough detail worthy of iFixit.
He did come across a few interesting tidbits along the way, including an Atmel Mega168P hanging out on the broken screen’s digitizer board, which now resides in his parts bin. The most intriguing thing [Rupert] discovered however was that the phone’s on-board memory chip wasn’t soldered in as he would have expected. Instead, he found a standard microSD slot with a 2GB card in tow. He didn’t happen to have a larger card on hand, but after researching a bit he did find out that swapping the card is a relatively simple process.
If you happen to have one of these phones sitting around, or come across a damaged unit at any point, it definitely seems worth it to resurrect it and change the factory card out for something along the lines of a 32GB model. We certainly wouldn’t complain if we had a rooted 32GB Streak kicking around!