Composite USB device driver implementation for STM32F2 (Photon/Electron/P1)

[avtolstoy]

By default Photon/Electron and P1 now present themselves as a composite USB device with two USB Serials, Serial being the first and a new USBSerial1 being the second one. This should work out of the box on Linux and Mac, Windows users will have to reinstall serial drivers. (This PR includes UNSIGNED drivers in misc/driver/windows, see 9b62479).

This PR also implements HID support (closes #528). Calling Mouse.begin() or Keyboard.begin() will register HID class driver in Composite driver and cause the device to perform a reattach. After successfully attaching, the device will present itself as a composite USB device with two USB Serials + HID.

A very simple test app that showcases the new functionality can be found at https://gist.github.com/avtolstoy/996cb3bb174337744094

---

Doneness:

• Contributor has signed CLA
• Problem and Solution clearly stated
• Code peer reviewed
• API tests compiled
• Run unit/integration/application tests on device
• Add documentation (N/A)
• Add to CHANGELOG.md after merging (add links to docs and issues)

[ScruffR]

Nice to see things coming together 👍

Just a question of ignorance ;-)
What is the purpose of a second serial that can't be achieved with a single one?

But more importantly for me: Will a composite CRC + Mouse + Keyboard be possible with this too?
It's the "or" in this sentence

Calling Mouse.begin() *or* Keyboard.begin() will register HID class driver

[avtolstoy]

@ScruffR I'm sure there could be numerous applications for a second USB serial. One of the use cases envisioned is providing easy access to possibly verbose debug logs without interfering with application utilizing Serial.

As for Mouse/Keyboard, the linked example showcases exactly that. The device will run 3 USB classes in total: 2 instances of CDC (Serial) and one instance of HID (implementing both Mouse and Keyboard).

[ScruffR]

Thanks for the clarification 👍

So I was just taking the "or" as "mutually exclusive or" rather than "and/or" - good to know.

Any idea in what version we might see this public?

[avtolstoy]

In order not to break compatibility with tools that work with USB serial, the default behavior has been changed. The device will enable only Serial on boot (and of course only if START_DFU_FLASHER_SERIAL_SPEED or START_YMODEM_FLASHER_SERIAL_SPEED have been set during build).

Since the bootloader has been removed from system-part2 on Electron (404ceb8), this PR now doesn't overflow system-part2.

Another caveat on Electron and P1: Electron and P1 use PA11 and PA12 for USB which are connected to USB FS core, unlike Photon, which uses PB14 and PB15 which are connected to USB HS core used in FS mode. Using USB HS core allows to use up to 5 bidirectional endpoints (5 in and 5 out), however USB FS core allows only 3 (3 in and 3 out) which puts a bit of a limitation and allows only either Serial + USBSerial1 or Serial + HID operation on Electron and P1. @technobly, you were right about FS pins, I should have checked more carefully :)

[avtolstoy]

This should be ready for a review, but I would like to get #959 merged into develop first to safely enable USB drivers logging.

Considerations for testing:

• Serial
• Serial + USBSerial1 (All)
• Serial + USBSerial1 + Mouse/Keyboard (All)
• Serial + Mouse/Keyboard (All)
• SerialLogHandler / USBSerial1LogHandler
• Application built for older firmware version
• Custom acquireSerialBuffer and acquireUSBSerial1Buffer
• New windows drivers (unsigned: https://github.com/avtolstoy/particle-drivers/releases)
• Compatibility with preinstalled "old" Windows drivers (https://community.spark.io/t/installing-the-usb-driver-on-windows-serial-debugging/882) when running with only Serial enabled (default).

[m-mcgowan]

I guess the rationale is that the baudrate doesn't actually affect the transfer, and is only "virtual" in the linerate descriptor?

[avtolstoy]

That is correct.

[ScruffR]

I seem to be unable to get Keyboard/Mouse to work on my Electron

char str[64];

void setup()
{
    Particle.function("type", kbdType);
    Particle.function("move", mouseMove);

    Serial.begin(115200);
    //Serial.end();
    Keyboard.begin();
    Mouse.begin();
}

void loop()
{
    static uint32_t ms;
    if (strlen(str) && millis() - ms > 1000)
    {
      ms = millis();
      Keyboard.print(str);
    }
}

int kbdType(String cmd)
{
    strcpy(str, cmd);
    Serial.println(str);
    return cmd.length();
}

int mouseMove(String cmd)
{
    int x = 0;
    int y = 0; 
    int b = 0;

    sscanf(cmd, "%d,%d,%d", &x, &y, &b);
    Serial.printlnf("%s: %4d / %4d (%d)", (const char*)cmd, x, y, b);
    Mouse.move(x, y, b);
    return cmd.length();
}

This is the status of my device

C:\Users\Andy>particle serial inspect
Platform: 10 - Electron
Modules
  Bootloader module #0 - version 6, main location, 16384 bytes max size
    Integrity: PASS
    Address Range: PASS
    Platform: PASS
    Dependencies: PASS
  System module #1 - version 100, main location, 131072 bytes max size
    Integrity: PASS
    Address Range: PASS
    Platform: PASS
    Dependencies: PASS
      System module #3 - version 100
  System module #2 - version 100, main location, 131072 bytes max size
    Integrity: PASS
    Address Range: PASS
    Platform: PASS
    Dependencies: PASS
      System module #1 - version 100
  System module #3 - version 100, main location, 131072 bytes max size
    Integrity: PASS
    Address Range: PASS
    Platform: PASS
    Dependencies: PASS
  User module #1 - version 4, main location, 131072 bytes max size
    UUID: 129AC6D385FF43EAFCDDEA84547CA5C2F26219AFC0E1DEFD39344A367A3DBE9B
    Integrity: PASS
    Address Range: PASS
    Platform: PASS
    Dependencies: PASS
      System module #2 - version 100
  empty - factory location, 131072 bytes max size

[ScruffR]

It would also be nice if there was an absolute Mouse.moveTo() like on the Teensys
https://forum.pjrc.com/threads/17218-USB-Mouse-Absolute-Coordinates?p=35546&viewfull=1#post35546