Viewing Scratchpad Memory Values

Ianj

New Member
Hello

I'm trying to view the scratchpad memory values in the Picaxe editor software. I thought that I could see them in real time when a downloaded programme came across a debug command but the Memory/Scratchpad window doesn't update (all values stay at at 00). Does this window only update in simulation mode?

I'm trying to debug a programme using the hardware serial port in background mode. For some reason the HSERPTR doesn't reliably increment when data from an external serial port is sent to the Picaxe

Regards

Ianj
 

hippy

Technical Support
Staff member
The Scratchpad memory display is only updated during simulation, not during live debugging. The DEBUG command doesn't send the Scratchpad data, only data for the standard 'b', 'w' variables along with pin and other status.

The 'hSerPtr' should increment correctly when it is receiving data so it may be worth posting your program code.
 

Ianj

New Member
The Scratchpad memory display is only updated during simulation, not during live debugging. The DEBUG command doesn't send the Scratchpad data, only data for the standard 'b', 'w' variables along with pin and other status.

The 'hSerPtr' should increment correctly when it is receiving data so it may be worth posting your program code.
Hello Hippy

Thanks for the quick reply.

I've used RS232 over the years but this is the first time I've used hardware in a background mode. I've put a simplified version of the code I've been using below

For the TX routine I'm basically I send 16 bytes of data in two 8 byte blocks. In each block the first 4 bytes are known dummy data that I decode to confirm the received data is good and the last 4 bytes is the real data. I'm sending the data as an 8 byte block as eventually I'm sending the data via a pair of AXE213 boards with some RF modules.

I have increased the delay between each block of 8 bytes but there was no change.

For the RX routine I look to see if the HSERPTR is greater than 16, if it is I reset the pointer, check to see if the dummy data is correct, if it is I update the PTR and copy the data to local variables. Then update the pointer again and do the same check. At the end of the routine the HSERPTR is reset

This is a simplified version, in reality I'm sending five 8 byte blocks and I added a timeout reset and some other checks to the receive routine.

At this stage I'm using an AXE091 experimenter board with a 40X2 chip. If I do a loopback on the RX to TX pin it works perfectly. I can see the Rx_Counter value jump from 0 to 16 and back. This is good.

If I load the software on a second protoboard (AX022) and connect the AX022 TX pin to the RX pin on the AXE091 board (and connect the board earths) The AXE091 chip only receives 3-4 bytes each time the send routine happens, It should see a 16 byte block.

I know the TX data from the AXE022 is good as I sniff the data on a PC serial port using the external serial connection on the AXE091.

I only use the HSERPTR to determine the RX data. Is that bad practice?

I've had a look at the data with a CRO, levels and timing looks good so I'm a bit puzzled. I feel that it's a hardware rather than a software issue but I can't work out what.

Thanks for your help

IanJ




Code:
; setup hardware serial port

hsersetup B2400_8, %001        ' Serial port 2400 baud, 8MHz clock, RX/TX levels = false, Background RX = true

    hserinflag = 0
    
    hserptr = 0
    
    ptr = 0

    data_error = 0    


' Program Start

Start:

loop1:

        Do some things
        
        gosub Send_Temperature

        wait a second
        
       'gosub Receive_Temperature

       Do some more things
    
       goto Loop1


Send_Temperature:

    hserout 0, ($41,$41,$41,$41,RealData1,RealData2,RealData3,RealData4)
    
    pause 10
    
    hserout 0,  ($42,$42,$42,$42,RealData5,RealData6,RealData7,RealData8)
    
Return 


Receive_Temperature:

rx_counter = hserptr

debug

if hserptr >= 16 then     'If the serial pointer has received 16 bytes then reset the pointer and get the data
    
        ptr = 0

        if @ptr = $41 and @ptrinc = $41 and @ptrinc = $41 and @ptrinc = $41 then     'Check the first 4 bytes to see if rx data is good
            
            ptr = 4
            
            Data_Byte1     = @ptrinc
            
             Data_Byte2         = @ptrinc

             Data_Byte3        = @ptrinc

             Data_Byte4        = @ptrinc
    
        else       'If Rx data is no good set Data_Error flag
        
            Data_Error = 1
        
        end if   
            
        ptr = 8
            
        if @ptr = $42 and @ptrinc = $42 and @ptrinc = $42 and @ptrinc = $42 then     'Check the first 4 bytes to see if rx data is good
            
            ptr = 12
            
            Data_Byte5     = @ptrinc
            
             Data_Byte6         = @ptrinc

             Data_Byte7        = @ptrinc

             Data_Byte8        = @ptrinc
            
                
        else
        
            data_Error = 1
        
        end if
    
    else if hserptr < 16 then
        
        rx_temp_error = 0
        
        rx_counter = hserptr
    
        'debug
;        
    else if hserptr > 40 then
        
        rx_Temp_Error = 1
    
