Quoting "Dmitry K." <[EMAIL PROTECTED]>:
On Friday 18 January 2008 13:28, Paulo Marques wrote:
[...]
Say, one of the things I wanted to implement, was something like an
include file with (just a rough sketch):
#define COUNTER_CTRL_PORT 0x56
static void avrtest_counter_start(byte counter)
{
*((volatile unsigned char *) COUNTER_CTRL_PORT) = counter;
}
static void avrtest_counter_stop(byte counter)
{
*((volatile unsigned char *) COUNTER_CTRL_PORT) = 0x80 | counter;
}
[...]
What I would like this interface to achieve:
- be able to start / stop the counters without affecting cycle counts
You can allocate COUNTER_CTRL_PORT at low part of port's addresses
with limitation of counters number to 8. So, SBI/CBI instruction
would be used (exclude -O0), that is simple to compensate.
Nice. I was only thinking of IN / OUT, but SBI / CBI make more sense
just to start / stop. The only drawback is that we will be using an
"allocated" port, like PORTG, or DDRG (for instance), but probably the
programs that we want to test won't be writing to these ports anyway,
so this shouldn't be a big problem.
And, we can do a single OUT to start or stop several counters at once ;)
Note, that avrtest is not too accurate in clocks counting, for
example, MOVW adds 2 clocks, ADIW/SBIW adds 0 clocks.
You're mean :)
That was _the_ only opcode that was missing cycle counting. I've just
reviewed all the opcodes, and the only other counting bug I could find
was that it was costing 2 cycles to do a MOVW, instead of 1 cycle.
[...]
Since you seem to frequently produce cycle counts for your floating
point operations and other libc functions, what would you like this
interface to be able to do?
I use a subtraction of 2 passes: with target and dummy functions.
But you would prefer to use a counter infrastructure like this one, no?
Or are there disadvantages that I'm not seing?
--
Paulo Marques
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
_______________________________________________
AVR-GCC-list mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
