Using BB2 as serial tunnel

Hi,

I’m using my SSC in combination with a BB2 and ATOM 28 pro. Normally I drive the SSC using the BB2 but I also need to get to the SSC directly to get to the registers or GP seq. Since the SSC is below the upper deck it isn’t easy to change the wires/jumpers every time.

I saw a solution with a normal switch to change the input from the pins to the connector. I was wondering, is it also possible to do this using software. Did somebody tried to write a program for the ATOM that reads the input from the connector and sends it directly to the pins that are connected to the SSC? This way we could program some kind of SSC mode to reach the SSC registers directly.

If nobody tried this before, I was thinking of receiving and sending data byte by byte. So just have a single byte register for the serin and when i receive a byte, send into the serout. I don’t know if it is fast enough to work byte by byte but this way i’m not limited for the length of data. What do you guys think, should this work?

Xan

Hi Xan,

I have thought of doing something like this as well. I wanted to set it up to do bidirectional communications, so that for example if you are using a program on the PC like seq or the like it may want to ask for information from the SSC-32 and wait for the response. So your program would have to wait for input from either location and transfer it to the other. The problem is that if the Atom Pro is sitting on a SERIN from one of the hosts it can not be processing input from the other (unless it is using HSERIN). So I aborted that approach.

Awhile ago Nathan(AcidTech) posted he was working on maybe adding something like HASERIN (hardware assist) which for certain IO pins (probably ones with interrupts attached), you could have multiple serial communications going on that acted sort of like you had multiple HSERIN. This was all part of his “exp” beta drops. But as he has not made any new drops since March and has not posted any updates about this, I am not holding my breath…

When I was workin on making my Brat communicate with a VB program on the PC (a mini sequencer), I tried several different approaches to start the handshake. Simply putting a serin in the main loop did not produce a reliable communication. I did find that there was an interrupt tied to the IO pin associated with (S_IN, S_OUT). They are actually tied to one pin on the PRO. What I found was I could set an interrupt when the signal for S_IN dropped. I could then setup to do a normal serin. On the other side I would simply output one byte of zero (which simply gave a pulse) and then pause and then do my normal output… I had checksums and the like. Details are in a different post.

So that gave me thoughts on some approaches on how to possibly solve the bidirectional echo. At first I will avoid talking about the IO pin associated with S_IN/S_OUT as I think this may add another complexity.

  1. At the bit level. Put both Input pins on IO pins that have interrupts associated with them. Set an interrupt for when the signal goes low. When this happens you set the value of the Output pin low and then you have a couple of different approaches to try.
    1a) You set the interrupt to go to the trailing edge and continue and wait for the signal to go high again and set the Output to high… May have latency problems…

1b) You go into some hard loop that keeps testing the the level and then echoing it, until the output stays high for some length of time and then you go back to the start.

  1. Like 1) except maybe you add some smarts about know the baud rate so once you get the start condition (signal going low), you use timings to test the state of the input bit at determined times and either echo at this point or shift the bits in to build the actual byte and then output (or not) later under program control. This was the approach that I was thinking of trying at some point as you could them have some smarts on the Pro that could decide if the command was for it or to be echoed…

In general terms, I think I could get approach 2) to work. However I was concerned about the complexity added with the main serial input on the pro S_IN and S_OUT are actually the same IO pin, with diodes… This causes automatic echos of inputs and the like, which I am afraid will get in the way. There may be ways around this, but I have not spent the time to find out. Now if you only need one way communication it might not be hard, but my guess is you wish to each programs like SEQ and I know it does do some querrys to get the version and the like…

Sorry about rambling on here.

Kurt

Hi Kurt,

It sounds like t is a little bit harder as I expected it to be. :confused: I thought about waiting for a byte on the S_IN and just sending that byte to a specified pin. I didn’t think about bidirectional serial data. If I want to do this the program needs to wait for both inputs. And I don’t know if the program is fast enough to handle a couple of bytes coming at once. It sure would come in handy if it should work!

I think that I’m gone spend some time to see if I can come up with something.

Thanks for the reaction.

Xan

Hi Kurt,

It’s been a while since we’ve spoke about this but I’ve got something that is starting to look like it. I’ve build a small program that can be used as serial tunnel but it still got some bugs. I don’t know if it is possible to fix them but maybe you’ve got a good idea about this.

