[STM32GENERIC and libmaple] USB on F4 (and possibly F1) libmaple core

Limited support for STM32F4 Discovery, Nucleo and custom F4 boards
Post Reply
ag123
Posts: 770
Joined: Thu Jul 21, 2016 4:24 pm

[STM32GENERIC and libmaple] USB on F4 (and possibly F1) libmaple core

Post by ag123 » Thu May 11, 2017 10:18 am

the USB 'protocol stack' on stm32 seem to be one of the pretty complex things on stm32, yet it is one of the most useful features from stm32f1 - f4, etc :)

hi steve, roger, and daniel hope you happen to be reading this

hi steve,
i found that the usb drivers or protocol stacks in the libmaple f4 (the black f4 vet branch)
https://github.com/stevstrong/Arduino_S ... aple/usbF4
seemed to be the same as roger's ?
https://github.com/rogerclarkmelbourne/ ... aple/usbF4

i did some code compares they seemed very similar except for some edits

then i take a look at daniel's STM32GENERIC core
https://github.com/danieleff/STM32GENER ... rduino/usb

it seemed daniel placed some usb common usb protocol stack codes in the arduino usb - hope daniel could comment on this
while i trace the codes i noted that codes in arduino/usb in turn calls into the STM Cube HAL codes in STM32/system
https://github.com/danieleff/STM32GENER ... M32/system
https://github.com/danieleff/STM32GENER ... F4/HAL_Src

the STM HAL 'library' STM32/system which supports almost the full line of stm32 devices is a whopping 100 megs in size (not surprising as this is what makes it possible to have a app/sketch that runs on 'any' stm32 platform calling into HAL)

the HAL and usb protocol stack in daniel's STM32GENERIC core apparently has some pretty updated HAL codes from STM
i'm seeing dates like year 2016 in the ST's comments, while that in libmaple f4 is back dated to some 2011

i'm wondering if it would help to 'upgrade' to using the same (daniels' STM32GENERIC) protocol stack for usb
that may help as we try to implement some of the other usb device class notably usb mass storage etc

but the codes looked very different between the current ones in libmaple vs that in stm32generic and i couldn't figure out how different they really are looking at them on a superficial level.

i'm thinking if we really want to use the same usb 'protocol stack' as stm32generic, we could abstract basically the usb common parts as well as the specific HAL parts for f4 (and maybe f1) that links to the usb 'protocol stack' codes

i keep calling it 'protocol stack' as apparently for usb 'devices' (not host) we'd need to write 'modules' register them with the protocol stack and the usb 'protocol stack' would call back our modules

um1734 stm32 cube usb device library
http://www.st.com/resource/en/user_manu ... 108129.pdf

User avatar
RogerClark
Posts: 7157
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Re: [STM32GENERIC and libmaple] USB on F4 (and possibly F1) libmaple core

Post by RogerClark » Thu May 11, 2017 10:30 am

ag123 wrote:the USB 'protocol stack' on stm32 seem to be one of the pretty complex things on stm32, yet it is one of the most useful features from stm32f1 - f4, etc :)

hi steve, roger, and daniel hope you happen to be reading this

hi steve,
i found that the usb drivers or protocol stacks in the libmaple f4 (the black f4 vet branch)
https://github.com/stevstrong/Arduino_S ... aple/usbF4
seemed to be the same as roger's ?
https://github.com/rogerclarkmelbourne/ ... aple/usbF4

i did some code compares they seemed very similar except for some edits

then i take a look at daniel's STM32GENERIC core
https://github.com/danieleff/STM32GENER ... rduino/usb

it seemed daniel placed some usb common usb protocol stack codes in the arduino usb - hope daniel could comment on this
while i trace the codes i noted that codes in arduino/usb in turn calls into the STM Cube HAL codes in STM32/system
https://github.com/danieleff/STM32GENER ... M32/system
https://github.com/danieleff/STM32GENER ... F4/HAL_Src

the STM HAL 'library' STM32/system which supports almost the full line of stm32 devices is a whopping 100 megs in size (not surprising as this is what makes it possible to have a app/sketch that runs on 'any' stm32 platform calling into HAL)

the HAL and usb protocol stack in daniel's STM32GENERIC core apparently has some pretty updated HAL codes from STM
i'm seeing dates like year 2016 in the ST's comments, while that in libmaple f4 is back dated to some 2011

i'm wondering if it would help to 'upgrade' to using the same (daniels' STM32GENERIC) protocol stack for usb
that may help as we try to implement some of the other usb device class notably usb mass storage etc

