updated README, LICENSE, notes

4 files changed, 164 insertions, 8 deletions

diff --git a/LICENSE b/LICENSE
index e65b34d..f52fe0e 100644
--- a/LICENSE
+++ b/LICENSE
@@ -10,7 +10,7 @@ CONTENT OF SUCH FIRMWARE AND/OR THE USE MADE BY CUSTOMERS OF THE CODING
 INFORMATION CONTAINED HEREIN IN CONNECTION WITH THEIR PRODUCTS.
 
 -------------------------------------------------------------------------------
-Unless otherwise noted in the header, all code in /libmaple/ are copyright
+Unless otherwise noted in the header, all code in /libmaple/ is copyright
 LeafLabs LLC and are released under the MIT License:
 
 Copyright (c) 2009-2010 LeafLabs LLC
@@ -36,3 +36,24 @@ THE SOFTWARE.
 See http://creativecommons.org/licenses/MIT/ for more information.
 
 -------------------------------------------------------------------------------
+Some of files in /stm32conf/ were written by 'lanchon' and posted in the
+STMicroelectronics forum at:
+
+https://my.st.com/public/STe2ecommunities/mcu/Lists/ARM%20CortexM3%20STM32/flat.aspx?RootFolder=/public/STe2ecommunities/mcu/Lists/ARM%20CortexM3%20STM32/STM32%20CC%2B%2B%20build%20environment%20using%20CodeSourcery%20Sourcery%20G%2B%2B&currentviews=18152
+
+These files are stated to be in the public domain. Other files in /stm32conf/
+are from CodeSourcery, Inc with the following notice:
+
+Copyright (c) 2006, 2007 CodeSourcery Inc
+
+The authors hereby grant permission to use, copy, modify, distribute,
+and license this software and its documentation for any purpose, provided
+that existing copyright notices are retained in all copies and that this
+notice is included verbatim in any distributions. No written agreement,
+license, or royalty fee is required for any of the authorized uses.
+Modifications to this software may be copyrighted by their authors
+and need not follow the licensing terms described here, provided that
+the new terms are clearly indicated on the first page of each file where
+they apply.
+
+-------------------------------------------------------------------------------
diff --git a/README b/README
index 9ea9a23..f3bb334 100644
--- a/README
+++ b/README
@@ -35,12 +35,13 @@ libmaple Repo Layout
     Extra wrappers and functionality around the lower level code which is 
     useful for programming in the IDE.
 
-/exapmles/
+/examples/
+    What it sounds like. Copy these to /main.cpp to compile them.
     
-
-/stm32lib/
-    The "standard" library given away by STM; to be removed ASAP.
-
+/notes/
+    Unstructured text notes that may be useful. The 45-maple.rules udev file
+    can be placed in /etc/udev/rules.d/ on compatible linux machines to allow
+    non-root access to the Maple USB device for uploading.
 
 Instructions to Compile for ARM Targets
 ------------------------------------------------------------------------------
@@ -62,6 +63,6 @@ You will also need to have dfu-util installed (on Linux) or compiled and placed
 in a folder "dfu-util/" at the same level as the maple-library folder (macosx
 and windows).
 
-Write your program using src/main.cpp as the entry point. Then just 'make' and follow the directions!
-
+Write your program using /main.cpp as the entry point. Then just 'make' and
+follow the directions!
 
