Listing order for bit, byte, and word variables in code

FIREMANJIM

New Member
My question is after you name the pins on the picaxe chip does it matter what order you list the variables? can you list the word variables before the bit and byte variables? I generally list all my bits then my bytes and then my word variables. A friend sent me the code below and I seen where his variables are all mixed up....Does this matter? Thanks for your help.



Code:
#rem
Picaxe 14m2
Dip 3 is for Trail or Feeder modes. Switch 1 ON is Feeder mode - OFF is Trail mode
Dips 1 and 2 are used to select the delay in feered mode
 
Dip 1 off and Dip 2 off selects 30 second delay
Dip 1 off and Dip 2 on selects 1 minute delay
Dip 1 on and Dip 2 off selects 3 minute delay
Dip 1 on and Dip 2 on selects 6 minute delay
 
 
#endrem
 
symbol CdsIn = b.3
symbol CdsPwr = b.2
symbol LED = b.4
symbol Shutter = c.1
symbol CamPwr = c.0
symbol Opto2Port1 = b.5       ' opto 2 terminal 1
symbol Opto2Port2 = b.0       ' opto 2 terminal 2
symbol PirIn = pinc.2
symbol DIP1 = pinc.4         ' Dip Switch 1 input
symbol DIP2 = pinc.3          ' Dip Switch 2 input
symbol DIP3 = pinb.1          ' Dip Switch 3 input
 
symbol DayStatus = bit0
symbol Type4 = bit1
symbol CDSTimer = w12
symbol LightLevel = b4
symbol DaySetting = b5
symbol NightSetting = b6
symbol Counter = b7
symbol FeederDelay = b8
symbol FeederMode = bit5
symbol CameraOn = bit2
symbol CameraRefreshTimer = w9
symbol CameraRefreshTime = w10
symbol ShutterDelay = w11
 
disablebod

' outputs as low
low LED
low CamPwr
low Shutter
Low CdsPwr
low Opto2Port1
low Opto2Port2
' set input pins as inputs
Input b.1
Input b.3
Input c.2
Input c.3
Input c.4
 
' set default variable settings
CameraOn = 0
DayStatus = 1
DaySetting = 60
NightSetting = 50
Type4 = 0
ShutterDelay = 2000
w13 = 0
nap 5 ' To let power settle if needed before checking dip switch settings
 
' check if Feeder Mode dip switch is on
if DIP3 = 0 then
                FeederMode = 1                              ' run in feeder mode
else
                FeederMode = 0                              ' run in trail mode
endif
 
 
' Setup camera timing for the rest of the operation of the camera
' Dip switches are Low when ON.  When OFF they are High
 
' DIP 1 and DIP 2 is OFF so 30 second feeder delay
if DIP1 = 1 and DIP2 = 1 Then
     FeederDelay = 14
 
' DIP1 1 Off and DIP 2 is ON so 1 minute delay
elseif DIP1 = 1 and DIP2 = 0 Then
      FeederDelay = 28
 
' DIP 1 ON and DIP 2 OFF so feeder delay is 3 minutes
elseif DIP1 = 0 and DIP2 = 1 Then
      FeederDelay = 79
 
' DIP 1 is ON and DIP 2 is ON so a 6 Minute feeder delay
elseif DIP1 = 0 and DIP2 = 0 Then
      FeederDelay = 157
endif

'turn on camera to test and charge flash cap
  High LED
  Pause 1000
  high CamPwr
  pause 500
  low CamPwr
  sleep 5
  high CamPwr
  pause 500
  low CamPwr
  Pause 1000
  Low LED
  sleep 1
  CameraRefreshTimer = 0
  pause 1000
 
WalkTest:
nap 2 ' nap for 72ms .072 seconds
if PirIn = 1 then
      high LED
        nap 6 ' pause low power for 1.1 seconds
     low LED
        nap 8 ' pause low power for 4 seconds
      w13 = 0
endif
if w13 >= 416 then  ' approx 30 seconds
        let b9 = 10
      for Counter = 1 to b9
    high LED
    pause 200
    low LED
    pause 200
    next Counter
        pause 1000
      goto CDSCheck
