ATmega88A Pin Change Interrupt Timing

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

Happy new year to all!

 

I have a question about the Pin Change Interrupt Timing.

 

Proplem:

There is a PWM Singnal on PD7(PCINT23), blue signal on picture. 

I would like to generate an interrupt each time on a high level on this pin.

Therefore I'm using the Pin change interrupt.

 

The Code I'm using for this is as follows:

 

#include <avr/io.h>
#include <stdlib.h>
#include <avr/interrupt.h>

 

ISR(PCINT2_vect)

{

PORTD |= (1 << PD5);     //PD5 High  Red Signal on picture

PORTD &= ~(1 << PD5);  //PD5 Low

}

 

int main(void)
{
PCMSK2 |= (1<<PCINT23); 
PCICR |= (1<<PCIE2);
sei();
DDRD &= ~(1 << PD7);  
DDRD |= (1 << PD5); 

 

    while (1) 
    {}

}

 

The AVR is running with 16 MHz (Clock Cycle Time should be 62,5ns )

Interrupt execution time should be 4 clock cycles as datasheet.

 

But as you can see on the picture the interrupt execution is delayed (sometimes outside the PWM Signal)(red line).

I expexted that the Interrupt should be executed more close to the rising edge of the blue signal.

 

Do you see something wrong in the code or do you have an idea to solve this problem?

 

Thank you in advance!

 

Regards,

Eric

 

OSC

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

How do you have your scope trigger set up?

Jim

If you want a career with a known path - become an undertaker. Dead people don't sue! - Kartman

Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?  - Lee "theusch"

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB user

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

Derick79 wrote:
Interrupt execution time should be 4 clock cycles as datasheet.

It is hard for me to tell with the posted picture.  What >>is<< the actual time between rising edges?

 

You have told the AVR speed; about how many clock cycles is that?  How constant is it across a number of the edges?

 

Read that datasheet section again --  "execution time"???  Regardless of the term, before the first instruction of ISR code is carried out, assuming global I bit is set:

 

-- Finish current instruction.

-- Your four cycles -- push PC and branch to vector

-- Process instruction at vector address; usually an RJMP. 

 

