I’m using the Debian Jessie image with kernel version 4.4.6-ti-r15 on my BeagleBone Black.
To monitor our vacuum system in the lab, we need a RS485 interface, so I simply connected an ADM2682 RS422/485 line driver
to UART4 of the BeagleBone using this Device Tree Overlay BB-UART4-RS485-00A0.dts (commit 16f76f7 on master branch)
P9.27 is connected to the DE and !RE inputs of the chip.
Using this for sending works just fine, but I have problems receiving messages over the bus.
For testing I wrote a small C-program which should read on the bus until it gets two times a timeout.
The reading is done via select-call with a 5 second timeout.
The device on the other end of the bus is contentiously sending data over the bus.
After receiving 49 bytes at most, the DE/!RE line goes up and my BeagleBone stops receiving any data…
I’ve uploaded a screenshot of the scope showing the three signals from the UART interface Scope
I did some further tests.
Actually none of the screens from my scope looks like I would expect it…
Picture 1 shows the result, if I try to read something on the bus with a 14s timeout (nothing was sended on the bus…) Pic1
Picture 2 shows the same, but this time there were messages send over the bus. After 49 bytes, the beagle bone toggles the DE/!RE gpio to high for unknown reasons (the test program is still reading from the UART interface) Pic2
Picture 3 shows the test, where the BeagleBone is sending Pic3
and finally picture 4 shows a test, where the BeagleBone should read (timeout 3s) on the bus, then send something and again reading (with 3s timeout)… Pic4
As you see, DE/!RS stays high after sending, although it should be low…
In addition I would expect this line to be low when the port is not used, but it’s high…
I checked if there is any other process (or driver) accessing GPIO3_19 but I could not find any…
I can't tell you Beaglebone specifics, but to stop after a certain
number of characters and set DE/!RE high (I'm guessing this is a full
indication?), sounds like you've hit the limits on a buffer of some 50
bytes, so it may be that you're running up against this limit.
Normally, when you read data from a hardware UART within a chip, the
internal FIFO in the hardware is cleared of that byte, data flags are
reset.
It sounds as if something's not being done.
If there is a software FIFO involved, and you're reading the data
directly from the chip (not sure how), then the FIFO is loaded, but
never read. When it's full, the serial interface should tell the
transmitter to stop sending.
Any chance you could post a picture of a simple drawing of how you
connected the 485 driver to the BB (like which pin to which pin and
any extra components)? Also could you post your small C test program?
I don’t have time to read your mail, but If you want to use rs485 on kernel 4.1/4.4 you have to use the omap driver and not 8250( which is the default ).
@Alex: I recommend, you read my mail
I did not look into the kernel source nor am I sure which driver is used in my Setup,
but the problem is not the "rs485-rts-active-high" flag
When sending, the RTS (or DE/!RE) signal behaves as expected. Only during receiving (and IMHO when idle)
the flag does not.
here is the schematic of my current test setup.
Concerning my test program : rs485_test.c
(it’s a ugly quick’n’dirty implementation…)
The RS485 line driver is connected to a RS485-RS232 Converter which is connected to a linux PC.
On this linux PC, the same program is used for the tests.
I had a look at the kernel source at github. From the code
I would say the 8250 driver supports RS485. Only the “rs485-rts-active-high” flag from the device tree overlay
seems not to be supported. But the same setting can be done via the struct serial_rs485 from user space.
Also RS485 seems to be working to a limited point.
Again: The only problem is receiving messages, which seems for what ever reason to be limited to 49 bytes.
If my kernel is not supporting RS485 I would expect that either sending or receiving is not working at all.
But from all the Pictures I linked in my previous mails, you can see, that the 8250 driver is switching the
RTS signal with the correct polarity.
Can someone point to to the kernel source for the kernel I am using (4.4.6-ti-r15)?
At least looking at the releases/tags in the repo at github this version is not listed…
I’d like to have a look at the exact same source which is currently running on my setup,
to see if there is some bug or missing support in the kernel…
> I did some further tests.
> Actually none of the screens from my scope looks like I would expect it...
>
> Picture 1 shows the result, if I try to read something on the bus with a 14s
> timeout (nothing was sended on the bus...)
> Pic1
> Picture 2 shows the same, but this time there were messages send over the
> bus. After 49 bytes, the beagle bone toggles the DE/!RE gpio to high for
> unknown reasons (the test program is still reading from the UART interface)
> Pic2
> Picture 3 shows the test, where the BeagleBone is sending
> Pic3
Your scope picture #3 does appear to show data being sent, however you
seem to say that your picture #2 portrays a test in which you received
49 bytes, however I don't see any sign of data being received in that
picture. Maybe I am missing something.
I am not an expert in these things, but my current understanding is
that what the 485 driver provides extra to what the UART driver does
is the automatic switch of the driver enable pin. One test I would
suggest, a test I have done myself, is to send and receive data with
485 using the UART driver. In this case the DE/RE needs to be set
manually. I do it using echo to /sys/class/gpio. Once that is working
well you could start test usinging the 485 driver. You should be able
to use your existing rs485_test.c program for that.
@Alex: I recommend, you read my mail
I did not look into the kernel source nor am I sure which driver is used in my Setup,
but the problem is not the "rs485-rts-active-high" flag
As Micka and Alex said the 4.1 and 4.4 driver do not have 485 support
enabled. Per an email by Robert you need to enable the OMAP serial
kernel configuration option and rebuild the kernel.
I did some further tests.
Actually none of the screens from my scope looks like I would expect it...
Picture 1 shows the result, if I try to read something on the bus with a 14s
timeout (nothing was sended on the bus...)
Pic1
Picture 2 shows the same, but this time there were messages send over the
bus. After 49 bytes, the beagle bone toggles the DE/!RE gpio to high for
unknown reasons (the test program is still reading from the UART interface)
Pic2
Picture 3 shows the test, where the BeagleBone is sending
Pic3
Your scope picture #3 does appear to show data being sent, however you
seem to say that your picture #2 portrays a test in which you received
49 bytes, however I don't see any sign of data being received in that
picture. Maybe I am missing something.
in all 4 picture from my 2nd post, channel 4 (green) shows one of
the two data lines of the bus.
Looking at #2 one can see, that this signal is starting toggling shortly before
the DE/RE signal goes high. That's the 49 bytes I receive. After that the data line
is still toggling araound but no longer between 0 and 1 but something in between,
because now, there are two devices sending on the bus. One is still the PC which
sends random data, the other one is the BeagleBone sending a constant 0...
(TX and DE/RE are constant high)
I am not an expert in these things, but my current understanding is
that what the 485 driver provides extra to what the UART driver does
is the automatic switch of the driver enable pin. One test I would
suggest, a test I have done myself, is to send and receive data with
485 using the UART driver. In this case the DE/RE needs to be set
manually. I do it using echo to /sys/class/gpio. Once that is working
well you could start test usinging the 485 driver. You should be able
to use your existing rs485_test.c program for that.
@Alex: I recommend, you read my mail
I did not look into the kernel source nor am I sure which driver is used in my Setup,
but the problem is not the "rs485-rts-active-high" flag
As Micka and Alex said the 4.1 and 4.4 driver do not have 485 support
enabled. Per an email by Robert you need to enable the OMAP serial
kernel configuration option and rebuild the kernel.
I'm still a bit puzzled how "rs485 is not supported" looks like...
For me, being able to send and receiving data is quiet the
contrary of "not supported".
Where can I find the sources of the kernel used in the debian-jessie-console 8.4 image
from April 07 in order to rebuild it? (I prefer changing as less as possible, thus I'd like
to use the exact same kernel source tree as it is now)
I did some further tests.
Actually none of the screens from my scope looks like I would expect it...
Picture 1 shows the result, if I try to read something on the bus with a 14s
timeout (nothing was sended on the bus...)
Pic1
Picture 2 shows the same, but this time there were messages send over the
bus. After 49 bytes, the beagle bone toggles the DE/!RE gpio to high for
unknown reasons (the test program is still reading from the UART interface)
Pic2
Picture 3 shows the test, where the BeagleBone is sending
Pic3
Your scope picture #3 does appear to show data being sent, however you
seem to say that your picture #2 portrays a test in which you received
49 bytes, however I don't see any sign of data being received in that
picture. Maybe I am missing something.
in all 4 picture from my 2nd post, channel 4 (green) shows one of
the two data lines of the bus.
Looking at #2 one can see, that this signal is starting toggling shortly before
the DE/RE signal goes high. That's the 49 bytes I receive. After that the data line
is still toggling araound but no longer between 0 and 1 but something in between,
because now, there are two devices sending on the bus. One is still the PC which
sends random data, the other one is the BeagleBone sending a constant 0...
(TX and DE/RE are constant high)
I am not an expert in these things, but my current understanding is
that what the 485 driver provides extra to what the UART driver does
is the automatic switch of the driver enable pin. One test I would
suggest, a test I have done myself, is to send and receive data with
485 using the UART driver. In this case the DE/RE needs to be set
manually. I do it using echo to /sys/class/gpio. Once that is working
well you could start test usinging the 485 driver. You should be able
to use your existing rs485_test.c program for that.
@Alex: I recommend, you read my mail
I did not look into the kernel source nor am I sure which driver is used in my Setup,
but the problem is not the "rs485-rts-active-high" flag
As Micka and Alex said the 4.1 and 4.4 driver do not have 485 support
enabled. Per an email by Robert you need to enable the OMAP serial
kernel configuration option and rebuild the kernel.
I'm still a bit puzzled how "rs485 is not supported" looks like...
For me, being able to send and receiving data is quiet the
contrary of "not supported".
Where can I find the sources of the kernel used in the debian-jessie-console 8.4 image
from April 07 in order to rebuild it? (I prefer changing as less as possible, thus I'd like
to use the exact same kernel source tree as it is now)
Just found the link to Roberts script-repo at github..
I will rebuild the kernel with the OMAP driver and test the RS485 interface again...
I rebuild the kernel changing the configuration as mentiond by Taceant,
copied the new kernel onto my SD card and put it back into my BBB.
The board boots, everything seems fine, so I install
the device tree overlays (bb.org-overlay repo) and reboot the board,
as suggested by the install script.
After that, the BeagleBone Black no longer boots.
Here is what I changed in the kernel config:
~ > diff yakbuild/KERNEL/.config yakbuild/KERNEL/.config.old
2551c2551,2552
< # CONFIG_SERIAL_8250_OMAP is not set
I mounted the SD card and deleted the initrd.img-uname -r file. After that, the BeagleBone was booting again.
But: Loading the BB-UART4-RS485 device tree overlay manually, I can now receive data over the RS485 bus,
but I can no longer send data.
So it seems the OMAP driver is not working either. Actually now it is even worse than before using the 8250 driver.
What about trying a 4.1.x kernel as some people seem to have had
success with it? However I would suggest installing a Debian image
that comes with a 4.1 kernel rather than using a 4.1 kernel on your
current image. Last year I had a problem with some sort of systemd
incompatibility with a kernel when I upgraded a kernel whereby the BBB
would not boot.
I prepared a second SD card with an older Debian Jessie image,
which is using a 4.1 kernel.
I rebuild the kernel, making the same modifications as for the 4.4 kernel.
With the 4.1 Kernel, loading the RS485 overlay via uEnv.txt works, but
still the DE/!RE line does nothing.
BTW: some mails ago I included a schematic of my setup. I just realized
that there is a mistake in it. DE/!RE is of course connected to P9-27 and not
to P9-25 as drawn in the picture.
I actually checked it now several times, that I have it correctly wired
I have to apologize for my last two mails, because I made a stupid mistake...
If you look at the source of my test program (6th message in this thread)
I only set the SER_RS485_ENABLED flag in the struct serial_rs485.
This didn't work, so I uncommented the next two lines which were
rs485conf.flags |= SER_RS485_RTS_ON_SEND;
rs485conf.flags &= ~SER_RS485_RTS_ON_SEND;
Of course this tells the RTS signal to be always 0 which does not work...
Fixing this bug, RS485 is now working with both kernels, 4.1 and 4.4,
using the OMAP driver...
I wonder, have you seen in the scope how many milliseconds does it
take for DE/RE to switch from high to low after the BB finishes
writing a block of data to the bus?
Would you please post the .dts files you used with the 4.1 and 4.4
kernels to enable RS485?
Using the config 9600 8N1 for testing, I get a delay of about 29.2 us between the falling edge of the DE/RE signal and the end of the stop bit of the UART.
