1

Is it possible to implement a host on stm32 (without hardware support) with only the program code to write data to the USB flash drive? I did not find any information on the Internet on this issue. There is an implementation device, but not a host. I'm studying the usb specification for the answer, but I still do not understand well her.

никита богатов
  • 11
  • 1
  • 1
    There are hundreds of different STM32's – Eugene Sh. Feb 26 '18 at 18:28
  • do you mean USB host? and you want to boot that with no special frimware on the STM32? – Jasen Слава Україні Feb 26 '18 at 18:50
  • @EugeneSh. Yes, but I have one that does not have hardware support – никита богатов Feb 26 '18 at 19:18
  • what is "hardware support"? – Marcus Müller Feb 26 '18 at 19:18
  • @Jasen Yeah, i mean USB host. Perhaps with limited capabilities, since I only need to write to a USB drive. – никита богатов Feb 26 '18 at 19:21
  • "hardware support" would be the USB OTG (or at least USB device) peripheral block. And no, this is not a sensible project - just get an STM32 that has the OTG port; that feature is offered in everything down to the M0s, including TQFP packages which are easy to work with. Or use an SDCARD in SPI or bit-bang mode on even the most primitive, instead of USB. – Chris Stratton Feb 26 '18 at 19:21
  • @MarcusMüller I mean that the exchange function already exists inside the microcontroller on a logical level and the registers – никита богатов Feb 26 '18 at 19:22
  • @ChrisStratton I understand that this is not reasonable, because I did not see anyone doing it. But the answer to the question "why?" Was not found. – никита богатов Feb 26 '18 at 19:24
  • Because bit-banging USB is at the cutting edge of possibility; and typically the device-side implementation depends on the host being regular while it cuts corners. I did hear about someone doing it on a propellor, but that's an odd chip. Ultimately, the biggest argument is that you'd have to be making *huge* production quantities before this would be worth the trouble to attempt. – Chris Stratton Feb 26 '18 at 19:26
  • @ChrisStratton fully agreeing; it'll be pretty much impossible to also handle a full file system while doing https://fahrplan.events.ccc.de/congress/2016/Fahrplan/events/8031.html – Marcus Müller Feb 26 '18 at 19:48
  • The file system probably isn't really a problem at all - that part can be done as painfully slowly as necessary, it's really just about storing and advancing state. – Chris Stratton Feb 26 '18 at 19:54
  • @ChrisStratton well, if you need to tailor all your firmware just to barely meet timing of the bus you're driving, how are you still exchanging data? (My choice of wording was unfortunate: I didn't mean the file system as data structure, but the fact that someone has to handle the data whilst still dealing with USB) – Marcus Müller Feb 26 '18 at 21:10

1 Answers1

3

Why the host function can't be implemented with device-only hardware? Because the USB is not symmetrical with regard to host and devices.

On the device side the USB function is to support basic USB protocol called "SIE", Serial Interface Engine. This engine includes device ability to RECEIVE host requests, starting with "default pipe", and respond properly with getting data with ACK response, or sending data and waiting for host ACK to complete transactions. Because of USB timing limitations (1.7us response time), the final stage of control transaction can't be implemented by software means, and most parts of device SIE engines are hardware-encoded. Other functions of SIE are to accept address assignment, and accept/enable configuration, which concludes the enumeration phase of USB attach protocol. Then the SIE supports basic IN/OUT/other pipes, within the same protocol constraints. In short, the device function is to RESPOND.

Because of these hardware limitations, it is impossible to use the device engine for host function, mainly because the host functions are entirely opposite to the device functions. The bus handling follows very different state machines. The host must GENERATE periodic frame packets, and INITIATE all transactions. And then provide smooth stream of data, all usually done using Direct Memory Access hardware. The host must provide port power function, and port reset function, which is not there in device implementations.

These are major reasons why MCU are designed with separate host hardware and device hardware controllers.

Ale..chenski
  • 38,845
  • 3
  • 38
  • 103
  • Not to mention that I'd actually be thrilled if someone was even just on a physical layer able to bitbang out FS USB with a cheapo STM32 – it's not like you can use LS to talk a mass storage device, can you? And doing LS (device) on a Cortex-M is only barely possible in software, even with a lot of good will on the host side. – Marcus Müller Feb 26 '18 at 21:12
  • @MarcusMüller, if you have external USB PHY over UTMI/ULPI, it could be possible to make a FS host using BYTE-banging, if you have direct access to UTMI port. Which you don't usually have. You can do some FPGA wrapper though. And yes, there is no mass storage at LS speeds. – Ale..chenski Feb 26 '18 at 22:41
  • yeah, but adding an FPGA just so you don't have to buy an MCU that either comes with UTMI access or actual dedicated host controller hardware would be... a surprising move, to say the least. Not to mention the fact that the amount of bare intelligence needed to handle a potentially \$2^7\$-device bus of mixed devices might just be a bit more intense than what a "dumb" device needs to be able to do. – Marcus Müller Feb 26 '18 at 22:48