Re: [PATCH 1/2] tty: add bits to manage multidrop mode

[Richard Genoud <richard.genoud@gmail.com>]

Le 12/09/2019 à 14:47, Rodolfo Giometti a écrit :
> On 12/09/2019 13:01, Richard Genoud wrote:
>> Hi Rodolfo,
>>
>> You could also add these mailing lists:
>> - linux-serial@vger.kernel.org
>> - linux-arm-kernel@lists.infradead.org
>> - linux-kernel@vger.kernel.org
> 
> OK. No problem!
> 
>> For reference, I've dug the conversation we had 2 years ago:
>> 0/2 : https://marc.info/?t=149192176100002&r=1&w=2
>> 1/2 : https://marc.info/?t=149192176300001&r=1&w=2
>> 2/2 : https://marc.info/?t=149192176700001&r=1&w=2
> 
> Thanks.
> 
>> And, like I said at that time, one problem I see with this
>> implementation (setting a SENDA bit that automatically unsets itself)
>> will break the way tcgetattr() is working:
>> https://marc.info/?l=linux-serial&m=149209522108027&w=2
> 
> I see... however the problem here is that this attribute is not sticky and it is
> reset by the controller after the first byte as been sent. Here is how
> Atmel/Microchip multidrop works (from the SAMA5D3's datasheet):
> 
> 44.7.3.9 Multidrop Mode
> If the value 0x6 or 0x07 is written to the PAR field in the US_MR, the USART
> runs in Multidrop Mode. This mode differentiates the data characters and the
> address characters. Data is transmitted with the parity bit to 0 and addresses
> are transmitted with the parity bit to 1.
> ...
> The transmitter sends an address byte (parity bit set) when SENDA is written to
> in the US_CR. In this case, the next byte written to the US_THR is transmitted
> as an address. Any character written in the US_THR without having written the
> command SENDA is transmitted normally with the parity to 0.
> 
> So, if we have a 4 bytes message where the first one is the address byte we can
> use multidrop by setting the SENDA bit at the beginning and then by just
> invoking a write() with the four bytes message. The controller automatically
> will set the 9th bit to 1 for the first byte and then to 0 for the following
> three bytes.
> 
> To do so we need a syscall to tell to the controller when the address bit
> (SENDA) must be set, each time, before sending the message.
> 
> In this implementation I used the syscall within tcsetattr() function but if
> this is not right, then I have to use another one... maybe a custom ioctl? Or
> can you please suggest a suitable solution? :-)
What's bothering me with this implementation, is that it's too close to
the hardware. Some other micro-controllers may not have the SENDA bit.
For instance, i.MX6ULL:
--->8----
To transmit 9-bit RS-485 frames, user need to enable parity (PREN=1) to
enable
trasmitting the ninth data bit, set 8-bit data word size (WS=1), and
write TXB8
(UMCR[2]) as the 9 th bit (bit [8]) to be transmitted (write '0' to TXB8
to transmit a data
frame, write '1' to transmit a address frame). The other data bit [7:0]
is written to TxFIFO
by writing to the UTXD same as normal RS-232 operation.
---8<----
And the TXB8 bit doesn't seem to clear itself automatically.

I maybe wrong, but I think that writing a line discipline for multidrop
mode would be more versatile.


Regards,
Richard

> 
> Thanks for your help,
> 
> Rodolfo Giometti
>