TA development topic

YEAH!

I only copy/passed the TA code in there and then we figured out that it didn’t fit in the BAP. So it is possible that there where some thing that where not in the right place. Thanks for getting it up and running. I hope to do the same thing this evening! No sports this evening. No game tonight.

I’ll post my progress :slight_smile:

Thanks!

Hi Kurt,

Just a small update this time. Last night I rewired the sensor inputs and moved the SSC I/O to P20 en P21.
The compared my working version with yours. Saw you added the GP disable stuff and the other changes you talked about.
After programming the THex did nothing.

I used your XBEE test program to see if receives input from the remote. And it does! Is this program also using the RTS signal?

I had an old BB1 laying around that I originally used for BlackWido. Removed the speaker and directly connected it to P22 (+ to signal, - to GND). The hex didn’t show any movement or sound when hitting the 0 button on the remote. I have to debug some more to figure out what is going on. More on Saturday.

Like you said all tracing like

serout s_out, i38400, "trace", 13]

is replaced by:

hserout 1, "trace", 13]

Does this also redirect to the usb directly? Hardware mapped?

Xan

Yes heserout with a 1 goes to the first hardware serial port and 2 goes to second. You need to initialize the port with the baud and the like by using sethserial… More later,it is 1:45am typing on iPad
Kurt

Good Morning,

It is now 6:30…

My XBee test program does use the RTS line:
CXBEE_RTS con p34

Note: in the real program I init the hardware serial port to the baud rate 38400.

You can see this at the [init] comment.

#ifndef BASICATOMPRO28 HSP_DEBUG con 1 sethserial1 H38400 #endif
Note: Most of the time you will see me use the define HSP_DEBUG to say which hardware port. I also SETUP HSP_XBEE in the other files, which on BAP28 gets defined as a 1 and on BAP40/ARC32 as 2… Then the rest of the code does not have to change… Unfortunately I could not get Nathan to provide any way to abstract the use of Hardware Serial port versus Bit Bang… So on 28 have to use SEROUT and on ARC32 choose to use HSEROUT.

On main program you say it does nothing… If you start a debug terminal, do you get output? If I remember correctly I would always get repeating of the message:
“Gait move forward” even when nothing else was happening… When you turn on the transmitter, do some other light(s) come on on your XBees? They should showing connection.
Do you see any flashing on the RX or TX leds on the XBee. On the debug terminal, I believe I left the code in place that dumps the XBEE packets it receives, like:

RCV XBEE Packet: 81 From:088: 9 1 0 80 0 FF 67 0

Note: this is not the complete packet, I simply hard code outputting so many bytes, so I could see what I was receiving…

That is all I can think of for now.

Kurt

P.S. - Just out of curiosity which version of Arc32 are you using? Is this an older 1 or a newer one sent by Dale? I remember Zenta got one from Dale that had some differences. Something about the Pins on either AUX1 and/or Aux2… I only have my old ones.

Hi Kurt,

I did some debugging and found out that I mixed up the wires to the SSC and Speaker. :blush:

I’ve got the ARC as shown in ARC manual the port AUX1 has pins that are bent in a 90 degree angle. I think this is the first version. The image on there product page difference from my version.

Gonna debug some TA now! Yeah :slight_smile:

:smiley:

Sounds like first version.

Kurt

Hi Kurt,

I can get my head around this… :unamused:

  • I’ve got 2 variables that are declared as a word (16 bits)
  • Both variables contain a value of 1000.
  • If I multiply them, the result will overflow the 16 bits (65536)
    How can I store this in a long (32 bits) variable?

I tried the following test program but it doesn’t make sense:

[code]sethserial1 H38400
var1 var word
var2 var word
var3 var word
var4 var long

var1 = 10000
var2 = 10000

main:

var3 = var1*var2
hserout 1, "var3 ", dec var3, 13]

hserout 1, "multi ", dec var1*var2, 13]

var4 = var1*var3
hserout 1, "var4 ", dec var4, 13]

pause 1000
goto main[/code]
The output will give:

