Differences

This shows you the differences between two versions of the page.

--- microcontrollers:microcontroller_development_notes [2012/01/11 22:41] – [Debugging] mithat
+++ microcontrollers:microcontroller_development_notes [2013/08/23 20:34] (current) – mithat
@@ Line 1: / Line 1: @@
 ====== Microcontroller development notes ======
-:!: //Caution: This page is under development and is deeply clouded by the author's lack of significant experience with microcontroller programming.//
+:!: //This page is under development.//
 Establishing a working microcontroller development setup involves two major areas:
@@ Line 13: / Line 13: @@
 The software tools installed on the host system (i.e., the //host toolchain//) that you'll use to prepare programs for a target system may include:
   * an assembler
-  * a compiler
-  * a linker
-  * a simulator
-  * a debugger
   * tools to prepare binary code for loading onto the target
   * a programmer
+  * a compiler (optional)
+  * a linker (optional)
+  * a simulator (optional)
+  * a debugger (optional)
-A compiler and linker will be required if you want to write your code in a high-level language. A simulator is useful for testing your code on the host system. A debugger can be used in conjunction with a simulator or with [[https://en.wikipedia.org/wiki/In-circuit_emulator|In-Circuit Emulation]]. A programmer is used to load the binary code onto the target processor and is discussed more completely in a later section.
+A compiler and linker will be required if you want to write your code in a high-level language. A simulator is useful for testing your code on the host system. A debugger can be used in conjunction with a simulator or with [[https://en.wikipedia.org/wiki/In-circuit_emulator|In-Circuit Emulation]].
+A programmer is used to load the binary code onto the target processor and is discussed more completely in a later section. A programmer isn't actually required if the target microcontroller has pre-installed on it a [[#bootloaders|bootloader]].
 ==== Language selection ====
@@ Line 33: / Line 35: @@
   * The target microcontroller must be supported by the selected h/w programmer.
-  * The selected h/w programmer must be supported by an available interface on the development system (serial bus or USB typically).
+  * The selected h/w programmer must be supported by an available interface on the development system (e.g, serial bus or USB).
   * The selected h/w programmer must be supported by a s/w programmer available for the development system OS.
   * The selected s/w programmer must also support the target microcontroller.
-There are a few different "styles" of h/w programmers from the target's perspective. Some programmers require you to physically remove the microcontroller from the target system and place it into a socket on the programmer. You do a magic incantation on your host computer and the microcontroller gets programmed. Then you remove the microcontroller from the programmer and put it back into the target. This setup was the standard for many years, but clearly it has its disadvantages: the target microcontroller must be socketed on the target board (essentially making it impossible to work with SMD devices), and the repeated remove-replace cycles are not only tedious but can damage the target microcontroller.
+==== Classic programmers ====
-This has lead to a second type of programmer "style" called [[https://en.wikipedia.org/wiki/In-System_Programming|In-System Programming]] (ISP). With an ISP programmer (pardon the redundancy), new firmware can be loaded onto the target while the target microcontroller it is still in the circuit. In other words, the h/w programmer connects directly to the target board. This requires that the appropriate interface be designed into the target board (typically on the order of a six-pin header). ISP is often accomplished using an industry-standard communication protocol originally developed for testing assemblies called [[https://en.wikipedia.org/wiki/Joint_Test_Action_Group|JTAG]]. So you'll see references to JTAG programmers---which are in fact ISP programmers.
+There are a few different "styles" of h/w programmers from the target's perspective. Classic microcontroller programmers require you to physically remove the microcontroller from the target system and place it into a socket on the programmer. You do a magic incantation on your host computer and the microcontroller gets programmed. Then you remove the microcontroller from the programmer and put it back into the target. This setup was the standard for many years, but clearly it has its disadvantages: the target microcontroller must be socketed on the target board (essentially making it impossible to work with SMD devices), and the repeated remove-replace cycles are not only tedious but can damage the target microcontroller.
-Do not confuse ISP with ICE ([[https://en.wikipedia.org/wiki/In-circuit_emulator|In-Circuit Emulation]]). ISP concerns itself with programming the target; ICE with debugging.
+==== In-System Programming ====
+The problems associated with "classic" target device programming have lead to a second type of programmer "style" called [[https://en.wikipedia.org/wiki/In-System_Programming|In-System Programming]] (ISP). With an ISP programmer (pardon the redundancy), new firmware is loaded onto the target while the target microcontroller it is still in the circuit. In other words, the h/w programmer connects directly to the target board. This requires that the appropriate interface be designed into the target board (typically on the order of a six-pin header). ISP is often accomplished using an industry-standard communication protocol originally developed for testing assemblies called [[https://en.wikipedia.org/wiki/Joint_Test_Action_Group|JTAG]]. So you'll see references to JTAG programmers---which are in fact ISP programmers.
+:!: Do not confuse ISP with ICE ([[https://en.wikipedia.org/wiki/In-circuit_emulator|In-Circuit Emulation]]). ISP concerns itself with programming the target; ICE with debugging.
+==== Bootloaders ====
+FIXME
 ===== Other stuff =====
@@ Line 54: / Line 64: @@
 ==== Debugging ====
-A debugger is a software tool that you can attach to a computing process and use to pause program flow and inspect and in many cases adjust the program's and/or processor's state.
+A debugger is a software tool that you can attach to a computing process and use to pause program flow and inspect as well as in many cases adjust the program's and/or processor's state.
-You can attach a debugger to a microcontroller in one of a few ways:
+You can attach a debugger to a microcontroller process in one of a few ways:
   * Run it on a simulator on the host and attach a debugger to the simulated process.
-  * Run it on an emulator on the host that connects to the target's socket with special hardware and use a debugger on the host.
+  * Run it on a "virtual processor" on the host that connects to the target's socket with special hardware---and use a debugger on the host.
   * Run it on a special version of the target processor that makes the processor state information available to the host in a special h/w interface.
   * Run it on a stock version of the target processor that that makes the processor state information available to the host in a standard JTAG interface.
@@ Line 64: / Line 74: @@
 The last three above are all referred to as [[https://en.wikipedia.org/wiki/In-circuit_emulator|In-Circuit Emulation]] (ICE)---even though only one of them actually involve emulation.
-==== Bootloaders ====
-FIXME