[beagleboard] Re: Serial Communication on Beaglebone Black

@Shaurabh
Is this your serial adapter:http://www.logicsupply.com/cbb-ttl-232/

You have two of them and have modified one to be Serial 4?

@Bruce
Yes that is. I tried with the adapter as well as without as there are two ways of doing it. It is working fine. But specifically for the CNC connection it is not.

@Shaurabh
OK they actually have a pretty nice document for that!

Now what is your CNC machine? What serial port document do you have for it?

The serial cape has only TXD and RXD driven, no handshake or flow control.
The CNC might expect something specific. It does look like the serial cape
has some of the control signals fed back, I did not study it enough and map
the 5x2 ribbon cable to the DB9 to figure that out.

You would need a null modem cable between the BBB DTE serial port and the
CNC DTE serial port, or you can modify the BBB serial as DCE instead. If
you make the BBB as DCE, and connect a straight serial cable to your PC
DTE, you should see the BBB bootloader information every time BBB powers
up. And you can log in to BBB on that serial0 port too.

If things are eventually connected correctly to the CNC, it will also see
the BBB bootloader information: is that OK for the CNC or will it get
confused? If the CNC sends some data to the BBB during bootup it could
confuse BBB.

So it might be better to use serial4, set as DCE which has no BBB debug use
already.

If you do that, you could connect serial4 as DCE from BBB to your PC with a
straight cable, and pretend your PC is the CNC. See if you can open a
terminal on the PC and BBB and see data both ways. If so then it should
work on the CNC just by moving the cable over. This assumes the CNC doesn't
need some specific flow control or handshake. You might be able to disable
that from the CNC side so all it needs is TX and RX.

Aren't serial ports wonderfully confusing?

At this moment I have a headache from working on code and hardware (not on
BBB, we are using a Teensy ARM Cortex M4 this time) talking to a custom
RS422-sort-of serial connection so I feel your pain.

It is confusing indeed.

I have a HAAS CNC machine. The documentation specifically states that interaction can occur only through an RS232 port.
Moving on, I connected the female DB 25 at the HAAS CNC using a null modem 25 to 9 and an RS232 to USB(initially). This connection worked perfectly when i connected it to my PC(USB at the PC). What the CNC does is: I send a command from my PC and the CNC spits back corresponding data.
Now all of it works perfectly fine.

But now I want to replicate the entire thing on a BBB. So that instead of my PC there is BBB.

I know the exact null modem + RS 232 works fine with my PC. But is not working at all with the BBB.
No handshake protocols are enabled. I have triple checked that just to be sure.
From what i think at the BBB :it should be DTE since at PC it is. I can try making it DCE.

DTE on BBB will be OK as long as you have null modem cable.

Try letting your PC simulate the CNC, and get communication working between
PC DTE and BBB. Then switch that PC end to the CNC.

Bruce

It is confusing indeed.

I have a HAAS CNC machine. The documentation specifically states that
interaction can occur only through an RS232 port.
Moving on, I connected the female DB 25 at the HAAS CNC using a null modem
25 to 9 and an RS232 to USB(initially). This connection worked perfectly
when i connected it to my PC(USB at the PC). What the CNC does is: I send a
command from my PC and the CNC spits back corresponding data.
Now all of it works perfectly fine.

But now I want to replicate the entire thing on a BBB. So that instead of
my PC there is BBB.

I know the exact null modem + RS 232 works fine with my PC. But is not
working at all with the BBB.
No handshake protocols are enabled. I have triple checked that just to be
sure.
From what i think at the BBB :it should be DTE since at PC it is. I can try
making it DCE.

One last time.

Computer USB (5 volts) to RS232 adaptor (+/- 9 volts or so). DTE or
DCE is solved by a null modem if needed.

BBB does not put out USB (in this case). BBB puts out 3.3 volts and
needs 3.3 volts. RS-232 adaptor MUST accept 3.3 volts from the BBB
and ONLY put out 3.3 volts TO the BBB.

RS-232 adaptor provides the interface to the CNC machine.

1) you MUST use an RS-232 adaptor to connect to the BBB
2) the adaptor MUST be set to produce only 3.3 volts and NOT 5.0 volts
to the BBB
3) once you figure out what the BBB is producing on what pin, and what
the CNC needs to see, connect the RS-232 adaptor accordingly.

IF the BBB is putting out signals on the TXD pin, then you have a
source to drive the RS-232 adaptor.

IF the BBB can see 3.3 volt signals on the RXD pin, then you can
listen to the CNC machine if it says anything.

I'd suggest the following:

1) oscilloscope
2) RS-232 analyzer (if needed)

The bits about CTS, RTS, CD, DSR and so can be determined from looking
at what the working interface is doing when you measure the signals at
the CNC machine's pins.

Harvey

@Harvey

He is using a mini cape which does the proper voltage level shifting. Link
in previous message in this thread.

Thanks, then it seems to be all software from this point on. Glad
that this hardware setup will not damage the BBB.

Harvey

I shall try that soon @ Bruce.
Okay. Here is a logic(do not know how sensible but still).
Every time I connect at my PC it works all fine. When i connect to other systems it asks to update the driver. Unless ofcourse the driver is installed.

