Might be able to run the BAP on this board?
Must have jumpers, as the power/gnd pins would be different from the '877, etc.
Alan KM6VV
Edit: “BAP”
Not sure what the ABP is. This board does run all of the Basic Atoms as well as Basic Atom Pros, Probably most basic Stamps as well. The 40 pin connector has the same width as the other boards, so with some chips you use only some of the pins.
Kurt
Sorry, make that BAP.
Alan KM6VV
Hi Xan and others,
My first attempt of running the SSC-32 at full speed had problems, but when I went back to slower it still did. I think I need to work a little on the wiring. The Type-N plug has a tendancy to wiggle loose and turn off the processor, which makes the robot have problems walking 
Yesterday I spent some time back on the DIY code and was adding a time out timer that if my Brat does not receive any notifications of something new from the remote at will ask for data, as a way to make sure that we did not lose it… For the brat I am going to ask once a second as the brat can not move very far in a second… Later for rover I may make that time much smaller as it might go a long ways in a second!
But while I was looking to add the timer to the DIY I decided some of our current timers are overkill, this may include the one on the phoenix for example. That is we may use WTimer and divide the clock/8 which gives us .5uS resolution. But when we use the clock values we are converting to miliseconds by dividing by 2000. So I am converting the code for the DIY to use TimerA and will be changing my HEX Bap40 to use timerB1. While these are only 8 bit timers, they have the ability to only increment by Clock/8192. So if my math is correct that using this, we only process interrupts something like 7.6 times per second, so almost no overhead!.
In case you are interested in trying it out, the code will look something like:
(Note: not fully tested yet, so use at your own and robots risk )
...
wTimerCnt var word ; used now also in timing of how long since we received a message
wCurTimer var word ; Last used
...
; Timer A init, used for timing of messages and some times for timing code...
TMA = 0 ; clock / 8192 ; Low resolution clock - used for timeouts...
ONASMINTERRUPT TIMERAINT, HANDLE_TIMERA_ASM
ENABLE TIMERAINT
gosub ResetTimerAVal
...
gosub GetTimerVal], wCurTimer
; BUGBUG:: chould convert timer value to milliseconds by (T * 8192 * 1000)/16000000 or (T * 64)/125 so 1 second is aprox 1953
if wCurTImer > 1953 then
...
;==============================================================================
;[Handle_Timer_asm] - Handle timer A overlfow in assembly language. Currently only
;used for timings for debuging the speed of the code
;Now used to time how long since we received a message from the remote.
;this is important when we are in the NEW message mode, as we could be hung
;out with the robot walking and no new commands coming in.
;==============================================================================
BEGINASMSUB
HANDLE_TIMERA_ASM
push.w r1 ; first save away ER1 as we will mess with it.
bclr #6,@IRR1:8 ; clear the cooresponding bit in the interrupt pending mask
mov.w @WTIMERCNT:16,r1 ; Add 256 to our counter
inc.b r1h
mov.w r1, @WTIMERCNT:16
pop.w r1
rte
ENDASMSUB
;--------------------------------------------------------------------
;[getTimerVal] - Gets the Timer value from our overflow counter as well as the TCA counter. It
; makes sure of consistancy. That is it is very posible that
; after we grabed the timers value it overflows, before we grab the other part
; so we check to make sure it is correct and if necesary regrab things.
;==============================================================================
bTimerTmp var byte
GetTimerVal:
bTimerTmp = WtimerCnt.highbyte
wTimerCnt.lowbyte = TCA
if wTimerCnt.highbyte <> bTimerTmp then GetTimerVal ; make sure consistent value
return wTimerCnt
;--------------------------------------------------------------------
;[ResetTimerAVal] - Resets the timer
;==============================================================================
ResetTimerAVal:
TCA = 0
wTimerCnt = 0
returnNotes in this code. I hard coded the conversion to miliseconds, Earlier I had a conversion constant that we would divide by. Should change this to a multiplier(64) and a diviser (125).
Also I added a simple reset function that zeroed the timer. I found in for example the phoenix code we would grab start and end time and subtract and maybe have to worry about wrap around. That approach would still easily work. If so I would probably convert the timer functions to 32 bits instead of 16.
That is all for now
Kurt
A quick update. I finally got the battery and baud rate to work again back at the slower 38.4K rate, so I tried again at the higher baud rate 115.2K and the legs were spastic and not moving correctly (Yes I did change the baud rate jumpers on the SSC-32 as well 
)
So I hooked up the logic analyzer to see what was being output. I configured the program to have it automatically guess what the baud rate is by looking like. It was able to properly convert the pulses to characters, but it said the baud rate was 123711, if I tell the analyzer that it is 115200 it does not get the characters correct. I will also report this to Nathan.
If I look at the generated baud modes, I think they are setup as maybe 10 clocks per increment, that is:
i38400 generates 0x4034 where the 0x4000 is for the Inverted bit. 0x34 which is 52*10 clocks should be the pulse width which converts to an actual baud rate of 38462 (20,000,000/520)
I115200 generates 0x4011 so 0x11=17 and 17*10 clocks which converts to an actual baud rate of 117647. I could try fudging and maybe mass in 0x4012 and see what I get.
Kurt
Kurt
Hi Kurt,
I’m following your work 
, and as usual its very interesting!
Using the second HSERIAL on the new 3687 for maxing the speed to the SSC32 sounds very promising, especially combined with XBEE control! I hope you get it right. 
Btw, Did you write what board you used for holding the 40 pin BAP?
Keep up the good work!
ARC32 board by chance?
Alan KM6VV
I thought that was a secret…
I’ve never seen it, just heard of it… 
I was more thinking that he used a BasicATOM Universal Development Board or something like that.
Thanks Guys,
Arc32??? My lips are sealed
I am using one of there univeral boards: basicmicro.com/Product.aspx?prod … egoryID=15
I tried ordering in their web page with paypall and ran into lots of problems. Ended up faxing in the order! But am now having fun
Kurt
By ARC-32, do you mean the combination of the SSC-32 and Bot Board / Atom Pro 40 Plus that actually does the servo pulses in hardware to eliminate the serial servo control bottlenecks? Never heard of it. 
Perhaps this will help your hearing a bit…
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.