Uninterrupted task + asynchronous ISR of no latency.

Log in or register to post comments
Go To Last Post
6 posts / 0 new
Author
Message
Brutte
Brutte's picture
Level: Raving Lunatic
Joined: Thu. Oct 5, 2006
Posts: 3229 View posts
Location: Poland
#1
Posted by Brutte: Tue. Mar 15, 2011 - 09:02 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Below I give an example of a simple task (sending data through SPI) which is processed with maximal speed (SPI sends 10Mb/s at f_cpu=20MHz, m644p) while processing ISRs without latency. The task is actually not interrupted at any moment (SPI sends without bit spaces) but mirrored in ISRs.

Does anybody know how such meshing of codes is named?

Attachment(s): 

Package icon AVR Studio 4.18b692 simulator_2 project attached (not tested on real hardware).

No RSTDISBL, no fun!

Tags:

AVR Microcontrollers, megaAVR and tinyAVR
Top
Bronze Marktheusch
theusch's picture
Level: 10k+ Postman
Joined: Mon. Feb 19, 2001
Posts: 39894 View posts
Location: Wisconsin USA
Posted by theusch: Tue. Mar 15, 2011 - 09:10 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Does anybody know how such meshing of codes is named?

I have no idea.

Nowadays, if this operation were critical to my app, I'd use a processor family with DMA and "streaming" operations on SPI/USART/I2S/etc. Xmega, recent ARM generations, MSP430 that I know of; probably (many?) more families.

Lee

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.

Top
Brutte
Brutte's picture
Level: Raving Lunatic
Joined: Thu. Oct 5, 2006
Posts: 3229 View posts
Location: Poland
Posted by Brutte: Fri. Mar 18, 2011 - 03:35 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
I'd use a processor family with DMA

Actually, SPI was just an example. And it is not about DMA (the book must be about something), but the style, the way context is switched. But thanks for the input!

So first you execute (A+B) tasks, then you switch to (B+C) tasks. Eventually A was suspended, C was resumed, but B was.. Nothing really happened with B, it is executing just like before. In this case several instances of B code must be meshed (Here first with A and second with C).

But have no idea how this method is called. Any clues?

No RSTDISBL, no fun!

Top
jayjay1974
jayjay1974's picture
Level: Raving Lunatic
Joined: Wed. Oct 30, 2002
Posts: 5763 View posts
Location: The Netherlands
Posted by jayjay1974: Fri. Mar 18, 2011 - 04:26 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Non-deterministic unprioritzed tickless non-pre-emptive stochastic random scheduling?

Top
glitch
glitch's picture
Level: Raving Lunatic
Joined: Sat. Jan 12, 2002
Posts: 8620 View posts
Location: Canada
Posted by glitch: Fri. Mar 18, 2011 - 05:45 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

but you are adding latency, as you still have to perform operations for 'B' while executing 'A' or 'C'. So while your ISR may start to execute immediately, the actual path through code is slower, as it must yield to the higher priority 'B' task. Interrupt latency is not about time to start of execution of the code [though it is often measured this way] it is about time to servicing the hardware that caused the interrupt. Having said that, as long as you can service the event before the next event, or the hardware has to wait for new data, there is no problem with the added latency.

So what you have created is a hard-coded priority system, where one task has has higher priority, than even ISR's.

Note that you can achieve the same effect, by allowing nested interrupts . [but only by the higher priority one - SPI in this case], and this does not require any mirroring of code.

Writing code is like having sex.... make one little mistake, and you're supporting it for life.

Top
Brutte
Brutte's picture
Level: Raving Lunatic
Joined: Thu. Oct 5, 2006
Posts: 3229 View posts
Location: Poland
Posted by Brutte: Sat. Mar 19, 2011 - 04:40 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
it is about time to servicing the hardware that caused the interrupt.

Definitions differ, but generally yes, it is the completion of the task (updating hardware) we are interested in.
Quote:
the actual path through code is slower

Obviously you have to execute all the code + overhead. What you can do is to reduce overhead and still meet the constrains given by selecting appropriate sequence of execution.
Quote:
Note that you can achieve the same effect, by allowing nested interrupts

When first you service C(aka ISR), interrupt it, then B(aka SPI)? This gives two overheads of calling ISR (changing context is made twice). And because of that I am afraid it will not meet B task constrains. Similar effect, no mirroring code but different performance.
As usual, "There are many ways to skin a cat". Smaller code but longer execution time.

Quote:
So what you have created is a hard-coded priority system, where one task has higher priority, than even ISR's.

I like your definition (unlike jayjay1974's)! B task executes with the highest priority, what is more, it cannot be interrupted, even though cpu is servicing ISRs at the same time. I gave the example with SPI sending (which is so simple that often made in hardware, aka DMA), but the very same can be made with for example a scheduler or any other high priority code.

Does anybody know programming language, where execution constrains can be stated explicitly (while coding or compiling)? You can define "B has higher priority than A", but it is not what the designer cares about. He cares about "Under given conditions B must be serviced not later than 1s after it is raised" and meeting only these types of constrains has any practical use. Isn't it a compiler's job to select the strategy/sequence/policy and check if these requirements

cannot be satisfied:

    -no way, cpu is too slow to meet all these constrains, -not enough RAM for that short latency
    -program memory too low and I cannot mirror scheduler code in ISRs.
or can be:
    - compilation OK, all constrains met.
?

No RSTDISBL, no fun!

Top