22
Since the code snippet you're interested in isn't big, you could disassemble your compiled code, look at all the assembly instructions and count how many cycles they need. You can find the number of cycles for each instruction in the datasheet.
If you have an oscilloscope, you can turn on a pin before the if statement and turn it off after your code snippet. ...
14
Let's do it!
Say we have the code
int main(void)
{
volatile uint8_t val = 0;
while (1)
{
if ((PIND & (1 << PIND6)) == (1 << PIND6)) {
val = 1;
} else {
val = 0;
}
}
}
Say we use AVR GCC with optimization flag -O1, then the disassembly of the relevant section looks like this:
...
11
I normally use the built-in simulator of Atmel Studio which has a cycle counter in the processor status window.
This is a combined screenshot from stepping though the code:
]
As you can see, the cycle counter is 18 before and 22 after stepping through the two statements. So according to the simulator it takes 4 cycles.
You can use this to step through the ...
8
If speed is important for this code, the following is probably noteworthy:
You could just write
val = (PIND & (1 << PIND6)) != 0;
or
val = 1 & (PIND >> PIND6);
I guess the last one is shorter/faster.
Concerning speed/time estimation:
Either
let your compiler generate an assembler listing file (*.lst) or
look at the disassembled ...
4
Generally speaking, you should strive to give variables as local a scope as possible. This makes it easier to find them, eliminates bugs caused by namespace collisions and can possibly reduce the overall stack use.
Local variables declared inside a {} scope may also be easier for the compiler to allocate them in registers, which is the ideal place both in ...
4
In terms of speed and efficiency, I cannot be sure where to declare them.
For clean code the scope must be as small as possible.
Use the static keyword if you have to make it persistent.
For speed you may want to look into how and where you use it. Often automatic (local) scope variables are very fast since they fit in R0-R15, then follow relative ...
2
What you have there is just a plugin with some basic static analysis.
If you require MISRA you'll have to buy a tool, MISRA is proprietary and not available in open source kits.
1
Few really good static checker tools that you must consider:
PC-Lint -> My personal favorite.
LDRA
Both of these are highly customisable, where rules can be suppressed or enabled, and also can be integrated with TI CCS.
Using a static code checker conforming to rules like MISRA or CERT etc, can save a lot of potential bugs in the long run. Consider using ...
1
Note: Wars were led about the "correct" placement of variables. ;-)
Anyway, some common sense went into style guides and coding regulations. To answer your questions:
Place variables at the most inner place possible. Reasons:
It is hard to grasp when you need to look at two (or more) distant places in the sources.
The compiler might have more chances to ...
Only top voted, non community-wiki answers of a minimum length are eligible
