Minimal Z1 commit, MSP430 support x1 and x2 processors.

Collapse duplicate Z1 MSP430 files.

Add support for new TI_HEADERS.   Simple tests done with old 3.2.3
Z1 toolchain and new mspgcc4 (4.4.5) with TI_HEADERS.

.gitignore

@@ -0,0 +1,5 @@
+*.[oa]
+*~
+build
+#*#
+.#*

00_Repo_Notes

@@ -1,4 +1,13 @@
 
+* Toolchain:
+
+The focus is on getting the new toolchain verified.  As such this repo is
+intended to be tested using new toolchain (mspgcc 4.4.5, uniarch, ti headers).
+
+Some testing with the old 3.2.3 toolchain (original tinyos and z1 varient) has
+also been done for simple function (ie. does it compile).
+
+
 * Repo Structure
 
 The msp430.git repo is located at: 
@@ -35,7 +44,7 @@ svn t2 mainline ---|
 
 master: is the main branch coming from the svn t2 mainline.  Updated manually.
 
-master_vhsb: (vogon hyper-spatial bypass)  Bypass the Z1 commits on the main
+master-vhsb: (vogon hyper-spatial bypass)  Bypass the Z1 commits on the main
 	trunk.  This branch tracks master but has the superfluous Z1 commit
 	removed as it conflicts with the collapsed msp430 x2xxx work done in
 	mm_core.  This collapsage forms the majority of the work of merging
@@ -53,6 +62,10 @@ mm-z1-pu: proposed updates.   After new code has been worked on for a bit and
 	enough stuff is ready to go in next, it is brought over to main
 	(mm-z1).
 
+x5:	integrate x5xxx family into result of mm-z1.  Includes all three major
+x5-next families, x1, x2, and x5.  Uses seperate dirs for major differences.
+x5-pu
+
 
 To pull a working branch based on the mm-z1-pu branch (a reasonable place to
 fork a working branch), do the following:

01_Merge_Notes

@@ -1,13 +1,34 @@
 
-1) removed extra Z1 commit into the trunk.   Gets in the way of the collapse work already done.
+The phrase "trunk-Z1" refers to the Z1 commit into the main t2 svn trunk.  T2 SVN trunk commits
+5442-5446 (corresponding git SHAs: 95e34ad, 7c460e2, 33fcc13, 4496245, and e50ad32.
 
-2) branched to master-vhsb (master with vogon hyper spatial bypass), ie trunk (master without
-   the extra Z1 code.
+By direct comparison, the trunk Z1 commit is 98% z1-sf 0.16.  A few missing things, nothing important
+but the msp430 branch brought those things back in.   See the following commit for the missing parts:
+
+    270f0cc Z1 changes outside main z1 modifications (outside tos/{chips,platforms}
+
+
+1) created the branch master-vhsb (master with vogon hyper spatial bypass).  The hyper-spatial bypass
+   jumps over the trunk-Z1 code (deletes it).
+
+2) removed trunk-Z1 commit.   Gets in the way of the collapse work already done.  See the following:
+
+    c2e52bd Remove extra Z1 commit.   Reverse 5442 (95e34ad)
+    2724902 Remove extra Z1 commit.   Reverse 5444 (33fcc13) and 5443 (7c460e2)
+    978a1d9 Remove extra Z1 commit.   Reverse 5446 (e50ad32) and 5445 (4496245)
 
 3) brought in code from sourceforge z1-0.16 that changed things but didn't hit the main areas for
-   the Z1.  ie.  stuff outside of tos/chips/msp430.
+   the Z1.  ie.  stuff outside of tos/chips/msp430.   See:
+
+    270f0cc Z1 changes outside main z1 modifications (outside tos/{chips,platforms}
 
-4) brought in z1 code that effects tos/chips/msp430.   But avoided the duplicates.  (z1-0.16 code
+4) brought in Z1 code that is required (non-duplicate):
+
+    1e1249a bring adxl345 and tmp102 into tos/chips
+    4e89d73 move z1-0.16 tos/platforms/z1 into msp430 (mm-z1)
+
+
+5) brought in z1 code that effects tos/chips/msp430.   But avoided the duplicates.  (z1-0.16 code
    checked against the trunk Z1 code (removed above) to see if anything missing).
 
 