MyStr var byte

ENABLEHSERIAL
SETHSERIAL H38400, H8DATABITS, HNOPARITY, H1STOPBITS

'HSEROUT [22,12,"STR MyStr"] ' Sends data to Pin 15 by default 


MAIN:
HSERIN 1, NoData, [STR MyStr\1] ' Gets data from Pin 14 by default 
'sound P9, [50\4000]
SEROUT S_OUT, I38400, [STR MyStr\1]
Goto MAIN
 
NoData: 
'sound P9, [50\4000]
SERIN S_IN, I38400, [STR MyStr\1] ' Might wait forever, unless you put in timeout... 

HSEROUT [STR MyStr\1] ' Sends data to Pin 15 by default 

GOTO MAIN

I think that my setup is familiar but I’ll here is a little fresh up :wink: Something about the setup, I’ve got a SSC connected to P14 and P15 of the ABB2 with a 28pro. I want to drive or R/W the registers of the SSC by connecting my PC to the S_IN/S_OUT of the ABB2. This is only for programming the SSC.

Bug 1: It is possible to send one byte at the time and pass it trough the ABB to the SSC. Since it will handle every single byte it can’t send a pass a whole string at once. This isn’t a problem while programming the SSC while using a terminal because it can easy hold up to my typing speed :wink: But connecting to programs like lynxterm doesn’t work.

Bug 2: Bi-directional communication is possible but only after sending a additional char. For example: “R0â€

Hi Xan,

I will give this more thought later. I don’t have much time this morning as our excavator will be here to move lots of dirt probably within the hour.

But one thing I was thinking is it would be a lot easier if we did not have to depend on S_IN and S_OUT as their diode processing makes it a bit harder to handle. However with some of the stuff I learned earlier on using INT0 it might be possible. Another approach may be to use the serial adapter on the SSC32 and max232 on it and connect P14 and P15 of the BB2 to it and as such you have a proper serial port that you can talk to the PC with that has hardware support… But more on this later.

Kurt

You might be able to use the parameters to serin to read in a string and terminate on some known input character such as CR. But I don’t know if this will solve anything.

Excavator, painters, finish carpenters, tile guy, hydroseeder!?!? Damn! You’re really building a gigantic bot!! :wink:

Bug 1:

I think that building something like this should do the job. I tried this, when I just started robotics, but I couldn’t get it to work at that moment. I should give it another try since I’ve learned a lot of new thing since then :wink:

Bug 2:

Well, when I tried the program it looks like it is waiting on the line where it reads the input from the PC. So I think that adding something like a timeout would do the job. What do you think?

This makes perfect sense to me and I did tried this but couldn’t get it to work. I made a really small loop that made the SSC output equivalent to the PC input and the PC output equivalent to the SSC input. It didn’t work but I haven’t got a idea why not. I really need to get myself a scope or logic analyser so I can check what is going on… But you may get it to work though!

Thanks for your time and advice! You’ve inspired me to try some new thing. I’ll keep you informed! :smiley:

Xan

While waiting for some XBee communication modules to arrive, I thought I would start playing with this as I would like to rezero out all of the servos on my CHR-3 hex and don’t want to have to dig in to get to the SSC-32 serial connections (Lazy).

Longer term I want to add on an Xbee (or Xbee pro) onto my Hex and do a DIY remote control with either a PS2 controller to start or RC controller parts i nthe controller and talk to the robot or robots using the XBee link. But for the short term I had a Bluetooth module sitting around and for the first time I was able to get Vista to talk to it… So right now I am in the process of two different approaches to make this work.

Approach 1: try to user serin to read in the commands from the BT (or later xbee) and then reissue them back to the SSC-32. I have the beginnings of code that try to understand enough of the codes to know when it should expect stuff back from the SSC-32 (things like the Q command). I have the beginnings of this semi-limping along. That is I can use SSC32 term to connect through the BT to my robot and issue a simple command like: #0p1500 I think works. The problem is if you do something like click on all 1500, I think it outputs the command as 4 different commands: 1 for each bank. So while you are processing the first line and echoing it to the SSC-32, you miss some or all of the next command… Also I don’t think I am getting the results back yet from the SSC-32. Will play more here…

The simple code looks something like:

