[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: 485 serial port read delay and send/receive turnaround
usleep() uses the select() system call for the timeout and the kernel
implementation of select() (sys_select() in elinux/fs/select.c)
uses the 100Hz timer (the HZ define) for timing this.
Thus, you can never get better then 10ms resolution,
it seems to round up and add an extra "jiffie" as well.
Possible solutions/work arounds:
* Use the RS485 ioctl() when writing to the port so that RTS toggling stuff
is handled by the kernel.
* Let the application do busywait calling gettimeofday() in a loop,
then you will get approx 52 us or 104 us resolution.
* Add that to usleep() in uC-libc for small timeouts so you mix select()
and busywaiting if needed.
* Increase HZ and rebuild the kernel to get higher timer resolution
(this might give strange sideeffects?)
* Modify the sys_select and the timer stuff in the kernel so that
it can take advantage of the second timer in ETRAX to get
From: Adam Felson <email@example.com>
Date: Wednesday, January 17, 2001 18:03
Subject: Re: 485 serial port read delay and send/receive turnaround
>Curiouser and curiouser:
>we also tried using an RS232 port and a 232->485 convertor. Using ioctl's
>to set/reset the RTS line didn't quite work because
>of characters still in the write fifo. What was strange was that any call
>to usleep() would get rounded up to the next 20 milliseconds. IE: a call
>to usleep(1) would delay for 20ms.
>Where does this 20ms come from? Can I reprogram that timer for something
>like 2-5 ms?
>HID Corporation - Engineering
>11674 N. Huron Street
>Denver, CO 80234-2924