subject:"\[beagleboard\] Re\: BBB UART4 RTS for RS\-485"

[beagleboard] Re: BBB UART4 RTS for RS-485

2014-09-03 Thread Alexander Hiam

I actually just put up a tutorial for doing this in 
Python: 
http://inspire.logicsupply.com/2014/09/beaglebone-rs-485-communication.html 
It uses GPIO1_16, but of course you can use any GPIO pin, including the one 
that's shared with UART4 RTS.
 

> When I tried to use:
> struct serial_rs485 rs485conf;
> rs485conf.flags |= SER_RS485_USE_GPIO;
> rs485conf.gpio_pin = GPIO0_9;
>
> I got error from gcc that it does not know those macros:
> ‘SER_RS485_USE_GPIO’ was not declared in this scope
>  rs485conf.flags |= SER_RS485_USE_GPIO;
> ‘struct serial_rs485’ has no member named ‘gpio_pin’
>   rs485conf.gpio_pin = GPIO0_9;
> ‘GPIO0_9’ was not declared in this scope
>   rs485conf.gpio_pin = GPIO0_9;
>
>  
That's because you're compiling with the standard libc headers, which don't 
include the modified serial_rs485 struct that uses the GPIO pin. The 
tutorial I linked above uses Python and just defines the same values 
locally, which you could do in C as well. You could also grab the Kernel 
source and include 'include/uapi/linux/serial.h', which has the patched 
serial_rs485 struct 
(https://github.com/RobertCNelson/bb-kernel/blob/am33x-v3.8/patches/fixes/0007-omap-RS485-support-by-Michael-Musset.patch#L201).
 

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: BBB UART4 RTS for RS-485

2014-09-04 Thread lucaso . janik

Thank you for your answers. The python code is working perfectly. 
I need to use it in greater C project though. So I am compiling new kernel 
including RS485 patch. I have tried /opt/scripts/tools/update_kernel.sh 
hoping that it includes the RS485 patch ...unsuccessfully.
I am now following steps from 
http://jkridner.wordpress.com/2014/06/04/yet-another-set-of-notes-on-building-beaglebone-kernel/

Dne středa, 3. září 2014 17:57:53 UTC+2 lucaso...@gmail.com napsal(a):
>
> Hello,
> I'm writing an app for BeagleBoneBlack running debian (3.8.13-bone50). I 
> would like to use UART4 to communicate with RS485 transmitter over 
> P9.24(UART4 Tx), P9.26(UART4 Rx) and P8.33 (UART4 RTS). 
> I've disabled HDMI and enabled overlays BB-UART4 and BB-UART4-RTSCTS
>
> cat /sys/devices/bone_capemgr.9/slots
>  0: 54:PF--- 
>  1: 55:PF--- 
>  2: 56:PF--- 
>  3: 57:PF--- 
>  4: ff:P-O-L Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G
>  5: ff:P-O-- Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI
>  6: ff:P-O-- Bone-Black-HDMIN,00A0,Texas Instrument,BB-BONELT-HDMIN
>  7: ff:P-O-L Override Board Name,00A0,Override Manuf,BB-UART4
> 10: ff:P-O-L Override Board Name,00A0,Override Manuf,BB-UART4-RTSCTS
>
> cat /proc/tty/driver/OMAP-SERIAL 
> serinfo:1.0 driver revision:
> 0: uart:OMAP UART0 mmio:0x44E09000 irq:72 tx:345 rx:0 RTS|CTS|DTR|DSR
> 4: uart:OMAP UART4 mmio:0x481A8000 irq:45 tx:61355 rx:1 brk:1 RTS|DTR|DSR
>
>
> RS485 transmitter is connected through RS485-USB converter to PC. When I 
> run screen /dev/ttyO4 9600 +crtscts and periodicaly write some data to it, 
> PC receives it properly, but RTS line stays constantly low (I'm using scope 
> on Tx and RTS lines). 
> I've also tried to write simple C program, using *struct serial_rs485. *When 
> I write some data over this program, I got response: *Resource 
> temporarily unavailable* and dmesg says 
> *omap_uart 481a8000.serial: Must use GPIO for RS485 Support.*When I tried 
> to use:
> struct serial_rs485 rs485conf;
> rs485conf.flags |= SER_RS485_USE_GPIO;
> rs485conf.gpio_pin = GPIO0_9;
>
> I got error from gcc that it does not know those macros:
> ‘SER_RS485_USE_GPIO’ was not declared in this scope
>  rs485conf.flags |= SER_RS485_USE_GPIO;
> ‘struct serial_rs485’ has no member named ‘gpio_pin’
>   rs485conf.gpio_pin = GPIO0_9;
> ‘GPIO0_9’ was not declared in this scope
>   rs485conf.gpio_pin = GPIO0_9;
>
> Could somebody help me? I have no more ideas.
>
>
>
>
>
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: BBB UART4 RTS for RS-485

2017-03-23 Thread bmellero

Hi Alexander,

The link you provided does not work:

 http://inspire.logicsupply.com/2014/09/beaglebone-rs-485-communication.html
 

Do you mind sending me the tutorial? I am currently designing my own cape 
which will support two RS485 half duplex channels and your tutorial would 
be very helpful to get me started. My questions are:

1) Am I limited to UART4 or can I use any of the available UARTs on the 
Beaglebone Black?

2) Just to be 100% sure, I can use any of the GPIO pins for controlling DE 
& /RE pins on the RS485 transceiver (I'm using TI's ISO15MDW)?

Thank you,

Bolek

On Wednesday, September 3, 2014 at 10:07:26 AM UTC-7, Alexander Hiam wrote:
>
> I actually just put up a tutorial for doing this in Python: 
> http://inspire.logicsupply.com/2014/09/beaglebone-rs-485-communication.html
>  
> It uses GPIO1_16, but of course you can use any GPIO pin, including the 
> one that's shared with UART4 RTS.
>  
>
>> When I tried to use:
>> struct serial_rs485 rs485conf;
>> rs485conf.flags |= SER_RS485_USE_GPIO;
>> rs485conf.gpio_pin = GPIO0_9;
>>
>> I got error from gcc that it does not know those macros:
>> ‘SER_RS485_USE_GPIO’ was not declared in this scope
>>  rs485conf.flags |= SER_RS485_USE_GPIO;
>> ‘struct serial_rs485’ has no member named ‘gpio_pin’
>>   rs485conf.gpio_pin = GPIO0_9;
>> ‘GPIO0_9’ was not declared in this scope
>>   rs485conf.gpio_pin = GPIO0_9;
>>
>>  
> That's because you're compiling with the standard libc headers, which 
> don't include the modified serial_rs485 struct that uses the GPIO pin. The 
> tutorial I linked above uses Python and just defines the same values 
> locally, which you could do in C as well. You could also grab the Kernel 
> source and include 'include/uapi/linux/serial.h', which has the patched 
> serial_rs485 struct (
> https://github.com/RobertCNelson/bb-kernel/blob/am33x-v3.8/patches/fixes/0007-omap-RS485-support-by-Michael-Musset.patch#L201
> ). 
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/50b1a526-2ca1-4f20-92b8-0b497da1c975%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: BBB UART4 RTS for RS-485

2017-03-24 Thread rndmpt

Hi,

We are having allot of problems getting RS485 with RTS working on Debian: 
Linux 4.4
CAn someone help?

