5 comments:
Looking at iceBurn, the meaning of the bytes seems known? 2-byte […]
Added some more checking of the response.
Patch Set #4, Line 230: ret = do_command(req, sizeof(req), res, sizeof(res));
This seems flawed or at least confuses me too much. If I read iceBurn […]
They got this wrong. In fact, they end up padding the read count in the callers of __ICE40SPIPort.io() and then chop the padding from the response. E.g.:
def read(self, addr, size):
return self.io([self.CMD_FAST_READ...], size+5)[5:]
Eek. I suspect that they didn't grok this might be the reason iceBurn might not support readback of the memory.
Patch Set #4, Line 236: return -1;
iceBurn pads with zeros, aiui. And not by `readcnt` bytes but only […]
Yes, but their read count already contains the write size -- see above. They perhaps didn't realize it, or just didn't bother tidying up their code after they did.
The 0x00 vs. 0xff doesn't seem to matter. I don't remember why i chose 0xff, perhaps I've seen it in the trace from the proprietary digilent's tool.
Patch Set #4, Line 246: if ((res[1] & 0x40) == 0) {
Maybe we should check `tx_len` as well.
True. Done.
ret = spi_start_io(re
These are about the payload size, i.e. data actually read / written […]
Raised to 252, empirically determined as the actual limit of the payload the hardware can handle.
Not sure if an inner loop would significantly speed this up, I'd prefer keeping things simple now.
To view, visit change 23338. To unsubscribe, or for help writing mail filters, visit settings.