PowerUp and Reset Code in SX/B, RTCC interrupts in SX/B, Global VARS in SX/B

Zoot

I'm working on a program that is SX/B in the main program and almost all ASM in the ISR. The (minor) problem I was having on reset is that the ISR would start rolling before my own SX/B code at the start of the program had initialized things for me properly. For a quick workaround, my Start: SX/B code initializes a ready flag, an the ISR skips to it's own end until that bit is set.

Since SX/B is so phenomenally convenient, I hadn't peeked at the generated startup code too closely until last night. So here's the conundrum -- it seems that either I need to do my work around, or not use SX/B because even with NOSTARTUP my ports and RTCC and such get set by the SX/B generated code *before* my user entered code appears in the list file. Or, I guess come up with more elegant code that start off in zero state better? Is that right?

Quasi-related -- I've been playing with RAM banks and getting feel for working with indirect reading of registers. If the lower half of each ram bank is *always* the "global" vars ($0-$F), then in an SX/B program I am limited in my "true" global vars because of lot of the global ram bank is used by the param vars and such. 4 free global bytes by my count. I realize the upper half of bank 0 is quasi-global in SX/B because SX/B seems to always presume a "return" to bank 0, but again, since I don't really want to sacrifice the loveliness of SX/B I want to know what my constrictions are.

Last newbie question -- in the SX/B startup code there are "mirror" registers for the ports that get setup? Like TRIS_A maps to $FA (if I remember correctly). $FA -- where is that? Are those special registers in the SX or what?

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

Post Edited (Zoot) : 10/26/2007 11:37:14 AM GMT

JonnyMac

Since you didn't post your code (hint, hint), one must assume that you're using SX/B's rate feature for the ISR which takes care of setting the option register and return value properly for clock speed. If you leave out the rate feature then you must set the option register manually to get the ISR going; of course, you'll also have to append a value after RETURNINT -- but you can get both of those values out of your current program (look in the startup section) before removing the rate parameter.

If you look in the output listing (use Ctrl-L to view) you'll see that the shadow registers for the TRIS registers (on the SX28) are at $FA - $FC.

Bean

Yes if you don't want the interrupt happening at startup. You will have to calculate the rate manually and set the OPTION register and the RETURNINT value like Jon suggested.

The TRIS shadow locations are needed because on the SX28 you cannot read the TRIS hardware registers. They are write-only. So you cannot set or clear a single bit on them.
By storing the TRIS value in ram (nothing special about those addresses, just the last address in RAM) allows you to set or clear bits.

Bean.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My goal is to live forever...Or die trying.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
www.hittconsulting.com
·

Zoot

Thanks to both of you for the clarifications.

Yes, I'm using SX/B for calculating the ISR rate, initializing vars and ports, main program and functions; the ISR and some of the bulkier parts of the main program are ASM. I don't think there's a need to post the code -- it's all doing what I expect, I've just been trying to go through some of the generated assembly and see why certain things are happening. Getting at the guts, as it were. In my case, one part of the ISR checks the state of a detector while running some counters and such, and the detector doesn't quite settle on power-up before the ISR kicks in. On reset it's OK.

I started to do my own startup code in ASM to get the initialization order the way I wanted it and learn my M modes, but to be honest, I stopped (for now) because SX/B is just *so* dang convenient and error-free for that kind of work.

On the port map registers for SX28 -- sounds like these are software maintained pin bitmaps so that the program's own changes to the ports can be recorded (for use in subsequent bitmasks when writing to the pins). Super clever. I need to look at the generated list file more closely

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

Zoot

OK, I checked out the generated start/reset/powerup code in my program and I think I've found a trap? Or maybe something else?
See my comments in .src listing below. *IF* my reading is correct, the RTCC is set to run in the OPTION register BEFORE pullups are set.

Which would explain my results -- my IR detector was giving me noisy results (I'm sure you've read the many posts on this topic at all the forums). Part of my soution was using the internal pullup on the input pin (which cut down on false lows quite a bit). So on soft reset, it's not generally a problem because the pin is already set to pullup. But on powerup, it's not. Since my ISR checks the detector and sets some states for the main program, it caused unexpected behavior.
This code is untouched from what SX/B generated

                  
  ORG $+2  ; FOR DEBUGGER  RESET __PROGSTART                ;  PROGRAM Start 'NOSTARTUP
__PROGSTART:                    
  JNB TO,@__RESTORETRIS         
  JB PD,@__POWERUP              
  CLR W                         
  MODE $09                      
  MOV !RB,W                     
  MOV FSR,W                     
  MODE $0F                      
  CJE FSR,#0,@__POWERUP         
  CJNE FSR,#$FF,@__RESTORETRIS  
__POWERUP:                      
  CLR RA                        
  CLR RB                        
  CLR RC                        
  MOV FSR,#$08                  
  SB FSR.3                      
  SETB FSR.4                    
  CLR IND                       
  IJNZ FSR,@$-3                 
  MOV FSR,#__TRISA              
  MOV IND,#255                  
  INC FSR                       
  MOV IND,W                     
  INC FSR                       
  MOV IND,W                     
__RESTORETRIS:                  
  MOV FSR,#__TRISA    'jmp here if soft reset; by default mode = $F;
                      'so this would appear to map "shadowed" TRIS state to actual pin ports??? why?
                      'wouldn't this set pins that were last inputs to HIGH and outputs to LOW?
  MOV !RA,IND                   
  INC FSR                       
  MOV !RB,IND                   
  INC FSR                       
  MOV !RC,IND                   
  MOV !OPTION,#128     'RTCC rollover enabled before input/output states and pullups are done
  MODE $0F             '
  MOV FSR,#__TRISA     'setup FSR to save initial user pin dirs back to shadow registers after restore         
  MOV W,#247                    
  MOV !RA,W                     
  MOV IND,W                     
  MOV FSR,#__TRISC     'ditto         
  MOV W,#192                    
  MOV !RC,W                     
  MOV IND,W                     
  MODE $0E            'pullups setup and saved to ports
  MOV W,#248                    
  MOV !RA,W                     
  MOV W,#0                      
  MOV !RB,W                     
  MOV W,#63                     
  MOV !RC,W                     
  CLR FSR                       
  JMP @Start                    
  ORG $+2  ; FOR DEBUGGER  

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

Bean

The easist thing would be to just put an external pullup resistor on the pin.

Otherwise, don't use the rate parameter on the INTERRUPT line and set OPTION manually.

Bean.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My goal is to live forever...Or die trying.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
www.hittconsulting.com
·