USB Complete - Packet Identified and CRC - ping-pong buffering etc

[JorgenSandberg]

I am busy converting your HID Generic to XC8. That has forced me to dig into the detailed working of the USB software. I have it running and can enumerate the 18F4550. But thre are a couple of details that bother me and maybe someone in the forum will take the time to inform me.

In the book USB Complete page 46 is stated that all packets consists of: a PID (packet identifier), maybe some data, and a CRC (error-checking). On page 92 is stated that the data packet for a setup contains a PID and additionally 8 data bytes. The HID Generic software uses an 8 byte buffer to receive the setup packages. In the definition of the packages in the software there is no room for the PID. So, my question is: Is the PID included in the bytes coming out of the SIE in the 18F4550 or does the SIE strip off the PID and the CRC in packets received on the USB bus (i.e. OUT packages)? Similarly, does the SIE generate the PID and CRC on IN packages?

If the PID is not passed in the bytes to the software in the 18F4550, how will the user then know what kind of packet has been received?

Digging through the HID Generic software to convert it for XC8, I believe the key is to ensure that the BDT and the buffers addressed in the BDT are correctly placed in RAM as per the 18F4550 manual. (The BDT has to start at 400 hex and the buffers have to be after the BDT and up to 7FF hex). When I looked carefully at the buffers addressed in the BDT, I could not identify any ping-pong buffering. Ping pong buffering is selected in the configuration file and implemented in the BDT but only one buffer is used, they ping and pong to one and the same buffer. Have I missed something when I read the code? Another thing is that the Endpoint 01 IN and Endpoint 01 OUT are defined to be 64 bytes long (fixed coded in the endpoint descriptors), but the code reserves only 8 bytes for the buffer that is entered into the BDT for the two endpoints. Again, have I missed something when I read the code? These questions are rather important when I allocate absolute addresses to the BDT and the buffers, else I risk they overlap and result in a mess.

Regards,
Jorgen

[JorgenSandberg]

Sorry, I have figured out the PID part of my questions. The PID is removed by the SIE and presented in the BDnSTAT when this is owned by the SIE. Complex, but OK it is there.

Regards,
Jorgen

[Barry Twycross]

It all depends on your hardware, and I'm not familiar with the hardware you're using. However, all USB cores I've used have worked in much the same way. You only get the data payload delivered, ie no PID. For most endpoints this is not a problem, as they only get sent one PID (and OUT for receive endpoint). Control endpoints are slightly different and have to be configured as such. The endpoint is expecting to receive either an OUT or a SETUP at various times.

There is usually some flag to tell you a SETUP has been received, and that flag is not set if an OUT is received. You should check your documentation. Some cores have special buffers for any SETUP packet received. Don't forget that to spec, a control endpoint must be able to receive a SETUP packet at any time regardless of what the endpoint is expecting. There is usually some provision to make this possible.