Home arrow Support arrow Forums

Luminary Micro Forums
home | post reply | threaded view | PDF | help | rules
Boardwalk :: Forum List Luminary Micro Forums Suggestions
<< Start < Prev 1 2 3 Next > End >>

ppz2005

Junior Boarder 		Click here to see the profile of this user

2008/08/06 22:26

Re:add user interrupts on future device

Yes,I confirm that user interrupts in MCUs is really useful.No matter how designers use the user interrupts,for example,driving 'user task' or driving peripherals,user interrupts benefit the realtime ability,program simplicity,especially,with the Cortex-M3 NVIC.
Traditional OS are not the only solution(for example,no OSs,or,state machines mothod),especially for most little,deeply embeded use.Most of Luminary MCUs is for this market.So,I think it's a good,new idea for Luminary.
I hope to know if it is a good or bad idea.
thanks,

login or register to reply

rocksoft

Expert Boarder 		Click here to see the profile of this user

2008/08/07 02:03

Re:add user interrupts on future device

I'm still not sure what it is you're trying to do, can you explain further? ...and perhaps why a timer can't be use for your periodic interrupt? Also... if you do not use a particular interrupt for a peripheral you can use it's interrupt by the software pend method, for example maybe one of the GPIO blocks you are not using.

Liam.

login or register to reply

cb1

Platinum Boarder 		Click here to see the profile of this user

2008/08/07 17:36

Re:add user interrupts on future device

Agree with rocksoft - timer usually is ideal - however with Cortex M3 SysTick (methinks) is even better. Its use frees the more complex timers - we simply count the desired number of "systicks" - and generate unique interrupts upon a "match."

It appears that you are weighing use of regular interrupts versus using some rtos. We may be able to better assist if you could further/deeper list your goals and objectives...

login or register to reply

ppz2005

Junior Boarder 		Click here to see the profile of this user

2008/08/07 21:54

Re:add user interrupts on future device

I mean I can construct a real time system to use a interrupt as a 'task'.For example:

int0:GPIO int handle,just a normal int handle
int1:other int handle
...
userint0:'task0',just like a task in an OS
userint1:'task1'
...
main routine:'empty task',typically making MCU sleepping

Here,a 'task' is the same as a task in an system with an OS,but it would return when it complete.The interrupts for peripheral have the highest priority,and userint0 is higher than userint1,...,main routine has the lowest priority.
An interrupt routine can send a software interrupt pending to any other interrupt handler or 'task',and then interrupt controler would schedule 'tasks' according to their interrupt priority with no time. And context switch is in fact a real interrupt switch,so it is very fast.
Now,I get a complete system with task schedule,context switch,and no task stack has to be used.Code is compact.
Maybe,it is a very little system,and it cannot complete large application,but little application is more.
In a typical application with OS,context switch time is more than 5 us(assume main clock is 50MHz),but it is only less than 1 us in such a interrupt drive system.For many litte application,speed is important.Speed means more ability,less power dissipation,etc..
Just as rocksoft discribed,we can use an interrupt of an unused peripheral as an user interrupt,but we have to turn this peripheral on,and it would infect other signal somehow,and such interrupts are too less.All reserve interrupt is not available too.
Thank you for concerning this subject.
And maybe I cannot express myself very accurately,or more,correctly,for English is not my native language.
regards,

login or register to reply

rocksoft

Expert Boarder 		Click here to see the profile of this user

2008/08/08 02:22

Re:add user interrupts on future device

Hi,

Thanks for the description, I understand now. I actually do a very similar thing.

I have a circular "queue" of functions in software and a main loop to either sleep if the queue is empty or call the functions on the queue if they exists. The functions just execute and return.

Both real interrupts and user code can add themselves or other functions to the queue and there is no interrupt or context switch overhead just the addition and removal from the queue. You can also setup timers to add things to the queue for periodic events.

This maybe isn't as fast as the system you describe, it is fairly fast though as the main loop and queue addition are assembly language coded. It isn't "real time" but it's generally real time enough if you are careful to return to the main loop quickly.

What I do is if the processing is going to take a long time the function can implement a state machine where it does a little work and then re-schedules itself for more work later. I run a TCP/IP stack, a USB stack and various other tasks "concurrently" on my LM3S6965 board using this method.

The main problem is that it is quiet hard to program for complex tasks but if your system is simple it might be a suitable solution.

Perhaps other members have better ideas?

Regards,

Liam.

login or register to reply

dereksoftstuff

Expert Boarder 		Click here to see the profile of this user

2008/08/08 03:13

Re:add user interrupts on future device

Interesting topic, event scheduling. I've done a similar thing. see Events - using interrupt event queue and cyclic event queues, no stacks or context switches or pre-emption, events all run to completion - real-time system - low overhead from scheduler - typically < 2us scheduler latency (interrupts)(@50MHz).

Having ISRs send interrupts to other ISRs which send interrupts to other ISRs which send ... - adds no value. There is one processor and there is one processor clock, it doesn't matter whether you spend your time (clocks) in an ISR or in a thread - it's the same time.

The question is whether you want a RTOS or a single thread system (+ISRs). With the RTOS you gain pre-emption but lose with stacks/context switches.

Like rocksoft says, you should always design your system to have many quick events, not a few slow events, so that it responds well. Then the difference between an RTOS and a non-RTOS begins to blur.

Both are good - it depends on your application ...

login or register to reply
<< Start < Prev 1 2 3 Next > End >>
Boardwalk :: Forum List Luminary Micro Forums Suggestions

Luminary Micro Forums