[Tinyos-2-commits] CVS: tinyos-2.x/tos/lib/net/6lowpan README, 1.1, 1.2

Matus Harvan mharvan at users.sourceforge.net
Fri Dec 7 07:38:52 PST 2007


Update of /cvsroot/tinyos/tinyos-2.x/tos/lib/net/6lowpan
In directory sc8-pr-cvs10.sourceforge.net:/tmp/cvs-serv602

Modified Files:
	README 
Log Message:
added information about workaround for 16-bit aligning to the 6lowpan README


Index: README
===================================================================
RCS file: /cvsroot/tinyos/tinyos-2.x/tos/lib/net/6lowpan/README,v
retrieving revision 1.1
retrieving revision 1.2
diff -C2 -d -r1.1 -r1.2
*** README	5 Dec 2007 22:58:42 -0000	1.1
--- README	7 Dec 2007 15:38:50 -0000	1.2
***************
*** 25,28 ****
--- 25,43 ----
     mote. A workaround is to add a usleep(10000) before sending subsequent
     fragments in the serial_tun daemon on the PC.
+  * The mspgcc compiler generates broken code using 16-bit values not
+    aligned at 16-bit boundaries. See
+    http://www.nabble.com/msp430-gcc-generating-unaligned-access.-t2261862.html
+    and page 25 in
+    http://www.eecs.harvard.edu/~konrad/projects/motetrack/
+    mspgcc-manual-20031127.pdf
+    for details. This seems to only happen with packed structs, where
+    some elements cannot be aligned. For example, a struct with an
+    8-bit, 16-bit, 8-bit and 16-bit value in the given order. As the
+    struct is packed, one of the 16-bit values can be aligned at a
+    16-bit boundary.
+    The current workaround is to force 8-bit operations for cases where
+    this can happen. This is done by the set_16t(), get_16t()
+    functions. In cases where unaligned accesses could happen, these
+    functions have to be used.
  
  More details can be found in



More information about the Tinyos-2-commits mailing list