Converting from a BAP28 to a BAP40

Another of my random projects :laughing:

Now that Basic Micro has the BAP40 for sale and they sell a few boards that they plug into, I thought I would give one a try to see what all I need to change to make it work on one of my robots. I thought also since Basic Micro does not currently have a spec sheet out for this big guy I would post some of the information I have found. FYI - I purchased one of their Lab boards to do this.

First here is the pin out for the BAP 40, this came from Nathan (AcidTech):

[code]Pro40 pin outs are:

P0(P50/WKP0)<->(PB0/AN0)
P1(P51/WKP1)<->(PB1/AN1)
P2(P52/WKP2)<->(PB2/AN2)
P3(P53/WKP3)<->(PB3/AN3)
P4(P54/WKP4)
P5(P55/WKP5/ADTRG)
P6(P56/SDA)<->(P86 on RevD)
P7(P57/SCL)<->(P85 on RevD)
P8(P60/FTIOA0)
P9(P61/FTIOB0)<->(P74/TMRIV)
P10(P62/FTIOC0)
P11(P63/FTIOD0)
P12(P64/FTIOA1)
P13(P65/FTIOB1)<->(P70/SCK3_2)
P14(P66/FTIOC1)<->(P71/RXD_2)
P15(P67/FTIOD1)<->(P72/TXD_2)
P16(P30)
P17(P31)
P18(P32)
P19(P33)
P20(P34)
P21(P35)
P22(P36)
P23(P37)
P24(P10/TMOW)
P25(P11/PWM)
P26(P12)
P27(P23)
P28/AX0(P14/IRQ0)<->(PB7/AN7)
P29/AX1(P15/IRQ1/TMIB1)<->(PB6/AN6)
P30/AX2(P16/IRQ2)<->(PB5/AN5)
P31/AX3(P17/IRQ3/TRGV)<->(PB4/AN4)
Thats as close to 4 8bit ports as it is possible to get on the H8-3687. Also S_IN and S_OUT are TXD and RXD.
[/code]

An earlier question I had was where the AX0-3 pins were in relation to the Pin numbers as well as how the other pins were added.

While the Bap28 is currently based on the H8/3694 processor, the Bap40 is based on the H8/3687 and as such there are some differences I will have to take into account when I try converting the code to run on it.

Some of these include:

The Bap40 runs at 20mhz instead of 16mhz, so timing loops need to change. Also some commands like HSERVO are impacted on it. That is the value you pass to HSERVO will change as this value directly relates to the processor speed. For most of our programs this should be easy as we will simply need to change a constant for a modifier between degrees and the HServo value.

HSerial: the good news is this chip has two hardware serial ports. The main HSERIAL is now on S_IN and S_OUT. The second one is on P14 and P15. So if you use hserial on these pins will need to change to hserial2.
Edit:

Analog pins: As Nathan mentioned AX0-3 are now P28-P31

Interrupts: If you are using interrupts like IRQ2, the physical pin numbers has changed.

Timers: If you are using any of the timers, this will probably impact your code. That is the BAP28 has timers: A(8), V(8), W(16) and the BAP40 has timers: B1(8), V(8), Z(2 channels of 16). Hservo on Bap28 uses W timer and on Bap40 I believe uses Channel 0 of Z timer.

Edit: The H8 the Bap40 uses has the capabilities of a Real Time Clock, but this would require an external 32.768khz crystal. Without the Crystal the RTC can be used as another 8 bit timer.

…

It would be nice to be able to have code that conditionally compiles for both chips. I think I may have found a way. That is we can test for the existence of one of the defines for system variables for each platform. Something like:

[code]#ifdef TCNT
; BAP28
ONASMINTERRUPT TIMERWINT, HANDLE_TIMERW_ASM

TCRW = 0x30 ; Set the counter to clock/8 which is the slowest we can set it
TMRW = 0x80 ; Start timer
enable TIMERWINT_OVF
#else
;BAP40
ONASMINTERRUPT TIMERZ1INT, HANDLE_TIMERZ_ASM
; set the appropriate values
TCR_1 = 0x3 ; clock divided by 8
TSTR.bit1 = 1 ; start clock 1
TCNT_1 = 0 ; initialize to zero
enable TIMERZ1INT_OVF
#endif
[/code]