[code]
; Constants
BT_IN con P8 ; which pin is the input from the bluetooth connected to
BT_OUT con P9 ; which IO pin is the output to the bluetooth
BT_BAUTE con i38400 ; what is the baud rate

SSC_OUT con P11 ;Output pin for (SSC32 RX) on BotBoard (Yellow)
SSC_IN con P10 ;Input pin for (SSC32 TX) on BotBoard (Blue)
SSC_BAUTE con i38400 ;SSC32 Baute rate

BTBUFSIZE con 256 ; Our buffer

SSCCMDTBL bytetable |
3,“QPL”,4,|
3,“VER”,0xff,|
2,“QP”,1,|
1,“Q”,1,|
0

;=================================================================================================================
; Variables
bBuff var byte(BTBUFSIZE)
bStrlen var byte
bBytesRet var byte

;=================================================================================================================
; Code to ask for input from the PC and echo it off to the SSC-32 card and if necessary wait for a reply from the SSC-32
; and echo that back to the pc.
main:
bBuff = rep 0\BTBUFSIZE ; since the serin may not return anything like how many characters it received we prefill so can find null
serin BT_IN, BT_BAUTE, [str bBuff\BTBUFSIZE\13]
bBytesRet = 0 ; Don’t expect anything to return.
; Before we send it off to the SSC32, we may first want to look at the command to see if it might produce an output that we need to wait for.
mov.l #BBUFF:24, er0 ; lets scan to find the first zero
mov.b @er0, r1l ; Save away the first for quick checking of do we think we will have stuff returned to us from the SSC32
_NOTZERO:
mov.b @er0+,r1h ; load the next byte into R1L
bne #_NOTZERO:8 ; it is not zero try next byte
sub.l #BBUFF:24, er0 ; figure out our size
dec.b r0l
mov.b r0l, @BSTRLEN ; save away the string length

; quick check to see if the first character is a #.  If so echo the whole line out to ssc-32
cmp.b	#'#', r1l				; ok check for normal output line
beq		#OUTPUT_TO_SSC:16

; Can we figure out which command we have, for now it is Quick and dirty table is in command length order...
mov.l	#SSCCMDTBL, er1			; Ok we point to the start of the command table
xor.l	er2, er2				; zero out the whole R2 register.

_FCMD_LOOP:
mov.b @er1+, r2l ; get the length of the next command.
beq @OUTPUT_TO_SSC:8 ; command not in our list, so jump off to the output function
mov.l #BBUFF:24, er0 ; point to the start of our buffer

_FCMD_NCHR:
mov.b @er0+, r3h ; get the next byte of the command buffer
and.b #0xdf, r3h ; Hack to make any lower case character into an upper character
mov.b @er1+, r3l ; get the next byte out command table
cmp.b r3h, r3l
bne @_FCMP_NE:8 ; not equal

; the bytes are equal, decrement the count and see if we are done.
dec.b	r2l						; 
bne		_FCMD_NCHR				; not done yet

; we matched all that was passed. should maybe do some more validating but, what the heck
mov.b	@er1, r3l				; get the next byte out command table which is the number of bytes we expect to return
mov.b	r3l, @BBYTESRET:16		; save away into the bytes to return variable
bra		#OUTPUT_TO_SSC:8		; and go do it.

; when the characters don't match, align up to the next command

_FCMP_NE:
add.l er2, er1 ; point to the next command in the table
bra #_FCMD_LOOP:8 ; go try to process the next loop

OUTPUT_TO_SSC:
serout s_out, i9600, [dec bBytesRet, “-”, str bBuff\bStrlen, 13]

serout SSC_OUT, SSC_BAUTE, [str bBuff\bStrlen, 13]		; Ok lets quickly write the command out to the SSC-32

; First a simple check if it starts with a # it will have no return so go directly to the output function
if bBytesRet = 0 then 
	goto main		; Dont expect anything so go back to get the next line
else 
	; Ok we expect something.  if count = ff then it is a string we are expecting.
	if bBytesRet = 0xff then
		bBuff = rep 0\BTBUFSIZE								
		serin SSC_IN, SSC_BAUTE, [str bBuff\BTBUFSIZE\13]

		mov.l	#BBUFF:24, er0			; lets scan to find the first zero

