On Saturday 30 May 2009, Øyvind Harboe wrote:
> Committed.
>
> Some more comments on reset_config and why it has the options
> it has.
>
>
> Index: C:/workspace/openocd/doc/openocd.texi
> ===================================================================
> --- C:/workspace/openocd/doc/openocd.texi (revision 1946)
> +++ C:/workspace/openocd/doc/openocd.texi (working copy)
> @@ -1699,7 +1699,20 @@
>
> @deffn {Command} reset_config mode_flag ...
> This command tells OpenOCD the reset configuration
> -of your combination of JTAG interface, board, and target.
> +of your combination of JTAG board and target in target
> +configuration scripts.
But it's *not* limited to configuration scripts; see my
previous "PROPOSAL 3":
https://lists.berlios.de/pipermail/openocd-development/2009-May/007318.html
#1 is now merged. If this gets restricted to config
scripts this should become a "{Config Command}".
And I think it's incorrect to imply that there is any
other command for saying that an interface doesn't
pass, for example, SRST (by removing "interface"
from the above text).
> +
> +If you have an interface that does not support SRST and
> +TRST(unlikely),
Not unlikely at all. The 14-pin JTAG connectors
that TI uses don't pass SRST. The 10-pin JTAG
connectors that Atmel uses with AVR8 (and AVR32)
chips don't pass TRST. (Although there's a pin
reserved for TRST. It's unclear if *any* JTAG
adapters use that, since the only chips supporting
that signal are the unclear-future AVR32 AP7s.)
Ergo my "PROPOSAL 2" (see URL above).
> then you may be able to work around that
> +problem by using a reset_config command to override any
> +settings in the target configuration script.
A point that's already made in the NOTE: at the top of
that chapter: "... when the JTAG adapter doesn’t support
everything, the system configuration file will need to
override parts of the reset configuration provided by
other files."
> +
> +SRST and TRST has a fairly well understood definition and
More correctly: "have fairly ... definitions ..." ;)
> +behaviour in the JTAG specification, but vendors take
> +liberties to achieve various more or less clearly understood
> +goals. Sometimes documentation is available, other times it
> +is not. OpenOCD has the reset_config command to allow OpenOCD
> +to deal with the various common cases.
IMO none of that text belongs in the description of what
the "reset_config" command itself does. Explanations and
motivations belong in "big picture" text ... like the
subsection immediately preceding this. And some of that
information already *is* included; see the tail end of
that preceding subsection.
One thing I'm trying to do with the docs is to improve
the quality, and part of that is focussing the command
descriptions on just describing "what" they do.
The other parts of the classic reportial "five W's"
(who, what, when, where, why ... and sometimes "how")
belong in text other than the command descriptions.
That implies a bit more effort to couple those kinds
of explanations with the rest of the story, but that's
exactly what's needed for good documentation.
- Dave
>
> The @var{mode_flag} options can be specified in any order, but only one
> of each type -- @var{signals}, @var{combination}, @var{trst_type},
>
>
> --
> Øyvind Harboe
> Embedded software and hardware consulting services
> http://consulting.zylin.com
> _______________________________________________
> Openocd-development mailing list
> [email protected]
> https://lists.berlios.de/mailman/listinfo/openocd-development
>
>
_______________________________________________
Openocd-development mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/openocd-development