@@ -18,3 +39,9 @@
   and collapsing.
 
 * might want to add Zolertia copyrights to adxl345 and tmp102.
+
+* Z1 msp430hardware.h commented out the defines for I2CBUSY but the main msp430/msp430hardware.h
+  doesn't.   Where should the I2C stuff be defined?
+
+  For the time being, if this causes problems for Z1 then need to have per cpu family msp430hardware.h
+  files.  Or do it with an #ifdef (PLATFORM_Z1)

02_To_Do

@@ -1,4 +1,15 @@
 
+* fix copyrights
+
 * apps/IPBaseStation: defines a reset in a particularily ugly way.   Needs to be
-  fixed and mad part of the platform/cpu definition.
+  fixed and made part of the platform/cpu definition.
+
+* What is the purpose of msp430regtypes.h?  Is there a easier way to deal with this?
+
+* There are multiple copies of msp430hardware.h.   Is that reasonable?
+
+* i2c for msp430 isn't done yet.  needs to be cleaned up and made less ugly.  Interface
+  needs to be finished.
 
+* CC2420 modules use LocalIeeeEui64C to obtain an ipv6 link-local address.  Z1 needs to
+  provide.

03_Removed

@@ -7,3 +7,7 @@ are outdated and duplicates.
 
   The trunk version of IPDispatch.h is used in the msp430 (mm-z1) branch.
 
+* z1/tos/chips/msp430/adc12 removed.   No Z1 dependancies.  Moved forward on trunk.
+  removed DXNRG from interrupt handler (per Xavier).
+
+* z1/tos/chips/msp430/dma

support/make/z1.target

@@ -8,7 +8,23 @@ MSP_MCU ?= msp430x261
 MSP_GCC ?= msp430-gcc
 MSP_NESC_TARGET ?= msp430
 PFLAGS += -mdisable-hwmul 
-PFLAGS += -mdata-64k
+
+#
+# Old Z1, mspgccX (3.2.3) tool chain accepts -mdata-64k and -mcode-64k
+# but new mspgcc4 (4.4.5) doesn't understand these yet and causes the
+# tinyos toolchain (nesc) to produce a really strange error:
+#   "nesc1: internal error: couldn't define builtin macros - exiting"
+#
+# One immediate thought is to simply leave this out for the old toolchain
+# but it is unclear what kind of code it will generate.   It should be
+# fine but how big are pointers?   The 261x parts (Z1 and friends) all
+# have miniscule amounts of ram (all < 64K).   But how smart is the
+# compiler?   Does it know to that it can always use 16 bit data pointers?
+# Can it tell the difference between a data pointer and a code pointer?
+#
+# Be careful out there.
+#
+#PFLAGS += -mdata-64k
 
 VOLUME_FILE = volumes-stm25p.xml
 VOLUME_ALLOCATOR ?= tos-storage-stm25p

tos/chips/msp430/00_README

