@@ -10,7 +10,7 @@ This module implements "foreign data interface" for MicroPython. The idea
1010behind it is similar to CPython's ``ctypes `` modules, but the actual API is
1111different, streamlined and optimized for small size. The basic idea of the
1212module is to define data structure layout with about the same power as the
13- C language allows, and the access it using familiar dot-syntax to reference
13+ C language allows, and then access it using familiar dot-syntax to reference
1414sub-fields.
1515
1616.. seealso ::
@@ -31,55 +31,55 @@ Following are encoding examples for various field types:
3131
3232* Scalar types::
3333
34- "field_name": uctypes.UINT32 | 0
34+ "field_name": offset | uctypes.UINT32
3535
3636 in other words, value is scalar type identifier ORed with field offset
3737 (in bytes) from the start of the structure.
3838
3939* Recursive structures::
4040
41- "sub": (2 , {
42- "b0": uctypes.UINT8 | 0 ,
43- "b1": uctypes.UINT8 | 1 ,
41+ "sub": (offset , {
42+ "b0": 0 | uctypes.UINT8 ,
43+ "b1": 1 | uctypes.UINT8 ,
4444 })
4545
4646 i.e. value is a 2-tuple, first element of which is offset, and second is
4747 a structure descriptor dictionary (note: offsets in recursive descriptors
48- are relative to a structure it defines).
48+ are relative to the structure it defines).
4949
5050* Arrays of primitive types::
5151
52- "arr": (uctypes.ARRAY | 0, uctypes.UINT8 | 2 ),
52+ "arr": (offset | uctypes.ARRAY, size | uctypes.UINT8),
5353
5454 i.e. value is a 2-tuple, first element of which is ARRAY flag ORed
5555 with offset, and second is scalar element type ORed number of elements
5656 in array.
5757
5858* Arrays of aggregate types::
5959
60- "arr2": (uctypes.ARRAY | 0, 2 , {"b": uctypes.UINT8 | 0 }),
60+ "arr2": (offset | uctypes.ARRAY, size , {"b": 0 | uctypes.UINT8 }),
6161
6262 i.e. value is a 3-tuple, first element of which is ARRAY flag ORed
6363 with offset, second is a number of elements in array, and third is
6464 descriptor of element type.
6565
6666* Pointer to a primitive type::
6767
68- "ptr": (uctypes.PTR | 0 , uctypes.UINT8),
68+ "ptr": (offset | uctypes.PTR , uctypes.UINT8),
6969
7070 i.e. value is a 2-tuple, first element of which is PTR flag ORed
7171 with offset, and second is scalar element type.
7272
7373* Pointer to an aggregate type::
7474
75- "ptr2": (uctypes.PTR | 0 , {"b": uctypes.UINT8 | 0 }),
75+ "ptr2": (offset | uctypes.PTR , {"b": 0 | uctypes.UINT8 }),
7676
7777 i.e. value is a 2-tuple, first element of which is PTR flag ORed
7878 with offset, second is descriptor of type pointed to.
7979
8080* Bitfields::
8181
82- "bitf0": uctypes.BFUINT16 | 0 | 0 << uctypes.BF_POS | 8 << uctypes.BF_LEN,
82+ "bitf0": offset | uctypes.BFUINT16 | lsbit << uctypes.BF_POS | bitsize << uctypes.BF_LEN,
8383
8484 i.e. value is type of scalar value containing given bitfield (typenames are
8585 similar to scalar types, but prefixes with "BF"), ORed with offset for
@@ -88,20 +88,21 @@ Following are encoding examples for various field types:
8888 BF_POS and BF_LEN positions, respectively. Bitfield position is counted
8989 from the least significant bit, and is the number of right-most bit of a
9090 field (in other words, it's a number of bits a scalar needs to be shifted
91- right to extra the bitfield).
91+ right to extract the bitfield).
9292
93- In the example above, first UINT16 value will be extracted at offset 0
93+ In the example above, first a UINT16 value will be extracted at offset 0
9494 (this detail may be important when accessing hardware registers, where
9595 particular access size and alignment are required), and then bitfield
96- whose rightmost bit is least-significant bit of this UINT16, and length
97- is 8 bits, will be extracted - effectively, this will access
98- least-significant byte of UINT16.
96+ whose rightmost bit is *lsbit* bit of this UINT16, and length
97+ is *bitsize* bits, will be extracted. For example, if *lsbit* is 0 and
98+ *bitsize* is 8, then effectively it will access least-significant byte
99+ of UINT16.
99100
100101 Note that bitfield operations are independent of target byte endianness,
101102 in particular, example above will access least-significant byte of UINT16
102103 in both little- and big-endian structures. But it depends on the least
103104 significant bit being numbered 0. Some targets may use different
104- numbering in their native ABI, but ``uctypes`` always uses normalized
105+ numbering in their native ABI, but ``uctypes`` always uses the normalized
105106 numbering described above.
106107
107108Module contents
0 commit comments