Capture pin change timings

Go To Last Post
7 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I've read the (very short) AVR® Simulator User Guide, but can see any mention of recording the IO pins states/changes when running the simulator/debugger (I assume they're the same thing?)

 

Is it possible to get a readout of what happened to the IO pins during a run?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Read the help section about "stimuli and logging" but you may have to accept that there's only so much you can achieve in simulation. For real world events and timings you may be better off with real hardware, probably with a debugger interface and an analyser/scope. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks.  That looked both simple and effective until I actually tried it.

 

$log PORTB
$log TCNT2  
$startlog my-output.stim
#5000
$stoplog
$break

The output file is created, but empty.  No logging to it.  The same is true with the example in the manual though, output file created but nothing logged.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

FYI: In AVR Studio, "simulator" refers to the simulation of a device in software. "Debugging" can be used with a simulated chip or a real one.

 

It is actually a bit difficult to get hardware IO details out of the debugger because there are so many external things that can mess it up. For example, you can set a pin to be a logic high output, but if there is something external that holds that pin low, all bets are off; the debugger would never know!

 

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

For logging I/O pin changes, use a logic analyzer, levels and timing is its specialty.

 

 

FF = PI > S.E.T

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

For logging I/O pin changes, use a logic analyzer, levels and timing is its specialty.

Is that something that would work with the debugger/Simulator?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I was surprised to read that an Atmel Studio feature blatantly didn't work (I didn't believe it) so tested your stim file myself.

 

So I hacked an existing ATmega328P project to configure TIMER2 thus:

 

  • CTC mode
  • OCR2A = 3
  • Clock = CLKIO with Prescaler / 8
  • OCIE2A interrupt enabled

 

 In the ISR I toggled PORTB.

 

 

Here is an extract of the logfile which on examination makes perfect sense:

TCNT2 = 0x02
#8
TCNT2 = 0x03
#8
TCNT2 = 0x00
#8
TCNT2 = 0x01
#2
PORTB = 0xff
#6
TCNT2 = 0x02
#8
TCNT2 = 0x03
#8
TCNT2 = 0x00
#8
TCNT2 = 0x01
#2
PORTB = 0x00
#6
TCNT2 = 0x02
#8