var3 57600 multi 100000000 var4 576000000

  • So it looks like var3 gets an overflow. Don’t know why 57600 though.
  • ‘Multi’ shows that the chip is capable of doing the math.
  • It looks like the cast from a word to a long isn’t done correctly.
  • Also if I change var1 and var2 to longs it doesn’t give the wanted result.
    Any idea what is causing this, and how to solve this?

Thanks

I need to get the T-Hex back out to check this.

It is my understanding from Nathan, that all math is done using 32 bits. So 10000 * 10000 = 100000 which in hex is 5F5E100. Assigning this to a word value will probably take the low order word=E100 which in decimal is 57600. So assigning the result to a 32 bit variable should handle it.

My assumption is if you assigned Var4 = var1*var2 it would also print out the same as Multi. It looks like Var4 is correct as you are multiplying 57600 * 1000 and getting the value 576000000.

So everything here is working as I would expect

Kurt

Thanks!

57600 makes more sense now. I didn’t look at the value as hex. should have done that :slight_smile: (been away to long… :cry: )

I’ve been changing a lot of code in my test app. I must have mistyped ‘var4=var1var2’ to 'var4=var1var3’. stupid!

Again, Thanks for your quick answer. I’ll check it out this evening! Lots of bot time this week :smiley:

Xan

ps. gratz with your 3500th post already! :open_mouth:

Is this also for the BAP or only for the ARC? Both manuals says 16 bits processors so the 32 bit math is already done in 2 clocks i guess…

They are 16 bit processors, but they have 32 bit registers, that break down into other parts. That is take the 32 bit register er1. It breaks down to 2 16 bit registers e1 and r1. The 16 bit register r1, breaks down to 2 8 bit registers r1h and r1l. Note: e1 does not break down to 8 bit registers. As for 2 clocks, it takes quite a few more clocks than this…
Example:

mov.w @VAR1:16, r1 ; move takes 6 clocks mov.w @VAR2:16, r2 ; 6 clocks mulxu.w r1, er2 ; 16 bit multiply result 32 bits - 22 clocks mov.w r2, @VAR3:16 ; Save result 6

So the line: “var3 = var1 * var2” takes a minimum of 40 clocks…

Kurt

Hi Guys,

I’ve got a day off from work so I’m playing with TA today. Yeah! :slight_smile:

So far I found 2 issues that I need some help with.
A: SSC false readings
I noticed that sometimes the SSC gives me some false values when querying the servo positions. To test this further I made the following test program:

[code]sethserial1 H38400
var1 var word
var3 var word(31)

cSSC_OUT con P21 ;Output pin for (SSC32 RX) on BotBoard (Yellow)
cSSC_IN con P20 ;Input pin for (SSC32 TX) on BotBoard (Blue)
cSSC_BAUD con i38400;i115200 ;SSC32 BAUD rate 38400 115200

i var word
legindex var word
main:

pause 100
hserout 1, "send: "]
for legindex = 0 to 31
hserout 1, " ", dec legIndex, " ", dec (1500+(legindex10))]
serout cSSC_OUT, cSSC_BAUD, “#”, dec legIndex, “P”, dec (1500+(legindex
10))]
pause 1
next
hserout 1, [13]
serout cSSC_OUT, cSSC_BAUD, [13]

pause 100
gosub QueryServoPulses

hserout 1, "query: "]
for i = 0 to 31
hserout 1, " ", dec i, " ", dec var3(i)]
pause 1
next
hserout 1, [13]

pause 1000
goto main
;--------------------------------------------------------------------
;[QUERY SERVO PULSES] Queries the current angles of the servos
; Using the SSC binary bit mask
;- byte 1 = (binary) 1 0 1 1 s3 s2 s1 s0
;- byte 2 = (binary) 0 s10 s9 s8 s7 s6 s5 s4
;- byte 3 = (binary) 0 s17 s16 s15 s14 s13 s12 s11
;- byte 4 = (binary) 0 s24 s23 s22 s21 s20 s19 s18
;- byte 5 = (binary) 0 s31 s30 s29 s28 s27 s26 s25
;WARNING! rearanging the servo pin numbers also requires to rearanging the QueryPinMask AND PWM Serin order.
; PWM serin returns 2 bytes for each queried servo. The read order is from low (P0) to high (P31).
QueryServoPulses:

