explanation about timer0!!

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

hello freaks,

the following code is for a counter using T0 and it displays the counts on 7 segment displays.

but it didn't wok properly till i changed the delay time form 1 ms to 10 ms.

 

can i please get an explanation for that?

#define  F_CPU 1000000ul
#include <avr/io.h>
#include <util/delay.h>	
#define SegOne   0x01
#define SegTwo   0x02
#define SegThree 0x04
int main(void)
{
	TCCR0 |= (1<<CS02) | (1<<CS01);
	TCCR0 &= ~(1<<CS00);
	DDRC = 0xff;
	DDRD = 0xff;
	char seg_code[]={0xc0,0xf9,0xa4,0xb0,0x99,0x92,0x82,0xf8,0x80,0x90};
	int i,r;
    while (1) 
    {
		r = TCNT0;
		i=r/100;
		r=r%100;
		PORTD = SegOne;
		PORTC= seg_code[i];
		_delay_ms(1);
		i=r/10;
		r=r%10;
		PORTD = SegTwo;
		PORTC= seg_code[i];
		_delay_ms(1);
		i=r/1;
		PORTD = SegThree;
		PORTC= seg_code[i];
		_delay_ms(1);
		
    }
}

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

Looks like Proteus.

So what sort of output are you getting from your proteus simulator?

I suggest you put in some effort to figure out how all the tools in your simulator work.

Ayman89 wrote:
it didn't wok properly
Is a very bad fault description.

Very likely there is no bug, but you only do not understand what your simulator is doing.

 

Instead. I want to give some more general advise.

With the way you are writing code you are currently on a road into the swamp.

Soon your road will get narrower and narrower untill you fall of and are completely lost.

 

You will not see it in a simulator, but multiplexing displays is a non trivial task.

The brightness of the segments will vary with the time a segment is on.

Therefore usually an interrupt function is used to do the multiplexing.

Interrupt functions are usually also kept as small as possible, because they interrupt the normal program flow.

And, even more important, on the AVR architecture, you only have a single interrupt level.

Writing code that interrupts the interrupts can be done, but is ... not advisable for beginners.

 

So instead of trying to debug your code, I want to advise some steps which will learn you to write better code.

 

1). Learn to use functions. Write a function to divide your number into single digits, and then put each digit in a segment buffer.

2). Write a function to read the segment buffers and output them to the display.

3). Learn to work with interrupts.

4). Use a (timer) interrupt and put the code from "2)." in it to multiplex the LCD.

5). Use real hardware instead of a simulator. Simulators are never perfect.

 

After these steps the ISR will regularly upate your multiplexed display, and you can use the function you wrote in the first step whenever you want to change the contents of the display.

Your main program loop is then empty from all those delay functions and you can do something there without having to worry about the display output.

 

The link below is to a current topic from another beginner, and it turned into a tutorial on how to get interrupts going and things you have to think about while working with interrupts.

https://www.avrfreaks.net/forum/why-led-blinking-code-doesnt-work

Doing magic with a USD 7 Logic Analyser: https://www.avrfreaks.net/comment/2421756#comment-2421756

Bunch of old projects with AVR's: http://www.hoevendesign.com

Last Edited: Sat. Oct 6, 2018 - 12:16 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Why did you create another thread asking the same question?

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

lol -- at the risk of repeating from above and the other posting of this, how does OP expect to see a change of an LED in a millisecond?  [edit simulation undoubtedly] But I'd guess the stated F_CPU of 1MHz doesn't match a "real" 8MHz.  OP is lying to his compiler.

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.

Last Edited: Sat. Oct 6, 2018 - 05:30 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Perhaps delete the other thread - The other is full of "noise" and at least this one has an inline picture.

 

Perhaps Proteus is actually very realistic in this regard and is turning on the LED for 1ms. Unfortunately our computer monitors refresh typically at 60Hz I.e. one frame every 16.667ms.

If the OP were to build this circuit for real he may well see his digits illuminate.