CTC mode PWM generation only when i have pulse on my Input on Attiny13

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

Hi everyone I am on a project on attiny13. I want to drive my MOSFET with alternative switching at 100 Khz only when I have a square pulse input in the frequemcy range 3khz to 5 khz. Now i am in the position I have two seperate program. First that detect the pulse width and measure the frequency and make one pin high when i have in 3 to 5khz frequency range otherwise not. second i have program that drive MOSFET alternatively with 100khz frequency. Both program working fine seperately. When i combine these two program the input side is working. That means i will get my pulse output only when i have frequency betwwen 3 ti 5 khz but the pulse now that need to be given to MOSFET is not alternative. they are same and the pulse width is also not uniform. Can any body help me

#define F_CPU 9600000
#include <avr/io.h>
#include <util/delay.h>
#include <avr/interrupt.h>
#include <util/atomic.h>
#include <stdbool.h>
volatile uint8_t count=0;
volatile uint8_t ready=0;

void timer_init(void)
{	

	Here CTC mode that makes MOSFET with 100 Khz on pin0 and pin1 with OCIE0A and OCIE0B=5

}

ISR(PCINT0_vect)
{
		uint8_t tcnt1;

		 if pin B2 high

			make counter 0
		else
			 count		

}

int main(void)
{

		DDRB |= (1<<PB0);
		DDRB |= (1<<PB1);
		DDRB &= ~(1<<PB2);
		TCCR0B |= (1 << CS00);
		GIMSK |= (1 << PCIE);
		PCMSK |= (1 << PCINT2);
		sei();

    while (1) 

		if(ready)
		{

			if((count> 120) && (count<200))
			{
				timer_init();
			}

			else
			{
				disable toggling on CTC mode and disable OCIE0A and OCIE0B			

			}
		}
	}

 

george

Last Edited: Mon. Aug 5, 2019 - 05:34 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You kind of have the right approach there - what you should do is try and design this at a high level before rushing to implement C code. So things like:

disable toggling on CTC mode and disable OCIE0A and OCIE0B

where you outline the high level task to be achieve look good but:

		DDRB |= (1<<PB0);
		DDRB |= (1<<PB1);
		DDRB &= ~(1<<PB2);
		TCCR0B |= (1 << CS00);
		GIMSK |= (1 << PCIE);
		PCMSK |= (1 << PCINT2);

is a bit pointless at this stage. Just put some comment like:

one time initialisation

later you can begin to add more detail like:

set port B inputs/output
start timer
set up pin change interrupt

But don't just rush direct to detailed implementation - you need a clear "overall picture" before you start worrying about the intricate detail of how each bit will actually be done.

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

As per my finding till now the problem may be because of timer 

TCCR0B |= (1 << CS00);

but donot know how to fix it because same timer is used in PCINT and CTC mode and there is a mismatch. This is just i think. 

george

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

I found out that it is the problem of priority of interrupt. Can i change the priority of ISR?

george

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

George Babu wrote:
I found out that it is the problem of priority of interrupt. Can i change the priority of ISR?

1)  No, classic AVR8s have only one level of interrupt priority.

2)  What difference would priority make?  You only have one interrupt source enabled, right?

 

You need to tell more about accuracy and response time requirements.  If it were me, I'd probably use timer-as-counter or similar and count for a convenient fraction of a second.  Then compare the hits with the high and low limits, and react accordingly.  If 8-bit timer and a few kHz then it would be a small fraction to avoid overflow (that can cause a trigger as well).  Now, with the Tiny13 you are limited on interrupts.

 

But there should be no race in your simple app, IMO.  Keep the timer running all the time for the time base, then turn on/off the PWM feature.

 

 

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

Hello theusch can you tell me about #count for a convenient fraction of second.... what do you mean to say that i didnot understand.

if you see my code i had use a timer/counter that counts and checks if my count is between 120 to 200(which is nothing but checking if my input is between 3 to 5 khz) and if it is true it will set up my CTC mode giving outputs). Is this the same you mean to say or different?

george

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

I didnot change my code and even the  input is constant (no change) and when i see the outputs in oscilloscope my two outputs (used for switching MOSFET) are not same. Sometimes they vary exactly alternatively, sometimes they are same and sometimes even if i remove input my outputs are always there. I need to touch the input pin to make it ground then only my output comes back to zero. Is it a hardware problem or software problem? Why my same code is behaving differently at different time. Can anybody share the solution? 

george

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

i found out its the problem of timer because the same timer is used to run CTC mode and PCINT. How can i fix the issue of timer. 

george

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

After the 100KHz is coming out (due to finding 3 to 5 KHz), does the input still need monitored, to shut off the 100KHz when  the freq is no longer 3 to 5 KHz??  Or is a one-time detection & forget checking thereafter?  If so, the timer mode can be switched from detection to generating.

 

If you need to do both always and constantly at the same time, it is more tricky.

You can set up to generate the 100KHz  at all times & just disable the pin (using timer comxx control bits )when you don't want output.  No IRQ is involved in generating the output.  When you determine you need output, change the comxx bits to produce it.

Then the timer timebase (tcnt) can be used for measurement as well...either just monitor tcnts vs your input (time since last input pin change IRQ to determine freq).

Since the input is "slow" you might not even need irq's on the input...just monitor the pin & watch the tcnt in a tight loop as a measurement.  The loop must be fast enough if you expect really high freqs,that might be aliased in any loop sampling (This is true for IRQ too, since there is latency).  So if you applied 10.387 MHz to the pin, all bets are off as to what happens.

 

 

 

 

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

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

Hello

Can you please explain with pseudocode or code for both the methods. I target is the second one you described but first i will go with first one see the result and go on second one

george

Last Edited: Thu. Aug 8, 2019 - 12:38 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi i slolved the problem but i have an issue with low frequency below 1,5 Khz i am also getting output. What is the problem and what are the issue with mocrocontroller. The result i got is I am getting output below 1,5 KHz and between  3 to 5 Khz input frequency. I want to remove the issue getting output below 1.5 khz. Any sugessition?

george

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

Who can guess without seeing the actual code?