endif
w13 = w13 +  1 ' increment loop counter             
goto WalkTest

          
CDSCheck:
    high    CdsPwr        ' apply power to CDS sensor
    nap 5    ' allow power to settle
    readadc    CdsIn, LightLevel
    low CdsPwr
    if LightLevel >= DaySetting then
        DayStatus = 1
        CameraRefreshTimer = 0
        CDSTimer = 0
    elseif  LightLevel < NightSetting then
        DayStatus = 0
        CameraRefreshTimer = 0
        CDSTimer = 0
  
    endif
                            
 
main:

'daytime run code

if Daystatus = 1 then
    if PirIn = 1 then
          if FeederMode = 1 then
                if CameraOn = 0 then     ' if camera is off turn it on
                high CamPwr
                  pause 500
                low CamPwr
                 CameraOn = 1
                pause ShutterDelay
                endif
            high Shutter  ' Press Shutter Button to take picture
               pause 3000
            low Shutter
               sleep 5
            high CamPwr    ' turn camera off in feeder mode
              pause 500
            low CamPwr
              CameraOn = 0
                w5 = 0
             sleep FeederDelay
          endif
                                
                
        if FeederMode = 0 then
               if CameraOn = 0 then ' if camera is off turn it on
                high CamPwr
                   pause 500
                low CamPwr
                   CameraOn = 1
                   pause ShutterDelay
                endif
            high Shutter ' Press Shutter Button to take picture
               pause 3000
            low Shutter
               pause 1000
                 w5 = 0                                                 
          endif
        CameraRefreshTimer = 0 ' reset camera refresh counter/timer
      endif
                
if CameraOn = 1 then
        w5 = w5 + 1 ' increment temporary counter for camera on time with no pir activity
     if w5 >= 200 then ' camera timer set to about 20 seconds no activity
          high CamPwr ' turn camera off
           pause 500
          low CamPwr
          CameraOn = 0
             w5 = 0
            sleep 2
      endif
endif
                
CameraRefreshTimer = CameraRefreshTimer + 1
       if CameraRefreshTimer >= CameraRefreshTime then
         high CamPwr
           pause 500
         low CamPwr
             sleep 5
         high CamPwr
           pause 500
         low CamPwr
           sleep 1
             CameraRefreshTimer = 0
            pause 1000
          endif
                
              
CDSTimer = CDSTimer + 1
     If CDSTimer >= 2084 then ' check time every 2 1/2 minutes
            high  CdsPwr     ' apply power to CDS sensor
             nap 5     ' allow power to settle
          readadc  CdsIn, LightLevel
             low CdsPwr
          if LightLevel < NightSetting then
              DayStatus = 0
             else DayStatus = 1
             CameraRefreshTimer = 0
            CDSTimer = 0
          if CameraOn = 1 then
                 high CamPwr
               pause 500
                 low CamPwr
              CameraOn = 0
            endif
             nap 2
           goto main
             endif
      CDSTimer = 0     
      endif
endif
        
'nighttime run code

if Daystatus = 0 then
    if PirIn = 1 then
          if FeederMode = 1 then
                if CameraOn = 0 then     ' if camera is off turn it on
                high CamPwr
                  pause 500
                low CamPwr
                 CameraOn = 1
                pause ShutterDelay
                endif
            high Shutter  ' Press Shutter Button to take picture
               pause 3000
            low Shutter
               sleep 5
            high CamPwr    ' turn camera off in feeder mode
              pause 500
            low CamPwr
              CameraOn = 0
                w5 = 0
             sleep FeederDelay
          endif
                                
                
        if FeederMode = 0 then
               if CameraOn = 0 then ' if camera is off turn it on
                high CamPwr
                   pause 500
                low CamPwr
                   CameraOn = 1
                   pause ShutterDelay
                endif
            high Shutter ' Press Shutter Button to take picture
               pause 3000
            low Shutter
               sleep 5
                 w5 = 0                                                 
          endif
        CameraRefreshTimer = 0 ' reset camera refresh counter/timer
      endif
                
if CameraOn = 1 then
        w5 = w5 + 1 ' increment temporary counter for camera on time with no pir activity
     if w5 >= 200 then ' camera timer set to about 20 seconds no activity
          high CamPwr ' turn camera off
           pause 500
          low CamPwr
          CameraOn = 0
             w5 = 0
            sleep 2
      endif
endif
                
