Consider support for signal 11

[cnlohr]

This may provide driverless communication without drivers across platforms!!!

(Thank @xobs for that tidbit)

https://github.com/signal11/hidapi

[leopck]

Isn't HID already a support driver on all platform? Currently the espusb is supported on multiple platform right?

[cnlohr]

He mentioned in his talk that it allowed bi-directional communication, seems like could be a useful side-channel for driver-less, programmatic control.

[leopck]

bi-directional communication? does it use the control messages? or other means?

[cnlohr]

Looks like it can handle talking to descriptors and I'm guessing can talk to the stuff that talks to the descriptors, but... their 'hid_write' function is confusing. I know there's a world of standard HID USB that I don't understand, but it looks like they're literally calling the kernel 'write' command on the file descriptor, so, it likely will come in as a control message of some sort, so it should be able to be hooked into usb_handle_custom_control which would be really exciting!

[leopck]

yeah, looks like this would take some experimentation and playing around with. It does look promising for bi-directional communication... which most likely means that this would resolve the serial communication issue that we're trying to get it working right?

[cnlohr]

I think a real serial port would be "nice" but only because of the people who are emotionally tied to it. Personally, I really don't like serial except from the aspect of being able to get a serial debug terminal.

This would be much better because we could identify specific devices and upload to specific devices. Much better than "I don't know which one is ACM0? USB0?"

I don't think a solution like this will turn as many heads, but I think it a technically superior solution. I can't wait to see what the transfer rates will be like. If they're withing 80% of the raw control transfers, I can't imagine not using them.

[leopck]

Hmmm, I think this solution would be an eye-opener for lots of ppl as it did for me. But signal11 doesn't require any changes on the esp8266's codes right? The only modification needed is on the host side application am I getting this right?

[cnlohr]

I am not sure... But I do think it would be made easier by minor changes to usb.c. But it could be really good, like a specific hook to make it easier. Arrghh I won't be able to do any of this until after MAGFest :( I am seriously stoked.

[leopck]

Okay, now I think I'm confused. signal11 is a HID library which allows an application to interface with USB and Bluetooth HID-Class devices on Windows, Linux, FreeBSD, and Mac OS X

And you mentioned that minor changes to usb.c but isn't this modifying the device's source code? From what I understand, isn't signal11 meant for an application on Windows/Linux/Mac to 'talk' to the esp8266?

Also, thinking about it, even though we don't need a driver for this.... But we still have to install the HIDAPI application in order for us to 'talk' to the esp8266 by means of HID? Isn't this similar to installing a driver? (Although technically it's not a driver)

Sorry if I'm having a misunderstanding.

[leopck]

Oh wait, I think I just realized what you were referring to. You were referring to the changes made to the usb.c in order to achieve a bi-directional communication bcos currently we can't do bi-directional on espusb yet....

Alright, don't know what I was thinking just now... obviously my mind isn't concentrating properly

[xobs]

Neat project guys. I would have mentioned it in the talk if I knew about it!

The HID descriptor I use for bidirectional communication is https://github.com/xobs/joyboot/blob/master/rx_updater.c#L48

The Rust code I use for testing reads and writes is:

extern crate hidapi;
use hidapi::HidApi;
fn main() {

   let api = HidApi::new().expect("Failed to create API instance");
   let joystick = api.open(7119, 1486).expect("Failed to open device");
   let mut pkt_num = 0;
   let mut offset = 0u32;

    loop {
        let mut in_buf = [0u8; 9];
        let mut out_buf = [0u8; 9];

        out_buf[0] = 2;
        out_buf[1] = pkt_num;
        out_buf[2] = 5;

        out_buf[3] = 0;
        out_buf[4] = 1;

        out_buf[5] = (offset & 0xff) as u8;
        out_buf[6] = ((offset >> 8) & 0xff) as u8;
        out_buf[7] = ((offset >> 16) & 0xff) as u8;
        out_buf[8] = ((offset >> 24) & 0xff) as u8;

        match joystick.write(&mut out_buf[..]) {
            Ok(_) => (),//println!("Wrote {} bytes", write_res),
            Err(msg) => {println!("An error occurred while writing: {}", msg); continue},
        }

        match joystick.read_timeout(&mut in_buf[..], 1000) {
            Ok(res) if res == 0 => {println!("No data read"); continue; },
            Err(_) => {println!("Unknown error occurred when reading"); continue; },
            Ok(res) => {
                println!("Done with read, formatting {} bytes", res);
                let mut data_string = String::new();

                for u in &in_buf[..res] {
                    data_string.push_str(&(u.to_string() + "\t"));
                }

                println!("{}", data_string);

                pkt_num = pkt_num.wrapping_add(1);
            },
        }
    }
}

[probonopd]

In case you want to use this for esp8266/Arduino, don't forget that you need a way to select a port in the Arduino IDE for upload and serial monitor... and serial ones are the only ones that are working at this point. Which is why some people may be more than just emotionally tied to /dev/tty* devices.

[cnlohr]

@probonopd Oh yeah, now I remember the /real/ reason I left Arduinos long ago. face palm I think if we could convert it to the HID solution, I might actually use it - and I'll no longer have to live in the /dev/tty* nightmare.

@xobs what kinds of transfer speeds (in KBytes/sec) were you seeing with the HID transfers? Or was it limited to the awful <8kB/sec?

[xobs]

I haven't benchmarked it yet as I've only just now gotten reliable transfers. But the spec (section 5.7.4) mentions that "An endpoint for an interrupt pipe specifies its desired bus access period. A full-speed endpoint can specify a desired period from 1 ms to 255 ms. Low-speed endpoints are limited to specifying only 10 ms to 255 ms."

HID uses Interrupt endpoints, so you're limited to 10 ms as the minimum polling time, though many stacks will let you specify down to 1 ms. You'll have that limitation on any Interrupt endpoint, though.

Control endpoints don't seem to have a transfer limitation, so you may be able to get higher throughput through control transfers. Though then you're back into needing a driver on Windows, and you really should be formatting the control packets with the correct header.