Results 1 to 2 of 2
Enjoy an ad free experience by logging in. Not a member yet? Register.
- Join Date
- Mar 2010
embedded Linux, serial communication issue...
I have an embedded board running Linux, and a servo motor controller called SSC-32 which has a strange issue when communicating with the board. I'm sure it could be regulated from the router side by programming, but I don't know how so I write here to get help.
I found out that to set SSC-32 to communicate with WRT54GL, each time I must repeat this procedure:
1. Turn both the devices on
2. Short router RX and TX and echo something from router to itself and get that bunch of stacked data
3. Return serial set up to the right place between SSC-32 and the router
4. Finished! Now serial communication takes place normally.
If I don't pass the step 2, SSC-32 still obeys the command and runs servo motors, but issuing:
cat < /dev/tts/0 gives no feed back from the motor! Having 2nd step passed, feed back will also work right!
I have no problem with the hardware configuration of my serial port. All set up logically and functioning. No trivial error in setup (and no common issues like sending c/r characters).
It seems that there is some data stacked in the board during initialization process. When I do that 2nd step, I first receive a bunch of information about my embedded board, and only then it is "ready" to have data from SSC-32.
How could I command Linux so that completely reset the serial port, and throw away all data that exist there and bring the state ready for a new communication to start, both from the command line and by programming (in C)?
Any idea very appreciated
- Join Date
- Apr 2009
- I can be found either 40 miles west of Chicago, in Chicago, or in a galaxy far, far away.
You probably need to use the termios functions, such as tcflush(), tcsetattr(), tcdrain(), etc. From the termios man page:
tcdrain() waits until all output written to the object referred to by fd has been transmitted. tcflush() discards data written to the object referred to by fd but not transmit- ted, or data received but not read, depending on the value of queue_selector:Sometimes, real fast is almost as good as real time.
Just remember, Semper Gumbi - always be flexible!