Arm Community
Site
Search
User
Site
Search
User
Support forums
Architectures and Processors forum
Question : The Definitive Guide to the ARM Cortex-M3
Jump...
Cancel
State
Not Answered
Locked
Locked
Replies
33 replies
Subscribers
348 subscribers
Views
24194 views
Users
0 members are here
Cortex-M3
Cortex-M
Options
Share
More actions
Cancel
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
over 12 years ago
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
guestposter guestposter
over 12 years ago
Note: This was originally posted on 23rd January 2010 at
http://forums.arm.com
Hi Miro,
Direct call is faster, but if your user tasks are running at non-privileged level, then you will need SVC to access some of the system functions (e.g. NVIC accesses). Alternatively a user task might be compiled separately from the rest of the application. In this way using SVC is easier because it doesn't need to know the address of the system function.
SVC need 12 clock cycles (or more) due to interrupt latency, and will consume more stack space. So I would rather use direct call if possible. (But then I am a hardware guy moving to software, so are lots of software issues I might not aware of
).
Yes, if a system function cannot be reentrant, then SVC is an easy way to ensure that only one task/ISR can use it at one time. Another solution is to use the PRIMASK or BASEPRI register which can change the current priority level. So when an IRQ handler is going to use an OS function that another IRQ might use and the function cannot be reentrant, you can use PRIMASK or BASEPRI to block the other IRQ.
In this way you can directly call the function, would that be okay for your application?
Cancel
Vote up
0
Vote down
Cancel
Reply
0
guestposter guestposter
over 12 years ago
Note: This was originally posted on 23rd January 2010 at
http://forums.arm.com
Hi Miro,
Direct call is faster, but if your user tasks are running at non-privileged level, then you will need SVC to access some of the system functions (e.g. NVIC accesses). Alternatively a user task might be compiled separately from the rest of the application. In this way using SVC is easier because it doesn't need to know the address of the system function.
SVC need 12 clock cycles (or more) due to interrupt latency, and will consume more stack space. So I would rather use direct call if possible. (But then I am a hardware guy moving to software, so are lots of software issues I might not aware of
).
Yes, if a system function cannot be reentrant, then SVC is an easy way to ensure that only one task/ISR can use it at one time. Another solution is to use the PRIMASK or BASEPRI register which can change the current priority level. So when an IRQ handler is going to use an OS function that another IRQ might use and the function cannot be reentrant, you can use PRIMASK or BASEPRI to block the other IRQ.
In this way you can directly call the function, would that be okay for your application?
Cancel
Vote up
0
Vote down
Cancel
Children
No data