You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I briefly checked the OpenVizsla packet format and noticed that there is: HF0_TRUNC = 0x08, // Clipped due to packet length (> 800 bytes)
Then I noticed that this seems to originate from the software/fpga/ov3/ovhw/whacker/producer.py which has the MAX_PACKET_SIZE = 800.
Is there any actual reason why there is such an arbitrary limit set? Why not make it 1 + 1024 + 2 = 1027 (PID + Data payload + CRC-16) to match the USB 2.0 high speed maximum for interrupt and isochronous transfers?
The text was updated successfully, but these errors were encountered:
I don't have a good answer as to why we chose 800 as a maximum packet size. I'll have to revisit the code to determine if there is a good reason. I'll try to do so in the next few days.
The packetization code is a bit arcane. Choices in there have implications in the SDRAM access patterns, packet streaming to the host and other areas I probably don't remember. Some other analyzers just double each byte to a value/flags tuple to avoid this complexity, but we felt this was an unacceptable impact to capture bandwidth.
I briefly checked the OpenVizsla packet format and noticed that there is:
HF0_TRUNC = 0x08, // Clipped due to packet length (> 800 bytes)
Then I noticed that this seems to originate from the
software/fpga/ov3/ovhw/whacker/producer.py
which has theMAX_PACKET_SIZE = 800
.Is there any actual reason why there is such an arbitrary limit set? Why not make it 1 + 1024 + 2 = 1027 (PID + Data payload + CRC-16) to match the USB 2.0 high speed maximum for interrupt and isochronous transfers?
The text was updated successfully, but these errors were encountered: