Need someone to program timer function (AVR)

I am working on a project & have concluded that it's never going to get finished unless I get some assistance.

I need someone with considerable relevant experience, to program a timer function. Need it programmed in C (so that I can understand & modify it in the future). The device is an ATmega64 and I am using Imagecraft ICCAVR compiler.

Here's what I have in mind so far:

Function will be called by RTC or main program loop when the minute increments - returns "Setup".

512 day program is stored in consecutive eeprom locations - each day has a Schedule number (0-15) assigned to it. Example:

Starting Date = [# days since 1/0/2000]

Day Schedule# 1 3 2 3 3 3 4 3 5 3 6 2 7 2 8 5 9 3 etc.

The 16 schedules are also stored in eeprom. Each schedule has up to 16 events per day. Each event has a time and an associated "Setup" number.

Schedule Number 3 may look something like this: time Setup

0 (12:00 am), 3 360 (6:00 am), 1 480 (8:00 am), 12 840 (2:00 pm), 1 930 (3:30 pm), 12 1200 (8:00 pm), 3

Functionality:

12:00 AM Look up today's Schedule_Number & place in memory as Todays_Schedule_Number Evaluate for current "Setup" value return Setup

Each Minute: Evaluate time v. today's schedule & return "Setup"

This is as far as I have figured things so far. No doubt there are other issues to consider, which is why I am looking for someone who has already been there, who can do this efficiently and point out the things that I have not yet considered.

If interested, contact me at: scottk at iccom.com or

503-678-2849

Thanks, Scott Kelley

Reply to
Scott Kelley
Loading thread data ...

It didn't occur to you to ask in the imagecraft list ? They are very helpful there. Give them a try. Available at the imagecraft website.

Rene

--
Ing.Buero R.Tschaggelar - http://www.ibrtses.com
& commercial newsgroups - http://www.talkto.net
Reply to
Rene Tschaggelar

What seems to be your problem ?

Heres a start. // #include #include #include

#pragma INTERRUPT timer0_comp_isr:11 void timer0_comp_isr(void) {

if( PORTB & 0x80; ) // toggle pb.7 at each interrupt PORTB = 0x00; else PORTB = 0x80; }

void timer0_init(void) { TCCR0 = 0x00; //stop counter 0 TCNT0 = 0x00; //start count

// OCR0 = 0x40; //set compare 64 counts = 4uS @ 16Mhz // TCCR0 = 0x09; //start timer 0 @ 16mHz / no prescaler

// OCR0 = 0x40; //set compare 64 counts = 32uS // TCCR0 = 0x0A; //start timer 0 @ 16Mhz / 8

// OCR0 = 0x40; //set compare 64 counts = 256uS // TCCR0 = 0x0B; //start timer 0 @ 16Mhz / 64

OCR0 = 0x3e; //set compare 62 counts = ~1000uS 992uSec // OCR0 = 0x1f; //set compare 31 counts = ~500uS 498uSec TCCR0 = 0x0C; //start timer 0 @ 16Mhz / 256

// OCR0 = 0x40; //set compare 64 counts = 1024uS // TCCR0 = 0x0C; //start timer 0 @ 16Mhz / 256

// OCR0 = 0x40; //set compare 64 counts = 4098uS // TCCR0 = 0x0D; //start timer 0 @ 16Mhz / 1024

} void port_init(void) { PORTA = 0xff; DDRA = 0x00; PORTB = 0x00; DDRB = 0xff; PORTC = 0xFF; DDRC = 0x00; PORTD = 0x00; DDRD = 0xff; } //UART initialisation // desired baud rate: 38400 // actual: baud rate: 38400 // char size: 8 bit // parity: Disabled

void uart_init(void) { UCSRB = 0x00; //disable while setting baud rate // UCSRA = 0x00; UBRRL = 25; //set baud rate lo 38400 UBRRH = 0x00; //set baud rate hi UCSRB = 0x18; UCSRC = (1

Reply to
Donald

I sent you an approach you might use, but received "This address no longer accepts mail." for the above mentioned email address. So I'll just post it, but without my phone number included.

--- Scott, I may have understood your requirements it doesn't look like it would be too difficult to discuss, even over the phone. I'm not so far away from you (sounds like you might be Salem or at least Marion county.)

In any case, let me put what I understand in my own words:

The following declarations and definitions:

typedef unsigned int time_t; /* needs to hold up to 1440 */ typedef char setupID_t; /* only up to 15 or 16 */ typedef char scheduleID_t; /* only up to 15 or 16 */ typedef char itemcount_t; /* no more than 16, too */ typedef struct { time_t time; setupID_t setup; } item_t; typedef struct { item_t *items; itemcount_t count; } schedulelist_t;

/* In the following, define as many schedules as needed, with as many entries in each, as appears to be required. There may be more or fewer than 16 such arrays, if you like; and each array may have more or fewer than 16 events in them. */ item_t s01[]= { { time, setup# }, { time, setup# }, . . . { time, setup# } }; item_t s02[]= item_t s03[]= . . . item_t s16[]=

/* The following array simply provides a conversion from a schedule_t value (which is used as the array index) to a pointer to the appropriate schedule array, along with a count of entries in that array (necessary, of course.) */ schedulelist_t schedules[]= { { s01, sizeof( s01 ) / sizeof( s01[0] ) }, { s02, sizeof( s02 ) / sizeof( s02[0] ) }, . . . { s16, sizeof( s16 ) / sizeof( s16[0] ) } };

/* The following is a simple array of scheduleID_t's. This converts from the julian day number to the appropriate schedule. */ scheduleID_t daytosch[512];

I hope the above is clear enough, as regards setting up the needed structures and I hope it conforms to where you were hoping to head. (I also hope I didn't make some stupid error in writing it out.) What is perhaps missing from the above list is the actual setup routines to be invoked -- all you get from the above is a setup number. Somehow, you will need to apply that number. But I assume you can figure that out. If the above is sufficiently close, then other considerations are:

(1) You will need either some kind of base date used for computing the julian day number (that is, if you somehow keep dates in some calendar form) or else you will simply need to initialize the current day in some fashion and then maintain it over time.

(2) In maintaining the current day and time, you will need a timer event that provides a regular heart beat. It doesn't really matter whether this is fast or slow, just so long as you get at least a few "ticks" each minute. More than a few is okay, it just uses up more CPU. This timer will be an interrupt event. So it will not be called normally, but invoked by hardware. And you'll need to set that part of things up, correctly.

(3) You need to decide whether or not you want the timer interrupt actually performing the setup, based on the setup number, or if you can instead simply poll a setup number variable. If a variable is okay and you can poll it, you might use the special value of -1, for example, to mean "nothing to do, no schedule's timed event has been triggered yet." Then, if the variable ever changes from that value, you know that the timer interrupt has indicated that an event has just taken place.

The timer event might look like (c-like pseudo-code):

static volatile setupID_t setup; static time_t minute_t; static int day; /* or somesuch */

timer: /* whatever your heartbeat's definition of 'sub-minute' is: */ ++sub-minute; if (sub-minute rolls over on the minute) { sub-minute= 0; if (++minute >= 1440) { minute= 0; // handle day-wrapping, if needed -- not in spec, though if (++day >= 512) day= 0; // end of optional wrapping code schedule= &schedules[daytosch[day]]; } for ( n= 0; n < schedules->count; ++n ) if ( minute == (schedules->items)[n].time ) { if ( setup != -1 ) /* main didn't process the last setup!! */ ; setup= (schedule->items)[n].setup; break; } end-of-interrupt

main: for ( setup= -1; ; ) { auto setupID_t mysetup; while ( setup == -1 ) ; mysetup= setup; setup= -1; /* do something with 'mysetup' */ }

I think that's about it.

best of luck, Jon

Reply to
Jonathan Kirwan

add:

in case that wasn't clear.

And this part:

should have been:

I incorrectly used the plural form of schedule in a couple of places. And some of the parentheses weren't exactly required, though not bad.

I also didn't mention various initializations that would be required. But there's no point about those, just yet, until the rest has settled down.

best of luck, Jon

Reply to
Jonathan Kirwan

Below this line is a copy of the message.

Return-Path: Received: (qmail 31867 invoked from network); 8 Jan 2006 16:46:52

-0800 Received: from smtpauth.newman.easystreet.com (HELO smtpauth.easystreet.com) (206.102.12.11) by ip103.zzz.com with (DHE-RSA-AES256-SHA encrypted) SMTP; 8 Jan

2006 16:46:52 -0800 Received: from ELECTRONICS (pool-71-111-0-57.ptldor.dsl-w.verizon.net [71.111.0.57]) by smtpauth.easystreet.com (Postfix) with ESMTP id 2C2E8B0BA for ; Sun, 8 Jan 2006 16:48:53 -0800 (PST) From: Jonathan Kirwan To: "Scott Kelley" Subject: Re: Need someone to program timer function (AVR) Date: Sun, 08 Jan 2006 16:46:41 -0800 Message-ID: References: In-Reply-To: X-Mailer: Forte Agent 3.1/32.783 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable
Reply to
Jonathan Kirwan

I'm not looking for cash and I don't plan on doing much more than I have, except being available for some questions. I'm also local, perhaps a dozen miles away, so I can physically look him up if need be.

I wouldn't know. I have been away from the group for a while.

Sensible.

Understood.

Jon

Reply to
Jonathan Kirwan

Jon did call me, and he can verify that I do indeed exist. Unfortunately, my ISP is not so sure. They implemented a new system this last weekend, and in the process, disconnected this email address for most of the weekend, and lost all email that had been sent there.

What sorts of inaccurate things did I claim?

The referenced post was to this group on 10/04/2005. It is titled "timer system - any thoughts?". You responded twice on 10/08/2005. It was because your response indicated that you were particularly knowledgable in this field that I emailed you personally, as you and others pointed out some things which made it clear to me that if I am going to get this functioning properly from the get-go, I need to find someone who really knows what he is doing. I also, as you surmise, emailed two others whose response to the same post indicated that they too had a good deal of applicable experience with this type of function.

That the money would flow, is certainly something that I would expect to discuss, and about which I would expect that you or anyone would require specific arrangements before starting work to minimize your risk.

Paul, if I were desparate, I wouldn't have gone out of my way to personally email you and the other people who had shown themselves to be most knowledgable re. the subject.

Scott Kelley

Reply to
Scott Kelley

I didn't forget, typically someone has a price that they think their efforts are worth & it becomes a question of whether I am convinced that what they bring to the table makes that price a good value, or whether we can reach some other sort of an agreement.

Reply to
Scott Kelley

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.