From: Nate W <del...@gm...> - 2005-10-07 08:44:26
|
Here's my configuration: gumstix mounted on robostix removed the getty for ttyS0 from /etc/inittab stty -F /dev/9600 ispeed 9600 ospeed 9600 raw stty -F /dev/ttyS0 cs8 -parenb -cstopb -ixon -ixoff I have bluetooth PAN set up, and I log in to the gumstix via ssh the robostix ttyS0 header goes to a level shifter and a USB-serial interfac= e I have teraterm running on my windows box, 9600 8N1, no flow control Good news: if I run the getty manually, I can log in and use the gumstix over the serial line More good news: if i run sertest -p /dev/ttyS0 -d -v I can type in my ssh window or terminal window and watch characters going in both directions Bad news: if I run "echo abcdef > /dev/ttyS0" only the "abc" appears in the terminal window. Even if I do this right after running sertest to (theoretically) configure the serial port. I've tried this all with /dev/ttyS2 as well, with almost the same results: sertest works, but when I use echo, only the first 2.5 characters come through: ab=E3. I tried the gpio adjustments shown on the tips-and-tricks wiki page for ttys2, but no luck. I also have a small C program that writes stuff to the serial port, and again only the first 3 bytes come out the other end. If I could just squeeze FIVE bytes through with each write to the serial port, I'd be happy. :-) But I'm stuck at 3 bytes max (occasionally 4), and I'm totally stumped. Anyone have suggestions? Thanks, Nate Waddoups Redmond WA USA http://www.natew.com/ <=3D=3D for nerds http://www.featherforum.com/ <=3D=3D for birds |
From: Craig H. <cr...@gu...> - 2005-10-07 17:58:57
|
Using stdout/stdin redirection like that to/from a serial port on =20 gumstix seems to have this symptom. I think the userspace is closing =20= the serial port either prematurely, or closing it in a way which =20 causes the data in the UART buffer which is as-yet-unsent to get =20 dumped. I'm not sure if this is a kernel issue, or a problem with =20 the C lib -- more likely the former I think. The workaround is to =20 ensure that the serial port doesn't get closed. The app I have which =20= uses a gumstix serial port (our shipping robot which is controlled by =20= a gumstix) uses socat to redirect a TCP port to the serial port -- =20 then as long as you hold the TCP connection open, socat won't close =20 the serial port. Another option I've used it to create a named pipe, =20= and use socat or similar to copy from the pipe to the serial port. C On Oct 7, 2005, at 1:44 AM, Nate W wrote: > I've tried this all with /dev/ttyS2 as well, with almost the same > results: sertest works, but when I use echo, only the first 2.5 > characters come through: ab=E3. I tried the gpio adjustments shown = on > the tips-and-tricks wiki page for ttys2, but no luck. I also have a > small C program that writes stuff to the serial port, and again only > the first 3 bytes come out the other end. > > If I could just squeeze FIVE bytes through with each write to the > serial port, I'd be happy. :-) But I'm stuck at 3 bytes max > (occasionally 4), and I'm totally stumped. Anyone have suggestions? > |
From: Dave H. <dhy...@gm...> - 2005-10-07 18:55:33
|
On 10/7/05, Craig Hughes <cr...@gu...> wrote: > Using stdout/stdin redirection like that to/from a serial port on > gumstix seems to have this symptom. I think the userspace is closing > the serial port either prematurely, or closing it in a way which > causes the data in the UART buffer which is as-yet-unsent to get > dumped. I'm not sure if this is a kernel issue, or a problem with > the C lib -- more likely the former I think. The workaround is to > ensure that the serial port doesn't get closed. Hmmm. Maybe you could try this: (echo "abcdef"; sleep 1) > /dev/ttyS0 that would hold it open for a second. You could easily write an echo command that does a smaller sleep until somebody else figures out what's wrong with the close stuff. -- Dave Hylands Vancouver, BC, Canada http://www.DaveHylands.com/ |
From: Nate W <del...@gm...> - 2005-10-08 04:37:53
|
Thanks Dave, the sleep trick works. My code had the same problem (it's not just shell redirection), and keeping the process alive just a bit longer lets all of the data come through. Craig, I think you're right about this being a kernel issue - it should ensure that all pending writes have completed before the it actually closes the file, no matter how much data is still queued up when the application calls close(). On 10/7/05, Dave Hylands <dhy...@gm...> wrote: > On 10/7/05, Craig Hughes <cr...@gu...> wrote: > > Using stdout/stdin redirection like that to/from a serial port on > > gumstix seems to have this symptom. I think the userspace is closing > > the serial port either prematurely, or closing it in a way which > > causes the data in the UART buffer which is as-yet-unsent to get > > dumped. I'm not sure if this is a kernel issue, or a problem with > > the C lib -- more likely the former I think. The workaround is to > > ensure that the serial port doesn't get closed. > > Hmmm. > > Maybe you could try this: > > (echo "abcdef"; sleep 1) > /dev/ttyS0 > > that would hold it open for a second. You could easily write an echo > command that does a smaller sleep until somebody else figures out > what's wrong with the close stuff. |