@@ -0,0 +1,87 @@
+
+This directory contains interface files for the TI msp430 family of CPUs.
+The TI architecture is rather scattered and the cpu interface to major
+pieces reflects this.  The main problem areas include: peripheral registers,
+interrupts, and interrupt vectors.
+
+Care should be taken to minimize duplicates while maintaining the minimum implementation
+that reflects the cpus currently supported by TinyOS.    This should be done in a way
+that minimizes impact on existing implementations (be backward compatible).  See the
+file 01_Dependencies for what CPUs are supported and the cpu dependencies.
+
+Where reasonable, conflicting areas are kept in a flat file and differences are
+#ifdef'd.   When this becomes too cumbersome, different interface definitions and
+implementations are placed into cpu family directories and the interface to
+the reset of the tinyos os is shadowed.   The correct directory needs to be
+specified in the .platform file.
+
+Most of the cpu definitions are obtained automatically via the toolchain, ie. the -mmcu
+specification automatically included the appropriate cpu header file.  ie. -mmcu=msp430x2618
+causes the msp430f2618.h include file to be invoked.
+
+The TI MSP430 family has many variants.  There is a main cpu core and various integrated peripherals on
+chip.  What a given chip includes is spelled out by the included chip definition file automatically
+included via the -mmcu mechanism.
+
+The tinyos interface is spit into several sections:
+
+msp430hardware.h and msp430regtypes.h define various other attributes that interface the cpu
+to the tinyos environment.   These files coupled with the chip definition file define the cpu
+and other capabilities available.
+
+The original architecture, the MSP430, provides 16 bit addresses.   A subsequent revision denoted
+MSP430X modifies the cpu and addressing to provide 20 bit addresses.  Backward compatibilty to the
+MSP430 was considered.   A further modification is denoted the MSP430XV2 but it is unclear exactly
+what this modified.
+
+Several directories are available that provide the drivers for the specified peripheral.  Presence
+of the peripheral can be detected by checking appropriate values in the chip definition file.  These 
+directories are:
+
+adc12:	Most MSP430 chips include a 12 bit analog to digital converter.
+
+dma:	3 or 8 independent dma channels are provided. MSP430X cpus can address 20 bits via the DMA
+	engines.   20 bits increases the overhead significantly and should only be used if really
+	needed.  ie.  Most cpus only provide RAM in the lower 64K so there really isn't much need
+	for 20 bit addresses, unless one is DMAing out of high memory (ROM).
+
+	Currently, only a 16 bit dma interface is provided.  In the future a dma32 interface could
+	be defined to provide access to the full 20 bits of addressing.
+
+pins:	interface to digital I/O.
+
+sensors: interfaces to on chip internal temperature and voltage sensors.
+
+timer:	interface to on chip timing mechanisms.  Timers and Alarms.
+
+usart:	interface to original UART/SPI/I2C on MSP430 parts.  (1st generation).
+
+usci:	interface to USCI modules UART/SPI/I2C on MSP430X and later parts.
+
+
+
+CPU Families:
+
+When it is too cumbersome to maintain a flat file that includes #ifdef'd difference for each of 
+the different variants, it is useful to seperate common interfaces into cpu family dependent family
+files that provide various TinyOS interfaces.
+
+The following families and what cpus are supported are listed below.  When a new cpu is added to TinyOS
+support, it can first be isolated and supported independently.   When commonalities are understood, any
+duplication can be removed and subsumed into a flat file via #ifdef's as appropriate.   Any remaining
+interfaces that are too cumbersome, can be supported by an existing cpu family interface or a new family
+can be defined as appropriate.  The intent is to provide a mechanism that allows gradual refactorization as
+new cpus are brought into the fold.
+
+The following families currently exist.   Included are what cpus have been verified.  Only add cpus that
+have actually been instantiated.
+
+x1xxx: msp430f1611, msp430f149
+       telos{a,b}, epic, eyesIFXv1, eyesIFXv2, shimmer{,2,2r}, span, tinynode
+
+x2xxx: msp430f2617, msp430f2618, msp430f2619
+       Z1, MM4 (mam-mark mote)
+
+x5xxx: cc430f5137, msp430f5438{,a}
+       surf, ev430, mm5 (mam-mark mote)
+

tos/chips/msp430/01_Dependencies

