Remove annoying end-of-line whitespace from doc/* files.

git-svn-id: svn://svn.berlios.de/openocd/trunk@2744 b42882b7-edfa-0310-969c-e2dbd0fdcd60

5 files changed, 65 insertions, 65 deletions

diff --git a/doc/manual/primer/autotools.txt b/doc/manual/primer/autotools.txt
index 10c60006..fbf42196 100644
--- a/doc/manual/primer/autotools.txt
+++ b/doc/manual/primer/autotools.txt
@@ -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.
diff --git a/doc/manual/primer/docs.txt b/doc/manual/primer/docs.txt
index d478d81c..504da790 100644
--- a/doc/manual/primer/docs.txt
+++ b/doc/manual/primer/docs.txt
@@ -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
diff --git a/doc/manual/primer/jtag.txt b/doc/manual/primer/jtag.txt
index 9142dadc..0c675282 100644
--- a/doc/manual/primer/jtag.txt
+++ b/doc/manual/primer/jtag.txt
@@ -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
diff --git a/doc/manual/primer/patches.txt b/doc/manual/primer/patches.txt
index 098766eb..b24e72fa 100644
--- a/doc/manual/primer/patches.txt
+++ b/doc/manual/primer/patches.txt
@@ -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
diff --git a/doc/manual/primer/tcl.txt b/doc/manual/primer/tcl.txt
index c10c3647..9be4a05e 100644
--- a/doc/manual/primer/tcl.txt
+++ b/doc/manual/primer/tcl.txt
@@ -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.