Changing to a dedicated stack in an interrupt routine

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

Hi,

Is there a "best" way to swap to a dedicated interrupt stack in an ISR?

 

If I use the naked attribute then I can change the Sp and save... but I lose the intelligence of the compiler in knowing which registers need to be saved, and must save all registers. Is there some way to change the SP and then have the usual compiler prologue run?

 

Thanks in advance for any ideas.

 

Greg

regards
Greg

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

ASM ISR that swaps the stack and then calls the C ISR?  You might end up saving the register(s) you use to switch SPs more than once...

Any of the RTOS implementations for AVR probably ends up doing something like this.

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


FreeRTOS has details of a specific implementation and the one they chose to use as way of illustration is actually the AVR one so it works through the details of how FreeRTOS works on the AVR. It starts here:

 

https://www.freertos.org/impleme...

 

(just keep following the Next: links on each page).

 

Read all the pages under this section:

 

 

Eventually you will arrive at:

 

https://www.freertos.org/impleme...

https://www.freertos.org/impleme...

 

That shows their TCB/stack switching.

 

 

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

gregd99 wrote:
Is there a "best" way to swap to a dedicated interrupt stack in an ISR?[ (my emphasis) /quote]

Please state the reason for the stack switch-over. Are you performing a context switch in regard to a pre-emptive task switcher or some other reason ?

 

I would have thought that purely for an interrupt task you would want as fast a response as possible and changing stacks is NOT going to give you that.

 

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

 

Yes.... but...

In going for smallish RAM footprint (Tiny85) I am prepared to trade time for space .

 

Another question is whether this is worth the effort :-)

regards
Greg

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

Thanks. I had seen much of that.... but not all.

The Free-RTOS idea that seems best to link to what I was thinking is the "deferred interrupt" idea where yo take the stack hit in a deferred task with minimal usage in the ISR.

 

That probably has some application, but for hw i/o not keen.

 

Conclusion is probably to stop trying so hard to save a few bytes of RAM!

 

Thanks again.

Greg

regards
Greg

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

gregd99 wrote:
Another question is whether this is worth the effort :-)
I have no idea on earth why you think an 8K micro would benefit from an RTOS. There is only so much flash, RAM and CPu time to go round and you start eating it (possibly considerable quantities) as soon as you start adding an OS.

 

Let's face it most embedded apps are a main loop and a handful of ISRs and that is it.

 

You don't usually reach such complexity, with so many parallel threads of execution required that it must be handled by an executive OS until you are maybe looing at 64K or more of code.

 

I know I was he original poster an maintainer of:

 

https://www.avrfreaks.net/forum/...

 

but that's simply because people kept asking "what RTOS can I run on an AVR?". But just because you can does not mean you should !!

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

clawson wrote:

But just because you can does not mean you should !!

 

Absolutely. Understand there are many other ways, and that in principle simple is best.

 

However, it turns out that I can run a handful of tasks on a tiny85 and it is sort of nice to be able to use some high level ideas. Also nice to see what is possible without resorting to extreme coding approaches.

regards
Greg

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

But an ATtiny85 only has 512 bytes of SRAM. I remember running an experiment on a mega168 (1K SRAM) using FreeRTOS and I found I could only comfortably accommodate about five FreeRTOS tasks in 1K. So you don't have a lot of wiggle room in a micro with 0.5K !

 

What do you think an OS actually "brings" to your solution?

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

@OP:

Task switcher?

OS?

Something else?

What are you actually trying to accomplish that would

be advanced by playing with the stack pointer?

Moderation in all things. -- ancient proverb

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

skeeve wrote:

@OP:

What are you actually trying to accomplish that would be advanced by playing with the stack pointer?

A tiny executive with timers/semaphores/queues.

regards
Greg

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

clawson wrote:

What do you think an OS actually "brings" to your solution?

Some simpler programming.

Everything is also possible with flags/interrupt counters etc.... but it is messy.

 

The tradeoff is complexity in getting the executive working - I think everyone has some sort of framework they re-use from project to project - and.... care with use of stacks. The minimum stack size is 32+1+2=35 bytes (registers+psw+return address). Allowing for local and global vars, I seem to be able to run half a dozen tasks without too much difficulty. Stacks are all marked with a value so that overflow can be detected... but when that happens it does not lead to happiness.

 

Greg

regards
Greg

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

gregd99 wrote:
Some simpler programming.
"Composability"

gregd99 wrote:
Stacks are all marked with a value so that overflow can be detected
SP can be compared to a "high-water" caution and/or warning limit in a prologue.

Some CPU architectures implement stack pointer checking in hardware.

gregd99 wrote:
... but when that happens it does not lead to happiness.
... leads to an assertion; ideally enough CPU registers and output signal(s) to indicate a stack overflow.

 


https://youtu.be/o3eyz1gEqGU?t=561 for 20s in Beyond the RTOS - Part 1: Concurrency & "spaghetti" as main challenges of professional developers - YouTube (18m56s)

 

Stack Overflow Detection Using Data Breakpoint | Microchip Studio

megaAVR OCD has data breakpoints whereas debugWIRE doesn't.

 

"Dare to be naïve." - Buckminster Fuller

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

gchapman wrote:

gregd99 wrote:

Stacks are all marked with a value so that overflow can be detected

SP can be compared to a "high-water" caution and/or warning limit in a prologue.

All this on a Tiny85 with 512 bytes of SRAM IIRC.  Remarkable.  Save all 32 GP registers and other important stuff and leave some working room ... how many times?  To what end, again?  Perhaps give a complete example of this class of app, with any traditional way, and the improved RTOS way, and then I can be ejumacaited. 

 

Yes, I've packed a lot of app over the years into Mega8/Mega48/Mega88/Tiny45/Tiny85 -class apps.  Funny -- never once did I feel that switching stacks, nor tasking, nor preemption, would help me. 

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.

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

theusch wrote:
... and leave some working room
By analysis can identify the worst case stack usage; tools aid so don't need to detect stack overflow.

 

StackAnalyzer: Stack Usage Analysis (AbsInt) due to Other stack-usage analysis tools and Bound-T time and stack analyser

AVR | 7. Machine Specific Topics — GNATstack 20.0w documentation (AdaCore)

 


Mastering stack and heap for system reliability: Part 1 – Calculating stack size - Embedded.com

How to Prevent and Detect Stack Overflow | Barr Group

[1/4 page]

Slide 6: How Many Stacks?

[GCC, IAR, PIC, RTOS]

...

[mid-page]

Slide 12: Monitoring Stack via Debugger

...

Slide 14: Runtime Stack Monitoring

...

Slide 16: Software-Based Stack Monitoring

...

[2/3 page]

Slide 18: An Ounce of Prevention…

...

tiny85 sits pretty (available, 8 KB program space, very low pin count) with no follow-on in AVRxt (4 KB max for low pin count) though AVRxt UPDI can transmit the stack pointer.

On Stacks - The Embedded Muse 309 by Jack Ganssle

Are We Shooting Ourselves in the Foot with Stack Overflow? « State Space by Miro Samek

 

GCC :

 

"Dare to be naïve." - Buckminster Fuller

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

Some really great info there.

 

I think you might have done this before! laugh

regards
Greg

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

mid-80s

A junior engineer learned from senior engineers who documented timing and sizing for all source code units (assembly language)

Though CDP1802 can have mini-computer amounts of RAM that was unusual as the price was very expensive.

Philae | AVR Freaks

 

"Dare to be naïve." - Buckminster Fuller