On Thursday, March 23, 2017 at 9:13:23 PM UTC+2, bmel...@gmail.com wrote:
>
> Hi Alexander,
>
> The link you provided does not work:
>
>  
> http://inspire.logicsupply.com/2014/09/beaglebone-rs-485-communication.html
>  
>
> Do you mind sending me the tutorial? I am currently designing my own cape 
> which will support two RS485 half duplex channels and your tutorial would 
> be very helpful to get me started. My questions are:
>
> 1) Am I limited to UART4 or can I use any of the available UARTs on the 
> Beaglebone Black?
>
> 2) Just to be 100% sure, I can use any of the GPIO pins for controlling DE 
> & /RE pins on the RS485 transceiver (I'm using TI's ISO15MDW)?
>
> Thank you,
>
> Bolek
>
> On Wednesday, September 3, 2014 at 10:07:26 AM UTC-7, Alexander Hiam wrote:
>>
>> I actually just put up a tutorial for doing this in Python: 
>> http://inspire.logicsupply.com/2014/09/beaglebone-rs-485-communication.html
>>  
>> It uses GPIO1_16, but of course you can use any GPIO pin, including the 
>> one that's shared with UART4 RTS.
>>  
>>
>>> When I tried to use:
>>> struct serial_rs485 rs485conf;
>>> rs485conf.flags |= SER_RS485_USE_GPIO;
>>> rs485conf.gpio_pin = GPIO0_9;
>>>
>>> I got error from gcc that it does not know those macros:
>>> ‘SER_RS485_USE_GPIO’ was not declared in this scope
>>>  rs485conf.flags |= SER_RS485_USE_GPIO;
>>> ‘struct serial_rs485’ has no member named ‘gpio_pin’
>>>   rs485conf.gpio_pin = GPIO0_9;
>>> ‘GPIO0_9’ was not declared in this scope
>>>   rs485conf.gpio_pin = GPIO0_9;
>>>
>>>  
>> That's because you're compiling with the standard libc headers, which 
>> don't include the modified serial_rs485 struct that uses the GPIO pin. The 
>> tutorial I linked above uses Python and just defines the same values 
>> locally, which you could do in C as well. You could also grab the Kernel 
>> source and include 'include/uapi/linux/serial.h', which has the patched 
>> serial_rs485 struct (
>> https://github.com/RobertCNelson/bb-kernel/blob/am33x-v3.8/patches/fixes/0007-omap-RS485-support-by-Michael-Musset.patch#L201
>> ). 
>>
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/128d1fae-46ac-4e2d-a759-1cb1568f443c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: BBB UART4 RTS for RS-485

2014-09-04 Thread Micka

In the Debian image from Robert C Nelson, the patch rs485 is already
included.
Le 4 sept. 2014 20:57,  a écrit :

> Thank you for your answers. The python code is working perfectly.
> I need to use it in greater C project though. So I am compiling new kernel
> including RS485 patch. I have tried /opt/scripts/tools/update_kernel.sh
> hoping that it includes the RS485 patch ...unsuccessfully.
> I am now following steps from
> http://jkridner.wordpress.com/2014/06/04/yet-another-set-of-notes-on-building-beaglebone-kernel/
>
> Dne středa, 3. září 2014 17:57:53 UTC+2 lucaso...@gmail.com napsal(a):
>>
>> Hello,
>> I'm writing an app for BeagleBoneBlack running debian (3.8.13-bone50). I
>> would like to use UART4 to communicate with RS485 transmitter over
>> P9.24(UART4 Tx), P9.26(UART4 Rx) and P8.33 (UART4 RTS).
>> I've disabled HDMI and enabled overlays BB-UART4 and BB-UART4-RTSCTS
>>
>> cat /sys/devices/bone_capemgr.9/slots
>>  0: 54:PF---
>>  1: 55:PF---
>>  2: 56:PF---
>>  3: 57:PF---
>>  4: ff:P-O-L Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G
>>  5: ff:P-O-- Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI
>>  6: ff:P-O-- Bone-Black-HDMIN,00A0,Texas Instrument,BB-BONELT-HDMIN
>>  7: ff:P-O-L Override Board Name,00A0,Override Manuf,BB-UART4
>> 10: ff:P-O-L Override Board Name,00A0,Override Manuf,BB-UART4-RTSCTS
>>
>> cat /proc/tty/driver/OMAP-SERIAL
>> serinfo:1.0 driver revision:
>> 0: uart:OMAP UART0 mmio:0x44E09000 irq:72 tx:345 rx:0 RTS|CTS|DTR|DSR
>> 4: uart:OMAP UART4 mmio:0x481A8000 irq:45 tx:61355 rx:1 brk:1 RTS|DTR|DSR
>>
>>
>> RS485 transmitter is connected through RS485-USB converter to PC. When I
>> run screen /dev/ttyO4 9600 +crtscts and periodicaly write some data to it,
>> PC receives it properly, but RTS line stays constantly low (I'm using scope
>> on Tx and RTS lines).
>> I've also tried to write simple C program, using *struct serial_rs485. *When
>> I write some data over this program, I got response: *Resource
>> temporarily unavailable* and dmesg says
>> *omap_uart 481a8000.serial: Must use GPIO for RS485 Support.*When I
>> tried to use:
>> struct serial_rs485 rs485conf;
>> rs485conf.flags |= SER_RS485_USE_GPIO;
>> rs485conf.gpio_pin = GPIO0_9;
>>
>> I got error from gcc that it does not know those macros:
>> ‘SER_RS485_USE_GPIO’ was not declared in this scope
>>  rs485conf.flags |= SER_RS485_USE_GPIO;
>> ‘struct serial_rs485’ has no member named ‘gpio_pin’
>>   rs485conf.gpio_pin = GPIO0_9;
>> ‘GPIO0_9’ was not declared in this scope
>>   rs485conf.gpio_pin = GPIO0_9;
>>
>> Could somebody help me? I have no more ideas.
>>
>>
>>
>>
>>
>>  --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: BBB UART4 RTS for RS-485

2014-09-08 Thread lucaso . janik

I've downloaded Robert C Nelson's code and run build_kernel.sh and 
install_kernel.sh. I've controlled that sources are patched by rs485 patch.
BBB booted up normally and uname -r says that I am running new kernel. But 
I don't have patched kernel headers. I have created serial.h header as 
following:
 1 #include 
  2 
  3 
  4 struct serial_rs485 {
  5 __u32   flags;  /* RS485 feature flags */
  6 #define SER_RS485_ENABLED   (1 << 0)/* If enabled */
  7 #define SER_RS485_RTS_ON_SEND   (1 << 1)/* Logical 
level for
  8RTS pin when 

  9sending */
 10 #define SER_RS485_RTS_AFTER_SEND(1 << 2)/* Logical 
level for
 11RTS pin 
after sent*/
 12 #define SER_RS485_RTS_BEFORE_SEND (1 << 3)
 13 #define SER_RS485_USE_GPIO (1 << 5)
 14 //#define SER_RS485_RX_DURING_TX  (1 << 4)
 15 __u32   delay_rts_before_send;  /* Delay before send 
(milliseconds) */
 16 __u32   delay_rts_after_send;   /* Delay after send 
(milliseconds) */
 17 //   __u32   padding[5]; /* Memory is cheap, new structs
 18 __u32 gpio_pin; /* GPIO Pin Index */
 19 __u32 padding[4]; /* Memory is cheap, new structs
 20 are a royal PITA .. */
 21 };


