MSP430G needs more MClock-Cyles for same instruction as an MSP430F Device

Kaj Uppenkamp said:

measured cycles

How exactly you measure cycles?

Hi,

I have used the CCSTEP "Register" inside the IAR-Workbench.

For _NOP() Instruction it shows the correct value :-)

First this to know is that "clr.b" is in fact "mov.b #0,". The other instructions uses the same number of cycles.

On the F serie there is a constant generator used with R2/R3, and there is six defined value available through this method.

So a move with a constant (for example 0) do not required the load value cycle, what sounds logical for me is that this function is not implemented in the G series, or perhaps the compiler won't optimize this and do not use R2/R3, but I doubt it, IAR made great compiler.

I've not all details, only what I remember when playing with msp430.

Kaj Uppenkamp said:

Do you have an idea ?

I may be mistaken but doesn't the G2553 use a CPU code and the F5xx have CPUX core?

Isn't TI allowed to improve performance of products as it develops newer technologies and families of devices?

Is this just a curiosity or a real issue for you?

Is this just a curiosity or a real issue for you?

  ??? mmmh, yes. This is an issue.

 

I have to port an application from an MSP430F5xxx to an MSP430Gxxx, especially to the smallest one: MSP430G2001.

So I have something to do by code and not by Timer-Hardware.Every MClock is important :-)
So I recognized the difference between the two µControllers.

..... the F5xx have CPUX core

I think this is only interesting for addressranges above 64K.

 Isn't TI allowed to improve performance of products as it develops newer technologies and families of devices?

Certainly not, but it should be also allowed to be wondering, when something goes faster or slower.

The only thing i could find, is this note (slau208k):

The MSP430X CPU implemented on these devices has, in some cases, slightly different
cycle counts from the MSP430X CPU implemented on the 2xx and 4xx families.

And this is not really helpful to understand why !

And somewhere else:

The MSP430X CPU is completely backward compatible with the MSP430 CPU

I understand "completely backward compatible" as function compatible and timing. My mistake .... sorry for that :-()

 

On the F serie there is a constant generator used with R2/R3, and there is six defined value available through this method.

There is the same contant generator in the G serie.

There are at least 3 different versions of CPU -- MSP430, MSP430X, and MSP430X2. The M-cycles differ slightly.

If you are using c and worry about M-clocks, you must be very brave. Even Assemblers nowadays generate machine codes that wast M-clocks.

Yes most C programmers never really care about precise clocks

I'm a Assembler programmer and when the byte $55 got sent it never showed up correct.
It turned out that those extra 3 clks for each bitchange and $55 has max changes made the last bit out of sync.
So I made the program so that total clock is the same

NMI_ISR     mov.b   #8,R5                     ; 1 start bit + 8 bits
            mov.b   #13,R6                    ; 104 cycles /2
baudloop    dec.b   R6                        ; 1 cycle
            jnz     baudloop                  ; 2 cycles
            mov.b   #27,R6                    ; 81 cycles + overhead = 104 cycles (9600 baud @1mhz)
            bit.b   #NMIIFG,&IFG1             ; is the IRQ flag set?
            bic.b   #NMIIFG,&IFG1             ; clear NMI flag in both cases (z is not affected)          
            jz      nobitchange               ; jump if z=1, bit = 0
            xor.w   #0x3300+WDTNMIES,&WDTCTL  ; xor edge, also turn 0x69 in to 0x5a
            sub.b   #2,R6                     ; above insruction is 5 and myself 1, so run loop 25
nobitchange bit.w   #WDTNMIES,&WDTCTL         ; Is falling edge selected?, set C

Spooky said:

Why does the MSP430G2353 often needs one more cycle  ???

Not one more. The F5x takes one less for MOV instructions from/to memory. The F5x family has MSP430X2 core that does pipelining a bit more efficiently.

Difference CPU, different core, different timing behavior, even though the result (in terms of state changes) is the same for the same sequence of instructions.
Interrupt latency has been reduced by one cycle too.

In FRAM, timing behavior is again different because on >8MHz CPU speed, access to FRAM requires a waitstate, while instruction steps that do not read FRAM (like ram/HW-register read/write) don't. Moreover, the cache implemented in FRAM makes up for some waitstates, depending on alignment of the instruction to the cacheline and whether the instruction reads from a different FRAM location or not (invalidating the cache)

Well, if you need timing, use a timer. That's why these thingies are called 'timer' and not 'counter'. :)