CameraRefreshTimer = CameraRefreshTimer + 1
       if CameraRefreshTimer >= CameraRefreshTime then
         high CamPwr
           pause 500
         low CamPwr
             sleep 5
         high CamPwr
           pause 500
        low CamPwr
           sleep 1
             CameraRefreshTimer = 0
            pause 1000
      endif
                
              
CDSTimer = CDSTimer + 1
 If CDSTimer >= 2084 then ' check time every 2 1/2 minutes
        high  CdsPwr    ' apply power to CDS sensor
         nap 5     ' allow power to settle
      readadc  CdsIn, LightLevel
         low CdsPwr
      if LightLevel < NightSetting then
          DayStatus = 0
          else DayStatus = 1
          CameraRefreshTimer = 0
          CDSTimer = 0
          if CameraOn = 1 then
                 high CamPwr
               pause 500
                 low CamPwr
              CameraOn = 0
          endif
          nap 2
          goto main
    endif
      CDSTimer = 0     
endif
endif       
                

nap 2     
goto main
 

lbenson

Senior Member
It doesn't matter as far as program execution goes, but the practice you describe of bits, then bytes, then words in numeric order is the one I try to follow--otherwise it becomes easy to accidentally redefine a register/variable, which can lead to all kinds of fun in debugging.
 

hippy

Technical Support
Staff member
As said; it doesn't really matter other than in ease of reading the code when one hasn't written it, trying to debug things or ensure that one doesn't accidentally use a variable which has already been used.

I tend to define word variables first then byte variables, with bit variables placed amongst them or separately depending on what feels right. My version for the above would have been -
Code:
Symbol reserveW0          = w0    ; b1:b0

symbol DayStatus          = bit0
symbol Type4              = bit1
symbol CameraOn           = bit2
symbol FeederMode         = bit3

symbol CameraRefreshTimer = w1    ; b3:b2
symbol CameraRefreshTime  = w2    ; b5:b4
symbol ShutterDelay       = w3    ; b7:b6
symbol CDSTimer           = w4    ; b9:b8

symbol LightLevel         = b10
symbol DaySetting         = b11
symbol NightSetting       = b12
symbol Counter            = b13
symbol FeederDelay        = b14
Ordering pin definitions is a bit more awkward. I would accept what there is as grouping functionality makes sense even if the physical connections are all over the place.