diff --git a/notes/i2c b/notes/i2c
new file mode 100644
index 0000000..c324bb2
--- /dev/null
+++ b/notes/i2c
@@ -0,0 +1,134 @@
+
+Maple -------------------------------------------------------------------------
+
+We'll probably want both HardwareI2C and SoftI2C implementations, with the
+soft being bitbanged on arbitrary pins (and possibly only master-mode; almost
+certainly not multi-master).
+
+The first simple implementation will support up to 400khz operation, only 
+7-bit addresses, no clock stretching (on our part), only blocking master
+read/write (with timeout), and only master n-write,n-read combined messages.
+
+A more advanced implementation would be event-driven, support DMA, higher
+clock speeds, handle error interrupts, etc. 
+
+Should all of these return a status code? or just fail? or fail silently?
+
+Ring buffers etc are not needed because the length of the read/write is always
+known (or handled by the application code for slave mode).
+
+// port = {1,2}
+i2c_init(port, freq)
+i2c_disable(port)
+
+// blocking/polling
+i2c_master_read(port, slave_addr, *data, len)  // wrapper around writeread
+i2c_master_write(port, slave_addr, *data, len) // wrapper around writeread
+i2c_master_writeread(port, slave_addr, *wdata, wlen, *rdata, rlen)
+
+// callbacks/interrupts
+i2c_slave_set_addr(port, addr) // enables callbacks etc if they aren't already;
+                               // set ACK high
+i2c_slave_set_rx_callback(port, *function) // takes a byte?
+i2c_slave_set_tx_callback(port, *function) // gives a byte?
+
+How to init:
+ - setup pins
+ - setup peripheral input clock: 4MHz for fast mode
+ - configure clock control registers
+ - configure rise time register
+ - configure interrupts
+ - configure I2C_CR1 to enable the peripheral
+ - set ACK flag low: won't be a slave until addr is set
+
+How to master_write:
+ - START, addr[0:7], W, ACK, DATA[0:7], ACK, DATA[8:15], ..., STOP
+ - software sets START high, which toggles M/SL to master mode
+ - when START actually happens, SB is set and interrupt happens; hardware
+   waits until address is written to DR
+ - address shifts out and an interrupt is thrown with ADDR high; if LSB of
+   address was low, in transmitter mode. TRA reflects this
+ - software writes to the first byte to DR and clears ADDR
+ - first byte shifts out and when there's an ACK an interrupt is thrown
+   with TxE high; if no new byte was written to DR since the previous
+   transmission BTF goes high
+ - software writes next byte to DR and clears BTF, or sets STOP bit to end
+   data transmission, or sets START to begin next part of combined session
+ - after STOP is set, hardware goes back to slave mode
+
+How to master_read:
+ - START, addr[0:7], R, ACK, DATA[0:7], ACK, ..., NACK, DATA[-8:-1], STOP
+ - software sets START high, which toggles M/SL to master mode
+ - when START actually happens, SB is set and interrupt happens; hardware
+   waits until address is written to DR
+ - address shifts out and an interrupt is thrown with ADDR high; if LSB of
+   address was high, in receiver mode. TRA reflects this.
+ - software clears ADDR; hardware shifts in first byte from slave and sends ACK
+   if ACK is set. interrupt is thrown with RxNE high, with BTF set
+ - if only reading one byte, ACK should be set low and STOP high; hardware will
+   then NACK and STOP after reading
+ - software reads from DR and clears BTF bit. next byte is shifted in
+ - software sets NACK low after second-to-last byte is read by setting ACK low
+   after reading from DR, and either setting STOP or START high
+ - after STOP is set, hardware goes back to slave mode
+
+How to master_writeread:
+ - [START, addr[0:7], W, ACK, WDATA[0:7], ...], 
+   [START, addr[0:7], R, ACK, RDATA[0:7], ACK, ..., NACK, RDATA[-8:-1]]
+   STOP
+ - implement the above read/write but set START high instead of STOP high at
+   the end
+
+How to slave tx (master read):
+ - if address is matched, ACK is send (if ACK flag is high) and ADDR goes high;
+   event interrupt is triggered if ITEVFEN flag is set. TRA indicates whether
+   this is a read or write request
+ - program sets DR degister and clears ADDR flag; hardware will clock stretch
+   until ADDR is low
+ - if ITVENFEN and ITBUFEN are set, the TxE interrupt is triggered after the
+   byte is sent and the master ACKs. now the hardware stretches until BTF is
+   cleared before sending again.
+ - after the STOP is sent, hardware sets STOPF, throws an event if ITEVFEN is
+   high, and waits for a read of SR1 and write CR1
+
+How to slave rx (master write):
+ - if address is matched, ACK is send (if ACK flag is high) and ADDR goes high;
+   event interrupt is triggered if ITEVFEN flag is set. TRA indicates whether
+   this is a read or write request
+ - the hardware shifts in the byte to DR and sends an ACK if ACK flag is high
+ - if ITEVFEN and ITBUFEN are set, an RxNE interrupt is sent. hardware waits
+   until the BTF flag is reset
+ - after the STOP is sent, hardware sets STOPF, throws an event if ITEVFEN is
+   high, and waits for a read of SR1 and write CR1
+
+i2c General Reference ---------------------------------------------------------
+
+http://en.wikipedia.org/wiki/I²C
+
+4 modes/roles for a given device. These designations are transaction specific;
+a device can switch roles from one transaction to the next:
+    master transmit
+    master receive
+    slave transmit
+    slave receive
+
+
+STM32 Specific Reference ------------------------------------------------------
+
+see stm32 docs: reference manual (doc 13902 rev10) pg637/1003
+
+see STM32F10x_StdPeriph_Lib_V3.2.0/Project/STM32F10x_StdPeriph_Examples/I2C/Interrupt for an example project (reading/writing between the two i2c buses) based on the stm32library
+
+>100khz is "fast mode", which goes up to 400khz. stm32 supports up to 400khz.
+    things are different in fast mode: 4mhz input clock
+
+interrupts see pg652/1003
+registers see pg654/1003
+
+PEC = packet error checking. don't think this is i2c standard
+
+each i2c port has an error and an event interrupt 
+
+the stm32 is in slave mode by default; it enters master only when executing
+a request
+
diff --git a/pin-mapping.txt b/notes/pin-mapping.txt
index c1709e8..c1709e8 100644
--- a/pin-mapping.txt
+++ b/notes/pin-mapping.txt