I got into AVR chips because they are easy to program, and that has become more and more true over the years with the ever-falling cost of programmers. But it’s pretty easy to make a mistake when burning the fuses on the chips and if you don’t have a proper programmer (my first programmer was a horrifyingly slow self-built DAPA cable) you’ll have a brick on your hands. This little board may be able to help in that situation. I gave the USB µISP a try this week. The half-stick-of-gum-sized board flashes firmware like a champ and includes a rescue pin for when you have clock source problems.
There are a few AVR microcontrollers with onboard temperature sensors. These temperature sensors are neither accurate nor precise, but they do work for a few use cases. [Thomas] came up with a little bit of code that runs on all AVR microcontrollers, and is at least as accurate as the sensors in the rare AVRs that have them.
Although not all AVRs have a temperature sensor, they do all have RC oscillators, and these RC oscillators are temperature sensitive. By combining the RC oscillator and watchdog timer, [Thomas]’ code can get a vague idea if it’s getting hotter or colder.
To prove his code works, [Thomas] took an ATtiny13A chip loaded up with a few bits of code and placed a heated coin on it. The chip was programmed to turn on an LED when it detected a rise in temperature, and predictably, the LED lit up. With a coin chilled in a bowl of ice water, another bit of code ran, flashing the LED.
While we’re sure it’s neither accurate nor precise, it does have its uses – overheating protection or a simple thermostat. You can check out a video of the code in action below.
He started off making an AVR synthesized guitar, but [Erix] ended up with much more: a complete six-voice AVR wavetable synthesis song machine that’ll run on an ATMega328 — for instance, on an Arduino Uno.
If you’re an AVR coder, or interested in direct-digital synthesis or PWM audio output, you should have a look at his code (zip file). If you’d just like to use the chip to make some tunes, have a gander at the video below the break.
[Bogdan] makes a good point. When you use a dev board you get programming, debugging, power sourcing, and usually a UART. When you go to the trouble of hooking up a programmer why don’t you get the same thing? Astutely, he points out that all you usually get with programmers is programming. So he set out to add features to the hardware he uses to program XMEGA.
The first part of the trick hinges on his use of PDI programming. This is slightly different from ISP programming. Both use a six-pin connector cable but with PDI two of these pins are unused. He took this opportunity to reroute the chip’s TX and RX pins through the cable, which now gives him an avenue to use a UART-to-USB adapter without adding any cables to his target board. Rather than add a second USB cable he rolled a USB hub into the mix. An LM1117 regulates the 5V USB rail down to 3.3V as a source for the target board.
The programmer being used is an Atmel ICE. As you might imagine he didn’t want to make permanent alterations to it. His modifications are all handled externally, with one IDC cable connecting the programmer to his added circuitry and another headed off to the target board. For now he’s jumpering RX/TX to the programming header but plans to route the signals on future PCBs.
The most common way of programming AVR microcontrollers is the In System Programming port. That little six-pin header with MOSIs and MISOs coming out of it will program every AVR you’ll ever come across. The ISP does have a downside – fuses. Set your fuses wrong, and without a High Voltage Serial Programmer, your chip is bricked. [Dilshan] designed his own HVSP that’s less expensive than the Atmel STK500 and has a nice GUI app.
Instead of following in the footsteps of the USBtinyISP, [Dilshan] is using a PIC18F as the main microcontroller in the programmer. This chip was chosen because of its built-in USB functionality. Because the High Voltage part of a HVSP operates at 12V, actually providing that voltage needed to be taken into consideration. For this, [Dilshan] is using standard 78xx regulators with an 18V input.
The app to control this programmer does everything you would expect, including all the usual AVRdude commands. A great build, and just what we need to reset the fuses on a few dozen chips we have sitting around.
[Juan] sent us his writeup of a microcomputer he built using an Arduino UNO (AVR ATmega328p) and some off-board SRAM. This one’s truly minimalistic.
Have a look at the schematics (PDF). There’s an Arduino, the SPI SRAM, some transistors for TV video output, and a PS/2 connector for the keyboard. That’s it, really. It’s easily built on a breadboard in a few minutes if you have the parts on hand. Flash the Dan64 operating system and virtual machine into the AVR and you’re good to go.
Now we’ve seen a few 6502-based retro computers around here lately that use a 6502 paired with a microcontroller for the interfacing, but they’ve all been bulky three-chip affairs. [Juan] wins the minimalism prize by using a 6502 virtual machine implemented in the AVR to reduce the parts count down to two chips for the whole shooting match.
Using a 6502 virtual machine was a crucial choice in the design, because there are 6502 cross compilers that will let you compile and debug code for the microcomputer on your macrocomputer and then load it into the micro to run. This makes developing for the micro less painful.
How does it load programs you ask? The old-fashioned way of course, using audio files. Although rather than using the Kansas City Standard as in days of yore, he encodes the data in short and long pulses of square waves. This might be less reliable, but it sure saves on external hardware.
[Frank] has a Ultimaker2 and wanted to install a new bootloader for the microcontroller without having physical access to the circuitry. That means installing a new bootloader for the ATMega2560 without an In System Programmer, and as is usual on AVRs, the bootloader can only be edited with an ISP. Additionally, modifying the bootloader in any way runs the risk of corruption and a bricked circuit. That’s okay, because [Frank] knows how to do it, and he’s here to show you how.
You can think of the memory layout of the ATMega in the Ultimaker as being split in half, with the printer firmware in the first half and the bootloader in the second half. There’s extra space in both halves, and that’s something that comes in very useful. When the circuit powers up, it jumps to the bootloader, does it’s thing, then jumps to the very beginning of the application code – a vector table – that starts up the actual firmware.
[Frank]’s trick to adding on to the bootloader is to place the SD card bootloader in the space normally reserved for applications, not where you would expect to find a bootloader. This code is accessed by the stock bootloader jumping into a modified vector table at the beginning of the application data that points to new executable code. That code is the actual SD card bootloader, but because it is in the application part of the memory, it can’t perform Flash writing or erasing. To fix that, a tiny bit of code is tacked onto the end of the bootloader for performing Flash writes and jumps back to the application part of memory.