fixed formatting and typos

Wiki/AddingOptibootChipsToIde.md

@@ -7,14 +7,14 @@ Both the preferred location and the format of the file change from version to ve
 
 # IDE Version 1.6.4 (and later)
 ## Boards Manager
-Verions 1.5.x (beta) of the IDE added support for a much broader range of non-AVR and 3rd party hardware.  This changed the directory structure in the user's sketchbook folder in ways that were incompatible with 1.0.x (in particular, adding a "platform" sub directory, so that boards.txt was in <sketchbook>/hardware/<extname>/<platformname>/)
+Versions 1.5.x (beta) of the IDE added support for a much broader range of non-AVR and 3rd party hardware.  This changed the directory structure in the user's sketchbook folder in ways that were incompatible with 1.0.x (in particular, adding a "platform" sub directory, so that boards.txt was in \<sketchbook\>/hardware/\<extname\>/\<platformname\>/).
 
 In 1.6.4 (a production release), the IDE added a "boards manager" that permits a 3rd party extension to be automatically downloaded and installed simply by adding a URL in the preferences panel and (in yet another location and clicking an "Install" button in the Boards Manager panel.  (The actual files end up in yet a different place in the file system, but this should be transparent to the users.)  This is the preferred way to install the Optiboot boards.txt if you are running 1.6.4 or later, but it does not (currently) install source code.
 
 # IDE version 1.0.x
-In version 1.0 of the Arduino IDE, it became possible to put hardware extensions in the sketchbook folder, by putting new subdirectories in <sketchbook>/hardware/<extname>.  You could put a suitably formatted boards.txt there describing the new optiboot cpus, pointing toward .hex files located in that tree, or in other locations.
+In version 1.0 of the Arduino IDE, it became possible to put hardware extensions in the sketchbook folder, by putting new subdirectories in \<sketchbook\>/hardware/\<extname\>.  You could put a suitably formatted boards.txt there describing the new optiboot cpus, pointing toward .hex files located in that tree, or in other locations.
 
 
 # IDE Version 00xx
-Optiboot was written prior to version 1.0 of the IDE.  In those days, the only way to add additional boards was to modify the boards.txt file that included within the directory structure of the IDE itself. (<installDir>/hardware/arduino/boards.txt, with the .hex files in <installDir>/hardware/arduino/bootloaders/optiboot)  The directory structure of the Optiboot repositor reflects this old structure.
+Optiboot was written prior to version 1.0 of the IDE.  In those days, the only way to add additional boards was to modify the boards.txt file that included within the directory structure of the IDE itself. (\<installDir\>/hardware/arduino/boards.txt, with the .hex files in \<installDir\>/hardware/arduino/bootloaders/optiboot)  The directory structure of the Optiboot repository reflects this old structure.
 

Wiki/CompilingOptiboot.md

@@ -7,12 +7,12 @@ This will require some relatively deep knowledge of avr-gcc, Atmel AVR hardware
 
 # Details #
 
-Optiboot is designed to be compiled with the same version of avr-gcc that is distributed with the Arduino environment: 4.3.2.  This is actually quite an old version of gcc; some effort has been made to allow the compile to procede with new versions of the compiler.  However, since Optiboot MUST compile to a total size of less than 512 bytes, it is very sensitive to changes in the way the compiler does optimizations, or the way it processes optimization options on the compile command.
+Optiboot is designed to be compiled with the same version of avr-gcc that is distributed with the Arduino environment: 4.3.2.  This is actually quite an old version of gcc; some effort has been made to allow the compile to proceed with new versions of the compiler.  However, since Optiboot MUST compile to a total size of less than 512 bytes, it is very sensitive to changes in the way the compiler does optimizations, or the way it processes optimization options on the compile command.
 
-In all cases, Optiboot compiles directly from the command line using "make", rather than from within any IDE.  It is currently designed to used compilers installed in one of three different places:
+In all cases, Optiboot compiles directly from the command line using "make", rather than from within any IDE.  It is currently designed to use compilers installed in one of three different places:
 
   * Local Development Environment - you have WinAVR (on Windows), CrossPack (on Mac), or an avr-gcc package (linux) installed on your system, with appropriate development tools somewhere in your path.
-  * You have Arduino installed, and are trying to compile Optiboot from its home directory within the Arduino directory structure (hardware/arduino/bootloaders/optiboot/)  The Arduino app includes a pretty complete set of compiler tools, and these can be used to compile optiboot without installing a separate toolchain. (as of Version 1.5 of the Arduino IDE, a much smaller set of tools is included, and this method doesn't work any more.)
+  * You have Arduino installed, and are trying to compile Optiboot from its home directory within the Arduino directory structure (hardware/arduino/bootloaders/optiboot/).  The Arduino app includes a pretty complete set of compiler tools, and these can be used to compile optiboot without installing a separate toolchain. (as of Version 1.5 of the Arduino IDE, a much smaller set of tools is included, and this method doesn't work any more.)
   * You have downloaded the Arduino Source code, which also includes (binary) copies of avr-gcc toolchains, and a source directory containing the Optiboot source code.
 
 WARNING: some targets don't compile with "make" 3.81 or 3.82 due to bug in it.  See https://github.com/Optiboot/optiboot/issues/106
@@ -41,17 +41,17 @@ Where <platform> is one of the named chips or boards implemented as normal targe
   * **LED=\<portpin\>**  --  Like "LED=B5" or "LED=L5" - which LED to flash.
   * **LED\_START\_FLASHES=n**  -- number of flashes to emit when the bootloader executes (default 3)  Setting this to 0 omits the LED-flashing code and saves some space.
   * **LED\_START\_ON**  -- Turn on the LED when the bootloader starts.  A smaller alternative to LED\_START\_FLASHES.
-  * **LED\_DATA\_FLASH=1 ** -- flash the LED in the data receive function as well as at bootloader startup.
+  * **LED\_DATA\_FLASH=1** -- flash the LED in the data receive function as well as at bootloader startup.
   * **BIGBOOT=1** -- include extra features that cause the bootloader to grow to between 512 and 1024 bytes.
   * **SUPPORT\_EEPROM=1** -- try to include EEPROM read/write support, without other BIGBOOT features.
-  * **NO\_APP\_SPM=1** -- Omit the code tat allows applications to have Optiboot execute an SPM instruction (for writing to flash.)
+  * **NO\_APP\_SPM=1** -- Omit the code that allows applications to have Optiboot execute an SPM instruction (for writing to flash.)
 
 For example:
 
 ~~~~
 make UART=1 LED=A7 AVR_FREQ=20000000L atmega1284
 ~~~~
-Note that many of the board-level targets are implemented using a recursive invocation of make using this options.  For exmaple, the "pro20" target ends up being:
+Note that many of the board-level targets are implemented using a recursive invocation of make using this options.  For example, the "pro20" target ends up being:
 
 ~~~~
  make atmega168 AVR_FREQ=20000000L LED_START_FLASHES=3

Wiki/CompilingOptiboot_x.md

@@ -55,7 +55,7 @@ For example:
 make -f Makefile.mega0 UARTTX=A1 LED=A7 atmega4809
 make -f Makefile.mega0 curiosity4809
 ~~~~
-Note that many of the board-level targets are implemented using a recursive invocation of make using this options.  For exmaple, the "drazzy402" target ends up being:
+Note that many of the board-level targets are implemented using a recursive invocation of make using this options.  For example, the "drazzy402" target ends up being:
 
 ~~~~
  make -f  Makefile.mega0 optiboot_attiny402.hex UARTTX=A1 TIMEOUT=8 LED=A7
@@ -66,6 +66,6 @@ The mega-0 and tiny-0/1 architecture is significantly different (and "nicer") th
 
  1. The bootloader starts at 0x0, and the Application start after the bootloader. <br>This means that the bootloader binary is the same for chips in the same family that have different flash memory size (eg ATmega1609 and ATmega4809.)
  2. Commonality of binaries.<br>These chips have much better cross-chip compatibility than previous AVR generations.  Common peripherals are identical and at the same addresses.  Combined with (1), this means that the same bootloader binary should run on any of the 14, 20, and 24pin tiny0 or tiny1 chips, if the same UARTTX ports are in use.
- 3. Chosing a UART.<br>In addition to having multiple UARTs, the mega-0 has a pin multiplexing ability that can redirect the functionality to two different sets of pins for each UART.  Specifying the port and pin of the TX signal uniquely identfies both the UART and pinmux settings.
+ 3. Choosing a UART.<br>In addition to having multiple UARTs, the mega-0 has a pin multiplexing ability that can redirect the functionality to two different sets of pins for each UART.  Specifying the port and pin of the TX signal uniquely identifies both the UART and pinmux settings.
  4. Clock speed.<br>Mega-0 chips normally boot to an internal clock that is accurate and fast enough for uart communications, regardless of whether "normal operation" of that board uses a different clock rate.  Optiboot runs off of this internal clock after figuring out the rate
  1. New NVM structure.<br>Flash and EEPROM are treated very similarly, so that support for both fits easily in the 512byte bootloader.

Wiki/GoodQuestions.md

@@ -10,7 +10,7 @@ Optiboot occasionally generates questions on various forums (Arduino, AVRFreaks,
 In older versions, Optiboot was limited by the "Version 1" STK500 communications protocol, which only allows up to 64kwords of flash to be programmed.  The v7.0 code uses an out-of-band "SPI Command" to set the RAMPX register.<br><br>
 
   1. Why does Optiboot have its own copy of boot.h ?<br><br>
-  The copy of boot.h used by Optiboot has been modified to use "out" instructions instead of "sts."  The out instruction is shorter, but only works if the target registers in withing the first 64 IO addresses.<br>
+  The copy of boot.h used by Optiboot has been modified to use "out" instructions instead of "sts."  The out instruction is shorter, but only works if the target register is within the first 64 IO addresses.<br>
   As of Version 7.0, the Optiboot copy of boot.h has been renamed to boot_opt.h, defines ONLY the special "short" functions, and includes the standard \<avr/boot.h\> to pick up all the standard definitions.<br><br>
 
   1. What is a "Virtual Boot Partition"<br><br> 

Wiki/HowOptibootWorks.md

@@ -2,7 +2,7 @@
 
 Optiboot implements a small subset of the  "STK500 communications protocol" (version 1) defined by Atmel in their [Application Note AVR061](http://www.atmel.com/Images/doc2525.pdf)  In order to conserve code space, many of the protocol commands are ignored and receive "lies" rather than correct response codes, leading to the possibility that the bootloader may not operate correctly with all host-side software.  It is known to work with versions of "avrdude" supporting the "-c arduino" programmer type.
 
-Optiboot is designed to reside in the bootloader section, and chip fuses should be set appropriately for the size of optiboot (normally 256 words) (BOOTSZx) and to reset to the bootloader start address (BOOTRST)  Note that BOOTSZx values are chip-dependent, and some of the chips suppored by Optiboot have a 512word minimum bootloader size.)
+Optiboot is designed to reside in the bootloader section, and chip fuses should be set appropriately for the size of optiboot (normally 256 words) (BOOTSZx) and to reset to the bootloader start address (BOOTRST).  Note that BOOTSZx values are chip-dependent, and some of the chips supported by Optiboot have a 512 word minimum bootloader size.)
 
 ## Basic Operation ##
   1. On reset, Optiboot starts and reads the reset reason from MCUSR.  For any cause other than "external reset", the application is started immediately.  Otherwise, optiboot attempts to download new application software:
@@ -33,7 +33,7 @@ The following commands will have their arguments correctly read, and produce in
 |STK\_SET\_DEVICE|0x42, 'B'| |
 |STK\_SET\_DEVICE\_EXT|0x45, 'E'| |
 
-All other commands will result in a success response if they are immediate followed by CRC\_EOP (0x20, ' ') (ie they are ignored), or a WDT reset (start applicatin) otherwise.
+All other commands will result in a success response if they are immediate followed by CRC\_EOP (0x20, ' ') (ie they are ignored), or a WDT reset (start application) otherwise.
 
 ## Space Saving Techniques ##
 In order to save space, Optiboot utilizes a couple of techniques that may be of general interest:

Wiki/InstallingOnChips.md

@@ -4,7 +4,7 @@ There are two aspects to "installing optiboot."  The first problem, which is dis
 
 The second problem is configuring the Arduino IDE to support the optiboot-loaded chips.  This is easy if you're loading up ATmega328x chips, since any 328 chip with optiboot is essentially an Arduino Uno, and you can use the existing Uno configuration.  It is more difficult (and not yet documented) if you're adding a new chip, or putting optiboot on a chip that normally uses a different bootloader.  This is (will be) described at [AddingOptibootChipsToIde](https://github.com/Optiboot/optiboot/blob/master/Wiki/AddingOptibootChipsToIde.md).
 
-Much information about burning optiboot into ATmega chips for use in Arduino can be found in the Arduino forums, especially in [this thread](http://arduino.cc/forum/index.php/topic,64105.0.html)
+Much information about burning optiboot into ATmega chips for use in Arduino can be found in the Arduino forums, especially in [this thread](http://arduino.cc/forum/index.php/topic,64105.0.html).
 
 There are about three main methods of installing optiboot on an otherwise blank AVR chip.
 

Wiki/Virtual-Boot-Partition.md

@@ -29,4 +29,4 @@
   1. Any downsides of this feature?<br>
  Sadly, there are 2 of them:
  <br>The Bootloader code is larger and doesn't fit in 512B.
- <br>It requres one unused vector to store original jump to application. And you must be sure that this vector will be unused by applications loaded by Optiboot with VBP enabled.
+ <br>It requires one unused vector to store original jump to application. And you must be sure that this vector will be unused by applications loaded by Optiboot with VBP enabled.

Wiki/github-issue-labels

@@ -1,4 +1,4 @@
-Explanations for possibly mysterious lables used on Optiboot github "issues."
+Explanations for possibly mysterious labels used on Optiboot github "issues."
 
 Component-Docs  - requires a fix in the documentation only
 Component-Makefiles - requires a change to the makefiles only

optiboot/bootloaders/optiboot/README.TXT

@@ -11,7 +11,7 @@ Arduino-specific issues are tracked as part of the Arduino project
 at http://github.com/arduino/Arduino
 
 
-Most of the information in this file is superceeded by the wiki content at
+Most of the information in this file is superseded by the wiki content at
 https://github.com/Optiboot/optiboot/wiki
 
 It's till here "just in case."
@@ -63,7 +63,7 @@ or  make OS=macosx ENV=arduinodev <targets>
 
 Programming Chips Using the _isp Targets
 
-The CPU targets have corresponding ISP targets that will actuall
+The CPU targets have corresponding ISP targets that will actually
 program the bootloader into a chip. "atmega328_isp" for the atmega328,
 for example.  These will set the fuses and lock bits as appropriate as
 well as uploading the bootloader code.