BIP MinerHardwareBinaryProtocol - Revision history

Luke-jr at 20:27, 14 July 2012

2012-07-14T20:27:44Z

Luke-jr: /* Packet Format */

2012-07-03T03:19:42Z

Packet Format

← Older revision		Revision as of 03:19, 3 July 2012
Line 16:		Line 16:

	===Packet Format===		===Packet Format===
	*1 byte: always FF		*1 byte: always FE
	*1 byte: packet length/type		*1 byte: packet length/type
	*N bytes: packet data		*N bytes: packet data
Line 35:		Line 35:
	Null-length commands (ie, "ff" without any valid data packets preceding it) must be ACK'd and ignored.		Null-length commands (ie, "ff" without any valid data packets preceding it) must be ACK'd and ignored.

	Anything up to the initial FF is ignored.		Anything up to the initial FE is ignored.

	===Command Format===		===Command Format===

Luke-jr at 03:19, 3 July 2012

2012-07-03T03:19:13Z

← Older revision		Revision as of 03:19, 3 July 2012
Line 16:		Line 16:

	===Packet Format===		===Packet Format===
			*1 byte: always FF
	*1 byte: packet length/type		*1 byte: packet length/type
	*N bytes: packet data		*N bytes: packet data
Line 33:		Line 34:

	Null-length commands (ie, "ff" without any valid data packets preceding it) must be ACK'd and ignored.		Null-length commands (ie, "ff" without any valid data packets preceding it) must be ACK'd and ignored.

			Anything up to the initial FF is ignored.

	===Command Format===		===Command Format===

Luke-jr: /* Packet Format */

2012-07-03T02:57:26Z

Packet Format

← Older revision		Revision as of 02:57, 3 July 2012
Line 32:		Line 32:
	CRC32 must include the string "mhbp" plus the packet length/type byte and all data; this is not used to prevent corruption (USB already guarantees that), but rather to avoid acting when something foreign sends stuff. If the CRC32 does not match, the device should send a "fd" packet back and abort the command.		CRC32 must include the string "mhbp" plus the packet length/type byte and all data; this is not used to prevent corruption (USB already guarantees that), but rather to avoid acting when something foreign sends stuff. If the CRC32 does not match, the device should send a "fd" packet back and abort the command.

	Null-length commands (ie, "ff" without any valid data packets preceding it) must be ignored.		Null-length commands (ie, "ff" without any valid data packets preceding it) must be ACK'd and ignored.

	===Command Format===		===Command Format===

Luke-jr: /* Packet Format */

2012-07-03T02:53:37Z

Packet Format

← Older revision		Revision as of 02:53, 3 July 2012
Line 30:		Line 30:
	ACK should be sent in response to each 250-byte packet. Bulk data transfers, such as bitstream uploads, should wait until ACK is received before sending more packets (maybe? or does USB handle this for us too?).		ACK should be sent in response to each 250-byte packet. Bulk data transfers, such as bitstream uploads, should wait until ACK is received before sending more packets (maybe? or does USB handle this for us too?).

	CRC32 must include the packet length/type byte and all data; this is not used to prevent corruption (USB already guarantees that), but rather to avoid acting when something foreign sends stuff. If the CRC32 does not match, the device should send a "fd" packet back and abort the command.		CRC32 must include the string "mhbp" plus the packet length/type byte and all data; this is not used to prevent corruption (USB already guarantees that), but rather to avoid acting when something foreign sends stuff. If the CRC32 does not match, the device should send a "fd" packet back and abort the command.

	Null-length commands (ie, "ff" without any valid data packets preceding it) must be ignored.		Null-length commands (ie, "ff" without any valid data packets preceding it) must be ignored.

Luke-jr at 02:48, 3 July 2012

2012-07-03T02:48:22Z

← Older revision		Revision as of 02:48, 3 July 2012
Line 37:		Line 37:
	*1 byte: request id		*1 byte: request id
	*1 byte: command id		*1 byte: command id
	**0x -- Modification commands (potentially dangerous)		**Cx -- Modification commands (potentially dangerous)
	**4x -- Informational commands		**Dx -- Replies to Modification commands
	**~~(high bit set for replies)~~		**Ex -- Informational commands
			**Fx -- Replies to Informational commands
	*1 byte: device number (ignored for some commands)		*1 byte: device number (ignored for some commands)
	**00 is the MCU		**00 is the MCU
Line 53:		Line 54:

	===Commands===		===Commands===
	====01 -- program software====		====c1 -- program software====
	Data:		Data:
	* 4 bytes: hardware version (big endian)		* 4 bytes: hardware version (big endian)
Line 61:		Line 62:
	* 4 bytes: software size		* 4 bytes: software size
	* N bytes: software data		* N bytes: software data
	====02 -- get/set clock speed====		====c2 -- get/set clock speed====
	Data:		Data:
	* 1 byte: new clock speed (00 = don't change)		* 1 byte: new clock speed (00 = don't change)
	Reply (if getting):		Reply (if getting):
	* 1 byte: current clock speed		* 1 byte: current clock speed
	====03 -- get/set register(s)====		====c3 -- get/set register(s)====
	Data:		Data:
	* 2 bytes: first register number		* 2 bytes: first register number
Line 74:		Line 75:
	* 1 byte: width (in bits) of each register		* 1 byte: width (in bits) of each register
	* N bytes: value of each register		* N bytes: value of each register
	====04 -- watch register(s)====		====c4 -- watch register(s)====
	Data:		Data:
	* 2 bytes: first register number		* 2 bytes: first register number
