Serial Communication w/ Mini-ABB and vex microcontroller

Lynxmotion Electronics & Software
1

I have been trying to establish communication between a Vex micro-controller and an Atom28 (on a mini-ABB) for well over a month now.

I finally achieved serial transmission with the Vex (not as easy as one might think), and now I am beating my head against the wall on this last bit.

I am fairly new to this type of work, I have not really worked with hardware before at this level. As interesting as it is, I find myself overwhelmed by the amount of information I need to assimilate in order to figure this out.

I would appreciate any help that can be offered.

  1. I am not sure if I am connecting the two devices properly.

The pin outs from the VEX are

  1. CTS
    2)+5V
    3)RTS
    4)GND
    5)RX
    6)TX

Now, I am trying to use the DB9 port on the mini-ABB and all I’ve managed to do is get it to reset.

I started with the code generated by powerpod for serial control of a BH3-R walker. I changed the baud rate to N115200 because that is the transmission rate of the vex controller. I have had problems getting it to transmit at lower baud, but I’m sure it is possible.

On the DB9 I have :
pin 2 -> RX
pin 3 -> TX
pin 5->GND
pin 6 -> pin 7

The servos go to the neutral pose (standing position) when the Vex controller is turned on, so there is some recognition that a signal exists at the serial port. (Since it won’t do that without the vex being connected or while the vex is off.)

I am sending a string when a button is pressed, “80 FF 7F 80 80 80 80” and a carriage return.

I am not really sure where to go from here.

2

Did you generate code for a PS2 BH3-R walker or a comm version? That’s the square button PS2 code.

RX should be connected to TX and vice-versa, along with a ground. Looks like you’ve got that, and the baudrate sorted out.

Servos going to neutral has nothing to do with a signal at the serial port that I know of. This sounds like a simple start up event.

OK, you say you’re sending the string, are you SEEING the string? You can connect a terminal to the TX of the 'bot board, and use a print statement to “echo” the command (or other status) to the terminal.

If the command is recognized, then it should decode and result in the “learn to fly” ACTIVITY. The COMM version also wants a checksum in the command string sent to the 'bot.

I’d code either a beep or an LED doing something at various places in the code. As characters are received, as a command is decoded (yours), etc., one at a time to trace how far into the code you get.

HTH

Alan KM6VV

3

Thanks for the reply.

At least it would appear that I have the connection properly made. That is one less thing to have to play around with.

Is tying pin6 to pin7 on the ABB DB9 correct? If so, why? What does that do?
(you don’t have to answer that, I’m just curious).

I generated the comm version of the code, I thought it was expecting basically the same commands as the PS2 version. I’ll double check that though.

I have tried (still trying–goooo FAILURE!) just sending a simple binary value and using that to trigger an on board LED, but I have not had success with that yet.

I can see the string on HyperTerminal (or any other terminal program I tested), but I have not tried to read from the abb while the vex controller is connected. Correct me here, but would I not need a level shifter to connect to the computer’s serial port. The vex serial is at TTL levels.

I noticed the checksum in the code. What do I need to send? Is there a identifier string or something I need to send before a command?

I mean the neutral standing pose. If there is nothing connected to the pin that is being polled the initialization doesn’t occur. So when I connect the Vex (and turn it on) it will initialize, otherwise it just lays on the ground.

4

I don’t know offhand what those pins are being used for.

The command is basically the same, but with a checksum at the end. See the Atom BASIC code to determine how the checksum is calculated.

You would, but it’s VERY useful to be able to generate messages and see values in the program.

The checksum goes at the START.

80 FF 7F 80 80 80 80 0D

And ends with a CR. Oh wait, you DO have the checksum (80) at the start! Then FF and 7F are the buttons, followed by X and Y joystick values, then the CR. a COM version of the Atom BASIC code should recognize that! I send this string with my terminal program.

A COM pin? on the Vex? I don’t know about the Vex, It’s the Atom Bot board that talks to the SSC32 and controls the servos, right? The Atom board doesn’t wait for a signal (as I recall) to do anything. But then, I’ve just studied the code.

5

Ok. Update, turns out the Vex was not reliably communicating through its serial port. That issue has been resolved.

I have altered the connections between the two systems (Atom28 mini-ABB and Vex) to make use of one of the I/O pins on the ABB. That way I can read the debug data through the DB9 connection to my PC.

Yay, I am able take a signal and output it to the debug term.

Here is the part I am having trouble with.

I am sending it 8 bytes “04\FB\FF\80\80\80\80\0D”, I am using various output methods to find one that actually works. (In the example case the “” inserts a stop bit between the bytes, this seems to be giving me the most consistent results.)

When I am reading the bytes on the PC (after passing through the Atom) I am getting this

B0 93 12 8C 14 C2 B8 26 C2

---- or ----

90 93 12 8C 14 C2 B8 26 C2

Yes, that’s right OR. Sometimes it is the first one, sometimes the second.
The fact that it is consistent is good, but I still don’t know what to do to fix it, or even why the first byte varies.

I am completely lost on this one.

Additionally, I have also tried to send in two’s complemented binary which yields

A2 93 12 8C 14 C2 B8 26 C2

as you can see, only the first byte differs again.

Does that mean that only the first byte is being read and the rest is being filled with trash or something?

6

OK, you can send data from the ABB to the PC?

You are sending from what to what? From the vex to the ABB I’ll assume. Are you using standard com ports at the same baud rate and number of stop bits etc. on both ends?

Are you processing the data in the ABB? Simply doing an “echo” on the ABB in/out of the com port should be tested.

