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? :-) Thanks for your help, Rodolfo Giometti -- GNU/Linux Solutions e-mail: giometti@xxxxxxxxxxxx Linux Device Driver giometti@xxxxxxxx Embedded Systems phone: +39 349 2432127 UNIX programming skype: rodolfo.giometti
