Quote from: end18 on March 12, 2014, 02:19:21 PM

Quote from: zefir on March 11, 2014, 09:10:37 PM

Clarification: SPI Processing shorter Chip Chains

I have been approached by users having difficulties to operate their designs with the official or reference cgminer driver.

Here is the SPI trace provided:

Code:

TX: 8 bytes: 09 00 88 A6 21 84 00 00 //spi_send_command
RX: 8 bytes: 00 00 00 00 09 00 88 A6 //spi_send_command
RX: 2 bytes: 21 84 //spi_poll_result
RX: 2 bytes: 00 00 //spi_poll_result
RX: 2 bytes: 00 00 //spi_poll_result

To understand why polling for the ACK (i.e. reading 0x90 00 from the chain) fails in this case, consider how the current implementation accesses the chain:
1) write a command to the first A1, which with every next dummy write is shifted to the next A1
2) to get an ACK, shift the data through the chain until you receive the expected return values

The reference implementation in a first step writes the command and in the second polls for the result. This works with longer chains, but in this case (with 1 or 2 chip chains) fails because the response is obviously returned already while the command is still written.

To circumvent the issue, one needs to search for the ACK already in the RX buffer of the command write step. In the upper case the correct processing would therefore be:
1) write 8 bytes for command 09
2) in the RX buffer search for the ACK (here at position 5)
3) determine how many more words need to be polled for the full ACK (here 2 more words) and do the poll

Unfortunately I have no single chip chain available to test and implement this, but it obviously is no rocket science and should be easily done.

I had same problem in 1-chip Test.

I just changed additional recv size. :-)
(at [register read] & [result read] )

Can 2-chip cgminer fork with RX buffer patch be uploaded to Bitmine Github ?