Forum Rule: Always post complete source code & details to reproduce any issue!
Results 1 to 3 of 3

Thread: USBHost_t36 Auto detect

  1. #1
    Junior Member
    Join Date
    Apr 2018
    Location
    Netherlands
    Posts
    2

    USBHost_t36 Auto detect

    Hi all,

    I'm experimenting with creating a semi universal USB (host) to midi/cv converter with the teensy 3.6 with 4 port usb hub. The first thing I'm not sure how to approach is to detect if/what device is attached. Here are my questions:
    - Is it possible to do hot swapping of USB devices? (I did read something about this in the source code I thought).
    - Is it possible to autodetect what type, or even specific device is connected, and on what port (what function can give me this info if possible?).
    - Should I create all possible instances of USB devices up front, or is it possible to dynamically create them upon connect?

    The idea I'm working on is to give each usb device a couple of "apps" that translate the received data into generic midi or cv.
    For example:
    A Launchpad is connected and detected by the teensy 3.6 > choose a (launchpad specific) app - step-sequencer, mixer, synth, etc > app does it's work. Repeat for all attached USB devices.

    Thx for the great work on Teensy and support on this forum!

  2. #2
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    5,299
    I can somewhat answer some of these questions, but maybe not all.

    Yes you can hot swap USB devices. Hopefully most/all of the time. Some of the devices may not have 100% proper release code so reusing could be issues. I try to resolve these as I see them.

    Note however I have not touched any the MIDI stuff so those parts I can not answer.

    Can you detect when devices come and go? Yes - Currently mainly only be polling. It has been suggested that it would be nice to have some form of callback function for it, but I don't think that is done yet...

    How can you query them? Actually there are several examples showing this in the example code: For example with the latest version of the library, I believe there is an example called: Mouse_KeyboardBT (under bluetooth).

    In this example I actually keep three lists of objects, which include:

    Code:
    USBDriver *drivers[] = {&hub1, &hub2, &keyboard1, &bluet, &hid1, &hid2, &hid3, &hid4, &hid5};
    
    #define CNT_DEVICES (sizeof(drivers)/sizeof(drivers[0]))
    const char * driver_names[CNT_DEVICES] = {"Hub1", "Hub2", "KB1", "Bluet", "HID1" , "HID2", "HID3", "HID4", "HID5"};
    
    bool driver_active[CNT_DEVICES] = {false, false, false, false};
    
    // Lets also look at HID Input devices
    USBHIDInput *hiddrivers[] = {&mouse1};
    
    #define CNT_HIDDEVICES (sizeof(hiddrivers)/sizeof(hiddrivers[0]))
    const char * hid_driver_names[CNT_HIDDEVICES] = {"Mouse1"};
    
    bool hid_driver_active[CNT_HIDDEVICES] = {false};
    
    BTHIDInput *bthiddrivers[] = {&keyboard1, &mouse1};
    #define CNT_BTHIDDEVICES (sizeof(bthiddrivers)/sizeof(bthiddrivers[0]))
    const char * bthid_driver_names[CNT_BTHIDDEVICES] = {"Keyboard(BT)", "Mouse(BT)"};
    bool bthid_driver_active[CNT_BTHIDDEVICES] = {false};
    Why 3 sets? First main set is for top level USB objects which are the whole device, like a HUB, or in some cases a Keyboard, and HID parsers, more on that later. So you can directly see if a device is connected by doing something like: if (Keyboard1) {
    It will be true if keyboard1 is connected and false if it is not.

    Second list is those devices which are HID (Human Interface Device), where you need a HID parser object, who then parses the HID information. Some examples of this are Mouse, or Some Keyboards or Joysticks... And third is like HID, but it is specific to Bluetooth objects...

    The main reason I mention the three sets is if for example if you connect a Keyboard by Bluetooth for example:
    doing: if (Keyboard1) ...
    Will return TRUE, but doing if (drivers[2]) which is the keyboard one will return false, as it is not connected at the USBDriver level but instead at the BTHIIDInput level...

    Currently the list of objects is static. I have at times thought of maybe adding some call out function(s) when we detect a new device connecting. Not sure if best as first thing or only if system does not find a match, but then maybe this call back could create or register other objects... But again this has not been done.

    Hope that helps (a little)

  3. #3
    Junior Member
    Join Date
    Apr 2018
    Location
    Netherlands
    Posts
    2
    Thank you for the fast and detailed reply, it clarifies some of my questions.

    It would indeed be very helpful to have callback functions instead of polling. Especially if it could give info back on the device being connected.

    if (Keyboard1) returns a boolean, do you also know if/how I can get more info about the usb device, so I can check if a specific device is connected?

    Sorry if it is already described somewhere, I find it difficult to find the info as it is a bit scattered.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •