docs: ARM updates for Code_Overview.md

Some details on the code flow and organization have changed since
support for ARM processors was added.  Update Code_Overview.md
accordingly.

Signed-off-by: Kevin O'Connor <kevin@koconnor.net>

docs/Code_Overview.md

@@ -6,13 +6,22 @@ Directory Layout
 
 The **src/** directory contains the C source for the micro-controller
 code. The **src/avr/** directory contains specific code for Atmel
-ATmega micro-controllers. The **src/simulator/** contains code stubs
+ATmega micro-controllers. The **src/sam3x8e/** directory contains code
-that allow the micro-controller to be test compiled on other
+specific to the Arduino Due style ARM micro-controllers. The
-architectures.
+**src/simulator/** contains code stubs that allow the micro-controller
+to be test compiled on other architectures. The **src/generic/**
+directory contains helper code that may be useful across different
+host architectures. The build arranges for includes of
+"board/somefile.h" to first look in the current architecture directory
+(eg, src/avr/somefile.h) and then in the generic directory (eg,
+src/generic/somefile.h).
 
 The **klippy/** directory contains the C and Python source for the
 host part of the firmware.
 
+The **lib/** directory contains external 3rd-party library code that
+is necessary to build some targets.
+
 The **config/** directory contains example printer configuration
 files.
 
@@ -21,16 +30,18 @@ compiling the micro-controller code.
 
 During compilation, the build may create an **out/** directory. This
 contains temporary build time objects. The final micro-controller
-object that is built is in **out/klipper.elf.hex**
+object that is built is **out/klipper.elf.hex** on AVR and
+**out/klipper.bin** on ARM.
 
 Micro-controller code flow
 ==========================
 
-Execution of the micro-controller code starts in **src/avr/main.c**
+Execution of the micro-controller code starts in architecture specific
-which calls sched_main() located in **src/sched.c**. The sched_main()
+code (eg, **src/avr/main.c**) which ultimately calls sched_main()
-code starts by running all functions that have been tagged with the
+located in **src/sched.c**. The sched_main() code starts by running
-DECL_INIT() macro. It then goes on to repeatedly run all functions
+all functions that have been tagged with the DECL_INIT() macro. It
-tagged with the DECL_TASK() macro.
+then goes on to repeatedly run all functions tagged with the
+DECL_TASK() macro.
 
 One of the main task functions is command_task() located in
 **src/command.c**. This function processes incoming serial commands
@@ -46,12 +57,13 @@ times by scheduling timers.
 Timer functions are scheduled by calling sched_timer() (located in
 **src/sched.c**). The scheduler code will arrange for the given
 function to be called at the requested clock time. Timer interrupts
-are initially handled in an interrupt handler in **src/avr/timer.c**,
+are initially handled in an architecture specific interrupt handler
-but this just calls sched_timer_kick() located in **src/sched.c**. The
+(eg, **src/avr/timer.c**), but this just calls sched_timer_kick()
-timer interrupt leads to execution of schedule timer functions.  Timer
+located in **src/sched.c**. The timer interrupt leads to execution of
-functions always run with interrupts disabled. The timer functions
+schedule timer functions.  Timer functions always run with interrupts
-should always complete within a few micro-seconds. At completion of
+disabled. The timer functions should always complete within a few
-the timer event, the function may choose to reschedule itself.
+micro-seconds. At completion of the timer event, the function may
+choose to reschedule itself.
 
 In the event an error is detected the code can invoke shutdown() (a
 macro which calls sched_shutdown() located in **src/sched.c**).
@@ -62,12 +74,12 @@ interrupts disabled.
 Much of the functionality of the micro-controller involves working
 with General-Purpose Input/Output pins (GPIO). In order to abstract
 the low-level architecture specific code from the high-level task
-code, all GPIO events are implemented via wrappers. These wrappers are
+code, all GPIO events are implemented in architectures specific
-located in **src/avr/gpio.c**. The code is compiled with gcc's "-flto
+wrappers (eg, **src/avr/gpio.c**). The code is compiled with gcc's
--fwhole-program" optimization which does an excellent job of inlining
+"-flto -fwhole-program" optimization which does an excellent job of
-functions across compilation units, so most of these tiny gpio
+inlining functions across compilation units, so most of these tiny
-functions are inlined into their callers, and there is no run-time
+gpio functions are inlined into their callers, and there is no
-cost to using them.
+run-time cost to using them.
 
 Klippy code overview
 ====================
@@ -90,4 +102,5 @@ There are three threads in the Klippy host code. The main thread
 handles incoming gcode commands. A second thread (which resides
 entirely in the **klippy/serialqueue.c** C code) handles low-level IO
 with the serial port. The third thread is used to process response
-messages from the micro-controller in the Python code.
+messages from the micro-controller in the Python code (see
+**klippy/serialhdl.py**).