Then expand the loop, send data from the vex into the ABB and back out to the PC. Initially you’ll need all three operating at the same baud rate, etc.

That could be true. Try some simple tests first! KISS!

Alan KM6VV

7

Yes. I am using the debug terminal in the BasicMicro IDE

I am just echoing. I have it running from the Vex into the ABB and back ou to the PC. I have the baud setting as I8N1_115200, which is the default mode for the Vex. Also it is the only rate at which the Vex programming tool (that which uploads code the microcontroller from the PC) operates.

Yes. Vex to PC works fine, I have tried a couple of different terminal programs to make sure the serial output was not unique to the Vex/Vex Loader combination.

I’m pretty sure that nothing would require that. I was just trying to test the formatting of the vex’s various available output. It went like this…
Tried single byte output. ---- The echo did not match, and was different nearly every time.

Tried different formatting parameters. — Still no matching echo.

Discovered that the Vex code that outputs a single word sends a 16bit word in reverse order with a carriage return appended and all as hex.

Tried two’s complement to see if that would give a clue as to what was happening to the bit stream (cause I already had a bunch of results for binary, hex and strings). Of course I know that in the end its all just a binary stream, I simply wanted to find out if the there was a difference in the way the box handled different values for output.

I have buttons connected to the Vex so that I can control the output. That way I can easily test different formats to see if they give the equivalent results.

Yep. It was. So now I am down to sending two bytes at a time.
04 FF
The “echo” is B0 0 or 90 0.

8

16 bit word? This is RS-232, it’s only 8 bits at most! Almost sounds like you’re using a “send integer” type of routine. Look for a “send char” or “send byte” routine. Otherwise, try PACKING your bytes into the 16 bit integers. But you don’t want the auto CR.

Do you HAVE to send two bytes at a time? You might be able to use that instead (but it’s quite unusual), just pack the data, or send only one byte in the LSD, and strip it when received.

Alan KM6VV

9

I did not know that.

The function I was using (in that case) was called PrintWord, and the CR is something I can’t remove. Some of the source files(that one for instance) are write protected. Of course, I can write my own version, which I will do. At least I feel like I am starting to make progress.
There is a PrintByte, but that yielded no better results.

I am not familiar with PACKING…so sound the Google hunt bugle!

I wanted two bytes because the first one keeps flipping between two values, but the second one seems stable. I have tried it with only one byte, but that didn’t work either.

Also, I don’t know what LSD means. So again the googling and the reading and testing.

I am doing all this in a school lab. Fridays tend to be a “lab day” where I can get work done (or fail to get work done), but it can be difficult for me to find much time during the rest of the week. So if it is a while before my next post, it is simply because I am trying to pass various and sundry classes.

I really appreciate your help with this.

10

To pack a word is to simply put two bytes in it. word = (byte1 * 256) + byte2.

You could always change the code on the ABB to receive a series of words with CRs sent. But I can’t believe there isn’t a simple “com out” or “send byte” routine. PrintByte? that could do it. What happened?

Sending a pair of bytes at a time could be OK, but it that’s not working correctly, then I’d fix it first.

But you’ve said you can send bytes and strings from vec to the PC?

If the USB in a word has a bit that keeps on flipping, then somethings wrong. verify the parity and bits/byte.

OK, we’ll wait. Glad to help.

Alan KM6VV

11

Yay. Finals are done. Summer classes begun. Serial communication working, mostly.

I achieved two way communication between the Vex and Atom28. (A paper is forthcoming.) There is one issue I have yet to resolve though. The string I am sending to the Atom28 is interpreted correctly every even number if times it is sent, but incorrectly on the odd times.

  1. First transmission == fail.
  2. Repeat trans. == success.
  3. Repeat trans. == fail.
  4. Repeat trans. == success.
    . . . so on, so forth . . .

I have a signal going back to the vex when the signal is bad to indicate that the transmission needs to be repeated, but that is obviously not the solution, just a failsafe mechanism.

Any clues as to what is going on?

12

I was running into similar issues when I was having my Brat (atom Pro) communicate with the PC (VB). Whenever the Brat would try to output something back to the PC, I would have to do dummy reads to remove some echo characters. I have not tried to do the same thing with an ATom to see if the same condtitions happen.

Have you tried verifying what characters you are receiving on the Atom to see if this is the issue?

Also note unless you are using the hardware serial port, if the code running on the Atom (or pro) is not sitting in a Serin command when a communcation starts, you will miss part or all of the input. This has bitten me in the past!

Kurt

13

The problem in my case is sending to the Atom, not from it. Am I correct that there is no read buffer on the Atom, its just a stream, right?

When it reads it is reading correctly. That is, it is not getting incorrect characters, it is just putting them in the wrong place in the byte array. I think.

I am using serin.

Though, once I get all the code workin’ right I will attempt to do this via the hardware serial port.

14

Yes serin is a bit bang function that will monitor the IO line and use the proper timing for the baud rate that is in use and at each bit interval will see if it is high or low and use that to build the actual byte. So if the you are not sitting the serin, there will be nothing monitoring the IO line and that data will be lost. If you are finding for example your first byte is ending up in the first location of the array, it may be you were not in the serin when the data stream started and lost a couple of bytes of data.

However if you use HSERIN on the hardware serial port (P14 and P15) which is TTL level signals, then there is hardware support on the underlying chip to monitor the input and buffer it. However you lose the RS232 signal and the DB9 connector… One option which I have meant to try on my Hex was to use the DB9 connector on the SSC-32 by jumpering from P14 and P15 of the ABB to the jumpers on the SSC-32, which should hopefully go through the RS232 conversion…