_NOTZERO2:
mov.b @er0+,r1h ; load the next byte into R1L
bne #_NOTZERO2:8 ; it is not zero try next byte
dec.l #1,er0 ; get back to the NULL character
mov.b #13, r1h
mov.b r1h, @er0 ; put a CR back into the end of the buffer and increment
sub.l #BBUFF:24, er0 ; figure out our size
inc.b r0l
mov.b r0l, @BBYTESRET ; save away the string length

	else
		serin SSC_IN, SSC_BAUTE, [str bBuff\bBytesRet]
	endif
	
	; Now lets return the returned infor back to the PC
	serout BT_OUT, BT_BAUTE, [str bBuff\bBytesRet]
endif

goto main[/code]

Somethings I might try to fix this approach include:

  1. Maybe continue to do reads with a timeout and buffer up all of the commands in a run before issuing them. This might work, but will probably not make using the slider in SSC term as smooth.

  2. Try to move the pins around and use part of the hardware serial port for the BT(in) and part for the SSC-32(out). This might work but would conflict on using the PS2 controller on the BB2. Again for my case this may work OK as I plan to move the controller off of the BOT anyway…

Approach 2: A simple echo at the bit level. What I am trying to do is to simply take whatever the state of the input pin for BT and put this as the output state for SSC-32 and likewise take the input state of SSC-32 and put it as the output state of the BT. So far I have not had any luck with getting the communication going. Maybe I need to pull some signals high or low, will try to debug later. The code looks something like:

[code] Constants
BT_IN con p8 ; which pin is the input from the bluetooth connected to (P80)
BT_OUT con p9 ; which IO pin is the output to the bluetooth (P81)
BT_BAUTE con i38400 ; what is the baud rate

SSC_IN con p10 ;Input pin for (SSC32 TX) on BotBoard (Blue) (P82)
SSC_OUT con p11 ;Output pin for (SSC32 RX) on BotBoard (Yellow) (P83)
SSC_BAUTE con i38400 ;SSC32 Baute rate

; Define some debug LED pins. Normally on P12-P14 on BB2, but jumpered to P4-p6
;
LED1 con p4 ; (P54)
LED2 con p5 ; (P55)
LED3 con p6 ; (P56)

;=================================================================================================================
; Variables

b var bit

;=================================================================================================================
;Initialization code
input p8
output p9
output p11
input p10
output p4
output p5
output p6

high	p4
high	p5
low		p6

;=================================================================================================================
; Code to ask for input from the PC and echo it off to the SSC-32 card and if necessary wait for a reply from the SSC-32
; and echo that back to the pc.
main:
b = in8
out11 = b
out4 = b

b = in10
out9 = b
out5 = b

#ifdef DOINASSEMBLY
; assembly init the IO ports again
bclr.b #0,@PCR8:8 ; set BT_IN to input
bset.b #1,@PCR8:8 ; set BT_OUT to output
bclr.b #2,@PCR8:8 ; SET SSC_IN to input
bset.b #3,@PCR8:8 ; set SSC_OUT to output

bset.b	#4,@PCR5:8		; Set LED1 to output
bset.b	#5,@PCR5:8	
bset.b	#6,@PCR5:8

_MAINLOOP
bld.b #0,@PCR8:8 ; get the current value of BT_IN into the C bit
bst.b #3,@PCR8:8 ; And set the value into SSC_OUT
bst.b #4,@PCR5:8 ; set an LED so we get an idea if anything is happening…

bld.b	#2,@PCR8:8		; and et the current value of SSC_IN
bld.b	#1,@PCR8:8		; and set it to BT_OUT
bst.b	#5,@PCR5:8		; set an LED so we get an idea if anything is happening...
bra		@_MAINLOOP:8	; and repeat foreaver

#endif

goto main[/code]

Note in this code. I am using a BB2, but I have pulled off the jumpers in the LED/buttons area, I then took a 3 wire servo wire and connected P4-p6 to the LED side of the jumpers…

That is all for now. Will let you know if I make any more progress.

Kurt

I played around with it a little this afternoon and it appears the second approach can work. With the following code running on the Atom Pro:

[code];=================================================================================================================
; SSC32 - intercept and router program
;
; This program can be used with a bluetooth or other serial adapters to allow someone to have their Atom pro
; connected to the SSC-32, but at times allow a PC to connect to the SSC-32 to do things such as run the terminal
; or seq, or…
;
; This first attempt will be to try to do it at the bit twidling level. In order for this to work both devices
; have to be running at the same baud rate.