serout cSSC_OUT, cSSC_BAUD, [0xBF, 0x7F, 0x7F, 0x7F, 0x7F]

serin cSSC_IN, cSSC_BAUD, [var3(0).highbyte, var3(0).lowbyte |
,var3(1).highbyte, var3(1).lowbyte |
,var3(2).highbyte, var3(2).lowbyte |
,var3(3).highbyte, var3(3).lowbyte |
,var3(4).highbyte, var3(4).lowbyte |
,var3(5).highbyte, var3(5).lowbyte |
,var3(6).highbyte, var3(6).lowbyte |
,var3(7).highbyte, var3(7).lowbyte |
,var3(8).highbyte, var3(8).lowbyte |
,var3(9).highbyte, var3(9).lowbyte |
,var3(10).highbyte, var3(10).lowbyte |
,var3(11).highbyte, var3(11).lowbyte |
,var3(12).highbyte, var3(12).lowbyte |
,var3(13).highbyte, var3(13).lowbyte |
,var3(14).highbyte, var3(14).lowbyte |
,var3(15).highbyte, var3(15).lowbyte |
,var3(16).highbyte, var3(16).lowbyte |
,var3(17).highbyte, var3(17).lowbyte |
,var3(18).highbyte, var3(18).lowbyte |
,var3(19).highbyte, var3(19).lowbyte |
,var3(20).highbyte, var3(20).lowbyte |
,var3(21).highbyte, var3(21).lowbyte |
,var3(22).highbyte, var3(22).lowbyte |
,var3(23).highbyte, var3(23).lowbyte |
,var3(24).highbyte, var3(24).lowbyte |
,var3(25).highbyte, var3(25).lowbyte |
,var3(26).highbyte, var3(26).lowbyte |
,var3(27).highbyte, var3(27).lowbyte |
,var3(28).highbyte, var3(28).lowbyte |
,var3(29).highbyte, var3(29).lowbyte |
,var3(30).highbyte, var3(30).lowbyte |
,var3(31).highbyte, var3(31).lowbyte]

return
;--------------------------------------------------------------------
[/code]
When running the program a couple of times I get the following result:

send: 0 1500 1 1510 2 1520 3 1530 4 1540 5 1550 6 1560 7 1570 8 1580 9 1590 10 1600 11 1610 12 1620 13 1630 14 1640 15 1650 16 1660 17 1670 18 1680 19 1690 20 1700 21 1710 22 1720 23 1730 24 1740 25 1750 26 1760 27 1770 28 1780 29 1790 30 1800 31 1810
query: 0 1500 1 1510 2 1620 3 1530 4 1540 5 1550 6 1560 7 1570 8 1580 9 1790 10 1600 11 1610 12 1620 13 1630 14 1640 15 1650 16 1660 17 1670 18 1680 19 1690 20 1700 21 1710 22 1720 23 1740 24 1740 25 1750 26 1760 27 1770 28 1780 29 1790 30 1800 31 1810

send: 0 1500 1 1510 2 1520 3 1530 4 1540 5 1550 6 1560 7 1570 8 1580 9 1590 10 1600 11 1610 12 1620 13 1630 14 1640 15 1650 16 1660 17 1670 18 1680 19 1690 20 1700 21 1710 22 1720 23 1730 24 1740 25 1750 26 1760 27 1770 28 1780 29 1790 30 1800 31 1810
query: 0 1510 1 1510 2 1520 3 1530 4 1540 5 1550 6 1560 7 1570 8 1580 9 1590 10 1600 11 1610 12 1620 13 1630 14 1640 15 1650 16 1670 17 1670 18 1680 19 1690 20 1700 21 1710 22 1720 23 1730 24 1740 25 1750 26 1760 27 1770 28 1780 29 1800 30 1800 31 1810