and used it in small example program:
#include 
#include 
#include 
#include 
#include "serial.h"
//#include 
#include 
#include 

int main()
{
int fd = open("/dev/ttyO4", O_RDWR | O_NOCTTY | O_NDELAY);
if (fd < 0)
{
perror("Error opening tty!");
return 1;
}

struct serial_rs485 rs485conf;

rs485conf.flags |= SER_RS485_ENABLED;

rs485conf.flags |= SER_RS485_USE_GPIO;
rs485conf.gpio_pin = 9;
rs485conf.flags |= SER_RS485_RTS_ON_SEND;
rs485conf.flags &= ~(SER_RS485_RTS_AFTER_SEND);
rs485conf.delay_rts_before_send = 0;
rs485conf.delay_rts_after_send = 0;

if (ioctl (fd, TIOCSRS485, &rs485conf) < 0)
{
perror("Bad ioctl");
}

struct termios ttyc;
tcgetattr(fd, &ttyc);

cfsetospeed(&ttyc, B9600);   
cfsetispeed(&ttyc, B9600);
ttyc.c_cflag &= ~CRTSCTS;
ttyc.c_cflag |= CS8 | CLOCAL | CREAD;
ttyc.c_cflag |= CRTSCTS;
ttyc.c_cc[VMIN] = 1;
ttyc.c_cc[VTIME] = 5;
tcsetattr(fd, TCSANOW, &ttyc);

char data = 0xAA;

int i = 0;
while(i < 1)
{
if(write(fd, &data, 1) < 1)
{
perror("Error sending char");
break;
}

i++;
}

if (close (fd) < 0)
{
perror("Error closing tty!");
return 1;
}


return 0;
}
but RTS pin stays still LOW.


Dne čtvrtek, 4. září 2014 21:51:58 UTC+2 Mickae1 napsal(a):
>
> In the Debian image from Robert C Nelson, the patch rs485 is already 
> included. 
> Le 4 sept. 2014 20:57, > a écrit :
>
>> Thank you for your answers. The python code is working perfectly. 
>> I need to use it in greater C project though. So I am compiling new 
>> kernel including RS485 patch. I have tried 
>> /opt/scripts/tools/update_kernel.sh hoping that it includes the RS485 patch 
>> ...unsuccessfully.
>> I am now following steps from 
>> http://jkridner.wordpress.com/2014/06/04/yet-another-set-of-notes-on-building-beaglebone-kernel/
>>
>> Dne středa, 3. září 2014 17:57:53 UTC+2 lucaso...@gmail.com napsal(a):
>>>
>>> Hello,
>>> I'm writing an app for BeagleBoneBlack running debian (3.8.13-bone50). I 
>>> would like to use UART4 to communicate with RS485 transmitter over 
>>> P9.24(UART4 Tx), P9.26(UART4 Rx) and P8.33 (UART4 RTS). 
>>> I've disabled HDMI and enabled overlays BB-UART4 and BB-UART4-RTSCTS
>>>
>>>  cat /sys/devices/bone_capemgr.9/slots
>>>  0: 54:PF--- 
>>>  1: 55:PF--- 
>>>  2: 56:PF--- 
>>>  3: 57:PF--- 
>>>  4: ff:P-O-L Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G
>>>  5: ff:P-O-- Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI
>>>  6: ff:P-O-- Bone-Black-HDMIN,00A0,Texas Instrument,BB-BONELT-HDMIN
>>>  7: ff:P-O-L Override Board Name,00A0,Override Manuf,BB-UART4
>>> 10: ff:P-O-L Override Board Name,00A0,Override Manuf,BB-UART4-RTSCTS
>>>
>>> cat /proc/tty/driver/OMAP-SERIAL 
>>> serinfo:1.0 driver revision:
>>> 0: uart:OMAP UART0 mmio:0x44E09000 irq:72 tx:345 rx:0 RTS|CTS|DTR|DSR
>>> 4: uart:OMAP UART4 mmio:0x481A8000 irq:45 tx:61355 rx:1 brk:1 RTS|DTR|
>>> DSR
>>>
>>>
>>> RS485 transmitter is connected through RS485-USB converter to PC. When I 
>>> run screen /dev/ttyO4 9600 +crtscts and periodicaly write some data to it, 
>>> PC receives it properly, but RTS line stays constantly low (I'm using scope 
>>> on Tx and RTS lines). 
>>> I've also tried to write simple C program, using *struct serial_rs485. 
>>> *When 
>>> I write some data over this program, I got response: *Resource

Re: [beagleboard] Re: BBB UART4 RTS for RS-485

2014-09-08 Thread Micka

Normally If you look at the log (dmsg)  you should see a line rs485
something. It's a printk that I show when the ioctl work.

And of course you have to configure the pin correctly = pin mode for TX,
rx,  gpio.
Le 8 sept. 2014 17:27,  a écrit :