So i was thinking if the same applies to a BBB. Would i have to update or upgrade the driver the same way?
If so then anybody knows how to?

is this PC running windows ?

Yes all the three i tried on.

i would say you would need WINE installed on the BBB if you want to run
windows programs on the BBB
I have never tried it though so your mileage will vary

how were you running the program on the BBB if its a windows program ?

Okay. Well windows is simply the OS as far as its role is concerned. I am using Python 2.7 entirely to communicate. I have the same exact version of python installed on BBB as well. So i doubt if WINE would help.

well you need scope . or a logic probe

Could you elaborate please.

http://www.ebay.com/itm/Tektronix-2440-Digital-300MHz-Sampling-Oscilloscope-500MS-s-DSO-with-GPIB-/191874097157?hash=item2cac966005:g:wxEAAOSwxehXOjEP

http://www.ebay.com/itm/B-K-PRECISION-DP-21-Probe-Digital-Logic-/331331058853?hash=item4d24debca5:g:X7IAAOSwaG9XJNo9

Well, I stumbled across this discussion because I just found out today after wasting hours that my Beaglebone appears to have RX and TX mislabeled (swapped). Maybe that's the source of some of the confusion that others are having, too? I am accustomed to always connecting TX to RX and vice-versa between components, but to get the Beaglebone to work with all my other serial devices (that work in the usual way with other development boards), I have to connect RX to RX and TX to TX! Mind you, this is a brand new PocketBeagle, and maybe the developers just got this one board backwards, but maybe all the BBs have the same screwy labeling?

-- Will

Yeah we also stumbled last-week on Tx and Rx being swapped/ ‘crossed’ for UART1 (?only?) on the BB-X15 AND TI 572x evm REVA3 schematics. The other UARTS appear fine. Details to follow.

I’ve been using a beaglebone black (in debian) to communicate with my Matsuura MC800 VF (1993). It’s got an old yasnac I-80 controller on it, and I have to drip feed most stuff because I’ve only got about 30k of program memory. For the record I was unable to get this to work with USB to serial adapters, in both Windows and Linux. As soon as I went directly to the UART pins it was easy.

I recommend using stty to set the serial port, and the just copy the file you want to the serial port. For example, I run at 4800 baud, 7 data bits even parity 1 stop bit with software “flow control”. Here’s how I set the port settings for the beaglebone black:

stty -F /dev/ttyS1 4800 parenb cs7 -icrnl ixon nl1 cr1

then do something like this to copy the file to the serial port and have the beaglebone spit it out. In my case I’m using serial (uart) 1:

cp /pathtofile/mycncfile.nc /dev/ttyS1

You can do it in Python, but I’d get it working at the most basic level first. With Python there could be additional software buffers between you and the cnc machine that could cause issues.

I use a max232 between the beaglebone and the machine for level shifting. I’m currently using an old one a buddy soldered up and had laying around, but I’m going to put in a more professional max232 in the next couple days. The one I got was on Amazon link here:

https://www.amazon.com/gp/product/B00HKIMBZW/ref=oh_aui_search_detailpage?ie=UTF8&psc=1

It looks, good, but I haven’t tested it yet.

Now, I’ve got a question for you guys. Has anyone been able to get hardware flow control working on the beaglebone black in debian?

-Marc

Hi,

I’m running on a BB-X15 with kernel 4.4.110-ti-r142 and Debian, 8.10 (2018-01-01).

I have not yet correctly run hardware flow control on Beagleboard-X15/BBB, but I BELIEVE I saw evidence that the non-default, OMAP serial driver (as opposed to the default 8250 serial driver) was auto-toggling the RTS line when the RTS line was using a GPIO line instead of a “dedicated RTS line” for the respective UART. Caution: it could be that the driver was treating the GPIO line differently than the dedicated RTS line, so I need to go back and flush all of this out (unless someone on here already knows the answer)… I also need to show you the difference in how my device tree fragment for this UART was specified.

Furthermore, since we’re doing RS485/MODBUS for our work project, our strategy (at the moment) is to manually toggle the dedicated RTS line which is connected to the “DE switch” on a 2-wire RS485 chip. Toggling the DE switch switches whether the half-duplex RS485 chip is transmitting (e.g. UART port’s Txd line is connected) or receiving (e.g. UART port’s Rxd line is connected). One interesting thing to note, is that so long as we use a "dedicated RTS line from the UART, we can manually toggle that RTS line (in Python, for instance) regardless of whether we’re using the OMAP driver or the 8250 driver.

My BB-X15 is currently setup for UART 9. The pinmux has been configured to expose UART9’s Rxd, Txd, RTS, and CTS. I just need a good, easy way of testing hardware flow control maybe in some kind of real time data exchange. So maybe something like a Python program running on both my PC and my BB-X15 which boomerangs back what the other party sends???

I will TRY to test this this week in my spare time, but there’s some stuff at work and outside of work this week which could easily necessitate pushing this back… So bare with me, and follow-up if I drop the ball.

Thanks!

Jeff