On 04/20/17 16:31, Richard Genoud wrote:
On 18/04/2017 17:37, Rodolfo Giometti wrote:
On 04/18/17 11:21, Richard Genoud wrote:
On 14/04/2017 16:28, Rodolfo Giometti wrote:
On 04/14/17 16:24, Richard Genoud wrote:
On 13/04/2017 17:12, Rodolfo Giometti wrote:
On 04/13/17 16:53, Richard Genoud wrote:
On 13/04/2017 14:19, Rodolfo Giometti wrote:
On 04/13/17 12:43, Richard Genoud wrote:
On 11/04/2017 22:12, Rodolfo Giometti wrote:
Multidrop 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. However this usually
slow
down communication by adding a delay between the first byte and
the
others.
This patch defines two non-stadard bits PARMD (that enables
multidrop)
and SENDA (that marks the next transmitted byte as address)
that can
be used to completely remove the delay during transmission by
correctly managing the parity bit generation in hardware.
Signed-off-by: Rodolfo Giometti <giometti@xxxxxxxx>
---
include/linux/tty.h | 2 ++
include/uapi/asm-generic/termbits.h | 2 ++
2 files changed, 4 insertions(+)
diff --git a/include/linux/tty.h b/include/linux/tty.h
index 83b264c..85238ff 100644
--- a/include/linux/tty.h
+++ b/include/linux/tty.h
@@ -166,6 +166,8 @@ struct tty_bufhead {
#define C_CIBAUD(tty) _C_FLAG((tty), CIBAUD)
#define C_CRTSCTS(tty) _C_FLAG((tty), CRTSCTS)
#define C_CMSPAR(tty) _C_FLAG((tty), CMSPAR)
+#define C_PARMD(tty) _C_FLAG((tty), PARMD)
+#define C_SENDA(tty) _C_FLAG((tty), SENDA)
#define L_ISIG(tty) _L_FLAG((tty), ISIG)
#define L_ICANON(tty) _L_FLAG((tty), ICANON)
diff --git a/include/uapi/asm-generic/termbits.h
b/include/uapi/asm-generic/termbits.h
index 232b478..7e82859 100644
--- a/include/uapi/asm-generic/termbits.h
+++ b/include/uapi/asm-generic/termbits.h
@@ -140,6 +140,8 @@ struct ktermios {
#define HUPCL 0002000
#define CLOCAL 0004000
#define CBAUDEX 0010000
+#define PARMD 0100000
+#define SENDA 0200000
#define BOTHER 0010000
#define B57600 0010001
#define B115200 0010002
I guess there's a problem with SENDA (bit 16)
It's overlapping with CIBAUD (002003600000 (bits 28,19,18,17,16))
You're right! In this case which bit should I use for SENDA? :(
Since it is referred to output data maybe can we move it into
c_oflag
bits?
Well, bits 23 and 24 are free in asm-generic/c_cflag, and since
multidrop uses the parity bit, I'd say it fits better in c_cflag
than in
c_oflag.
I see, but while PARMD defines a special parity usage the SENDA bit is
dedicated to output data only... however if you prefer I use bits
23 and
24 it's OK for me! :-)
But honestly, I find the SENDA bit logic disturbing and not compliant
with the way tc{g,s}etattr() works.
Because, usually, a tcsetattr() call is followed by a tcgetattr()
call
to check if everything went well. (tcsetattr return 0 if *any* of the
requested change succeeded).
So, with the proposed implementation, we will have
struct termios term, check;
ret = tcgetattr(fd, &term);
if (ret < 0) {
perror("tcgetattr");
exit(-1);
}
term.c_cflag |= PARENB | CMSPAR | PARMD | SENDA;
ret = tcsetattr(fd, TCSADRAIN, &term);
if (ret < 0) {
perror("tcsetattr");
exit(-1);
}
ret = tcgetattr(fd, &check);
if (term.c_cflag != check.c_cflag) {
/* fail to set all c_cflags */
exit(-1);
}
=> it will always fail.
This should be another reason because we should use c_oflag instead of
c_cflag! :-P
Actually it isn't, I gave the example of c_cflag, but it's the same
with
c_{i,o,l}flag
I see... so any advice about how to manage SENDA bit in order to avoid
this drawback?
I'm not a tty guru, but I think the proper way to implement this would
be with a new line discipline.
Gosh! A new line discipline for a special parity settings? =8-o
In any case there are no methods to directly manage tty parity settings
within a line discipline. The developer still needs to use the
tcsetattr() to set the PARMD parity mode.
Maybe we can solve the problem by keeping the multidrop settings within
the tcsetattr()+PARMD and then using something similar to the
send_break() mechanism called with the TCSBRK ioctl() command. We can
add a TCSSENDA ioctl() commands which in turn calls a send_md_address()
function implemented as follow:
static int send_md_address(struct tty_struct *tty, unsigned int bytes)
{
int retval;
if (tty->ops->senda_ctl == NULL)
return 0;
return tty->ops->senda_ctl(tty, bytes);
}
Where the senda_ctl (one per serial driver) do the job! The bytes
parameters is just because we may have more than one address bytes...
Do you think that this could be a reasonable solution?
As I'm not familiar with the multidrop, I read a little bit about it here :
https://www.namanow.org/images/pdfs/technology/mdb_version_4-2.pdf
(p29-32)
And I'm starting to understand the whole problem here.
Correct me if I'm wrong, but as I understood it, multidrop is a
messaging protocol (like i2c or modbus) used on RS485 to address only
one device on the bus.
The "mode bit" is used to differentiate the address/command byte from
the data/checksum
Now, this mode bit can be implemented by using a 9bit data mode (but
this mode is not supported by tcsetattr())
And it can also be implemented by using the parity bit, leading to quite
a lot of tcsetattr() calls (2 by message).
This mode bit is also used in the response to indicate the last byte
sent from the slave to the master.
So, with 9bit mode, multidrop protocol could be fully handled in user
space (no need to call tcsetattr() twice per message, and the mode bit
could be tested in the slave response !). But 9bit mode is not supported
by tcsetattr().
With parity bit, mode bit can be emulated for sending a block, and it
can also be reconstructed when reading a block by setting IGNPAR=0 and
PARMRK=1 (but it's a pain !).
The 3rd method is the use of the multidrop mode of the serial controller
(what you are proposing).
For Atmel controllers, when this mode is enabled, the parity bit is used
as a mode bit.
So, before transmitting a message, the SENDA bit should be set, and
then, the transmitter will set the mode bit for the next byte, leaving
it at 0 for all the following ones.
This is perfectly right! The 3rd method I proposed is to avoid a big delay the
2nd method introduces due the fact we must change the parity settings between
the address bytes and the data ones. This delay drastically drops the speed
communication in case we have to use an high baud rate.
When receiving, the parity error interrupt will only be fired if the
mode bit is high (meaning that a whole block has been received).
The first question I would ask is do we want this protocol to be handled
in the kernel or in user-space ?
If it's in kernel, it may be something like the I2C protocol, the
attached devices (coin device, bill validator, display or whatever)
would also have a kernel drivel, with a right interface.
The mode bit will directly be handled in the kernel, using one of the 3
methods described above, depending of the underlying controller
capabilities.
If it's in user-space, there's already a solution with MARK/SPACE parity
bit and parity bit reconstruction with PARMRK (not the easiest way, but
it can work with every serial controller).
Yes this works but it has the drawback described above... :'(
Adding the 9 data-bits support would give another solution. (but the
controller would have to support 9bits mode, and dealing with 9bit data
buffer may be not so fun).
This solution would be definitely the best one but adding the 9th bit into the
tty layer is not so easy... all data structures have been designed for 8 (or
less) bits!
And there's the solution you propose, with a PARMD parity bit.
It will also change the behaviour of PARMRK / IGNPAR since the notion of
parity error would actually be "end of block reception".
And do you know if some other controllers implement this multidrop mode ?
Because this solution seems to be Atmel specific.
AFAIK the multidrop mode is supported also by Freescale (IMX6 and maybe IMX7)
even if by using directly 9 bits transmission. The SENDA trick (that is
autogically sending the next first byte as an address while the following ones
as data) is Atmel specific. Atmel solution is really smart (even if limited to 1
byte addresses long) because it allows developers to send a message without any
delay between the address and the data bytes.
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
