STM32 StdPeriph_Lib 3.4

[sebastian239955_stm1_stmicro]

Posted on March 14, 2011 at 15:59

STM32 StdPeriph_Lib 3.4

#!winning-makework

[ColdWeather]

Posted on May 17, 2011 at 14:27

Maybe because some parts of an init structure can be set at runtime only (for instance, timer dividers depending on the system clock, etc...). In such cases the init structure to allocate in RAM like local variables.

[Tesla DeLorean]

Posted on May 17, 2011 at 14:27

Many of us are quite happy building these structures on the stack, and thus not consuming any RAM permanently. And as mentioned, some things might actually be configurable and setting them in stone is a sure fire way to prevent any flexibility.

Want to define you're structures as const, then go ahead and do that and cast the input parameters to the library. Don't like the library, then modify it, they provide the source. Actually want to save code/data space for configuring GPIO's, then build a compact table description and iterate through it.

[rdraschwandtner]

Posted on May 17, 2011 at 14:27

Yes but this is just a hack!

clive, please read

http://www.parashift.com/c++-faq-lite/const-correctness.html

Conclusion

1. If the const correctness has been followed correctly one would be able to place a instance in the read-only or in the read-write section, without casting anything to anything!
2. If the const correctness has been followed correctly one would be able to see at a glance if the given parameter is modified!

Example <code> #include <stdio.h> typedef struct {     char a;     char b; } dummy_t; //this const means: I don't want to modify the content of your pointer void foo( const dummy_t *dummy ) {     char temp;     //dummy is not modifiable     //-> read only     //dummy->a = 'a'; //works if const is not in signature         temp = dummy->a; //just read it } int main( void ) {     dummy_t ramdummy =     {         .a = 'x',         .b = 'y',     };     static const dummy_t flashdummy =     {         .a = '4',         .b = '2',     };     foo(&ramdummy);     foo(&flashdummy);     printf(''ramdummy.a=%c\n''             ''ramdummy.b=%c\n'', ramdummy.a, ramdummy.b);     printf(''flashdummy.a=%c\n''             ''flashdummy.b=%c\n'', flashdummy.a, flashdummy.b);     return 0; } </code> @clive: the pragmatic way is not the best way (in this case)!  sebastian made a good suggestion to improve the library. If ST does not want to implement it, it's their case.

[Tesla DeLorean]

Posted on May 17, 2011 at 14:27

Yet the article you cite is highly C++ centric. Where the compiler might realistically modify, or add runtime code, that is not immediately apparent.

I'm not convinced this exercise will materially improve the code/data utilization. Perhaps you can go through the code and demonstrate this. I know it will contractually guarantee that the compiler won't write to such structures, but I'm not convinced the library does so now. Using RAM utilization as an argument in favour of doing the conversion, is incredibly weak. If one-time initialization code is permanently consuming RAM resources on an embedded system, the library user has far more problems with coding than the ''const correctness'' of the underlying library. ST's example code defines a lot of unnecessary global RAM based structures, and it's been pointed out by Andrew, and others, that these examples could be made significantly better. They are in the end though throw away examples, but as Microsoft has discovered, people tend to be rather lazy and a lot of example code gets cut-n-pasted blindly without much thought to the context. Even if one doesn't cast structures to the library, this would not legally preclude you from building large compact static/const table structures in ROM/FLASH and enumerating/decoding those into local stack based structures passed down to the library. Such efforts would materially improve the code/data utilization. And I'll reiterate that you have the source, we can clean or bug fix it as required. If your process requires you to run Lint against it, and sanitize it for const correctness, do that and share the results.

[John F.]

Posted on May 17, 2011 at 14:27

Can anyone explain why this topic is in ''wide screen''? All the other threads wrap neatly on my screen. This one is about twice as wide as the display!

Oh! ... and I just create the INIT structures on the stack, use them and lose them. Works fine for me!

[Andrew Neil]

Posted on May 17, 2011 at 14:27

''Can anyone explain why this topic is in 'wide screen'?''

No - the whole ST Forum is a complete mystery! However, the opening post is in an unusual font  - looks like the OP somehow managed to find a ''preformatted'' mode...''I just create the INIT structures on the stack, use them and lose them. Works fine for me!'' I think the OP muddled the issue between the input parameter in the API call being const, and the structure that you pass to it being const. Having the API input parameters declared as const makes sense; Having the structure in Flash does not make universal sense.

[Tesla DeLorean]

Posted on May 17, 2011 at 14:27

Can anyone explain why this topic is in ''wide screen''?

The OP applied some formatting in this godawful Word(tm)esc text editing dialog, and that effects all subsequent posts. He could edit it, but then it would probably re-order the posts too. I was looking for a ''remove all formatting'' button, but couldn't find one. As Andrew observed, the OP believes all his init data is statically allocated in RAM, this is a level of ''doing things wrong'' that will not be fixed by a library change, or rules enforcement by the compiler. And my observation that if RAM footprint is a problem, there are better ways to solve that. I certainly wouldn't advocate filling vast tracts of FLASH with repetitive constant data either, since most of it is used once and discarded, and is ripe for folding in any event. I'm all for the compiler being able to do this, and libraries that enable it, but it is so often used as a crutch. Developing solid code has a lot more to do with understanding the problem and the system limits/interactions, than erecting fences for the unwary. Perhaps someone can sanitize the library, and provide a patch file, so the poor guys that have to maintain it can merge in the ''idealized'' solution.

[rdraschwandtner]

Posted on May 17, 2011 at 14:27

Ok, I think we ran into a deadlock. Everyone has a different opinion.

Lets forget the s**t of placing one-time used init data into static memory areas. But as andrew already stated, API input parameters make sense. They really make sense, because the user is able to pass a constant and a mutable instance to the library without casting! clive, do you agree, or not?