but the codes looked very different between the current ones in libmaple vs that in stm32generic and i couldn't figure out how different they really are looking at them on a superficial level.

i'm thinking if we really want to use the same usb 'protocol stack' as stm32generic, we could abstract basically the usb common parts as well as the specific HAL parts for f4 (and maybe f1) that links to the usb 'protocol stack' codes

i keep calling it 'protocol stack' as apparently for usb 'devices' (not host) we'd need to write 'modules' register them with the protocol stack and the usb 'protocol stack' would call back our modules

um1734 stm32 cube usb device library
http://www.st.com/resource/en/user_manu ... 108129.pdf
The libmaple F1 and F4 USB is based on very old STM code, but I think it could require a lot of effort to replace it with the HAL code.
Which is probably not worth the effort as it my also cause bloat and compatibility problems

It may however be possible to find updated versions of the STM files the USB code uses, as they probably contain bug fixes

ag123
Posts: 770
Joined: Thu Jul 21, 2016 4:24 pm

Re: [STM32GENERIC and libmaple] USB on F4 (and possibly F1) libmaple core

Post by ag123 » Thu May 11, 2017 11:03 am

i'd think we'd 'leave f1 alone' for a start, but usb device classes being some 'very popular' features, we may see 'users' hoping to have the same in f1, hence i'm thinking we could start with f4 but we copy / abstract only the usb parts for f4

and maybe some parts for f1 as well, but we'd not yet go back to f1 and make changes.
i found out that it may even be possible to do some 'gimmicky' things like 'composite devices' e.g.
https://msdn.microsoft.com/en-us/librar ... s.85).aspx
, The device class field of the device descriptor (bDeviceClass) must contain a value of zero, or the class (bDeviceClass), subclass (bDeviceSubClass), and protocol (bDeviceProtocol) fields of the device descriptor must have the values 0xEF, 0x02 and 0x01 respectively, as explained in USB Interface Association Descriptor.
. The device must have multiple interfaces.
. The device must have a single configuration.
i'm not sure if that means if we enumerate as a device class 0xEF, 0x02, 0x01 we could literally work as both usb-serial and mass storage concurrently
this would seemed like a funky use case but i'd think it certainly won't be easy to program that.

we may even end up needing to contend with things like not writing to the sd card while mass storage is active or risk corrupting the card

danieleff
Posts: 336
Joined: Thu Sep 01, 2016 8:52 pm
Location: Hungary
Contact:

Re: [STM32GENERIC and libmaple] USB on F4 (and possibly F1) libmaple core

Post by danieleff » Thu May 11, 2017 11:31 am

USB is a beast. The only way I can do it is because STM already did it.

If you really want to share it, start by figuring out the layers USB has, and how they are implemented. The higher layers could be shared easier (given some common lower API).

The high level c++ classes can be common, like SerialUSB.
The device, config, interface descriptors can be shared, they are just byte arrays.
USB class implementation is harder, it must have a common lower layer (USB message processing).
handling setup USB messages is still doable.
below that (endpoints etc), it starts to get really low level.
even below that, registers, ... ugh

Yes, composite for example CDC+MSC+HID is certainly doable.

stevestrong
Posts: 1747
Joined: Mon Oct 19, 2015 12:06 am
Location: Munich, Germany

Re: [STM32GENERIC and libmaple] USB on F4 (and possibly F1) libmaple core

Post by stevestrong » Thu May 11, 2017 11:44 am

I would definitely leave F1 as it is. Never touch a running system. And also because it is already highly speed optimized.

I downloaded some weeks back the latest USB host device library 2.2.0 from ST official site (UM1021) and compared to the actual F4 USB part - the existing F4 parts were almost identical, the downloaded package contains some more USB device classes, including MSC, DFU, HID, HID+CDC, HID+MSC.
So the actual F4 code in stm32duino repo can be considered "good" and "actual", the current CDC (serial USB) version is actually working without problems so far. The rest can be extended with these new classes with acceptable effort.

My opinion:
I don't really think that it would be beneficial to make the stm32duino (Roger's) repo "generic", too.
Each family (F1, F3, F4, F7) has its own specialties, and I think it is not necessary to bloat the code with lots of ifdefs. I simply don't like it.
And I have nothing against duplicates, as long as they work. And updating different duplicates, when necessary, takes not too much time.
Who wants to have generic, can have the Daniel's repo.

