Alexandre Coffignal wrote:
> Jan Kiszka a écrit :
>> Alexandre Coffignal wrote:
>>> Thanks you for your response.
>>> I used this patch to communicate with a slave equipment in rs485 (modbus
>>> protocol). The data is transmitted over a 2-wire twisted pair bus.
>>> Master initiates all communication activity, by sending data. To do this
>>> it must set RTS line to high state during all it's transmission. Before
>>> slave answer, master must lower the RTS line.
>> Will the slave wait on the deassertion of RTS? Or what will happen if
>> RTS is still high and the slave starts its answer?
> No slave does not wait on the deassertion of RTS, if RTS is still high
> during slave answer, it happen a collision and
> the master does not receive the frame.
>>> my slave equipment answer in less than 200us, so i must know when xmit
>>> is completing to lower the RTS line
>>> An extension to RTSER_RTIOC_WAIT_EVENT may be a good solution but do you
>>> know if an extension to RTSER_RTIOC_WAIT_EVENT can guarantee this timing?
>> Given a proper platform (check its capabilities with the latency or the
>> irqbench test), yes. It's a myth that such things can only be done in
>> kernel space.
> Ok I take note of this, but do you think this function should not be in
> kernel space in half duplex RS485 ?
Well, at least not based on the current design (the task approach is not
yet convincing to me).
Also, I think one problem of a kernel space solution is to detect when a
485 "frame" (not sure if this is the right term) starts and when it end.
To my understanding, RTS is high across multiple bytes. And user space
knows best if there will more bytes and RTS should remain high or if
that was all and RTS should go low again.
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
Xenomai-core mailing list