end if

    if data_error = 1 then        
        
        hserinflag = 0
    
        hserptr = $0
    
        ptr = $0
        
        Data_error = 0
        
    end if
    
Return
 

hippy

Technical Support
Staff member
The first thing I would say is sending two blocks of 8 bytes with a 10 millisecond gap between them is too fast for RF hardware to keep up with, but that should not be too problematic with a wired system.

As to why it's not receiving a full set of data I am not sure. It would be worthwhile starting with something simpler which just grabs data and display it, see if you can spot the "$41,$41,$41,$41,x,x,x,x,$42,$42,$42,$42,y,y,y,y" data in that -
Code:
#terminal 9600
hsersetup B2400_8, %001
pause 2000
do
  do : loop while ptr = hserPtr
  b0 = @ptrinc
  b1 = b0 / $10 + "0" : if b1 > "9" then : b1 = b1+7 : end if
  b2 = b0 & $0F + "0" : if b2 > "9" then : b2 = b2+7 : end if
  sertxd( "$" )
  sertxd( b1  )
  sertxd( b2  )
  sertxd( " " )
loop
 

Ianj

New Member
The first thing I would say is sending two blocks of 8 bytes with a 10 millisecond gap between them is too fast for RF hardware to keep up with, but that should not be too problematic with a wired system.

As to why it's not receiving a full set of data I am not sure. It would be worthwhile starting with something simpler which just grabs data and display it, see if you can spot the "$41,$41,$41,$41,x,x,x,x,$42,$42,$42,$42,y,y,y,y" data in that -
Code:
#terminal 9600
hsersetup B2400_8, %001
pause 2000
do
  do : loop while ptr = hserPtr
  b0 = @ptrinc
  b1 = b0 / $10 + "0" : if b1 > "9" then : b1 = b1+7 : end if
  b2 = b0 & $0F + "0" : if b2 > "9" then : b2 = b2+7 : end if
  sertxd( "$" )
  sertxd( b1  )
  sertxd( b2  )
  sertxd( " " )
loop
Thanks for the reply

Yeah I'm relying on the buffer associated with hardware serial port to handle the data, I did add a much larger delay between HSEROUT as a test but it didn't make any difference.

I was planning on doing a very simple serial routine similar to what you've outlined so I'll give that a go

What does puzzle me is why the routine works perfectly when the TX and RX pins are connected together on a single chip. In the real version of the software I was sending out 40 bytes with no built delay between the HSEROUT commands. The timing issues would be the same but it works correctly.

The RF part will be another can of worms. In preliminary testing I can't reliably send data across the link but I can turn off the lounge room ceiling light. I always wondered how that remote control worked, now I know. :)

Thanks for your help

IanJ
 

Ianj

New Member
Greetings Hippy

Thanks for the reply

Yeah I'm relying on the buffer associated with hardware serial port to handle the data, I did add a much larger delay between HSEROUT as a test but it didn't make any difference.

I was planning on doing a very simple serial routine similar to what you've outlined so I'll give that a go

What does puzzle me is why the routine works perfectly when the TX and RX pins are connected together on a single chip. In the real version of the software I was sending out 40 bytes with no built delay between the HSEROUT commands. The timing issues would be the same but it works correctly.

The RF part will be another can of worms. In preliminary testing I can't reliably send data across the link but I can turn off the lounge room ceiling light. I always wondered how that remote control worked, now I know. :)

Thanks for your help

IanJ
Greetings Hippy

I ran a series of tests with the Transmit Picaxe running a very simple routine that used the HSEROUT command sending one or more bytes of data followed by a delay and then repeating.

The Receive Picaxe code was setup to use background receive mode and all its code did was to look for changes in the value in the HSERPTR and copy the data to memory so I could look at the received data values using the debug command.

Initially the results were very disappointing I could only reliably receive a single byte of data at a time when they were separated by a minimum 100mS delay or a two byte data burst with a minimum 180mS delay between data bursts. A data burst of three or more bytes was not reliably received in any circumstance.

It finally dawned on me that problem was the position of the debug command in both the test code and my original code. It was included in a loop that was checking the value of the HSERPTR. Continuously updating the Picaxe editor would cause the hardware serial port to incorrectly report the number of received bytes to the HSERPTR.

When I moved the debug outside the loop I could reliably receive a 40 byte burst of data from the Transmit Picaxe.

I now understand why my original single board Tx to Rx loopback worked but not when I used the same code across two boards.

Now to work on the RF link part of the project......
 

lbenson

Senior Member
problem was the position of the debug command
Yes, DEBUG is notorious for introducing delays which interfere with programs which work fine without DEBUG. SERTXD also (but to a lessor degree in many cases) adds these complications. As you learned, if you doing something timing-dependent, allow it to complete before attempting to display the results.

Good debugging to have figured that out.
 
Top