Help with PASM synchronization
David Betz
Posts: 14,530
I'm sure I've made an obvious blunder here but I can't see what it is. I have written a PASM CRC routine that I intend to use in a communications object and I wanted to verify that it was producing the same results as my working Spin code. I wrote the following test program to verify this. The program works but gets stuck at the line after the cognew call waiting for the PASM code to complete. I guess I must have he PAR handling wrong but I've stared at it for a while and can't see what I'm doing wrong. The idea is that param_ptr gets set to the address of the test data but that the PASM code sets it to zero when it has finished computing the CRC. The main Spin code waits for that parameter to become zero before printing the result. The problem is that I never exit the "repeat while" loop suggesting that the PASM code never finishes or it fails to set param_ptr to zero. Can anyone spot my blunder?
Thanks!
David
Thanks!
David
CON
_clkmode = xtal1 + pll16x
_xinfreq = 5_000_000
conRxPin = 31 '' the RX pin to use for UART console
conTxPin = 30 '' the TX pin to use for UART console
conMode = 0 '' the mode to use for FullDuplex UART console
conBaud = 115200 '' the baud rate to use for UART console
CR = $0d
OBJ
ser : "FullDuplexSerialExtended"
PUB main | param_ptr, param_cnt, param_crc, spin_crc, i
ser.start(conRxPin, conTxPin, conMode, conBaud)
spin_crc := 0
repeat i from 0 to 15
spin_crc := updcrc_spin(spin_crc, byte[@test_data][i])
ser.str(string("Spin value: "))
ser.hex(spin_crc, 8)
ser.tx(CR)
param_ptr := @test_data
param_cnt := 16
cognew(@crc_test, @param_ptr)
repeat while param_ptr <> 0
ser.str(string("PASM value: "))
ser.hex(param_crc, 8)
ser.tx(CR)
repeat
PRI updcrc_spin(crc_spin, data)
return (word[@crctab][(crc_spin >> 8) & $ff] ^ (crc_spin << 8) ^ data) & $ffff
DAT
test_data byte $01, $12, $23, $34, $45, $56, $67, $78
byte $89, $9a, $ab, $bc, $cd, $de, $ef, $f0
org 0
crc_test mov tmp, par
rdlong ptr, tmp
add tmp, #4
rdlong count, tmp
mov crc, #0
:loop rdbyte rxdata, ptr
call #updcrc
add ptr, #1
djnz count, #:loop
mov tmp, par
add tmp, #8
wrlong crc, tmp
mov tmp, par
wrlong zero, tmp
cogid tmp
cogstop tmp
ptr res 1
count res 1
tmp res 1
zero long 0
updcrc mov t1, crc
test t1,#$100 wz
shr t1, #9
add t1, #crctab
movs :load, t1
shl crc, #8
:load mov t1, 0-0
if_nz shr t1, #16
xor crc, t1
xor crc, rxdata
and crc, word_mask
updcrc_ret ret
crc res 1
rxdata res 1
t1 res 1
word_mask long $ffff
crctab
word $0000, $1021, $2042, $3063, $4084, $50a5, $60c6, $70e7
word $8108, $9129, $a14a, $b16b, $c18c, $d1ad, $e1ce, $f1ef
word $1231, $0210, $3273, $2252, $52b5, $4294, $72f7, $62d6
word $9339, $8318, $b37b, $a35a, $d3bd, $c39c, $f3ff, $e3de
word $2462, $3443, $0420, $1401, $64e6, $74c7, $44a4, $5485
word $a56a, $b54b, $8528, $9509, $e5ee, $f5cf, $c5ac, $d58d
word $3653, $2672, $1611, $0630, $76d7, $66f6, $5695, $46b4
word $b75b, $a77a, $9719, $8738, $f7df, $e7fe, $d79d, $c7bc
word $48c4, $58e5, $6886, $78a7, $0840, $1861, $2802, $3823
word $c9cc, $d9ed, $e98e, $f9af, $8948, $9969, $a90a, $b92b
word $5af5, $4ad4, $7ab7, $6a96, $1a71, $0a50, $3a33, $2a12
word $dbfd, $cbdc, $fbbf, $eb9e, $9b79, $8b58, $bb3b, $ab1a
word $6ca6, $7c87, $4ce4, $5cc5, $2c22, $3c03, $0c60, $1c41
word $edae, $fd8f, $cdec, $ddcd, $ad2a, $bd0b, $8d68, $9d49
word $7e97, $6eb6, $5ed5, $4ef4, $3e13, $2e32, $1e51, $0e70
word $ff9f, $efbe, $dfdd, $cffc, $bf1b, $af3a, $9f59, $8f78
word $9188, $81a9, $b1ca, $a1eb, $d10c, $c12d, $f14e, $e16f
word $1080, $00a1, $30c2, $20e3, $5004, $4025, $7046, $6067
word $83b9, $9398, $a3fb, $b3da, $c33d, $d31c, $e37f, $f35e
word $02b1, $1290, $22f3, $32d2, $4235, $5214, $6277, $7256
word $b5ea, $a5cb, $95a8, $8589, $f56e, $e54f, $d52c, $c50d
word $34e2, $24c3, $14a0, $0481, $7466, $6447, $5424, $4405
word $a7db, $b7fa, $8799, $97b8, $e75f, $f77e, $c71d, $d73c
word $26d3, $36f2, $0691, $16b0, $6657, $7676, $4615, $5634
word $d94c, $c96d, $f90e, $e92f, $99c8, $89e9, $b98a, $a9ab
word $5844, $4865, $7806, $6827, $18c0, $08e1, $3882, $28a3
word $cb7d, $db5c, $eb3f, $fb1e, $8bf9, $9bd8, $abbb, $bb9a
word $4a75, $5a54, $6a37, $7a16, $0af1, $1ad0, $2ab3, $3a92
word $fd2e, $ed0f, $dd6c, $cd4d, $bdaa, $ad8b, $9de8, $8dc9
word $7c26, $6c07, $5c64, $4c45, $3ca2, $2c83, $1ce0, $0cc1
word $ef1f, $ff3e, $cf5d, $df7c, $af9b, $bfba, $8fd9, $9ff8
word $6e17, $7e36, $4e55, $5e74, $2e93, $3eb2, $0ed1, $1ef0
fit 496
Comments
However, this restriction on RES is very bizarre. There is nothing in the manual that mentions this. Is this a bug in the BST Spin compiler?
There are two program counters in the assembler. One keeps track of the cog (long) address of the generated code and the other keeps track of the hub (byte) address where the code is placed. The ORG statement sets the cog address and is usually used to reset the cog address to zero. The RES statement increments the cog address by its operand in order to reserve space in the cog, but doesn't increment the hub address at all. This is intended for use at the end of a cog program and allows for variables to be allocated in the cog, but not to occupy space in hub memory. The actual cog locations are loaded from whatever happens to follow the last generated code in hub memory when the COGNEW / COGINIT is executed.
If you place a RES statement in the middle of a cog program, the cog program counter is incremented, but the actual data that's in memory is whatever follows the RES statement(s) so the cog addresses and the following code and/or data are out-of-sync.