Reading the Clock frequency / Peeksfr in simulator

[cpedw]

I want to find which speed the 14M2 is running in a program that uses M32, M16 and K31 at different stages; there's an interrupt with a serout so I need to be able to restore the right speed after serout, before return from interrupt.

It seems that the SFR called OSCCON at $99 ($19 in Bank 1). My reading of the manual suggests that PEEKSFR, $39, b0 should access OSCCON. But according to westaust's table it should be PEEKSFR, 143, b0.

In the simulator, both addresses return 0 for all setfreqs.

At last, the questions;
Which is the peeksfr address to use to read OSCCON in a 14M2?
Does the simulator work on SFRs?
Am I approaching the original problem, returning from an interrupt at the right clock speed, in the best way?

Thanks,
Derek

 

[PhilHornby]

I did some experimenting with this (back in 2015), from which I still have some code :-

#picaxe 14m2
#terminal 4800
#no_data
#no_end

#rem

OSCCON reqister address is 099h
To convert to Picaxe equivalent, we do the following:-

  0    9    9
0000 1001 1001
 |   |xx|   /
  \  / /   /
 0011 1001/
   3    9 

So, in Picaxe terms, address 099h becomes 39h

SetFreq     OSCCON (dec)      Terminal Baud     Toggle Frequency
  M1              88                1200              96Hz  
  none            104               4800              395Hz
  M4              104               4800              385Hz
Multi-task        120               4800              486-847Hz (depending on Task 1 load)
  M8              112               9600              772Hz
  M16             120               19200             1540Hz
  M32             240               38400             3086Hz
  
#endrem
;Start0:

setfreq M1 ; or whatever

peeksfr $39,b0
sertxd (cr,lf,"OSCCON=",#b0)
do 
      toggle C.0
loop

 

[cpedw]

Just for completeness, I ran a similar program to find OSCCON for all speeds of a 14M2:

m32  %11110000  240
m16  %01111000  120
m8   %01110000  112
m4   %01101000  104
m2   %01100000  96
m1   %01011000  88
k500 %00111000  56
k250 %00110000  48
k31  %00001000  8

 

[cpedw]

Further delving has shown that simulation doesn't do SFR at all.
This program

#picaxe 14M2
#no_data

symbol sfr = b0
symbol bank= b1
symbol addr= b2
symbol first=b4
symbol second=b5

FOR bank = 0 to 2
    FOR addr = $0C to $1F

        sfr = bank *32 + addr
        peeksfr sfr,b3
        
        IF b3>0 THEN
            first = sfr / 16 + "0"
            If first > "9" Then
              first = first + 7
            End If

            second = sfr & $0F + "0"
            If second > "9" Then
              second = second + 7
            End If
            
            sertxd("$",first,second," ", #b3,cr,lf)
        ENDIF
    Next addr
Next bank

end

produced no output at all. Note that it only prints if peeksfr returns non-zero.
Running the same program in real hardware produces several non-zero outputs.

Incidentally, I was surprised to find that bank>2 causes reset. The manual for peeksfr suggests that bank can be up to 7.

Derek

 

[Flenser]

Incidentally, I was surprised to find that bank>2 causes reset. The manual for peeksfr suggests that bank can be up to 7.

Derek, what_exactly_ was you peeksfr command that caused the reset?

From the peeksfr command in Manual 2 for the M2 chips you can peeksfr bank 2:
Bit 7-5 Memory Bank $00-$07

But, querying the locations $00-$0B in any bank are documented as causing a reset:
Bit4-0 Addresses $0C to $1F on this bank
($00-$0B are invalid and cause instant reset)

 

[cpedw]

Derek, what_exactly_ was you peeksfr command that caused the reset?

The location where reset occurs is Bank 3, address $13. I tried skipping that but bank 3, address $14 also causes reset. I haven't investigated higher.

 

[PhilHornby]

Returning to the original question, for a moment ...

there's an interrupt with a serout so I need to be able to restore the right speed after serout, before return from interrupt.

You may be able to use HSEROUT to avoid having to change frequency in the ISR.

 

[cpedw]

You may be able to use HSEROUT to avoid having to change frequency in the ISR.

I've never used hserout; I will look into that.

 

[Flenser]

I want to find which speed the 14M2 is running in a program that uses M32, M16 and K31 at different stages

cpedw, PhilHornby's suggestion should do what you want.
Provided that the hserout pin is available on your 14M2 then when you change the clock freq in your program all you need to do is also change the hserout config to match like this:
SETFREQ M4
HSERSETUP B9600_4 <the mode you chose for hserout is the same for every hsersetup>
...
SETFREQ M16
HSERSETUP B9600_16 <the mode you chose for hserout is the same for every hsersetup>

Then your hserout commands, which don't refer to the clock freq, will work based on your most resent HSERSETUP:
HSERIN var
...
HSEROUT break, ({#}data,{#}data...)

 

[AllyCat]

Hi

"Derek, what_exactly_ was you peeksfr command that caused the reset?"

The location where reset occurs is Bank 3, address $13. I tried skipping that but bank 3, address $14 also causes reset. I haven't investigated higher.

So presumably the exact command was PEEKSFR $73 , bn ? I haven't checked this myself but can see why it might be an issue. As you've discovered the PEEKSFR commands are not "simulated" because they are a "window" into the relevant PIC's Hardware that is not part of the PICaxe Basic software (Language):

Address $13 in bank 3 is NOT a (hardware) register but another window into a region of (EEPROM) Memory. This can only have any validity if the address (defined in $11 and $12) is set and/or known, so why do you need to read it? AFAIK this is not documented for any of the PICaxes and is quite unlikely to correspond with the non-volatile memory locations in PIcaxe Basic (e.g. EEPROM , TABLE or Program Memory), just as some PICaxe Port.pin definitions do not correspond with the Base PIC's pin numbers. Also, there seems to be a "grey area" over the separation between Program Memory and Non-Volatile Data Memory, so (if implemented) that register might give access to (and thus permit copying of) the PICaxe Basic Program code, which is the reason why the lower registers ($00 to $0C) are arranged to generate an immediate Reset.

Cheers, Alan.

 

[inglewoodpete]

I'm pretty sure that I read years ago that SFRs are not included in the simulator. The SFRs would be far to difficult and expensive to simulate in the PICAXE realm. The SFR commands are provided for access into the real chip's registers.

Personally, I rarely use use the simulator and then, only to debug an algorythm that I use later in the real PICAXE. After all, the real chip will have the real wiring with its own 'real world' connected to it.