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, <[email protected]> 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 <linux/types.h>
>>>   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
>>>   8                                                            RTS pin 
>>> when     
>>>   9                                                            sending */
>>>  10 #define SER_RS485_RTS_AFTER_SEND        (1 << 2)        /* Logical 
>>> level for
>>>  11                                                            RTS 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 <fcntl.h>
>>> #include <termios.h>
>>> #include <sys/ioctl.h>
>>> #include <sys/types.h>
>>> #include "serial.h"
>>> //#include <include/uapi/linux/serial.h>
>>> #include <stdio.h>
>>> #include <unistd.h>
>>>
>>> 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 < 10000)
>>>     {
>>>         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, <[email protected]> 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 [email protected] 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 [email protected].
>>>>> 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 [email protected].
>>> 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 [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to