UART transmission every 5 minutes using Timer.

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

Iam using AT tiny 1634 processor and i want to send data through UART and get it displayed through terminal .

 

I want to send the data through UART every 5 minutes using Timer,.

 

UART transmission every 5 minutes using Timer. 

 

Please help me.

S.Bharath

Last Edited: Tue. Jul 2, 2019 - 12:16 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Show what you have done so far.

 

(but anyway timing for periods like 5 minutes often involves just timing for shorter periods and counting them up - for example 5 minutes (300 seconds) is 3000 lots of 100ms. So if your timer cannot reach a complete 5 minutes then count up smaller time periods).

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

S.Bharath wrote:

I want to send the data through UART every 5 minutes using Timer,.

 

UART transmission every 5 minutes using Timer. 

 

Thats Easy.

 

Set up your timer to 'tick' every 10 milliseconds(or 100 milliseconds, adjust code accordingly)

In the Timer ISR, increment a volatile variable called 'tick'

In your MAIN loop, monitor 'tick', when 'tick' equals 100, increment global integer variable called 'seconds', and reset 'tick' to zero.

Monitor 'seconds', and when 'seconds' equals 300(the number of seconds in 5 minutes), Stop the timer, call a function that transmits your data out of the usart.  Then reset 'seconds' back to zero, reset 'tick' to zero, restart the timer.

 

That should get you going.

 

S.Bharath wrote:
Please help me.

I just did smiley  You now need to write the code.

 

Jim

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"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"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

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

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

You should start with an Arduino!

 

Jim

 

Click Link: Get Free Stock: Retire early! PM for strategy

share.robinhood.com/jamesc3274
stack gold/silver https://www.onegold.com/join/713...

 

 

 

 

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

 

1. Blink and LED or toggle a pin you can probe with a meter to see that you can run code.

 

2. Send a message through the uart and see it on the terminal.

 

3. Make the measurement or whatever to get the string you want to send to the terminal.

 

4. Set up a timer to count off seconds. Just because the short time frame is easier to test. Something like dividing the cpu clock. 

 

5. Cry because your timer just isn't right. This helps you find he correct timer settings.

 

6. Count off 300 of these seconds and send your message.

 

 

The largest known prime number: 282589933-1

It's easy to stop breaking the 10th commandment! Break the 8th instead. 

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

There is another solution: You can connect two timers in serial and use timer prescaler.

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

Arduino has a 32bit tick that increments every 1ms. The function to get tick is millis().
If you prepare the same one, you will find many application tips.

 

I assume 16 MHz operation.

 

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

//#define F_CPU 16000000UL

volatile uint32_t tick; // 1ms counter

ISR(TIM0_COMPA_vect){
    // 1ms periodic
    tick++;
}

void tick_init(void){
    // 16MHz / 64 / 250 = 1KHz
    TIMSK = (1 << OCIE0A);
    OCR0A = 249;
    TCCR0A = (1 << WGM01);
    TCCR0B = (1 << CS01) | (1 << CS00);
}

uint32_t millis(void){
    // Exclusive acquisition
    uint32_t tmp;
    cli();
    tmp = tick;
    sei();
    return tmp;
}

int main(void){
    uint32_t t_start;

    tick_init();
    sei();

    t_start = millis();
    while (1){
        if ((millis() - t_start) >= 300000){
            t_start += 300000;
            // 5min periodic
            // Execute transmission
        }
    }
}

 

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

I would add that, if you use a timer tick in the range of, say, 1 to 20 ms, not only can you count ticks to get your 300 second period, but in general you can use the same tick for many other timing chores in your program.  

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

The code in #7 should work, but you should avoid the need of cli around sei code.

 

Keep the timer variables as statics in the ISR, and set a flag every time 300 sec is gone (and check and clear it in main). 

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

sparrow2 wrote:

Keep the timer variables as statics in the ISR, and set a flag every time 300 sec is gone (and check and clear it in main).

I'll offer a counter-argument, which is that I have an aversion to having timing calculations inside the ISR, especially when the ISR tick is being used for multiple timings.  There is no right or wrong approach, it all reduces to a question of which is more understandable and maintainable for any particular programmer.

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

I have an aversion to having timing calculations inside the ISR

That may be true, since who wants to recalculate the same thing over & over....however, a simple ISR compare with a constant amount (say 300 sec), should be nearly the smallest code one can write, just a cp/cpi/cpc gets it done.  

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

avrcandies wrote:

I have an aversion to having timing calculations inside the ISR

That may be true, since who wants to recalculate the same thing over & over....however, a simple ISR compare with a constant amount (say 300 sec), should be nearly the smallest code one can write, just a cp/cpi/cpc gets it done.  

Yeah, it's not the clock cycles I'm concerned with, it's the fact that it involves placing what I consider higher-order code (specific timings and logic for specific program needs) inside a very low level ISR.  I don't have a hard and fast rule about it, but in general I'd rather just fetch a tick counter and do the timing logic outside the ISR, based on the counter value.  As is done in #7, except I like to compare directly against target values, so my code would look more like:

        if ((int32_t)(millis() - t_target) >= 0)
        {
            t_target += 300000;
            // 5min periodic
            // Execute transmission
        }
    }

 

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

From what I see in the datasheet, the  tiny1634 has 1 8bit timer, 1 16 bit timer and 1 watchdog timer. Any of these is capable of generating periodic interrupts.

Personally, I would use the WDT because the other timers are more "valuable" and could be needed for other things, like PWM.

 

I also prefer the method of keeping some global tick variable that is periodically incremented by the timer interrupt. The main code stream can use this variable for whatever purposes are needed.