USB host on Pico- do we need a host controller chip ?

hi,
I am trying to input data to a pico from a USB barcode reader (in either HID or virtual com mode).
OTG is not required , USB would be a dedicated input.
Happy to dig deeper and get a logic analyser on the case but USB low level signalling is a new world for me. Searching the forums :

• Ive been able to move the repl to serial so that I can use the USB for connecting to the reader. And separate power supply sorted so not required to power via USB.
  
• I now understand that a straight USB.on("data" , function(d){...}) doesn’t respond to USB peripheral input.
  
• ive seen the forum answer that host mode is not supported. http://forum.espruino.com/conversations/­284427/
  
• Ive seen the threads that use an external USB controller shield. http://forum.espruino.com/conversations/­332374/#comment14698591
  https://www.hackster.io/gerrit-niezen/ad­ding-usb-host-support-to-espruino-2c494d­
  
• and I can see there is HID support to use the pico to send to a host.
  
  

So my questions here are:

• has anything moved on since the above conversations with USB peripheral input to the pico?
  
• is there any way forward to ustilise the USB host functionality of the STM32F401xD ?
  
• is an additional host controller chip/shield the only practical way to crack this? Seems a really unnecessary overhead if the STM.. can handle the host interface.
  
  

and any suggestions on investigations I could do to move this forward appreciated.

Thanks in Advance
Simon

Hi Simon,

I'm afraid nothing has progressed on USB Host. While possible with the hardware (although I think most implementations add some kind of USB switch device?) there'd be a lot of software work required in Espruino, and that hasn't been done.

So I think your main options would be:

• There is a MicroPython port for the Pico (I'm not sure how old it is) and that may support USB Host - at least MicroPython supports it on their own boards.
  
• You could write the code you need in C using ST's libraries - depending on what you're after and if there's an example already that may actually be the easiest option
  
• There's the external shield option - but that could still be a decent amount of work
  
  

Sorry to not have better news!

Thanks Gordon,
Thanks for the confirmation and the clear options. I’ve been doing some more googling and checked out the libraries and stm32 reference docs. I think it’s possible but I have to say it looks incredible complex.
On a general point this https://youtu.be/4FOkJLp_PUw
is a great youtube tutorial with stm32 that shows the logic analyser techniques (and effort ) it might take to debug such a development.

I’ll investigate a bit more , Signed up to Udemy course on interfaces in embedded c, for stm32 !!! but no promises.

Out of interest , and maybe mid term answer to my problem, have you decided if, the new Espruino Wi-fi Board might support USB host ! Or use hardware that could. ? If one was going to invest time in this maybe it be better spent that way.

Thanks again for considered response.
And Happy new year.

I'm pretty sure the new Wifi won't support USB Host I'm afraid - it'll be using the nRF52840 which supports device only :(

Indeed :(
But that’s good to know in any event.
PICO it is then.
Will let the forum know how I get on, in the c driver, usb host , stm library world !

Hi,
Quick status, having spent some time on this, Im going to make a serious attempt at adding a USB host functionality option on the Pico build for host HID support.
Approach maybe with a with a new E.USBSetHost, function that can be used in conjunction with the existing E.USBSetHID to set the mode between: USB device Virtual com (default) , USB Device with HID or USB Host for HID. ie set to host on next USB insert of the board.

Will add discussion on an approach for comment after more learning on my part.
status So far:
Working thru Udemy course embedded driver development for STM32.
Learnt how to successfully build Espruino and flash to Pico on Ubunto box
Currently getting to grips with the current Pico USB build: Looking at the STM libraries currently employed, working back from STM32_USB.make, using STM Library docs. , understanding how E.USBSetHID is implemented.

Found great basic USB tutorial.
https://www.st.com/content/st_com/en/sup­port/learning/stm32-education/stm32-mooc­s/STM32-USB-training.html

Trying to get hold of a STM32F407G DISC BOARD for the development as it has debug capability and USB wired up to STF32F4.... But struggling on availability, just spoke to Anglia Live sales rep to complete questionnaire on my 'project' to justify having stock allocated to me !
So told her this was a project to enhance the Espruino project , hope that is enough.

If ok , will raise an issue for an enhancement 'Provide USB Host functionality on Pico' on Github to formalise the work, in case it helps with supply issue of the dev board. And then can have discussion there on the approach .
Cheers Simon

Just heard the discovery board has been dispatched :)

From the GitHub commits and changes of the STM drivers in Espruino (targetlibs/stm32usb/Src/) back in 2015 , it looks like GWilliams was very busy and there were a ton of changes to the STM libraries to get USB working in Espruino. SO .... clearly changing existing functionality to use more recent STM libraries is not agood idea ! So approach has to be that any Host functionality is all incremental and sits beside existing device virtual com and HID. However that also makes sense, looking at the current STM host libraries in
https://www.st.com/resource/en/user_manu­al/dm00105256-stm32cube-usb-host-library­-stmicroelectronics.pdf

... they would be a parallel set to the existing device libraries on the stack. See Attached pic.

1 Attachment

complicated ....... still early days. update in a couple of weeks.

Realised that given my requirement is to input to pico from usb barcode readers that are usually capable of output in virtual com mode, then may only need host CDC capability on the pico and not need host HID also. So will start with host CDC .

Initially , looks like CDC is an easier implementation and needing fewer library files.
Interested in others view , if you only had one usb class of input. HID or virtual com ?

I think probably CDC - with that you can pretty much just open up the right endpoint (which you could hard-code rather than trying to read the descriptors on the fly) and then you should usually receive serial data on it. I don't think there's much other setup required (but I guess it depends on the device)

Thanks Gordon, CDC it is.

Quick status ... still putting in lots of hours on this. Steep learning curve for me. Achieved so far,

• building Espruino for pico on Ubuntu and getting vars for build
  
• building Espruino in Stmcube ide with hacked make file.
  
• Wired up pico with swd via a Nucleo SWD and so able to run debug via stmcube ide on Espruino interpreter, with power and active console via serial on pico, so can trace thru existing interpreter functionality eg serial.inject. (See pics attached)
  
• Started custom lib in Espruino Usbhost , with jswrap_usbhost
  
• got standalone stmcubef4 usb host library running with a simple main on discovery board. Can see init and receive data callbacks that need to be implemented in Espruino idle loop via wrapper.
  
• Currently copying over usbhost library components from stmcubef4 and trying to build Espruino with them included, issues are newer versions of common files down the usb stack that are shared With existing Espruino usb client stack. Trying to understand and work the overlap. Don’t want to give up on building with both host and client stacks in place.
  
• Initial dev target is ‘just’ disable usb client, init usbhost, and print received data to console.
  
• I will be seeking advice , in due course, on plumbing in usbhost cdc get data into an usbhost.on(‘data’, callback) via the wrapper functionality. Looks like serial.inject has some clues.
  

2 Attachments

P.s any advice always appreciated.

A little wire wrapping going on in the mean time. :)

1 Attachment

Looks great! Hope it goes well!

Yes, building with the new ST APIs is a bit of a pain. You may find some clues in the targets/stm32l4 code, but also I seem to recall that on the whole you could split things up enough that mostly the USB could use the new HAL and everything else could use the old HAL