Interrupts ?

Agent420

Hello - new Propeller user, first post, plz be gentle [noparse];)[/noparse]

I've done some quick searching of the forum, scanned the faqs and tips stickies etc.

I understand the multi-core nature of the Propeller does not include interrupts as we have known them in the past.

So how to handle immediate operations on an external pin...· Assign a dedicated cog to the task?

I am looking to incorporate the 1hz signal from a DS1307 clock chip into my program, using that signal to immediately update a dsiplay.· But I can think of some similar tasks where an 'emulation' of interrupts such as this would be needed.

Hopefully this is not the dumb question of the week [noparse]:)[/noparse]· I didn't see it mentioned anywhere...

Thanks!

bambino

Your comparision of Cogs to interrupts is OK, however, at 1 hz there is still a lot of resources left in that cog to possible update your display too. Depends on what type of display your using. If it is a serial LCD, then of course one cog could do that and more.

Rayman

You don't really need the DS1307 to derive a 1Hz signal... If you're Prop has a crystal oscillator, you can make your own, just about as accurate, 1Hz signal...

And, basically you have to do polling because there are no interupts, not a problem with multiple cogs.

Agent420

Rayman said...
You don't really need the DS1307 to derive a 1Hz signal... If you're Prop has a crystal oscillator, you can make your own, just about as accurate, 1Hz signal...

And, basically you have to do polling because there are no interupts, not a problem with multiple cogs.

Thanks for the replies.

I guess the polling comparison is what I was after - the term escaped me earlier.

The DS1307 aside, if a design requires an external interrupt like signal, and that signal is of some level of importance as to be acted on immediately, the 'Propeller way' of dealing with that is to assign a cog with the dedicated task of polling those pins?

I guess for signals of importance where the polling could be incorporated into other code, you just poll when convenient, and not dedicate a new cog to the task.


But as for my DS1307 example, for a real time clock, I was under the impression that 32.768 watch crystals were significantly more accurate (especially over days+) than high speed crystals.· Plus I'd like battery backup of time.· And it saves me writing calender code [noparse];)[/noparse]



Post Edited (Agent420) : 4/30/2008 6:28:51 PM GMT

simonl

Agent420 said...
the 'Propeller way' of dealing with that is to assign a cog with the dedicated task of polling those pins?

Yup - dedicating a COG would do it

What others are saying is that, whilst completely dedicating a COG will do what you want, depending on the criticality of the task you may be able to use the same COG for other things too - you just need to be sure of you code's timing to ensure you don't miss the event you're watching for.

Gees, the Propeller's so flexible it still surprises me

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,

Simon

---

www.norfolkhelicopterclub.co.uk
You'll always have as many take-offs as landings, the trick is to be sure you can take-off again ;-)
BTW: I type as I'm thinking, so please don't take any offense at my writing style

Rayman

BTW:· You might want to check out my DS1307 code:
http://forums.parallax.com/showthread.php?p=691564

It has a bunch of time functions...

Agent420

Thanks - I think I am starting to get the picture.· This one aspect is probably my biggest hurdle in paradigm change from 'conventional' controller programming.

Along a related topic, how do you folks deal with the timers?· Previous controller architectures usually required setting interrupt routines so that when a timer fired it would jump to an isr; this all running in the bacjground of sequential code.· The timer examples I have examined so far (ie IO Timing Basics Lab PDF) on the Propeller are typically wait like statements that seem to hold up code execution until the timer reaches a set point.· Is this another example of when you would typically assign another cog the timer task?

·

hippy

Yes, this is another case where a dedicated Cog can be used. That it's waiting doesn't stop any other Cog from running, when the wait ends, that Cog can set a flag in Hub memory for others to detect or set an output I/O line ( if there's one available for such use ) which others can read.

The Cog could also poll the CNT value rather than wait to see if the timer should generate an 'interrupt'. It all depends on what latency you need.

If the Cog is polling the CNT value, it can also poll other things, which is what was being talked about when saying a Cog can do more than one thing and doesn't need to be dedicated to a single task. A single Cog could set a timer 'interrupt flag' and also set an 'interrupt flag' through monitoring an input pin and so on.

A single Cog could be monitoring one timer and setting a single 'interrupt flag', or it could be monitoring multiple timers and setting many 'interrupt flags'.

simonl

Might also be worth seeing if CTR(A/B) and PHS(A/B) would be useful.

I'm not 'up' on these yet, but my understanding is that these can be set to count independently and your COG would only have to monitor their register(s). That's two psuedo-interrupts per COG, and they'll be as accurate as your Propeller clock source

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,

Simon

---

www.norfolkhelicopterclub.co.uk
You'll always have as many take-offs as landings, the trick is to be sure you can take-off again ;-)
BTW: I type as I'm thinking, so please don't take any offense at my writing style