For STM32_USB_Device_Library please provide a version symbol
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-06-27 2:47 PM - edited ‎2024-06-27 2:48 PM
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
- Labels:
-
STM32Cube MCU Packages
-
USB
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-06-27 4:34 PM - edited ‎2024-06-27 4:53 PM
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.
- Please post an update with details once you've solved your issue. Your experience may help others.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-06-28 12:20 AM
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-06-28 1:55 AM
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-06-28 2:06 AM
@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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-06-28 2:27 AM
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).
Thanks
Omar
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-06-28 3:21 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-06-28 4:21 AM
> 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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-08-06 7:39 AM
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.
Thanks
Omar
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-08-06 7:49 AM - edited ‎2024-08-06 7:51 AM
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