I would add an additional diagram above the list just to make it clearer, and also show which are inputs and which are outputs -
Code:
;              PICAXE-14M2
;             .-----_-----.
;            -| +V     0V |-
;            -| C.5   B.0 |--> Opto2Port2
;     DIP1 -->| C.4   B.1 |<-- DIP3
;     DIP2 -->| C.3   B.2 |--> CdsPwr
;    PirIn -->| C.2   B.3 |<-- CdsIn 
;  Shutter <--| C.1   B.4 |--> LED
;   CamPwr <--| C.0   B.5 |--> Opto2Port1
;             `-----------'
That comes in real handy when wiring things up or wanting to measure an input or output pin, saves having to figure out where they are every time.

One thing which is probably more important than SYMBOL ordering, is always using SYMBOL names in the source code, not "Input b.1", "w5 = 0", "w13 = 0" etc, as is done in the code you have.

That makes it difficult to change the allocations as I did in the first example, because, after a change, what's 'w5' is no longer the same. That will end up corrupting things.

It also makes it hard to know what 'w5' or 'w13' is without having to refer back to the SYMBOL list.
 

Hemi345

Senior Member
Another suggestion is to name your symbols leading with a letter to indicate what type it is and use camel case. For example:
Code:
'pins
symbol pHSI = b.1

'bits
symbol bAlertLed = bit2
symbol bButton1 = pinC.1

'bytes
symbol vAlertStatus = b3

'words
symbol wHumidity = w8
"v" is probably less intuitive for others reading my code, but I thought of using v because of "v"ariable and most of my code uses byte variables. Anyway, at a glance, I know what the symbol specified is capable of storing or doing and can help prevent bugs in my code or quickly identify what's wrong when they do happen :)
 

inglewoodpete

Senior Member
I do something along the lines of Hemi345, using prefixes on variable and pin names.

When it comes to ordering the variables, I avoid double-allocation by listing variables from w0 to wmax with bits and bytes meshed into the sequence.

Taken from a recent PICAXE Project:
Rich (BB code):
'
' **** Variables - t prefix: bit variable; b: byte; w: word; r: other RAM; s: scratchpad; e: EEPROM
'
'ymbol bLEDStatus    = b0     'w0
Symbol tFlashGrn     = bit0   'b0,w0 v0.18   'Flag to flash Green LED
Symbol tGFlashState  = bit1   'b0,w0 v0.18   'Current Green LED State (if flashing)
Symbol tFlashYlw     = bit2   'b0,w0 v0.14   'Flag to flash Yellow LED
Symbol tYFlashState  = bit3   'b0,w0 v0.14   'Current Yellow LED State (if flashing)
Symbol tFlashRed     = bit4   'b0,w0 v0.14   'Flag to flash Red LED
Symbol tRFlashState  = bit5   'b0,w0 v0.14   'Current Red LED State (if flashing)
Symbol tFlashBlue    = bit6   'b0,w0 v0.15   'Flag to flash Blue LED
Symbol tBFlashState  = bit7   'b0,w0 v0.15   'Current Blue LED State (if flashing)
'
'ymbol bCommsStatus  = b1     'w0
Symbol tStCommsGood  = bit8   'b1,w0 v0.14   'Wireless comms status
Symbol tStLocked     = bit9   'b1,w0 v0.14   'All Doors are locked
Symbol tStPrevLocked = bit10  'b1,w0 v0.16   'Previous state of all locks bit
Symbol tStDoorsOpen  = bit11  'b1,w0 v0.14   'One or more vehicle doors are open
Symbol tStPrevDoorsOpen = bit12 'b1,w0 v0.18 'Previous state of all doors bit
Symbol tSendResp     = bit13  'b1,w0
Symbol tMismatch     = bit14  'b1,w0 v0.10
Symbol tNoCommsYet   = bit15  'b1,w0 v0.17   'Set to True at bootup until first comms received
'
'ymbol bCarStatus    = b2     'w1
Symbol tStAcc        = bit16  'b2,w1 v0.14   'Vehicle Accessories Power Status
Symbol tStIgn        = bit17  'b2,w1 v0.14   'Vehicle Ignition Status
Symbol tStPrevIgn    = bit18  'b2,w1 v0.16   'Previous Vehicle Ignition Status
Symbol tStSelfPower  = bit19  'b2,w1 v0.14   'Slave self-power bit status
Symbol tStOBDInit    = bit20  'b2,w1 v0.14   'OBD interface in vehicle has been initialised
Symbol tStOBDValid   = bit21  'b2,w1 v0.14   'OBD data from vehicle is valid
Symbol tStShutDnPend = bit22  'b2,w1 v0.14   'Shut down of Slave unit is pending
Symbol tRedFastFlash = bit23  'b2,w1 v0.20   'Car unlocked, comms established but no OBD data yet
'
'ymbol <sparebyte>   = b3     'w1
'ymbol <sparebits>   = bit24 to bit31 'b3, w1
'
Symbol bLoopCtr      = b4     'w2   v0.9
Symbol bData         = b5     'w2   v0.9
Symbol bSearchPtr    = b6     'w3   v0.9 
Symbol bPtrMem       = b6     'w3   v0.10
Symbol bStringPtr    = b7     'w3   v0.10
Symbol bEEPROMPtr    = b8     'w4   v0.16
Symbol bSoundPtr     = b9     'w4   v0.16
Symbol bPWMPeriod    = b10    'w5   v0.16
Symbol bSoundSeq     = b11    'w5   v0.16
'
'Symbol wTemp         = w8     'b16/17
Symbol bTempStsByt   = b16    'w8
Symbol bTemp         = b17    'w8
'Symbol wSendPktCount = w9     'b18/19
Symbol wSendCount    = w10    'b20/21
Symbol wSendCount.Lo = b20    'b20/21
Symbol wPWMDuty      = w11    'b22/23 v0.16
Symbol wPWMDuty.Lo   = b22    'w11    v0.16
Symbol wPWMDuty.Hi   = b23    'w11    v0.16
'Symbol wFailCount    = w12    'b24/25 Counter of seconds - a byte would only allow 4.25 minutes
Symbol bLoop1        = b26    'w13
Symbol bLoop2        = b27    'w13
Symbol bRecvCount    = b28    'w14  v0.4
Symbol bLogPtr       = b29    'w14  v0.4
Symbol bRetryCount   = b30    'w15  v0.5
Symbol bCalcCSum     = b31    'w15  v0.7

...and so on
 

FIREMANJIM

New Member
Thanks for the help Hippy. I appreciate it. So where I use w5 for the "Trailmode Timer" and w13 for the "Walktest Timer" you are saying I should name them as well instead of just using w5 and w13? Also do I need to use the w1, w2, w3, for my larger timers that use larger #s or is it ok to use the w's lower on the list? Sorry for the stupid questions...I am just learning. Just don't want the chip constantly resetting.
As said; it doesn't really matter other than in ease of reading the code when one hasn't written it, trying to debug things or ensure that one doesn't accidentally use a variable which has already been used.

I tend to define word variables first then byte variables, with bit variables placed amongst them or separately depending on what feels right. My version for the above would have been -
Code:
Symbol reserveW0          = w0    ; b1:b0

symbol DayStatus          = bit0
symbol Type4              = bit1
symbol CameraOn           = bit2
symbol FeederMode         = bit3

symbol CameraRefreshTimer = w1    ; b3:b2
symbol CameraRefreshTime  = w2    ; b5:b4
symbol ShutterDelay       = w3    ; b7:b6
symbol CDSTimer           = w4    ; b9:b8

symbol LightLevel         = b10
symbol DaySetting         = b11
symbol NightSetting       = b12
symbol Counter            = b13
symbol FeederDelay        = b14
Ordering pin definitions is a bit more awkward. I would accept what there is as grouping functionality makes sense even if the physical connections are all over the place.

I would add an additional diagram above the list just to make it clearer, and also show which are inputs and which are outputs -
Code:
;              PICAXE-14M2
;             .-----_-----.
;            -| +V     0V |-
;            -| C.5   B.0 |--> Opto2Port2
;     DIP1 -->| C.4   B.1 |<-- DIP3
;     DIP2 -->| C.3   B.2 |--> CdsPwr
;    PirIn -->| C.2   B.3 |<-- CdsIn
;  Shutter <--| C.1   B.4 |--> LED
;   CamPwr <--| C.0   B.5 |--> Opto2Port1
;             `-----------'
That comes in real handy when wiring things up or wanting to measure an input or output pin, saves having to figure out where they are every time.

