Hello,
I have a 40x1 a.3 communicating i2c to a slave 28x1 a.3 (with 'rts' and 'cts' lines for speed and reliability)
I have just found uncertainity in the 28x1's scratchpad on adresses 0 and 1.
when I say 'scratchpad', I always mean the slave 28x1's scratchpad.
"x" in binary numbers means that bit can be either 0 or 1.
Firstly, the 40x1 [redefining $30] puts %10000000 into adres 1 of the scratchpad, then the 28x1 responds by putting %10001100 (portA's state +bit7) in. The 40x1 reads it, and the 28x1 resets bit7 so it is %00001100 in adres 1.
Next, the 40x1 [redefining $30] puts %0000001x into adres 0, and the 28x1 completes an operation, then resets adres 0 to %0.
next, the 40x1 [redefining $30] puts %0000101x (in an if-then sequence) into adres 0, but the debug on the 28x1, which it always goes through after the 40x1 writes to it, says that adres 0 =%00000000 and adres 1 =%00110000. This means the 28x1 starts doing the wrong operation. The debug shows the correct values on the terminal window until then.
Could anyone find the cause of this data glitch at the end please, or do I have to say what they are basically doing, and post the programs and a schematic?
edit: I changed the slave address of both (including the [refiners]) into $A0 (%10100000), and now I get %10100000 in adres 1 and %00000000 in adres 0 after the 40x1 puts %0000101x into adres 0.
where this happens is:
seems like the hi2c interpreter goes faulty on hi2cout commands in if statements, by sending the slave adres number into the stated+1 memory adres.
edit2: I have changed the memory adres 0s into 1s, and the memory adres 1s into 2s (e.g. changed 'symbol dmctl=0' to 'symbol dmctl=1'), and I get the same glitch when now, %10100000 gets put into adres 2 at the above commands.
edit3: err... Hang on! I have just removed the 'if' statement so it just leaves 'hi2cout [$A0],dmctl,(%1010)', and it still has the problem!
edit4: I have removed [$A0] to leave 'hi2cout dmctl,(%1010)', and still doesn't work properly.
edit5: even when the full %00001010 is typed in. Another thing to say is that after the 40x1 has put %1x, the 28x1 goes through many hpwm(duty) ... and pwmout 1, ... /duty ... commands, and then 'hpwm off' and 'pwmout 1 off' commands at the end.
edit6: I put a 'hi2csetup off' commands before the pwm commands in the 28x1, and repeated the 'hi2csetup i2cslave,$30' command after them, and now, at the same command on the 40x1, the address 0 is still %00000000, and adres 1 stays at %00001100.
Next, the 40x1 retrys sending hi2cout 0,(%0000001x) about 100 times until both adresses become %10100000.
while it retrys, I 'scoped the i2c bus to find the slave adress and memory adres bytes, but no data bytes. I also scoped the starting sequence to find it correct, with the data byte after the adres bytes.
I'll just look at the 40x1 now.
edit7: The reason why there is no data byte after the adres bytes is because there is no ack after the memory adres.
So finally, the problem is that after the 28x1 has been through the pwm commands, even though the hi2csetup command is put after the pwm commands, the 40x1 cannot access the 28x1's scratchpad because it didn't recieve an ack after the address bytes were sent.
I have a 40x1 a.3 communicating i2c to a slave 28x1 a.3 (with 'rts' and 'cts' lines for speed and reliability)
I have just found uncertainity in the 28x1's scratchpad on adresses 0 and 1.
when I say 'scratchpad', I always mean the slave 28x1's scratchpad.
"x" in binary numbers means that bit can be either 0 or 1.
Code:
40x1:
setfreq m8
hi2csetup i2cmaster,$30,i2cfast_8,i2cbyte
28x1:
setfreq m8
hi2csetup i2cslave,$30Next, the 40x1 [redefining $30] puts %0000001x into adres 0, and the 28x1 completes an operation, then resets adres 0 to %0.
next, the 40x1 [redefining $30] puts %0000101x (in an if-then sequence) into adres 0, but the debug on the 28x1, which it always goes through after the 40x1 writes to it, says that adres 0 =%00000000 and adres 1 =%00110000. This means the 28x1 starts doing the wrong operation. The debug shows the correct values on the terminal window until then.
Could anyone find the cause of this data glitch at the end please, or do I have to say what they are basically doing, and post the programs and a schematic?
edit: I changed the slave address of both (including the [refiners]) into $A0 (%10100000), and now I get %10100000 in adres 1 and %00000000 in adres 0 after the 40x1 puts %0000101x into adres 0.
where this happens is:
Code:
symbol dmctl=0
...
symbol crw=bit20
...
...
if crw=1 then
hi2cout [$A0],dmctl,(%1011)
else
hi2cout [$A0],dmctl,(%1010)
endifedit2: I have changed the memory adres 0s into 1s, and the memory adres 1s into 2s (e.g. changed 'symbol dmctl=0' to 'symbol dmctl=1'), and I get the same glitch when now, %10100000 gets put into adres 2 at the above commands.
edit3: err... Hang on! I have just removed the 'if' statement so it just leaves 'hi2cout [$A0],dmctl,(%1010)', and it still has the problem!
edit4: I have removed [$A0] to leave 'hi2cout dmctl,(%1010)', and still doesn't work properly.
edit5: even when the full %00001010 is typed in. Another thing to say is that after the 40x1 has put %1x, the 28x1 goes through many hpwm(duty) ... and pwmout 1, ... /duty ... commands, and then 'hpwm off' and 'pwmout 1 off' commands at the end.
edit6: I put a 'hi2csetup off' commands before the pwm commands in the 28x1, and repeated the 'hi2csetup i2cslave,$30' command after them, and now, at the same command on the 40x1, the address 0 is still %00000000, and adres 1 stays at %00001100.
Next, the 40x1 retrys sending hi2cout 0,(%0000001x) about 100 times until both adresses become %10100000.
while it retrys, I 'scoped the i2c bus to find the slave adress and memory adres bytes, but no data bytes. I also scoped the starting sequence to find it correct, with the data byte after the adres bytes.
I'll just look at the 40x1 now.
edit7: The reason why there is no data byte after the adres bytes is because there is no ack after the memory adres.
So finally, the problem is that after the 28x1 has been through the pwm commands, even though the hi2csetup command is put after the pwm commands, the 40x1 cannot access the 28x1's scratchpad because it didn't recieve an ack after the address bytes were sent.
Last edited:
