S?bastien Bourdeauducq wrote: > Didn't work. Also tried deglitching (patch attached) without any > visible improvement.
:-( I've tried yesterday to get CRC checking of incoming data to work. No matter what I tried, I always ran into timing issues between the EOP of DATAx and the time I was able to send the ACK, or worse failure patterns. Things I tried: - step-wise (one byte at a time) CRC calculation after receiving each byte, with check of the residual after EOP, - idem, with residual check before WAIT_RX and two loops with distinct EOP handling (i.e., accept or drop), - calculate the CRC after sending the ACK and then decide on whether to accept the packet or fail hard. Sometimes, I got a few transfers through, but always with marginal timing. I also tried various different implementations of the CRC calculation (inline function with CRC in short, struct, via char pointer; open-code the calculation; table in progmem or RAM), to no avail. What's odd is that apparently innocuous changes suddenly caused RX timeouts or CRC errors. Things like whether I'd print a complaint after a CRC error had a major impact. The most surprising result was that calculating the CRC after sending the ACK yielded a flood of RX timeouts. My plan is now to add instrumentation inside the SoC, so that I can monitor things like buffering delay or the time between incoming EOP and EOP signal to Navre without adding code that itself distorts the timing. I'm now downloading ISE. Then I have to figure out how to use it. Wish me luck :-) - Werner _______________________________________________ http://lists.milkymist.org/listinfo.cgi/devel-milkymist.org IRC: #milkymist@Freenode