;=================================================================================================================
; Constants
BT_IN con p8 ; which pin is the input from the bluetooth connected to (P80)
BT_OUT con p9 ; which IO pin is the output to the bluetooth (P81)
BT_BAUTE con i38400 ; what is the baud rate

SSC_IN con p10 ;Input pin for (SSC32 TX) on BotBoard (Blue) (P82)
SSC_OUT con p11 ;Output pin for (SSC32 RX) on BotBoard (Yellow) (P83)
SSC_BAUTE con i38400 ;SSC32 Baute rate

; Define some debug LED pins. Normally on P12-P14 on BB2, but jumpered to P4-p6
;
LED1 con p4 ; (P54)
LED2 con p5 ; (P55)
LED3 con p6 ; (P56)

;=================================================================================================================
; Variables

b var byte

;=================================================================================================================
;Initialization code
input p8
output p9
input p10
output p11
output p4
output p5
output p6

high	p4
high	p5
low		p6

;=================================================================================================================
; Code to ask for input from the PC and echo it off to the SSC-32 card and if necessary wait for a reply from the SSC-32
; and echo that back to the pc.
main:
; assembly init the IO ports again

bclr.b	#0,@PCR8		; makd sure  BT_IN to input 
bset.b	#1,@PCR8		; set BT_OUT to output
bclr.b	#2,@PCR8		; SET SSC_IN to input
bset.b	#3,@PCR8		; set SSC_OUT to output

bset.b	#4,@PCR5		; Set LED1 to output
bset.b	#5,@PCR5	
bset.b	#6,@PCR5
mov.w	#0, r0			; Quick and dirty count down to flash the led...

;
; simply loop copying the input bits to the output bit.
_MAINLOOP:
bld.b #0,@PDR8:8 ; get the current value of BT_IN into the C bit
bst.b #3,@PDR8:8 ; And set the value into SSC_OUT
bst.b #4,@PDR5:8 ; set an LED so we get an idea if anything is happening…

bld.b	#2,@PDR8:8		; and et the current value of SSC_IN
bst.b	#1,@PDR8:8		; and set it to BT_OUT
bst.b	#5,@PDR5:8		; set an LED so we get an idea if anything is happening...
dec.w	#1,r0
bne		#_MAINLOOP:8
bnot.b	#6,@PDR5:8		; and change the state of P6

bra		@_MAINLOOP:8	; and repeat foreaver

[/code]
With the BT module plugged into P8 and P9 and the SSC plugged into P10 and P11, I was able to have this code running on the Atom Pro and run SEG on my PC, which properly connected to the SSC-32 through the Atom, showing the proper version and the like and then doing a command like ALL 1500 worked as well as moving the sliders made the appropriate servo work.

Note the code also assumes you have jumpers from P4-P6 to P12-P14 for the LEDS and shows the input states for the two Input pins on P4 and P5 and blinks P6 to let you know it is doing something.

Now the fun would be to integrate it into the phoenix code (or in my case modified version for CHR-3), such that I could trigger this and use PEP or SEG to try out new sequences without having to do hardware mods…

Kurt

Hi Kurt,

Didn’t had time to try it out but it sounds great! It looks like the “low-levelâ€

I was thinking of trying to integegrate it in much the same way, except that I was probably going to add code to exit when the same button was pressed again.

As for S_IN and S_OUT, getting to the low level is probably not much of an issue. They are on the RENESAS IO pin 14 which is also IRQ0. The problem is that they are both on the same IO pin with a diode circuit connecting them so the input is replicated on the output. Going one direction would probably be easy, going bidirectional may be a little more fun. Maybe I will try a hack later that assumes the majority of the input comes from the S_IN to the SSC-32 and stay in that mode until something actually changes on the SSC-32 output side in which case you try to echo it back… Just seemed to be easier to work it with the Bluetooth and later with the XBEE.

I actually enjoy working at the low level here. This processor is pretty nice to work with as you have 32 bit registers. I enjoy working on the Atmega as well, but it only has 8 bit registers, so something as simple as incrementing a 32 bit number takes more work (Inc, add with carry, …)

Kurt