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