I'm about to start a USB project. New to me with STM.
I am using an STM32L476RG on a Nucleo board. (Yes we're cheap). I see LOTS of opportunity for myself. Lots of GOOD and LOTS of UNKNOWN. The LOTS of UNKNOWN can easily go BAD based on my experience. I'd like to avoid that if possible.
I'm willing to do a lot of work. Probably what it will take anyway. I like learning. But I'm just listing some observations and possible pathway steps I might take here and would appreciate any nudges, encouragement, discouragment, suggestions that might make the UNKNOWN not go BAD... Try not to point and giggle though.. :-/
1. The Nucleo doesn't have a USB connector on it DIRECTLY to the STM32L476RG. (PA11-44 and 12-45). It DOES have one to the STLINK STM32F103 on the debug board. THAT USB hole culminates in a serial connection to the 476 for debug ( and a sneaky VCP to the F103 ) via a USART on the 476. Right?
2. Nothing stopping me adding a good old fashioned USB B type connector to the Nucleo header pins for the DP, DM, USB power sense and ground other than maybe a little worry about those finicky transmission line wiggles that the sub ideal connection means might induce into the signals. Right? (Okay I'll keep em short. No 1 foot wire wrap wire jumpers.)
3. Should be able to get this
example application running AFTER I go and get the later CUBE version which is now 1.5 Right?
4. I don't necessarily want a VCP driver to launch on the PC when I plug my device in. But THIS CDC example code probably will do that. Right?
5. The USB - HID device example will show up as HID device when plugged in.
Right? (remember - no giggling)
6. Devices that require a custom or specific driver to be launched when plugged in, are trigered to do so by specific information from the device when it is plugged in, during enumeration / discovery. (Descriptors)
7. The first thing a USB device gets hit with when it is plugged into a HOST USB port is a RESET signal from the HOST. This causes some esablished standard communication protocols to kick off from a known starting point so everybody gets on the right page to start with.
8. Just my AT-A-GLANCE -
I kind of half suspect that ALL this USB stuff will be a nearly an exact outer operational framework as I have seen in getting and embedded Ethernet solution running. Not the DATA / ICD formats or anything but just the concept. Like for The embedded Ethernet code – there is a BUNCH of lines of code that gets ran ONCE to set the thing up. Then you set around waiting for a CONNECTION interrupt and that runs a BUNCH of OTHER lines. THEN you just sit around and wait for an I GOT SOMETHING! interrupt and grab data or you load up a buffer and punch the driver in the nose to transmit it. Lastly there a DISCONNECT to handle also. Another BUNCH of lines of code.
I'm looking forward to diving into this. The rest of my STM experience has went really well.