@@ -0,0 +1,132 @@
+
+CPU families:
+
+We currently define 3 cpu families that group similar TI msp430 chips together.   Two chips
+can be grouped together if for that module or interface the behaviour is the same.
+
+The main family is simply "msp430" and whenever possible we endevour to put everything we can into the
+generic msp430 directory.  This is the top level.   However when it becomes too cumbersome to make
+this fit for a given functionality, it may be necessary to split a new cpu out into one of the family
+directories.  These are subdirectories off msp430, ie.  msp430/x1xxx and are selected by the .platform
+file for a platform.
+
+Currently what differentiates the different family directories is interrupt behaviour, peripheral
+register mapping, low power behaviour.
+
+
+CPUs supported:
+
+    x1xxx: msp430f149, msp430f1611
+    x2xxx: msp430f261{6,7,8,9}
+    x5xxx: cc430f513{7,8,8a}
+
+
+Interrupt Vectors:
+
+x1xxx vectors:  (149, 1611)					x2xxx vectors: (msp430f261{6,7,8,9})
+
+								14      DAC12_VECTOR                            
+								15      DMA_VECTOR                              
+0xFFE0	0	DACDMA_VECTOR		(1611 only)     	16      USCIAB1TX_VECTOR                        
+0xFFE2	1	PORT2_VECTOR			       		17      USCIAB1RX_VECTOR                        
+0xFFE4	2	USART1TX_VECTOR			        	18      PORT1_VECTOR                            
+0xFFE6	3	USART1RX_VECTOR			        	19      PORT2_VECTOR                            
+0xFFE8	4	PORT1_VECTOR			       		20      RESERVED20_VECTOR                       
+0xFFEA	5	TIMERA1_VECTOR		Timer A CC1-2   	21      ADC12_VECTOR                            
+0xFFEC	6	TIMERA0_VECTOR		Timer A CC0     	22      USCIAB0TX_VECTOR                        
+0xFFEE	7	ADC12_VECTOR			        	23      USCIAB0RX_VECTOR                        
+0xFFF0	8	USART0TX_VECTOR			        	24      TIMERA1_VECTOR          Timer A CC1-2   
+0xFFF2	9	USART0RX_VECTOR			        	25      TIMERA0_VECTOR          Timer A CC0     
+0xFFF4	1	WDT_VECTOR			       		26      WDT_VECTOR                              
+0xFFF6	1	COMPARATORA_VECTOR		        	27      COMPARATORA_VECTOR                      
+0xFFF8	1	TIMERB1_VECTOR		Timer B CC1-6   	28      TIMERB1_VECTOR          Timer B CC1-6   
+0xFFFA	1	TIMERB0_VECTOR		Timer B CC0     	29      TIMERB0_VECTOR          Timer B CC0     
+0xFFFC	1	NMI_VECTOR			        	30      NMI_VECTOR                              
+0xFFFE	15	RESET_VECTOR			       		31      RESET_VECTOR                            
+
+
+x5xxx vectors: (msp430f543{5,6,7,8}{,a}, cc430f5137)
+
+543{5,6,7,8}{,a}						cc430f5137
+0xFFD2	41	RTC_VECTOR
+0xFFD4	42	PORT2_VECTOR
+0xFFD6	43	USCI_B3_VECTOR
+0xFFD8	44	USCI_A3_VECTOR
+0xFFDA	45	USCI_B1_VECTOR					45      AES_VECTOR                              
+0xFFDC	46	USCI_A1_VECTOR					46      RTC_VECTOR                              
+0xFFDE	47	PORT1_VECTOR					                                                
+0xFFE0	48	TIMER1_A1_VECTOR	Timer1_A3, CC1-2	48      PORT2_VECTOR                            
+0xFFE2	49	TIMER1_A0_VECTOR	Timer1_A3, CC0		49      PORT1_VECTOR                            
+0xFFE4	50	DMA_VECTOR					50      TIMER1_A1_VECTOR        Timer1_A3 CC1-2 
+0xFFE6	51	USCI_B2_VECTOR					51      TIMER1_A0_VECTOR        Timer1_A3 CC0   
+0xFFE8	52	USCI_A2_VECTOR					52      DMA_VECTOR                              
+0xFFEA	53	TIMER0_A1_VECTOR	Timer0_A5 CC1-4		53      CC1101_VECTOR                           
+0xFFEC	54	TIMER0_A0_VECTOR	Timer0_A5 CC0		54      TIMER0_A1_VECTOR        Timer0_A5 CC1-4 
+0xFFEE	55	ADC12_VECTOR					55      TIMER0_A0_VECTOR        Timer0_A5 CC0   
+0xFFF0	56	USCI_B0_VECTOR					56      ADC12_VECTOR                            
+0xFFF2	57	USCI_A0_VECTOR					57      USCI_B0_VECTOR                          
+0xFFF4	58	WDT_VECTOR					58      USCI_A0_VECTOR                          
+0xFFF6	59	TIMER0_B1_VECTOR	Timer0_B7 CC1-6		59      WDT_VECTOR                              
+0xFFF8	60	TIMER0_B0_VECTOR	Timer0_B7 CC0		60      COMP_B_VECTOR                           
+0xFFFA	61	UNMI_VECTOR					61      UNMI_VECTOR                             
+0xFFFC	62	SYSNMI_VECTOR					62      SYSNMI_VECTOR                           
+0xFFFE	63	RESET_VECTOR					63      RESET_VECTOR                            
+
+
+1) Vectors move to various addresses dependent on what cpu you are using.  (This is taken care of by
+   proper usage of the cpu header files.
+
+2) Depending on family, vectors are shared across function.  This complicates things and is ugly.
+
+   ie.  x1xxx vector 0 is DACDMA (shared with DAC and DMA) but on the x2xxx and x5xxx families DMA
+   has its own vector and no DAC vector (no DAC).
+
+   Worse yet is the sharing of vectors for the USCI on the x2xxx parts.   A vector is provided for
+   USCIAB0TX_VECTOR which is shared across both the A side and B side of the USCI which typically
+   can be operated in very different modes.  This has been cleaned up in the x5xxx series parts.
+
+
+Addressing:
+
+The x1xxx family supports 16 bit addressing, x2xxx and x5xxx support 20 bit addresses.
+
+x2xxx family parts define __MSP430_HAS_MSP430X_CPU__
+x5xxx family parts define __MSP430_HAS_MSP430XV2_CPU__
+
+Either __MSP430_HAS_MSP430X_CPU__ or __MSP430_HAS_MSP430XV2_CPU__ indicates the potential
+for 20 bit addresses.  Whether 20 bit addresses are being used depends on what switches
+are passed to the toolchain.
+
+
+ADC12:
+
+The adc12 module is supported on x1xxx, x2xxx, and x5xxx parts.   ADC12_VECTOR is defined and
+the module behaves the same for all supported families.  No special support needs to be
+provided.
+
+
+DMA:
+
+1) Addressing.   The x1xxx family only supports 16 bit addresses.  The x2xxx and x5xxx support
+   20 bit addresses.
+
+   x1xxx family parts define __MSP430_HAS_DMA_3__ (16 bit addresses, 3 channels).
+   x2xxx, x5xxx family parts define __MSP430_HAS_DMAX_3__ (20 bit addresses, 3 channels).
+
+   DMAX modules provide 2 16-bit address objects for each DMA address needed.  (20 bit defined)
+   The lower 16 bit object is equivilent to a DMA address on a non-DMAX module.  When this lower
+   object is written the upper is automatically zeroed.  This provides backward compatibility
+   for drivers written for non-DMAX modules.  These drivers will work fine with DMAX modules
+   when accessing the lower 64K of memory.
+
+2) DMA Transfer select.  Transfer select fields determine what a DMA engine (channel) should
+   use to initiate a transfer cycle.  These fields maybe 4 or 5 bits wide and the driver needs
+   to know how to construct an appropriate control word when interacting with the h/w.
+
+
+3) Interrupt vector:
+
+   On the x1xxx family, the vector is named DACDMA_VECTOR and other families use DMA_VECTOR.
+
+   The driver uses either DACDMA_VECTOR or DMA_VECTOR if defined.  Otherwise complains about lack of
+   support.

tos/chips/msp430/dma/HplMsp430DmaC.nc

@@ -98,4 +98,3 @@ implementation {
   Dma2.Interrupt -> HplMsp430DmaP;
 
 }
-