Need 3 cost effective USB ports

Many f the F4 and F7 series offer 2 USB interfaces, one "device only" and the other "USB OTG" (device or host).

Check out tunyusb https://github.com/hathach/tinyusb . They claim to have host mode with support for hubs. I haven't used this yet, but others on this forum refer to it often when people hit issues with ST's implementation.

STM32M1 ??? Do y ou mean the STM32MP1? That is an entirely different beast. Dual A-something and M-something CPUs, with Linux running on the A CPU.

> Many f the F4 and F7 series offer 2 USB interfaces, one "device only" and the other "USB OTG" (device or host).

Wherever 2 USB interfaces are present, both are OTG.

The difference is, that only one of them is HS-capable (wich external PHY, except the 'F723/730).

JW

Thanks. @Bob S​ , I looked at that tinyusb link. The support table at this link shows very, very few devices with USB host support at all. And it doesn't mention if those support hubs. I was thinking about PORTING a working usb host version (such as for NXP, Raspberry Pi, or Renesas: the only three supported) over to STM32F2 series. But does it really support hubs on those? I'm very skilled, but how much time would that port and test take me? INDEED I need to go do more research about tinyusb supporting hubs and the possibility of STM32F2 support (STM32F207VCT7).

I need to learn more about this external PHY stuff. I've never heard of having the PHY external...

The problem with USB hubs in STM32 is twofold:

• bug in the built-in FS PHY which prevents connecting LS devices behind hub
• the USB host related Cube software is not written with supporting a device tree in mind

> how much time would that port and test take me?

What a weird question.

JW

@Community member​ , is that bug in built-in FS PHY a HARDWARE bug, or a FIRMWARE bug? In reality, I haven't really paid much attention to USB speed. Might it be that some USB thumb drives worked through the hub and some didn't? I might be able to live with that in the product. I really don't know which speed(s) is(are) USB thumb drives! A quick search yielded no good results: "HS" and "LS" are two short. I think I'm getting better search results with "High Speed" and "Low Speed". This link seems promising. So, @Community member​ , if I can find and restrict usage to only HS usb flash drives, might the STM32F2 with CubeMX (HAL) library be able to use a pair of HS usb flash drives through a hub chip? I'm already using a hub chip USB2422T/MJ for other purposes. ***OK, I just re-read your response. The CubeMX isn't going to support the device tree period, anyway.*** I'll leave my paragraph here anyway.

So it sounds like I simply *must* abandon the CubeMX, at least for the USB support. Then the question above remains about HS usb flash drives. Might they work even with the built-in FS PHY.

Then comes the external PHY question. If external PHY is just a simple chip to add to get past a problem, then I need to figure out (or be told, thank you very much, not LOL) what this external PHY chip is. I do have decades of experience, just NOT with this stuff.

LOL, you think asking how long is a weird question. I'm just trying to get an idea for degree of complexity. I don't know how else to phrase it, other than as I just did.

> is that bug in built-in FS PHY a HARDWARE bug, or a FIRMWARE bug?

Hardware.

> A quick search yielded no good results: "HS" and "LS" are two short.

If you had to look them up, then your starting point with USB is rock bottom. No offence.

> Then the question above remains about HS usb flash drives. Might they work even with the built-in FS PHY.

Again USB 101 (more precisely, USB 2.0, the specification), which says, that all HS devices must support FS, but then they don't need to have the same functionality at both speeds. However, the USB FLASH drive would gain absolutely nothing from not supporting the same functionality at both speeds (only devices with isochronous transfer e.g. sound- or video-related devices would need to have different treatment of both speeds), so I believe there are very few if any thumbdrives out there which wouldn't work at FS.

But - and that's the "but" which will follow you all the journey with USB - there's more to "USB drive" than just some basic packets for setup and then pure data. The USB Mass storage class is nothing else but a thin veil on SCSI. How well familiar are you with that? OK, the vast majority of drives out there implement a very limited subset of SCSI, you can simply look up any implementation on the net and copypaste the two or three commands needed. But there's no guarantee that it will be as simple as that - and indeed, I came across one drive (of a dozen or two which was my random testing group, gathered from colleagues and friends) which was weirder than that.

And then there's another "but" (I promised, see). SCSI is only the "data" layer. On top of that you have disk partitioning. There are quite a couple of them. Yes, again, most are simple MBR, but again I came across GUID - and it was a "built-in" one which "came with the drive", without knowledge of its owner (as it "worked usually" on all major OS). Are you ready to be screamed at by customers for not supporting a drive which "works as usually" on his PCs?

Oh and then there's the "but" of the filesystem...

And the "but" of weird device-level implementations, like a dual-device thumbdrive with embedded hub (because of it being a "security" thumbdrive with built-in fingerprint reader). And blasts from the past - U3 drives, anyone?

But let's just get back to USB itself. So, you are ready to work with a protocol you don't know the basics of, documented in a 650-pages long document (only basic USB + hub, without the mass-storage class) with historical layers and consequences; implemented in an incredibly complex hardware IP with its own historical layers, which comes with incredibly crappy documentation, with nobody to consult in case of doubts.

No, I'm not trying to discourage you, despite of how that sounded - just trying to point out that there may be some pitfalls ahead.

And that's why asking how long *is* a weird question.

JW

@Community member​ , LOL, no offense taken regardless, but I didn't mean I was looking up "HS" and "LS" themselves. I meant looking up whether or not thumb drives were HS or LS. It never occurred to me before today to worry about that question for thumb drives. I did find some stuff about thumb drives being High Speed or Low Speed (or Full Speed). Therefore, I meant that looking up "USB thumb drive LS vs HS" or something like that, the "LS vs HS" part is not specific enough. Putting in the full length meaning of LS vs HS helped on the search.

Yes, I've known of SCSI for decades. I've also known of USB Mass Storage Class for a long time. No, I didn't know USB Mass Storage device was thinly veiled SCSI. Yes, I've worked a little with MBR and GUID. Yes, various FAT. I hear you about screaming customers.

LOL, I know there are lots of pitfalls. I would categorize my USB specific knowledge at at least 25%. I would categorize my long term ability at 99%, and my "black box" ability at 99%. I'm excellent at migrating working systems from one place to another. Do I *want* to do it, NO, LOL!

Yes, crappy doc? Seen that day in and day out, beginning with [EDIT] MFC in the, what 90's? Or was it 80's? Can't remember. Don't want to. Crappy doc? CubeMX and the HAL libraries!

Still, I think if tinyusb works for one platform, it MIGHT work for another and not be too difficult to port. Do I want to do that port personally, right now? No, I don't. I have the skill, but not the desire. I want to set it up for one of my two successors to do. Do they have the skill? The time? The desire? I was looking for an order to difficulty. The difficulty you described is nothing new sounding to me. The "unknowns" of course, are the rub. And the possibility of an impossible-to-fix dead end is the worst.

Finally, just because the spec says something should work doesn't mean that it does. Thus, for example, perhaps a bug you mentioned in the very beginning.

Anyway, I appreciate your assistance this time and in the past, and in the future as well, I hope.. I know a lot more than your recent misunderstanding of what I wrote. But I know there's a lot more I don't know, even though I probably know more than most. And the things I don't know I don't know are what I'm trying to noodle through right now. (There are various slightly inconsistent phrasings of the levels of ignorance, so I can't give a good corresponding link right now.) Bottom line, I haven't found any improvement whatsoever in reducing the risk of following a single of many possible specific paths forward. (Unknown unknown = risk) That's not your fault or mine. Maybe a successor will find something. Otherwise, the answer for the customer is going to be a much higher cost in both money and time!...

Which reminds me. A long time ago an ex air force guy taught me: "Good, Fast, or Cheap... Pick any Two." My current client wants all three. That client also knew that old ex air force guy...

@Community member​ Define "cost effective"? Low cost of development/shorter time to market or low cost of parts?

> My current client wants all three.

Not going to happen. But they can dream... unless they sleep at work.

"Yes", LOL. either/both. Actually, I guess I really meant parts cost. Well, no, I actually meant also shorter development time. Either. Rather a $10 MCU than a $20 MCU. Rather have libraries that work and thus shorter development time/cost. Been doing microprocessors for four decades, but very little with USB. So too many unknowns for me right now!

You can use two mcus, one say 'F2 to handle the two hosts, and an other, say the 'F1, to handle the device.

There are also commercial USB stacks offerings out there, I'm quite sure they include hubs handling.

There may be also other open-source implementations.

It may be possible to adopt the Cube code, I don't know it that well and it may have evolved since I last looked at it (and was not impressed).

JW