From b11d79110ebea755d139406fa65e484cdc379cf0 Mon Sep 17 00:00:00 2001 From: dbrownell Date: Mon, 21 Sep 2009 18:52:45 +0000 Subject: Remove annoying end-of-line whitespace from doc/* files. git-svn-id: svn://svn.berlios.de/openocd/trunk@2744 b42882b7-edfa-0310-969c-e2dbd0fdcd60 --- doc/manual/primer/autotools.txt | 2 +- doc/manual/primer/docs.txt | 4 +-- doc/manual/primer/jtag.txt | 80 ++++++++++++++++++++--------------------- doc/manual/primer/patches.txt | 6 ++-- doc/manual/primer/tcl.txt | 38 ++++++++++---------- 5 files changed, 65 insertions(+), 65 deletions(-) (limited to 'doc/manual/primer') 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 make distcheck command produces an archive of the project deliverables (using make dist) 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 -$(srcdir). The Makefile uses a rule to convert +$(srcdir). The Makefile uses a rule to convert @c Doxyfile.in into the @c Doxyfile used by make doxygen. @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 svn diff. 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: ( , 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. -- cgit v1.2.3