send: 0 1500 1 1510 2 1520 3 1530 4 1540 5 1550 6 1560 7 1570 8 1580 9 1590 10 1600 11 1610 12 1620 13 1630 14 1640 15 1650 16 1660 17 1670 18 1680 19 1690 20 1700 21 1710 22 1720 23 1730 24 1740 25 1750 26 1760 27 1770 28 1780 29 1790 30 1800 31 1810
query: 0 1500 1 1510 2 1520 3 1530 4 1540 5 1560 6 1560 7 1570 8 1580 9 1590 10 1600 11 1610 12 1620 13 1630 14 1640 15 1650 16 1660 17 1670 18 1680 19 1690 20 1700 21 1710 22 1720 23 1730 24 1740 25 1750 26 1760 27 1770 28 1780 29 1790 30 1800 31 1810

send: 0 1500 1 1510 2 1520 3 1530 4 1540 5 1550 6 1560 7 1570 8 1580 9 1590 10 1600 11 1610 12 1620 13 1630 14 1640 15 1650 16 1660 17 1670 18 1680 19 1690 20 1700 21 1710 22 1720 23 1730 24 1740 25 1750 26 1760 27 1770 28 1780 29 1790 30 1800 31 1810
query: 0 1500 1 1620 2 1520 3 1530 4 1740 5 1550 6 1560 7 1570 8 1580 9 1590 10 1600 11 1610 12 1620 13 1630 14 1640 15 1650 16 1660 17 1670 18 1680 19 1690 20 1700 21 1710 22 1720 23 1730 24 1740 25 1750 26 1760 27 1770 28 1780 29 1790 30 1800 31 1810

send: 0 1500 1 1510 2 1520 3 1530 4 1540 5 1550 6 1560 7 1570 8 1580 9 1590 10 1600 11 1610 12 1620 13 1630 14 1640 15 1650 16 1660 17 1670 18 1680 19 1690 20 1700 21 1710 22 1720 23 1730 24 1740 25 1750 26 1760 27 1770 28 1780 29 1790 30 1800 31 1810
query: 0 1600 1 1650 2 1520 3 1530 4 1540 5 1550 6 1560 7 1570 8 1580 9 1590 10 1600 11 1610 12 1620 13 1630 14 1640 15 1650 16 1660 17 1670 18 1680 19 1690 20 1700 21 1710 22 1720 23 1730 24 1740 25 1750 26 1760 27 1770 28 1780 29 1810 30 1800 31 1810

I marked all the false readings in red.

I’ve tried the following firmware versions:

  • SSC32-V2.05Alpha4A-EGP
  • SSC32-V2.06Alpha1B-EGP
  • SSC32-V2.07Alpha1A-EGP
    All versions give me the same result :frowning:
    Am I overlooking something or does this show an, as we call it, “a hidden feature” (aka bug). Maybe mike could help out here.

B: baud rate
The Query Servo Pulses function is copied from the Hybrid which was communicating on a baud of 38400.
Kurt, can you tell me what changes must be made to upgrade the baud to 115200?

Thanks!

Xan

First the easy part
B) I changed cSSC_BAUD con i115200 ;SSC32 BAUD rate 38400 115200
And I changed the Baud jumper on the SSC-32. It worked for me with BAP28, but I was having problem on Arc32, which may have been issue with my own code. Probably should try it again and check out with logic analyzer.

Now to guess work: My strong guess is that the serial stream to and from the Arc32 is getting corrupted. Remember in the BAP28 version with XBee and SSC-32 we had the code to enable and disable control interrupts…
gosub ControlAllowInput[0];

That was to keep the XBee from outputting characters, which would cause an interrupt on the hardware serial port to handle the data coming in… Well your data is probably being corrupted by the interrupts for handling the output to the debug hardware serial port, when it finishes outputting a character it generates an interrupt, such that the interrupt handler can see if there are any more characters in the queue…

