When exactly does the Interrupt routine start running in an SX/B program.

RobotWorkshop

I don't recall seeing this question come up before but when exactly does the Interrupt routine as defined in an SX/B program really start executing? Does it wait until after the housekeeping stuff is done like configuring the I/O ports, etc or does it fire up right away?

Suppose you want to hold off starting up the ISR routine for a little bit when your program starts. Would it be best to just set a flag in the ISR, let it run, and use that to tell the ISR to do its job? Or, would you want to disable the interrupts until you are ready for them.

One case in particular is when using a program on the SX chip with a background UART in the ISR. If it is connected to another device which is powered at the same time and the device may misbehave by sending junk as it starts then it would be reasonable to put in a delay or otherwise tell the background serial code to ignore anything on the line for a second or so after power is applied.

This is one issue I just ran across when using an SX48 for a new project. I wired up a display to show any data sent to it on the serial line. I noticed a couple garbage characters on power up and if I can add a delay before the ISR starts that should fix that issue.

Best Regards,

Robert

Bean

Periodic interrupts are enabled just before your main code is started (after memory is cleared and ports are setup).

For your situation, I would make the pin an INPUT, then after you get the variables setup make it an OUTPUT.

Bean

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
www.iElectronicDesigns.com

·

RobotWorkshop

Typically after the interrupt code i've started the program with something like:

Start:
AIO = %00000111 ' Setup port A
BIO = %10000111 ' Setup port B

' Setup variables to initial values

Main:

' Main program code here....

Goto Main


Would the ISR start as soon as it hits the start of the program or wait until it gets to the main portion of the program? I'm still not 100% clear at what point the ISR is enabled when the chip is powered up.

The pin in question is already an input to start with. The issue is that the SX48 seems to receive some garbage from the other end when everything starts up. I think that if I can tell it to hold off looking at the pin after a reset or power up that should fix it.

Robert

Zoot

Robert -- to the best of my knowledge, RTCC interrupts are enabled by activating RTCC rollovers in the options register, setting whether you are using RTCC rollover or RTCC pin for trigger, setting prescaler.

Then of course, it is presumed that the RTCC itself will have some kind of -W value written to it at the end of the ISR so that the next iteration is run when it is supposed to.

In SX/B, the startup code automatically sets the options reg. properly, calculates prescaler and RETIW (thank you, Bean!), so unless your program is pure assembly, you can't get control over WHEN this happens at reset or after a powerdown. If you look at the list file from an SX/B program you'll see it in the assembly in the startup code, in the order Bean mentions.

Using NOSTARTUP leaves file registers and such in their startup state, but will *still* set up the ports and options, btw.

Options register:
RTW   RTE_IE   RTS   RTE_ES   PSA   PS2   PS1   PS0 
Bit 7                                                      ... Bit 0 
 
7 -- RTW -- 0 = Register 01 addresses W, 1 = RTCC 
6 -- RTE_IE -- 0 = RTCC rollover interrupt enabled, 1 = disabled 
5 -- RTS -- 0 = RTCC increments on internal instr. cycle, 1 = RTCC increments on RTCC input transition 
4 -- RTE_ES -- 0 = RTCC increments on rising edges on RTCC pin, 1 = RTCC increments on falling edges on RTCC pin 
3 -- PSA -- 0 = Prescaler assigned to RTCC, 1 = Prescaler assigned to Watchdog timer 
2 -- PS2 -- Prescaler divider setting 
1 -- PS1 -- 1:2 ... 1:256 for RTCC, 1:1...1:128 for WDT 
0 -- PS0 --  WD timeout: 0.016 ... 2.0 seconds 

(Bean, correct me if I'm wrong on any of this...)

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
When the going gets weird, the weird turn pro. -- HST

RobotWorkshop

Thanks for the extra details. I suppose I should start reviewing the assembly code a bit after compiling the original program with SX/B.

For the moment I may just use a flag that the ISR routine can check right upon entry to see if it is suppose to be active. After a slight delay in the main body of the program I can just toggle on that flag so that the ISR routine can just fall through and run normally.

Only a few more issues to shake out and another old robot will be working again...

Best Regards,

Robert

Zoot

Robert -- I've done the exact same thing in some SX/B programs -- set a flag in the mainline program to let the ISR know that it is initialized, etc. (Although sometimes I think this may point more to inadequacies in my programming style and program designs -- grin -- )

There's a tradeoff there, for sure -- I use a lot of ASM in my SX/B programs, but I like having SX/B as the overall framework -- highly convenient esp. for the mainline program. IMO, SX/B generates *really* nice and efficient code for something that is "auto-generated" assembly (Bean is the man!).

But if a program is taken out of the SX/B environment, you can generally make things *very* compact, gain a bit more control over subtler features, AND claim back global variable space used by the PARAM vars defined in SX/B. I guess it's always question of what the needs of the project are.

Bean -- how difficult would it be to extend the NOSTARTUP directive to allow for setting/not-setting vars, AND/OR setting/not-setting options, AND/OR setting/not-setting ports and such? Rather than ports/options always being setup and vars being the optional aspect?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
When the going gets weird, the weird turn pro. -- HST

Bean

Zoot said...

Bean -- how difficult would it be to extend the NOSTARTUP directive to allow for setting/not-setting vars, AND/OR setting/not-setting options, AND/OR setting/not-setting ports and such? Rather than ports/options always being setup and vars being the optional aspect?

Probably not too hard. Let me think about an elegant way to do it.

Bean.


▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
www.iElectronicDesigns.com

·