Skip to main content
Paulus
Paulus
Associate II
October 22, 2019
Question

Advice about implementing new code written with HAL into older appln written with older low level libraries (2013).

  • October 22, 2019
  • 1 reply
  • 724 views

The USB device I need is working with a set of newer libraries (mxCube). All my application ported code is written with older libraries so the permutations are:

A. App with older libraries combined with USB running on new libraries (lazy way, short cut. The way I have been working...)

B. Port App to newer libraries so everything works together (that's the way you do it and preferred)

C. Port USB to older libraries so all works together (that's a fall back and hard to debug plus workarounds)

I have been trying plan A with importing the USB files into the App framework and the other way around. Importing the App code into the USB framework (produced by CubeMx application).

That took a full day (2700 errors), so should we move on to B since that is clearly the way to do it? It is a massive piece of work to get that working, I estimate 3-4 weeks. Any advice about the approach here? Any tools available?

This topic has been closed for replies.

1 reply

berendi
berendi
Principal
October 23, 2019

I was in the same situation, legacy code using StdPeriph and the old set of CMSIS headers that came with StdPeriph, new code for the USB host with HAL. Took plan A.

To solve the thousands of conflict between old and new headers, I did not actually merge the USB handling into the base application, but put USB handling into a separate project, compiled as a static library, and linked that with the application. Took maybe a day to figure it all out, minimal changes were needed in the existing codebase.

Make sure that no hardware resources are shared between the two projects, each should handle their peripherals exclusively. Think about the periodic interrupt (SysTick) handler.

Be aware that the CubeMX USB host library makes some delay calls up to 200 ms. If that's not acceptable, consider expanding the state machine in usb_core.c

Plan B means practically rewriting all hardware accesses in the application, because there is zero chance that HAL has an equivalent for every single function you are using from the old library. It can invalidate timing assumption, breaking the already working application in unpredictable and hard to find ways.

Plan C might be workable, if you can find a legacy USB library. STSW-STM32046 might be what you'd need here.

Terms & ConditionsAccessibility statement