Is there a USB in this MK?

Not all yogurts are equally beneficial.

Until wireless technologies finally won, USB (U) became (or is about to become) the most frequently used interface in microcontroller devices (MK) and surely occupies the niche of a standard communication device, displacing the UART. Let's not forget that at the moment in the most well-known and widespread series of motherboards based on the MC - Arduino - even the UART itself is implemented through a converter from the U interface, and in some advanced versions the converter is implemented on the MC itself. So, the presence of a U module in an MK becomes one of the criteria for choosing a specific device from a variety of options. Unfortunately, it is impossible to just look at the table in the documentation and make sure that there is a plus in the corresponding row. Consider some features of the interface in terms of functionality.

First of all, Yu has three options for execution of 1, 2 and (who would have thought) 3, as well as version versions.
Option 1 supports low speed (LS = 1.5 MB) and full speed (FS = 12 MB), and low speed can be implemented in hardware on any MC with 2 digital ports, a clock frequency of 10 MHz and one interrupt of these legs (the latter requirement can be removed under certain restrictions on the application program). The topic is more than a tattered one and is mentioned only in order to emphasize the author's erudition. Therefore, it can be said with confidence that almost every MC has onboard U of the first version in LS mode and the topic is closed (there is one feature, but about it later).

Option 2 also supports high speed (HS = 480 MB), but the implementation of such devices in the MC is still not very common, especially in terms of the physical (PHY) interface, so it is not relevant yet and will not be discussed further (please disagree with the comments) . So we can focus on the features of the FS mode.

I don’t see much point in considering option 3, since it is not intended for the MK, the performance requirements are too high, and its hardware features are still hidden in the external transceiver (which is also true for most HS implementations).
')
So, what pitfalls can be hidden in the MC, for which we are sure that it has PHY USB FS Device, as it is written in the documentation, which (stones) can become an obstacle in the implementation of the requirements for our device.

First of all, these are termination resistors (here it is a feature). As is known, the presence of a resistor on one of the data lines is a sign of the speeds supported by the device, but at the same time a sign of connecting the device to the bus. Therefore, if the selected MK has no internal termination resistors (in modern MKs it is unlikely, but this has happened before, especially when implementing LS devices on ports), you will not be able to initialize the process of re-connecting the device by disconnecting the resistor from the data line. Of course, such an opportunity may not be necessary, but it should be remembered.

The requirements of compliance with the standards will be considered fulfilled if there is an U icon for the concern on the device, although I personally would not have hoped for it. There was a very specific situation when the analyzer reported on single packets in the middle of the line, although the device functioned normally and the matter was clearly in the inconsistency of the levels. Well, this parameter cannot be influenced in any way, because nobody writes in the documentation about partial compliance with the standard.

And now really interesting things begin, which we can read in the documentation. First of all, this is the number of end points (OT), since it is this parameter that directly determines the implemented functionality. Well, first of all, without zero OT, the device will not work at all, so its presence is not discussed. I did not find an indication that the zero OT can be used for any other purposes, except for configuring the device when it is turned on, if anyone has other information, share it.
Therefore, we need exactly more than one OT, the nearest integer 2, but still they are made at least 4. Why - because the simplest devices use one OT to control, and the second (and third) to transmit data, that's just 4 and it turned out. This amount is quite enough for the implementation of almost any U device, but only until you need to create a combination device. This is where the ambush exists - unfortunately, it is impossible to use one OT for the implementation of various functions.
Here you can create a combined HID device as you like, all reports can be sent to the host one by one from OT, and one by one from the transfer of reports and data from the mass memory is no longer possible. Therefore, the number of OTs (and this parameter is determined by the hardware and cannot be increased programmatically, although there are options) is a serious limitation in the design of combined devices.

The next important detail is the OT parameters, namely the size of the buffer for the data, the possibility of coupling the buffers, and the ability to work on receiving and transmitting simultaneously. Let's start with the last - for full duplex transmission one by one, you need to have separate readiness flags for reading and writing (in principle this requirement can be bypassed programmatically with certain host requirements) and separate receive and transmission buffers (and there’s nothing to do they are really needed). If such requirements in this MK are met, then the number of OTs doubles, as it were, and this facilitates the construction of combined devices.

The next important parameter is the size of the OT memory buffer, since the maximum data packet size directly depends on it. Again, this parameter is not so important for HID devices, but for data transmission devices it can limit the bandwidth in a very significant way. The presence of more than one buffer for one direction of transmission of one OT to organize the switching of buffers is directly related to bandwidth. An important parameter to ensure maximum throughput is the ability of the Yu controller to work with the PDU MK mechanism.

As you can see, the above requirements for the implementation of Yu in the MC are reduced to two groups - speed and functionality. And if nothing can be done with speed, and it is tightly limited by hardware capabilities (another question is that inaccurate writing of the driver can limit these possibilities even more - see specific implementations), then from the point of view of the functional there is one absolutely charming trick that allows making devices of unlimited functionality .
This trick is to implement a pseudo-hub, since in this case you can imagine a combination device as a set of devices connected to the hub and thereby remove all restrictions on the number and type of OT. Of course, this will require careful programming and does not represent a trivial task, but, nevertheless, it is completely realizable. However, for this option there is a categorical requirement for the U interface - the ability to receive packets with any address, that is, the ability to disable the address filter, which is not realized in every MC.

I summarize all of the above, you can say that if you plan to create a relatively simple U device (HID), then the plus in the description of the MC in the corresponding line is enough, but if you plan a combined heterogeneous device, or a device with intensive data transmission, you should be very careful read the specification of the UU controller selectable MK to avoid unpleasant disappointments.

As the reader probably understands, this post is the result of walking on a rake, so a small practical recommendation, created as a result of a very specific project - the use of Milander’s MK to implement the devices described in the previous paragraph cannot be recommended. The MKs themselves are not bad at all, but here’s the U interface implemented in them with very limited capabilities. But the STM-ny MK with this task completely coped, it is felt that the experience of the developers of the U interface at this company is very large (or maybe a good license is purchased).