usbd_setup_vendor

I am writing a usb driver on a board to talk to a sister board over usb-i2c. I have a hw module connecting the board to the sister board. The hw module translates the usb requests to i2c and vice versa. I am able to attach to the device successfully and need to start sending or receiving data. I am using the usbd_setup_vendor() to prepare the URB but unsure of how to use the request and value parameters.

#include <sys/usbdi.h>

int usbd_setup_vendor( struct usbd_urb *urb,
                       _uint32 flags,
                       _uint16 request, 
                       _uint16 rtype,
                       _uint16 value, 
                       _uint16 index,
                       void *addr, 
                       _uint32 len );

Also, how are these different from the “addr” parameter that I have seen in some examples as being used to hold the data? I need to send commands with data to the board to modify register values and was wondering which parameter to use. Any help is appreciated.

What specific commands does the HW module support (a reset? anything else? Or does it just support send/receive)? Those are what goes in the request/value fields.

The addr/len fields are for transferring blocks of data to the HW module.

Tim

Thanks for your reply. Please see my response.

What specific commands does the HW module support (a reset? anything else? Or does it just support send/receive)? Those are what goes in the request/value fields.
I am assuming that you are referring to the HW module as the piece that sits between the main board and the sister board. This HW module is just for converting
the USB to i2c. I am not aware of the commands that it supports. I am interested in setting/reading registers from the sister board using supported commands plus data. The sister
board supports reset, read/write etc.

The addr/len fields are for transferring blocks of data to the HW module.
My understanding is that the command and data that I need to send to the sister board need to be held in the “addr” field since this gets passed on to the sister board.
Is this understanding correct? If yes, what should the request/value fields hold?

Thanks

Tim,

Thanks for your reply. Please see my comments.

What specific commands does the HW module support (a reset? anything else? Or does it just support send/receive)? Those are what goes in the request/value fields.
To my knowledge, the HW module (sitting between the main and sister board) just passes the requests and replies bw the two boards, and does the usb to i2c conversion.

The addr/len fields are for transferring blocks of data to the HW module.
Since I need to send command and data to the sister board, I am assuming the “addr” field should hold both of them. In such a case, I am not sure what the value of the
“request” and “value” fields should be. Probably need to talk to the vendor that supplied the hw module and sister board?

Thanks

Yes, that’s what I meant.

You definitely should talk to that vendor. Ideally they have a Linux (or Windows) driver they can give you source code for to help you understand what you have to support.

I realize it seems like a simple matter to transmit/receive data but think about the following things: Does that HW board have any buffer (and how large is it) to hold data you want to transmit to your sister board or will you have to write 1 byte at a time? Can you check if that buffer is full? How does that HW board tell you there is data from your sister board (do you have to poll to see if there is data or does it send on it’s own via interrupt).

So there may be commands to support the following:
Is Buffer Full (checks if buffer is full / how much space remaining before you send data to the HW board)
Transmit (this would be when you’d fill out addr field with the data to be transmitted)
Reset (clears buffer? or resets I2C bus or something else)
Mode (set receive mode to polling or interrupt based sending)
Read Data (read data when in polling mode)

and so on. Here a link to a device similar to yours (USB-I2C) that talks about the commands their device supports

robot-electronics.co.uk/htm/usb_i2c_tech.htm

So you can see why there may be several commands supported even if they aren’t obvious.

Tim

P.S. Things would be a lot simpler if there was a Serial<->I2C adapter since you wouldn’t need to write a serial driver.

Thanks Tim.