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
)
, and as usual its very interesting!