So certainly not 4.  But in your picture it might be a couple dozen.  So now we need to consider your chosen toolchain.  We can divine that it is GCC.  What optimization settings? What version?  (don't latest versions have the "smarter ISR" stuff?)

 

Easiest is to post the .LSS for your ISR, as well as tell how long PD5 is high.  I'd expect two cycles, about 125ns.  But your picture shows maybe a microsecond.  CKDIV8 fuse set so everything is /8?  -O0 ?

 

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

Blowing up the diagram, I counted about 32 horizontal "dots" in each division.

 

The first edge, rising on the blue signal, the rising on the red signal is about 5 "dots" later => ~3+us => ~50 AVR cycles.

 

The second edge is delayed about 10 dots.  That means the ISR has been delayed, right? ("interrupt latency") 

 

Either the AVR is running much slower than you think, perhaps ~1MHz, or my guess is -O0 and an ugly-looking code sequence.  Post .LSS section...

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

Unlike Theusch I'm not going to count pixels to try to derive clock cycles.

If you want to work with clock cycle accuracy, then put a probe on the clock...

However from the pulsewidth (red) of your ISR it seems indeed about 1/20 of a divison which suggests 1MHz if the set/clear bit in the ISR are both optimised into sbi and cbi instructions.

1MHz is a suspicious value. It is the default clock frequency from the internal RC oscillator.

How sure are you your uC is running on 16MHz?

Do you have a 16MHz signal on your crystal?

If you use a software loop with _delay_ms(10); and toggle a pin you can easily verify if F_CPU is set to the same value as the real clock of you uC.

 

I assume you use gcc? (avr studio)

In GCC it's pretty easy to output list files with the generated asm code intertwined with the commented out C source code.

This is often very helpfull in examining optimisation results and predict timing and such.

 

GCC is also not the best compiler when it comes to tight interrupt code.

It tends to push more registers than needed, but details are to vague in my memory. (sreg always pushed? "zero" register always pushed?)

And of course all registers used for intermediate results in the ISR are pushed on the stack. This all needs time.

AVR's are also not the "best" architecture for fast interrupt response. Sometimes 32 registers are nice to have, but if you're out off luck (big ISR's, calling functions from within an ISR) then GCC pusches them all onto the stack.

Examine the list file and you know exactly what the processor (compiler) does.

 

Why do you generate interrupts on pin change if you say you only need the positive flank?

Or do you want to time how long the PWM signal is high?

You can offload that to a timer and do it in hardware.

(And then use the negative flank of the PWM signal to read the accumulated time of the high period from the timer).

 

Another easy way to give more insight in timing is to also toggle a bit in the while(1){} loop in main.

Whenever an interrupt occurs that pin will temporarily stop toggling.

 

Is this project for hobby / commercial / high volume / one-off?

I try to avoid critical timing on this level. Especially in software because it tend to eat a lot of development time to get it to work reliably.

Remember that you can buy a uC with 10x the horse power for about the same price as a M88 nowaday's.

And what is the cost of the uC compared to the rest of the project? (pcb, power supply, box, etc)...

Paul van der Hoeven.
Bunch of old projects with AVR's:
http://www.hoevendesign.com

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

Paulvdh wrote:
Unlike Theusch I'm not going to count pixels to try to derive clock cycles.

Well, just from looking at the post it appeared to be a couple microseconds, while the code and description would imply much less.  I figgered to make an intelligent response along those lines I had to give some rough numbers.  So I opened the image and the "dots" became more apparent.

 

Still, let's have OP answer my questions.  Seeing the .LSS, and having a measurement of the PD5 high time, should help us to speculate further.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

Here can you see the output of a logic analyzer.

Channel 0 is PD5 (output of the ISR)

Channel 1 is PD7 (input to trigger the interrupt)

Optimation Level is -O1

CKDIV8 is disabled

The AVR is running from a 16 MHz Crystal

 

The plan is to start in the ISR an A/D convertion for messuring the emitter current of an IGBT. PD7 is the Gate Input of the IGBT.

Hopefully this gives you a better picture.

This project is for my thesis.

 

 

 

 

 

LA

 

LSS File

Simulator.elf:     file format elf32-avr

 

Sections:

Idx Name          Size      VMA       LMA       File off  Algn

  0 .data         00000000  00800100  00800100  000000d2  2**0

                  CONTENTS, ALLOC, LOAD, DATA

  1 .text         0000007e  00000000  00000000  00000054  2**1

                  CONTENTS, ALLOC, LOAD, READONLY, CODE

  2 .comment      00000030  00000000  00000000  000000d2  2**0

                  CONTENTS, READONLY

  3 .note.gnu.avr.deviceinfo 0000003c  00000000  00000000  00000104  2**2

                  CONTENTS, READONLY

  4 .debug_aranges 00000028  00000000  00000000  00000140  2**0

                  CONTENTS, READONLY, DEBUGGING

  5 .debug_info   00000691  00000000  00000000  00000168  2**0

                  CONTENTS, READONLY, DEBUGGING

  6 .debug_abbrev 0000060d  00000000  00000000  000007f9  2**0

                  CONTENTS, READONLY, DEBUGGING

  7 .debug_line   00000216  00000000  00000000  00000e06  2**0

                  CONTENTS, READONLY, DEBUGGING

  8 .debug_frame  00000040  00000000  00000000  0000101c  2**2

                  CONTENTS, READONLY, DEBUGGING

  9 .debug_str    00000342  00000000  00000000  0000105c  2**0

                  CONTENTS, READONLY, DEBUGGING

 10 .debug_loc    0000002f  00000000  00000000  0000139e  2**0

                  CONTENTS, READONLY, DEBUGGING

 11 .debug_ranges 00000018  00000000  00000000  000013cd  2**0

                  CONTENTS, READONLY, DEBUGGING

 

Disassembly of section .text:

 

00000000 <__vectors>:

   0: 19 c0        rjmp .+50      ; 0x34 <__ctors_end>

   2: 20 c0        rjmp .+64      ; 0x44 <__bad_interrupt>

   4: 1f c0        rjmp .+62      ; 0x44 <__bad_interrupt>

   6: 1e c0        rjmp .+60      ; 0x44 <__bad_interrupt>

   8: 1d c0        rjmp .+58      ; 0x44 <__bad_interrupt>

   a: 1d c0        rjmp .+58      ; 0x46 <__vector_5>

   c: 1b c0        rjmp .+54      ; 0x44 <__bad_interrupt>

   e: 1a c0        rjmp .+52      ; 0x44 <__bad_interrupt>

  10: 19 c0        rjmp .+50      ; 0x44 <__bad_interrupt>

  12: 18 c0        rjmp .+48      ; 0x44 <__bad_interrupt>

  14: 17 c0        rjmp .+46      ; 0x44 <__bad_interrupt>

  16: 16 c0        rjmp .+44      ; 0x44 <__bad_interrupt>

  18: 15 c0        rjmp .+42      ; 0x44 <__bad_interrupt>

  1a: 14 c0        rjmp .+40      ; 0x44 <__bad_interrupt>

  1c: 13 c0        rjmp .+38      ; 0x44 <__bad_interrupt>

  1e: 12 c0        rjmp .+36      ; 0x44 <__bad_interrupt>

  20: 11 c0        rjmp .+34      ; 0x44 <__bad_interrupt>

  22: 10 c0        rjmp .+32      ; 0x44 <__bad_interrupt>

  24: 0f c0        rjmp .+30      ; 0x44 <__bad_interrupt>

  26: 0e c0        rjmp .+28      ; 0x44 <__bad_interrupt>

  28: 0d c0        rjmp .+26      ; 0x44 <__bad_interrupt>

  2a: 0c c0        rjmp .+24      ; 0x44 <__bad_interrupt>

  2c: 0b c0        rjmp .+22      ; 0x44 <__bad_interrupt>

  2e: 0a c0        rjmp .+20      ; 0x44 <__bad_interrupt>

  30: 09 c0        rjmp .+18      ; 0x44 <__bad_interrupt>

  32: 08 c0        rjmp .+16      ; 0x44 <__bad_interrupt>

 

00000034 <__ctors_end>:

  34: 11 24        eor r1, r1

  36: 1f be        out 0x3f, r1 ; 63

  38: cf ef        ldi r28, 0xFF ; 255

  3a: d4 e0        ldi r29, 0x04 ; 4

  3c: de bf        out 0x3e, r29 ; 62

  3e: cd bf        out 0x3d, r28 ; 61

  40: 0e d0        rcall .+28      ; 0x5e <main>

  42: 1b c0        rjmp .+54      ; 0x7a <_exit>

 

00000044 <__bad_interrupt>:

  44: dd cf        rjmp .-70      ; 0x0 <__vectors>

 

00000046 <__vector_5>:

 

 

 

ISR(PCINT2_vect)

 

{

  46: 1f 92        push r1

  48: 0f 92        push r0

  4a: 0f b6        in r0, 0x3f ; 63

  4c: 0f 92        push r0

  4e: 11 24        eor r1, r1

 

PORTD |= (1 << PD5);     //PD5 High  Red Signal on picture

  50: 5d 9a        sbi 0x0b, 5 ; 11

 

PORTD &= ~(1 << PD5);  //PD5 Low

  52: 5d 98        cbi 0x0b, 5 ; 11

 

}

  54: 0f 90        pop r0

  56: 0f be        out 0x3f, r0 ; 63

  58: 0f 90        pop r0

  5a: 1f 90        pop r1

  5c: 18 95        reti

 

0000005e <main>:

 

 

 

int main(void)

{

PCMSK2 |= (1<<PCINT23);

  5e: ed e6        ldi r30, 0x6D ; 109

  60: f0 e0        ldi r31, 0x00 ; 0

  62: 80 81        ld r24, Z

  64: 80 68        ori r24, 0x80 ; 128

  66: 80 83        st Z, r24

PCICR |= (1<<PCIE2);

  68: e8 e6        ldi r30, 0x68 ; 104

  6a: f0 e0        ldi r31, 0x00 ; 0

  6c: 80 81        ld r24, Z

  6e: 84 60        ori r24, 0x04 ; 4

  70: 80 83        st Z, r24

sei();

  72: 78 94        sei

DDRD &= ~(1 << PD7);

  74: 57 98        cbi 0x0a, 7 ; 10

DDRD |= (1 << PD5);

  76: 55 9a        sbi 0x0a, 5 ; 10

 

 

while (1)

{}

  78: ff cf        rjmp .-2      ; 0x78 <main+0x1a>

 

0000007a <_exit>:

  7a: f8 94        cli

 

0000007c <__stop_program>:

  7c: ff cf        rjmp .-2      ; 0x7c <__stop_program>

 

Atmel Studio 7 (Version: 7.0.1188 - )
© 2015 Atmel Corp.
All rights reserved.

OS Version: Microsoft Windows NT 6.2.9200.0
Platform: Win32NT

Installed Packages: Shell VSIX manifest - 7.0
Shell VSIX manifest
Version: 7.0
Package GUID: e874ffe4-fbe3-4624-9a17-61014ede02d0
Company: Atmel Corporation

Installed Packages: Atmel Start - 1.0.99.0
Atmel Start
Version: 1.0.99.0
Package GUID: F8853255-9C7B-4DC2-8E0F-64D9324AEB0E
Company: Atmel

Installed Packages: Atmel Software Framework - 3.32.0.596
ASF
Version: 3.32.0
Package GUID: 4CE20911-D794-4550-8B94-6C66A93228B8
Company: Atmel
HelpUrl: http://asf.atmel.com/3.32.0
Release Description: ASF - 3.32.0 Release

ASF
Version: 3.31.0
Package GUID: 4CE20911-D794-4550-8B94-6C66A93228B8
Company: Atmel
HelpUrl: http://asf.atmel.com/3.31.0
Release Description: ASF - 3.31.0 Release

ASF
Version: 3.30.1
Package GUID: 4CE20911-D794-4550-8B94-6C66A93228B8
Company: Atmel
HelpUrl: http://asf.atmel.com/3.30.1
Release Description: ASF - 3.30.1 Release

ASF
Version: 3.29.0
Package GUID: 4CE20911-D794-4550-8B94-6C66A93228B8
Company: Atmel
HelpUrl: http://asf.atmel.com/3.29.0
Release Description: ASF - 3.29.0 Release

ASF
Version: 3.28.1
Package GUID: 4CE20911-D794-4550-8B94-6C66A93228B8
Company: Atmel
HelpUrl: http://asf.atmel.com/3.28.1
Release Description: ASF - 3.28.1 Release

 

Installed Packages: LiveWatch - 2.0.54
LiveWatch
Version: 2.0.54
Package GUID: 7DF6DCFD-2BCA-41C7-9C0E-1B7F606B008E
Company: Atmel

Installed Packages: GdbConsole - 7.0.154
GdbConsole
Version: 7.0.154
Package GUID: 49258291-0FED-4501-881B-6BAA91BEBCA8
Company: Atmel

Installed Packages: Atmel Kits - 7.0.85
Atmel Kits
Version: 7.0.85
Package GUID: 6F4B8FE4-C464-4916-8B43-AC92431C1CDF
Company: Atmel

Installed Packages: AtmelToolchainProvider - 7.0.891
AtmelToolchainProvider
Version: 7.0.891
Package GUID: AtmelToolchainProvider.Atmel.10EF9C74-D8DA-4872-85F5-D8BB3101E245
Company: Atmel

Installed Packages: Data Visualizer Extension - 2.6.519
Data Visualizer Extension
Version: 2.6.519
Package GUID: 25dc067d-df31-4e22-be7f-cc6a77ccc7f3
Company: Atmel

Installed Packages: Atmel Gallery - 7.8
Atmel Gallery
Version: 7.8
Package GUID: AtmelStudio7ExtensionManager
Company: Atmel

Installed Packages: Percepio Trace for Atmel Studio - 1.3
Percepio Trace for Atmel Studio
Version: 1.3
Package GUID: fe274744-c496-42fc-9e52-f77b92d669b1
Company: Percepio AB

Installed Packages: Visual Assist for Atmel Studio - 10.9.2093.2
Visual Assist for Atmel Studio
Version: 10.9.2093.2
Package GUID: 7997A33C-B154-4b75-B2AC658CD58C9510
Company: Whole Tomato Software

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

Hmmm, what sample rate is your logic analyser running at?

#1 This forum helps those that help themselves

#2 All grounds are not created equal

#3 How have you proved that your chip is running at xxMHz?

#4 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand." - Heater's ex-boss

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

So, 1.25us from rising edge to port changing. At 16MHz that's 20 cycles.

 

There's the delay from the edge happening to it being recognised, the delay to finish the current (RJMP) instruction, the delay to push PC, the RJMP at the ISR vector, the delay in the ISR prologue and then the setting of the port. 20 cycles seems about right.

 

 

#1 This forum helps those that help themselves

#2 All grounds are not created equal

#3 How have you proved that your chip is running at xxMHz?

#4 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand." - Heater's ex-boss

Last Edited: Wed. Jan 3, 2018 - 02:57 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

at 12MHz, it's only a very low cost tool

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

Derick79 wrote:
PORTD |= (1 << PD5); //PD5 High Red Signal on picture

50: 5d 9a sbi 0x0b, 5 ; 11

PORTD &= ~(1 << PD5); //PD5 Low

52: 5d 98 cbi 0x0b, 5 ; 11

Regardless whether there might be a (one cycle?) delay for the SBI/CBI to "take" and the 'scope see the change, that should "wash" for the SBI followed by the CBI and the output should be high for two cycles.  125ns, right?

 

That is roughly what is seen in the logic analyzer notations above.  The differences might be due to LA sampling artifacts, as the two PD5 captures are different.

 

Sure looks different to my eye than the 'scope traces in the OP, where it appears to be about a microsecond of high. 

 

Similarly, the 'scope trace shown, if it is really 20us/division, clearly shows to the naked eye much longer than the 1+us shown in the LA picture.  Not really 20us/div?  Different clock rate?

 

GCC gurus will need to comment on how to get the "smart" ISR in this case, to not fuss with R0 and SREG.  But no matter for now; let's make a guess...

 

-- [main loop] RJMP is 2 cycles, so an average of 1 cycle to finish current instruction

-- 4 cycles to get to the vector

-- 2 cycles for the vector's RJMP

 

So 7 cycles to get to the ISR.

 

Derick79 wrote:
46: 1f 92 push r1 48: 0f 92 push r0 4a: 0f b6 in r0, 0x3f ; 63 4c: 0f 92 push r0 4e: 11 24 eor r1, r1

-- 5 more cycles for that "prologue"; now we are up to 12.

-- 2 cycles for the SBI.

-- one more cycle for it to "take" on the output?

 

So that is 15 cycles or so.  Should be about a microsecond at 16MHz.

 

============================

Derick79 wrote:
The plan is to start in the ISR an A/D convertion for messuring the emitter current of an IGBT.

The cycle-counting analysis is "interesting".  But to reach your goal (which I assume is to start the conversion ASAP after gate goes high?) then why not let the chip do that for you with auto-trigger?  See datasheet for ADATE.  Lessee -- on that model you would need to use either INT0 or the analog comparator.  [there is another more convoluted approach using the T0 or T1 pins, timer-as-counter, and a compare match on 0 count]

 

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

But the oscilloscope and the LA are showing the same behavior.

What als can be seen is that sometimes the interrupt is generated outside the pulse of PD7 (see the first picture in the right area).

This can be also seen on the LA. 

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

Derick79 wrote:

at 12MHz, it's only a very low cost tool

 

OK, so all your timings have an error of +/-0.042us.

#1 This forum helps those that help themselves

#2 All grounds are not created equal

#3 How have you proved that your chip is running at xxMHz?

#4 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand." - Heater's ex-boss

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

Derick79 wrote:

What als can be seen is that sometimes the interrupt is generated outside the pulse of PD7 (see the first picture in the right area).

 

You are using  a Pin Change Interrupt. So ANY change, low-to-high or high-to-low, will be latched as an interrupt. So you get an interrupt on both the rising and falling edge of PD7.

#1 This forum helps those that help themselves

#2 All grounds are not created equal

#3 How have you proved that your chip is running at xxMHz?

#4 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand." - Heater's ex-boss

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

...which is what the LA shows.

 

PD7 goes high and 1.25us later you get a pulse on PD5. PD7 goes low and 1.25us later you get another pulse on PD5.

#1 This forum helps those that help themselves

#2 All grounds are not created equal

#3 How have you proved that your chip is running at xxMHz?

#4 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand." - Heater's ex-boss

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

Dear Theusch,

 

thank you for the ADATE tip, i was not aware of this function.

Problem is that the pcb is already finished and i have no time to make another one.

Further i need three gate inputs to start an A/D conversion.

 

I will try polling the input without interrupt. Maybe this is sufficient.

 

Dear Brian,

thank you too, i thought PCINT generates only an interrupt at reaching the high level.

 

Thanks for your time. Its now more clear to me

 

 

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

Derick79 wrote:
Further i need three gate inputs to start an A/D conversion.

You say that the 'scope and LA are "the same picture".  Tell the time base on the 'scope picture.  As the analysis shows, it soen't make sense that they are the same.

 

Is your aim to measure the current during every pulse on PD7?  How far apart are these pulses?  The 'scope picture, if 20us/div, implies 40us or less.  The AVR's ADC, for full resolution, needs an ADC clock of about 200kHz or less.  So a conversion is roughly 100us at 10ksps.  And you want to monitor three channels?  Probably not practical with an AVR8 if you want to gather values from every cycle.  And even if you do, where are you going to put all that information?

 

Re "the circuit board already built" -- you don't have an Xacto knife and wire and solder?  Sometimes changes need to be made.

 

 

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

I don't have time to think this through fully at the moment but...

 

your interrupt source is PD7 which is also the AIN1 pin. You might be able to use the analogue comparator because you can select rising or falling edge ISR. If the other comparator input was fed from the bandgap then the comparator would act as a high/low detector for PD7.

 

...just a thought.

#1 This forum helps those that help themselves

#2 All grounds are not created equal

#3 How have you proved that your chip is running at xxMHz?

#4 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand." - Heater's ex-boss

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

Hello,

 

Do you try a dealy on trigger?

 

ISR(PCINT2_vect)

{

PORTD |= (1 << PD5);  

_delay_us(10);

PORTD &= ~(1 << PD5);  

}

 

Sometimes you need to counter the overflow if the PWM is to fast.

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

Derick79 wrote:
Problem is that the pcb is already finished and i have no time to make another one.

PD7 is one of the Analog Comparator inputs.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

You are right Theusch,

 

the time basse on the scope picture are 20us/div.

So the pulse width un the scope picture sould be around 4us roughly.

But please note,the pulse width is changing all the time.

I think the delay between the generated interrupt and the rising edge of PD7 was abnormal.

But, below you can see the LA with polling PD7. The delay ist still the same.

 

I have to test if a sufficient current measurement is possible.

 

I'm working with only 8 bit resolution on the adc.

Channel 0 shows the time from starting the AD convertion until to write the result to an array.

After some measurements i will calculate the average current.

 

I want to measure the signals on by one, not all three at the same time.

 

 

al

 

 

 

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

As #9 20 clk delay is about what the code give, (you will never know because it depends of the instruction in "main" and where in that instruction it was when the ISR was triggered).

You can cut the delay to about the half if the ISR was written in ASM. (or change C compiler).

 

If you need min. delay, then have main running a long line of nop's (I guess you have a good idea of when the signal come). (else like  the video people put it to sleep then you know the delay).

or just a loop in main that wait for the signal (no ISR)

 

 

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

sparrow2 wrote:
If you need min. delay,...

That is of importance here, IMO.  OP never answered about whether min. delay was the goal here.  [there are also the practical aspects of the fast repetition rate of the signal and where all the data is going to be stored and where the cycles will come from to process]

 

Anyway,

-- If min. delay is of primary importance, then ADATE negates any ISR cycle counting.

-- Remember that AVR8 S/H is some ADC clock cycles after the conversion commences.  Even if a 1MHz ADC clock that would be about 1.5us.  For a realistic 250kHz ADC clock, that would be 6us.  Makes the cycle-counting pale in comparison.

-- Better be great drive on that signal.

-- Let's say you sample immediately on the rising edge of that trigger signal -- say, less than half a microsecond.  Are you really going to get a good estimate of current used that soon after you turn on the faucet?  You sparkies need to answer that.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.