Objective Development Forums

AVR-USB I/O

2007-11-11T12:37:12+02:00

Or look at the Automator project. It uses Windows HID functions to send and receive data and it contains an abstraction library based on Windows HID calls for Windows and libusb calls for Unix.

Statistics: Posted by christian — Sun Nov 11, 2007 12:37 pm

AVR-USB I/O

2007-11-11T07:40:10+02:00

Anonymous wrote:
christian wrote:If you need to send data to the device, I would recommend that you also encapsulate this in reports sent to the device, so that you can stay fully compliant with HID. See the Automator project for an example.

You don't need the interrupt-in endpoint. However, the HID specification demands that one exists. The host operating system may refuse to connect to the device if there is no interrupt-in endpoint.

And finally: Yes, you can poll for control messages from the host, of course. If you declare an endpoint as interrupt-in, the operating system's USB driver does the polling for you. This is usually more efficient in terms of CPU time used.

Thanks. I'm currently searching on the web regarding the HID side of things. I'm trying to figure out how to pull data from and put data to the
HID on the host side. It is transfering data on the scheduled times. but I'm not sure how to get at it or put data into it for the interupt_out.

I know I can do transfers, either control_in or control_out, but I'm not sure if that is how I'm supposed to get the data to and from the HID. I would imagine there is some pipes functions in the HID.dll, but I'm still searching.

Thanks again.

edit: The windows ddk has alot of examples of HID and USB functions.

Statistics: Posted by Guest — Sun Nov 11, 2007 7:40 am

AVR-USB I/O

2007-11-11T06:14:42+02:00

christian wrote:If you need to send data to the device, I would recommend that you also encapsulate this in reports sent to the device, so that you can stay fully compliant with HID. See the Automator project for an example.

You don't need the interrupt-in endpoint. However, the HID specification demands that one exists. The host operating system may refuse to connect to the device if there is no interrupt-in endpoint.

And finally: Yes, you can poll for control messages from the host, of course. If you declare an endpoint as interrupt-in, the operating system's USB driver does the polling for you. This is usually more efficient in terms of CPU time used.

Thanks. I'm currently searching on the web regarding the HID side of things. I'm trying to figure out how to pull data from and put data to the
HID on the host side. It is transfering data on the scheduled times. but I'm not sure how to get at it or put data into it for the interupt_out.

I know I can do transfers, either control_in or control_out, but I'm not sure if that is how I'm supposed to get the data to and from the HID. I would imagine there is some pipes functions in the HID.dll, but I'm still searching.

Thanks again.

Statistics: Posted by Guest — Sun Nov 11, 2007 6:14 am

AVR-USB I/O

2007-11-10T19:07:56+02:00

If you need to send data to the device, I would recommend that you also encapsulate this in reports sent to the device, so that you can stay fully compliant with HID. See the Automator project for an example.

You don't need the interrupt-in endpoint. However, the HID specification demands that one exists. The host operating system may refuse to connect to the device if there is no interrupt-in endpoint.

And finally: Yes, you can poll for control messages from the host, of course. If you declare an endpoint as interrupt-in, the operating system's USB driver does the polling for you. This is usually more efficient in terms of CPU time used.

Statistics: Posted by christian — Sat Nov 10, 2007 7:07 pm

AVR-USB I/O

2007-11-10T02:50:43+02:00

christian wrote:The technical description is correct. You can send control-in messages of up to 254 bytes. If your out-data fits into a setup package (one or two integers), then you can do the same as PowerSwitch and parse the data from setup. Otherwise you need a control-out transfer and implment usbFunctionWrite().

One thing is not entirely correct, though. When usbFunctionSetup() is called, you must return immediately and have reply data available. You can't wait until the encoder has incremented. However, you can poll for the encoder from the host side and return a zero increment if the encoder has not changed.

Christian, I've been working pretty hard trying to get this working and it appears that everything is working fine at this time. I have a routine that I wrote that reads a quadrature mechanical encoder and sends that value to the host via the HID report. This report just makes windows think that this is a joystick. The encoders just change the values of the axis information in the hid report at this time.

I'm also able to initialize these values by sending the atmega8 values via a control out message that is implemented in a form like what is being done with powerswitch. I'm able to initialize all 6 axis's to any value I want.

All of this really of no real use yet other than understanding how to send data back and forth from host ->device and device->host. I'm just about ready to implement all of the encoders to adjust radios and autopilot settings and the LCD displays for the radios and the autopilot heading, speed, altitude ect.

