ATtiny85 Clock Frequency Verifier

Introduction: ATtiny85 Clock Frequency Verifier

Recently I had a need for an application that I could run on a coin battery. Normally I would use a PIC microcontroller for low power but I wanted to explore Arduino options. Up until now my Arduino projects have used Nanos which are both too large and too power hungry for this type of application. I tried a Lilypad and got the power down but it was still a little bigger than I wanted. Next I tried a Digispark board but wasn’t able to get the power low enough. Another issue with all of these boards is that they all use a boot loader which eats up code space and delays startup of the application code. I then did some research on the ATtiny85 chip used on the Digispark board and found that I could easily program it using the Arduino IDE even though it doesn’t have a boot loader.

The other half of the ATtiny85 project I was contemplating could be done with any Arduino and doesn’t require battery operation but it does require the microcontroller to run at a minimum of 8-MHz. The ATtiny85 defaults to its 1-MHz internal clock but a simple procedure allows the IDE to reconfigure it for the 8-MHz internal clock. It was easy for me to test the frequency change because I have a nice digital oscilloscope. But I wanted an easier way to verify the change so I wrote a simple sketch to do that.

Step 1: Hardware

Because the ATtiny85 doesn’t have a boot loader, you basically need another Arduino in order to program it using the Arduino IDE. The setup is well documented online so I won’t repeat it here. That approach is bit cumbersome so I opted to buy the inexpensive (< $20) Sparkfun ATtiny85 USB programmer which has a socket exactly suited for the ATtiny85 chip. The programmer uses an AVR chip that handles the code transfer to the ATtiny85 in the same way that an external Arduino would. There are also connections on the programmer so you can actually use it as a development board just by connecting to your external components. The Sparkfun programmer has an onboard LED connected through a resistor to pin5 of the ATtiny85 socket (PB0). My program makes use of that LED so if you have a different programming setup just wire a 1k resistor and LED to pin5 of your ATtiny85.

Step 2: Software

The software is just a simple modification of the standard “Blink” program. It will blink at a slow rate if the ATtiny85 internal clock is running at 1-MHz and at a fast rate if the clock fuse has been set to 8-MHz. The code takes a reading of the current microseconds count and then performs a simple delay. After that it takes another reading of the microseconds count and uses the two counts to determine how much time has passed. Obviously, much more time will have passed when executing at 1-MHz versus executing at 8-MHz. The resulting count is then used to determine which path to take for flashing the LED.

You can go back and forth between 1-MHz and 8-MHz on your ATtiny85 chips because it just changes a writable fuse in the chip. So loading up this program first when you run the “Burn Bootloader” command to set the clock fuse gives you a quick and easy way to verify that the correct frequency has been set. Just make sure to click on the “Upload” button after the boot load command finishes and then watch the LED.

Be the First to Share

    Recommendations

    • Make it Glow Contest

      Make it Glow Contest
    • First Time Author Contest

      First Time Author Contest
    • PCB Challenge

      PCB Challenge

    4 Discussions

    0
    grovedc
    grovedc

    22 days ago on Step 2

    I'd have to admit to being confused. Looking at the code:

    Start_Time = micros();
    delayMicroseconds(5);
    End_Time = micros();

    if ((End_Time - Start_Time) >= 50) {

    This can only work if delayMicroseconds(5) actually takes more than 50 microseconds. So a slow clock causes delayMicroseconds(5) to "try its best", but you actually don't get the 5 microseconds, you get something greater than 50 microseconds?

    0
    Boomer48
    Boomer48

    Reply 21 days ago

    That value also includes time for the second read of "micros". I haven't looked at the code for the those functions to see how many assembly language steps they take. I did a lot of hobby projects on the PIC before "discovering" the Arduino. All of my PIC projects are written in assembly language so it made me very aware of software execution times based on clock speed.

    0
    grovedc
    grovedc

    Reply 21 days ago

    I agree. Basically, you can look at the test as calling two functions. At 1 megahertz, if you have 1 instruction per cycle, then you get 50 cycles just for the call/return overhead. Or, stated another way, at 1 megahertz, if you are asking for a 5 microsecond delay, then you only get 5 clock cycles for calling the delay function. I suspect that the call/return overhead is higher than that.

    In any event, thanks for the code. It does exactly what I needed. I was just puzzled as I looked at the code, hopefully this discussion can be useful for others.

    0
    Boomer48
    Boomer48

    Reply 21 days ago

    This is from the Arduino Reference:

    "This function works very accurately in the range 3 microseconds and up.
    We cannot assure that delayMicroseconds will perform precisely for
    smaller delay-times."

    That is based on the 16-MHz clock of the Uno. Multiply that by 16 for the 1-MHz ATtiny85 and you get 48usec as the bottom limit for accuracy.