Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Why MAX_PACKET_SIZE is set to 800? #29

Open
desowin opened this issue Jul 4, 2019 · 1 comment · May be fixed by #56
Open

Why MAX_PACKET_SIZE is set to 800? #29

desowin opened this issue Jul 4, 2019 · 1 comment · May be fixed by #56

Comments

@desowin
Copy link
Contributor

desowin commented Jul 4, 2019

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?

@somehdlguy
Copy link
Collaborator

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants