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@xxxxxxxxxxxxxxx >> - linux-arm-kernel@xxxxxxxxxxxxxxxxxxx >> - linux-kernel@xxxxxxxxxxxxxxx > > 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 >