Durring my testing it would appear that I really don't need a interupt_in endpoint as I can send data both ways via a control message. Is this correct? If this is the case, is there a way on the host side to tell if a control message has been sent by the device? I'm using a modified version of the powerswitch program. Is there any callbacks or anything in the libusb driver that provides this type of functionality?

Anyway...thanks for all of your help.

edit: It just occured to me that I might be able to continuously poll for data from a control in via:

Code:

usb_control_msg(handle, USB_TYPE_VENDOR | USB_RECIP_DEVICE | USB_ENDPOINT_IN, PSCMD_GET, 0, 0, (char *)buffer, sizeof(buffer), 5000)

Is this true?

Statistics: Posted by Rukus — Sat Nov 10, 2007 2:50 am

AVR-USB I/O

2007-11-03T17:58:14+02:00

christian wrote:The technical description is correct. You can send control-in messages of up to 254 bytes. If your out-data fits into a setup package (one or two integers), then you can do the same as PowerSwitch and parse the data from setup. Otherwise you need a control-out transfer and implment usbFunctionWrite().

One thing is not entirely correct, though. When usbFunctionSetup() is called, you must return immediately and have reply data available. You can't wait until the encoder has incremented. However, you can poll for the encoder from the host side and return a zero increment if the encoder has not changed.

Well it appears that I'm learning something These examples are a big help as well as your posts. I appreciate you taking the time to help me along.

Thanks again.

Statistics: Posted by Guest — Sat Nov 03, 2007 5:58 pm

AVR-USB I/O

2007-11-03T17:05:40+02:00

The technical description is correct. You can send control-in messages of up to 254 bytes. If your out-data fits into a setup package (one or two integers), then you can do the same as PowerSwitch and parse the data from setup. Otherwise you need a control-out transfer and implment usbFunctionWrite().

One thing is not entirely correct, though. When usbFunctionSetup() is called, you must return immediately and have reply data available. You can't wait until the encoder has incremented. However, you can poll for the encoder from the host side and return a zero increment if the encoder has not changed.

Statistics: Posted by christian — Sat Nov 03, 2007 5:05 pm

AVR-USB I/O

2007-11-03T16:54:47+02:00

I've been studying Powerswitch. Correct me if I'm wrong:

avr program loops in main until it receives a USB Control message. The firmware driver calls usbFunctionSetup(uchar data[8]) and data contains
the usb command sent from powerswitch.

The usbFunctionSetup routine decides what command was sent by testing
the variable bRequest.

If it is a switchon or switchoff, it changes the output bits on its I/O, or if it
is a status request, it puts the status info into the reply buffer and returns a 2 value to the caller which indicates how many bytes to send back via the reply buffer?

If all of this is true, in my case I should be able to send a control message back to the host when one of the mechanical encoders has incremented or decremented the radio frequency. And then when the host gets it, it should be able to send a control message back to send the actual radio frequency to display via 7 segment displays?

How many bytes can I send as a control in or control out message?

This seems to do exactly what I want if I am understanding it correctly.

Thanks for your help and understanding. I'm a noob, but ya just gotta start somewhere

Statistics: Posted by Guest — Sat Nov 03, 2007 4:54 pm

AVR-USB I/O

2007-11-03T15:57:16+02:00

You need to install libusb-win32 and attach it to RemoteSensor's IDs. I'm not a Windows expert, so I don't have much experience with that, but the libusb-win32 package contains some instructions.

When I make software for Windows, I usually prefer HID because it saves me the extra driver.

Statistics: Posted by christian — Sat Nov 03, 2007 3:57 pm

AVR-USB I/O

2007-11-03T15:23:19+02:00

christian wrote:Yes, RemoteSensor needs its own driver since it's not based on HID.

HID is somewhat limited, you can't do generic control requests. All data must be transferred in fixed size structures which must be described to the operating system by means of Report Descriptors.

In spite of the limits, HID is suitable for what you want to do. Instead of triggering just a notification with the interrupt-in endpoint, you send the payload data. Output data is still sent with a control-out transfer, but it must adhere to the structure defined in the Report Descriptor.

Constructing the Report Descriptor is not always easy. Google finds many documents which describe how to do it. I would recommend that you have a look at Automator. Although it does not use the interrupt-in endpoint, it demonstrates how arbitrary data can be encapsulated in a descriptor without too much effort.

where is the driver for the host side of the Remote sensor project?
When the found device window pops up....what driver do I attach?

Statistics: Posted by Guest — Sat Nov 03, 2007 3:23 pm