So I may try hosting this board on one of the robots, either Rover or CHR-3 and see if I can get it up and running or at least walking or driving… May take awhile as I have more projects than time.

Edited: 10/13 Added in more information about HSERIAL and RTC

Kurt

Made it a sticky for ya!

Thanks :slight_smile:

So far I have a Lynxmotion PS2 running on the board. My other tried and true PS2 controller from Sector 7 is a bit flaky on the Bap40. I think it has to do with speed of the clock signal, which is running at 400khz on both processors, but there is a slight difference in the wave forms…

I have updated the code for the phoenix 1.3 to try it on the CHR-3. Just need to rig up some battery cable and change the leg dimensions for the CHR and give it a try…

Kurt

Quick Update:
I edited the first post to put information in, such that S_IN and S_OUT are internally on two different IO pins and as such full duplex. So you have full use of HSERIAL here. Likewise notes on Real time clock (RTC)

Also yesterday, I did hack up a battery connector such that I could plug the N type connector into the Lab board and then a hooked up a power cable from there to the logic portion of the SSC-32. I then downloaded the a fresh copy of phoenix 1.3, changed the timer, changed the dimension information to use with my CHR-3, changed some sbytes to swords and downloaded it to the BAP40, which I have hooked up to the SSC-32 on the hex and I had it walking! :slight_smile:

Kurt

Awesome! 8)

SER_IN and SER_OUT are taken over by HSERIAL? Interesting.

Good work on ferreting out the details of the 40-pin chip!

ā€œType Nā€ connector? Must not be my RF connector!

Alan KM6VV

Hi Alan,

The Type N Coaxial DC Power Plug from Radio Shack (274-1573) appeared to be close if not the same as the power plug that I had on the Wall Wart from Lynxmotion, which plugs into the board. I do need to tighten up the connection as when the hex walks it sometimes shakes free. I will probably start off with a wire zip… to hold it in place…

Yep having fun playing with this as well as the DIY remote/Mech Brat. But now off to changing oil in the tractor…

Kurt

Hi Kurt,

I can see you’re having fun here. :smiley:

You’ve noticed that the BAP40 runs on a different frequency. Now the first question popped up in my mind was: Is it possible to drive the SSC at full speed (115.2) using the serout command?

I know it’s possible with the HSEROUT command but it’s innterrupt driven and can give some problems in other commands like we found out in the DIY RC project.

Thanks,

Xan

Hi Xan,

Yep, having fun. I am splitting my Robot time between this and the XBee stuff with the DIY. I have a bunch coded now for the DIY, including setting the destination address and the Remote address (to handle multiple people with DIY in the same area). Also coded the ability to only send information when it changes, still need a little on the robot side to handle it. But now is time to start testing/debugging it… But that is a different thread.

I can give it a try! :smiley: We already have a timer interrupt in the phoenix code that you use to keep from outputing a new SSC command until the last one had a chance to complete. Currently I did a straight conversion from using W timer to using Z channel 1, which we still generate timer interrupts. I was thinking of maybe converting this to use a different timer either B1 or the RTC. With these two you can set the increment to be as slow as system clock/8192. So if the slowest move that we wish to time is lets say .2 seconds, then that would take a counter that goes up to: Clock * .2 / 8192 or
20,000,000 * .2 / 8192 = 488+ or lets say 489, which can fit into the 8 bit timer as you can use the overflow flag as a 9th bit.

I hope that makes sense
Kurt

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 :slight_smile:

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 :slight_smile: )

...
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
	return

Notes 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 :laughing:)

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 :wink:, 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. :smiley:

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… :wink:
I’ve never seen it, just heard of it… :smiling_imp:

I was more thinking that he used a BasicATOM Universal Development Board or something like that.

Thanks Guys,

Arc32??? My lips are sealed :wink:

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. :blush:

Perhaps this will help your hearing a bit…

bribe.jpg