> I've downloaded Robert C Nelson's code and run build_kernel.sh and
> install_kernel.sh. I've controlled that sources are patched by rs485 patch.
> BBB booted up normally and uname -r says that I am running new kernel. But
> I don't have patched kernel headers. I have created serial.h header as
> following:
>  1 #include 
>   2
>   3
>   4 struct serial_rs485 {
>   5 __u32   flags;  /* RS485 feature flags */
>   6 #define SER_RS485_ENABLED   (1 << 0)/* If enabled
> */
>   7 #define SER_RS485_RTS_ON_SEND   (1 << 1)/* Logical
> level for
>   8RTS pin
> when
>   9sending */
>  10 #define SER_RS485_RTS_AFTER_SEND(1 << 2)/* Logical
> level for
>  11RTS pin
> after sent*/
>  12 #define SER_RS485_RTS_BEFORE_SEND (1 << 3)
>  13 #define SER_RS485_USE_GPIO (1 << 5)
>  14 //#define SER_RS485_RX_DURING_TX  (1 << 4)
>  15 __u32   delay_rts_before_send;  /* Delay before send
> (milliseconds) */
>  16 __u32   delay_rts_after_send;   /* Delay after send
> (milliseconds) */
>  17 //   __u32   padding[5]; /* Memory is cheap, new
> structs
>  18 __u32 gpio_pin; /* GPIO Pin Index */
>  19 __u32 padding[4]; /* Memory is cheap, new structs
>  20 are a royal PITA .. */
>  21 };
>
>
> and used it in small example program:
> #include 
> #include 
> #include 
> #include 
> #include "serial.h"
> //#include 
> #include 
> #include 
>
> int main()
> {
> int fd = open("/dev/ttyO4", O_RDWR | O_NOCTTY | O_NDELAY);
> if (fd < 0)
> {
> perror("Error opening tty!");
> return 1;
> }
>
> struct serial_rs485 rs485conf;
>
> rs485conf.flags |= SER_RS485_ENABLED;
>
> rs485conf.flags |= SER_RS485_USE_GPIO;
> rs485conf.gpio_pin = 9;
> rs485conf.flags |= SER_RS485_RTS_ON_SEND;
> rs485conf.flags &= ~(SER_RS485_RTS_AFTER_SEND);
> rs485conf.delay_rts_before_send = 0;
> rs485conf.delay_rts_after_send = 0;
>
> if (ioctl (fd, TIOCSRS485, &rs485conf) < 0)
> {
> perror("Bad ioctl");
> }
>
> struct termios ttyc;
> tcgetattr(fd, &ttyc);
>
> cfsetospeed(&ttyc, B9600);
> cfsetispeed(&ttyc, B9600);
> ttyc.c_cflag &= ~CRTSCTS;
> ttyc.c_cflag |= CS8 | CLOCAL | CREAD;
> ttyc.c_cflag |= CRTSCTS;
> ttyc.c_cc[VMIN] = 1;
> ttyc.c_cc[VTIME] = 5;
> tcsetattr(fd, TCSANOW, &ttyc);
>
> char data = 0xAA;
>
> int i = 0;
> while(i < 1)
> {
> if(write(fd, &data, 1) < 1)
> {
> perror("Error sending char");
> break;
> }
>
> i++;
> }
>
> if (close (fd) < 0)
> {
> perror("Error closing tty!");
> return 1;
> }
>
>
> return 0;
> }
> but RTS pin stays still LOW.
>
>
> Dne čtvrtek, 4. září 2014 21:51:58 UTC+2 Mickae1 napsal(a):
>>
>> In the Debian image from Robert C Nelson, the patch rs485 is already
>> included.
>> Le 4 sept. 2014 20:57,  a écrit :
>>
>>> Thank you for your answers. The python code is working perfectly.
>>> I need to use it in greater C project though. So I am compiling new
>>> kernel including RS485 patch. I have tried 
>>> /opt/scripts/tools/update_kernel.sh
>>> hoping that it includes the RS485 patch ...unsuccessfully.
>>> I am now following steps from http://jkridner.wordpress.com/
>>> 2014/06/04/yet-another-set-of-notes-on-building-beaglebone-kernel/
>>>
>>> Dne středa, 3. září 2014 17:57:53 UTC+2 lucaso...@gmail.com napsal(a):

 Hello,
 I'm writing an app for BeagleBoneBlack running debian (3.8.13-bone50).
 I would like to use UART4 to communicate with RS485 transmitter over
 P9.24(UART4 Tx), P9.26(UART4 Rx) and P8.33 (UART4 RTS).
 I've disabled HDMI and enabled overlays BB-UART4 and BB-UART4-RTSCTS

  cat /sys/devices/bone_capemgr.9/slots
  0: 54:PF---
  1: 55:PF---
  2: 56:PF---
  3: 57:PF---
  4: ff:P-O-L Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G
  5: ff:P-O-- Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI
  6: ff:P-O-- Bone-Black-HDMIN,00A0,Texas Instrument,BB-BONELT-HDMIN
  7: ff:P-O-L Override Board Name,00A0,Override Manuf,BB-UART4
 10: ff:P-O-L Override Board Name,00A0,Override Manuf,BB-UART4-RTSCTS

 cat /proc/tty/driver/OMAP-SERIAL
 serinfo:1.0 driver revision:
 0: uart:OMAP UART0 mmio:0x44E09000 irq:72 tx:345 rx:0 RTS|CTS|DTR|DSR
 4: uart:OMAP UART4 mmio:0x481A8000 irq:45 tx:61355 rx:1 brk:1 RTS|DTR|
 DSR

Re: [beagleboard] Re: BBB UART4 RTS for RS-485

2014-09-08 Thread Alexander Hiam



Normally If you look at the log (dmsg)  you should see a line rs485 
> something. It's a printk that I show when the ioctl work.
>
Right, it's 'rs485 v1.1'. If you see that in dmesg then the ioctl worked 
and it's almost certainly a pinmux issue.
 

> And of course you have to configure the pin correctly = pin mode for TX, 
> rx,  gpio. 
> Le 8 sept. 2014 17:27, > a écrit :
>
>> I've downloaded Robert C Nelson's code and run build_kernel.sh and 
>> install_kernel.sh. I've controlled that sources are patched by rs485 patch.
>> BBB booted up normally and uname -r says that I am running new kernel. 
>> But I don't have patched kernel headers. I have created serial.h header as 
>> following:
>>  1 #include 
>>   2 
>>   3 
>>   4 struct serial_rs485 {
>>   5 __u32   flags;  /* RS485 feature flags */
>>   6 #define SER_RS485_ENABLED   (1 << 0)/* If 
>> enabled */
>>   7 #define SER_RS485_RTS_ON_SEND   (1 << 1)/* Logical 
>> level for
>>   8RTS pin 
>> when 
>>   9sending */
>>  10 #define SER_RS485_RTS_AFTER_SEND(1 << 2)/* Logical 
>> level for
>>  11RTS pin 
>> after sent*/
>>  12 #define SER_RS485_RTS_BEFORE_SEND (1 << 3)
>>  13 #define SER_RS485_USE_GPIO (1 << 5)
>>  14 //#define SER_RS485_RX_DURING_TX  (1 << 4)
>>  15 __u32   delay_rts_before_send;  /* Delay before send 
>> (milliseconds) */
>>  16 __u32   delay_rts_after_send;   /* Delay after send 
>> (milliseconds) */
>>  17 //   __u32   padding[5]; /* Memory is cheap, new 
>> structs
>>  18 __u32 gpio_pin; /* GPIO Pin Index */
>>  19 __u32 padding[4]; /* Memory is cheap, new structs
>>  20 are a royal PITA .. */
>>  21 };
>>
>>
>> and used it in small example program:
>> #include 
>> #include 
>> #include 
>> #include 
>> #include "serial.h"
>> //#include 
>> #include 
>> #include 
>>
>> int main()
>> {
>> int fd = open("/dev/ttyO4", O_RDWR | O_NOCTTY | O_NDELAY);
>> if (fd < 0)
>> {
>> perror("Error opening tty!");
>> return 1;
>> }
>>
>> struct serial_rs485 rs485conf;
>>
>> rs485conf.flags |= SER_RS485_ENABLED;
>>
>> rs485conf.flags |= SER_RS485_USE_GPIO;
>> rs485conf.gpio_pin = 9;
>> rs485conf.flags |= SER_RS485_RTS_ON_SEND;
>> rs485conf.flags &= ~(SER_RS485_RTS_AFTER_SEND);
>> rs485conf.delay_rts_before_send = 0;
>> rs485conf.delay_rts_after_send = 0;
>>
>> if (ioctl (fd, TIOCSRS485, &rs485conf) < 0)
>> {
>> perror("Bad ioctl");
>> }
>> 
>> struct termios ttyc;
>> tcgetattr(fd, &ttyc);
>> 
>> cfsetospeed(&ttyc, B9600);   
>> cfsetispeed(&ttyc, B9600);
>> ttyc.c_cflag &= ~CRTSCTS;
>> ttyc.c_cflag |= CS8 | CLOCAL | CREAD;
>> ttyc.c_cflag |= CRTSCTS;
>> ttyc.c_cc[VMIN] = 1;
>> ttyc.c_cc[VTIME] = 5;
>> tcsetattr(fd, TCSANOW, &ttyc);
>> 
>> char data = 0xAA;
>>
>> int i = 0;
>> while(i < 1)
>> {
>> if(write(fd, &data, 1) < 1)
>> {
>> perror("Error sending char");
>> break;
>> }
>> 
>> i++;
>> }
>> 
>> if (close (fd) < 0)
>> {
>> perror("Error closing tty!");
>> return 1;
>> }
>>
>>
>> return 0;
>> }
>> but RTS pin stays still LOW.
>>
>>
>> Dne čtvrtek, 4. září 2014 21:51:58 UTC+2 Mickae1 napsal(a):
>>>
>>> In the Debian image from Robert C Nelson, the patch rs485 is already 
>>> included. 
>>> Le 4 sept. 2014 20:57,  a écrit :
>>>
 Thank you for your answers. The python code is working perfectly. 
 I need to use it in greater C project though. So I am compiling new 
 kernel including RS485 patch. I have tried 
 /opt/scripts/tools/update_kernel.sh 
 hoping that it includes the RS485 patch ...unsuccessfully.
 I am now following steps from http://jkridner.wordpress.com/
 2014/06/04/yet-another-set-of-notes-on-building-beaglebone-kernel/

 Dne středa, 3. září 2014 17:57:53 UTC+2 lucaso...@gmail.com napsal(a):
