From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <5174F4E3.8030603@grandegger.com> Date: Mon, 22 Apr 2013 10:29:23 +0200 From: Wolfgang Grandegger MIME-Version: 1.0 References: <516BA7C4.1050403@grandegger.com> <516E336C.1060509@xenomai.org> <516F9E87.6020002@grandegger.com> <516FA077.20400@grandegger.com> <5171069C.3020909@grandegger.com> <5171A299.60905@grandegger.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Xenomai] patch to src/utils/can/rtcansend.c to support data from a file List-Id: Discussions about the Xenomai project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel M. Drucker, Ph.D." Cc: xenomai@xenomai.org 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 > >