In this post on the Arduino.cc forums and this blog post, [Majek] announced that he had fooled the AVR microcontroller inside and Arduino into writing user data into its own flash memory during runtime. Wow!
[Majek] has pulled off a very neat hack here. Normally, an AVR microcontroller can’t write to its own flash memory except when it’s in bootloader mode, and you’re stuck using EEPROM when you want to save non-volatile data. But EEPROM is scarce, relative to flash.
Now, under normal circumstances, writing into the flash program memory can get you into trouble. Indeed, the AVR has protections to prevent code that’s not hosted in the bootloader memory block from writing to flash. But of course, the bootloader has to be able to program the chip, so there’s got to be a way in.
The trick is that [Majek] has carefully modified the Arduino’s Optiboot bootloader so that it exposes a flash-write (SPM) command at a known location, so that he can then use this function from outside the bootloader. The AVR doesn’t prevent the SPM from proceeding, because it’s being called from within the bootloader memory, and all is well.
The modified version of the Optiboot bootloader is available on [Majek]’s Github. If you want to see how he did it, here are the diffs. A particularly nice touch is that this is all wrapped up in easy-to-write code with a working demo. So next time you’ve filled up the EEPROM, you can reach for this hack and log your data into flash program memory.
Thanks [Koepel] for the tip!
Most modern computers are able to dynamically adjust their operating frequency in order to save power when they’re not heavily used and provide instantaneous-seeming response when load increases. You might be surprised to hear that the lowly 8-bit AVR microcontrollers can also switch CPU-speed gears on the fly. In this edition of Embed with Elliot, we’ll dig into the AVR’s underappreciated CPU clock prescaler.
Continue reading “Embed With Elliot: Shifting Gears With AVR Microcontrollers”
A while ago, [Paul Stoffregen], the creator of the Teensy family of microcontrollers dug into the most popular Arduino library for driving TFT LCDs. The Teensy isn’t an Arduino – it’s much faster – but [Paul]’s library does everything more efficiently.
Even when using a standard Arduino, there are still speed and efficiency gains to be made when driving a TFT. [Xark] recently released his re-mix of the Adafruit GFX library and LCD drivers. It’s several times faster than the Adafruit library, so just in case you haven’t moved on the Teensy platform yet, this is the way to use one of these repurposed cell phone displays.
After reading about [Paul]’s experience with improving the TFT library for the Teensy, [Xark] grabbed an Arduino, an LCD, and an Open Workbench Logic Sniffer to see where the inefficiencies in the Adafruit library were. These displays are driven via SPI, where the clock signal goes low for every byte shifted out over the data line. With the Adafruit library, there was a lot of wasted time in between each clock signal, and with the right code the performance could be improved dramatically.
The writeup on how [Xark] improved the code for these displays is fantastic, and the results are impressive; he can fill a screen with pixels at about 13FPS, making games that don’t redraw too much of the screen at any one time a real possibility.
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.
My full review is below. All technical information for the µISP can be found in the User’s guide. The board itself is now available to purchase in the Hackaday Store.
Continue reading “Review: uISP programmer for AVR”
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.
Continue reading “Measuring Temperature On An AVR Without A Sensor”
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.
Continue reading “Slick Six-Voice Synth for AVRs”
[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.