Cubeprogrammer_api source code (or a bare minimum version of the library)

[cuwittrock]

Hi,

I have just downloaded the CubeProgrammer API to use as a library in a DFU application for a STM32F072, with the intention of linking it into my own project. But I find the library contains too many features for it to be of (straight forward) use. You are forced to include Qt and you need both the CubeProgrammer_API.bin AND the CubeProgrammer_API.dll files. Not only that but it appears that it is also required to have external loader files.

Since there is no source code made available then you can't avoid "including whole world". I have no use for Qt as I don't want a UI but only USB access for DFU. And I know what devices that I want to support, so I don't need/want external loader files. The library could have an option for pushing loader information instead of being forced to use external files.

So, could the source be made available or could the API come as a standalone .bin file? Like so, that you could do with the static library only and needing anything else. In this way you could link it into your project and not be forced to included a bundle of unnecessary and unwanted dependencies.

I could opt for writing my own API but I would prefer to spend my time on other matters. Also, I assume that it is in the interesting of ST that suitable libraries are made available to facilitate SW development.

Kind regards,
Christian

P.S. it would be nice if the API supported DFU images as well.

[MFran.4]

Same here.

[ACand.3]

I am also trying to use the stmcubeProgrammer api to update firmware using ftdi uart.
And it asks to use QT, is there a way to avoid qt? 

[lightwavetech]

The original post is spot-on.  I was encouraged to see the improved API interface on CubeProgrammer_API compared to the DfuSe tool that it superseded, but then disappointed to learn how many seemingly unrelated library dependencies is has once I tried to integrate it fully into my application.  Please release the source code for this API so the community can pick-and-choose which functionality they need, avoid unrelated UI dependencies (Qt), hardcode database file for single processor, and build into a static library.

[lightwavetech]

Furthermore, the display callback architecture is oriented to the example console app and does not support more generic typical C callback functionality (like the passing of a *void to be used as "user data" in case the user needs to pass context to their handler).

Also, possible error codes are not well-documented.

Also, why using wchar* instead of char* for the message in the display callback?