Using UART for bi-directional data flow

Does anyone know how to configure a BeagleBone’s UART to send data both ways? As of right now, I only know how to either send or receive data on one port; I can’t do it both ways.

I have 2 Uarts configured on the expansion connectors of the BBBk using the techniques mentioned in some other threads. I currently have one setup to communicate bidirectionally over an XBee that responds to the Arbotix Commander (sold by Trossen). The other is connected up bidirectionally to a RoboClaw (Motor controller by Basic Micro/Orion Robotics). I have some hacked up Serial Wrappers to make it easier for me to port my Arduino Code base both for in this case a Rover and in other cases for Hexapod Robots (Phoenix code base).

Note: in my case I have udev rules setup to create symbolic links that in this case I have:
\dev\ttyXBEE → \dev\ttyO1
\dev\ttyRCLAW → \dev\ttyO2

In other cases I have had it setup these links to ttys that are created for USB converters like(\dev\ttyUSB0).

The code may not be perfect or optimal, but if you are interested in looking, it is up on my github account:
https://github.com/KurtE/Raspberry_Pi
(Sorry about the project name, but trying to make code run on both)

The code that I am using for serial code is stuff I modified from the Arduino world and most of it is in the library directory

Kurt

The WrapperSerial class was something I hacked up from code from several places. Started off on the RPI to adapt my Arduino Port of the Phoenix code base (hexapod robots) to the Raspberry Pi. There are threads about this both on the Lynxmotion forums (http://www.lynxmotion.net/viewtopic.php?f=25&t=8607&start=30 )as well as the Trossen Robotics Forums (http://forums.trossenrobotics.com/showthread.php?6040-PhantomX-controlled-by-a-Raspberry-Pi). There were a few others up there also interested in this and one of them asked about getting input for the Arbotix Commander (XBee), so I start playing with this. I found some XBee code base and the like some place on the web… And I hacked up some code that appeared to work fine, but I knew that I was also going to want similar code to talk to the SSC-32 (Servo Controller), Debug output, … So thought it would be nice to have a Serial class. So I hacked up some standard Arduino code (1.0.x) (Print, Stream, …) to have it compile on the RPI, and then had the simple Wrapper class call into those.

I probably should put some more comments into the Headers :oops:

By default the serial system will probably try to buffer as much data as it can, until some conditions are met. I don’t remember fully how the RPI is setup, but these conditions may include things like buffer is full (not sure of buffer size here), Could also include things like max delay (latency)… But they usually include a way to override this, by doing some form of flush operation, so for
example in some of my XBee code you will see things like:

`
void InitXBee(void)
{
uint8_t abT[10];
char szDevice[] = “/dev/ttyXBEE”;

XBeeSerial.begin(szDevice, B38400); // BAUD rate is defined in Hex_CFG.h file…
// Ok lets set the XBEE into API mode…

delay(1000);
XBeeSerial.write("+++");
XBeeSerial.flush();

`

Note: I am using some device rules to give a symbolic name to the tty port that the XBee is on. On The RPI this is currently an FTDI usb device, currently on BBB this is to one of the USARTS on the expansion connectors ttyO2

Hope that helps
Kurt

This is what the “flush” command is for; it flushes data from output buffers to the line.

Yes flush is what you need. I tried to show that in the example earlier of outputting a +++ to the XBee, where the next line was a flush.

The confusion with flush, is for Arduino version < 1.0.x they had the flush command to discard all buffered input. With the 1.0.0 release they changed this to what other systems have used for a long time, which is to force the buffered output to go out…
Again on the Arduino the code would wait for the output to go out. Actually at first it would wait until the last character was queued on the hardware registers on or about 1.0.3, they changed it to wait until the last character was actually output…

Kurt

I tried flush to no avail so I just copied your Wrapperserial code (the begin method) and it all worked. So I started commenting out each line and found that the flow control is to be blamed.

tc.c_cflag &= ~ CRTSCTS; /* disable hardware CTS/RTS flow control */

In my code I set hardware flow control on but Arduino doesn’t do hard ware flow control. With this option set as off, I was able to get the bytes from Debian to Arduino. I will try raspberry pi but expect the same result.

It’s so difficult to use a serial device since all the unix/linux is still holding on to the serial port for terminal idea. Almost all termios options are for dumb terminals like VT100 or something. Wishing to have a simple stream object and nothing to process the stream but my own program. Does linux serial port program always involve this termios struct?

By the way, what is the reason of opening the serial port with a file descriptor and then opening a FILE with that file descriptor? I was just using the file descriptor and read write instead of the FILE with fread and fwrite.

Thanks. Couldn’t have progress without your code.