OOPS! Seems like I’ve stumbled into a conspiracy! I haven’t heard of it either, but I like it!
Alan KM6VV
A slight update here. It turns out that on the Pro40 using the the H8/3687 at 20mhz, that using hserial at 115200 will not work very well. That is if you look at their formulas for the hardware serial port, that there would be about an 8.5% error at that baud rate. Here is additional information that I received from Nathan.
Edit: Note: this may also be true with BAP28 running at 16mhz on the H8/3694, where you have hardware baud rates:
Note: numbers will bye N * 32 so the the hardware baud rates are something like
1 = 500,000
2 = 250,000
3 = 166,666
4 = 125,000
5 = 100,000
6 = 83,333
7 = 71,428
8 = 62,500
9 = 55,555
10 = 50,000
11 = 45,454
12 = 41,666
13 = 38,461So for XBee or SSC-32 baud rate of 38400 we have a real low error rate something like a .15%
for 57600 XBee probably something like 3.7% error
for 115200 again 8.5% error
So for now will leave xbee at 38400…
Kurt
I slight update to this and soon maybe trying out XBee control of my Hex as well…
I decided to prepare the Hex code based off of Xans phoenix 1.3 code to try it with the DIY remote with XBee. Zenta mentioned that he now has some XBees and would like to try it on his hex as well. But we have concerns that the HSERIAL to control the XBee may cause the serouts to the SsC to not work properly. So I decided to try converting the hex code to use my Timer assisted serout functions, so I am now in the process of doing that. I now have the code compiling for both Bap28s and Bap40s. While at it I removed the TimerW interrupts for a timer and on the Bap28 used TimerA and Bap40 TimerB1 where timer increments on clock/8192. Also updated the TASerout function to hopefully work on Bap40. TimerV is on both modules, but had to scale the times for the differences in clock speeds. If it works, I may also be able to drive the SSC-32 at full speed, but we will see…
Since my output function only works with a buffer and size, I had to do some conversion of ServoDriver function. I now calls functions to output each pin and looks something like:
[code]ServoDriver:
;Front Right leg
gosub ServoOutputPin[RFCoxaPin,TOINT(TOFLOAT(-RFCoxaAngle +90)/0.10588238)+650]
gosub ServoOutputPin[RFFemurPin,TOINT(TOFLOAT(-RFFemurAngle+90)/0.10588238)+650]
gosub ServoOutputPin[RFTibiaPin,TOINT(TOFLOAT(-RFTibiaAngle+90)/0.10588238)+650]
…
;Send
gosub ServoOutputTime[SSCTime]
PrevSSCTime = SSCTime
return
;--------------------------------------------------------------------
;[SOItoAVal] Internal convert the number into ascii in our output buffer…
; Warning:: this uses the variables internal to the two output functions…
SOPin var WORD
SOVal var WORD
SOIndex var WORD
SOBuf var byte(12)
SOIToAVal:
SOPin = 10000 ; reuse here...
; find the first digit to output
while (SOPin >= SOVal) and (SOPin > 1)
SOPin = SOPin / 10
wend
do
SOBuf(SOIndex) = SOVal/SOPin + "0"
SOIndex = SOIndex + 1
SOVal = SOVal // SOPin
SOPin = SOPin / 10
while (SOPIN > 0)
return
;--------------------------------------------------------------------
;[ServoOutputPin] Output information about one pin
ServoOutputPin[SOPin, SOVal] :
SOBuf(0) = “#”
SOBuf(1) = (SOPin/10) + “0”
SOBuf(2) = (SOPin//10) + “0”
SOBuf(3) = “P”
SOIndex = 4
gosub SOItoAVal ; use our internal function to convert SOVal to ascii starting at SOIndex in SOBuf
gosub TASerout[SSC_OUT, SSC_BAUTE, @SOBuf, SOIndex]
return
;--------------------------------------------------------------------
;[ServoOutputTime] Output Time Value
ServoOutputTime[SOVal] :
SOBuf(0) = “T”
SOIndex = 1
gosub SOIToAVal ; convert our time value to ascii string starting at SOIndex
SOBuf(SOIndex) = 13 ; end with CR
gosub TASerout[SSC_OUT, SSC_BAUTE, @SOBuf, SOIndex + 1] ; output our string remember to add CR at end!
return
;--------------------------------------------------------------------
;[FREE SERVOS] Frees all the servos
FreeServos
for Index = 0 to 31
gosub ServoOutputPin[Index,0]
next
gosub ServoOutputTime[200]
return
[/code]
Now off to testing it out and then trying out an XBee on it!
Kurt
Just an FYI…
I have now done some debugging of the code with the output to the SSC-32 going through TASerout with the code above. It is now walking again!!! 
Not only that it is now walking at the highest SSC-32 baud of 115200.
I have most of the XBEE code also merged in here. However I still need to do a little more work as P14 and P15 on Bap28 uses HSERIAL but on the Bap40 it is HSERIAL2. Also my first pass input function does not have all of the body rotate stuff yet.
Now to hook-up the Xbee hardware. Since I have the IO pins, I may leave the PS2 on the hex. WIll need to move its IO pins, but that is easy as the pull-up resistor is going to the breadboard… May use one of the switches on the board to switch between PS2 and XBee…
That is all for now
Kurt
Nice effort!
Will you be able to use other RF links besides XBee? Like BlueTooth?
Also making the PS2 available sounds like a good idea.
Alan KM6VV
Thanks Alan,
A lot of the code I am working on is semi-specific to the XBee, but a lot of it is not. That is the DIY remote control code with XBees has a bunch of code that is specific for pairing the units and the like, but that could be abstracted out, after that it is simply packet formats and serial IO. So you could probably do something very similar with Blue tooth. I will probably also make the changes to handle either Series 1 or Series 2 Xbees. but that is after I pick up another Series 2 as one of mine is bricked…
Yep I will probably leave on the PS2, so I can continue to play and test with it.
Kurt
Hi Kurt,
Sorry for my late response. Great to hear you’ve got the baud at the max. This should change the SSC update time from 50 to 17 ms! WOW! This would upgrade the speed a lot when used with V2.0!
I’m also interested in the XBEE logic. This would make the DIY state of the art because it would also allow bidirectional communication.
As always, Great work Kurt!
Xan
EDIT: Is it also possible to run the BAP28 on 115200?
Thanks Xan,
In theory it should work on both processors. The code is the same, I just change the scaling of timer involved. I will include a completely hacked up with lots of #ifdefs to compile for either XBEE or PS2. It automatically compiles for BAP28 or BAP40. I am still debuging some issues with timings of XBEES on PRO40s. The HSERIN2 and/or timings is not working the same on the BAP40 so my packets are not working properly. I did test them yesterday on my test board with BAP28 and they were working. I have some questions out to Nathan on this, will try to fix/work around. May swap back in Bap28 as I would like to see the Hex walk under XBee control.
This code is not using TimerA (28)or TimerB1(40) for timings of SSC-32 moves. They increment every 8192 clocks so I changed to use a multiplier and divider to convert to milliseconds. They interrupt maybe 7-8 times per second, so I am not worried about the 32 bit timer value wraps around as my robot does not run for days without rebooting. I now also use this timer for a couple of other things. Like when I turn on the mode that the remote only tells me when something changes, if I don’t hear anything for a second, I query it for data anyway… Also I have a hack in there to see if I can make the HSERIN2 timeout work the way I think it is supposed to…
Again I included the code here, but this Is a work in progress, which has not been run on the hex in XBEE mode…
Yeah, I would really like to see that happend!
Thanks for sharing your work Kurt! 8)
I’m in the “building process” on a new robot at the time, but I’m looking forward to play with the XBEE’s too, soon.
BTW, you’ve changed your profile picture! Cool, the DIY reminds me a little of a robot face. 
Funny you should mention swapping the BAP28 back in. I’ve been thinking of rigging up a BB2 and BAP28 onto my functioning hexapod. It currently has a PIC4620 programmed in ‘C’ on a “QuikFlash” board, but I’d like to see how the Phoenix code runs on my 'bot in person! And of course there is already a ‘C’ port of the code (somebody beat me to it), which is an avenue I intend to explore.
On another robotics club list, URLs of several ARM7 modules (some 28-pin!) were posted. These are also interesting!
So many uPs, so little time!
Alan KM6VV
Hi Alan and Zenta,
Yep, I may try putting the BAP28 back onto the Hex, I simply removed it to play with the Pro40. I can easily work on the XBEE stuff on the 40 without it being on the robot. It would be nice to see the XBEE stuff running on the hex so maybe tomorrow I will get a chance to do it. Been busy today doing none robot stuff.
If I did not like the BAPs with the renesas H8s, there are several different processor chips/boards that I would try including things like the pico ITX… but for now I will stick with these.
Yah I finally a profile picture and since I am spending a lot of time with the DIY stuff, I am trying out this one. I was hoping to use one with James the Christmas Bush but so far I have not found a decent picture.
Kurt