Couple of options here:

  1. Since this is a simple test, with no other interrupts. Don’t use the hardware serial port. Use: serout S_OUT, i… ] instead. (would need to remove the sethserial1…) as well.

  2. Since the only interrupts you are now receiving is from the hardware serial port for output characters, you could probably disable interrupts around your serout and serin to the serial port

  3. Could add in the code like I did in the Arc32 version of T-Hex I uploaded awhile ago and add in some of the wait for the output queue to be empty… Probably still need a delay as will probably still get one more interrupt when the last character is output…
    Code looked like:

WaitDebugHSeroutComplete: #ifndef BASICATOMPRO28 nop ; transisition to assembly language. _WDTC_LOOP: mov.b @_HSEROUTSTART,r0l mov.b @_HSEROUTEND,r0h cmp.b r0l,r0h bne _WDTC_LOOP:8 pause 1 ; give time for the last character to output and do it's interrupt. #endif return
Would need to add calls to this before each serout or serin…

Will try to test some of this out later today.
Kurt

Quick update: I am running a slightly modified version of your program. That is I detect if there is an error and print * instead of blank around the pin number and I will beep once for that pass through. So far in 10 minutes no errors. I was having problems at first with servo 31. Figured out it’s entry was being walked over by the variable i. The array needs 32 elements (0-31). So updated the array definition and that fixed that.

Note: I first tried at 115200 and everything errored, so will probably hook up LA to see what is being output…

Kurt

Update: I commented out the HSEROUT’s with the Send part and now 115200 appears to be working… WIll now try to add them in and try different ways to see what works…

Update2: I uncommented the hserouts and used sledgehammer and that helps. That is I do a disable before the serout and an enable after it… This is what Arduino SoftwareSerial does…

Here is the code I am playing with:

[code] sethserial1 H38400
var1 var word
var3 var word(32)
fError var bit;
cSpeakerPin con P22
cSSC_OUT con P21 ;Output pin for (SSC32 RX) on BotBoard (Yellow)
cSSC_IN con P20 ;Input pin for (SSC32 TX) on BotBoard (Blue)
; cSSC_BAUD con i38400;i115200 ;SSC32 BAUD rate 38400 115200
cSSC_BAUD con i115200 ;SSC32 BAUD rate 38400 115200

i var word
legindex var word

sound cSpeakerPin, [40\4000, 40\5000]

main:

pause 100
hserout 1, "send:  "]
for legindex = 0 to 31
   hserout 1, " ", dec legIndex, " ", dec (1500+(legindex*10))]
   disable
   serout cSSC_OUT, cSSC_BAUD, "#", dec legIndex, "P", dec (1500+(legindex*10))]
   enable

; pause 1
next
hserout 1, [13]
serout cSSC_OUT, cSSC_BAUD, [13]

pause 100   
gosub QueryServoPulses

hserout 1, "query: "]
fError = 0;
for i = 0 to 31
  if var3(i) <> (1500+(i*10)) then
  	hserout 1, "*", dec i, "*", dec var3(i)]
  	if (!fError) then
  		sound cSpeakerPin, [40\5000]
  		fError = 1
  	endif
  else
  	hserout 1, " ", dec i, " ", dec var3(i)]
  endif
  pause 1
next
hserout 1, [13]

