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