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 <[email protected]>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 > [email protected] > http://www.xenomai.org/mailman/listinfo/xenomai > _______________________________________________ Xenomai mailing list [email protected] http://www.xenomai.org/mailman/listinfo/xenomai
