retiw and "negative" w

Jim Kueneman

I am learning to program the SX and I have a question about the following code

mov    w, #-100
retiw

I struggle as to what "-" means here. There is no sign bit in the registers (that I see) so is this just a special case for using such a thing? Is what is really happening here is you are "adding and rolling over" the correct value to rtcc to make it look like you subtracted 100 from it and doing it without causing another rollover interrupt?

Thanks,
Jim

JonnyMac

That's an easy way to set the RTCC to a specific value so that it will fire in that many cycles. The RTCC counts upward and at the 255-->0 rollover the interrupt is triggered. If you look at -100 as a binary value, the decimal equivalent is 156, this means that in 100 counts you'll get to zero and have an interrupt.

Phil Pilgrim (PhiPi)

mov w,#-100 is exactly the same as mov w,#156. Both generate the same object code, since -100 and 156 are the same number in twos-complement notation (i.e. $9C). So the net effect of your code is to add 156 to RTCC on exit from the interrupt service routine.

-Phil

Jim Kueneman

Thanks, that is what I thought. New question I am doing this:

org     $0
interrupt
    clrb    PWM_0
    setb    PWM_1           ; Reset the period    
    test    PWM_SPEED    ; Is the speed 0?
    sz                     ; skip if zero flag set
    jmp    _ISR_PWM_RUN
    mov    w, #-39
retiw    

_ISR_PWM_RUN
......
retiw .....

main
        
main_loop    
    jmp     main_loop                       ;back to main loop

The OPTION register is set for 1:64 for the rtcc.

In the interrupt PWM_SPEED is always 0 so _ISR_PWM_RUN is never called.

I run it in SxSim and break on the first line of the interrupt.

Loop 1 = 2498 cycles
Loop 2 = 2495 cycles
Loop 3 = 2495 cycles
Loop 4 = 2498 cycles
Loop 5 = 2495 cycles
Loop 6 = 2495 cycles
....

I thought this was suppose to be jitter free interrupts


Thanks,
Jim

Jim Kueneman

Somebody said...
Some instructions (e.g. JMP) require more than one cycle to execute. An interrupt will never interfere with an "executing" instruction midstream.

Understood. Thanks.

Jim

Phil Pilgrim (PhiPi)

Jim,

I deleted the post you responded to, since I wasn't yet sure it was the right explanation. But now I'm convinced it was. Your RTCC period is 2496 cycles which, although it's divisible by three, causes interrupts in the middle of your JMP. So the JMP must run to completion before the interrupt can be serviced. On average the cycle length you experience will be 2496, but any instruction-length jitter is inevitable.

As a test, you could simulate your code in non-turbo mode, wherein JMPs are two cycles long. The jitter you see should be no longer than two cycles in that case.

-Phil

Bean

I'm pretty sure the hardware WILL interrupt at exactly the correct number of cycles. Regardless if it is during a JMP instruction.

I think maybe it is SX-Sim that is giving the cycle count incorrectly.

Bean.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
www.hittconsulting.com
·

Phil Pilgrim (PhiPi)

Bean,

You're right. I found this bit of info here, quoting an old Parallax press release:

Parallax said...
Detecting and responding to real-world events in a timely fashion is key for most MCU applications. That's most certainly the case for 'Virtual Peripherals' in which SX software must deliver the fast and precise timing of dedicated hardware.

Here, the advantages of the SX RISC-like architecture over other MCUs are most apparent. Most of the older popular MCUs have CISC instruction sets in which instruction execution times are variable. Thus, interrupt response time for these chips is not predictable, varying from dozens to more than a hundred clocks depending on the instruction being executed when an interrupt occurs. This introduces unavoidable 'jitter' into the system timing, fundamentally limiting performance (i.e. resolution and S/N ratio).

By contrast, all SX instructions are fixed length (12-bits) and most execute in a single clock. As is usual in pipelined designs, branches take longer (3 clocks) since the pipeline must be refilled. However, the SX avoids even this small amount of uncertainty by simply canceling or 'annulling' partially executed instructions, allowing immediate response if an interrupt is detected.

Often older MCUs must further save critical registers before handling the interrupt and then restore them upon completion. To avoid this bottleneck, the SX includes dedicated stack locations and automatic state, save and restore.

The bottom line is that the SX responds more quickly and predictably (3 clocks for an internal interrupt request, 5 clocks external) than other 8-bit MCUs. In fact, according to Leung, "The deterministic, sub-100 ns interrupt response of the SX is superior to that offered by much higher priced 16-bit MCUs and DSPs".

So it must be the simulator.

-Phil

Jim Kueneman

Thanks for the follow up. I don't have a requirement for that tight of jitter so I moved on but it is good to know.

Jim