aboutsummaryrefslogtreecommitdiffstats
path: root/source/bootloader.rst
diff options
context:
space:
mode:
authorMarti Bolivar <mbolivar@mit.edu>2010-11-28 11:23:33 -0500
committerMarti Bolivar <mbolivar@mit.edu>2010-11-28 11:23:33 -0500
commitd9cbd78e29d42e70bb46641dd43ee0772c8c975f (patch)
tree80a67cba4468dbcd89b3cd23ad56695b1f146c66 /source/bootloader.rst
parent546b34076d230b617ba86defb6b90cd934b01878 (diff)
downloadlibrambutan-d9cbd78e29d42e70bb46641dd43ee0772c8c975f.tar.gz
librambutan-d9cbd78e29d42e70bb46641dd43ee0772c8c975f.zip
reorganized all the arduino/ docs into a lang/ subdirectory since
they're properly CC attributed now.
Diffstat (limited to 'source/bootloader.rst')
-rw-r--r--source/bootloader.rst51
1 files changed, 35 insertions, 16 deletions
diff --git a/source/bootloader.rst b/source/bootloader.rst
index 46c2cf0..6cb9ece 100644
--- a/source/bootloader.rst
+++ b/source/bootloader.rst
@@ -226,12 +226,12 @@ A bootloader packet is composed of a sequence of fields, as follows.
- 1
- 0--0xFF
- Queries and responses must have the same sequence number; rolls
- over to 0 after 0xFF.
+ over to 0 after 0xFF
* - MESSAGE_SIZE
- 2
- 0--0xFFFF
- - Size of message body, currently limited to a 1024B maximum
+ - Size of message body, currently limited to a 1024B=1KB maximum
* - TOKEN
- 1
@@ -241,14 +241,32 @@ A bootloader packet is composed of a sequence of fields, as follows.
* - MESSAGE_BODY
- Variable, determined by MESSAGE_SIZE field
- Command query or response
- - See next section
+ - See :ref:`next section <bootloader-commands>`
* - CHECKSUM
- 4
- XOR of all other 32-bit words in packet
- - Words are checksummed little-endian; however, like all
- multi-byte fields, the CHECKSUM is transmitted between PC and
- device in network (big-endian) order.
+ - See :ref:`below <bootloader-checksum>`
+
+.. _bootloader-checksum:
+
+.. highlight:: cpp
+
+.. note:: When computing the checksum, the words in a packet are
+ interpreted big-endian (as if the packet were a sequence of 32-bit,
+ big-endian unsigned integers). If the end of the MESSAGE_BODY is
+ not aligned with a four-byte boundary, then the checksum will treat
+ it as if it was padded with zero bytes to a four-byte boundary.
+
+ As a concrete example, an entire GET_INFO query (see :ref:`below
+ <bootloader-get-info>`), including the packet structure, is
+ comprised of the byte sequence ::
+
+ {0x1B, 0x7F, 0x00, 0x01, 0x7F, 0x00, 0x64, 0x7F, 0x00, 0x01}
+
+ The SEQUENCE_NUM of this query is 0x7F.
+
+.. highlight:: sh
.. _bootloader-commands:
@@ -256,15 +274,16 @@ Commands
^^^^^^^^
The packet structure overhead is for reliability. The actual queries
-and responses are transacted inside of the message body. Following in
-the footsteps of the STK-500 protocol, each query or response begins
-with the single byte CMD field. For each query, the resultant response
-must begin with the same CMD byte. For each type of CMD, the structure
-of queries and responses is of fixed size. Following STK-500, fields
-longer than 1 byte are transmitted MSB first (big-endian). However,
-READ and WRITE commands operate byte-wise (not word-wise); it is up to
-the host PC to ensure that alignment and ordering issues are handled
-appropriately.
+and responses are transacted inside of the message body. Following
+the STK-500 protocol, each query or response begins with the single
+byte command field. For each query, the resultant response must begin
+with the same CMD byte. For each type of command, the structure of
+queries and responses is of fixed size.
+
+Also following STK-500, fields longer than 1 byte are transmitted MSB
+first (big-endian). However, READ and WRITE commands operate byte-wise
+(not word-wise); it is up to the host PC to ensure that alignment and
+ordering issues are handled appropriately.
.. _bootloader-get-info:
@@ -447,7 +466,7 @@ READ_BYTES query:
* - LENGTH
- 2
- Maximum number of bytes to read (currently, this may be at most
- 512). Must be a multiple of 4.
+ 1024 = 1KB). Must be a multiple of 4.
READ_BYTES response: