Yes the Shield is up to the task, especially if you still have the SSC-32. It has 256KB of memory which is very nice. It also has 4 USARTS, which again is real real nice. That is you have one for debug(USB), one for XBee, one for SSC-32 and a reserve one for things like Serial display… Arduino runs at 16mhz even though the underlying Atmega can run at 20mhz like the Arc32. The Arc32 with it’s 32 bit processor probably has a bit more horsepower, but I am not sure that is an issue. Especially since the Atmegas have more and I believe faster interrupts… Also since we are compiling our code versus running on an interpreter I am not sure if it does have more cpu power…
Now about Seeeduino Mega with Botboarduino Mega Shield : Yes the code is setup for it. Or at least was. Also since in the last couple of days Arduino has released it’s first official release (1.0), I am now converting all of the code I posted yesterday to this release. Luckily the phoenix code was already updated by another member yesterday 
.
As for Cost, I am not sure which is cheaper: The mega with shield and SSC-32 or Arc32. Obviously if we add SSC-32 to Arc32, than that cost will be higher.
Now if we go with Arc32, I am on the fence on with or without SSC-32, now talking about your points.
1-2) Interrupt issues/kiss - Personally I am not sure which way is this.
a) with - Yes offload the servo work which is good. Nathan says the Servo support adds about 1-2% usage of Arc32
b) without - Use Serial output. Now if we are using XBees either Xbee or SSC-32 can be on hardware serial port, but not both. Assume SSC-32 is using bitbang. Have to use support to turn off interrupts from controller while we are doing our serial outputs to SSC-32. Also since bitbanging we are holding up the processor during the output of the characters…
-
I have ported the code to a few different platforms already, again abstracting out the servo controller, allows us to go either way. I am currently in the background also trying to get this code to run on an Uno32 by Digilent. It uses a Pic32 running at 80mhz, 2 usarts with form factor of Arduino. They also make a Mega32 with the same form factor as Arduino Mega, too bad they don’t make it in the Seeeduino Mega form factor as this would really kick… But that is a different subject.
-
Delays: With SSC-32 when your foot sensor detects something it has to send some serial data to the SSC-32 to tell it to stop and then some more characters to ask where it is and wait for the data to come back… Again assuming my earlier ideas of guesstimating by time did not work. Without the SSC-32, you can get the current positions, which simply reads a few memory locations…
Note: As I mentioned the current code does not support the Arc32 (or Bap40 or Bap64) with SSC-32. Used to: but was removed to get rid of #ifdef. In particular the following from the phoenix_drivers_ssc32.bas would need to be conditional:
[code];--------------------------------------------------------------------
;[TIMER INTERRUPT INIT]
TIMERINT con TIMERAINT
ONASMINTERRUPT TIMERAINT, HANDLE_TIMERA_ASM
;--------------------------------------------------------------------
;[InitServoDriver] - Initializes the servo driver including the main timer used in the phoenix code
InitTimer:
;Timer
; Timer A init, used for timing of messages and some times for timing code…
TIMERINT con TIMERAINT
WTIMERTICSPERMSMUL con 64 ; BAP28 is 16mhz need a multiplyer and divider to make the conversion with /8192
WTIMERTICSPERMSDIV con 125 ;
TMA = 0 ; clock / 8192 ; Low resolution clock - used for timeouts…
ENABLE TIMERINT
return
;==============================================================================
;[Handle_Timer_asm] - Handle timer A overflow 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.l er1 ; first save away ER1 as we will mess with it.
bclr #6,@IRR1:8 ; clear the cooresponding bit in the interrupt pending mask
mov.l @LTIMERCNT:16,er1 ; Add 256 to our counter
add.l #256,er1
mov.l er1, @LTIMERCNT:16
pop.l er1
rte
ENDASMSUB
return ; Put a basic statement before…
;==============================================================================
;[GetCurrentTime] - 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.
;==============================================================================
GetCurrentTime:
lCurrentTime = lTimerCnt + TCA
; handle wrap
if lTimerCnt <> (lCurrentTime & 0xffffff00) then
lCurrentTime = lTimerCnt + TCA
endif
return lCurrentTime
[/code]
Real simple changes, with things like TCA ->TCB1, needing to slightly change the itnerrupt to make sure the right interrupt bit is cleared and change the constants for conversions from ticks to MS and which interrupt ias assigned to TIMERINT…
So again no big deal and the changes are burred where most users don’t need to worry about. They simply need to call GetCurrentTime…
So I will let you make the call.
Looks like we’ve pushed the BAP28 to it’s limits with the current Phoenix code 
The mega would do an awesome job. But for now the only hardware I can supply will be Atom Pro or BBduino. Just days away from BBduino.
… (