One thing which is probably more important than SYMBOL ordering, is always using SYMBOL names in the source code, not "Input b.1", "w5 = 0", "w13 = 0" etc, as is done in the code you have.

That makes it difficult to change the allocations as I did in the first example, because, after a change, what's 'w5' is no longer the same. That will end up corrupting things.

It also makes it hard to know what 'w5' or 'w13' is without having to refer back to the SYMBOL list.
r
 

westaust55

Moderator
It is recommended to use the SYMBOL statements to give meaningful names to you variables.
Then use those names within your program.
Then if you change “Trailmodetimer” to use W8 instead of W5 all instances are effectively changed at the same time by the Programming Editor (PE).
If you use the raw variable names such as W5 then
(A) remembering later what W5 does may become difficult
(B) if you change that to say W8 you need to go through your program and edit every instance - forget/miss one instance and you will have the problem of working out why your program is not performing or giving the expected results.
 

Hemi345

Senior Member
Also do I need to use the w1, w2, w3, for my larger timers that use larger #s or is it ok to use the w's lower on the list?
I'm not sure what you're asking, but this may answer your question. Use w/word variables for anything that might have a value over 255. It doesn't matter if you use w1 or w10, they do the same thing.

When I need word symbols, I now specifically start at the highest and work backwards (e.g., w13 on a PICAXE 14M2). The reason behind this is that only the first 32 bits (b0 thru b3) can be given symbol names, so I don't think it's wise to use up those memory spaces for word or byte symbols if you need/want to easily reference those bits. For example, I'll usually reserve at least the first two bytes (b0 and b1) for bit use (shown in yellow). You can see that w2(b4 and b5) cannot be referenced at the bit level using symbol names (red arrow). If you double allocate a variable/variable clash, PE will alert you -- click the red ! (shown by blue arrow) to show the variable clashes:
PEsymbols.png

Things like solenoid state (on/off), day and night cycle (day/night), dampner position (open/closed), work great using just a bit (0/1) and save precious program space. I should have included constants in my post above. I name those symbols starting with a "c". Using constants makes the program very readable. For example, if you are using the pullup resistor on a button and pressing the button results in a low signal, using a constant helps :

