reorganize doc

README.md

@@ -16,19 +16,24 @@ alt="Yuotube" width="100%" height="auto" border="10" /></a>
 
 | FAQ's & Updates     | Installation        | Use of the Proxmark |
 | ------------- |:-------------:| -----:|
-|[Whats changed?](#whats-changed)  | [Setup and build for ArchLinux](/Installation_Instructions/Arch-Linux-Installation-Instructions.md) | [Validating proxmark client functionality](/Use_of_Proxmark/1_Validation.md)|
-|[Development](#development) | [Setup and build for UBUNTU](/Installation_Instructions/Ubuntu-Installation-Instructions.md)  | [First Use and Verification](/Use_of_Proxmark/2_Configuration-and-Verification.md) |
-| [Why don't you add this or that functionality?](#why-dont-you-add-this-or-that-functionality)  | [Homebrew (Mac OS X) & Upgrading HomeBrew Tap Forumula](/Installation_Instructions/Mac-OS-X-Homebrew-Installation-Instructions.md) | [Commands & Features](/Use_of_Proxmark/3_Commands-and-Features.md)|
-|[Why didn't you based it on offical PM3 Master?](#why-didnt-you-based-it-on-offical-pm3-master) |[ParrotOS Installation ](/Installation_Instructions/Parrot-OS-Proxmark3-RDV4-installation.md)|[PM3 GUI](#pm3-gui)
-|[Notices](#notices)|[Setup and build for Windows](/Installation_Instructions/Windows-Installation-Instructions.md)||
-|[Issues](#issues)|[Coverity Scan Config & Run](/Installation_Instructions/Coverity-Scan-Config-%26-Run.md)||
-||[Kali Linux Installation Instructions](/Installation_Instructions/Kali-Installation-Instructions.md)|
+|[Whats changed?](#whats-changed)  | [Setup and build for ArchLinux](/doc/md/Installation_Instructions/Arch-Linux-Installation-Instructions.md) | [Validating proxmark client functionality](/doc/md/Use_of_Proxmark/1_Validation.md)|
+|[Development](#development) | [Setup and build for UBUNTU](/doc/md/Installation_Instructions/Ubuntu-Installation-Instructions.md)  | [First Use and Verification](/doc/md/Use_of_Proxmark/2_Configuration-and-Verification.md) |
+| [Why don't you add this or that functionality?](#why-dont-you-add-this-or-that-functionality)  | [Homebrew (Mac OS X) & Upgrading HomeBrew Tap Forumula](/doc/md/Installation_Instructions/Mac-OS-X-Homebrew-Installation-Instructions.md) | [Commands & Features](/doc/md/Use_of_Proxmark/3_Commands-and-Features.md)|
+|[Why didn't you based it on offical PM3 Master?](#why-didnt-you-based-it-on-offical-pm3-master) |[ParrotOS Installation ](/doc/md/Installation_Instructions/Parrot-OS-Proxmark3-RDV4-installation.md)|[PM3 GUI](#pm3-gui)
+|[Notices](#notices)|[Setup and build for Windows](/doc/md/Installation_Instructions/Windows-Installation-Instructions.md)||
+|[Issues](#issues)|[Coverity Scan Config & Run](/doc/md/Installation_Instructions/Coverity-Scan-Config-%26-Run.md)||
+||[Kali Linux Installation Instructions](/doc/md/Installation_Instructions/Kali-Installation-Instructions.md)|
 
 ---
 ## Whats changed?
-	* added flash memory 256kb.
-	* added smart card module
-	* added FPC connector
+
+On the hardware side:
+
+  * added flash memory 256kb.
+  * added smart card module
+  * added FPC connector
+
+On the software side: quite a lot, see the [Changelog file](CHANGELOG.md).
 
 ## Development
 This fork now compiles just fine on 

doc/original_proxmark3/system.txt

@@ -1,276 +1,276 @@
-
-This is outdated.
-
----
-
-INTRODUCTION TO THE proxmark3
-=============================
-
-The proxmark3 device is designed to manipulate RFID tags in a number of
-different ways. For example, a proxmark3 can:
-
-    * read a low-frequency (~100 kHz) or high-frequency (13.56 MHz) tag,
-      including the ISO-standard tags; standards that require
-      bidirectional communication between the reader and the tag are
-      not a problem
-
-    * emulate a low- or high-frequency tag, in a way very similar to the
-      way that a real tag behaves (e.g., it derives its timing from the
-      incident carrier)
-
-    * eavesdrop on the signals exchanged between another reader and tag
-
-    * measure the resonant frequency of an antenna, to a certain extent
-      (this is a convenience when building a test setup for the previous
-      three functions)
-
-The proxmark3 may be thought of as a direct-sampling software radio.
-There is some complication, though, because of the usual dynamic range
-issue in dealing with signals in RFID systems (large signal due to
-the reader, small signal due to the tag). Some analog processing is
-therefore used to fix this before the signal is digitized. (Although,
-it is possible to digitize the signal from the antenna directly, with
-appropriate population options. It is just not usually a good idea.)
-
-SYSTEM ARCHITECTURE
-===================
-
-The ANTENNA sends and receives signals over the air. It is external to
-the board; it connects through SV2. Separate pins on the connector are
-used for the low- and high-frequency antennas, and the analog receive
-paths are separate. The antennas are inductive loops, which are resonated
-by on-board capacitors.
-
-On the transmit side, the antennas are excited by large numbers of
-paralleled bus driver buffers. By tri-stating some of the buffers, it
-is possible to vary the transmit strength. This may be used to generate
-a modulated carrier. The buffers are driven by signals from the FPGA,
-as are the output enables. The antennas are excited as series circuits,
-which permits a large input power for a relatively small input voltage.
-
-By driving all of the buffers low, it is possible to make the antenna
-look to the receive path like a parallel LC circuit; this provides a
-high-voltage output signal. This is typically what will be done when we
-are not actively transmitting a carrier (i.e., behaving as a reader).
-
-On the receive side, there are two possibilities, which are selected by
-RLY1. A mechanical relay is used, because the signal from the antenna is
-likely to be more positive or negative than the highest or lowest supply
-voltages on-board. In the usual case (PEAK-DETECTED mode), the received
-signal is peak-detected by an analog circuit, then filtered slightly,
-and then digitized by the ADC. This is the case for both the low- and
-high-frequency paths, although the details of the circuits for the
-two cases are somewhat different. This receive path would typically
-be selected when the device is behaving as a reader, or when it is
-eavesdropping at close range.
-
-It is also possible to digitize the signal from the antenna directly (RAW
-mode), after passing it through a gain stage. This is more likely to be
-useful in reading signals at long range, but the available dynamic range
-will be poor, since it is limited by the 8-bit A/D. These modes would be
-very appropriate, for example, for the heavily-discussed attacks in which
-a tag's ID is learned from the data broadcast by a reader performing an
-anticollision loop, because there is no dynamic range problem there. It
-would also be possible to program the proxmark3 to receive broadcast AM
-radio, with certain changes in component values.
-
-In either case, an analog signal is digitized by the ADC (IC8), and
-from there goes in to the FPGA (IC1). The FPGA is big enough that it
-can perform DSP operations itself. For some high-frequency standards,
-the subcarriers are fast enough that it would be inconvenient to do all
-the math on a general-purpose CPU. The FPGA can therefore correlate for
-the desired signal itself, and simply report the total to the ARM. For
-low-frequency tags, it probably makes sense just to pass data straight
-through to the ARM.
-
-The FPGA communicates with the ARM through either its SPI port (the ARM
-is the master) or its generic synchronous serial port (again, the ARM
-is the master). The ARM connects to the outside world over USB.
-
-DETAILS: POWER DISTRIBUTION
-===========================
-
-I make a half-hearted attempt to meet the USB power specs; this adds a
-bit of complexity. I have not made measurements to determine how close
-I come to succeeding, but I think that the suspend current might turn
-out to be a pain.
-
-The +3V3 rail is always powered, whenever we are plugged in to USB. This
-is generated by an LDO, which burns a quiescent current of 150 uA
-(typical) already. The only thing powered from the +3V3 rail is the ARM,
-which can presumably do smart power control when we are in suspend.
-
-The ARM generates two signals to switch power to the rest of the board:
-FPGA_ON, and NVDD_ON. When NVDD_ON goes low, the Vdd rail comes up to
-about five volts (the filtered-but-unregulated USB voltage). This powers
-most of the analog circuitry, including the ADC and all of the opamps
-and comparators in the receive path, and the coil drivers as well. Vdd
-also feeds the +3V3-FPGA and +2v5 regulators, which power only the
-FPGA. These regulators are enabled by FPGA_ON, so the FPGA is powered
-only when NVDD_ON is asserted low, and FPGA_ON is asserted high.
-
-DETAILS: FPGA
-=============
-
-The FPGA is a Spartan-II. This is a little bit old, but it is widely
-available, inexpensive, and five-volt tolerant. For development, the FPGA
-is configured over JTAG (SV5). In operation, the FPGA is configured in
-slave serial mode by the ARM, from a bitstream stored in the ARM's flash.
-
-Power to the FPGA is managed by regulators IC13 and IC12, both of which
-have shutdown. These generate the FPGA's VCCO (+3v3) and VCCINT (+2v5)
-supplies. I am a little bit worried about the power-on surge, since we
-run off USB. At the very minimum, the FPGA should not get power until
-we have enumerated and requested the full 500 mA available from USB. The
-large electrolytic capacitors C37 and C38 will presumably help with this.
-
-The logic is written in Verilog, of course for webpack. I have structured
-the FPGA in terms of `major modes:' the FPGA's `major mode' determines
-which of several modules is connected to the FPGA's I/O pins. A separate
-module is used for each of the FPGA's function; for example, there is
-now a module to read a 125 kHz tag, simulate a 125 kHz tag, transmit to
-an ISO 15693 tag, and receive from an ISO 15693 tag.
-
-DETAILS: ANALOG RECEIVE PATH
-============================
-
-For `slow' signals, I use an MCP6294 opamp. This has a GBW of 10 MHz,
-which is more than enough for the low-frequency stuff, and enough for
-all of the subcarrier frequencies that I know of at high frequency. In
-practice, the `slow' signals are all the signals following the peak
-detector. These signals are usually centred around the generated
-voltage Vmid.
-
-For `fast' signals, I use an AD8052. This is a very fast voltage-feedback
-amplifier (~100 MHz GBW). I use it immediately after the antenna for
-both the low- and high-frequency cases, as a sort of an ugly LNA. It is
-not optimal, but it certainly made the design easy.
-
-An ordinary CD4066 is used to multiplex the four possible signals
-(low/high frequency paths, RAW/PEAK-DETECTED). There is a potential
-problem at startup, when the ARM is in reset; there are pull-ups on the
-lines that control the mux, so all of the switches turn on. This shorts
-the four opamp outputs together through the on-resistance of the switch.
-All four outputs float to the same DC voltage with no signal, however,
-and the on-resistance of the switches is fairly large, so I don't think
-that will be a problem in practice.
-
-Comparators are used to generate clock signals when the device is
-emulating a tag. These clock signals are generated from the signal on the
-antenna, and therefore from the signal transmitted by the reader. This
-allows us to clock ourselves off the reader, just like a real tag would.
-These signals go in to the FPGA. There is a potential problem when the
-FPGA is powered down; these outputs might go high and try to power the
-FPGA through the protection diodes. My present solution to this is a
-couple of resistors, which is not very elegeant.
-
-The high-frequency peak-detected receive path contains population options
-for many features that I do not currently use. A lot of these are just
-me guessing that if I provide options for different series and shunt
-passives, perhaps it will come in handy in some way. The Zener diodes D10
-and D11 are optional, but may protect the front end from an overvoltage
-(which will fry the peak detector diodes) when the `simulated tag'
-is read by a powerful reader.
-
-DETAILS: ANALOG TRANSMIT PATH
-=============================
-
-The coil drivers are just ACT244 bus buffers. I parallel eight of them
-for each antenna (eight for the high-frequency antenna, eight for the
-low-frequency antenna). This should easily provide a hundred milliamps
-coil drive or so, which is more than enough for anything that I imagine
-doing with the device. The drivers hit the coil with a square wave
-voltage, however, which means that it is only the bandpass filter effect
-of a resonant antenna that suppresses the odd harmonics. In practice it
-would probably take heroic efforts (high antenna Q) to meet the FCC/CE
-harmonic specs; and in practice no one cares.
-
-The tx strength, given good antenna tuning, is determined by the series
-resistors. Choose the ratios to stay within the rated current of the
-buffers, and to achieve the desired power ratios by enabling or disabling
-nOEs for the desired modulation index. It is useful to populate one of the
-resistors as a high value (~10k) for the simulated tag modes; this allows
-us to look at the incident carrier without loading the reader very much.
-
-DETAILS: ARM
-============
-
-Atmel makes a number of pin-compatible ARMs, with slightly different
-peripherals, and different amounts of flash and RAM. It is necessary
-to choose a device with enough flash not just for the ARM's program,
-but also for the FPGA image (which is loaded by the ARM).
-
-The ARM is responsible for programming the FPGA. It also supplies a
-clock to the FPGA (although the FPGA clock can also run off the 13.56
-MHz clock not used for anything else, which is obviously asynchronous
-to anything in the ARM).
-
-It is necessary to use JTAG to bring the ARM for the first time; at
-that point you can load a bootrom, and subsequently load new software
-over USB. It might be possible to use the ARM's pre-loaded bootloader
-(see datasheet) instead of JTAG, but I wanted the JTAG anyways for
-debugging, so I did not bother. I used a Wiggler clone, with Macraigor's
-OCD Commander. More expensive tools would work as well.
-
-USB SOFTWARE
-============
-
-At present I enumerate as an HID device. This saves me writing a driver,
-but it forces me to do interrupt transfers for everything. This limits
-speed and is not very elegant. A real USB driver would be nice, maybe
-even one that could do stuff like going isochronous to stream samples
-from the A/D for processing on the PC.
-
-PRETENDING TO BE A TAG
-======================
-
-It is not possible, with the given topology, to open-circuit the antenna
-entirely and still look at the signal received on it. The simulated tag
-modes must therefore switch between slight loading and heavy loading,
-not open- and short-circuts across the antenna, evening though they do
-not depend upon the incident carrier for power (just timing information).
-
-RECEIVING SIGNAL STRAIGHT FROM THE ANTENNAS
-===========================================
-
-There is a path straight from the antenna to the A/D, bypassing the peak
-detector assembly. This goes through a gain stage (just a fast voltage
-feedback opamp), and from there straight in to the mux.
-
-It is necessary to energize the relay to connect these paths. If the
-coil is driven (as if to excite and read a tag) while these paths are
-connected, then damage will probably result. Most likely the opamp
-will fry.
-
-READING A TAG
-=============
-
-The tag is excited by a carrier transmitted by the reader. This is
-generated by IC9 and IC10, using some combination of buffers. The transmit
-power is determined by selecting the right combination of PWR_OEx pins;
-drive more of them low for more power. This can be used to modulate the
-transmitted signal, and thus send information to the tag.
-
-The received signal from the antenna is first peak-detected, and then
-high-pass filtered to reject the unmodulated carrier. The signal is
-amplified a bit, and goes in to the A/D mux from there. The A/D is
-controlled by the FPGA. For 13.56 MHz tags, it is easiest to do everything
-synchronous to the 13.56 MHz carrier.
-
-INTERFACE FROM THE ARM TO THE FPGA
-==================================
-
-The FPGA and the ARM can communicate in two main ways: using the ARM's
-general-purpose synchronous serial port (the SSP), or using the ARM's
-SPI port. The SPI port is used to configure the FPGA. The ARM writes a
-configuration word to the FPGA, which determines what operation will
-be performed (e.g. read 13.56 MHz vs. read 125 kHz vs. read 134 kHz
-vs...). The SPI is used exclusively for configuration.
-
-The SSP is used for actual data sent over the air. The ARM's SSP can
-work in slave mode, which means that we can send the data using clocks
-generated by the FPGA (either from the PCK0 clock, which the ARM itself
-supplies, or from the 13.56 MHz clock, which is certainly not going to
-be synchronous to anything in the ARM), which saves synchronizing logic
-in the FPGA. The SSP is bi-directional and full-duplex.
-
+
+This is outdated.
+
+---
+
+INTRODUCTION TO THE proxmark3
+=============================
+
+The proxmark3 device is designed to manipulate RFID tags in a number of
+different ways. For example, a proxmark3 can:
+
+    * read a low-frequency (~100 kHz) or high-frequency (13.56 MHz) tag,
+      including the ISO-standard tags; standards that require
+      bidirectional communication between the reader and the tag are
+      not a problem
+
+    * emulate a low- or high-frequency tag, in a way very similar to the
+      way that a real tag behaves (e.g., it derives its timing from the
+      incident carrier)
+
+    * eavesdrop on the signals exchanged between another reader and tag
+
+    * measure the resonant frequency of an antenna, to a certain extent
+      (this is a convenience when building a test setup for the previous
+      three functions)
+
+The proxmark3 may be thought of as a direct-sampling software radio.
+There is some complication, though, because of the usual dynamic range
+issue in dealing with signals in RFID systems (large signal due to
+the reader, small signal due to the tag). Some analog processing is
+therefore used to fix this before the signal is digitized. (Although,
+it is possible to digitize the signal from the antenna directly, with
+appropriate population options. It is just not usually a good idea.)
+
+SYSTEM ARCHITECTURE
+===================
+
+The ANTENNA sends and receives signals over the air. It is external to
+the board; it connects through SV2. Separate pins on the connector are
+used for the low- and high-frequency antennas, and the analog receive
+paths are separate. The antennas are inductive loops, which are resonated
+by on-board capacitors.
+
+On the transmit side, the antennas are excited by large numbers of
+paralleled bus driver buffers. By tri-stating some of the buffers, it
+is possible to vary the transmit strength. This may be used to generate
+a modulated carrier. The buffers are driven by signals from the FPGA,
+as are the output enables. The antennas are excited as series circuits,
+which permits a large input power for a relatively small input voltage.
+
+By driving all of the buffers low, it is possible to make the antenna
+look to the receive path like a parallel LC circuit; this provides a
+high-voltage output signal. This is typically what will be done when we
+are not actively transmitting a carrier (i.e., behaving as a reader).
+
+On the receive side, there are two possibilities, which are selected by
+RLY1. A mechanical relay is used, because the signal from the antenna is
+likely to be more positive or negative than the highest or lowest supply
+voltages on-board. In the usual case (PEAK-DETECTED mode), the received
+signal is peak-detected by an analog circuit, then filtered slightly,
+and then digitized by the ADC. This is the case for both the low- and
+high-frequency paths, although the details of the circuits for the
+two cases are somewhat different. This receive path would typically
+be selected when the device is behaving as a reader, or when it is
+eavesdropping at close range.
+
+It is also possible to digitize the signal from the antenna directly (RAW
+mode), after passing it through a gain stage. This is more likely to be
+useful in reading signals at long range, but the available dynamic range
+will be poor, since it is limited by the 8-bit A/D. These modes would be
+very appropriate, for example, for the heavily-discussed attacks in which
+a tag's ID is learned from the data broadcast by a reader performing an
+anticollision loop, because there is no dynamic range problem there. It
+would also be possible to program the proxmark3 to receive broadcast AM
+radio, with certain changes in component values.
+
+In either case, an analog signal is digitized by the ADC (IC8), and
+from there goes in to the FPGA (IC1). The FPGA is big enough that it
+can perform DSP operations itself. For some high-frequency standards,
+the subcarriers are fast enough that it would be inconvenient to do all
+the math on a general-purpose CPU. The FPGA can therefore correlate for
+the desired signal itself, and simply report the total to the ARM. For
+low-frequency tags, it probably makes sense just to pass data straight
+through to the ARM.
+
+The FPGA communicates with the ARM through either its SPI port (the ARM
+is the master) or its generic synchronous serial port (again, the ARM
+is the master). The ARM connects to the outside world over USB.
+
+DETAILS: POWER DISTRIBUTION
+===========================
+
+I make a half-hearted attempt to meet the USB power specs; this adds a
+bit of complexity. I have not made measurements to determine how close
+I come to succeeding, but I think that the suspend current might turn
+out to be a pain.
+
+The +3V3 rail is always powered, whenever we are plugged in to USB. This
+is generated by an LDO, which burns a quiescent current of 150 uA
+(typical) already. The only thing powered from the +3V3 rail is the ARM,
+which can presumably do smart power control when we are in suspend.
+
+The ARM generates two signals to switch power to the rest of the board:
+FPGA_ON, and NVDD_ON. When NVDD_ON goes low, the Vdd rail comes up to
+about five volts (the filtered-but-unregulated USB voltage). This powers
+most of the analog circuitry, including the ADC and all of the opamps
+and comparators in the receive path, and the coil drivers as well. Vdd
+also feeds the +3V3-FPGA and +2v5 regulators, which power only the
+FPGA. These regulators are enabled by FPGA_ON, so the FPGA is powered
+only when NVDD_ON is asserted low, and FPGA_ON is asserted high.
+
+DETAILS: FPGA
+=============
+
+The FPGA is a Spartan-II. This is a little bit old, but it is widely
+available, inexpensive, and five-volt tolerant. For development, the FPGA
+is configured over JTAG (SV5). In operation, the FPGA is configured in
+slave serial mode by the ARM, from a bitstream stored in the ARM's flash.
+
+Power to the FPGA is managed by regulators IC13 and IC12, both of which
+have shutdown. These generate the FPGA's VCCO (+3v3) and VCCINT (+2v5)
+supplies. I am a little bit worried about the power-on surge, since we
+run off USB. At the very minimum, the FPGA should not get power until
+we have enumerated and requested the full 500 mA available from USB. The
+large electrolytic capacitors C37 and C38 will presumably help with this.
+
+The logic is written in Verilog, of course for webpack. I have structured
+the FPGA in terms of `major modes:' the FPGA's `major mode' determines
+which of several modules is connected to the FPGA's I/O pins. A separate
+module is used for each of the FPGA's function; for example, there is
+now a module to read a 125 kHz tag, simulate a 125 kHz tag, transmit to
+an ISO 15693 tag, and receive from an ISO 15693 tag.
+
+DETAILS: ANALOG RECEIVE PATH
+============================
+
+For `slow' signals, I use an MCP6294 opamp. This has a GBW of 10 MHz,
+which is more than enough for the low-frequency stuff, and enough for
+all of the subcarrier frequencies that I know of at high frequency. In
+practice, the `slow' signals are all the signals following the peak
+detector. These signals are usually centred around the generated
+voltage Vmid.
+
+For `fast' signals, I use an AD8052. This is a very fast voltage-feedback
+amplifier (~100 MHz GBW). I use it immediately after the antenna for
+both the low- and high-frequency cases, as a sort of an ugly LNA. It is
+not optimal, but it certainly made the design easy.
+
+An ordinary CD4066 is used to multiplex the four possible signals
+(low/high frequency paths, RAW/PEAK-DETECTED). There is a potential
+problem at startup, when the ARM is in reset; there are pull-ups on the
+lines that control the mux, so all of the switches turn on. This shorts
+the four opamp outputs together through the on-resistance of the switch.
+All four outputs float to the same DC voltage with no signal, however,
+and the on-resistance of the switches is fairly large, so I don't think
+that will be a problem in practice.
+
+Comparators are used to generate clock signals when the device is
+emulating a tag. These clock signals are generated from the signal on the
+antenna, and therefore from the signal transmitted by the reader. This
+allows us to clock ourselves off the reader, just like a real tag would.
+These signals go in to the FPGA. There is a potential problem when the
+FPGA is powered down; these outputs might go high and try to power the
+FPGA through the protection diodes. My present solution to this is a
+couple of resistors, which is not very elegeant.
+
+The high-frequency peak-detected receive path contains population options
+for many features that I do not currently use. A lot of these are just
+me guessing that if I provide options for different series and shunt
+passives, perhaps it will come in handy in some way. The Zener diodes D10
+and D11 are optional, but may protect the front end from an overvoltage
+(which will fry the peak detector diodes) when the `simulated tag'
+is read by a powerful reader.
+
+DETAILS: ANALOG TRANSMIT PATH
+=============================
+
+The coil drivers are just ACT244 bus buffers. I parallel eight of them
+for each antenna (eight for the high-frequency antenna, eight for the
+low-frequency antenna). This should easily provide a hundred milliamps
+coil drive or so, which is more than enough for anything that I imagine
+doing with the device. The drivers hit the coil with a square wave
+voltage, however, which means that it is only the bandpass filter effect
+of a resonant antenna that suppresses the odd harmonics. In practice it
+would probably take heroic efforts (high antenna Q) to meet the FCC/CE
+harmonic specs; and in practice no one cares.
+
+The tx strength, given good antenna tuning, is determined by the series
+resistors. Choose the ratios to stay within the rated current of the
+buffers, and to achieve the desired power ratios by enabling or disabling
+nOEs for the desired modulation index. It is useful to populate one of the
+resistors as a high value (~10k) for the simulated tag modes; this allows
+us to look at the incident carrier without loading the reader very much.
+
+DETAILS: ARM
+============
+
+Atmel makes a number of pin-compatible ARMs, with slightly different
+peripherals, and different amounts of flash and RAM. It is necessary
+to choose a device with enough flash not just for the ARM's program,
+but also for the FPGA image (which is loaded by the ARM).
+
+The ARM is responsible for programming the FPGA. It also supplies a
+clock to the FPGA (although the FPGA clock can also run off the 13.56
+MHz clock not used for anything else, which is obviously asynchronous
+to anything in the ARM).
+
+It is necessary to use JTAG to bring the ARM for the first time; at
+that point you can load a bootrom, and subsequently load new software
+over USB. It might be possible to use the ARM's pre-loaded bootloader
+(see datasheet) instead of JTAG, but I wanted the JTAG anyways for
+debugging, so I did not bother. I used a Wiggler clone, with Macraigor's
+OCD Commander. More expensive tools would work as well.
+
+USB SOFTWARE
+============
+
+At present I enumerate as an HID device. This saves me writing a driver,
+but it forces me to do interrupt transfers for everything. This limits
+speed and is not very elegant. A real USB driver would be nice, maybe
+even one that could do stuff like going isochronous to stream samples
+from the A/D for processing on the PC.
+
+PRETENDING TO BE A TAG
+======================
+
+It is not possible, with the given topology, to open-circuit the antenna
+entirely and still look at the signal received on it. The simulated tag
+modes must therefore switch between slight loading and heavy loading,
+not open- and short-circuts across the antenna, evening though they do
+not depend upon the incident carrier for power (just timing information).
+
+RECEIVING SIGNAL STRAIGHT FROM THE ANTENNAS
+===========================================
+
+There is a path straight from the antenna to the A/D, bypassing the peak
+detector assembly. This goes through a gain stage (just a fast voltage
+feedback opamp), and from there straight in to the mux.
+
+It is necessary to energize the relay to connect these paths. If the
+coil is driven (as if to excite and read a tag) while these paths are
+connected, then damage will probably result. Most likely the opamp
+will fry.
+
+READING A TAG
+=============
+
+The tag is excited by a carrier transmitted by the reader. This is
+generated by IC9 and IC10, using some combination of buffers. The transmit
+power is determined by selecting the right combination of PWR_OEx pins;
+drive more of them low for more power. This can be used to modulate the
+transmitted signal, and thus send information to the tag.
+
+The received signal from the antenna is first peak-detected, and then
+high-pass filtered to reject the unmodulated carrier. The signal is
+amplified a bit, and goes in to the A/D mux from there. The A/D is
+controlled by the FPGA. For 13.56 MHz tags, it is easiest to do everything
+synchronous to the 13.56 MHz carrier.
+
+INTERFACE FROM THE ARM TO THE FPGA
+==================================
+
+The FPGA and the ARM can communicate in two main ways: using the ARM's
+general-purpose synchronous serial port (the SSP), or using the ARM's
+SPI port. The SPI port is used to configure the FPGA. The ARM writes a
+configuration word to the FPGA, which determines what operation will
+be performed (e.g. read 13.56 MHz vs. read 125 kHz vs. read 134 kHz
+vs...). The SPI is used exclusively for configuration.
+
+The SSP is used for actual data sent over the air. The ARM's SSP can
+work in slave mode, which means that we can send the data using clocks
+generated by the FPGA (either from the PCK0 clock, which the ARM itself
+supplies, or from the 13.56 MHz clock, which is certainly not going to
+be synchronous to anything in the ARM), which saves synchronizing logic
+in the FPGA. The SSP is bi-directional and full-duplex.
+