>
> Hello,
> I'm writing an app for BeagleBoneBlack running debian (3.8.13-bone50). 
> I would like to use UART4 to communicate with RS485 transmitter over 
> P9.24(UART4 Tx), P9.26(UART4 Rx) and P8.33 (UART4 RTS). 
> I've disabled HDMI and enabled overlays BB-UART4 and BB-UART4-RTSCTS
>
>  cat /sys/devices/bone_capemgr.9/slots
>  0: 54:PF--- 
>  1: 55:PF--- 
>  2: 56:PF--- 
>  3: 57:PF--- 
>  4: ff:P-O-L Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G
>  5: ff:P-O-- Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI
>  6: ff:P-O-- Bone-Black-HDMIN,00A0,Texas Instrument,BB-BONELT-HDMIN
>  7: ff:P-O-L Override Board Name,0

Re: [beagleboard] Re: BBB UART4 RTS for RS-485

2014-09-09 Thread lucaso . janik

Yes, I can see 'rs485 v1.1'. The python code still works fine out of the 
box. C code Rx and Tx lines work OK but RTS still does nothing.
When I exported the GPIO9 by hand, dmesg got:
[  222.055685] gpio_request: gpio-9 (RS485 TXE) status -16
[  222.055730] omap_uart 481a8000.serial: Could not request GPIO 9 : -16

That means that 485 kernel support works. Without manually exporting it 
says just "[  537.089146] rs485 v1.1" and does nothing.

BUT now I've discovered something strange with logical level flags in 
struct serial_rs485, maybe I'm using different header or maybe I don't 
understand it correctly.
When I changed the SER_RS485_RTS_AFTER_SEND to 0 and SER_RS485_RTS_ON_SEND 
to 0,* it started working fine*. 
That means, when sending data, RTS goes HIGH, after sending, it goes 
immediately LOW , that means, 
I expected setting ON_SEND to 1 and AFTER_SEND to 0, but with this setting 
it just changed from LOW to LOW.

Thank you both again for Your valuable help.
I'm satisfied now :-)


Dne pondělí, 8. září 2014 19:12:55 UTC+2 Alexander Hiam napsal(a):
>
>
>
> Normally If you look at the log (dmsg)  you should see a line rs485 
>> something. It's a printk that I show when the ioctl work.
>>
> Right, it's 'rs485 v1.1'. If you see that in dmesg then the ioctl worked 
> and it's almost certainly a pinmux issue.
>  
>
>> And of course you have to configure the pin correctly = pin mode for TX, 
>> rx,  gpio. 
>> Le 8 sept. 2014 17:27,  a écrit :
>>
>>> I've downloaded Robert C Nelson's code and run build_kernel.sh and 
>>> install_kernel.sh. I've controlled that sources are patched by rs485 patch.
>>> BBB booted up normally and uname -r says that I am running new kernel. 
>>> But I don't have patched kernel headers. I have created serial.h header as 
>>> following:
>>>  1 #include 
>>>   2 
>>>   3 
>>>   4 struct serial_rs485 {
>>>   5 __u32   flags;  /* RS485 feature flags */
>>>   6 #define SER_RS485_ENABLED   (1 << 0)/* If 
>>> enabled */
>>>   7 #define SER_RS485_RTS_ON_SEND   (1 << 1)/* Logical 
>>> level for
>>>   8RTS pin 
>>> when 
>>>   9sending */
>>>  10 #define SER_RS485_RTS_AFTER_SEND(1 << 2)/* Logical 
>>> level for
>>>  11RTS pin 
>>> after sent*/
>>>  12 #define SER_RS485_RTS_BEFORE_SEND (1 << 3)
>>>  13 #define SER_RS485_USE_GPIO (1 << 5)
>>>  14 //#define SER_RS485_RX_DURING_TX  (1 << 4)
>>>  15 __u32   delay_rts_before_send;  /* Delay before send 
>>> (milliseconds) */
>>>  16 __u32   delay_rts_after_send;   /* Delay after send 
>>> (milliseconds) */
>>>  17 //   __u32   padding[5]; /* Memory is cheap, new 
>>> structs
>>>  18 __u32 gpio_pin; /* GPIO Pin Index */
>>>  19 __u32 padding[4]; /* Memory is cheap, new structs
>>>  20 are a royal PITA .. */
>>>  21 };
>>>
>>>
>>> and used it in small example program:
>>> #include 
>>> #include 
>>> #include 
>>> #include 
>>> #include "serial.h"
>>> //#include 
>>> #include 
>>> #include 
>>>
>>> int main()
>>> {
>>> int fd = open("/dev/ttyO4", O_RDWR | O_NOCTTY | O_NDELAY);
>>> if (fd < 0)
>>> {
>>> perror("Error opening tty!");
>>> return 1;
>>> }
>>>
>>> struct serial_rs485 rs485conf;
>>>
>>> rs485conf.flags |= SER_RS485_ENABLED;
>>>
>>> rs485conf.flags |= SER_RS485_USE_GPIO;
>>> rs485conf.gpio_pin = 9;
>>> rs485conf.flags |= SER_RS485_RTS_ON_SEND;
>>> rs485conf.flags &= ~(SER_RS485_RTS_AFTER_SEND);
>>> rs485conf.delay_rts_before_send = 0;
>>> rs485conf.delay_rts_after_send = 0;
>>>
>>> if (ioctl (fd, TIOCSRS485, &rs485conf) < 0)
>>> {
>>> perror("Bad ioctl");
>>> }
>>> 
>>> struct termios ttyc;
>>> tcgetattr(fd, &ttyc);
>>> 
>>> cfsetospeed(&ttyc, B9600);   
>>> cfsetispeed(&ttyc, B9600);
>>> ttyc.c_cflag &= ~CRTSCTS;
>>> ttyc.c_cflag |= CS8 | CLOCAL | CREAD;
>>> ttyc.c_cflag |= CRTSCTS;
>>> ttyc.c_cc[VMIN] = 1;
>>> ttyc.c_cc[VTIME] = 5;
>>> tcsetattr(fd, TCSANOW, &ttyc);
>>> 
>>> char data = 0xAA;
>>>
>>> int i = 0;
>>> while(i < 1)
>>> {
>>> if(write(fd, &data, 1) < 1)
>>> {
>>> perror("Error sending char");
>>> break;
>>> }
>>> 
>>> i++;
>>> }
>>> 
>>> if (close (fd) < 0)
>>> {
>>> perror("Error closing tty!");
>>> return 1;
>>> }
>>>
>>>
>>> return 0;
>>> }
>>> but RTS pin stays still LOW.
>>>
>>>
>>> Dne čtvrtek, 4. září 2014 21:51:58 UTC+2 Mickae1 napsal(a):

 In the Debian image from Robert C Nelson, the patch rs485 is already 
 included. 
 Le 4 sept. 2014 20:57,  a écrit :

