Clock speed on a atiny13a

Go To Last Post
12 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I might be wrong, but I have a Atiny13a, and if I do a simple toggle pin with no delay, I messure a frequence at 118 kHz isch. but acourting to the datasheet, it has a frequence at 4,8 or 9,3 Mhz, how do I reach that frequence ? I might be wrong, but when i do a simple toggle, with no delay, only plain portb = ~portb, how can i reach the speed in Mhz

 

Best reagards

 

Romdata

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Can we see your actual program? And, what are your fuse settings?

 

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It Is realy just this simple

 

/*

 * test3.c

 *

 * Created: 31-08-2018 05:36:49

 * Author : ricky

 */ 

 

#include <avr/io.h>

 

 

int main(void)

{

DDRB=0xFF;

PORTB = 0x00;

    /* Replace with your application code */

    while (1) 

    {

PORTB = ~PORTB;

    }

}

 

My fuses are set as defaults - se attachment

 

And as you see at my scope, it only messures 118,??? kHz

 

 

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The fuse display says that it should be  running at 9.6MHz. An output clock rate of 118KHz says 83 CPU clocks per output cycle. I don't believe it.

 

Toggling that way is a read-modify-write operation that takes several actual operations per toggle. But, even if it is 5 or 6 clocks per toggle, that is still a long ways from 83.

 

The next thing is to check the assembly listing. That is in the .lss file that is generated by the compiler. You should find it in the "debug" folder in your project directory. Please copy and post the code part of that listing.

 

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

Last Edited: Fri. Aug 31, 2018 - 06:07 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

 

test3.elf:     file format elf32-avr

 

Sections:

Idx Name          Size      VMA       LMA       File off  Algn

  0 .text         00000034  00000000  00000000  00000054  2**1

                  CONTENTS, ALLOC, LOAD, READONLY, CODE

  1 .data         00000000  00800060  00800060  00000088  2**0

                  CONTENTS, ALLOC, LOAD, DATA

  2 .comment      00000030  00000000  00000000  00000088  2**0

                  CONTENTS, READONLY

  3 .note.gnu.avr.deviceinfo 0000003c  00000000  00000000  000000b8  2**2

                  CONTENTS, READONLY

  4 .debug_aranges 00000020  00000000  00000000  000000f4  2**0

                  CONTENTS, READONLY, DEBUGGING

  5 .debug_info   00000364  00000000  00000000  00000114  2**0

                  CONTENTS, READONLY, DEBUGGING

  6 .debug_abbrev 0000030c  00000000  00000000  00000478  2**0

                  CONTENTS, READONLY, DEBUGGING

  7 .debug_line   0000017b  00000000  00000000  00000784  2**0

                  CONTENTS, READONLY, DEBUGGING

  8 .debug_frame  00000024  00000000  00000000  00000900  2**2

                  CONTENTS, READONLY, DEBUGGING

  9 .debug_str    0000023a  00000000  00000000  00000924  2**0

                  CONTENTS, READONLY, DEBUGGING

 10 .debug_ranges 00000010  00000000  00000000  00000b5e  2**0

                  CONTENTS, READONLY, DEBUGGING

 

Disassembly of section .text:

 

00000000 <__vectors>:

   0: 09 c0        rjmp .+18      ; 0x14 <__ctors_end>

   2: 0e c0        rjmp .+28      ; 0x20 <__bad_interrupt>

   4: 0d c0        rjmp .+26      ; 0x20 <__bad_interrupt>

   6: 0c c0        rjmp .+24      ; 0x20 <__bad_interrupt>

   8: 0b c0        rjmp .+22      ; 0x20 <__bad_interrupt>

   a: 0a c0        rjmp .+20      ; 0x20 <__bad_interrupt>

   c: 09 c0        rjmp .+18      ; 0x20 <__bad_interrupt>

   e: 08 c0        rjmp .+16      ; 0x20 <__bad_interrupt>

  10: 07 c0        rjmp .+14      ; 0x20 <__bad_interrupt>

  12: 06 c0        rjmp .+12      ; 0x20 <__bad_interrupt>

 

00000014 <__ctors_end>:

  14: 11 24        eor r1, r1

  16: 1f be        out 0x3f, r1 ; 63

  18: cf e9        ldi r28, 0x9F ; 159

  1a: cd bf        out 0x3d, r28 ; 61

  1c: 02 d0        rcall .+4      ; 0x22 <main>

  1e: 08 c0        rjmp .+16      ; 0x30 <_exit>

 

