Eureka: meaning of setupdat 0 and 1

Late night lab work...

Discovery: CyU3PUsbGetEP0Data and CyU3PUsbSendEP0Data Mystery??

How the Vendor/Class Request is handled in the FX3 ?

The API CyU3PUsbRegisterSetupCallback() will register a callback function which will handle vendor/class/standard requests. If the fastEnum bit in the function parameter is set then the device hardware itself handles the standard request, we only need to handle the class/vendor requests. The registered setup callback function will be executed whenever a control request is received. Two 4 byte callback function parameters will specify the 8 byte setup packet. Handling of each setup request involve one and only one of the following API calls. 1. CyU3PUsbSendEP0Data, [Called to perform any IN-data phase associated with the request] 2. CyU3PUsbGetEP0Data,  [Called to perform any OUT-data phase associated with the request] 3. CyU3PUsbAckSetup,[Called to complete the status handshake (ACK) phase of a request that does not involve any data transfer] 4. CyU3PUsbStall,[Called to stall EP0 to fail the setup request] If the setup callback function successfully handled the request then the user should return CyTrue, or else the user should return CyFalse. Flowcharts and code examples are also attached for the following, 1. Stalling Vendor / Class request. 2. Handling Vendor / Class request with Data Phase. 3. Handling Vendor / Class request without Data Phase.

Discovery: End Point 0...

One of the blogs on Cypress.. (wasnt answered, but gives a good insight):

I am used to dealing with microcontrollers where the USB data is put into an array that can be accessed at the byte level. So you call a doUSB() function, you get a 64byte packet of data from the host, process, and send back a 64byte packet. Or receive a byte array all the time and then send out byte arrays all the time by just checking if the endpoint is clear to do so or not.
So looking at the FX3 sample code is daunting. I can make the GPIO sample wiggle a PWM pin and so it works.
But now I just want to be able to pass the information out of the USB module into a peripheral and into another chip like an FPGA to do some light work and pass it pack through the peripheral and back into the USB module. Like a FIFO in for USB data from the host to the device and a FIFO out for USB data from the device to the host.
Since there are impossibly tiny Samtech and Tyco connectors on the dev board to access the Slave FIFO, I am forced to use the SPI header. I read that it can go 33MHz which is fine for initial testing. I am hoping I can move to the slave FIFO once I get an actual board spun with an FPGA and the FX3 on it. But for now it will be 2 dev kits wired together with some jumper wire.
So back to the firmware, I am looking at the USBSpiRegMode example (although I still dont understand the difference between RegMode and DMA mode) because it seems like a good base to go from USB to SPI. I don't know if I know what I am looking at.
I see uint8_t glEp0Buffer[4096]; which appears to be Endpoint 0's byte array buffer. Is that correct? It also looks like the USB mode is not a Write-then-Read architecture but an architecture that splits the write and reads from the endpoint into separate entitites so that you could write forever without reading or visa versa read forever without writing. Correct?It would appear that CyU3PUsbGetEP0Data() is the magic USB goo that checks the USB endpoint from the host to the FX3 and when there is data it will return the data in the buffer, correct?
So this bit of code...
            status = CyU3PUsbGetEP0Data (length, glEp0Buffer, NULL);...gets "length" bytes from EndPoint 0 (EP0) and puts them into glEp0Buffer, with returned_data's index-0 at glEp0Buffer's index-0? Is this a blocking call until data is received or does it fail the status if there is nothing to read?Then to transfer on the Spi peripheral it uses this bit of code immediately afterwards correct?
            if (status == CY_U3P_SUCCESS)            {                status = CyFxSpiTransfer (index, length,                        glEp0Buffer, CyFalse);            }            break;It would also appear that to send data over USB, you would call CyU3PUsbSendEP0Data(length, buffer pointer) correct?
So would it stand to reason that I could simple stay in a loop that called CyU3PUsbGetEP0Data() and get a byte stream back that I could then pass into CyFxSpiTransfer() for the Host->FPGA communication? Then pass that returned SPI byte array into CyU3PUsbSendEP0Data() for the FPGA->Host communication?
Any help would be appreciated.

Important Discovery: Vendor requests!

So who is a vendor?

I am guessing- in  my case - matlab is the vendor.  

What is a vendor request?

When matlab sends a code to USB, that code is passed to the USB call back function, which in turn will request what functions to run. 

How to write one?

For a Vendor requets to read bytes it should be

Direction IN / Req Type Vendor  / Target Device / Req Code your request code

ERRORS: Creating your own codes from scratch...??

The problem:

Take gpioApp example and rename it and put it in the same folder as the original - this gives the same general errors about DMA conflicts and other libraries not found.
So TIEs code must have been working but some setup has to be figured out...
For now let me just play around with interface and the TP2 pin. 

Solution:

//in cyfxtx.c it should be... int return type. int
CyU3PDmaBufferFree (
        void *buffer)
// in cy3os.h make sure the function has "extern int" extern int // if its void return then it will give conflicting functions. CyU3PDmaBufferFree (
        void *buffer)

ERROR: TIEs code wont build: Conflicting function

And then if I dumbly comment it out. Gave me more errors! 

LOL. Now what?