> Thank you

Re: [beagleboard] Re: BBB UART4 RTS for RS-485

2014-09-09 Thread Alexander Hiam



On Tuesday, September 9, 2014 8:09:32 AM UTC-4, lucaso...@gmail.com wrote:
>
> Yes, I can see 'rs485 v1.1'. The python code still works fine out of the 
> box. C code Rx and Tx lines work OK but RTS still does nothing.
> When I exported the GPIO9 by hand, dmesg got:
> [  222.055685] gpio_request: gpio-9 (RS485 TXE) status -16
> [  222.055730] omap_uart 481a8000.serial: Could not request GPIO 9 : -16
>
> That means that 485 kernel support works. Without manually exporting it 
> says just "[  537.089146] rs485 v1.1" and does nothing.
>
> BUT now I've discovered something strange with logical level flags in 
> struct serial_rs485, maybe I'm using different header or maybe I don't 
> understand it correctly.
> When I changed the SER_RS485_RTS_AFTER_SEND to 0 and SER_RS485_RTS_ON_SEND 
> to 0,* it started working fine*. 
> That means, when sending data, RTS goes HIGH, after sending, it goes 
> immediately LOW , that means, 
> I expected setting ON_SEND to 1 and AFTER_SEND to 0, but with this setting 
> it just changed from LOW to LOW.
>

Oh yeah, forgot about that. There's a couple ternary operators in the 
driver that I think might be backwards, which makes it the logic levels a 
bit counter intuitive. It's:
  SER_RS485_ENABLED | SER_RS485_USE_GPIO 
for an active high RE/DE signal and:
  SER_RS485_ENABLED | SER_RS485_USE_GPIO | SER_RS485_RTS_ON_SEND | 
SER_RS485_RTS_AFTER_SEND
for an inverted, active low RE/DE signal.

