uPSD334 Instruction timing when PFQ and BC are disabled

[asterna]

Posted on January 14, 2005 at 23:35

uPSD334 Instruction timing when PFQ and BC are disabled

[asterna]

Posted on May 17, 2011 at 12:05

Hello,

I must disable PFQ and BC in some sections of my code to ensure deterministic execution (timing is essential).

I understand that for instruction timing I should take the number of machine cycles from Instruction Set, multiply it by number of MCU clocks per machine cycle and add the number of wait periods, depending on the instruction type (code wait and possibly RD/WR wait for MOVX instruction as set in BUSCON).

I made experiments in which I measured execution time for blocks of 1000 instruction (using timer) to check the real instruction execution time.

The results are a little bit confusing for some instructions.

I used the following settings:

OSC clocks per machine cycle = 4

Wait time settings (BUSCON):

CW = 00 (3 clocks), RDW = 00 (4 clocks), WRW = 00 (4 clocks).

For most instructions the results are as expected, e.g.:

NOP, RRC A, CLR C, CLR bit = 7 (4+3) clocks

MOV bit,C, SJMP rel, JC rel, DJNZ Rn,rel = 11 (2*4+3) clocks

But some instructions show greater time then expected, e.g.:

ANL direct,#data, JB bit,rel expected = 11 (2*4+3), real 12

BUSCON description in datasheet says about some exception, namely that CW, even if set to 3 clock periods, results 4 clock periods for MOVC instructions (I understand MOVC A, @A+DPTR and MOVC a,@A+PC).

My first thought was that MOVC refers to all situations, when extra data (in addition to opcode) is read from code memory. But tests do not support this assumption (e.g. CLR bit needs extra byte and the measured time is (4+3) clocks, as expected).

So, my theory is now that number of clocks for all 3 byte instructions should be computed according to the following formula (of course not for MOVX instructions):

(number_of_cycles * clocks_per_cycle) + code_wait + 1

Am I right or there is some catch in this?

I would be grateful for explanation of this problem

[asterna]

Posted on May 17, 2011 at 12:05

Sorry for the mistake in message header.

The correct microcontroller type is uPSD 3334D