Line 87:		Line 88:
	** 2 bytes: register number		** 2 bytes: register number
	** N bytes: value of register		** N bytes: value of register
	====40 -- ping====		====e0 -- ping====
	Device number ignored.		Device number ignored.
	Replies with same data given		Replies with same data given
	====41 -- get FPGA count====		====e1 -- get FPGA count====
	Device number ignored.		Device number ignored.
	Reply:		Reply:
	* 1 byte: number of FPGAs		* 1 byte: number of FPGAs
	====42 -- hardware version====		====e2 -- hardware version====
	Reply:		Reply:
	* 4 bytes: hardware version (big endian)		* 4 bytes: hardware version (big endian)
Line 107:		Line 108:
	* N bytes: human-readable hardware model/version string (UTF-8)		* N bytes: human-readable hardware model/version string (UTF-8)

	====43 -- software version====		====e3 -- software version====
	Reply:		Reply:
	* 4 bytes: software version (big endian)		* 4 bytes: software version (big endian)
Line 114:		Line 115:
	* 1 byte: length of human-readable software name		* 1 byte: length of human-readable software name
	* N bytes: human-readable hardware model/version string (UTF-8)		* N bytes: human-readable hardware model/version string (UTF-8)
	====44 -- get temperature====		====e4 -- get temperature====
	Reply:		Reply:
	* 1 byte: temperature in celcius		* 1 byte: temperature in celcius

	==Examples==		==Examples==
			''' Needs updating '''

	====Get temperature of FPGA #2====		====Get temperature of FPGA #2====
	> 04 00 44 02 00 ff		> 04 00 44 02 00 ff

Luke-jr: /* 42 -- hardware version */

2012-06-28T03:14:17Z

42 -- hardware version

← Older revision		Revision as of 03:14, 28 June 2012
Line 100:		Line 100:
	* 2 bytes: hardware model number		* 2 bytes: hardware model number
	* 4 bytes: hardware specific information ("ID Code")		* 4 bytes: hardware specific information ("ID Code")
			* 1 byte: length of hardware serial number
			* N bytes: hardware serial number
	* 1 byte: length of hardware model number		* 1 byte: length of hardware model number
	* N bytes: hardware model number (EUI-64 when available)		* N bytes: hardware model number (EUI-64 when available)
	* 1 byte: length of human-readable hardware model		* 1 byte: length of human-readable hardware model
	* N bytes: human-readable hardware model/version string (UTF-8)		* N bytes: human-readable hardware model/version string (UTF-8)

	====43 -- software version====		====43 -- software version====
	Reply:		Reply:

Luke-jr: CRC32 to avoid responding to gibberish

2012-06-28T03:12:33Z

CRC32 to avoid responding to gibberish

← Older revision		Revision as of 03:12, 28 June 2012
Line 18:		Line 18:
	*1 byte: packet length/type		*1 byte: packet length/type
	*N bytes: packet data		*N bytes: packet data
			*4 bytes: packet data CRC32 (only for data packets)

	Packet length/types:		Packet length/types:
	* 00 - Abort		* 00 - Abort
	* 01 to fa - Data packet length (1 to ~~250~~ bytes)		* 01 to ef - Data packet length (1 to 239 bytes)
	* fb to fd - ~~Reserved~~		* f0 to fc - Reserved
			* fd - Bad packet (command aborted)
	* fe - ACK		* fe - ACK
	* ff - End of command		* ff - End of command

	ACK should be sent in response to each 250-byte packet. Bulk data transfers, such as bitstream uploads, should wait until ACK is received before sending more packets (maybe? or does USB handle this for us too?).		ACK should be sent in response to each 250-byte packet. Bulk data transfers, such as bitstream uploads, should wait until ACK is received before sending more packets (maybe? or does USB handle this for us too?).

			CRC32 must include the packet length/type byte and all data; this is not used to prevent corruption (USB already guarantees that), but rather to avoid acting when something foreign sends stuff. If the CRC32 does not match, the device should send a "fd" packet back and abort the command.

			Null-length commands (ie, "ff" without any valid data packets preceding it) must be ignored.

	===Command Format===		===Command Format===
Line 125:		Line 131:

	====Reset the command queue====		====Reset the command queue====
	To reset the command queue, send ~~251~~ zero bytes; this will pad-out any "open" packet, and send a zero-length for the next one to abort the command.		To reset the command queue, send 244 zero bytes; this will pad-out any "open" packet, and send a zero-length for the next one to abort the command.

	==Motivation==		==Motivation==

Luke-jr: /* Packet Format */

2012-06-28T03:04:34Z

Packet Format

← Older revision		Revision as of 03:04, 28 June 2012
Line 19:		Line 19:
	*N bytes: packet data		*N bytes: packet data

	~~Valid lengths are~~ 1-250 (bytes).		Packet length/types:
	End of command ~~is denoted by a length/type of ff.~~		* 00 - Abort
	~~Abort command is denoted by a length/type of 00.~~		* 01 to fa - Data packet length (1 to 250 bytes)
	ACK ~~is denoted by a length/type of fe, and~~ should be sent in response to each 250-byte packet. Bulk data transfers, such as bitstream uploads, should wait until ACK is received before sending more packets (maybe? or does USB handle this for us too?).		* fb to fd - Reserved
	~~Length/types fa-fd are reserved~~.		* fe - ACK
			* ff - End of command

			ACK should be sent in response to each 250-byte packet. Bulk data transfers, such as bitstream uploads, should wait until ACK is received before sending more packets (maybe? or does USB handle this for us too?).

	===Command Format===		===Command Format===

Luke-jr: /* Packet Format */

2012-06-28T02:58:58Z

Packet Format

← Older revision		Revision as of 02:58, 28 June 2012
Line 16:		Line 16:

	===Packet Format===		===Packet Format===
	1 byte: packet length/type		*1 byte: packet length/type
	N bytes: packet data		*N bytes: packet data

	Valid lengths are 1-250 (bytes).		Valid lengths are 1-250 (bytes).