• State Not Answered
  • Locked Locked
  • Replies 33 replies
  • Subscribers 349 subscribers
  • Views 23815 views
  • Users 0 members are here
2025 survey

We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.

Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Question : The Definitive Guide to the ARM Cortex-M3

Kenichi Kenichi
Note: This was originally posted on 11th December 2007 at http://forums.arm.com

Dear, all.

I am new in this forum.
Recently I studying Cortex-M3 core, so I bought book "The Definitive Guide to the ARM Cortex-M3" by Joseph Yiu.
This book is very good book and this explains most of unaswered questions by TRM or AALRM.

As I found some mistake in this book, I would like to feedback, but I could not find publisher's homepage. Then I found Josephe's name in this forum, I would like to ask here.

In page 42, there is fig 3.11 and 3.12 but this contents is same as fig 3.8 and 3.9.
Fig 3.8 and 3.9 should be some program list.

Can I get correct figure? Or where I should contact?
Please advise.

Kenichi
Parents
  • 0
    Note: This was originally posted on 23rd January 2010 at http://forums.arm.com

    Thanks Joseph,

    I think it is pointless to discuss the case when we have a stacked IRQ before the SYSTICK. The IRQ may have pushed some top registers so the task context cannot be saved easily.

    The only option is to implement the context switching from some exception that has the lowest priority.

    Yes, it if possible to have a mid-priority level SVC so that an OS aware IRQ handler can use the SVC function. But instead of using SVC, you might able to call the SVC function directly rather than using SVC exception.


    I am afraid that is not a good idea. We use SVC for system functions that are not reentrant. So if you have more than one IRQ level using kernel functions then you can't call them directly. Otherwise imagine that IRQ1 has called a system function and it is interrupted from IRQ2 that can also call the same or similar function.

    Hm... actually... you are right ;-) You can use direct calls, but you need to rise the priority first (or disable the IRQs). But then the question is why you would use two different approaches? One for tasks and one for ISRs... Here we need to compare the SVC handler code and the priority veneer code. But if the SVC is the faster then we should use for both tasks and ISRs. Otherwise we should use the "direct" approach.

    btw. I don't like the new SVC very much ;-) For ARM7 I had a SWI handler of only 5 instructions and that was the only overhead. No stack usage at all. Even most of my system functions were stackless so everything was fast & simple. Now with the SWI the handler is going to be about twice as big and slower. So I may consider the direct call as well ;-)
Reply
  • 0
    Note: This was originally posted on 23rd January 2010 at http://forums.arm.com

    Thanks Joseph,

    I think it is pointless to discuss the case when we have a stacked IRQ before the SYSTICK. The IRQ may have pushed some top registers so the task context cannot be saved easily.

    The only option is to implement the context switching from some exception that has the lowest priority.

    Yes, it if possible to have a mid-priority level SVC so that an OS aware IRQ handler can use the SVC function. But instead of using SVC, you might able to call the SVC function directly rather than using SVC exception.


    I am afraid that is not a good idea. We use SVC for system functions that are not reentrant. So if you have more than one IRQ level using kernel functions then you can't call them directly. Otherwise imagine that IRQ1 has called a system function and it is interrupted from IRQ2 that can also call the same or similar function.

    Hm... actually... you are right ;-) You can use direct calls, but you need to rise the priority first (or disable the IRQs). But then the question is why you would use two different approaches? One for tasks and one for ISRs... Here we need to compare the SVC handler code and the priority veneer code. But if the SVC is the faster then we should use for both tasks and ISRs. Otherwise we should use the "direct" approach.

    btw. I don't like the new SVC very much ;-) For ARM7 I had a SWI handler of only 5 instructions and that was the only overhead. No stack usage at all. Even most of my system functions were stackless so everything was fast & simple. Now with the SWI the handler is going to be about twice as big and slower. So I may consider the direct call as well ;-)
Children
No data