* [Xenomai] patch to src/utils/can/rtcansend.c to support data from a file
@ 2013-03-28 22:00 Daniel M. Drucker, Ph.D.
2013-04-15 7:09 ` Wolfgang Grandegger
0 siblings, 1 reply; 17+ messages in thread
From: Daniel M. Drucker, Ph.D. @ 2013-03-28 22:00 UTC (permalink / raw)
To: xenomai
When sending a large number of CAN messages from a script (in our case, to
initialize a servo), rtcansend can be somewhat slow because every message
requires a setup and teardown.
I added a --file flag to rtcansend which allows you to instead read bytes
from a file (or stdin, using '-' as the filename). The file has one CAN
message per line, in the same format (space-separated) as it would have
been in the can-msg on the command line. Blank lines are ignored. Lines
which start with a ' ' (space) or '#' (hash) character are ignored. If a
filename is given, any can-msg specified on the command line is ignored.
I hope this of use to someone, and it'd be really great if this could be
merged!
Thanks,
Daniel
https://gist.github.com/dmd/5267158 and inlined here:
--- xenomai-2.6.2.1/src/utils/can/rtcansend.c 2013-01-22 14:37:05.000000000
-0500
+++ robot4/crob/rtcansendmulti.c 2013-03-28 17:47:21.436106822 -0400
@@ -1,4 +1,5 @@
#include <stdio.h>
+#include <string.h>
#include <stdlib.h>
#include <signal.h>
#include <unistd.h>
@@ -18,9 +19,10 @@
static void print_usage(char *prg)
{
fprintf(stderr,
- "Usage: %s <can-interface> [Options] <can-msg>\n"
+ "Usage: %s <can-interface> [Options] [<can-msg>]\n"
"<can-msg> can consist of up to 8 bytes given as a space separated
list\n"
"Options:\n"
+ " -f, --file=FILENAME file to read bytes from instead of the command
line. one list per line.\n"
" -i, --identifier=ID CAN Identifier (default = 1)\n"
" -r --rtr send remote request\n"
" -e --extended send extended frame\n"
@@ -45,7 +47,7 @@
static nanosecs_rel_t timeout = 0;
static struct can_frame frame;
static struct sockaddr_can to_addr;
-
+const char* input_filename = NULL;
void cleanup(void)
{
@@ -127,6 +129,7 @@
struct option long_options[] = {
{ "help", no_argument, 0, 'h' },
+ { "file", required_argument, NULL, 'f'},
{ "identifier", required_argument, 0, 'i'},
{ "rtr", no_argument, 0, 'r'},
{ "extended", no_argument, 0, 'e'},
@@ -148,15 +151,20 @@
frame.can_id = 1;
- while ((opt = getopt_long(argc, argv, "hvi:l:red:t:cp:sL:",
+ while ((opt = getopt_long(argc, argv, "hvi:l:red:t:cp:sL:f:",
long_options, NULL)) != -1) {
switch (opt) {
case 'h':
print_usage(argv[0]);
exit(0);
+ case 'f':
+ input_filename = optarg;
+ break;
+
case 'p':
print = strtoul(optarg, NULL, 0);
+ /* fall through */
case 'v':
verbose = 1;
@@ -263,18 +271,6 @@
}
}
- if (count)
- frame.can_dlc = sizeof(int);
- else {
- for (i = optind + 1; i < argc; i++) {
- frame.data[dlc] = strtoul(argv[i], NULL, 0);
- dlc++;
- if( dlc == 8 )
- break;
- }
- frame.can_dlc = dlc;
- }
-
if (rtr)
frame.can_id |= CAN_RTR_FLAG;
@@ -298,7 +294,49 @@
goto failure;
}
- rt_task();
+ if (input_filename != NULL) {
+ if (!strcmp(input_filename, "-"))
+ input_filename = "/dev/stdin";
+
+ FILE *file = fopen(input_filename, "r");
+
+ if (file != NULL) {
+ char line [1024];
+ while (fgets(line, sizeof line, file) != NULL) {
+ // put the data into frame
+ char * pch;
+ if (line[0] == '#' || line[0] == ' ' || line[0] == '\n') continue;
+ pch = strtok(line, " ");
+ dlc = 0;
+ while ((pch != NULL) && (dlc < 8)) {
+ frame.data[dlc] = strtoul(pch, NULL, 0);
+ pch = strtok(NULL, " ");
+ dlc++;
+ }
+ frame.can_dlc = dlc;
+ rt_task();
+ }
+ fclose(file);
+ }
+ else {
+ perror(input_filename);
+ goto failure;
+ }
+ }
+ else {
+ if (count)
+ frame.can_dlc = sizeof(int);
+ else {
+ for (i = optind + 1; i < argc; i++) {
+ frame.data[dlc] = strtoul(argv[i], NULL, 0);
+ dlc++;
+ if( dlc == 8 )
+ break;
+ }
+ frame.can_dlc = dlc;
+ }
+ rt_task();
+ }
cleanup();
return 0;
^ permalink raw reply [flat|nested] 17+ messages in thread* Re: [Xenomai] patch to src/utils/can/rtcansend.c to support data from a file
2013-03-28 22:00 [Xenomai] patch to src/utils/can/rtcansend.c to support data from a file Daniel M. Drucker, Ph.D.
@ 2013-04-15 7:09 ` Wolfgang Grandegger
2013-04-17 3:04 ` Matthew Fornero
0 siblings, 1 reply; 17+ messages in thread
From: Wolfgang Grandegger @ 2013-04-15 7:09 UTC (permalink / raw)
To: Daniel M. Drucker, Ph.D.; +Cc: xenomai
Hi Daniel,
thanks for your contribution...
On 03/28/2013 11:00 PM, Daniel M. Drucker, Ph.D. wrote:
> When sending a large number of CAN messages from a script (in our case, to
> initialize a servo), rtcansend can be somewhat slow because every message
> requires a setup and teardown.
>
> I added a --file flag to rtcansend which allows you to instead read bytes
> from a file (or stdin, using '-' as the filename). The file has one CAN
> message per line, in the same format (space-separated) as it would have
> been in the can-msg on the command line. Blank lines are ignored. Lines
> which start with a ' ' (space) or '#' (hash) character are ignored. If a
> filename is given, any can-msg specified on the command line is ignored.
>
> I hope this of use to someone, and it'd be really great if this could be
> merged!
Well, I actually see it as a nice extension for a special purpose. I do
not see an general benefit for basic CAN testing. I also prefer to keep
rtcansend short and simple.
Wolfgang.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Xenomai] patch to src/utils/can/rtcansend.c to support data from a file
2013-04-15 7:09 ` Wolfgang Grandegger
@ 2013-04-17 3:04 ` Matthew Fornero
2013-04-17 3:06 ` Matthew Fornero
2013-04-17 5:30 ` Gilles Chanteperdrix
0 siblings, 2 replies; 17+ messages in thread
From: Matthew Fornero @ 2013-04-17 3:04 UTC (permalink / raw)
To: Wolfgang Grandegger; +Cc: Daniel M. Drucker, Ph.D., xenomai
FWIW, we would find this extension to be pretty useful for testing. We
often do regulatory compliance testing (FCC, CE, etc) well ahead of having
a full software stack working, so use simple shell scripts to
generate/check traffic on all of our interfaces.
Being able to script data without delays would allow us to generate more
representative traffic during these tests. Of course we could accomplish
the same with a small test program in C, but shell scripts seem to be more
accessible for getting something up and running "quick and dirty".
-Matt
On Mon, Apr 15, 2013 at 3:09 AM, Wolfgang Grandegger <wg@grandegger.com>wrote:
> Hi Daniel,
>
> thanks for your contribution...
>
> On 03/28/2013 11:00 PM, Daniel M. Drucker, Ph.D. wrote:
> > When sending a large number of CAN messages from a script (in our case,
> to
> > initialize a servo), rtcansend can be somewhat slow because every message
> > requires a setup and teardown.
> >
> > I added a --file flag to rtcansend which allows you to instead read bytes
> > from a file (or stdin, using '-' as the filename). The file has one CAN
> > message per line, in the same format (space-separated) as it would have
> > been in the can-msg on the command line. Blank lines are ignored. Lines
> > which start with a ' ' (space) or '#' (hash) character are ignored. If a
> > filename is given, any can-msg specified on the command line is ignored.
> >
> > I hope this of use to someone, and it'd be really great if this could be
> > merged!
>
> Well, I actually see it as a nice extension for a special purpose. I do
> not see an general benefit for basic CAN testing. I also prefer to keep
> rtcansend short and simple.
>
> Wolfgang.
>
> _______________________________________________
> Xenomai mailing list
> Xenomai@xenomai.org
> http://www.xenomai.org/mailman/listinfo/xenomai
>
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Xenomai] patch to src/utils/can/rtcansend.c to support data from a file
2013-04-17 3:04 ` Matthew Fornero
@ 2013-04-17 3:06 ` Matthew Fornero
2013-04-17 5:30 ` Gilles Chanteperdrix
1 sibling, 0 replies; 17+ messages in thread
From: Matthew Fornero @ 2013-04-17 3:06 UTC (permalink / raw)
To: Wolfgang Grandegger; +Cc: Daniel M. Drucker, Ph.D., xenomai
> FWIW, we would find this extension to be pretty useful for testing. We often
> do regulatory compliance testing (FCC, CE, etc) well ahead of having a full
> software stack working, so use simple shell scripts to generate/check
> traffic on all of our interfaces.
>
> Being able to script data without delays would allow us to generate more
> representative traffic during these tests. Of course we could accomplish the
> same with a small test program in C, but shell scripts seem to be more
> accessible for getting something up and running "quick and dirty".
>
> -Matt
Sorry about the top post / overly long lines wrapping-- gmail defaults
to this and I forgot to modify it.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Xenomai] patch to src/utils/can/rtcansend.c to support data from a file
2013-04-17 3:04 ` Matthew Fornero
2013-04-17 3:06 ` Matthew Fornero
@ 2013-04-17 5:30 ` Gilles Chanteperdrix
2013-04-17 13:04 ` Matthew Fornero
1 sibling, 1 reply; 17+ messages in thread
From: Gilles Chanteperdrix @ 2013-04-17 5:30 UTC (permalink / raw)
To: Matthew Fornero; +Cc: Daniel M. Drucker, Ph.D., xenomai
On 04/17/2013 05:04 AM, Matthew Fornero wrote:
> FWIW, we would find this extension to be pretty useful for testing. We
> often do regulatory compliance testing (FCC, CE, etc) well ahead of having
> a full software stack working, so use simple shell scripts to
> generate/check traffic on all of our interfaces.
>
> Being able to script data without delays would allow us to generate more
> representative traffic during these tests. Of course we could accomplish
> the same with a small test program in C, but shell scripts seem to be more
> accessible for getting something up and running "quick and dirty".
Maybe you could make it a separate test?
--
Gilles.
^ permalink raw reply [flat|nested] 17+ messages in thread* Re: [Xenomai] patch to src/utils/can/rtcansend.c to support data from a file
2013-04-17 5:30 ` Gilles Chanteperdrix
@ 2013-04-17 13:04 ` Matthew Fornero
2013-04-17 13:07 ` Daniel M. Drucker, Ph.D.
0 siblings, 1 reply; 17+ messages in thread
From: Matthew Fornero @ 2013-04-17 13:04 UTC (permalink / raw)
To: Gilles Chanteperdrix; +Cc: Daniel M. Drucker, Ph.D., xenomai
On Wed, Apr 17, 2013 at 1:30 AM, Gilles Chanteperdrix
<gilles.chanteperdrix@xenomai.org> wrote:
> Maybe you could make it a separate test?
Yep-- we certainly could (and have in the past). Just wanted to
provide some feedback that other users (my group) of the software
would find this feature useful, as we often reach for the most common
tool when turning on / testing a new system.
-Matt
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Xenomai] patch to src/utils/can/rtcansend.c to support data from a file
2013-04-17 13:04 ` Matthew Fornero
@ 2013-04-17 13:07 ` Daniel M. Drucker, Ph.D.
2013-04-18 7:19 ` Wolfgang Grandegger
0 siblings, 1 reply; 17+ messages in thread
From: Daniel M. Drucker, Ph.D. @ 2013-04-17 13:07 UTC (permalink / raw)
To: Matthew Fornero; +Cc: xenomai
Gilles et al.,
Would you be willing to merge a separate 'rtcanmultisend' tool perhaps?
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Xenomai] patch to src/utils/can/rtcansend.c to support data from a file
2013-04-17 13:07 ` Daniel M. Drucker, Ph.D.
@ 2013-04-18 7:19 ` Wolfgang Grandegger
2013-04-18 7:27 ` Wolfgang Grandegger
2013-04-18 15:08 ` Daniel M. Drucker, Ph.D.
0 siblings, 2 replies; 17+ messages in thread
From: Wolfgang Grandegger @ 2013-04-18 7:19 UTC (permalink / raw)
To: Daniel M. Drucker, Ph.D.; +Cc: xenomai
On 04/17/2013 03:07 PM, Daniel M. Drucker, Ph.D. wrote:
> Gilles et al.,
> Would you be willing to merge a separate 'rtcanmultisend' tool perhaps?
Well, I do still not see the real benefit of reading just the data from
a file. Why is a simply shell script not good enough for that purpose?
What are you doing whith that data sent to the bus?
Anyway, the input file should provide the id, rtr and ext, apart from
the data, at least.
Wolfgang.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Xenomai] patch to src/utils/can/rtcansend.c to support data from a file
2013-04-18 7:19 ` Wolfgang Grandegger
@ 2013-04-18 7:27 ` Wolfgang Grandegger
2013-04-18 21:49 ` Daniel M. Drucker, Ph.D.
2013-04-18 15:08 ` Daniel M. Drucker, Ph.D.
1 sibling, 1 reply; 17+ messages in thread
From: Wolfgang Grandegger @ 2013-04-18 7:27 UTC (permalink / raw)
To: Daniel M. Drucker, Ph.D.; +Cc: xenomai
On 04/18/2013 09:19 AM, Wolfgang Grandegger wrote:
> On 04/17/2013 03:07 PM, Daniel M. Drucker, Ph.D. wrote:
>> Gilles et al.,
>> Would you be willing to merge a separate 'rtcanmultisend' tool perhaps?
>
> Well, I do still not see the real benefit of reading just the data from
> a file. Why is a simply shell script not good enough for that purpose?
> What are you doing whith that data sent to the bus?
>
> Anyway, the input file should provide the id, rtr and ext, apart from
> the data, at least.
Thinking more about it, a specialized rtcanmultisend.c in
"examples/rtdm/profiles/can" would be nice. Please also provide an
example input file.
Thanks,
Wolfgang.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Xenomai] patch to src/utils/can/rtcansend.c to support data from a file
2013-04-18 7:27 ` Wolfgang Grandegger
@ 2013-04-18 21:49 ` Daniel M. Drucker, Ph.D.
2013-04-19 8:55 ` Wolfgang Grandegger
0 siblings, 1 reply; 17+ messages in thread
From: Daniel M. Drucker, Ph.D. @ 2013-04-18 21:49 UTC (permalink / raw)
To: Wolfgang Grandegger; +Cc: xenomai
> Thinking more about it, a specialized rtcanmultisend.c in
> "examples/rtdm/profiles/can" would be nice. Please also provide an
> example input file.
Here is my rtcansendmulti.c:
https://gist.github.com/dmd/5416474
By default, it operates exactly the same as the current rtcansend (so
this could just replace the existing rtcansend - there's no real
reason to have both).
If a filename option is provided, it ignores any <can-msg> that may be
present on the command line, and instead reads that file line at a
time, treating each line as if it were a command line. The updated
help should explain this:
Usage: ./rtcansendmulti <can-interface> [Global Options] [<can-msg>]
Global Options:
-f, --file=filename filename to read from, or - for stdin
<can-msg> will be ignored if a file is specified
-L, --loopback=0|1 switch local loopback off or on
-v, --verbose be verbose
-t, --timeout=MS timeout in ms
-s, --send use send instead of sendto
-h, --help this help
Global Options OR any line in file:
-i, --identifier=ID CAN Identifier (default = 1)
-d, --delay=MS delay in ms (default = 1ms)
-r --rtr send remote request
-e --extended send extended frame
-l --loop=COUNT send message COUNT times
-c, --count message count in data[0-3]
-p, --print=MODULO print every MODULO message
filename (or - for stdin) contains lines of the format:
[Options] [<can-msg>]
Blank lines are ignored.
# comments out the remainder of a line.
If an option is given on a particular line in a file, that option
overrides the specified global option for that line only.
For example, I might have a file foo which contains:
# this is a comment
-i 0x601 0x40 0x41 0x60 0x00 #this is another comment
0x40 0x41 0x60 0x00
And I run:
rtcansendmulti rtcan0 -v -i 0x602 -f foo
I will see:
interface rtcan0
s=1, ifr_name=rtcan0
<0x601> [4] 40 41 60 00
<0x602> [4] 40 41 60 00
Cleaning up...
Note that the first line was sent to cobid 0x601 (specified on that
line), and the second to globally specified 0x602.
Let me know if you have any questions.
Daniel
^ permalink raw reply [flat|nested] 17+ messages in thread* Re: [Xenomai] patch to src/utils/can/rtcansend.c to support data from a file
2013-04-18 21:49 ` Daniel M. Drucker, Ph.D.
@ 2013-04-19 8:55 ` Wolfgang Grandegger
2013-04-19 13:58 ` Carles Lopez
0 siblings, 1 reply; 17+ messages in thread
From: Wolfgang Grandegger @ 2013-04-19 8:55 UTC (permalink / raw)
To: Daniel M. Drucker, Ph.D.; +Cc: xenomai
Hi Daniel,
On 04/18/2013 11:49 PM, Daniel M. Drucker, Ph.D. wrote:
>> Thinking more about it, a specialized rtcanmultisend.c in
>> "examples/rtdm/profiles/can" would be nice. Please also provide an
>> example input file.
>
> Here is my rtcansendmulti.c:
>
> https://gist.github.com/dmd/5416474
>
>
> By default, it operates exactly the same as the current rtcansend (so
> this could just replace the existing rtcansend - there's no real
> reason to have both).
Well, simply duplicating code/file/features was also not my idea. Reduce
it to the useful minimum, e.g. remove reading from the command line,
remove "-c", "-s" etc.
> If a filename option is provided, it ignores any <can-msg> that may be
> present on the command line, and instead reads that file line at a
> time, treating each line as if it were a command line. The updated
> help should explain this:
>
> Usage: ./rtcansendmulti <can-interface> [Global Options] [<can-msg>]
>
> Global Options:
> -f, --file=filename filename to read from, or - for stdin
> <can-msg> will be ignored if a file is specified
> -L, --loopback=0|1 switch local loopback off or on
> -v, --verbose be verbose
> -t, --timeout=MS timeout in ms
> -s, --send use send instead of sendto
> -h, --help this help
>
> Global Options OR any line in file:
> -i, --identifier=ID CAN Identifier (default = 1)
> -d, --delay=MS delay in ms (default = 1ms)
> -r --rtr send remote request
> -e --extended send extended frame
> -l --loop=COUNT send message COUNT times
> -c, --count message count in data[0-3]
> -p, --print=MODULO print every MODULO message
>
> filename (or - for stdin) contains lines of the format:
> [Options] [<can-msg>]
>
> Blank lines are ignored.
> # comments out the remainder of a line.
>
>
> If an option is given on a particular line in a file, that option
> overrides the specified global option for that line only.
>
> For example, I might have a file foo which contains:
>
> # this is a comment
> -i 0x601 0x40 0x41 0x60 0x00 #this is another comment
> 0x40 0x41 0x60 0x00
>
> And I run:
> rtcansendmulti rtcan0 -v -i 0x602 -f foo
>
> I will see:
> interface rtcan0
> s=1, ifr_name=rtcan0
> <0x601> [4] 40 41 60 00
> <0x602> [4] 40 41 60 00
> Cleaning up...
>
> Note that the first line was sent to cobid 0x601 (specified on that
> line), and the second to globally specified 0x602.
I would prefer removing -i, -r, -e, etc. and add it as data:
s 0x601 0x40 0x41 0x60 0x00 (standard frame)
e 0x12345678 0x40 0x41 (extended frame)
sr 0x601 (standard rtr frame)
er 0x3456778 (extended rtr frame)
You could also fill an array of CAN messages instead of parsing the
lines every time.
What do you think?
Thanks,
Wolfgang.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Xenomai] patch to src/utils/can/rtcansend.c to support data from a file
2013-04-19 8:55 ` Wolfgang Grandegger
@ 2013-04-19 13:58 ` Carles Lopez
2013-04-19 20:01 ` Wolfgang Grandegger
0 siblings, 1 reply; 17+ messages in thread
From: Carles Lopez @ 2013-04-19 13:58 UTC (permalink / raw)
To: Wolfgang Grandegger; +Cc: Daniel M. Drucker, Ph.D., xenomai
Hi,
as Daniel we are here also interested in dumping CAN frames to our
devices and extending/adding this tool to Xenomai would be great.
Sometimes in our company it's really useful to save the rtcanrecv
output and, sometime later, send it in order to reproduce CAN traffic.
do you guys think that it's interesting that rtcansendmulti supports
same syntax than rtcanrecv output?
To do for instance:
rtcanrecv | rtcansendmulti -
thx
On Fri, Apr 19, 2013 at 10:55 AM, Wolfgang Grandegger <wg@grandegger.com> wrote:
> Hi Daniel,
>
> On 04/18/2013 11:49 PM, Daniel M. Drucker, Ph.D. wrote:
>>> Thinking more about it, a specialized rtcanmultisend.c in
>>> "examples/rtdm/profiles/can" would be nice. Please also provide an
>>> example input file.
>>
>> Here is my rtcansendmulti.c:
>>
>> https://gist.github.com/dmd/5416474
>>
>>
>> By default, it operates exactly the same as the current rtcansend (so
>> this could just replace the existing rtcansend - there's no real
>> reason to have both).
>
> Well, simply duplicating code/file/features was also not my idea. Reduce
> it to the useful minimum, e.g. remove reading from the command line,
> remove "-c", "-s" etc.
>
>> If a filename option is provided, it ignores any <can-msg> that may be
>> present on the command line, and instead reads that file line at a
>> time, treating each line as if it were a command line. The updated
>> help should explain this:
>>
>> Usage: ./rtcansendmulti <can-interface> [Global Options] [<can-msg>]
>>
>> Global Options:
>> -f, --file=filename filename to read from, or - for stdin
>> <can-msg> will be ignored if a file is specified
>> -L, --loopback=0|1 switch local loopback off or on
>> -v, --verbose be verbose
>> -t, --timeout=MS timeout in ms
>> -s, --send use send instead of sendto
>> -h, --help this help
>>
>> Global Options OR any line in file:
>> -i, --identifier=ID CAN Identifier (default = 1)
>> -d, --delay=MS delay in ms (default = 1ms)
>> -r --rtr send remote request
>> -e --extended send extended frame
>> -l --loop=COUNT send message COUNT times
>> -c, --count message count in data[0-3]
>> -p, --print=MODULO print every MODULO message
>>
>> filename (or - for stdin) contains lines of the format:
>> [Options] [<can-msg>]
>>
>> Blank lines are ignored.
>> # comments out the remainder of a line.
>>
>>
>> If an option is given on a particular line in a file, that option
>> overrides the specified global option for that line only.
>>
>> For example, I might have a file foo which contains:
>>
>> # this is a comment
>> -i 0x601 0x40 0x41 0x60 0x00 #this is another comment
>> 0x40 0x41 0x60 0x00
>>
>> And I run:
>> rtcansendmulti rtcan0 -v -i 0x602 -f foo
>>
>> I will see:
>> interface rtcan0
>> s=1, ifr_name=rtcan0
>> <0x601> [4] 40 41 60 00
>> <0x602> [4] 40 41 60 00
>> Cleaning up...
>>
>> Note that the first line was sent to cobid 0x601 (specified on that
>> line), and the second to globally specified 0x602.
>
> I would prefer removing -i, -r, -e, etc. and add it as data:
>
> s 0x601 0x40 0x41 0x60 0x00 (standard frame)
> e 0x12345678 0x40 0x41 (extended frame)
> sr 0x601 (standard rtr frame)
> er 0x3456778 (extended rtr frame)
>
> You could also fill an array of CAN messages instead of parsing the
> lines every time.
>
> What do you think?
>
> Thanks,
>
> Wolfgang.
>
> _______________________________________________
> Xenomai mailing list
> Xenomai@xenomai.org
> http://www.xenomai.org/mailman/listinfo/xenomai
--
Carles Lopez
Software Engineer
carles.lopez@pal-robotics.com
http://www.pal-robotics.com
Pal Robotics, S.L.
c/ Pujades 77-79, 4t 4a
08005 Barcelona
Tel: +34 93 414 53 47
Fax: +34 93 209 11 09
Skype: carles.pal-robotics
Facebook http://www.facebook.com/palrobotics1
Twiter http://twitter.com/#%21/palrobotics
PAL robotics http://www.youtube.com/user/PALRobotics
channel
AVÍS DE CONFIDENCIALITAT: Aquest missatge i els seus documents adjunts
poden contenir informació privilegiada i/o confidencial que va
dirigida exclusivament al seu destinatari. Si vostè rep aquest
missatge i no és el destinatari assenyalat, o la persona encarregada
de l'entrega a la susdita persona, si us plau, notifiqui-ho
immediatament i remeti el missatge original a l'adreça de correu
electrònic indicada. Qualsevol còpia, ús o distribució no autoritzats
d'aquesta comunicació és estrictament prohibida.
AVISO DE CONFIDENCIALIDAD: Este mensaje y sus documentos adjuntos,
pueden contener información privilegiada y/o confidencial que está
dirigida exclusivamente a su destinatario. Si usted recibe este
mensaje y no es el destinatario indicado, o el empleado encargado de
su entrega a dicha persona, por favor, notifíquelo inmediatamente y
remita el mensaje original a la dirección de correo electrónico
indicada. Cualquier copia, uso o distribución no autorizados de esta
comunicación queda estrictamente prohibida.
CONFIDENTIALITY NOTICE: This e-mail and the accompanying document(s)
may contain confidential information which is privileged and intended
only for the individual or entity to whom they are addressed. If you
are not the intended recipient, you are hereby notified that any
disclosure, copying, distribution or use of this e-mail and/or
accompanying document(s) is strictly prohibited. If you have received
this e-mail in error, please immediately notify the sender at the
above e-mail address.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Xenomai] patch to src/utils/can/rtcansend.c to support data from a file
2013-04-19 13:58 ` Carles Lopez
@ 2013-04-19 20:01 ` Wolfgang Grandegger
2013-04-19 20:09 ` Daniel M. Drucker, Ph.D.
0 siblings, 1 reply; 17+ messages in thread
From: Wolfgang Grandegger @ 2013-04-19 20:01 UTC (permalink / raw)
To: Carles Lopez; +Cc: Daniel M. Drucker, Ph.D., xenomai
On 04/19/2013 03:58 PM, Carles Lopez wrote:
> Hi,
>
> as Daniel we are here also interested in dumping CAN frames to our
> devices and extending/adding this tool to Xenomai would be great.
>
> Sometimes in our company it's really useful to save the rtcanrecv
> output and, sometime later, send it in order to reproduce CAN traffic.
>
> do you guys think that it's interesting that rtcansendmulti supports
> same syntax than rtcanrecv output?
> To do for instance:
> rtcanrecv | rtcansendmulti -
Good idea. Sounds useful.
Wolfgang.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Xenomai] patch to src/utils/can/rtcansend.c to support data from a file
2013-04-19 20:01 ` Wolfgang Grandegger
@ 2013-04-19 20:09 ` Daniel M. Drucker, Ph.D.
2013-04-22 8:29 ` Wolfgang Grandegger
0 siblings, 1 reply; 17+ messages in thread
From: Daniel M. Drucker, Ph.D. @ 2013-04-19 20:09 UTC (permalink / raw)
To: Wolfgang Grandegger; +Cc: xenomai
>> do you guys think that it's interesting that rtcansendmulti supports
>> same syntax than rtcanrecv output?
>> To do for instance:
>> rtcanrecv | rtcansendmulti -
>
> Good idea. Sounds useful.
I'm not sure how I'd reconcile that idea with:
> I would prefer removing -i, -r, -e, etc. and add it as data:
> s 0x601 0x40 0x41 0x60 0x00 (standard frame)
> e 0x12345678 0x40 0x41 (extended frame)
> sr 0x601 (standard rtr frame)
> er 0x3456778 (extended rtr frame)
I liked the format I came up with because it explicitly does NOT
define any new syntax and does not require any kind of parsing beyond
what rtcansend is already doing with getopt.
Is there a good reason to define a new syntax? Using the syntax that
is the output of rtcanrecv would mean we couldn't have things like
per-message delays.
Daniel
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Xenomai] patch to src/utils/can/rtcansend.c to support data from a file
2013-04-19 20:09 ` Daniel M. Drucker, Ph.D.
@ 2013-04-22 8:29 ` Wolfgang Grandegger
2013-04-22 13:40 ` Daniel M. Drucker, Ph.D.
0 siblings, 1 reply; 17+ messages in thread
From: Wolfgang Grandegger @ 2013-04-22 8:29 UTC (permalink / raw)
To: Daniel M. Drucker, Ph.D.; +Cc: xenomai
On 04/19/2013 10:09 PM, Daniel M. Drucker, Ph.D. wrote:
>>> do you guys think that it's interesting that rtcansendmulti supports
>>> same syntax than rtcanrecv output?
>>> To do for instance:
>>> rtcanrecv | rtcansendmulti -
>>
>> Good idea. Sounds useful.
>
> I'm not sure how I'd reconcile that idea with:
>
>> I would prefer removing -i, -r, -e, etc. and add it as data:
>> s 0x601 0x40 0x41 0x60 0x00 (standard frame)
>> e 0x12345678 0x40 0x41 (extended frame)
>> sr 0x601 (standard rtr frame)
>> er 0x3456778 (extended rtr frame)
>
> I liked the format I came up with because it explicitly does NOT
> define any new syntax and does not require any kind of parsing beyond
> what rtcansend is already doing with getopt.
This method is not transparent/straight-forward, I feel. You mix various
things making the code more complex than necessary.
> Is there a good reason to define a new syntax? Using the syntax that
I still prefer a simple ascii base syntax describing the complete message.
> is the output of rtcanrecv would mean we couldn't have things like
> per-message delays.
You want to change the delay between messages as well? Anyway, the
output of rtcanrecv is probably to awkward to convert.
Wolfgang.
> Daniel
>
>
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Xenomai] patch to src/utils/can/rtcansend.c to support data from a file
2013-04-22 8:29 ` Wolfgang Grandegger
@ 2013-04-22 13:40 ` Daniel M. Drucker, Ph.D.
0 siblings, 0 replies; 17+ messages in thread
From: Daniel M. Drucker, Ph.D. @ 2013-04-22 13:40 UTC (permalink / raw)
To: Wolfgang Grandegger; +Cc: xenomai
> I still prefer a simple ascii base syntax describing the complete message.
Ok. What would you suggest? I'm not super-familiar with some of the
CAN stuff (like extended messages), so I'm not sure what would best
make sense.
> You want to change the delay between messages as well?
Yes, because often there are certain messages in the sequence that
cause the slave to stop listening for several milliseconds.
Daniel
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Xenomai] patch to src/utils/can/rtcansend.c to support data from a file
2013-04-18 7:19 ` Wolfgang Grandegger
2013-04-18 7:27 ` Wolfgang Grandegger
@ 2013-04-18 15:08 ` Daniel M. Drucker, Ph.D.
1 sibling, 0 replies; 17+ messages in thread
From: Daniel M. Drucker, Ph.D. @ 2013-04-18 15:08 UTC (permalink / raw)
To: Wolfgang Grandegger; +Cc: xenomai
> Well, I do still not see the real benefit of reading just the data from
> a file. Why is a simply shell script not good enough for that purpose?
Speed. Each invocation of rtcansend is slow. If you're sending several
dozen commands (in our case, to set up PDOs and step a servo through
the state machine on startup), it's the difference between:
shell script using rtcansend: 7.6 seconds
using rtcanmultisend: 0.8 seconds
> Anyway, the input file should provide the id, rtr and ext, apart from
> the data, at least.
Ok.
Daniel
^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2013-04-22 13:40 UTC | newest]
Thread overview: 17+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-03-28 22:00 [Xenomai] patch to src/utils/can/rtcansend.c to support data from a file Daniel M. Drucker, Ph.D.
2013-04-15 7:09 ` Wolfgang Grandegger
2013-04-17 3:04 ` Matthew Fornero
2013-04-17 3:06 ` Matthew Fornero
2013-04-17 5:30 ` Gilles Chanteperdrix
2013-04-17 13:04 ` Matthew Fornero
2013-04-17 13:07 ` Daniel M. Drucker, Ph.D.
2013-04-18 7:19 ` Wolfgang Grandegger
2013-04-18 7:27 ` Wolfgang Grandegger
2013-04-18 21:49 ` Daniel M. Drucker, Ph.D.
2013-04-19 8:55 ` Wolfgang Grandegger
2013-04-19 13:58 ` Carles Lopez
2013-04-19 20:01 ` Wolfgang Grandegger
2013-04-19 20:09 ` Daniel M. Drucker, Ph.D.
2013-04-22 8:29 ` Wolfgang Grandegger
2013-04-22 13:40 ` Daniel M. Drucker, Ph.D.
2013-04-18 15:08 ` Daniel M. Drucker, Ph.D.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.