On 04/21/17 11:32, Stuart Longland wrote:
That looks clean and simple enough… I used the example of two address
bytes to depict a "generic" solution, with the thought of that `mdrop`
struct perhaps having a couple of members:
struct mdrop_t {
int addr_len;
uint8_t* addr;
} mdrop;
uint8_t addr[1] = {0x00};
mdrop.addr_len = 1;
mdrop.addr = addr;
ret = ioctl(fd, TCSSETADDR, &mdrop);
Then each frame, you'd call
ret = ioctl(fd, TCSSENDA);
before writing a frame. That would automatically prepend that buffer.
Want to send another frame? Call ioctl(fd, TCSSENDA) again then start
writing.
I don't understand how you can manage the sending of the address bytes inside
the serial driver... you have to intercept the write() system call in some ways
and then prepend the address bytes, is that right? If so how you can avoid
delays between the two writes?
Note that with my solution we just have to inform the serial controller about
how many address bytes will arrive in the next message and it will do the job
for us.
Your example there though would be better if you're sending to lots of
addresses… in my example, you'd have to call TCSSETADDR again to set a
different address. In that regard, your solution is much simpler (and
requires fewer ioctls to boot).
In fact I have to communicate with different slaves. :-) However even if from
the userspace they are looking equivalent, IMHO they are not into kernel space,
especially regarding their implementation.
The thorny issue IMO is on receive. Userspace really needs to know
where the address starts and ends. You can assume a fixed size, but if
the protocol uses a variable address length, you're screwed.
[snip]
This can be resolved by using the parity check as below:
term.c_iflag |= PARENB | PARMD | PARMRK |INPCK;
term.c_iflag &= ~IGNPAR;
In fact by using this setting all received bytes are marked in case of "parity
error" and then we can distinguish between address and data bytes which have
different parity value (1 for address and 0 for data).
Ciao,
Rodolfo
--
HCE Engineering e-mail: giometti@xxxxxxxxxxxxxxxxxxx
GNU/Linux Solutions giometti@xxxxxxxxxxxx
Linux Device Driver giometti@xxxxxxxx
Embedded Systems phone: +39 349 2432127
UNIX programming skype: rodolfo.giometti
Cosino Project - the quick prototyping embedded system - www.cosino.io
Freelance ICT Italia - Consulente ICT Italia - www.consulenti-ict.it
--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