Oh, and my Black F4 branch is actually the Roger's repo, plus some improvements which could be committed to Roger's repo when error free, PR pending.

EDIT
The only case when it would be meaningful to touch F1 USB code is when we want to add new features, like MSC/HID/Audio. I think there are already some examples spread all over the forum.
Last edited by stevestrong on Thu May 11, 2017 12:15 pm, edited 3 times in total.

ag123
Posts: 770
Joined: Thu Jul 21, 2016 4:24 pm

Re: [STM32GENERIC and libmaple] USB on F4 (and possibly F1) libmaple core

Post by ag123 » Thu May 11, 2017 12:03 pm

danieleff wrote:USB is a beast. The only way I can do it is because STM already did it.

If you really want to share it, start by figuring out the layers USB has, and how they are implemented. The higher layers could be shared easier (given some common lower API).

The high level c++ classes can be common, like SerialUSB.
The device, config, interface descriptors can be shared, they are just byte arrays.
USB class implementation is harder, it must have a common lower layer (USB message processing).
handling setup USB messages is still doable.
below that (endpoints etc), it starts to get really low level.
even below that, registers, ... ugh

Yes, composite for example CDC+MSC+HID is certainly doable.
hi daniel,

could you comment a little about the common usb codes in arduino/usb ?
https://github.com/danieleff/STM32GENER ... rduino/usb

it seemed to be some rather common 'protocol stack' that is very much
um1734 stm32 cube usb device library
http://www.st.com/resource/en/user_manu ... 108129.pdf
i'm not too sure about the 'host' (OTG) parts of it but some of the files in the common arduino/usb seemed to be this 'usb device library'
this seemed to be some sort of 'middleware'

then it seem that STM32/system
there are various 'low level/layer' HAL codes which the above 'usb device library' calls into

i've been reading a little into um1734 stm32 cube usb device library above, apparently to implement a new usb device class
one would need to write a module in which the 'um1734 middle ware usb device library' would call back into the module with e.g. the usb IN and OUT requests, and we'd need to handle it from there for our device class

both the state maps used in this um1734 middle ware usb device library are hardly documented anywhere and those 'low layer HAL usb drivers' are also not documented on st's manuals.

but my thoughts are that if this 'um1734 middle ware usb device library' could be used as the 'common code' it may be rather benefitial that we use this as a 'standard', in that way usb device class modules written forward could link without issues with this 'common code'

and the tasks of writing those 'usb device class' we'd 'delegate' to the sketches, i.e. the sketches would need to provide the usb device class module, say usb mass storage and if this 'middle ware driver' and the relevant 'low layer' driver is there in the core codes it would link successfully and would work.

there are some concerns about distributing st's 'um1734 middle ware usb device library', but i'd guess currently this seemed like a 'lowest cost' and 'best compatibility' approach

just 2 cents

danieleff
Posts: 336
Joined: Thu Sep 01, 2016 8:52 pm
Location: Hungary
Contact:

Re: [STM32GENERIC and libmaple] USB on F4 (and possibly F1) libmaple core

Post by danieleff » Thu May 11, 2017 12:30 pm

It would be easier if you downloaded for example STM32CubeF4 1.16.0, most of the below files are from there.
  • STM32/system/STM32XX/HAL_Src is the lowest level layer, handles USB packets. This is different for every series. But the API (more/less) is the same.
  • STM32/cores/arduino/usb is the common USB middleware. Routes low level packets to the class driver. This is the same for every series. (Except the usbd_conf_XX.c files for plumbing)
  • STM32/cores/arduino/usb/[cdc/msc] is the class [CDC/MSC/later others...] middleware. This is the same for every series.
  • STM32/cores/arduino/stm32/USBDevice.cpp begin***() is the plumbing between USB middleware, class middleware, and user code
  • SerialUSB.cpp highest level (for CDC)
Also, have you read USB in a NutShell? http://www.beyondlogic.org/usbnutshell/usb1.shtml
And also, I am not a USB expert by any means.

ag123
Posts: 770
Joined: Thu Jul 21, 2016 4:24 pm

Re: [STM32GENERIC and libmaple] USB on F4 (and possibly F1) libmaple core

Post by ag123 » Thu May 11, 2017 12:49 pm

thanks much daniel, steve :mrgreen:
agreed and i'm just as well starting to 'touch the surface' of usb. usb is a 'monster of a protocol' in part due to its many varied pre defined use cases / device classes

Post Reply