diff rvinterf/doc/rvinterf.usage @ 431:5c75d84ffa81

rvinterf/doc: started documenting the usage of rvinterf tools
author Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
date Sat, 21 Jun 2014 23:36:13 +0000
parents
children
line wrap: on
line diff
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/rvinterf/doc/rvinterf.usage	Sat Jun 21 23:36:13 2014 +0000
@@ -0,0 +1,59 @@
+Rvinterf (the specific program by this name) is an extended version of rvtdump
+(see rvtdump.usage) that decodes and dumps and/or logs any and all output
+generated by the firmware running on the target just like rvtdump, but also
+creates a local UNIX domain socket on the host machine to which "client"
+programs can connect.  "Client" programs connecting to rvinterf via this local
+socket interface can:
+
+1. Receive copies of selected RVTMUX packets coming from the target;
+
+2. Send arbitrary RVTMUX packets toward the target.
+
+Rvinterf is invoked just like rvtdump:
+
+rvinterf [options] /dev/ttyXXX
+
+The following options have the same meaning as in rvtdump, see rvtdump.usage
+for the details: -b, -B, -d and -l.  The only difference is that -b without -l
+is potentially useful and thus allowed.
+
+Additional rvinterf options which don't exist in rvtdump are:
+
+-n
+
+	Suppress the output on stdout like -b, but don't fork into background.
+	This option is passed by "client" programs when they invoke rvinterf
+	behind the scenes instead of connecting to an already-running rvinterf
+	instance.
+
+-s pathname_for_socket
+
+	By default the local UNIX domain socket created by rvinterf is bound to
+	/tmp/rvinterf_socket; this option allows any other pathname to be
+	specified.
+
+-S <file descriptor number>
+
+	This option is not meant for direct use by human users.  It is passed
+	by "client" programs when they invoke rvinterf behind the scenes with
+	an unnamed and unbound socket pair instead of conecting to an already-
+	running rvinterf instance.
+
+-w number_in_seconds
+
+	It has been discovered experimentally that if an RVTMUX packet is sent
+	to a target when the latter is in the "deep sleep" state, the target
+	wakes up, but the packet that was sent is not received correctly.  TI's
+	reference fw seems to wait for 10 s after last serial activity before
+	falling into deep sleep (provided that all other conditions for that
+	sleep mode are satisfied), hence the following workaround has been
+	implemented in rvinterf: if a packet is to be sent to the target and
+	more than a set time has elapsed since the last transmitted packet, the
+	packet is preceded by a "wake-up shot" of 64 0 bytes (outside of a
+	packet, ignored by the fw) and a 100 ms pause.  This hack is not pretty,
+	but it appears to do its job of making RVTMUX communication with target
+	firmwares reliable.
+
+	The -w option changes the elapsed time threshold at which the "wake-up
+	shot" is sent; the default is 7 s.  Specify -w 0 to disable this hack
+	altogether.