Shop OBEX P1 Docs P2 Docs Learn Events
One wire communications w/ MotorMindB — Parallax Forums

One wire communications w/ MotorMindB

HowlerHowler Posts: 3
edited 2007-02-01 13:27 in General Discussion
I think I probably know what's going on here but I'm wondering if there is any sort of work-around.

I've setup a UART to communicate with a MotorMindB.· This device is capable of one-wire communications, that is sending the the response back on TX line.

Here's my chunk of code....

··· _motorMind.setDirection(Uart.dirTransmit);
··· _motorMind.sendByte(0x55);
··· _motorMind.sendByte(command);
··· while(!_motorMind.sendBufferEmpty());
··· _motorMind.setDirection(Uart.dirReceive);

I then have a simple loop that looks for a response

····· byte data;
····· while(_motorMind.byteAvailable())
····· {
········· data = (byte)_motorMind.receiveByte();
········· System.out.print("From Motor->");
········· System.out.print(pin);
········· System.out.print("<-byte->");
········· System.out.println(data);
····· }

According to the motor mind doc's the response should occur within·500us-1000us of getting the data.

I would appear that commands that return only one byte don't get picked up at all.· Responses that return two bytes only return one byte and that byte is random.

Is it safe to assume that the switch between TX to RX just isn't happening fast enough and I'm droppings some of the return bits?· If so is there any work around?

Right now I'm out of VP's so unless I can create additional ones, I'm really stuck with the one wire solution.

Any help would be appreciated

Kevin...

Comments

  • Peter VerkaikPeter Verkaik Posts: 3,956
    edited 2007-02-01 08:01
    It could be the direction change is too slow for the response.
    The way you test could also be wrong if response times are not equal
    to all commands.
    You use
    while (rx.byteAvailable()) {}
    directly after sending command.
    If at the moment of that test no (complete) data has arrived you still
    exit the while loop.
    Try using a delay first to be sure no data is received.
    CPU.delay(10500); //wait 1 second
    while (rx.byteAvailable()) {}
    If you then still get no responses then you know for certain
    the direction change takes too long.

    regards peter
  • HowlerHowler Posts: 3
    edited 2007-02-01 12:04
    Thanks for the quick reply Peter - Actually the "while(rx.byteAvailable())" is getting checked in a round-robin fashion so I'm pretty sure the direction change is taking too long.

    Are there any options like adding an additional VP? I think I tried this early on in the CPU class, but wasn't too successful. Is there any mechasim for programming at a lower level (drop down to assembly language) on the Javelin?

    Thanks again

    Kevin...
  • Peter VerkaikPeter Verkaik Posts: 3,956
    edited 2007-02-01 12:21
    If the direction change does take too long, the only option is to use
    2 uarts, meaning you need to stop another VP temporarily. If you use
    another transmit uart, you can safely stop that.
    In my code I frequently use only 1 VP slot for all transmit uarts.
    Without a look at your code I can't give an exact solution, if any.

    regards peter
  • HowlerHowler Posts: 3
    edited 2007-02-01 12:34
    Yes - that makes sense and will work thank you...I would still need to block with the "sendBufferEmpty()" before the vp.stop() right?

    Kevin...
  • Peter VerkaikPeter Verkaik Posts: 3,956
    edited 2007-02-01 13:27
    Yes.
    regards peter
Sign In or Register to comment.