pause 1000
goto main
;--------------------------------------------------------------------
;[QUERY SERVO PULSES] Queries the current angles of the servos
; Using the SSC binary bit mask
;- byte 1 = (binary) 1 0 1 1 s3 s2 s1 s0
;- byte 2 = (binary) 0 s10 s9 s8 s7 s6 s5 s4
;- byte 3 = (binary) 0 s17 s16 s15 s14 s13 s12 s11
;- byte 4 = (binary) 0 s24 s23 s22 s21 s20 s19 s18
;- byte 5 = (binary) 0 s31 s30 s29 s28 s27 s26 s25
;WARNING! rearanging the servo pin numbers also requires to rearanging the QueryPinMask AND PWM Serin order.
;        PWM serin returns 2 bytes for each queried servo. The read order is from low (P0) to high (P31).
QueryServoPulses:

  serout cSSC_OUT, cSSC_BAUD, [0xBF, 0x7F, 0x7F, 0x7F, 0x7F]
 
  serin cSSC_IN, cSSC_BAUD, [var3(0).highbyte, var3(0).lowbyte |
                     ,var3(1).highbyte, var3(1).lowbyte |
                     ,var3(2).highbyte, var3(2).lowbyte |
                     ,var3(3).highbyte, var3(3).lowbyte |
                     ,var3(4).highbyte, var3(4).lowbyte |
                     ,var3(5).highbyte, var3(5).lowbyte |
                     ,var3(6).highbyte, var3(6).lowbyte |
                     ,var3(7).highbyte, var3(7).lowbyte |
                     ,var3(8).highbyte, var3(8).lowbyte |
                     ,var3(9).highbyte, var3(9).lowbyte |
                     ,var3(10).highbyte, var3(10).lowbyte |
                     ,var3(11).highbyte, var3(11).lowbyte |
                     ,var3(12).highbyte, var3(12).lowbyte |
                     ,var3(13).highbyte, var3(13).lowbyte |
                     ,var3(14).highbyte, var3(14).lowbyte |
                     ,var3(15).highbyte, var3(15).lowbyte |
                     ,var3(16).highbyte, var3(16).lowbyte |
                     ,var3(17).highbyte, var3(17).lowbyte |
                     ,var3(18).highbyte, var3(18).lowbyte |
                     ,var3(19).highbyte, var3(19).lowbyte |
                     ,var3(20).highbyte, var3(20).lowbyte |
                     ,var3(21).highbyte, var3(21).lowbyte |
                     ,var3(22).highbyte, var3(22).lowbyte |
                     ,var3(23).highbyte, var3(23).lowbyte |
                     ,var3(24).highbyte, var3(24).lowbyte |
                     ,var3(25).highbyte, var3(25).lowbyte |
                     ,var3(26).highbyte, var3(26).lowbyte |
                     ,var3(27).highbyte, var3(27).lowbyte |
                     ,var3(28).highbyte, var3(28).lowbyte |
                     ,var3(29).highbyte, var3(29).lowbyte |
                     ,var3(30).highbyte, var3(30).lowbyte |
                     ,var3(31).highbyte, var3(31).lowbyte]
            
return
;--------------------------------------------------------------------

[/code]

Hi Kurt,

Thanks for your fast answer!

After reading your posts it sounds logic that the interrupts are messing up the data.
I added enable/disable around the line where the servo positions are send, just like you did. This did the job. :slight_smile:
But why is an enable/disable in the query function not needed?

Xan

Warning, I missed adding enable/disable around the last serout (of 13).

Depending on your code, you may need the enable/disable in a query, but since you had a long pause (10th of a second, I thought that it may be safe…)

Kurt

Ok, and how about my main code? I’ve got a lot (really a lot) of tracing added now i’m debugging. Should I add enable/disable in the update servo positions sub? Or is it better to use the WaitDebugHSeroutComplete function?

Xan

Edit: Wait, the WaitDebugHSeroutComplete is already in the UpdateServoPosition, and the query subs. Still the data is corrupt in the main program…

I have to go now. More testing for me tomorrow.

In case you wanted to test I added my test program to this post.

WARNING!!!
The program overrules the remote! The bot starts walking by itself! This to have a fixed speed and height.
To test you need to attach the terminal You’ll see a lot of number drop by Those are angles and PWM’s of leg 3 (RightRear). Once the are no more new lines comming you need to push the TA switch of leg RR. This will print the last send PWM’s for reference and then print the queried PWM’s. They should be the same since the leg had time enough to go down all the way.

Feel free to give it a try if you want.

WARNING 2 , the code is a mess at the moment :wink:

Xan
Working version.zip (54.2 KB)

Kurt,

Quick question. What is the reason that you changed the debug serouts to hserouts? Should it be a problem if i change it back to serouts so it won’t interrupt the program?

Xan

When working on the Arc32 with HServo, serout more or less does not work very well at anything above maybe 2400 baud… So … With this using SSC-32 you can probably use normal Serouts… Too bad this is not like Arduino or the like, you would simply need to change the define for the object…

Kurt