Jul
11
comment Concept of the static keyword from the perspective of embedded C
Re-read it now, the point I disagree is the paragraph starting with "Had they used 'extern' it might pose a problem." - extern would not have posed a problem, because it makes sure there is ever only one definition of the variable.
Jul
11
comment Concept of the static keyword from the perspective of embedded C
static instance of the variable would be allocated to its own, seperate memory location, which is avoided by extern.
Jul
11
comment Concept of the static keyword from the perspective of embedded C
Didn't really mean to criticize :) And after I re-read your answer I noticed that you really were the one to point out the different meanings of static. My point is just that what the static declaration (and definition) in the header file is used for in this case, i.e. referencing the same variable/memory location from multiple .c files, only works because of the (non-portable, non-standard) @ 0x06; address specifier, while the "proper" C way would be to use extern at the declaration(s) and a separate, single definition of the variable. Without the @ 0x06 address specifier, every
Jul
10
comment Concept of the static keyword from the perspective of embedded C
"Technically, with 'extern' the rule of thumb would be that only ONE compilation unit would specify the value and the others should not." - This should make clear that the @ 0x06 is part of the definition of the variable, not its declaration. There can only be one definition of a (non-static) variable in a program, anything else yields an error at link time (or before). You can declare the (non-static) variable multiple times via extern, but there can only be one definition.
Jul
10
revised Concept of the static keyword from the perspective of embedded C
added 8 characters in body
Jul
10
revised Concept of the static keyword from the perspective of embedded C
added 23 characters in body
Jul
10
comment Concept of the static keyword from the perspective of embedded C
@jonk Indeed I believe you misunderstood me. Notice that we're not talking about variable declarations/definitions inside functions but global ones. Notice the different meaning of static for global variables as opposed to function-local variables.
Jul
10
comment Concept of the static keyword from the perspective of embedded C
@CortAmmon I think it's the "more proper" way because, in this case, the static way only works because it relies on the (non-portable) extension (@ 0x06;) which allows to allocate multiple (static) instances of a variable to a single memory location. Using extern that would not be a concern.
Jul
9
awarded  Nice Answer
Jul
9
comment Concept of the static keyword from the perspective of embedded C
Great answer, +1! Only one minor point: They could have used extern, and it would be the more proper C way of doing it: Declaring the variable extern in a header file to be inlcuded multiple times in the program and defining it in some non-header file to be compiled and linked in exactly once. After all, PORTB is supposed to be exactly one instance of the variable to which different c.u.'s can refer. So the use of static here is kind-of a shortcut they took to avoid needing another .c file in addition to the header file.
Jul
8
revised Concept of the static keyword from the perspective of embedded C
added 79 characters in body
Jul
8
comment Concept of the static keyword from the perspective of embedded C
@ElectroVoyager cs.auckland.ac.nz/references/unix/digital/AQTLTBTE/DOCU_015.‌​HTM
Jul
8
comment Concept of the static keyword from the perspective of embedded C
@Finbarr Wrong. static globals are visible inside the whole single compilation unit, and are not exported beyond that. They're much like private members of a class in OOP. I.e. every variable that needs to be shared between different functions inside a compilation unit but are not supposed to be visible outside that c.u. should really be static. This also reduces "clobbering" of the program's global namespace.
Jul
8
answered Concept of the static keyword from the perspective of embedded C
Jul
4
comment Examples of fluid (including air) being used to transmit digital data?
"How is sounds used to transmit data underwater?"
Jul
2
comment Prevent compiler optimization for memory access in reflashable memory area
@Lundin The OP clearly states "that the address of Reflashable_Variable might vary later in the binary due to the change in size of some other parameters." - Why do you keep negating that requirement?
Jul
2
revised Prevent compiler optimization for memory access in reflashable memory area
added 57 characters in body
Jul
2
comment Prevent compiler optimization for memory access in reflashable memory area
And other manufacturers don't call it either. The whole FLASH in the chip can be used for program or data and can be erased and rewritten in pages. You keep implying that the OP wants to use the comparatively small EEPROM some chips include, but that does not match the original question. Further you keep insisting that what the OP is trying to do does not make sense, i.e. updating data in FLASH w/o changing/recompiling the code. This shows that you do not even understand the question and hence you should probably not write an answer and should definitely not criticise others' answers.
Jul
2
comment C Integer Promotion on 8-bit MCUs
"Does this mean that all 8-bit arithmetic operations on an AVR will take much longer if written in C than if written in assembly due to C's integer promotion?" - No.
Jul
2
comment Measurement of current with hall effect sensor
I'd say that V[ref] is the reference voltage for 0A. So the output would best be compared to V[ref] instead of assuming a fixed 2500mV. Notice that the sensors can sense AC, so by turning them around you can get increasing V[out] for increasing DC current; might be easier to handle.