Difference between revisions of "Sysclk LWLA1034/Protocol"
(Document a couple more commands) |
(Document even more commands) |
||
Line 113: | Line 113: | ||
=== Response === | === Response === | ||
The memory is apparently 36 bit wide: The size of the response in bits is 36 times the value in the length field. The software reads chunks of 120 words @ 36 bit at a time, which works out to an integer multiple of 8 (i.e. 4320 bits = 540 bytes). | The memory is apparently 36 bit wide: The size of the response in bits is 36 times the value in the length field. The software reads chunks of 120 words @ 36 bit at a time, which works out to an integer multiple of 8 (i.e. 4320 bits = 540 bytes). The final six reads are done in chunks of 8 words @ 36 bit, which works out to 36 bytes. Judging from this behavior, it seems that reading partial bytes is likely illegal. | ||
Note that the software always starts reading at address 4 rather than 0. Presumably the firmware uses the first four 36-bit words for internal bookkeeping. | Note that the software always starts reading at address 4 rather than 0. Presumably the firmware uses the first four 36-bit words for internal bookkeeping. | ||
== Command 0007: Configure Channels ??? == | |||
The software issues this command just once as part of the setup sequence when initiating a new capture operation. The message format appears similar to command 0008 and its response. | |||
=== Command === | |||
Tentatively: variable length of 3 words (6 bytes), plus length times 8 bytes. | |||
{| border="0" style="font-size: smaller;" class="sigroktable" | |||
!ID | |||
!Length? | |||
!Data 1? | |||
!Data 2? | |||
!... | |||
|- | |||
| 0007 | |||
| nnnn-nnnn | |||
| dddd-dddd-dddd-dddd | |||
| dddd-dddd-dddd-dddd | |||
| ... | |||
|} | |||
The two argument words in the header look like a 32-bit length field in mixed endian (2-1-4-3) byte order. However, the software never uses any value other than 10 for this field, so it could just as well mean something completely different. The header seems to match the format of command 0008, and the payload looks similar to the response to command 0008. | |||
== Command 0008: Read Channel State ??? == | |||
This command appears to read data from a streaming source, as there is no apparent address information. The software issues 34 of those in sequence every second when idle, likely in order to read out the state of each input channel. | |||
=== Command === | |||
Fixed length of 3 words (6 bytes). | |||
{| border="0" style="font-size: smaller;" class="sigroktable" | |||
!ID | |||
!Length? | |||
|- | |||
| 0008 | |||
| nnnn-nnnn | |||
|} | |||
The two argument words look like a 32-bit length field in mixed endian (2-1-4-3) byte order. However, the software never uses any value other than 10 for this field, so it could just as well mean something completely different. | |||
=== Response === | |||
Tentatively, if the message does indeed carry a length field: The response is a sequence of 64-bit words, i.e. 80 bytes for a length of 10. |
Revision as of 21:42, 21 December 2013
Command messages sent to the device appear to be a sequence of 16-bit words with little endian byte order. The first word in a message identifies the command type. Different command types have different message lengths. Some command types include a length field and allow for messages of variable length, others are of fixed size.
There are read commands which trigger an immediate response from the device, and write commands without a response.
Command 0001: Read Register
This command appears to read a 32-bit wide control register.
Command
Fixed length of 2 words (4 bytes).
ID | Address |
---|---|
0001 | aaaa |
Response
The response has a fixed length of 4 bytes. It is likely the content of a 32-bit register in either little endian or mixed endian byte order.
Command 0002: Write Register
This command appears to write a 32-bit value to a control register.
Command
Fixed length of 4 words (8 bytes).
ID | Address | Data |
---|---|---|
0002 | aaaa | dddd-dddd |
The data is likely either in little endian or in mixed endian byte order.
Command 0005: Write ???
This command appears to write 16 32-bit words at once. It is issued once after a transfer of captured data to the host has finished.
Command
Fixed length of 33 words (66 bytes).
ID | Data 1 | Data 2 | Data 3 | Data 4 | Data 5 | Data 6 | Data 7 | Data 8 | Data 9 | Data 10 | Data 11 | Data 12 | Data 13 | Data 14 | Data 15 | Data 16 |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
0005 | dddd-dddd | dddd-dddd | dddd-dddd | dddd-dddd | dddd-dddd | dddd-dddd | dddd-dddd | dddd-dddd | dddd-dddd | dddd-dddd | dddd-dddd | dddd-dddd | dddd-dddd | dddd-dddd | dddd-dddd | dddd-dddd |
The individual 32-bit words are likely either in little endian or in mixed endian byte order.
Command 0006: Read Memory at Address
This command appears to read a block from the device memory (probably the SRAM). It allows for random access using a 32-bit start address, and variable length via a 32-bit length field. The software uses this command to read captured data from the device's buffer.
Command
Fixed length of 5 words (10 bytes).
ID | Address | Length |
---|---|---|
0006 | aaaa-aaaa | nnnn-nnnn |
Both the address and the length are apparently encoded with mixed endian (2-1-4-3) byte order: MSW (16 bit) followed by LSW (16 bit), with the two bytes making up each individual 16-bit word in little endian order.
Response
The memory is apparently 36 bit wide: The size of the response in bits is 36 times the value in the length field. The software reads chunks of 120 words @ 36 bit at a time, which works out to an integer multiple of 8 (i.e. 4320 bits = 540 bytes). The final six reads are done in chunks of 8 words @ 36 bit, which works out to 36 bytes. Judging from this behavior, it seems that reading partial bytes is likely illegal.
Note that the software always starts reading at address 4 rather than 0. Presumably the firmware uses the first four 36-bit words for internal bookkeeping.
Command 0007: Configure Channels ???
The software issues this command just once as part of the setup sequence when initiating a new capture operation. The message format appears similar to command 0008 and its response.
Command
Tentatively: variable length of 3 words (6 bytes), plus length times 8 bytes.
ID | Length? | Data 1? | Data 2? | ... |
---|---|---|---|---|
0007 | nnnn-nnnn | dddd-dddd-dddd-dddd | dddd-dddd-dddd-dddd | ... |
The two argument words in the header look like a 32-bit length field in mixed endian (2-1-4-3) byte order. However, the software never uses any value other than 10 for this field, so it could just as well mean something completely different. The header seems to match the format of command 0008, and the payload looks similar to the response to command 0008.
Command 0008: Read Channel State ???
This command appears to read data from a streaming source, as there is no apparent address information. The software issues 34 of those in sequence every second when idle, likely in order to read out the state of each input channel.
Command
Fixed length of 3 words (6 bytes).
ID | Length? |
---|---|
0008 | nnnn-nnnn |
The two argument words look like a 32-bit length field in mixed endian (2-1-4-3) byte order. However, the software never uses any value other than 10 for this field, so it could just as well mean something completely different.
Response
Tentatively, if the message does indeed carry a length field: The response is a sequence of 64-bit words, i.e. 80 bytes for a length of 10.