Code:
'BITS --------------------------------------------------
symbol bBtn1 = pinC.1
symbol bDampnerPos = bit0

'CONSTANTS -----------------------------------------
symbol cPressed = 0 'button signal is low when pressed
symbol cOpen = 1
symbol cClosed = 0

if bBtn1 = cPressed then
'...
end if

if bDampnerPos = cOpen then
'...
end if
 
Last edited:

WhiteSpace

Well-known member
Some very useful practical suggestions - thanks. I also found the other day that having used SYMBOL names for all the pins made it much easier to move a project from a 20M2 to a 28X2. It was then just a question of re-allocating the SYMBOL to the correct pin (checking that it had the same functionality as on the 20M2), rather than having to go through the entire code and re-allocate the pins and check that I hadn’t missed any.
 

hippy

Technical Support
Staff member
It was then just a question of re-allocating the SYMBOL to the correct pin
"#IfDef _20X2" and the like are useful for creating multiple SYMBOL tables which are specific to the PICAXE the code is running on.

The code extract below ensures the program can only be compiled for an M2 and then assigns SYMBOL references to indicate the pins used by the hardware I2C bus so bit-banging can be done on the same pins ...
Code:
#IfDef _08M2
  #Define IS_M2
#EndIf
#IfDef _14M2
  #Define IS_M2
#EndIf
#IfDef _18M2
  #Define IS_M2
#EndIf
#IfDef _20M2
  #Define IS_M2
#EndIf

#IfNDef IS_M2
  #Error "This code is only intended for an M2 PICAXE"
#EndIf

#IfDef _08M2
  Symbol SCL = C.1 : Symbol SDA = C.2 : Symbol SDA_PIN = pinC.2
#EndIf
#IfDef _14M2
  Symbol SCL = B.3 : Symbol SDA = B.4 : Symbol SDA_PIN = pinB.4
#EndIf
#IfDef _18M2
  Symbol SCL = B.4 : Symbol SDA = B.1 : Symbol SDA_PIN = pinB.1
#EndIf
#IfDef _20M2
  Symbol SCL = B.7 : Symbol SDA = B.5 : Symbol SDA_PIN = pinB.5
#EndIf
With a bit of care, a single program can be crafted which will compile and work on any PICAXE.
 

FIREMANJIM

New Member
I'm not sure what you're asking, but this may answer your question. Use w/word variables for anything that might have a value over 255. It doesn't matter if you use w1 or w10, they do the same thing.

When I need word symbols, I now specifically start at the highest and work backwards (e.g., w13 on a PICAXE 14M2). The reason behind this is that only the first 32 bits (b0 thru b3) can be given symbol names, so I don't think it's wise to use up those memory spaces for word or byte symbols if you need/want to easily reference those bits. For example, I'll usually reserve at least the first two bytes (b0 and b1) for bit use (shown in yellow). You can see that w2(b4 and b5) cannot be referenced at the bit level using symbol names (red arrow). If you double allocate a variable/variable clash, PE will alert you -- click the red ! (shown by blue arrow) to show the variable clashes:
View attachment 23560

Things like solenoid state (on/off), day and night cycle (day/night), dampner position (open/closed), work great using just a bit (0/1) and save precious program space. I should have included constants in my post above. I name those symbols starting with a "c". Using constants makes the program very readable. For example, if you are using the pullup resistor on a button and pressing the button results in a low signal, using a constant helps :

Code:
'BITS --------------------------------------------------
symbol bBtn1 = pinC.1
symbol bDampnerPos = bit0

'CONSTANTS -----------------------------------------
symbol cPressed = 0 'button signal is low when pressed
symbol cOpen = 1
symbol cClosed = 0

if bBtn1 = cPressed then
'...
end if

if bDampnerPos = cOpen then
'...
end if
Thanks A Million....Had no idea about the "Red Dot" and what it does. Definitely learned something here.
 

Hemi345

Senior Member
Will the program "Compile SUcessfully" if there are variable clashes?
Yes. Some variable clashes are okay though if you're cognizant of how they clash. Like in my example above, the proximity counts 'wProxCounts' variable is returned from the sensor as two bytes. So I defined the vProxMsb (most significant byte) and vProxLsb (least significant byte) that make up wProxCounts.
 
Top