00000020 <__bad_interrupt>:

  20: ef cf        rjmp .-34      ; 0x0 <__vectors>

 

00000022 <main>:

#include <avr/io.h>

 

 

int main(void)

{

DDRB=0xFF;

  22: 8f ef        ldi r24, 0xFF ; 255

  24: 87 bb        out 0x17, r24 ; 23

PORTB = 0x00;

  26: 18 ba        out 0x18, r1 ; 24

    /* Replace with your application code */

    while (1) 

    {

PORTB = ~PORTB;

  28: 88 b3        in r24, 0x18 ; 24

  2a: 80 95        com r24

  2c: 88 bb        out 0x18, r24 ; 24

  2e: fc cf        rjmp .-8      ; 0x28 <main+0x6>

 

00000030 <_exit>:

  30: f8 94        cli

 

00000032 <__stop_program>:

  32: ff cf        rjmp .-2      ; 0x32 <__stop_program>

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Your fuses show CKDIV8 being set.  9.6 MHz / 8 = 1.2 MHz or .833 us per clock cycle.  That works out to 10 CPU cycles per entire hi-lo output cycle, or 5 CPU cycles per pass through the loop - seems about right.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yaer I just removed that devide by 8 fuses, and I now counts approximately 953.xxx kHz

So that is what I can get out of it, because it does several cycles to do one things, Am I right ???

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

No the fuse display says it is running at 9.6MHz divided by eight (CKDIV8). That makes 1.2MHz.

So about ten clocks per period would make a 120kHz frequency.

 

And the assembly listing confirms that. One toggle cycle consists of instructions IN - COM - OUT - RJMP. IIRC rjmp takes two clock cycles and the rest take one, so that would make it five cycles per toggle. And ten cycles per period.

 

EDIT: Ok, I'm a slow typer. You got an answer and replied before I managed to post this smiley

Last Edited: Fri. Aug 31, 2018 - 06:28 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

A modern AVR can toggle the PORTx when you write to PINx. Check your Tiny13 datasheet.
So your loop would be just OUT and RJMP. Which is only 3 cycles.
.
If you just want the fastest square wave on a single pin, use a Timer in CTC mode with a hardware PWM pin. 4.8Mhz.
.
David.

Last Edited: Fri. Aug 31, 2018 - 06:37 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You should be able to get slightly faster by not reading the port; something like

int main(void) {
    char c = 0;
    while (1) {
	PORTB = c;
	c = ~c;
    }
}
00000022 <main>:
  22:   80 e0           ldi     r24, 0x00       ; 0
  24:   88 bb           out     0x18, r24       ; 24
  26:   80 95           com     r24
  28:   fd cf           rjmp    .-6             ; 0x24 <main+0x2>

 

And a bit better than that (with periodic glitches) by "un-rolling" the loop:

int main(void) {
    char c = 0;
    char d = 0xFF;
    while (1) {
	PORTB = c;
	PORTB = d;
	PORTB = c;
	PORTB = d;
	PORTB = c;
	PORTB = d;
	PORTB = c;
	PORTB = d;
	PORTB = c;
	PORTB = d;
    }	
}
00000022 <main>:
  22:   8f ef           ldi     r24, 0xFF       ; 255
  24:   18 ba           out     0x18, r1        ; 24
  26:   88 bb           out     0x18, r24       ; 24
  28:   18 ba           out     0x18, r1        ; 24
  2a:   88 bb           out     0x18, r24       ; 24
  2c:   18 ba           out     0x18, r1        ; 24
  2e:   88 bb           out     0x18, r24       ; 24
  30:   18 ba           out     0x18, r1        ; 24
  32:   88 bb           out     0x18, r24       ; 24
  34:   18 ba           out     0x18, r1        ; 24
  36:   88 bb           out     0x18, r24       ; 24
  38:   f5 cf           rjmp    .-22            ; 0x24 <main+0x2>

 

And probably a bit more (actually, up to twice as fast, the way I read the datasheet) by setting OSCCAL to 0x7F.

(I'm not sure why they picked a "nominal" frequency of "9.6MHz."  Seems like they could have equally said a nice even 10MHz, just by tuning the initial OSCCAL value.)

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well thank you all for your time, I do get it now, Thx a lot

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

david.prentice wrote:
If you just want the fastest square wave on a single pin
Or, if the chip has it - enable CLKO. That simply puts F_CPU out on one of the pins.