>
> Thank you both again for Your valuable help.
> I'm satisfied now :-)
>
>
> Dne pondělí, 8. září 2014 19:12:55 UTC+2 Alexander Hiam napsal(a):
>
>
>
> Normally If you look at the log (dmsg)  you should see a line rs485 
> something. It's a printk that I show when the ioctl work.
>
> Right, it's 'rs485 v1.1'. If you see that in dmesg then the ioctl worked 
> and it's almost certainly a pinmux issue.
>  
>
> And of course you have to configure the pin correctly = pin mode for TX, 
> rx,  gpio. 
> Le 8 sept. 2014 17:27,  a écrit :
>
> I've downloaded Robert C Nelson's code and run build_kernel.sh and 
> install_kernel.sh. I've controlled that sources are patched by rs485 patch.
> BBB booted up normally and uname -r says that I am running new kernel. But 
> I don't have patched kernel headers. I have created serial.h header as 
> following:
>  1 #include 
>   2 
>   3 
>   4 struct serial_rs485 {
>   5 __u32   flags;  /* RS485 feature flags */
>   6 #define SER_RS485_ENABLED   (1 << 0)/* If enabled 
> */
>   7 #define SER_RS485_RTS_ON_SEND   (1 << 1)/* Logical 
> level for
>   8RTS pin 
> when 
>   9sending */
>  10 #define SER_RS485_RTS_AFTER_SEND(1 << 2)/* Logical 
> level for
>  11RTS pin 
> after sent*/
>  12 #define SER_RS485_RTS_BEFORE_SEND (1 << 3)
>  13 #define SER_RS485_USE_GPIO (1 << 5)
>  14 //#define SER_RS485_RX_DURING_TX  (1 << 4)
>  15 __u32   delay_rts_before_send;  /* Delay before send 
> (milliseconds) */
>  16 __u32   delay_rts_after_send;   /* Delay after send 
> (milliseconds) */
>  17 //   __u32   padding[5]; /* Memory is cheap, new 
> structs
>  18 __u32 gpio_pin; /* GPIO Pin Index */
>  19 __u32 padding[4]; /* Memory is cheap, new structs
>  20 are a royal PITA .. */
>  21 };
>
>
> and used it in small example program:
> #include 
> #include 
> #include 
> #include 
> #include "serial.h"
> //#include 
> #include 
> #include 
>
> int main()
> {
> int fd = open("/dev/ttyO4", O_RDWR | O_NOCTTY | O_NDELAY);
> if (fd < 0)
> {
> perror("Error opening tty!");
> return 1;
> }
>
> struct serial_rs485 rs485conf;
>
> rs485conf.flags |= SER_RS485_ENABLED;
>
> rs485conf.flags |= SER_RS485_USE_GPIO;
> rs485conf.gpio_pin = 9;
> rs485conf.flags |= SER_RS485_RTS_ON_SEND;
> rs485conf.flags &= ~(SER_RS485_RTS_AFTER_SEND);
> rs485conf.delay_rts_before_send = 0;
> rs485conf.delay_rts_after_send = 0;
>
> if (ioctl (fd, TIOCSRS485, &rs485conf) < 0)
> {
> perror("Bad ioctl");
> }
> 
> struct termios ttyc;
> tcgetattr(fd, &ttyc);
> 
> cfsetospeed(&ttyc, B9600);   
> cfsetispeed(&ttyc, B9600);
> ttyc.c_cflag &= ~CRTSCTS;
> ttyc.c_cflag |= CS8 | CLOCAL | CREAD;
> ttyc.c_cflag |= CRTSCTS;
> ttyc.c_cc[VMIN] = 1;
> ttyc.c_cc[VTIME] = 5;
> tcsetattr(fd, TCSANOW, &ttyc);
> 
> char data = 0xAA;
>
> int i = 0;
> while(i < 1)
> {
> if(write(fd, &data, 1) < 1)
> {
> perror("Error sending char");
> break;
> }
> 
> i++;
> }
> 
> if (close (fd) < 0)
> {
> perror("Error closing tty!");
> return

Re: [beagleboard] Re: BBB UART4 RTS for RS-485

2014-09-12 Thread Micka

Hello, everyone, I just notify something with the RS485 :


I've made a test programm, and in this programm, I'm sending all the time
one byte.

With the oscilloscope, I can see that there is a delay between each frame :
100ms .


Do you have the same thing ?


Micka,






On Tue, Sep 9, 2014 at 6:26 PM, Alexander Hiam 
wrote:

>
>
> On Tuesday, September 9, 2014 8:09:32 AM UTC-4, lucaso...@gmail.com wrote:
>>
>> Yes, I can see 'rs485 v1.1'. The python code still works fine out of the
>> box. C code Rx and Tx lines work OK but RTS still does nothing.
>> When I exported the GPIO9 by hand, dmesg got:
>> [  222.055685] gpio_request: gpio-9 (RS485 TXE) status -16
>> [  222.055730] omap_uart 481a8000.serial: Could not request GPIO 9 : -16
>>
>> That means that 485 kernel support works. Without manually exporting it
>> says just "[  537.089146] rs485 v1.1" and does nothing.
>>
>> BUT now I've discovered something strange with logical level flags in
>> struct serial_rs485, maybe I'm using different header or maybe I don't
>> understand it correctly.
>> When I changed the SER_RS485_RTS_AFTER_SEND to 0 and
>> SER_RS485_RTS_ON_SEND to 0,* it started working fine*.
>> That means, when sending data, RTS goes HIGH, after sending, it goes
>> immediately LOW , that means,
>> I expected setting ON_SEND to 1 and AFTER_SEND to 0, but with this
>> setting it just changed from LOW to LOW.
>>
>
> Oh yeah, forgot about that. There's a couple ternary operators in the
> driver that I think might be backwards, which makes it the logic levels a
> bit counter intuitive. It's:
>   SER_RS485_ENABLED | SER_RS485_USE_GPIO
> for an active high RE/DE signal and:
>   SER_RS485_ENABLED | SER_RS485_USE_GPIO | SER_RS485_RTS_ON_SEND |
> SER_RS485_RTS_AFTER_SEND
> for an inverted, active low RE/DE signal.
>
>>
>> Thank you both again for Your valuable help.
>> I'm satisfied now :-)
>>
>>
>> Dne pondělí, 8. září 2014 19:12:55 UTC+2 Alexander Hiam napsal(a):
>>
>>
>>
>> Normally If you look at the log (dmsg)  you should see a line rs485
>> something. It's a printk that I show when the ioctl work.
>>
>> Right, it's 'rs485 v1.1'. If you see that in dmesg then the ioctl worked
>> and it's almost certainly a pinmux issue.
>>
>>
>> And of course you have to configure the pin correctly = pin mode for TX,
>> rx,  gpio.
>> Le 8 sept. 2014 17:27,  a écrit :
>>
>> I've downloaded Robert C Nelson's code and run build_kernel.sh and
>> install_kernel.sh. I've controlled that sources are patched by rs485 patch.
>> BBB booted up normally and uname -r says that I am running new kernel.
>> But I don't have patched kernel headers. I have created serial.h header as
>> following:
>>  1 #include 
>>   2
>>   3
>>   4 struct serial_rs485 {
>>   5 __u32   flags;  /* RS485 feature flags */
>>   6 #define SER_RS485_ENABLED   (1 << 0)/* If
>> enabled */
>>   7 #define SER_RS485_RTS_ON_SEND   (1 << 1)/* Logical
>> level for
>>   8RTS pin
>> when
>>   9sending */
>>  10 #define SER_RS485_RTS_AFTER_SEND(1 << 2)/* Logical
>> level for
>>  11RTS pin
>> after sent*/
>>  12 #define SER_RS485_RTS_BEFORE_SEND (1 << 3)
>>  13 #define SER_RS485_USE_GPIO (1 << 5)
>>  14 //#define SER_RS485_RX_DURING_TX  (1 << 4)
>>  15 __u32   delay_rts_before_send;  /* Delay before send
>> (milliseconds) */
>>  16 __u32   delay_rts_after_send;   /* Delay after send
>> (milliseconds) */
>>  17 //   __u32   padding[5]; /* Memory is cheap, new
>> structs
>>  18 __u32 gpio_pin; /* GPIO Pin Index */
>>  19 __u32 padding[4]; /* Memory is cheap, new structs
>>  20 are a royal PITA .. */
>>  21 };
>>
>>
>> and used it in small example program:
>> #include 
>> #include 
>> #include 
>> #include 
>> #include "serial.h"
>> //#include 
>> #include 
>> #include 
>>
>> int main()
>> {
>> int fd = open("/dev/ttyO4", O_RDWR | O_NOCTTY | O_NDELAY);
>> if (fd < 0)
>> {
>> perror("Error opening tty!");
>> return 1;
>> }
>>
>> struct serial_rs485 rs485conf;
>>
>> rs485conf.flags |= SER_RS485_ENABLED;
>>
>> rs485conf.flags |= SER_RS485_USE_GPIO;
>> rs485conf.gpio_pin = 9;
>> rs485conf.flags |= SER_RS485_RTS_ON_SEND;
>> rs485conf.flags &= ~(SER_RS485_RTS_AFTER_SEND);
>> rs485conf.delay_rts_before_send = 0;
>> rs485conf.delay_rts_after_send = 0;
>>
>> if (ioctl (fd, TIOCSRS485, &rs485conf) < 0)
>> {
>> perror("Bad ioctl");
>> }
>>
>> struct termios ttyc;
>> tcgetattr(fd, &ttyc);
>>
>> cfsetospeed(&ttyc, B9600);
>> cfsetispeed(&ttyc, B9600);
>> ttyc.c_cflag &= ~CRTSCTS;
>> ttyc.c_cflag |= CS8 | CLOCAL | CREAD;
>> ttyc.c_cflag |= CRTSCTS;
>> ttyc.c_cc[VMIN] =

Re: [beagleboard] Re: BBB UART4 RTS for RS-485

2014-09-12 Thread Micka

my problem was two program working on the same uart ...^^

On Fri, Sep 12, 2014 at 10:39 AM, Micka  wrote:

> Hello, everyone, I just notify something with the RS485 :
>
>
> I've made a test programm, and in this programm, I'm sending all the time
> one byte.
>
> With the oscilloscope, I can see that there is a delay between each frame
> : 100ms .
>
>
> Do you have the same thing ?
>
>
> Micka,
>
>
>
>
>
>
> On Tue, Sep 9, 2014 at 6:26 PM, Alexander Hiam 
> wrote:
>
>>
>>
>> On Tuesday, September 9, 2014 8:09:32 AM UTC-4, lucaso...@gmail.com
>> wrote:
>>>
>>> Yes, I can see 'rs485 v1.1'. The python code still works fine out of the
>>> box. C code Rx and Tx lines work OK but RTS still does nothing.
>>> When I exported the GPIO9 by hand, dmesg got:
>>> [  222.055685] gpio_request: gpio-9 (RS485 TXE) status -16
>>> [  222.055730] omap_uart 481a8000.serial: Could not request GPIO 9 : -16
>>>
>>> That means that 485 kernel support works. Without manually exporting it
>>> says just "[  537.089146] rs485 v1.1" and does nothing.
>>>
>>> BUT now I've discovered something strange with logical level flags in
>>> struct serial_rs485, maybe I'm using different header or maybe I don't
>>> understand it correctly.
>>> When I changed the SER_RS485_RTS_AFTER_SEND to 0 and
>>> SER_RS485_RTS_ON_SEND to 0,* it started working fine*.
>>> That means, when sending data, RTS goes HIGH, after sending, it goes
>>> immediately LOW , that means,
>>> I expected setting ON_SEND to 1 and AFTER_SEND to 0, but with this
>>> setting it just changed from LOW to LOW.
>>>
>>
>> Oh yeah, forgot about that. There's a couple ternary operators in the
>> driver that I think might be backwards, which makes it the logic levels a
>> bit counter intuitive. It's:
>>   SER_RS485_ENABLED | SER_RS485_USE_GPIO
>> for an active high RE/DE signal and:
>>   SER_RS485_ENABLED | SER_RS485_USE_GPIO | SER_RS485_RTS_ON_SEND |
>> SER_RS485_RTS_AFTER_SEND
>> for an inverted, active low RE/DE signal.
>>
>>>
>>> Thank you both again for Your valuable help.
>>> I'm satisfied now :-)
>>>
>>>
>>> Dne pondělí, 8. září 2014 19:12:55 UTC+2 Alexander Hiam napsal(a):
>>>
>>>
>>>
>>> Normally If you look at the log (dmsg)  you should see a line rs485
>>> something. It's a printk that I show when the ioctl work.
>>>
>>> Right, it's 'rs485 v1.1'. If you see that in dmesg then the ioctl worked
>>> and it's almost certainly a pinmux issue.
>>>
>>>
>>> And of course you have to configure the pin correctly = pin mode for TX,
>>> rx,  gpio.
>>> Le 8 sept. 2014 17:27,  a écrit :
>>>
>>> I've downloaded Robert C Nelson's code and run build_kernel.sh and
>>> install_kernel.sh. I've controlled that sources are patched by rs485 patch.
>>> BBB booted up normally and uname -r says that I am running new kernel.
>>> But I don't have patched kernel headers. I have created serial.h header as
>>> following:
>>>  1 #include 
>>>   2
>>>   3
>>>   4 struct serial_rs485 {
>>>   5 __u32   flags;  /* RS485 feature flags */
>>>   6 #define SER_RS485_ENABLED   (1 << 0)/* If
>>> enabled */
>>>   7 #define SER_RS485_RTS_ON_SEND   (1 << 1)/* Logical
>>> level for
>>>   8RTS pin
>>> when
>>>   9sending */
>>>  10 #define SER_RS485_RTS_AFTER_SEND(1 << 2)/* Logical
>>> level for
>>>  11RTS pin
>>> after sent*/
>>>  12 #define SER_RS485_RTS_BEFORE_SEND (1 << 3)
>>>  13 #define SER_RS485_USE_GPIO (1 << 5)
>>>  14 //#define SER_RS485_RX_DURING_TX  (1 << 4)
>>>  15 __u32   delay_rts_before_send;  /* Delay before send
>>> (milliseconds) */
>>>  16 __u32   delay_rts_after_send;   /* Delay after send
>>> (milliseconds) */
>>>  17 //   __u32   padding[5]; /* Memory is cheap, new
>>> structs
>>>  18 __u32 gpio_pin; /* GPIO Pin Index */
>>>  19 __u32 padding[4]; /* Memory is cheap, new structs
>>>  20 are a royal PITA .. */
>>>  21 };
>>>
>>>
>>> and used it in small example program:
>>> #include 
>>> #include 
>>> #include 
>>> #include 
>>> #include "serial.h"
>>> //#include 
>>> #include 
>>> #include 
>>>
>>> int main()
>>> {
>>> int fd = open("/dev/ttyO4", O_RDWR | O_NOCTTY | O_NDELAY);
>>> if (fd < 0)
>>> {
>>> perror("Error opening tty!");
>>> return 1;
>>> }
>>>
>>> struct serial_rs485 rs485conf;
>>>
>>> rs485conf.flags |= SER_RS485_ENABLED;
>>>
>>> rs485conf.flags |= SER_RS485_USE_GPIO;
>>> rs485conf.gpio_pin = 9;
>>> rs485conf.flags |= SER_RS485_RTS_ON_SEND;
>>> rs485conf.flags &= ~(SER_RS485_RTS_AFTER_SEND);
>>> rs485conf.delay_rts_before_send = 0;
>>> rs485conf.delay_rts_after_send = 0;
>>>
>>> if (ioctl (fd, TIOCSRS485, &rs485conf) < 0)
>>> {
>>> perror("Bad ioctl");
>>> }

Re: [beagleboard] Re: BBB UART4 RTS for RS-485

2017-03-24 Thread Micka

There is no problem with the kernel 4.4 and rs485. Just use the omap driver
and not the 8250 driver. It works well for me since 4 years.

Le ven. 24 mars 2017 11:24,  a écrit :

> Hi,
>
> We are having allot of problems getting RS485 with RTS working on Debian:
> Linux 4.4
> CAn someone help?
>
>
> On Thursday, March 23, 2017 at 9:13:23 PM UTC+2, bmel...@gmail.com wrote:
>
> Hi Alexander,
>
> The link you provided does not work:
>
>
> http://inspire.logicsupply.com/2014/09/beaglebone-rs-485-communication.html
>
>
> Do you mind sending me the tutorial? I am currently designing my own cape
> which will support two RS485 half duplex channels and your tutorial would
> be very helpful to get me started. My questions are:
>
> 1) Am I limited to UART4 or can I use any of the available UARTs on the
> Beaglebone Black?
>
> 2) Just to be 100% sure, I can use any of the GPIO pins for controlling DE
> & /RE pins on the RS485 transceiver (I'm using TI's ISO15MDW)?
>
> Thank you,
>
> Bolek
>
> On Wednesday, September 3, 2014 at 10:07:26 AM UTC-7, Alexander Hiam wrote:
>
> I actually just put up a tutorial for doing this in Python:
> http://inspire.logicsupply.com/2014/09/beaglebone-rs-485-communication.html
>
> It uses GPIO1_16, but of course you can use any GPIO pin, including the
> one that's shared with UART4 RTS.
>
>
> When I tried to use:
> struct serial_rs485 rs485conf;
> rs485conf.flags |= SER_RS485_USE_GPIO;
> rs485conf.gpio_pin = GPIO0_9;
>
> I got error from gcc that it does not know those macros:
> ‘SER_RS485_USE_GPIO’ was not declared in this scope
>  rs485conf.flags |= SER_RS485_USE_GPIO;
> ‘struct serial_rs485’ has no member named ‘gpio_pin’
>   rs485conf.gpio_pin = GPIO0_9;
> ‘GPIO0_9’ was not declared in this scope
>   rs485conf.gpio_pin = GPIO0_9;
>
>
> That's because you're compiling with the standard libc headers, which
> don't include the modified serial_rs485 struct that uses the GPIO pin. The
> tutorial I linked above uses Python and just defines the same values
> locally, which you could do in C as well. You could also grab the Kernel
> source and include 'include/uapi/linux/serial.h', which has the patched
> serial_rs485 struct (
> https://github.com/RobertCNelson/bb-kernel/blob/am33x-v3.8/patches/fixes/0007-omap-RS485-support-by-Michael-Musset.patch#L201
> ).
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/128d1fae-46ac-4e2d-a759-1cb1568f443c%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAF%2BMRtnVGeQN9qVW7Msi4u3C1YfErKUf8E0Ve1S9%2BGX2nq-1KA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: BBB UART4 RTS for RS-485

[beagleboard] Re: BBB UART4 RTS for RS-485

[beagleboard] Re: BBB UART4 RTS for RS-485

[beagleboard] Re: BBB UART4 RTS for RS-485

Re: [beagleboard] Re: BBB UART4 RTS for RS-485

Re: [beagleboard] Re: BBB UART4 RTS for RS-485

Re: [beagleboard] Re: BBB UART4 RTS for RS-485

Re: [beagleboard] Re: BBB UART4 RTS for RS-485

Re: [beagleboard] Re: BBB UART4 RTS for RS-485

Re: [beagleboard] Re: BBB UART4 RTS for RS-485

Re: [beagleboard] Re: BBB UART4 RTS for RS-485

Re: [beagleboard] Re: BBB UART4 RTS for RS-485

Re: [beagleboard] Re: BBB UART4 RTS for RS-485

13 matches

Site Navigation

Mail list logo

Footer information