FreeCalypso > hg > freecalypso-sw
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.