Atmega644 instruction cycles count

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

Dear AVRFreaks

I'm running into a problem regarding Atmega644 cycle count for certain instructions, specifically the RCALL and RET instructions. According to the datasheet (doc2593.pdf), the RCALL instruction takes 4 cycles and the RET takes 5 cycles. These numbers are different from other AVR cores. Are they correct is my question?

I tried to use the cycle counter in AVR Studio, both simulator1 and simulator2 and get conflicting and confusing results. Sim1 gives me 3 cycles for the RCALL, 4 for the RET (most of the time), Sim2 gives 2 cycles for the RCALL and 3 for the RET.

What is the truth? I did search the forums to no avail and could not find an answer on the web.

Thanks

jrseattle

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

Even though it is not clearly or consistently documented, I believe that all of the mega AVRs require 3 cycles for RCALL and 4 cycles for RET if they have a program counter of 16 bits or less (128Kb or less flash memory). If a mega AVR has a program counter that is larger than 16 bits, then RCALL takes 4 cycles and RET takes 5 cycles because three bytes are pushed / popped to / from the stack instead of two.

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

Oh my, another screwed up data sheet :shock:! ATMEL has a spotty track record when it comes to data sheet accuracy and unfortunately known corrections are not consistently applied.

This document is supposed to have the instruction cycle times for all the AVRs including the Xmegas.
AVR Instruction Set:
http://www.atmel.com/dyn/resourc...

Your ATmega644 has a 16 bit PC (Program Counter).

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

It is not really the size of the flash memory that makes the difference, it is what generation the AVR core is. The latest generation is designed to handle larger flash memory, so it uses three bytes for the program counter even if the specific AVR that the core is in doesn't need it (such as the mega644).

Regards,
Steve A.

The Board helps those that help themselves.

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

Well, the ATmega640 uses a 16 bit PC (according to ATMEL tech support) and both ATmega256n chips in this family are 22 bit PCs. So, I find it surprising the ATmega644 would be a 22 bit PC.

There is also this:

ATmega644 data sheet page 17 wrote:
The ATmega644 Program Counter (PC) is 15/16 bits wide, thus addressing the 32/64K program memory locations.

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

OK, I found somewhere else that the instruction summary in the Atmega644 datasheet was copied from a larger AVR that indeed uses a 3 byte program counter and support the ELPM instruction, listed under the Atmega644 but not present AFAIK.
I doubled checked the SP over an RCALL and only 2 bytes are pushed which leads me to believe that the cycle count for the Atmega644 RCALL is 3, and for the RET is 4 cycles, consistent with other 2 byte PC AVRs.

Thanks for the replies

jrseattle

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

It also says (in the interrupt section):

Quote:
During these five clock cycles, the Program Counter (three bytes) is popped back from the Stack...

In older AVRs it says 4 clocks and two bytes.

Regards,
Steve A.

The Board helps those that help themselves.

Last Edited: Thu. Dec 11, 2008 - 07:24 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It looks like it is the datasheet that is wrong. In the simulator (version 2), RCALL takes 3 cycles and RET takes 4 for the mega644p. I would trust the simulator (at least version 2) more than the datasheet.

Regards,
Steve A.

The Board helps those that help themselves.

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

Is this with the latest revision of the datasheet?

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

Quote:

Is this with the latest revision of the datasheet?

...and are you dealing with a '644 or '644P? [but I'd think that would make no difference for the cycle counts under discussion]

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

On the current 164p/324p644p datasheet. Section 6.7.1 says 3 bytes and 5 clocks for returning from interrupt. And the instruction set summary says RCALL 4 clocks, RET and RETI 5 clocks. And the 644 datasheet agrees.

Regards,
Steve A.

The Board helps those that help themselves.

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

Interesting. I just happen to have a '324P on the bench. I'll try a "naked function" and check the timing on the 'scope.

void nakedfunc (void) {PINB.1 = 1;}
...
PINB.1 = 1;
PINB.1 = 1; // establish time base; should be 2 cycles
PINB.1 = 1;
nakedfunc();
PINB.1 = 1;
PINB.1 = 1; // establish time base; should be 2 cycles
PINB.1 = 1;

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

I did the test with nakedfunc(), which indeed is an SBI and RET:

                 ;void nakedfunc (void)
                 ; 0000 0198 {
                 _nakedfunc:
                 ; 0000 0199 	PINA.3 = 1;
0000db 9a03      	SBI  0x0,3
                 ; 0000 019A }
0000dc 9508      	RET

then do the sequence below, which compiles to SBI & RCALL

while (1)
	{
	PINA.3 = 1;
	PINA.3 = 1;
	PINA.3 = 1;
	nakedfunc();
	PINA.3 = 1;
	PINA.3 = 1;
	PINA.3 = 1;
	PINA.3 = 1;

	delay_ms (20);
	}

The clock is 7.3728MHz, which gives me a cycle time of 135.6xxxns. It happens to be a transistor drive circuit so there is a bit of rise/fall time; I'll round the measured times on the 'scope as best as I can. The sequence always starts with the pin low.

low ~20ms
high  270ns  first SBI   2 cycles
low   270ns  second SBI  2 cycles
high  660ns  third SBI + RCALL  5 cycles (right?  so 3 for RCALL)
low   830ns  function SBI + RET  6 cycles (right?  so 4 for RET)
high  270ns  first SBI after RET  2 cycles

So I'd say the datasheet(s) are wrong, and RCALL is 3 cycles, and RET is 4. RETI and CALL are left as an exercises for the reader.

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

There's motivational signs in the datasheet division- 'Copy and Paste Your Way to the Top', 'From One Datasheet, Many Datasheets', etc.

I doubt there is a RAMPZ register either, as the 164p/324p/644p datasheets says.

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

EW wrote:
Is this with the latest revision of the datasheet?
jrseattle wrote:
According to the datasheet (doc2593.pdf)....
From the ATMEL data sheet page:
http://www.atmel.com/dyn/product...
ATmega644 Preliminary (376 pages, revision M, updated 08/07)
http://www.atmel.com/dyn/resourc...

The data sheet I referred to in my replies was 2593M–AVR–08/07, which matches the current ATMEL data sheet web page.

There is an example code bug that was acknowledged by ATMEL on March 10, 2005 that still exists in 5 data sheets (reported and re-reported to ATMEL). Over the years I saw this uncorrected bug get copied into brand new data sheets time and time again. I'm sure its still waiting to get copied again from one of the surviving bad data sheets. Hence, my sarcasm in my first reply above.

BTW, excellent work on a definitive answer Lee. Thanks.

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

Quote:
I doubt there is a RAMPZ register either, as the 164p/324p/644p datasheets says.

It certainly won't compile in avr-gcc if you refer to RAMPZ in a mega644p.

Regards,
Steve A.

The Board helps those that help themselves.