3

I have made a program which give instruction to a motor module. I have successfully send instruction to him, asking it to make a rotation back and forth, but I can't get back the feedback result.

I sent signal throught the GPIO14 (tx) and GPIO15 (rx) to get the result. So I'm writting data on port /dev/ttyAMA0, and reading result into it too.

On arduino, there is led for tx/rx signal, which make the debug more confortable. Here, since my motor work, I presume it get the signal. But i'm trying to read on /dev/ttyAMA0 again, and I don't get any result.

This is a half-duplex communication, so there is a control pin who decide which one can talk. The fact that I get nothing when I send data to the motor, then I don't know if it is an hardware problem, or if I need to ask feedback to the motor. In the doc they say when you give command to the motor, it return a feedback status packet. The fact is, I don't know when the data is transmitted.

So my question is, is there a rapid way to test on Raspi if tx pin send data and rx pin get data. Or if the only way is to place debug led on the circuit. And when you read into /dev/ttyAMA0, if you need to wait for the data, or it acts like a buffer?

Mr Bonjour
  • 163
  • 1
  • 8
  • Hopefully you have configured the Pi 3 to use /dev/ttyAMA0 as the UART, because otherwise it is the bluetooth module and there may be some erroneous conclusions here. – goldilocks Sep 16 '16 at 16:40
  • There is a 64k buffer associated with the UART, however, I'm not sure if this is per process/handle and hence cleared on open. I.e., it will accumulate data once there is an open handle, but it may be empty no matter what when you first open it. WRT debugging piscope should be useful. – goldilocks Sep 16 '16 at 16:43
  • yeah I was thinking of a solution like this. I'm going to investigate into piscope. And thank you too for the buffer info. I was not sure if I should wait for the incoming signal or if I could get the data later when reading the file. – Mr Bonjour Sep 17 '16 at 12:06

1 Answers1

1

One of the easiest ways to debug the serial i/o is to perform a hardware loop back. If you happen to have a ttl 3.3v to rs 232 adapter (DB9 connector) such as this, simply shorting pins 2 (rx) and 3 (tx) using a short jumper wire should allow you to see whats being sent out using a terminal program such as minicom. For more details search for rs232 d connector loopback. If you have direct access to the Pi's pins, using a female-female jumper on tx/rx pins should do as well.

One another thing you might want to see if it is a permission problem. Assuming you are using raspbian, see this on how to give access to the default user pi.

I sincerely hope you have made sure the voltage levels are compatible. The PI's pins operate at 3.3v. If the motor controller works on 5V TTL/RS232 or RS485 an appropriate level shifter/isolation is essential. Otherwise you are very likely to have fried you PI or its pins.

Community
  • 1
Shreyas Murali
  • 2,416
  • 1
  • 15
  • 22
  • 1
    mmm... I actually have done a loopback, and it worked. Even done with a serial to usb and send data through usb to UART and it worked. The fact is, I'm not sure if it's an error at circuit level or software level. The doc of the motor say when the data control is detected as low, it send its feedback output, but I get nothing. Strange that it take 3,3v for this special kind of purpose: I though TTL transmission should be at 5v. I checked and yes, it is 3.3v tolerant... The circuit has omitted this and people use it as raw 5v. – Mr Bonjour Sep 17 '16 at 12:02
  • 1
    "The doc of the motor say when the data control is detected as low, it send its feedback output" - if this is referring to RTS/CTS signals, then you'll need an additional GPIO dedicated to that. – Richard Apr 24 '17 at 18:20