QP command - Also serin timeout issue

Lynxmotion Electronics & Software
1

I am playing around with the Ground contact switches and I am trigging a WKP_0-WKP_5 interrupt when one of the contact switches makes contact.

During the interrupt I am trying to query the SSC-32 for the positions of a couple servos. As for a quick and dirty test version I am trying the QP command. Reading the online guide I believe I can query multiple servos with one command. I have tried something like:
QP 1 2
Also I have tried QP 1,2
But I am only getting 1 byte being returned. I verified this with logic analyzer. Note: I am using the experimental binary version of the SSC-32 firmware.
Version: SSC32-V2.05alpha3A-EGP

Second issue:

serin cSSC_IN, cSSC_BAUD, 1000, _HWKP_TO, [_wFEMFromSSC.lowbyte, _wTIBFromSSC.lowbyte] _HWKP_TO:
Looking at the logic analyzer it looks like the one byte being returned starts in .644ms. So I know my timeout is not enough. Will up it to 5ms. So the Timeout will happen, but after that point I believe the program is reseting. So not sure if some issue with serin timing out on version 2.0.0.0 if the BAP IDE? Note: still resets after changing the timeout to 10000

Kurt

2

Try QP1QP2 (spaces are optional, QP 1 QP 2 is the same). That should cause the SSC32 to send both bytes.

The delay before the SSC32 replies can vary depending on what it is doing when the request comes in, but it will always be at least the value specified for the transmit delay (one of the resgisters, I forget which). If you want the reply to happen faster, reduce the transmit delay. (The timing for the second byte will depend on the transmit pacing register.) Regardless of the delay/pacing, you should have a timeout of at least a few milliseconds. If the SSC32 happens to be updating servo positions when the command arrives, the response might be delayed by a millisecond or so.

I don’t know how the Basic ATOM behaves if you spend milliseconds in an interrupt handler. That might have something to do with the apparent resets.

Mike

3

Thanks Mike, Will try. May just convert to use the binary query command. But for the Quick and Dirty test it was easier to use the QP. Don’t have to worry about figuring out which bits to output. Not hard generate a bitmask for which servos I want, and then do some shift and masks to output the request, then receive the N bytes and figure out which one went to which servo… Not hard stuff, will probably do as it gives higher resolution…

As for the reset, I think it is probably a bug with the BAP code when it times out with partial results, it may corrupt a register or may corrupt the stack. Sent email to Nathan on this. I do have the code responding by doing two different serout/serin groupings. As for on the interrupt, I reenabled interrupts during the handler so should not be overly bad…

Kurt

4

The timeout problem is specified to using timeouts in an interrupt. A timeout clears the general stack when it exceptions(jumps to it’s label). That ends up clearing the return address of the interrupt causing your program to go boom. :slight_smile:

There is no way to fix this at the present time. However if you must use timeouts(which I highly recommend NOT doing because timeouts mean you are doing something that takes a long time) in an interrupt, you can pop the return address off the stack and save it in a word or long variable and then push it back on the stack once the command using the timeout is complete, but before resuming from the interrupt.

5

Updates:
Nathan mentioned in the prevous post , the reset problem is sort-of by design… That is, the code can not handle a timeout within an interrupt handler due to how he cleans up the stack when the timeout happens. There may be some hack ways around this. But this is experimental stuff anyway…

Been playing around with the trying to query with both QP and binary command and I am not getting consistent results, which I am now trying to figure out…

I have lots of stuff being printed out (nice to user Arc32 with HSERIAL for this!)

0 4 0:143(329,554=142)[1189 976=143]143(237,346=141)[1276 1173=141]
0 5 0:62(-607,-375=62)[2073 1853=62]143(237,346=141)[1276 1173=141]
0 6 0:143(212,229=141)[1299 1283=141]143(237,363=140)

WC: 0T: 345:260(1292,1217=141){1280,1240=143}<1321,1252=138>

The first couple of lines show the first two legs (I deleted the rest from this post). I am showing that in these three steps of the sequence the first leg is going to Y positions 143 to 62 back to 143 in tenths of CM. The numbers in the () in this line are the angles of the servos in 10s of degree, with the = showing my calculation for the FK from these angles. The numbers in the ] are the converted to pulses that is sent to the SSC-32 and again the = is my calculated y from these.

The WC line shows that I received WKP_0 interrupt. It also shows the time in ms after the command was issued : time of the command. the values in () are my guesstimate of expected values. Note: I should take into account that the time exceeded and should be the end value. The values in the {} are from the QP command,

serout cSSC_OUT, cSSC_BAUD, "QP", dec cFemurPin(_bWhichWKP), "QP", dec cTibiaPin(_bWhichWKP),13] serin cSSC_IN, cSSC_BAUD, 10000, _HWKP_TO, [_wFEMFromSSC.lowbyte, _wTIBFromSSC.lowbyte] _HWKP_TO: _wFEMFromSSC = _wFEMFromSSC * 10 _wTIBFromSSC = _wTIBFromSSC * 10
These values don’t make any sense to me. I then added the binary query, whose values are shwon in <>

_lSSCMask = (1<<cFemurPin(_bWhichWKP))| (1 << cTibiaPin(_bWhichWKP)) ; generate the mask serout cSSC_Out, cSSC_BAUD, [0xB0|(_lSSCMask & 0xf),(_lSSCMask>>4) & 0x7f, (_lSSCMask>>11) & 0x7f,(_lSSCMask>>18) & 0x7f,(_lSSCMask>>25) & 0x7f] serin cSSC_In, cSSC_BAUD, 10000, _HWKP_TO2,[_wFEMFromSSC2.highbyte, _wFEMFromSSC2.lowbyte,_wTIBFromSSC2.highbyte, _wTIBFromSSC2.lowbyte]; _HWKP_TO2:
Note: earlier in the interrupt handler I sent a stop command (0xa2) to the SSC-32.

Still investigating. One question I wonder is if the values returned by these commands take into account the servo zero offset stored on the SSC-32

All for now
Kurt

6

OK, you caught me. The binary queries do not take the PO value into account. Mea culpa. I am working on an update to the SSC-32 firmware to clean up binary mode and add some features. I’ll fix it in that update.

Mike

7

Hi Mike,

I see that Kurt found a small issue when querying the servo positions with an offset. Can you tell me what the current status is? I’m picking up the robotics stuff where I left a few months ago. So I probably have missed a lot. :open_mouth:

Thanks!

Xan