[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