
Consider replacing the read-modify-write operations with either macro
function/or bit band direct access. Not all mem addresses are available
in bit band region. Currently, no performance critical code warrants this. 

macroize many magic board specific params into conf file:
	 LED Pin
	 USB Disc Pin
	 Default Usr Flash/Ram prog location

Fully support USB Suspend, as mandated by the spec but currently ignored. (if your computer goes into
standby and Maple is USB bus powered, it will likely just turn of, quite ungracefully). The proper thing
to do is to drop the clocks down to nil and wait until resume is detected to fire them up again. This 
effectively preserve the state of the application without much hassle. 

Rewrite the USB core to implement the bare minimum for the DFU control endpoint, virtual Com,
and enumeration. This means nixing our dependence on usb_lib. This is surprisingly doable, see
page 515 of the stm32f10x full manual (USB programming considerations). 

Adjust what DFU alternate configs are available:
     1) Usercode -> default RAM loc (must match linker script from build env)
     2) Usercode -> default FLASH loc (must match linker script from build env)
     3) Usercode -> .maple format, includes metadata about where to put what (ala IHex)

Build an interactive supervisor:
     1) Serial/virtual serial debug (r/w reg/ram/flash)
     2) offer hooks to usercode to modify conf regs or vector table

Grow interactive supervisor into an actual privileged kernel:
     1) mediates all direct cong register access
     2) provides stock means for handling exceptions
     3) provides stock interactive debug interface
     4) principly owns FLASH, USB, location of vector table, exception handlers, clocks, system pins (usb disc)
     5) everything else can probably be directly modded by usercode
     6) potentially manage power/standby modes

- in order to strongly protect against user code modifying system constants,
  like flash addresses near the bootloader, USB interrupt regs, special GPIO Pins,
  clock configurations regs, gpio config regs, ahb/apb clk conf regs, etc we would need
  to build the bootloader to claim supervisor privileges and then establish strict locks
  on certain memory addresses. This is needed, but beyond the scope of this first rev. For now,
  the comprimise solution is to ensure that exposed maple library functions (user library, not maple_lib.h here) 
  properly check accesses, perform appropriate read-write-modify operations, and throw exceptions
  to users who muck about with things they shouldnt be. However, users who dont use the library, and
  write code that explicitly accesses conf registers or flash memory couldnt do it by accident, so its ok 
  to hold them responsible for their own experimentation as long as we document the pitfalls. The principle way to 
  shoot yourself in the foot is to overwrite the bootloader in flash the lower flash addresses and not own 
  a jtag dongle. This would brick your maple. 

Provide stronger hooks between Makefile and preproc:
    1) strictly define stack ptr addr, user stack, usr code loc, vector table addr, stack size, etc.

Packaging with build chain:
 Strictly speaking, there are no 3rd party tools needed to write code and upload it to the chip
 except a dfu front end (dfu-utils in linux). However, until cortex support gets merged in to gcc (coming in 4.4)
 and for the sake of completeness we might consider including binaries or sources (somewhere? not here?) for:
     dfu-util userapp
     arm-none-eabi code sourcery compiler
     openocd
     ./flash directory for jtag scripts

for now, condense this whole stack to simply:
   1) clean up openocd .cfg files in ./flash directory and commit them.
   2) include a readme with locations for the other above programs