Enjoy : // 8N1 : mode . c_cflag &= ( ~ CSIZE ) ; mode . c_cflag |= CS8 ; mode . c_cflag &= ( ~ PARENB ) ; mode . c_cflag &= ( ~ CRTSCTS ) ; /* raw same as -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -opost -isig -icanon -xcase min 1 $ */ mode . c_iflag |= IGNBRK ; mode . c_iflag |= IGNPAR ; mode . c_iflag &= ( ~ INLCR ) ; mode . c_iflag &= ( ~ ICRNL ) ; mode . c_iflag &= ( ~ IXON ) ; mode . c_iflag &= ( ~ IXOFF ) ; mode . c_oflag &= ( ~ ONLCR ) ; mode . c_oflag &= ( ~ OCRNL ) ; mode . c_lflag &= ( ~ ISIG ) ; mode . c_lflag &= ( ~ ICANON ) ; mode . c_lflag &= ( ~ ECHO ) ; rv=tcsetattr ( pContext->iHandlerConnection , 0 /* no special action */ , & mode );
On Tue, Jan 28, 2014 at 11:36 AM, <[email protected]> wrote: > Hello Micka, > > Thanks for your prompt response. I was using 115200. Now I have tried with > 38400 and 9600 as well but still the problem persists. > > Can you do me a favor? Can you please send the termios structure > configurations with which query-response type application works at your > end? Here is the configurations I am using: > > struct termios my_termios, new_termios; > int fd0 = open("/dev/ttyO4", O_RDWR | O_NDELAY | O_NOCTTY); > > tcgetattr(fd0, &my_termios); > my_termios.c_iflag &= ~(IGNBRK | BRKINT | ICRNL | INLCR | PARMRK | > INPCK | ISTRIP | IXON); > my_termios.c_oflag &= ~(OCRNL | ONLCR | ONLRET | ONOCR | OFILL | > OLCUC | OPOST); > my_termios.c_lflag &= ~(ECHO | ECHONL | ICANON | IEXTEN | ISIG | > ECHOK | ECHOCTL | ECHOPRT); > my_termios.c_cflag &= ~(CSIZE | PARENB); > my_termios.c_cflag &= ~CRTSCTS; > my_termios.c_cflag |= CS8 | CLOCAL | CREAD; > my_termios.c_cflag &= ~CBAUD; > my_termios.c_cflag |= B9600; > my_termios.c_cc[VMIN] = 0; > my_termios.c_cc[VTIME] = 5; > rv = tcsetattr(fd0, TCSANOW, &my_termios); > tcgetattr(fd0, &new_termios); > > Thanks, > Ashish > > On Monday, January 27, 2014 7:23:01 PM UTC+5:30, Mickae1 wrote: > >> What is the baudRate ? Can you spy the communication with an other device >> ? ( serial adapter rs485/rs232 ) >> >> In my case, baudrate 38400 work pretty well, without noise. >> >> and please don't UNDERLINE ! >> >> Micka, >> >> >> On Mon, Jan 27, 2014 at 10:54 AM, <[email protected]> wrote: >> >>> Hi All, >>> >>> I have a interesting issue: >>> >>> What I have did is: >>> >>> - Downloaded Angstrom linux >>> - Applied RS485 patch >>> - Compiled kernel image and push it to BBB. >>> >>> Now I have developed two applications: >>> >>> 1. send.c : This application periodically sends the data on UART >>> 2. recv.c: This application waits to read the data from UART. >>> >>> Both above application works pretty well without any issue. Even I do >>> not have to manually drive the GPIO. (Driver patch handles GPIO value >>> perfectly.). >>> >>> *Problem:* >>> >>> *Now, I have developed an application which is combination of both send >>> and recv. I mean , after sending one byte on UART from BBB to other host >>> machine, I just wait for input bytes to receive(added receive timepout at >>> 10 sec). Now in this cae, even if I do not send any character from host >>> machine, BBB detects one/two arbitary bytes. This seems that driver changes >>> GPIO position (from send mode to recv mode) before transmitte buffer gets >>> empty. * >>> >>> Did any one has face this problem? Can you guys please share your >>> thoughts on this? >>> >>> Thank, >>> Ashish >>> >>> On Tuesday, December 3, 2013 11:23:48 PM UTC+5:30, [email protected]: >>>> >>>> Zach, >>>> >>>> That is great info! >>>> >>>> Thanks a bunch, >>>> >>>> Haik >>>> >>>> On Tuesday, December 3, 2013 11:42:10 AM UTC-5, Zachary Thorson wrote: >>>> >>>>> I am using a custom built cape for my application, so I have not >>>>> tested it. Though according to the schematics it looks like the chip does >>>>> not support those rates. >>>>> >>>>> According to the schematic at: >>>>> http://beagleboardtoys.info/index.php?title=BeagleBone_RS485 >>>>> >>>>> It looks like the RS485 cape uses a TI transceiver part no: SN75HVD12D >>>>> http://www.ti.com/lit/ds/symlink/sn75hvd12.pdf >>>>> >>>>> >>>>> <https://lh6.googleusercontent.com/-iazVOLORISQ/Up4HgMpjUQI/AAAAAAAAA54/FZqOvYcHf28/s1600/12-3-2013+10-31-36+AM.png> >>>>> >>>>> Should be able to go up to 1Mbps, but not much higher. >>>>> >>>>> Checking the ARM Datasheet (AM335x ARM Cortex -A8 MPU Technical >>>>> Reference Manual): >>>>> >>>>> 19.1.1 UART Mode Features >>>>> The general features of the UART/IrDA module when operating in UART >>>>> mode are: >>>>> >>>>> - 16C750 compatibility >>>>> - Baud rate from 300 bps up to 3.6864 Mbps >>>>> - Auto-baud between 1200 bps and 115.2 Kbps >>>>> >>>>> >>>>> Since on the ARM side, you have slightly higher max data rates, so if >>>>> you had a faster chip you could approach the rate you need given the right >>>>> design. If you need faster than what is natively on the ARM, you could >>>>> look into a custom solution with the PRU, but I don't have any experience >>>>> with that. >>>>> >>>>> >>>>> Zach >>>>> >>>>> On Tuesday, December 3, 2013 6:17:45 AM UTC-6, [email protected]: >>>>>> >>>>>> Hi Mika, >>>>>> >>>>>> I need to go two orders of magnitude higher (3.8 Meg, for a short >>>>>> distance of six feet, half duplex). Is there a chance with BBB? >>>>>> >>>>>> Thanks, >>>>>> Haik >>>>>> >>>>>> On Tuesday, December 3, 2013 3:40:39 AM UTC-5, Mickae1 wrote: >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> Well, I'm working with the BaudRate 38400 and I don't have any >>>>>>> problem. I didn't try further. >>>>>>> >>>>>>> micka, >>>>>>> >>>>>>> >>>>>>> On Tue, Dec 3, 2013 at 3:13 AM, <[email protected]> wrote: >>>>>>> >>>>>>>> Hi all, >>>>>>>> >>>>>>>> Interesting Work! What is the max baud rate you can get from this >>>>>>>> rs485 cape on BBB? >>>>>>>> >>>>>>>> Haik >>>>>>>> >>>>>>>> >>>>>>>> On Friday, June 21, 2013 5:54:29 AM UTC-4, Mickae1 wrote: >>>>>>>>> >>>>>>>>> Hi all, >>>>>>>>> >>>>>>>>> Yes I did it ^^, I successfully made my BBB ( Kernel 3.8.x ) work >>>>>>>>> with the *RS485 CAP ( I was able to talk with my PC with a >>>>>>>>> USB<>RS485 adaptater ) * >>>>>>>>> >>>>>>>>> To do it, I modified the Kernel (omap serial driver) and I tested >>>>>>>>> it on a Ubuntu Distribution ( Why ? Because I don't know how to >>>>>>>>> modify the >>>>>>>>> source code of the kernel with an angstrom distribution. And Robert >>>>>>>>> Nelson >>>>>>>>> explain very well how to do it with a Ubuntu distribution). >>>>>>>>> >>>>>>>>> It's true, that the eMMC use the GPIO1_0 & GPIO1_4 of the BBB and >>>>>>>>> the RS485 cap need them, but it's also *easy *to disable the >>>>>>>>> virtual cap eMMC! Just a simple echo -4 > $SLOTS do the trick. >>>>>>>>> And I also had to create my own rs485 virtual cap to enable the >>>>>>>>> GPIO1_0 & GPIO1_4 & UART1_TX & UART1_RX >>>>>>>>> >>>>>>>>> But now, for my project I need to cross compile, and it looks like >>>>>>>>> that there is no toolchain on the ubuntu distribution (working with >>>>>>>>> the >>>>>>>>> Robert Nelson Ubuntu distribution). >>>>>>>>> >>>>>>>>> So I'm going back to the Angstrom distribution, but my problem is >>>>>>>>> that I don't know where to put my patch ? Will it work ? I don't know >>>>>>>>> how >>>>>>>>> to create a patch, I just did this command : " sudo git diff > >>>>>>>>> ../rs485.patch" ( Robert Nelson => on your KERNEL folder ) >>>>>>>>> >>>>>>>>> I read here => http://downloads.angstrom-distribution.org/demo/ >>>>>>>>> beaglebone/ >>>>>>>>> >>>>>>>>> That i can create my own image, with this : >>>>>>>>> >>>>>>>>> git clone git://github.com/Angstrom-distribution/setup-scripts.git >>>>>>>>> >>>>>>>>> cd setup-scripts >>>>>>>>> >>>>>>>>> ./oebb.sh config beaglebone >>>>>>>>> >>>>>>>>> MACHINE=beaglebone ./oebb.sh bitbake systemd-image >>>>>>>>> >>>>>>>>> >>>>>>>>> My question is where I can put my patch ? Or where I can modify >>>>>>>>> the Kernel ? >>>>>>>>> >>>>>>>>> >>>>>>>>> Thx you every one, It's because of your help, That I was able to >>>>>>>>> make this Work ! >>>>>>>>> >>>>>>>>> >>>>>>>>> I will soon explain my work on this project in my blog. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Michael Musset, >>>>>>>>> >>>>>>>> -- >>>>>>>> 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/groups/opt_out. >>>>>>>> >>>>>>> >>>>>>> -- >>> 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/groups/opt_out. >>> >> >> -- > 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/groups/opt_out. > -- 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/groups/opt_out.
