Remove annoying end-of-line whitespace from doc/* files.
git-svn-id: svn://svn.berlios.de/openocd/trunk@2744 b42882b7-edfa-0310-969c-e2dbd0fdcd60
This commit is contained in:
dbrownell
@@ -144,7 +144,7 @@ implement new checks.
|
||||
The <code>make distcheck</code> command produces an archive of the
|
||||
project deliverables (using <code>make dist</code>) and verifies its
|
||||
integrity for distribution by attemptng to use the package in the same
|
||||
manner as a user.
|
||||
manner as a user.
|
||||
|
||||
These checks includes the following steps:
|
||||
-# Unpack the project archive into its expected directory.
|
||||
|
||||
@@ -90,7 +90,7 @@ provide detailed documentation for each option.
|
||||
To support out-of-tree building of the documentation, the @c Doxyfile.in
|
||||
@c INPUT values will have all instances of the string @c "@srcdir@"
|
||||
replaced with the current value of the make variable
|
||||
<code>$(srcdir)</code>. The Makefile uses a rule to convert
|
||||
<code>$(srcdir)</code>. The Makefile uses a rule to convert
|
||||
@c Doxyfile.in into the @c Doxyfile used by <code>make doxygen</code>.
|
||||
|
||||
@section primerdoxyoocd OpenOCD Input Files
|
||||
@@ -105,7 +105,7 @@ that can be found under the @c doc/manual directory in the project tree.
|
||||
New files containing valid Doxygen markup that are placed in or under
|
||||
that directory will be detected and included in The Manual automatically.
|
||||
|
||||
@section primerdoxyman Doxygen Reference Manual
|
||||
@section primerdoxyman Doxygen Reference Manual
|
||||
|
||||
The full documentation for Doxygen can be referenced on-line at the project
|
||||
home page: http://www.doxygen.org/index.html. In HTML versions of this
|
||||
|
||||
@@ -1,14 +1,14 @@
|
||||
/** @page primerjtag OpenOCD JTAG Primer
|
||||
|
||||
JTAG is unnecessarily confusing, because JTAG is often confused with
|
||||
JTAG is unnecessarily confusing, because JTAG is often confused with
|
||||
boundary scan, which is just one of its possible functions.
|
||||
|
||||
JTAG is simply a communication interface designed to allow communication
|
||||
to functions contained on devices, for the designed purposes of
|
||||
initialisation, programming, testing, debugging, and anything else you
|
||||
JTAG is simply a communication interface designed to allow communication
|
||||
to functions contained on devices, for the designed purposes of
|
||||
initialisation, programming, testing, debugging, and anything else you
|
||||
want to use it for (as a chip designer).
|
||||
|
||||
Think of JTAG as I2C for testing. It doesn't define what it can do,
|
||||
Think of JTAG as I2C for testing. It doesn't define what it can do,
|
||||
just a logical interface that allows a uniform channel for communication.
|
||||
|
||||
See @par
|
||||
@@ -17,42 +17,42 @@ See @par
|
||||
and @par
|
||||
http://www.inaccessnetworks.com/projects/ianjtag/jtag-intro/jtag-state-machine-large.png
|
||||
|
||||
The first page (among other things) shows a logical representation
|
||||
describing how multiple devices are wired up using JTAG. JTAG does not
|
||||
specify, data rates or interface levels (3.3V/1.8V, etc) each device can
|
||||
support different data rates/interface logic levels. How to wire them
|
||||
The first page (among other things) shows a logical representation
|
||||
describing how multiple devices are wired up using JTAG. JTAG does not
|
||||
specify, data rates or interface levels (3.3V/1.8V, etc) each device can
|
||||
support different data rates/interface logic levels. How to wire them
|
||||
in a compatible way is an exercise for an engineer.
|
||||
|
||||
Basically TMS controls which shift register is placed on the device,
|
||||
between TDI and TDO. The second diagram shows the state transitions on
|
||||
Basically TMS controls which shift register is placed on the device,
|
||||
between TDI and TDO. The second diagram shows the state transitions on
|
||||
TMS which will select different shift registers.
|
||||
|
||||
The first thing you need to do is reset the state machine, because when
|
||||
you connect to a chip you do not know what state the controller is in,you need
|
||||
to clock TMS as 1, at least 7 times. This will put you into "Test Logic
|
||||
Reset" State. Knowing this, you can, once reset, then track what each
|
||||
transition on TMS will do, and hence know what state the JTAG state
|
||||
The first thing you need to do is reset the state machine, because when
|
||||
you connect to a chip you do not know what state the controller is in,you need
|
||||
to clock TMS as 1, at least 7 times. This will put you into "Test Logic
|
||||
Reset" State. Knowing this, you can, once reset, then track what each
|
||||
transition on TMS will do, and hence know what state the JTAG state
|
||||
machine is in.
|
||||
|
||||
There are 2 "types" of shift registers. The Instruction shift register
|
||||
and the data shift register. The sizes of these are undefined, and can
|
||||
change from chip to chip. The Instruction register is used to select
|
||||
which Data register/data register function is used, and the data
|
||||
There are 2 "types" of shift registers. The Instruction shift register
|
||||
and the data shift register. The sizes of these are undefined, and can
|
||||
change from chip to chip. The Instruction register is used to select
|
||||
which Data register/data register function is used, and the data
|
||||
register is used to read data from that function or write data to it.
|
||||
|
||||
Each of the states control what happens to either the data register or
|
||||
Each of the states control what happens to either the data register or
|
||||
instruction register.
|
||||
|
||||
For example, one of the data registers will be known as "bypass" this is
|
||||
(usually) a single bit which has no function and is used to bypass the
|
||||
chip. Assume we have 3 identical chips, wired up like the picture
|
||||
and each has a 3 bit instruction register, and there are 2 known
|
||||
instructions (110 = bypass, 010 = some other function) if we want to use
|
||||
"some other function", on the second chip in the line, and not change
|
||||
For example, one of the data registers will be known as "bypass" this is
|
||||
(usually) a single bit which has no function and is used to bypass the
|
||||
chip. Assume we have 3 identical chips, wired up like the picture
|
||||
and each has a 3 bit instruction register, and there are 2 known
|
||||
instructions (110 = bypass, 010 = some other function) if we want to use
|
||||
"some other function", on the second chip in the line, and not change
|
||||
the other chips we would do the following transitions.
|
||||
|
||||
From Test Logic Reset, TMS goes:
|
||||
|
||||
|
||||
0 1 1 0 0
|
||||
|
||||
which puts every chip in the chain into the "Shift IR state"
|
||||
@@ -60,7 +60,7 @@ Then (while holding TMS as 0) TDI goes:
|
||||
|
||||
0 1 1 0 1 0 0 1 1
|
||||
|
||||
which puts the following values in the instruction shift register for
|
||||
which puts the following values in the instruction shift register for
|
||||
each chip [110] [010] [110]
|
||||
|
||||
The order is reversed, because we shift out the least significant bit
|
||||
@@ -70,18 +70,18 @@ first. Then we transition TMS:
|
||||
|
||||
which puts us in the "Shift DR state".
|
||||
|
||||
Now when we clock data onto TDI (again while holding TMS to 0) , the
|
||||
data shifts through the data registers, and because of the instruction
|
||||
registers we selected (some other function has 8 bits in its data
|
||||
Now when we clock data onto TDI (again while holding TMS to 0) , the
|
||||
data shifts through the data registers, and because of the instruction
|
||||
registers we selected (some other function has 8 bits in its data
|
||||
register), our total data register in the chain looks like this:
|
||||
|
||||
0 00000000 0
|
||||
|
||||
The first and last bit are in the "bypassed" chips, so values read from
|
||||
them are irrelevant and data written to them is ignored. But we need to
|
||||
The first and last bit are in the "bypassed" chips, so values read from
|
||||
them are irrelevant and data written to them is ignored. But we need to
|
||||
write bits for those registers, because they are in the chain.
|
||||
|
||||
If we wanted to write 0xF5 to the data register we would clock out of
|
||||
If we wanted to write 0xF5 to the data register we would clock out of
|
||||
TDI (holding TMS to 0):
|
||||
|
||||
0 1 0 1 0 1 1 1 1 0
|
||||
@@ -91,13 +91,13 @@ clock TMS:
|
||||
|
||||
1 1 0
|
||||
|
||||
which updates the selected data register with the value 0xF5 and returns
|
||||
which updates the selected data register with the value 0xF5 and returns
|
||||
us to run test idle.
|
||||
|
||||
If we needed to read the data register before over-writing it with F5,
|
||||
no sweat, that's already done, because the TDI/TDO are set up as a
|
||||
circular shift register, so if you write enough bits to fill the shift
|
||||
register, you will receive the "captured" contents of the data registers
|
||||
If we needed to read the data register before over-writing it with F5,
|
||||
no sweat, that's already done, because the TDI/TDO are set up as a
|
||||
circular shift register, so if you write enough bits to fill the shift
|
||||
register, you will receive the "captured" contents of the data registers
|
||||
simultaneously on TDO.
|
||||
|
||||
That's JTAG in a nutshell. On top of this, you need to get specs for
|
||||
|
||||
@@ -8,7 +8,7 @@ for OpenOCD contributors who are unfamiliar with the process.
|
||||
The standard method for creating patches requires developers to:
|
||||
- checkout the Subversion repository (or bring a copy up-to-date),
|
||||
- make the necessary modifications to a working copy,
|
||||
- check with 'svn status' to see which files will be modified/added, and
|
||||
- check with 'svn status' to see which files will be modified/added, and
|
||||
- use 'svn diff' to review the changes and produce a patch.
|
||||
|
||||
It is important to minimize the changes to only those lines that contain
|
||||
@@ -67,7 +67,7 @@ patch, or you can specified specific files and directories when using
|
||||
<code>svn diff</code>. Overlapping patches will be discussed in the
|
||||
next section.
|
||||
|
||||
The remainder of this section provides
|
||||
The remainder of this section provides
|
||||
|
||||
@subsection primerpatchprops Subversion Properties
|
||||
|
||||
@@ -110,7 +110,7 @@ The following series of commands will work: @par
|
||||
svn diff foo | unix2dos | patch -R
|
||||
@endcode
|
||||
|
||||
This is not a bug.
|
||||
This is not a bug.
|
||||
|
||||
@todo Does Subversion's treatment of line-endings for files marked with
|
||||
svn:eol-style=native continue to pose the problems described here, or
|
||||
|
||||
@@ -115,7 +115,7 @@ Exception: The arrays.
|
||||
|
||||
set x "2 * 6"
|
||||
set foo([expr $x]) "twelve"
|
||||
|
||||
|
||||
**************************************************
|
||||
***************************************************
|
||||
=== TCL TOUR ===
|
||||
@@ -133,7 +133,7 @@ This means it is evaluated when the file is parsed.
|
||||
In TCL, "FOR" is a funny thing, it is not what you think it is.
|
||||
|
||||
Syntactically - FOR is a just a command, it is not language
|
||||
construct like for(;;) in C...
|
||||
construct like for(;;) in C...
|
||||
|
||||
The "for" command takes 4 parameters.
|
||||
(1) The "initial command" to execute.
|
||||
@@ -215,7 +215,7 @@ All memory regions must have 2 things:
|
||||
(2) NAME( array )
|
||||
And the array must have some specific names:
|
||||
( <idx>, THING )
|
||||
Where: THING is one of:
|
||||
Where: THING is one of:
|
||||
CHIPSELECT
|
||||
BASE
|
||||
LEN
|
||||
@@ -224,7 +224,7 @@ All memory regions must have 2 things:
|
||||
RWX - the access ability.
|
||||
WIDTH - the accessible width.
|
||||
|
||||
ie: Some regions of memory are not 'word'
|
||||
ie: Some regions of memory are not 'word'
|
||||
accessible.
|
||||
|
||||
The function "address_info" - given an address should
|
||||
@@ -237,14 +237,14 @@ tell you about the address.
|
||||
MAJOR FUNCTION:
|
||||
==
|
||||
|
||||
proc memread32 { ADDR }
|
||||
proc memread16 { ADDR }
|
||||
proc memread8 { ADDR }
|
||||
proc memread32 { ADDR }
|
||||
proc memread16 { ADDR }
|
||||
proc memread8 { ADDR }
|
||||
|
||||
All read memory - and return the contents.
|
||||
|
||||
[ FIXME: 7/5/2008 - I need to create "memwrite" functions]
|
||||
|
||||
|
||||
**************************************************
|
||||
***************************************************
|
||||
=== TCL TOUR ===
|
||||
@@ -265,13 +265,13 @@ In a makefile or shell script you may have seen this:
|
||||
FOO_linux = "Penguins rule"
|
||||
FOO_winXP = "Broken Glass"
|
||||
FOO_mac = "I like cat names"
|
||||
|
||||
|
||||
# Pick one
|
||||
BUILD = linux
|
||||
#BUILD = winXP
|
||||
#BUILD = mac
|
||||
FOO = ${FOO_${BUILD}}
|
||||
|
||||
|
||||
The "double [set] square bracket" thing is the TCL way, nothing more.
|
||||
|
||||
----
|
||||
@@ -290,7 +290,7 @@ Notice this IF COMMAND - (not statement) is like this:
|
||||
The "IF" command expects either 2 params, or 4 params.
|
||||
|
||||
=== Sidebar: About "commands" ===
|
||||
|
||||
|
||||
Take a look at the internals of "jim.c"
|
||||
Look for the function: Jim_IfCoreCommand()
|
||||
And all those other "CoreCommands"
|
||||
@@ -298,10 +298,10 @@ The "IF" command expects either 2 params, or 4 params.
|
||||
You'll notice - they all have "argc" and "argv"
|
||||
|
||||
Yea, the entire thing is done that way.
|
||||
|
||||
|
||||
IF is a command. SO is "FOR" and "WHILE" and "DO" and the
|
||||
others. That is why I keep using the phase it is a "command"
|
||||
|
||||
|
||||
=== END: Sidebar: About "commands" ===
|
||||
|
||||
Parameter 1 to the IF command is expected to be an expression.
|
||||
@@ -315,7 +315,7 @@ CATCH - is an error catcher.
|
||||
You give CATCH 1 or 2 parameters.
|
||||
The first 1st parameter is the "code to execute"
|
||||
The 2nd (optional) is where to put the error message.
|
||||
|
||||
|
||||
CATCH returns 0 on success, 1 for failure.
|
||||
The "![catch command]" is self explaintory.
|
||||
|
||||
@@ -325,7 +325,7 @@ above, the IF command can take many parameters they just have to
|
||||
be joined by exactly the words "else" or "elseif".
|
||||
|
||||
The 4th parameter contains:
|
||||
|
||||
|
||||
"error [format STRING....]"
|
||||
|
||||
This lets me modify the previous lower level error by tacking more
|
||||
@@ -346,7 +346,7 @@ string, then using "dlopen()" and "dlsym()" to look it up - and get a
|
||||
function pointer - and calling the function pointer.
|
||||
|
||||
In this case - I execute a dynamic command. You can do some cool
|
||||
tricks with interpretors.
|
||||
tricks with interpretors.
|
||||
|
||||
----------
|
||||
|
||||
@@ -380,7 +380,7 @@ Some assumptions:
|
||||
|
||||
The "CHIP" file has defined some variables in a proper form.
|
||||
|
||||
ie: AT91C_BASE_US0 - for usart0,
|
||||
ie: AT91C_BASE_US0 - for usart0,
|
||||
AT91C_BASE_US1 - for usart1
|
||||
... And so on ...
|
||||
|
||||
@@ -419,9 +419,9 @@ with the generated list of commands for the entire USART.
|
||||
With that little bit of code - I now have a bunch of functions like:
|
||||
|
||||
show_US0, show_US1, show_US2, .... etc ...
|
||||
|
||||
|
||||
And show_US0_MR, show_US0_IMR ... etc...
|
||||
|
||||
|
||||
And - I have this for every USART... without having to create tons of
|
||||
boiler plate yucky code.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user