Pass-through commands for SSC-32 in Atom Basic code

Lynxmotion Legged Robots
1

In getting my new quadruped robot re-assembled and the legs adjusted, I first use PowerPod to align the servos at the 1500 position and then assemble. I then go on to connect to the Basic Atom.

Not all my servos could be mounted at this point, and I make changes in the “neutral” positions. So I find myself needing to go back and forth between the Basic Atom and directly to the SSC-32.

I have an idea that if the Basic Atom code had a “pass-through” command, i.e., could be sent raw SSC-32 commands via the com from the PowerPod and Sequencer programs, then I could talk directly to the SSC-32, without having to re-cable.

A few things would be needed:

Two-way coms between the SSC-32 and the Basic Atom pro (currently there is only a TX line out of the Basic Atom into the SSC-32.) Maybe this isn’t necessary.

Code for the Basic Atom to copy variable-length commands sent from the PowerPod and forward them to the SSC-32.

The PowerPod and Sequencer programs both require the SSC-32 to respond to the VER (or something similar) command with an appropriate response before being “connected”. This mechanism would probably have to be duplicated in order for either program to be enticed into talking to the Basic Atom program.

Although it would be convenient to just “add-in” this code to a hexapod (or 'quad!) program, It would be simpler to implement the function as a separate program.

Upon first thinking, this should be a simple program in BASIC, however I am finding out that Atom Basic is practically devoid of all the rich string handling functions in (ANSI) BASIC. Probably the only commands really needed are the ones to determine string length, and do a simple match of strings. These can be written out in Basic.

I tried a few lines of code:

	buff var Byte(20)

	buff = "test"
	serout S_OUT,i9600,[str buff\4,cr]  ; worked to get the string out.

Loop
	serin S_OUT,i9600, [str buff\4\cr]  ; try just 4 characters
	
; Character by character xfer
;
;	serin S_OUT,i9600, 200000,NoData, [echo]
;	serout S_OUT,i9600,[echo]
;
;	buff(i) = echo
;	i = i + 1
;	
;	if echo = cr or i = 18 then 
;	i = 0
;
	serout S_OUT,i9600,[str buff\4,cr]  ; try just sending 4 characters
;	endif
	
NoData
	goto Loop

Wasn’t too successful! And the “str” modifier isn’t extensively documented in either of the MBasic or Atom Pro manuals I had available to check (I’m compiling code on the 'pro).

I commented out the char by char read, didn’t get anywhere with it either.

The serin “str” command didn’t seem to work, possibly crashing and causing a re-boot, which would be a symptom of writing too many characters into a buffer. One would think the \4 and the \cr modifiers would prevent that.

I’ll probably take this over to the Basic Micro forum to get more information on the command and it’s modifiers when I get some time.

I’m interested in hearing if anyone has successfully used these modifiers, or if there is any interest in a program like this to allow a simple pass through.

I’ve successfully implemented a parser in C for the SSC-32 VER and some other commands that went into Loki, so I have the algorithms needed. But would it be worth it for this application?

I’d like to hear any comments or this or any similar program (module?) that might exist. Surely someone has done this already!

Alan KM6VV

2

I tried playing around with this on a BAP awhile ago. I tried some stuff, but was not completely sucessful.

I tried a couple of different approaches. The obvious first approach for BAP->SSC-32 communication should be able to work something like:

    buff var byte(128)

Loop:
    serin S_IN, i9600, [str\buff\128\cr]
    serout SSC_PORT, SSC_BAUD, [str\buf\128\cr, cr]
    goto main[/code]

I have not tried this approach in awhile.  I had some conversations with Nathan on usage of STR and I believe the new Basic Micro Studio behaviour is different than before.  That is now when you use the terminator character on input, the character is transfered to the input buffer and on output the termination cr is not output.   This was before I had a problem that when you used the termination character on input nothing was transfered for the termination character and so it was difficult to know what exactly was input.  Example problem was if first I got the command QP, the first two bytes in buff were updated to QP.  Then if the next command was Q, only the first byte was updated, so the first two characters were still QP.  To fix this I ended up having to zero the array...

There are problems with the simple approach.  For example, if you are outputing a complex move for all 18 servos of a hex, then your command may exceed 128 characters.  If this happens you will catch the first 128 characters and output them, but output a CR as well which in this case was not correct.  Also while you are dumping those characters to the SSC-32, any additional characters that were being sent by the PC will end up on the floor as you are not in the bit bang read serin read function to receive them.

You might be able to get around this as long as you can create a large enough buffer.

Now to work with something like powerpod or SEQ, I think you will need bidirectional communication.  My early attempt (which I don't know if I still have somewhere).  I then tried to expand on the like code above and looked at the first several bytes of a command line to see if it is some form of query and if it was, then wait for the response back from the SSC-32.  There are some complications of knowing how many characters might be returned.  Q->1, QP->?, VER->?...

The next approach I played with was trying to simply replacate The io states of the Input pins to the Output pins.  That is if S_IN part changed state then echo this state change on SSC_OUT, and if SSC_IN port changed then try to echo it back on S_OUT.  The code looked like this in assembly language:
[code]=================================================================================================================
; 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

This still was not working. I wondered what impact that the hardware of the BAP S_IN/S_OUT going to the same IO port on the underlying structure through the diodes was making. But then I started working on the DIY transmiter/receiver code and have not gotten back around to playing with it… If I get back to it, I might try hooking up the BAP with an external MAX232 or maybe a bluetooth to some other pins such that the S_IN/S_OUT circuitry was not impacting it to see if it had a chance to work or not. Looking at the code above I think that was the state I had left it in.

Not sure if this helped or not, but that is some of the things I tried.

Kurt

3

Hi Kurt,

A bigger buffer worked? Otherwise, it looked like I had the syntax correct. I hadn’t thought about directly bit-banging.

The cr handling is a little different, but I can work around that. I was thinking the BB2 could watch for the VER and respond to it directly, no need to get it from the SSC-32. I really didn’t want to write a full parser in BASIC, just enough to get the PC program talking to the BB2.

I hadn’t thought about the fact that they are sharing the IO pin. But buffering should handle that.

Thanks for the ideas.

Alan KM6VV

4

A cheap and simple hardware solution to your problem (may not be as elegant as a BB2 repeater software) is this:

I bought a few DB9 connectors for ribbon type cable (the ones where you squeeze the two halves together to crimp onto the ribbon).

I then bought some 9-pin ribbon cables and just cabled out my DB9s off of the BB2.

I figure that this same approach will work for your DB9 off of the SSC-32.

My drive to do this was for two reasons:

  1. Extends out the connector to an accessible location

  2. Prevents me from wearing out the DB9s (or possibly eventually ripping it out) by interfacing to the extended connector instead of the actual connector on either boards…

This was done on the Phoenix (as well as the CH3-R before the Phoenix) because the DB9 was hard to get to being “inside” the body cavity of the hexapods…

I’m currently in the process of restoring my CH3-R, I think I’m going to buy some ribbon-type DB9s and another roll of 9-pin ribbons soon…

Oh yeah, it sometimes helps to assemble a backshell to your extended DB9 so you can easily grab it. My fingers are starting to hurt from trying to separate it everytime I flash my BAP28 and testing out my code…

5

Hi Tom,

Thanks for the suggestions! I did some thinking along those lines as well. I was even considering adding a few more wires to the configuration pins so that the TTL level signals could be brought out to a switch as well. Not much room in my small 'quad body either! I’ll be lucky if I can get just the connector shell in without its housing. I have a lot of cable stuff, so the task shouldn’t be hard, I just didn’t have any of it with me on vacation!

Alan KM6VV

6

Sorry about reviving a sort-of older thread, but I have been playing around with idea of being able to download commands/sequences from the PC to my hex without having to change the hardware. Also since I have developed the XBEE DIY remote code, I thought I would try again.

This morning I have finally had some sucess with this. So far it is only to my test board connected to a spare SSC-32 and an extra XBEE… As well as an XBEE that is plugged into a USB port on my PC (using the sparkfun USB board). Both XBEES are currently talking at 9600 baud.

Currently my test program on the BAP initializes things and waits in a loop for input from the XBEE using flow control. I am using my own assembly language version of SERIN which I added optional End of Line character support as well as support to handle how the XBEE will send a couple of extra characters after you raise the flow control signal. I am also using my own serial input/output functions to talk to the SSC-32 at a baud rate 115200.

Using these functions makes it work reasonably well as the XBEE will buffer stuff up while I am talking to the SSC-32. So the main loop looks pretty simple:

[code]main:
; pretty simple loop, try reading in a line of characters and dump it out to the SSC-32, may need to fix our flow control to handle case where
; first character buffered is a cr as we may miss next character…
gosub TASerin[cXBEE_IN, CXBEE_RTS, cXBEE_BAUD, @bBuf, BBUFFLEN, 2000, 13], cb ; check TASerin to allow timeout to change after first char…
if cb > 0 then
gosub TASerout[cSSC_OUT, cSSC_BAUD, @bBuf, cb] ; output the bytes we received from the XBEE to the SSC

	' see if the last character was a cr
	if bBuf(cb-1) = 13 then
		gosub TASerin[cSSC_IN, 0, cSSC_BAUD, @bBufAck, BBUFFLEN, 10000, 13], cb
		if cb > 0 then
			gosub TASerout [cXBEE_OUT, cXBEE_BAUD, @bBufAck, cb]
		endif
	endif
endif
goto main

[/code]

With this I had my test VB app on the PC output the Ver command and if it received anything back it would print it in the test window. Well I am now properly printing out my SSC-version. I then ran Lynxterm and was able to enter commands. I also clicked All=1500 and through the logic analyzer verified that the command did get out to the SSC-32. I also then clicked on the firmware button and it did show: SSC32-V2.04GP and that it was a version 2 for the atmega 168. :smiley:

Now I am going to try to merge this back into my XBEE control for the HEX and see if I can get it to talk through SEQ and/or Excel (PEP)

Kurt

7

No problem, I’m still up!

Sounds very encouraging!

I hadn’t worked on the idea since vacation, but since I’ve got new '645 servos to swap in for the '475s, I’m going to need to do calibration again on my “Little Cat” 'quad. I’d want to run the Visual Sequencer, as well as Serial_CP_H3 (at some point). LynxTerm would also be useful!

I’d suggest making your routines workable with a simple serial cable as well. Extra points for BlueSmirf! BlueSmirf has flow control (?), theoretically it should work the same, although probably at different baud rates.

Good work!

Alan KM6VV