cancel
Showing results for 
Search instead for 
Did you mean: 

For STM32_USB_Device_Library please provide a version symbol

In STM32_USB_Device_Library for 'L4, ST kindly changed a key struct definition between versions, changing amongst other things the type of pUserData from plain pointer to an array of pointers.

That of course threw a bunch of errors in related user code.

For one of my clients, I need to maintain some code which uses this library (legacy thing, client does not change that). It's been built on several machines and some of them for reasons beyond my control have been updated with a newer version of CubeL4, resulting in that bunch of errors.

I would like to fix the user code in a way which is compatible with both versions of the STM32_USB_Device_Library . It would be nice to have a preprocessor symbol defined for the Library Version (so that this affair can be solved purely by conditionals with no runtime code) but I can't find any.

If the answer is "oh, there's none", then consider this to be a feature request.

JW

9 REPLIES 9
BarryWhit
Lead II

I mention this only as a very dirty workaround if ST doesn't come through.

`sizeof(struct)` is determined at compile-time. So, you if include a conditional based on it, the compiler should optimize away all but one branch, and then it would optimize away the conditional entirely and simply inline the body, resulting in zero run-time overhead.

 

#include <stdio.h>
#include <stddef.h>

struct a {
    int b[10];
};

#define LIBVER (sizeof(struct a) > 4 && offsetof(struct a,b) == 0  ? 0x55 : 0xaa)

int main(int argc, char const *argv[]) {
    printf("%x\n", LIBVER);
    return 0;
}
$ gcc -g -O2 -o 1 ./1.c
(gdb) disassemble main
Dump of assembler code for function main:
   0x0000000000401040 <+0>:      sub    rsp,0x8
   0x0000000000401044 <+4>:      mov    esi,0x55
   0x0000000000401049 <+9>:      mov    edi,0x402010
   0x000000000040104e <+14>:     xor    eax,eax
   0x0000000000401050 <+16>:     call   0x401030 <printf@plt>
   0x0000000000401055 <+21>:     xor    eax,eax
   0x0000000000401057 <+23>:     add    rsp,0x8
   0x000000000040105b <+27>:     ret

 

Update: extended to show use of offsetof(type,name), which may prove useful as well.

- If someone's post helped resolve your issue, please thank them by clicking "Accept as Solution".
- Please post an update with details once you've solved your issue. Your experience may help others.

Thanks.

I of course don't wait until ST comes up with something, that's why it's more of a feature request or rant.

Btw., Cube as such might benefit from having the version symbols exposed, rather than having them behind stub functions.

JW

FBL
ST Employee

Hi @waclawek.jan 

Thank you for reporting this issue.

An internal ticket 185284 has been reported to make the necessary changes.

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.


@waclawek.jan wrote:

Btw., Cube as such might benefit from having the version symbols exposed, rather than having them behind stub functions.


+1 to that! :thumbs_up:

There's been plenty of threads in the past which would have benefitted from that!

Typical case is when someone "inherits" an old project - and doesn't know what version(s) of ST code were used.

@FBL 

Saket_Om
ST Employee

Hello @waclawek.jan 

 

Thank you for bringing this issue to our attention.

I reported this internally.

Internal ticket number: 185288 (This is an internal tracking number and is not accessible or usable by customers).

If your question is answered, please close this topic by clicking "Accept as Solution".

Thanks
Omar
Andrew Neil
Evangelist III

So now we have 2 tickets: 

  1. 185284 raised by @FBL 
  2. 185288 raised by @Saket_Om 

Are they both addressing the same issue, or is one about the original, specific issue with STM32_USB_Device_Library for 'L4, and the other about the more general issue with ST-supplied code?

> Typical case is when someone "inherits" an old project - and doesn't know what version(s) of ST code were used.

There *is* a versioning system in place, but those symbols are private to that .c, and they are exposed through a function. This is not always the optimal solution.

I normally don't use Cube so don't care; here I am trying to accomodate external requirements.

JW

Hello @waclawek.jan 

This update was made to support composite since a while now, it was deployed in other STM32 products since 2022. Now user should update his application to be aligned with this update.

If your question is answered, please close this topic by clicking "Accept as Solution".

Thanks
Omar

Hi @Saket_Om ,

I am not questioning the changes as such here.

I am requesting symbols holding the version numbers, so that I can write my portion of code in a way which can use *either* version of the library. Blindly accomodating updates is not an option.

And I would like that to be as compile-time as possible for efficiency reasons, thus functions returning the version are not adequate for that.

JW