2011-06-13 06:30 PM
In
stm3210b_eval_lcd.c
Why use
static __IO
in
this definition
TextColor and LCDType ?
Put another way
I understand the
static
definition of
the
prefix stands for
a static
variable?
but
static sFONT
and
static __IO
should be
how to understand.
Who can
tell me?
#stm32 #stm32-lcd-eval2011-06-13 09:03 PM
No doubt to localize it to that specific file/object, and not pollute the global name space.
2011-06-14 02:00 AM
Did you have a particular reason for using such a large font?
''static sFONT
and
static __IO
should be
how to understand
'' I would guess that sFont is a typedef - use the facilites in your tools to find its definition. Anything that begins with underscores should be to do with the compiler - so check your tool Manuals for details of __IO; Or, again, use the facilites in your tools to find its definition. Any decent tools will have a ''Go To Definition'' feature. You haven't stated what tools you're using, so it's impossible to say how, precisely, you will need to do it - you will have to check the Manuals yourself.2011-06-14 02:30 AM
2011-06-14 02:31 AM
what is the advantage of this form of the Definition than others;
what is the difference between this two forms? 1.static __IOuint_16_t TextColor
; 2.staticuint_16_t TextColor
; 3.uint_16_t TextColor
;2011-06-14 04:58 AM
''what is the advantage of this form of the Definition''
Which form?''than others''What others?''what is the difference between this two forms?'' How about you show a full & complete example of each (the definition and its use) - so that we know what you're actually talking about?!
2011-06-14 01:16 PM
what is the advantage of this form of the Definition than others;
what is the difference between this two forms?
1.static __IO uint_16_t TextColor;
2.static uint_16_t TextColor;
3.uint_16_t TextColor;
The benefit of the first two is that you get a ''global'' variable with a potentially common naming, but it's symbol doesn't pollute the global namespace. ie you can have a different TextColor defined in other files and they won't interfere with each other. /** * IO definitions * * define access restrictions to peripheral registers */ #define __I volatile const /*!< defines 'read only' permissions */ #define __O volatile /*!< defines 'write only' permissions */ #define __IO volatile /*!< defines 'read / write' permissions */ The value of __IO in this context is a little more murky, but as a volatile it will force the compiler to re-read a value each time it is needed rather than optimizing off in a register, or out of a loop. This might be helpful if the value is apt to change under interrupt, or by another thread/task. As to why it was done this way, I'm not sure you're going to have the originating engineer come here and explain the design decision. Probably to prevent some compiler warnings, or strict type checking. You should analyze the code for yourself, and draw your own conclusions. Try setting different warning levels, or type compliance from the compiler. Try LINT or something. Bloody asinine forum software, had to edit this several times to get rid of the ''quoted message'' hiding content.
2011-06-15 01:49 AM
''The benefit of the first two is that you get a ''global'' variable with a potentially common naming, but it's symbol doesn't pollute the global namespace.''
aka ''file scope'' Other potential advantages include:''ie you can have a different TextColor defined in other files and they won't interfere with each other.''
That may or may not be an advantage in practice! Having identically-typed and identically-named but distinct variables could lead to confusion...''The value of __IO in this context is a little more murky'' In programming, there are always 2 things to consider:In this case, the 'C' syntax is identical for both __O and __IO, but having different names should help to make the programmer's intention clearer.
It may also be that this is intended to be ''generic'', and could be used to encapsulate some compiler-specific (or target-specific) features related to IO... However, as already noted, names beginning with underscores should be reserved for use by the compiler - user code should not define names beginning with underscores!''As to why it was done this way, I'm not sure you're going to have the originating engineer come here and explain the design decision.''When writing example code, this is the kind of thing that really should be clearly explained! See rant here: