Looking for software that's like hidusbf changes bInterval value for endpoint descriptor of HID device any alternatives or how to do this yourself?
Related
I'm using MPSSE library to have SPI communication via PC.
There are 3 main functions which handle communcation via SPI:
SPI_Read - for reading
SPI_Write - for writing
and the third one
SPI_ReadWrite, described as:
this function reads from and writes to the SPI slave simultaneously. Meaning that one bit is clocked in and one bit is clocked out during every clock cycle.
and I can't get the difference between them like in SPI signals...
What's the purpose of using it, if in SPI we need to serially do writing and reading.
Generally, a SPI transfer is always bidirectional, if we look only at the wires.
With SPI_Read() you need to look into its source or watch the sending wire to learn what is sent. Probably it is all 0 or all 1. However, only the received data is returned, and the caller does not need to provide data to send.
With SPI_Write() the received data is ignored. The caller has to provide the data to send.
And SPI_ReadWrite() reveals the true nature of this interface. With each clock one bit is sent, and one bit is received. Data to send must be provided, and received data is returned. The number of bits is the same for both directions.
It all depends on the communication partners how they handle it.
All operations on SPI are simultaneous read/write. The read-only function must write "dummy" data, while for the write-only function data is read and discarded. Most likely if you look into either SPI_Read() or SPI_Write() you will find that they are both implemented using SPI_ReadWrite(). At least you would with an MCU implementation, the MPSSE code is not SPI code but USB code for communicating with FTDI SPI/USB bridge devices, so the simplicity of SPI is not really apparent - USB is massively more complex but unlike SPI is half-duplex (excepting USB-C SS modes), so cannot truly perform simultaneously read/write - that is performed by the FTDI device not the USB connected PC which has a "virtual" SPI port
The reason is that the master and slave SPI roles are implemented as single shift-registers connected in a loop; as the master clocks data out one end of its shift-register, new data is simultaneously shifted in from the slave, so that after one complete word-write operation, new data from the slave will be present in the master shift register.
The nature of SPI is indicated by the signal names - master-out/slave-in (MOSI) and master-in/slave-out (MISO)* - both occur, one bit per SCLK edge.
Attribution CBurnett from https://en.wikipedia.org/wiki/Serial_Peripheral_Interface#/media/File:SPI_8-bit_circular_transfer.svg
In your case however what you have is:
----------------------------
| SPI/USB Bridge e.g. FT4222H|
---------- | ---------- ---------- |
| |<--SCLK---| | | ||
| SPI Slave|---MISO-->|SPI Master|<-->|USB Device||
| |<--MOSI---| | | ||
---------- | ---------- ---------- |
| ^ |
--------------------|-------
|
--------
|USB Host|
| (PC) |
--------
So the communications you are seeing is USB not SPI. The simultaneous read/write is occurring at the SPI Master/Slave level and bridged to USB art half-duplex (write followed by read). Note that Host/Device is simply a less loaded term than master/slave - the relationship and control are similar in that a USB device cannot initiate a transfer autonomously.
Not all devices can usefully exploit the simultaneous read/write capability; it is useful mostly in situations where input and output data are independent and streamed such as SPI UARTs, or perhaps in a proprietary MCU to MCU connection. In transactional operations, such as reading a device register or EEPROM memory location, you typically write a command or request and separately read the response, so separate read/write "facades" to the intrinsic read/write are provided so you don't have to handle the dummy data yourself.
We are developing an example where device continuously stream data through an isochronous IN endpoint. Now my question was as interrupt and isochronous have lot of similarities :
Max 1024 packets in USB HS
both are for bandwidth guarantee.
Host polls device every micro frame.
can I use my host interrupt endpoint to configure is to read from device's isochronous endpoints ?
device isochronous endpoints is following :
===>Endpoint Descriptor<===
bLength: 0x07
bDescriptorType: 0x05
bEndpointAddress: 0x81 -> Direction: IN - EndpointID: 1
bmAttributes: 0x05 -> Isochronous Transfer Type, Synchronization Type = Asynchronous, Usage Type = Data Endpoint
wMaxPacketSize: 0x0180 = 1 transactions per microframe, 0x180 max bytes
bInterval: 0x01
I understand there is NACK/ACK token in the interrupt endpoints , but let say if device ignores this NACK/ACK token can I still communicate with device using my interrupt endpoints ?
USB 2.0 specifies 4 types of transfers (in section 5.4 Transfer Types):
Control Transfers
Isochronous Transfers
Interrupt Transfers
Bulk Transfers
Section 5.8 says that Bulk Transfers provide:
Access to the USB on a bandwidth-available basis
Retry of transfers, in the case of occasional delivery failure due to errors on the bus
Guaranteed delivery of data but no guarantee of bandwidth or latency
(Emphasis mine.)
I don't see a similar statement for Control Transfers. Do they also guarantee delivery? If not, how are users expected to handle failures?
Please provide a citation(s) to support your answer.
The USB specification provides robust error detection and recovery for control transfers. The control transfer will either be completed or the USB host will know that it failed, and I think that's what "guaranteed delivery" is supposed to mean. This is important because control transfers are used to set up the device when you plug it into a computer and they are also used for many important purposes by the various USB device classes (e.g. they are used to set the baud rate of a serial port on a USB CDC ACM device).
From section 5.5.5 of the USB 2.0 specification:
The USB provides robust error detection and recovery/retransmission for errors that occur during control transfers. Transmitters and receivers can remain synchronized with regard to where they are in a control transfer and recover with minimum effort. Retransmission of Data and Status packets can be detected by a receiver via data retry indicators in the packet. A transmitter can reliably determine that its corresponding receiver has successfully accepted a transmitted packet by information returned in a handshake to the packet. The protocol allows for distinguishing a retransmitted packet from its original packet except for a control Setup packet. Setup packets may be retransmitted due to a transmission error; however, Setup packets cannot indicate that a packet is an original or a retried transmission.
The only transfer type without guaranteed delivery is isochronous. Also, the start of frame (SOF) packets don't have guaranteed delivery.
I am implementing USB as a host to read the contents of a FAT32 file system. The Endpoint descriptor returns me 0x81 as IN endpoint address and 0x02 for OUT EP.
I am implementing this using the OHCI. The Endpoint Descriptor in OHCI has a 4bit field for the Endpoint as shown by the 'EN' field-
So does this mean my endpoint address are 0x02 for OUT and 0x01 for IN? these are there endpoint numbers for sure.
I ask this because my Transfer Descriptor for accepeting data from the IN endpoint is failing and I am not able to figure out the reason yet.
As mentioned by Chris, it depends on the context and using 0x01 works !
I'm implementing USB on a PIC 18F2550 using a generic HID interface. I've set up the HID profile configuation to have a single 64 byte message for both inputs and outputs.
Now it's basically working. The device registers OK with windows. I can find it in my program on the PC and can send and receive data to it. The problem is this though - messages from the PC to the PIC are truncated to the size of the EP0 endpoint buffer.
Before I go debugging too much further I want to try to clarify my understanding of the USB protocols here and check I got it right.
Assume that the EP0 input buffer is 8 bytes. It's my understanding that the PC end will send a control packet which is 8 bytes. In there is the length in bytes of the data to follow. And then it will send a sequence of 8 byte data packets and the PIC end has to acknowledge each one.
It's my understanding that the PC end knows how big each packet may be by looking in the maximum packet size field in the device descriptor and will divide up the message accordingly into multiple data packets.
Before I go looking for more hours at the code, can anyone confirm that this is basically correct? That if the EP0 buffer size is 8 bytes then the PC should know this because of the configuration field I mentioned above and send multiple data packets?
If I make my receive buffer on the PIC 64 bytes then I get 64 bytes of the message which is sufficient for my needs, but I don't like not understanding why it doesn't work with small buffers, and one day I'll probably need them anyway.
Any advice or information would be welcome.
There is something called Endpoint Descriptor, which, among other things, defines the wMaxPacketSize - which is what the Host Controller Interface drivers use to subdivide a large USB transfer into smaller packets.
This is entirely different from the EP0 buffer size - which however, is always required to be larger than the wMaxPacketSize. My guess is (try posting your usb_config.h and usb_descriptors.c, if you use Microchip USB stack), that you're either trying to use 8-byte long EP0 with 64-byte long wMaxPacketSize, which is truncating the transfer.
Also, be aware that in USB 1.1 Low Speed, the wMaxPacketSize cannot exceed 8, and in USB 1.1 Full Speed it cannot exceed 64.
0x07,/*sizeof(USB_EP_DSC)*/
USB_DESCRIPTOR_ENDPOINT, //Endpoint Descriptor
HID_EP | _EP_IN, //EndpointAddress
_INTERRUPT, //Attributes
DESC_CONFIG_WORD(9), //size
0x01, //Interval
/* Endpoint Descriptor */
0x07,/*sizeof(USB_EP_DSC)*/
USB_DESCRIPTOR_ENDPOINT, //Endpoint Descriptor
HID_EP | _EP_OUT, //EndpointAddress
_INTERRUPT, //Attributes
DESC_CONFIG_WORD(9), //size
0x01 //Interval