Using a USB cable to communicate with a propellor chip

shadowninja · 2013-05-23 13:49

I am building a robot which uses a computer running ubuntu to do the high level processing such as AI and computer vision and a prop to control the motors and read a sonar sensor. The communication are done via a usb cable. The problem is that I can recive bytes from the propellor the comands I sending to the prop do not seem to be received. I am pretty sure the problem is with the props code. Here is my latest attempt at the program.

Con
_CLKMODE=XTAl1+PLL2X
_XINFREQ=5_000_000
input_pin1=0
input_pin2=1
servo1=2
servo2=3
var
byte output

long new
obj
SERVO : "Servo32v7.spin" 
serial        : "FullDuplexSerial"               
pub go
  dira[input_pin1]~~
  dira[input_pin2]~~
  dira[4]~~
  outa[4]~
    dira[23]~~
  outa[23]~
  SERVO.Start                 'Start Servo handler
    SERVO.Ramp  '<-OPTIONAL     'Start Background Ramping
   serial.Start(31, 30, %0000, 115200)                    'requires 1 cog for operation
repeat
  outa[4]:=1
  input:=serial.Rx
  if STRCOMP(input,str1)
     forward
     outa[23]:=1  
  elseif STRCOMP(input,str2)
    turnright 
  elseif STRCOMP(input,str3)
    turnleft
  elseif STRCOMP(input,str4)
    turn360
  else
   stop
   
  if ina[input_pin1]==0 AND ina[input_pin2]==0
    output:="1"
  elseif ina[input_pin1]==0 AND ina[input_pin2]==1
    output:="2"
  elseif ina[input_pin1]==1 AND ina[input_pin2]==0
    output:="3"
  elseif ina[input_pin1]==1 AND ina[input_pin2==1]
    output:="4"
  serial.Tx(output)
serial.Stop
pri forward
    SERVO.SetRamp(Servo1,2000,0)
        SERVO.SetRamp(Servo2,1000,0)
pri turnright
     SERVO.SetRamp(Servo1,1000,0)
    SERVO.SetRamp(Servo2,1000,0)
pri turnleft
     SERVO.SetRamp(Servo1,2000,0)
    SERVO.SetRamp(Servo2,2000,0)
pri turn360
     SERVO.SetRamp(Servo1,1000,0)
    SERVO.SetRamp(Servo2,1000,0)
pri stop
        SERVO.SetRamp(Servo1,1500,0)
    SERVO.SetRamp(Servo2,1500,0)
dat
input byte "1", 0
str1 byte "1", 0
str2 byte "2", 0
str3 byte "3", 0
str4 byte "4", 0

also in my previous attempt I sent straight up bytes containing characters over the usb to no effect. DO I need to start a new cog or is the problem with the data type or the way I am comparing the input to the constants in the IF statements? What do you think?

JonnyMac · 2013-05-23 14:01

I suggest you simplify your framework before adding the servo control. I do a lot of single-key command processing and have built a little template that may help you better organize (key to success) your code.

BTW... white space is your friend. Don't be afraid to add blank lines and extra spaces to make a program easier to read; this has no impact on the size of the downloaded code.

Duane Degn · 2013-05-23 16:20

It looks like you're setting your input pins as outputs.

dira[input_pin1]~~
  dira[input_pin2]~~

The above set the pins as outputs. The default state is input so you could just remove the above or change it to:

dira[input_pin1]~
  dira[input_pin2]~

The "rx" method only reads a single character. You could compare the single character byte instead of comparing strings.

input:=serial.Rx
  if input == str1
     forward
     outa[23]:=1

I haven't looked at JonnyMac's code yet, I bet he has a better way of doing this.

cavelamb · 2013-05-23 21:30

Jon,

Would you illuminate a couple of details in that code?

For instance...

con
#(-1), IS_ON, IS_OFF
#0, LSBFIRST, MSBFIRST

And #1 and #14 below?

con
#1, HOME, GOTOXY, #8, BKSP, TAB, LF, CLREOL, CLRDN, CR ' PST formmatting control
#14, GOTOX, GOTOY, CLS

JonnyMac · 2013-05-23 22:27

The first set defines IS_ON as -1 (all ones) and IS_OFF as 0 (enumerated constants). This allows me to do things like this:

outa[MSB..LSB] := IS_ON
  dira[MSB..LSB] := IS_ON

and it works no matter what the MSB and LSB settings are. Yes, I know that I could use post ~~ and ~ but they're confusing to programmers that are not well-versed in Spin, and the execution time is longer than the more verbose code style that I prefer. The LSBFIRST and MSBFIRST are remnants from code that used a shift register.

The other constants match up with PST constants.

See page 87 in the PDF manual on the syntax of enumerated constants.

cavelamb · 2013-05-24 05:40

I had forgotten that they would be incrementally enumerated.
And that the #n expression tells the compiler where to start counting.

I've (sorta) gotten used to the ~ and ~~ shorthand.
But spelling things out makes the code so much more readable.

Thanks

shadowninja · 2013-05-24 06:02

Well it turns out my assumptions were wrong. I did a test with transimiting/reciving program on my computer. It turns out if I comment out either the reciving or transimiting code the other works perfectly. SO what do you think can be done to fix the problem.

Duane Degn · 2013-05-24 08:26

shadowninja wrote: »

Well it turns out my assumptions were wrong. I did a test with transimiting/reciving program on my computer. It turns out if I comment out either the reciving or transimiting code the other works perfectly. SO what do you think can be done to fix the problem.

Did you fix the problem of making your button pins outputs? I'm guessing when you comment out the receiving portion, you comment out the part where you turn the pins to outputs so your tx code works.

Do you have a Prop Plug or some other USB to serial device you could use as a separate debug line? If I'm having problems with my code I just keep adding debug statements until it's clear what the program is actually doing. If you can't add a second serial line, add some LEDs so you know which part of code your program is executing. It may help to add some delays to make sure you can see the LEDs. I'd suggest adding a LED to indicate when a button press is detected even if you're just toggling pin 4 (I assume pin 4 has a LED).

JonnyMac · 2013-05-24 10:07

SO what do you think can be done to fix the problem.

Let me suggest it might be more useful for you to spell out HOW you want the code to behave instead of posting code that does not work. The latter could lead those that want to help to misunderstand your intentions.

Ariba · 2013-05-24 10:28

I think the FullDuplexSerial object needs more than 10 MHz clockfreq to work with 115.2 kBaud.
This would explain why sending and receiving at the same time does not work. But the code may be just fast enough to only send or only receive.
Why have you set the PLL to 2x and not 16x?

Andy

shadowninja · 2013-05-24 14:22

THank you Ariba, your suggestiong worked perfectly. Now I can start to wire my quickstart board

Using a USB cable to communicate with a propellor chip

Comments