Re: slcanpty

Re: slcanpty

[Oliver Hartkopp]

Hi Janusz,

the slcanpty programm is just some kind of proof of concept to make applications
run, that use the slcan ASCII protocol.

E.g. http://www.port.de/en/products/canopen/diagnose/can-analyzer-can-report.html

which has the LAWICEL CAN hardware as possible hardware:

See at www.canusb.com

If you would like to have a "remote control" via IP networking for SocketCAN,
I would recommend the socketcand:

https://github.com/dschanoeh/socketcand

Please google for "socketcand", there's a video also ...

http://www.youtube.com/watch?v=6vqCu1WY2F8

Regards,
Oliver


On 05.06.2013 18:24, Janusz Uzycki wrote:
> Hi Oliver.
>  
> I want to use slcanpty as mcp251x socket-CAN to TCP server in order to check
> CAN open (via CAN festival). Do you happen to know it is good idea?
> I noticed some obstacles:
> - the program uses select() for stdin - what is a reason instead of signals?
> Some workaround is to call slcanpty /dev/ptmx can0 < /dev/ptmx & because
> /dev/null does not support select() and code finishes immediately.
> - why did you comment out filter settings M/m? What did you mean by "the
> filter is no SocketCAN filter :-(" exactly?
> - the program does not finishes if PTY was closed - errno should be checked
> otherwise the main loop runs very fast (select() does not wait)
> Good point for me is to use eg. stdin/out instead of PTY. However the program
> seems to work ok with socat's PTY.
>  
> best regards
> Janusz Uzycki
>  

Re: slcanpty

[Janusz Uzycki]

Thanks Oliver for the links. Good to know. I thought that slcanpty provides 
universal protocol for Linux/Windows.
Is it possible to configure remote CAN using socketcand to use CAN Festival 
both under Linux and Windows on PC? Is the protocol 
(https://github.com/dschanoeh/socketcand/blob/master/doc/protocol.md) some 
kind of standard? What open source front-end could you advice?

best regards
Janusz

----- Original Message ----- 
From: "Oliver Hartkopp" <socketcan@hartkopp.net>
To: "Janusz Uzycki" <janusz.uzycki@elproma.com.pl>
Cc: <linux-can@vger.kernel.org>
Sent: Wednesday, June 05, 2013 9:44 PM
Subject: Re: slcanpty


> Hi Janusz,
>
> the slcanpty programm is just some kind of proof of concept to make
> applications
> run, that use the slcan ASCII protocol.
>
> E.g.
> http://www.port.de/en/products/canopen/diagnose/can-analyzer-can-report.html
>
> which has the LAWICEL CAN hardware as possible hardware:
>
> See at www.canusb.com
>
> If you would like to have a "remote control" via IP networking for
> SocketCAN,
> I would recommend the socketcand:
>
> https://github.com/dschanoeh/socketcand
>
> Please google for "socketcand", there's a video also ...
>
> http://www.youtube.com/watch?v=6vqCu1WY2F8
>
> Regards,
> Oliver
>
>
> On 05.06.2013 18:24, Janusz Uzycki wrote:
>> Hi Oliver.
>>
>> I want to use slcanpty as mcp251x socket-CAN to TCP server in order to
>> check
>> CAN open (via CAN festival). Do you happen to know it is good idea?
>> I noticed some obstacles:
>> - the program uses select() for stdin - what is a reason instead of
>> signals?
>> Some workaround is to call slcanpty /dev/ptmx can0 < /dev/ptmx & because
>> /dev/null does not support select() and code finishes immediately.
>> - why did you comment out filter settings M/m? What did you mean by "the
>> filter is no SocketCAN filter :-(" exactly?
>> - the program does not finishes if PTY was closed - errno should be
>> checked
>> otherwise the main loop runs very fast (select() does not wait)
>> Good point for me is to use eg. stdin/out instead of PTY. However the
>> program
>> seems to work ok with socat's PTY.
>>
>> best regards
>> Janusz Uzycki
>>
>
>

Re: slcanpty

[Oliver Hartkopp]

On 06.06.2013 14:03, Janusz Uzycki wrote:
> Thanks Oliver for the links. Good to know. I thought that slcanpty provides
> universal protocol for Linux/Windows.

The SLCAN protocol is a nice and simple ASCII protocol that fits for many
purposes. But it also has some disadvantages e.g. when you want timestamps and
additional error signaling you can usually get from a CAN controller.

> Is it possible to configure remote CAN using socketcand to use CAN Festival
> both under Linux and Windows on PC?

I'm not that deep in CAN Festival, but why not? :-)

> Is the protocol
> (https://github.com/dschanoeh/socketcand/blob/master/doc/protocol.md) some
> kind of standard? What open source front-end could you advice?

The protocol has been created to have a language independent CAN access over
remote/localhost network sockets.

It was mainly intended to be used together with Java which knows PF_INET
sockets much better than PF_CAN sockets ...

See

http://kayak.2codeornot2code.org

and

http://kayak.2codeornot2code.org/tutorial.html

If you have remarks to the doc/protocol.md please feel free to discuss and
extend it.

An other open protocol for this kind of remote CAN control purpose is probably
CANAL from http://www.vscp.org/wiki/doku.php/canal - did you know it?

Best regards,
Oliver


> 
> ----- Original Message ----- From: "Oliver Hartkopp" <socketcan@hartkopp.net>
> To: "Janusz Uzycki" <janusz.uzycki@elproma.com.pl>
> Cc: <linux-can@vger.kernel.org>
> Sent: Wednesday, June 05, 2013 9:44 PM
> Subject: Re: slcanpty
> 
> 
>> Hi Janusz,
>>
>> the slcanpty programm is just some kind of proof of concept to make
>> applications
>> run, that use the slcan ASCII protocol.
>>
>> E.g.
>> http://www.port.de/en/products/canopen/diagnose/can-analyzer-can-report.html
>>
>> which has the LAWICEL CAN hardware as possible hardware:
>>
>> See at www.canusb.com
>>
>> If you would like to have a "remote control" via IP networking for
>> SocketCAN,
>> I would recommend the socketcand:
>>
>> https://github.com/dschanoeh/socketcand
>>
>> Please google for "socketcand", there's a video also ...
>>
>> http://www.youtube.com/watch?v=6vqCu1WY2F8
>>
>> Regards,
>> Oliver
>>
>>
>> On 05.06.2013 18:24, Janusz Uzycki wrote:
>>> Hi Oliver.
>>>
>>> I want to use slcanpty as mcp251x socket-CAN to TCP server in order to
>>> check
>>> CAN open (via CAN festival). Do you happen to know it is good idea?
>>> I noticed some obstacles:
>>> - the program uses select() for stdin - what is a reason instead of
>>> signals?
>>> Some workaround is to call slcanpty /dev/ptmx can0 < /dev/ptmx & because
>>> /dev/null does not support select() and code finishes immediately.
>>> - why did you comment out filter settings M/m? What did you mean by "the
>>> filter is no SocketCAN filter :-(" exactly?
>>> - the program does not finishes if PTY was closed - errno should be
>>> checked
>>> otherwise the main loop runs very fast (select() does not wait)
>>> Good point for me is to use eg. stdin/out instead of PTY. However the
>>> program
>>> seems to work ok with socat's PTY.
>>>
>>> best regards
>>> Janusz Uzycki
>>>
>>
>>
> 

Re: slcanpty

[janusz.uzycki]

> The SLCAN protocol is a nice and simple ASCII protocol that fits for 
> many
> purposes. But it also has some disadvantages e.g. when you want 
> timestamps and
> additional error signaling you can usually get from a CAN controller.

Timestamps (Z) are supported. Error flags are emulated in slcanpty but 
SLCAN protocol seems more messy here, ie. there are different meaning 
conventions from each manufacturer.
Even CAN drivers (SocketCAN, can4linux, LinCAN etc.) are different. 
Which is optimal choice? I found tons of papers with title "our is 
better":) Good to have choice but 2-3 is enough.
However I was hope SLCAN is good supported by existing front-end 
software. Before I found old horch (origin: uClinux).

>> Is it possible to configure remote CAN using socketcand to use CAN 
>> Festival
>> both under Linux and Windows on PC?
> 
> I'm not that deep in CAN Festival, but why not? :-)

http://www.canfestival.org/doc Supported devices - the best multi OS 
support is for closed Peak System. VScom protocol is similar to SLCAN - 
it is why I asked about slcanpty.

>> Is the protocol
>> (https://github.com/dschanoeh/socketcand/blob/master/doc/protocol.md) 
>> some
>> kind of standard? What open source front-end could you advice?
> 
> The protocol has been created to have a language independent CAN 
> access over
> remote/localhost network sockets.
> 
> It was mainly intended to be used together with Java which knows 
> PF_INET
> sockets much better than PF_CAN sockets ...
> 
> See
> 
> http://kayak.2codeornot2code.org
> 
> and
> 
> http://kayak.2codeornot2code.org/tutorial.html

It would be great to have universal protocol for most third party 
frond-end software.

> If you have remarks to the doc/protocol.md please feel free to discuss 
> and
> extend it.

ok, first I'll try basics :)

> An other open protocol for this kind of remote CAN control purpose is 
> probably
> CANAL from http://www.vscp.org/wiki/doku.php/canal - did you know it?

Oh, I didn't know. The whole VSCP idea is very interesting because m2m 
-> IoT is trend for the future.

CAN bus issue, despite of defined industrial standards, is still quite 
fuzzy in APIs, networking protocols and finally software. In commercial 
solutions it is natural but in open source community common way would 
gain winner(s) and interoperability I guess. However thanks to your work 
it's going to be better.

kind regards
Janusz

[PATCH] slcanpty

[janusz.uzycki]

Hi Oliver.

I've tested the following case:
modprobe vcan
ip link add dev vcan0 type vcan
#ip link set vcan0 up type can bitrate 125000
ip link set vcan0 up
socat PTY,link=/tmp/a -
cgdb --args ./slcanpty /tmp/a vcan0

If socat killed slcanpty should finish instead of crazy loop (select 
always returns).
Here is proposal of very little patch:
 From a708491ea49e170ac1d36148e75b7b6c6f07b6fd Mon Sep 17 00:00:00 2001
 From: Janusz Uzycki <j.uzycki@elproma.com.pl>
Date: Fri, 7 Jun 2013 15:25:39 +0200
Subject: slcanpty: detect that master PTY descriptor closed


Signed-off-by: Janusz Uzycki <j.uzycki@elproma.com.pl>
---
  slcanpty.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/slcanpty.c b/slcanpty.c
index f3628b9..061c1ab 100644
--- a/slcanpty.c
+++ b/slcanpty.c
@@ -75,7 +75,7 @@ int pty2can(int pty, int socket, struct can_filter 
*fi,
         int tmp, i;

         nbytes = read(pty, &buf, sizeof(buf)-1);
-       if (nbytes < 0) {
+       if (nbytes <= 0) { /* 0 means that master PTY descriptor has 
been closed */
                 perror("read pty");
                 return 1;
         }
--
1.7.11.3

best regards
Janusz

Re: [PATCH] slcanpty

[Oliver Hartkopp]

Hi Janusz,

thanks for the patch.

I changed it in the way the perror() is only called on negative return values.

Please check it out for a test.

Best regards,
Oliver

On 07.06.2013 15:40, janusz.uzycki@elproma.com.pl wrote:
> Hi Oliver.
> 
> I've tested the following case:
> modprobe vcan
> ip link add dev vcan0 type vcan
> #ip link set vcan0 up type can bitrate 125000
> ip link set vcan0 up
> socat PTY,link=/tmp/a -
> cgdb --args ./slcanpty /tmp/a vcan0
> 
> If socat killed slcanpty should finish instead of crazy loop (select always
> returns).
> Here is proposal of very little patch:
> From a708491ea49e170ac1d36148e75b7b6c6f07b6fd Mon Sep 17 00:00:00 2001
> From: Janusz Uzycki <j.uzycki@elproma.com.pl>
> Date: Fri, 7 Jun 2013 15:25:39 +0200
> Subject: slcanpty: detect that master PTY descriptor closed
> 
> 
> Signed-off-by: Janusz Uzycki <j.uzycki@elproma.com.pl>
> ---
>  slcanpty.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/slcanpty.c b/slcanpty.c
> index f3628b9..061c1ab 100644
> --- a/slcanpty.c
> +++ b/slcanpty.c
> @@ -75,7 +75,7 @@ int pty2can(int pty, int socket, struct can_filter *fi,
>         int tmp, i;
> 
>         nbytes = read(pty, &buf, sizeof(buf)-1);
> -       if (nbytes < 0) {
> +       if (nbytes <= 0) { /* 0 means that master PTY descriptor has been
> closed */
>                 perror("read pty");
>                 return 1;
>         }
> -- 
> 1.7.11.3
> 
> best regards
> Janusz
> 

Re: [PATCH] slcanpty

[janusz.uzycki]

Hi Oliver.

The patch it ok. Thanks.
However I have a problem with "slcanpty: handle incomplete messages 
from pty correctly" patch and socat tests. The patch expects \r and 
socat by default sends only \n. Even "socat PTY,link=/tmp/a,crnl -" 
results in \n\n instead of \r\n in buf[] despite ICRNL flag is reset by 
tcsetattr(). Also "topts.c_lflag |= INLCR;" didn't help. Do you have 
idea?

best regards
Janusz

W dniu 2013-06-08 13:09, Oliver Hartkopp napisał(a):
> Hi Janusz,
> 
> thanks for the patch.
> 
> I changed it in the way the perror() is only called on negative return 
> values.
> 
> Please check it out for a test.
> 
> Best regards,
> Oliver
> 
> On 07.06.2013 15:40, janusz.uzycki@elproma.com.pl wrote:
>> Hi Oliver.
>> 
>> I've tested the following case:
>> modprobe vcan
>> ip link add dev vcan0 type vcan
>> #ip link set vcan0 up type can bitrate 125000
>> ip link set vcan0 up
>> socat PTY,link=/tmp/a -
>> cgdb --args ./slcanpty /tmp/a vcan0
>> 
>> If socat killed slcanpty should finish instead of crazy loop (select 
>> always
>> returns).
>> Here is proposal of very little patch:
>> From a708491ea49e170ac1d36148e75b7b6c6f07b6fd Mon Sep 17 00:00:00 
>> 2001
>> From: Janusz Uzycki <j.uzycki@elproma.com.pl>
>> Date: Fri, 7 Jun 2013 15:25:39 +0200
>> Subject: slcanpty: detect that master PTY descriptor closed
>> 
>> 
>> Signed-off-by: Janusz Uzycki <j.uzycki@elproma.com.pl>
>> ---
>>  slcanpty.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>> 
>> diff --git a/slcanpty.c b/slcanpty.c
>> index f3628b9..061c1ab 100644
>> --- a/slcanpty.c
>> +++ b/slcanpty.c
>> @@ -75,7 +75,7 @@ int pty2can(int pty, int socket, struct can_filter 
>> *fi,
>>         int tmp, i;
>> 
>>         nbytes = read(pty, &buf, sizeof(buf)-1);
>> -       if (nbytes < 0) {
>> +       if (nbytes <= 0) { /* 0 means that master PTY descriptor has 
>> been
>> closed */
>>                 perror("read pty");
>>                 return 1;
>>         }
>> --
>> 1.7.11.3
>> 
>> best regards
>> Janusz
>> 

Re: [PATCH] slcanpty

[janusz.uzycki]

I finally found. Here is a bug and my fix - I used bad member 
(http://linux.die.net/man/3/termios):
         /* disable local echo which would cause double frames */
         topts.c_lflag &= ~(ICANON | ECHO | ECHOE | ECHOK |
                            ECHONL | ECHOPRT | ECHOKE | ICRNL);
+       topts.c_iflag |= INLCR;
         tcsetattr(p, TCSANOW, &topts);
ICRNL from lflag should be also moved to "topts.c_iflag &= ~ICRNL;" or 
cfmakeraw() could be used.

best regards
Janusz

W dniu 2013-06-10 11:06, janusz.uzycki@elproma.com.pl napisał(a):
> Hi Oliver.
> 
> The patch it ok. Thanks.
> However I have a problem with "slcanpty: handle incomplete messages
> from pty correctly" patch and socat tests. The patch expects \r and
> socat by default sends only \n. Even "socat PTY,link=/tmp/a,crnl -"
> results in \n\n instead of \r\n in buf[] despite ICRNL flag is reset
> by tcsetattr(). Also "topts.c_lflag |= INLCR;" didn't help. Do you
> have idea?
> 
> best regards
> Janusz
> 
> W dniu 2013-06-08 13:09, Oliver Hartkopp napisał(a):
>> Hi Janusz,
>> thanks for the patch.
>> I changed it in the way the perror() is only called on negative 
>> return values.
>> Please check it out for a test.
>> Best regards,
>> Oliver
>> On 07.06.2013 15:40, janusz.uzycki@elproma.com.pl wrote:
>>> Hi Oliver.
>>> I've tested the following case:
>>> modprobe vcan
>>> ip link add dev vcan0 type vcan
>>> #ip link set vcan0 up type can bitrate 125000
>>> ip link set vcan0 up
>>> socat PTY,link=/tmp/a -
>>> cgdb --args ./slcanpty /tmp/a vcan0
>>> If socat killed slcanpty should finish instead of crazy loop (select 
>>> always
>>> returns).
>>> Here is proposal of very little patch:
>>> From a708491ea49e170ac1d36148e75b7b6c6f07b6fd Mon Sep 17 00:00:00 
>>> 2001
>>> From: Janusz Uzycki <j.uzycki@elproma.com.pl>
>>> Date: Fri, 7 Jun 2013 15:25:39 +0200
>>> Subject: slcanpty: detect that master PTY descriptor closed
>>> 
>>> Signed-off-by: Janusz Uzycki <j.uzycki@elproma.com.pl>
>>> ---
>>>  slcanpty.c | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>> diff --git a/slcanpty.c b/slcanpty.c
>>> index f3628b9..061c1ab 100644
>>> --- a/slcanpty.c
>>> +++ b/slcanpty.c
>>> @@ -75,7 +75,7 @@ int pty2can(int pty, int socket, struct can_filter 
>>> *fi,
>>>         int tmp, i;
>>> nbytes = read(pty, &buf, sizeof(buf)-1);
>>> -       if (nbytes < 0) {
>>> +       if (nbytes <= 0) { /* 0 means that master PTY descriptor has 
>>> been
>>> closed */
>>>                 perror("read pty");
>>>                 return 1;
>>>         }
>>> --
>>> 1.7.11.3
>>> best regards
>>> Janusz
>>> 

Re: [PATCH] slcanpty

[janusz.uzycki]

My proposal of fix:

 From 8047986ae5ea63150cd7a70e14a3f5ed0adef617 Mon Sep 17 00:00:00 2001
 From: Janusz Uzycki <j.uzycki@elproma.com.pl>
Date: Mon, 10 Jun 2013 11:31:04 +0200
Subject: slcanpty: pty terminal flags fixed (NL -> CR)


Signed-off-by: Janusz Uzycki <j.uzycki@elproma.com.pl>
---
  slcanpty.c | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/slcanpty.c b/slcanpty.c
index 635d12a..1e98f8c 100644
--- a/slcanpty.c
+++ b/slcanpty.c
@@ -454,7 +454,9 @@ int main(int argc, char **argv)

         /* disable local echo which would cause double frames */
         topts.c_lflag &= ~(ICANON | ECHO | ECHOE | ECHOK |
-                          ECHONL | ECHOPRT | ECHOKE | ICRNL);
+                          ECHONL | ECHOPRT | ECHOKE);
+       topts.c_iflag &= ~(ICRNL);
+       topts.c_iflag |= INLCR;
         tcsetattr(p, TCSANOW, &topts);

         /* Support for the Unix 98 pseudo-terminal interface /dev/ptmx 
/dev/pts/N */
--
1.7.11.3

BR
Janusz

[PATCH 1/2] slcanpty: "slcanpty < /dev/null" issue fix

[janusz.uzycki]

Other proposal:

 From 65c62e93ddabceacc9ef6059776a640967206bc1 Mon Sep 17 00:00:00 2001
 From: Janusz Uzycki <j.uzycki@elproma.com.pl>
Date: Fri, 7 Jun 2013 18:15:33 +0200
Subject: [PATCH 1/2] slcanpty: "slcanpty < /dev/null" issue fix

/dev/null returns EOF therefore select() finishes immediately. Now EOF
is probed on start.

Other /dev/null as stdin workarounds:
- lscanpty ... < /dev/ptmx (dirty but works)
- cat </dev/null | slcanpty ... (doesn't work for me and even the patch
   is "disabled" then)

Signed-off-by: Janusz Uzycki <j.uzycki@elproma.com.pl>
---
  slcanpty.c | 22 +++++++++++++++++++++-
  1 file changed, 21 insertions(+), 1 deletion(-)

diff --git a/slcanpty.c b/slcanpty.c
index 061c1ab..f312362 100644
--- a/slcanpty.c
+++ b/slcanpty.c
@@ -363,6 +363,23 @@ int can2pty(int pty, int socket, int *tstamp)
         return 0;
  }

+int check_select_stdin(void)
+{
+       fd_set rdfs;
+       struct timeval timeout;
+       int ret;
+
+       FD_ZERO(&rdfs);
+       FD_SET(0, &rdfs);
+       timeout.tv_sec = 0;
+       timeout.tv_usec = 0;
+       ret = select(1, &rdfs, NULL, NULL, &timeout);
+       if (ret < 0) return 0; /* not selectable */
+       if (ret > 0)
+               if (getchar() == EOF) return 0; /* EOF, eg. /dev/null 
*/
+       return 1;
+}
+

  int main(int argc, char **argv)
  {
@@ -372,6 +389,7 @@ int main(int argc, char **argv)
         struct sockaddr_can addr;
         struct termios topts;
         struct ifreq ifr;
+       int select_stdin = 0;
         int running = 1;
         int tstamp = 0;
         int is_open = 0;
@@ -393,6 +411,8 @@ int main(int argc, char **argv)
                 return 1;
         }

+       select_stdin = check_select_stdin();
+
         /* open pty */
         p = open(argv[1], O_RDWR);
         if (p < 0) {
@@ -464,7 +484,7 @@ int main(int argc, char **argv)
         while (running) {

                 FD_ZERO(&rdfs);
-               FD_SET(0, &rdfs);
+               if (select_stdin) FD_SET(0, &rdfs);
                 FD_SET(p, &rdfs);
                 FD_SET(s, &rdfs);

--
1.7.11.3

[PATCH 2/2] slcanpty: /dev/tty support for tests

[janusz.uzycki]

 From 4c6115b210b64cf93493c93b05f82c83a085fb73 Mon Sep 17 00:00:00 2001
 From: Janusz Uzycki <j.uzycki@elproma.com.pl>
Date: Fri, 7 Jun 2013 23:02:13 +0200
Subject: [PATCH 2/2] slcanpty: /dev/tty support for tests


Signed-off-by: Janusz Uzycki <j.uzycki@elproma.com.pl>
---
  slcanpty.c | 4 ++++
  1 file changed, 4 insertions(+)

diff --git a/slcanpty.c b/slcanpty.c
index f312362..b7e8ed7 100644
--- a/slcanpty.c
+++ b/slcanpty.c
@@ -44,6 +44,7 @@
  /* maximum rx buffer len: extended CAN frame with timestamp */
  #define SLC_MTU (sizeof("T1111222281122334455667788EA5F\r")+1)
  #define DEVICE_NAME_PTMX "/dev/ptmx"
+#define DEVICE_NAME_TTY "/dev/tty"

  #define DEBUG

@@ -407,10 +408,13 @@ int main(int argc, char **argv)
                         " /dev/ttyc0 for the slcan application\n", 
argv[0]);
                 fprintf(stderr, "e.g. for pseudo-terminal '%s %s can0' 
creates"
                         " /dev/pts/N\n", argv[0], DEVICE_NAME_PTMX);
+               fprintf(stderr, "e.g. for pseudo-terminal '%s %s can0' 
uses"
+                       " console terminal (for testing purposes)\n", 
argv[0], DEVICE_NAME_TTY);
                 fprintf(stderr, "\n");
                 return 1;
         }

+       if (strcmp(argv[1], DEVICE_NAME_TTY) != 0)
         select_stdin = check_select_stdin();

         /* open pty */
--
1.7.11.3

Re: [PATCH 2/2] slcanpty: /dev/tty support for tests

[janusz.uzycki]

Primarily I wanted to use stdin/stdout (defined as "-") but it required 
splitted p descriptor to pin and pout... For the "-" socat can be used 
so I stopped here.

best regards
Janusz

W dniu 2013-06-10 11:44, janusz.uzycki@elproma.com.pl napisał(a):
> From 4c6115b210b64cf93493c93b05f82c83a085fb73 Mon Sep 17 00:00:00 2001
> From: Janusz Uzycki <j.uzycki@elproma.com.pl>
> Date: Fri, 7 Jun 2013 23:02:13 +0200
> Subject: [PATCH 2/2] slcanpty: /dev/tty support for tests
> 
> 
> Signed-off-by: Janusz Uzycki <j.uzycki@elproma.com.pl>
> ---
>  slcanpty.c | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/slcanpty.c b/slcanpty.c
> index f312362..b7e8ed7 100644
> --- a/slcanpty.c
> +++ b/slcanpty.c
> @@ -44,6 +44,7 @@
>  /* maximum rx buffer len: extended CAN frame with timestamp */
>  #define SLC_MTU (sizeof("T1111222281122334455667788EA5F\r")+1)
>  #define DEVICE_NAME_PTMX "/dev/ptmx"
> +#define DEVICE_NAME_TTY "/dev/tty"
> 
>  #define DEBUG
> 
> @@ -407,10 +408,13 @@ int main(int argc, char **argv)
>                         " /dev/ttyc0 for the slcan application\n", 
> argv[0]);
>                 fprintf(stderr, "e.g. for pseudo-terminal '%s %s can0' 
> creates"
>                         " /dev/pts/N\n", argv[0], DEVICE_NAME_PTMX);
> +               fprintf(stderr, "e.g. for pseudo-terminal '%s %s can0' 
> uses"
> +                       " console terminal (for testing purposes)\n",
> argv[0], DEVICE_NAME_TTY);
>                 fprintf(stderr, "\n");
>                 return 1;
>         }
> 
> +       if (strcmp(argv[1], DEVICE_NAME_TTY) != 0)
>         select_stdin = check_select_stdin();
> 
>         /* open pty */
> --
> 1.7.11.3

Re: [PATCH 2/2] slcanpty: /dev/tty support for tests

[Oliver Hartkopp]

On 10.06.2013 11:53, janusz.uzycki@elproma.com.pl wrote:
> Primarily I wanted to use stdin/stdout (defined as "-") but it required
> splitted p descriptor to pin and pout... For the "-" socat can be used so I
> stopped here.

:-)

Ok, which of your three patches do you suggest to be applied now?

Is the terminal flags update patch enough?

Best regards,
Oliver

> 
> best regards
> Janusz
> 
> W dniu 2013-06-10 11:44, janusz.uzycki@elproma.com.pl napisał(a):
>> From 4c6115b210b64cf93493c93b05f82c83a085fb73 Mon Sep 17 00:00:00 2001
>> From: Janusz Uzycki <j.uzycki@elproma.com.pl>
>> Date: Fri, 7 Jun 2013 23:02:13 +0200
>> Subject: [PATCH 2/2] slcanpty: /dev/tty support for tests
>>
>>
>> Signed-off-by: Janusz Uzycki <j.uzycki@elproma.com.pl>
>> ---
>>  slcanpty.c | 4 ++++
>>  1 file changed, 4 insertions(+)
>>
>> diff --git a/slcanpty.c b/slcanpty.c
>> index f312362..b7e8ed7 100644
>> --- a/slcanpty.c
>> +++ b/slcanpty.c
>> @@ -44,6 +44,7 @@
>>  /* maximum rx buffer len: extended CAN frame with timestamp */
>>  #define SLC_MTU (sizeof("T1111222281122334455667788EA5F\r")+1)
>>  #define DEVICE_NAME_PTMX "/dev/ptmx"
>> +#define DEVICE_NAME_TTY "/dev/tty"
>>
>>  #define DEBUG
>>
>> @@ -407,10 +408,13 @@ int main(int argc, char **argv)
>>                         " /dev/ttyc0 for the slcan application\n", argv[0]);
>>                 fprintf(stderr, "e.g. for pseudo-terminal '%s %s can0' creates"
>>                         " /dev/pts/N\n", argv[0], DEVICE_NAME_PTMX);
>> +               fprintf(stderr, "e.g. for pseudo-terminal '%s %s can0' uses"
>> +                       " console terminal (for testing purposes)\n",
>> argv[0], DEVICE_NAME_TTY);
>>                 fprintf(stderr, "\n");
>>                 return 1;
>>         }
>>
>> +       if (strcmp(argv[1], DEVICE_NAME_TTY) != 0)
>>         select_stdin = check_select_stdin();
>>
>>         /* open pty */
>> -- 
>> 1.7.11.3

Re: [PATCH 2/2] slcanpty: /dev/tty support for tests

[janusz.uzycki]

;)

* The first today fixes terminal settings (cr/nl). Flags update is 
enough for that.
* 1/2 patch introduces stdin detection switch. It is important if you 
want to use slcanpty as deamon - natural choice for me.
* 2/2 patch is rather for very simple testings using console (like 
DEBUG define). However command "slcanpty /dev/tty vcan0 < /dev/null" 
makes the patch redundant.
So the first and 1/2 are really strongly suggested.

best regards
Janusz

W dniu 2013-06-10 20:29, Oliver Hartkopp napisał(a):
> On 10.06.2013 11:53, janusz.uzycki@elproma.com.pl wrote:
>> Primarily I wanted to use stdin/stdout (defined as "-") but it 
>> required
>> splitted p descriptor to pin and pout... For the "-" socat can be 
>> used so I
>> stopped here.
> 
> :-)
> 
> Ok, which of your three patches do you suggest to be applied now?
> 
> Is the terminal flags update patch enough?
> 
> Best regards,
> Oliver
> 
>> 
>> best regards
>> Janusz
>> 
>> W dniu 2013-06-10 11:44, janusz.uzycki@elproma.com.pl napisał(a):
>>> From 4c6115b210b64cf93493c93b05f82c83a085fb73 Mon Sep 17 00:00:00 
>>> 2001
>>> From: Janusz Uzycki <j.uzycki@elproma.com.pl>
>>> Date: Fri, 7 Jun 2013 23:02:13 +0200
>>> Subject: [PATCH 2/2] slcanpty: /dev/tty support for tests
>>> 
>>> 
>>> Signed-off-by: Janusz Uzycki <j.uzycki@elproma.com.pl>
>>> ---
>>>  slcanpty.c | 4 ++++
>>>  1 file changed, 4 insertions(+)
>>> 
>>> diff --git a/slcanpty.c b/slcanpty.c
>>> index f312362..b7e8ed7 100644
>>> --- a/slcanpty.c
>>> +++ b/slcanpty.c
>>> @@ -44,6 +44,7 @@
>>>  /* maximum rx buffer len: extended CAN frame with timestamp */
>>>  #define SLC_MTU (sizeof("T1111222281122334455667788EA5F\r")+1)
>>>  #define DEVICE_NAME_PTMX "/dev/ptmx"
>>> +#define DEVICE_NAME_TTY "/dev/tty"
>>> 
>>>  #define DEBUG
>>> 
>>> @@ -407,10 +408,13 @@ int main(int argc, char **argv)
>>>                         " /dev/ttyc0 for the slcan application\n", 
>>> argv[0]);
>>>                 fprintf(stderr, "e.g. for pseudo-terminal '%s %s 
>>> can0' creates"
>>>                         " /dev/pts/N\n", argv[0], DEVICE_NAME_PTMX);
>>> +               fprintf(stderr, "e.g. for pseudo-terminal '%s %s 
>>> can0' uses"
>>> +                       " console terminal (for testing 
>>> purposes)\n",
>>> argv[0], DEVICE_NAME_TTY);
>>>                 fprintf(stderr, "\n");
>>>                 return 1;
>>>         }
>>> 
>>> +       if (strcmp(argv[1], DEVICE_NAME_TTY) != 0)
>>>         select_stdin = check_select_stdin();
>>> 
>>>         /* open pty */
>>> --
>>> 1.7.11.3

Re: [PATCH 2/2] slcanpty: /dev/tty support for tests

[Oliver Hartkopp]

On 10.06.2013 20:38, janusz.uzycki@elproma.com.pl wrote:
> ;)
> 
> * The first today fixes terminal settings (cr/nl). Flags update is enough for
> that.
> * 1/2 patch introduces stdin detection switch. It is important if you want to
> use slcanpty as deamon - natural choice for me.
> * 2/2 patch is rather for very simple testings using console (like DEBUG
> define). However command "slcanpty /dev/tty vcan0 < /dev/null" makes the patch
> redundant.
> So the first and 1/2 are really strongly suggested.

Ok, i applied these two fixes after some coding style rework.

Tnx & best regards,
Oliver

Re: slcanpty

[janusz.uzycki]

Hi Oliver.

> The SLCAN protocol is a nice and simple ASCII protocol that fits for 
> many
> purposes. But it also has some disadvantages e.g. when you want 
> timestamps and
> additional error signaling you can usually get from a CAN controller.
> 
>> (https://github.com/dschanoeh/socketcand/blob/master/doc/protocol.md) 
>> some

I noticed that both slcanpty and socketcand don't implement bitrate 
settings yet.
iproute2 includes libnetlink but the library avoids CAN support.
libsocketcan seems to be the best choice but libnl also good.

What do you prefer for CAN interface control?

best regards
Janusz Uzycki

Re: slcanpty

[Oliver Hartkopp]

On 11.06.2013 18:29, janusz.uzycki@elproma.com.pl wrote:
> Hi Oliver.
> 
>> The SLCAN protocol is a nice and simple ASCII protocol that fits for many
>> purposes. But it also has some disadvantages e.g. when you want timestamps and
>> additional error signaling you can usually get from a CAN controller.
>>
>>> (https://github.com/dschanoeh/socketcand/blob/master/doc/protocol.md) some
> 
> I noticed that both slcanpty and socketcand don't implement bitrate settings yet.
> iproute2 includes libnetlink but the library avoids CAN support.
> libsocketcan seems to be the best choice but libnl also good.
> 
> What do you prefer for CAN interface control?

I'm personally using the standard ip tool from iproute together with this script:

https://gitorious.org/linux-can/can-misc/blobs/master/etc/can_if

BR,
Oliver

Re: slcanpty

[janusz.uzycki]

>>> The SLCAN protocol is a nice and simple ASCII protocol that fits for 
>>> many
>>> purposes. But it also has some disadvantages e.g. when you want 
>>> timestamps and
>>> additional error signaling you can usually get from a CAN 
>>> controller.
>>> 
>>>> (https://github.com/dschanoeh/socketcand/blob/master/doc/protocol.md) 
>>>> some
>> 
>> I noticed that both slcanpty and socketcand don't implement bitrate 
>> settings yet.
>> iproute2 includes libnetlink but the library avoids CAN support.
>> libsocketcan seems to be the best choice but libnl also good.
>> 
>> What do you prefer for CAN interface control?
> 
> I'm personally using the standard ip tool from iproute together with
> this script:
> 
> https://gitorious.org/linux-can/can-misc/blobs/master/etc/can_if

The script is nice but I thought about "< can0 B bitrate sample_point 
tq prop_seg phase_seg1 phase_seg2 sjw brp >" command in 
https://github.com/dschanoeh/socketcand/blob/master/doc/protocol.md 
exactly.
I looked for a proper code in socketcand and I didn't find. Is the 
command planned?
I'm asking because if it would be implemented in socketcand it could be 
also implemented in slcanpty for S/s command support. Unfortunately 
using an external library will introduce dependency :/

kind regards
Janusz

Re: slcanpty

[Oliver Hartkopp]

On 11.06.2013 23:19, janusz.uzycki@elproma.com.pl wrote:
>>>> The SLCAN protocol is a nice and simple ASCII protocol that fits for many
>>>> purposes. But it also has some disadvantages e.g. when you want timestamps
>>>> and
>>>> additional error signaling you can usually get from a CAN controller.
>>>>
>>>>> (https://github.com/dschanoeh/socketcand/blob/master/doc/protocol.md) some
>>>
>>> I noticed that both slcanpty and socketcand don't implement bitrate
>>> settings yet.
>>> iproute2 includes libnetlink but the library avoids CAN support.
>>> libsocketcan seems to be the best choice but libnl also good.
>>>
>>> What do you prefer for CAN interface control?
>>
>> I'm personally using the standard ip tool from iproute together with
>> this script:
>>
>> https://gitorious.org/linux-can/can-misc/blobs/master/etc/can_if
> 
> The script is nice but I thought about "< can0 B bitrate sample_point tq
> prop_seg phase_seg1 phase_seg2 sjw brp >" command in
> https://github.com/dschanoeh/socketcand/blob/master/doc/protocol.md exactly.
> I looked for a proper code in socketcand and I didn't find. Is the command
> planned?

Not yet.

Today the socketcand can run as normal user.

When we want to add the "B" option (which is generally a good idea) we need to
take care to run socketcand as root or as some sudo user to be able to
configure the CAN interfaces.

Configuring the CAN interfaces as administrator on the host that is connected
to CAN interfaces is IMO a good solution. Don't know what happens, if multiple
users connected to the socketcand and specifiy different bitrates %-(

> I'm asking because if it would be implemented in socketcand it could be also
> implemented in slcanpty for S/s command support. Unfortunately using an
> external library will introduce dependency :/

Btw. i would recommend the libsocketcan from the pengutronix git then.

Best regards,
Oliver

Re: slcanpty

[Janusz Uzycki]

>>>> What do you prefer for CAN interface control?
>>>
>>> I'm personally using the standard ip tool from iproute together with
>>> this script:
>>>
>>> https://gitorious.org/linux-can/can-misc/blobs/master/etc/can_if
>>
>> The script is nice but I thought about "< can0 B bitrate sample_point tq
>> prop_seg phase_seg1 phase_seg2 sjw brp >" command in
>> https://github.com/dschanoeh/socketcand/blob/master/doc/protocol.md 
>> exactly.
>> I looked for a proper code in socketcand and I didn't find. Is the 
>> command
>> planned?
>
> Not yet.
>
> Today the socketcand can run as normal user.
> When we want to add the "B" option (which is generally a good idea) we 
> need to
> take care to run socketcand as root or as some sudo user to be able to
> configure the CAN interfaces.
>
> Configuring the CAN interfaces as administrator on the host that is 
> connected
> to CAN interfaces is IMO a good solution.

Yes.

> Don't know what happens, if multiple
> users connected to the socketcand and specifiy different bitrates %-(

I think it will be rare case :)


>> I'm asking because if it would be implemented in socketcand it could be 
>> also
>> implemented in slcanpty for S/s command support. Unfortunately using an
>> external library will introduce dependency :/
>
> Btw. i would recommend the libsocketcan from the pengutronix git then.

ok, it's nice library API.

BTW:
I've learnt about HW filters in SJA1000. I compared the datasheet with 
acceptance filter explanation here http://www.can232.com/?page_id=72
According to datasheet's figures filter output bit acceptance is (AMRn | 
(input ^ ACCn)) and according to the tables in explanation acceptance is 
(AMRn | !(input ^ ACCn)). Do you have experience in practive about it?
I want to convert SJA1000 filter to SocetCAN. SJA1000 has several difficult 
features: dual filter (problem with overlapped filters - additional checking 
required), data filter for 1st and/or 2nd data byte (BCM mode supports, RAW 
mode requires userland filtering but ok).
Finally I consider it is better to use socketCAN filters or implement the 
whole well defined filter (not universal like socketcan filter) in userland. 
What could be more CPU effective?

best regards
Janusz Uzycki

Re: slcanpty

[j.uzycki]

[-- Attachment #1: Type: text/plain, Size: 993 bytes --]

Hi Oliver.

> BTW:
> I've learnt about HW filters in SJA1000. I compared the datasheet
> with acceptance filter explanation here
> http://www.can232.com/?page_id=72
> According to datasheet's figures filter output bit acceptance is
> (AMRn | (input ^ ACCn)) and according to the tables in explanation
> acceptance is (AMRn | !(input ^ ACCn)). Do you have experience in
> practive about it?
> I want to convert SJA1000 filter to SocetCAN. SJA1000 has several
> difficult features: dual filter (problem with overlapped filters -
> additional checking required), data filter for 1st and/or 2nd data
> byte (BCM mode supports, RAW mode requires userland filtering but ok).
> Finally I consider it is better to use socketCAN filters or implement
> the whole well defined filter (not universal like socketcan filter) in
> userland. What could be more CPU effective?

I've just implemented SJA1000 filter emulator. I didn't test it yet. 
What do you think about the idea?

best regards
Janusz Uzycki

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-slcanpty-initial-SJA1000-filter-emulator.patch --]
[-- Type: text/x-diff; name=0001-slcanpty-initial-SJA1000-filter-emulator.patch, Size: 8662 bytes --]

From b553e890981ce6b0c0a0255b77762a37630177a1 Mon Sep 17 00:00:00 2001
From: Janusz Uzycki <j.uzycki@elproma.com.pl>
Date: Tue, 18 Jun 2013 10:04:50 +0200
Subject: [PATCH] slcanpty: initial SJA1000 filter emulator


Signed-off-by: Janusz Uzycki <j.uzycki@elproma.com.pl>
---
 slcanpty.c       |  22 +++++++
 slcanpty_sja.inc | 193 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 215 insertions(+)
 create mode 100644 slcanpty_sja.inc

diff --git a/slcanpty.c b/slcanpty.c
index a05c88e..12d4d00 100644
--- a/slcanpty.c
+++ b/slcanpty.c
@@ -48,6 +48,8 @@
 
 #define DEBUG
 
+#include "slcanpty_sja.inc"
+
 static int asc2nibble(char c)
 {
 
@@ -128,7 +130,11 @@ rx_restart:
 #endif
 
 	/* check for filter configuration commands */
+#if 0
 	if (cmd == 'm' || cmd == 'M') {
+#else
+	if (cmd == 'm' || cmd == 'M' || cmd == 'W') {
+#endif
 		buf[9] = 0; /* terminate filter string */
 		ptr = 9;
 #if 0
@@ -148,6 +154,18 @@ rx_restart:
 			setsockopt(socket, SOL_CAN_RAW,
 				   CAN_RAW_FILTER, fi,
 				   sizeof(struct can_filter));
+#else
+		if (cmd == 'W') {
+			sja_regs.single = buf[1] & 0x01;
+			ptr = 2;
+		} else
+		if (cmd == 'm')
+			sja_regs.ACR = strtoul(buf+1,NULL,16);
+		else
+			sja_regs.AMR = strtoul(buf+1,NULL,16);
+
+/*		if (*is_open)*/
+			sja_filter_set(&sja_filter, &sja_regs);
 #endif
 		goto rx_out_ack;
 	}
@@ -345,6 +363,9 @@ int can2pty(int pty, int socket, int *tstamp)
 		return 1;
 	}
 
+	if (!sja_filter_pass(&sja_filter, &frame))
+		return 0; /* drop the frame */
+
 	/* convert to slcan ASCII frame */
 	if (frame.can_id & CAN_RTR_FLAG)
 		cmd = 'R'; /* becomes 'r' in SFF format */
@@ -513,6 +534,7 @@ int main(int argc, char **argv)
 	/* open filter by default */
 	fi.can_id   = 0;
 	fi.can_mask = 0;
+	sja_filter_init(&sja_filter);
 
 	while (running) {
 
diff --git a/slcanpty_sja.inc b/slcanpty_sja.inc
new file mode 100644
index 0000000..5108b73
--- /dev/null
+++ b/slcanpty_sja.inc
@@ -0,0 +1,193 @@
+/*********************************************************************************/
+/* SJA1000 filter emulator
+ * Copyright (c)2013 Janusz Uzycki, ELPROMA
+ *
+ * This code is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ */
+/*********************************************************************************/
+
+/* links:
+ * https://www.kernel.org/doc/Documentation/networking/can.txt
+ * http://www.can232.com/?page_id=75 - dual filter
+ * http://www.can232.com/?page_id=72 - CAN232 v3 single/dual filter
+ * - http://www.can232.com/docs/can232_v3.pdf
+ * - http://www.can232.com/docs/canusb_manual.pdf
+ * - http://www.can232.com/docs/CAN_Filter_Ext_Dual.pdf
+ * - http://www.can232.com/docs/CAN_Filter_Std_Dual.pdf
+ * - http://www.nxp.com/documents/data_sheet/SJA1000.pdf
+ */
+
+/* 0 = must be 0
+ * 1 = must be 1
+ * X = don't care
+ *
+ * SJA1000: (AMR | [!](ACC ^ input))
+ * input  ACRn AMRn
+ *   0	   0    0
+ *   1     1    0
+ *   X     1    1
+ *
+ * SocketCAN: (canid & mask == input & mask)
+ *  input canid mask
+ *   0     0    1
+ *   1     1    1
+ *   X     X    0
+ */
+
+/* canid=ACR, mask=~AMR
+ * bits are reordered, SJA1000 uses dual filter, pair for SFF and EFF = 4 socketCAN filters
+ * warning: socketCAN will double if both filters pass the same frame, SJA1000 do not double
+ *
+ * can.h: SFF_MASK-standard(11), EFF_MASK-extended(29), ERR_flag=CAN_INV_FILTER (see below), RTR_flag, EFF_flag(format)
+ * A filter matches, when
+ *
+ *          <received_can_id> & mask == can_id & mask
+ *
+ * The filter can be inverted (CAN_INV_FILTER bit set in can_id) or it can
+ * filter for error message frames (CAN_ERR_FLAG bit set in mask).
+ */
+
+/*********************************************************************************/
+/* single filter SFF */
+#define SJA_SFF_id(reg)		((reg >> 21) & CAN_SFF_MASK)
+#define SJA_SFF_rtr(reg)	(reg & 0x00100000U)
+#define SJA_SFF_db1(reg)	((reg >> 8) & 0xFF)
+#define SJA_SFF_db2(reg)	(reg & 0xFF)
+
+/* single filter EFF */
+#define SJA_EFF_id(reg)		((reg >> 3) & CAN_EFF_MASK)
+#define SJA_EFF_rtr(reg)	(reg & 0x00000004U)
+
+/* dual filter SFF */
+#define SJA_SFF1_id(reg)	((reg >> 21) & CAN_SFF_MASK)
+#define SJA_SFF1_rtr(reg)	(reg & 0x00100000U)
+#define SJA_SFF1_db1(reg)	( ((reg >> 12) & 0xF0) | (reg & 0x0F) )
+#define SJA_SFF2_id(reg)	((reg >> 5) & CAN_SFF_MASK)
+#define SJA_SFF2_rtr(reg)	(reg & 0x00000010U)
+
+/* dual filter EFF */
+#define SJA_EFF1_id(reg)	( (reg >> (16-13)) & 0x1FFFE000U )
+#define SJA_EFF2_id(reg)	( (reg << 13) & CAN_EFF_MASK )
+
+/*********************************************************************************/
+struct sja_regs_t {
+	unsigned long int ACR;
+	unsigned long int AMR;
+	char single;	/* single(1) / dual(0) filter mode */
+} sja_regs = {0, 0, 0};
+
+struct sja_filter_t {
+	/* max. four filters: dual SFF and dual EFF */
+	struct can_filter f[4];
+	char max_filters;
+	/* max. two first data bytes filtered for the 1-st SFF filter */
+	struct sja_filter_data_t {
+		__u8 data;
+		__u8 mask;
+	} f0[2];
+} sja_filter;
+
+/*********************************************************************************/
+void sja_filter_init(struct sja_filter_t *f)
+{
+	memset(f, 0, sizeof(struct sja_filter_t));
+}
+
+/*********************************************************************************/
+void sja_filter_set(struct sja_filter_t *f, struct sja_regs_t *r)
+{
+#define SJA_rtr(var, rtr)	if(rtr) var |= CAN_RTR_FLAG
+	int i;
+
+	/* SJA1000 to SocketCAN logic truth table */
+	r->AMR = ~r->AMR;
+
+	sja_filter_init(f);
+	if (r->single) {
+		f->max_filters = 2;
+
+		/* SFF filter */
+		f->f[0].can_id   = SJA_SFF_id(r->ACR);
+		f->f[0].can_mask = SJA_SFF_id(r->AMR);
+		SJA_rtr(f->f[0].can_id,   SJA_SFF_rtr(r->ACR));
+		SJA_rtr(f->f[0].can_mask, SJA_SFF_rtr(r->AMR));
+
+		f->f0[0].data = SJA_SFF_db1(r->ACR);
+		f->f0[0].mask = SJA_SFF_db1(r->AMR);
+		f->f0[1].data = SJA_SFF_db2(r->ACR);
+		f->f0[1].mask = SJA_SFF_db2(r->AMR);
+
+		/* EFF filter */
+		f->f[1].can_id = SJA_EFF_id(r->ACR) | CAN_EFF_FLAG;
+		f->f[1].can_mask = SJA_EFF_id(r->AMR) | CAN_EFF_FLAG;
+		SJA_rtr(f->f[1].can_id,   SJA_EFF_rtr(r->ACR));
+		SJA_rtr(f->f[1].can_mask, SJA_EFF_rtr(r->AMR));
+	} else {
+		f->max_filters = 4;
+
+		/* 1st SFF filter */
+		f->f[0].can_id   = SJA_SFF1_id(r->ACR);
+		f->f[0].can_mask = SJA_SFF1_id(r->AMR);
+		SJA_rtr(f->f[0].can_id,   SJA_SFF1_rtr(r->ACR));
+		SJA_rtr(f->f[0].can_mask, SJA_SFF1_rtr(r->AMR));
+
+		f->f0[0].data = SJA_SFF1_db1(r->ACR);
+		f->f0[0].mask = SJA_SFF1_db1(r->AMR);
+
+		/* 2nd SFF filter */
+		f->f[1].can_id   = SJA_SFF2_id(r->ACR);
+		f->f[1].can_mask = SJA_SFF2_id(r->AMR);
+		SJA_rtr(f->f[1].can_id,   SJA_SFF2_rtr(r->ACR));
+		SJA_rtr(f->f[1].can_mask, SJA_SFF2_rtr(r->AMR));
+
+		/* 1st EFF filter */
+		f->f[2].can_id = SJA_EFF1_id(r->ACR) | CAN_EFF_FLAG;
+		f->f[2].can_mask = SJA_EFF1_id(r->AMR) | CAN_EFF_FLAG;
+
+		/* 2nd EFF filter */
+		f->f[3].can_id = SJA_EFF2_id(r->ACR) | CAN_EFF_FLAG;
+		f->f[3].can_mask = SJA_EFF2_id(r->AMR) | CAN_EFF_FLAG;
+	}
+
+	/* filter preprocess - speed up */
+	for (i = 0; i < 4; i++)
+		f->f[i].can_id &= f->f[i].can_mask;
+	for (i = 0; i < 2; i++)
+		f->f0[i].data &= f->f0[i].mask;
+
+	/* clean up */
+	r->AMR = ~r->AMR;
+}
+
+/*********************************************************************************/
+int sja_filter_pass(struct sja_filter_t *f, struct can_frame *frame)
+{
+	int pass;
+
+	pass  = (frame->can_id & f->f[0].can_mask == f->f[0].can_id);
+	if (f->f0[0].mask && frame->can_dlc > 0)
+		pass &= (frame->data[0] & f->f0[0].mask == f->f0[0].data);
+	if (f->f0[1].mask && frame->can_dlc > 1)
+		pass &= (frame->data[1] & f->f0[1].mask == f->f0[1].data);
+	pass |= (frame->can_id & f->f[1].can_mask == f->f[1].can_id);
+	if (f->max_filters < 4)
+		return pass;
+	pass |= (frame->can_id & f->f[2].can_mask == f->f[2].can_id);
+	pass |= (frame->can_id & f->f[3].can_mask == f->f[3].can_id);
+	return pass;
+}
+
+/*********************************************************************************/
+
-- 
1.7.11.3

Re: slcanpty

[Oliver Hartkopp]

On 18.06.2013 10:24, j.uzycki@elproma.com.pl wrote:

>> BTW:
>> I've learnt about HW filters in SJA1000. I compared the datasheet
>> with acceptance filter explanation here
>> http://www.can232.com/?page_id=72
>> According to datasheet's figures filter output bit acceptance is
>> (AMRn | (input ^ ACCn)) and according to the tables in explanation
>> acceptance is (AMRn | !(input ^ ACCn)). Do you have experience in
>> practive about it?
>> I want to convert SJA1000 filter to SocetCAN. SJA1000 has several
>> difficult features: dual filter (problem with overlapped filters -
>> additional checking required), data filter for 1st and/or 2nd data
>> byte (BCM mode supports, RAW mode requires userland filtering but ok).
>> Finally I consider it is better to use socketCAN filters or implement
>> the whole well defined filter (not universal like socketcan filter) in
>> userland. What could be more CPU effective?
> 
> I've just implemented SJA1000 filter emulator. I didn't test it yet. What do
> you think about the idea?

Pretty funny.

Your referenced docs (and your patch) are very informative, but I just wonder
if the filters have really ever been used by anybody.

They look *very* special.

If there's a need to implement it, it's ok.
But IMHO adding the filters just for the completeness of an emulation can be
omitted when nobody is ever using it.

Best regards,
Oliver

Re: slcanpty

[j.uzycki]

>> I've just implemented SJA1000 filter emulator. I didn't test it yet. 
>> What do
>> you think about the idea?
> 
> Pretty funny.
> 
> Your referenced docs (and your patch) are very informative, but I just 
> wonder
> if the filters have really ever been used by anybody.
> 
> They look *very* special.
> 
> If there's a need to implement it, it's ok.
> But IMHO adding the filters just for the completeness of an emulation 
> can be
> omitted when nobody is ever using it.

The whole solution is very specific. The main idea is to reuse existing 
CAN applications ecosystem by common protocols (based on serial port or 
TCP/IP stack).
An universal remote CAN gateway sends data via eg. GPRS which generates 
costs, delays etc. Therefore filters are very appreciated. In other case 
the filters could be negligible.
The simplest choice seems just emulate cheap SLCAN adapters using eg. 
slcanpty.
Another option is socketcand - much better but desired for the future 
front-end applications (I hope).
Any better idea?

best regards
Janusz