comparison 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
comparison
equal deleted inserted replaced
430:14618bd924ec 431:5c75d84ffa81
1 Rvinterf (the specific program by this name) is an extended version of rvtdump
2 (see rvtdump.usage) that decodes and dumps and/or logs any and all output
3 generated by the firmware running on the target just like rvtdump, but also
4 creates a local UNIX domain socket on the host machine to which "client"
5 programs can connect. "Client" programs connecting to rvinterf via this local
6 socket interface can:
7
8 1. Receive copies of selected RVTMUX packets coming from the target;
9
10 2. Send arbitrary RVTMUX packets toward the target.
11
12 Rvinterf is invoked just like rvtdump:
13
14 rvinterf [options] /dev/ttyXXX
15
16 The following options have the same meaning as in rvtdump, see rvtdump.usage
17 for the details: -b, -B, -d and -l. The only difference is that -b without -l
18 is potentially useful and thus allowed.
19
20 Additional rvinterf options which don't exist in rvtdump are:
21
22 -n
23
24 Suppress the output on stdout like -b, but don't fork into background.
25 This option is passed by "client" programs when they invoke rvinterf
26 behind the scenes instead of connecting to an already-running rvinterf
27 instance.
28
29 -s pathname_for_socket
30
31 By default the local UNIX domain socket created by rvinterf is bound to
32 /tmp/rvinterf_socket; this option allows any other pathname to be
33 specified.
34
35 -S <file descriptor number>
36
37 This option is not meant for direct use by human users. It is passed
38 by "client" programs when they invoke rvinterf behind the scenes with
39 an unnamed and unbound socket pair instead of conecting to an already-
40 running rvinterf instance.
41
42 -w number_in_seconds
43
44 It has been discovered experimentally that if an RVTMUX packet is sent
45 to a target when the latter is in the "deep sleep" state, the target
46 wakes up, but the packet that was sent is not received correctly. TI's
47 reference fw seems to wait for 10 s after last serial activity before
48 falling into deep sleep (provided that all other conditions for that
49 sleep mode are satisfied), hence the following workaround has been
50 implemented in rvinterf: if a packet is to be sent to the target and
51 more than a set time has elapsed since the last transmitted packet, the
52 packet is preceded by a "wake-up shot" of 64 0 bytes (outside of a
53 packet, ignored by the fw) and a 100 ms pause. This hack is not pretty,
54 but it appears to do its job of making RVTMUX communication with target
55 firmwares reliable.
56
57 The -w option changes the elapsed time threshold at which the "wake-up
58 shot" is sent; the default is 7 s. Specify -w 0 to disable this hack
59 altogether.