I use Crossworks and normally I've been using the register/bit names in the
crossworks device header files to access the device registers, e.g.
PCONP|=PCONP_PCUART3; to turn on the power for uart 3.
The Crossworks device header file has all the bits defined in each register in
the format _
However recently I've been using an NXP example file which uses the CMSIS
register definitions. The CMSIS definitions however do not seem to have any bit
definitions, so you just end up with meaningless numbers in the code...
LPC_SC->PCONP|=(1<<25); //enable uart3
Is there a better way to do this which I am missing?
--
Tim Mitchell
bit names in CMSIS
Started by ●March 2, 2012
Reply by ●March 2, 20122012-03-02
Tim,
> I use Crossworks and normally I've been using the register/bit names in
the
> crossworks device header files to access the device registers, e.g.
> PCONP|=PCONP_PCUART3; to turn on the power for uart 3.
> The Crossworks device header file has all the bits defined in each
register in
> the format _
>
> However recently I've been using an NXP example file which uses the CMSIS
> register definitions. The CMSIS definitions however do not seem to have
any
> bit definitions, so you just end up with meaningless numbers in the
code...
> LPC_SC->PCONP|=(1<<25); //enable uart3
>
> Is there a better way to do this which I am missing?
The unfortunate downside of CMSIS implementation. I would say that the old
CrossWorks header files are probably going to be legacy items from here on
in with new Cortex-M devices because ARM have come up with CMSIS and more
vendors are getting on board--even the ones that were first out of the block
like Luminary and NXP. The SVD files are pretty good from many vendors,
but, well, not using CMSIS is probably working against the tide.
I do not believe there is a way for customers to directly feed CMSIS
experience back to ARM; it is probably best done through vendors for the
specific vendor CMSIS files.
--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
SolderCore running Defender... http://www.vimeo.com/25709426
> I use Crossworks and normally I've been using the register/bit names in
the
> crossworks device header files to access the device registers, e.g.
> PCONP|=PCONP_PCUART3; to turn on the power for uart 3.
> The Crossworks device header file has all the bits defined in each
register in
> the format _
>
> However recently I've been using an NXP example file which uses the CMSIS
> register definitions. The CMSIS definitions however do not seem to have
any
> bit definitions, so you just end up with meaningless numbers in the
code...
> LPC_SC->PCONP|=(1<<25); //enable uart3
>
> Is there a better way to do this which I am missing?
The unfortunate downside of CMSIS implementation. I would say that the old
CrossWorks header files are probably going to be legacy items from here on
in with new Cortex-M devices because ARM have come up with CMSIS and more
vendors are getting on board--even the ones that were first out of the block
like Luminary and NXP. The SVD files are pretty good from many vendors,
but, well, not using CMSIS is probably working against the tide.
I do not believe there is a way for customers to directly feed CMSIS
experience back to ARM; it is probably best done through vendors for the
specific vendor CMSIS files.
--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
SolderCore running Defender... http://www.vimeo.com/25709426
Reply by ●March 2, 20122012-03-02
----Original Message----
From: l...
[mailto:l...] On Behalf Of Paul Curtis
Sent: 02 March 2012 10:47 To: l...
Subject: RE: [lpc2000] bit names in CMSIS
> The unfortunate downside of CMSIS implementation. I
> would say that the old
> CrossWorks header files are probably going to be legacy
> items from here on
> in with new Cortex-M devices because ARM have come up
> with CMSIS and more
> vendors are getting on board--even the ones that were
> first out of the block
> like Luminary and NXP. The SVD files are pretty good
> from many vendors,
> but, well, not using CMSIS is probably working against
> the tide.
All true, I am starting to use the CMSIS definitions for new jobs because of this.
So there are no bit definitions because NXP haven't provided them?
--
Tim Mitchell
From: l...
[mailto:l...] On Behalf Of Paul Curtis
Sent: 02 March 2012 10:47 To: l...
Subject: RE: [lpc2000] bit names in CMSIS
> The unfortunate downside of CMSIS implementation. I
> would say that the old
> CrossWorks header files are probably going to be legacy
> items from here on
> in with new Cortex-M devices because ARM have come up
> with CMSIS and more
> vendors are getting on board--even the ones that were
> first out of the block
> like Luminary and NXP. The SVD files are pretty good
> from many vendors,
> but, well, not using CMSIS is probably working against
> the tide.
All true, I am starting to use the CMSIS definitions for new jobs because of this.
So there are no bit definitions because NXP haven't provided them?
--
Tim Mitchell
Reply by ●March 2, 20122012-03-02
> > The unfortunate downside of CMSIS implementation.
I would say that
> > the old CrossWorks header files are probably going to be legacy items
> > from here on in with new Cortex-M devices because ARM have come up
> > with CMSIS and more vendors are getting on board--even the ones that
> > were first out of the block like Luminary and NXP. The SVD files are
> > pretty good from many vendors, but, well, not using CMSIS is probably
> > working against the tide.
>
>
> All true, I am starting to use the CMSIS definitions for new jobs because
of
> this.
>
> So there are no bit definitions because NXP haven't provided them?
Correct. NXP are responsible for NXP's CMSIS files--ARM are not. Take a
look at the EFM32 CMSIS files--I believe you'll find they are much, much
bigger!
--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
SolderCore running Defender... http://www.vimeo.com/25709426
> > the old CrossWorks header files are probably going to be legacy items
> > from here on in with new Cortex-M devices because ARM have come up
> > with CMSIS and more vendors are getting on board--even the ones that
> > were first out of the block like Luminary and NXP. The SVD files are
> > pretty good from many vendors, but, well, not using CMSIS is probably
> > working against the tide.
>
>
> All true, I am starting to use the CMSIS definitions for new jobs because
of
> this.
>
> So there are no bit definitions because NXP haven't provided them?
Correct. NXP are responsible for NXP's CMSIS files--ARM are not. Take a
look at the EFM32 CMSIS files--I believe you'll find they are much, much
bigger!
--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
SolderCore running Defender... http://www.vimeo.com/25709426
Reply by ●March 2, 20122012-03-02
Il 02/03/2012 11:55, Tim Mitchell ha scritto:
>
>
> ----Original Message----
> From: l...
> [mailto:l... ] On
> Behalf Of Paul Curtis
> Sent: 02 March 2012 10:47 To: l...
>
> Subject: RE: [lpc2000] bit names in CMSIS
>
> > The unfortunate downside of CMSIS implementation. I
> > would say that the old
> > CrossWorks header files are probably going to be legacy
> > items from here on
> > in with new Cortex-M devices because ARM have come up
> > with CMSIS and more
> > vendors are getting on board--even the ones that were
> > first out of the block
> > like Luminary and NXP. The SVD files are pretty good
> > from many vendors,
> > but, well, not using CMSIS is probably working against
> > the tide.
>
> All true, I am starting to use the CMSIS definitions for new jobs
> because of this.
>
> So there are no bit definitions because NXP haven't provided them?
>
> --
> Tim Mitchell
>
Hi Tim,
I am curious about this post because ARM sponsorized CMSIS and because
NXP (as other silicon makers) gives CMSIS libraries for its Cortex-M
families of microcontrollers and being a consultant I am interested to
know more opinions about them.
1. What do you think about CMSIS? Is is a good idea and a good
implementation?
2. NXP as other silicon makers makes and gives for free CMSIS
implementation for Cortex microcontroller families with the idea
to shorten the applications development cycle. What do you think about?
Do you use them? Are the NXP libraries useful for your daily use? If not
why?
3. If you are using the NXP libraries: do you need also bit definitions?
Why?
>
>
>
> ----Original Message----
> From: l...
> [mailto:l... ] On
> Behalf Of Paul Curtis
> Sent: 02 March 2012 10:47 To: l...
>
> Subject: RE: [lpc2000] bit names in CMSIS
>
> > The unfortunate downside of CMSIS implementation. I
> > would say that the old
> > CrossWorks header files are probably going to be legacy
> > items from here on
> > in with new Cortex-M devices because ARM have come up
> > with CMSIS and more
> > vendors are getting on board--even the ones that were
> > first out of the block
> > like Luminary and NXP. The SVD files are pretty good
> > from many vendors,
> > but, well, not using CMSIS is probably working against
> > the tide.
>
> All true, I am starting to use the CMSIS definitions for new jobs
> because of this.
>
> So there are no bit definitions because NXP haven't provided them?
>
> --
> Tim Mitchell
>
Hi Tim,
I am curious about this post because ARM sponsorized CMSIS and because
NXP (as other silicon makers) gives CMSIS libraries for its Cortex-M
families of microcontrollers and being a consultant I am interested to
know more opinions about them.
1. What do you think about CMSIS? Is is a good idea and a good
implementation?
2. NXP as other silicon makers makes and gives for free CMSIS
implementation for Cortex microcontroller families with the idea
to shorten the applications development cycle. What do you think about?
Do you use them? Are the NXP libraries useful for your daily use? If not
why?
3. If you are using the NXP libraries: do you need also bit definitions?
Why?
>
Reply by ●March 2, 20122012-03-02
A few inputs to support Tim.
On Fri, Mar 2, 2012 at 8:53 AM, M. Manca wrote:
> **
> Il 02/03/2012 11:55, Tim Mitchell ha scritto:
> Hi Tim,
> I am curious about this post because ARM sponsorized CMSIS and because
> NXP (as other silicon makers) gives CMSIS libraries for its Cortex-M
> families of microcontrollers and being a consultant I am interested to
> know more opinions about them.
>
> 1. What do you think about CMSIS? Is is a good idea and a good
> implementation?
>
You will always find people that like and others that dislike a given
implementation. Personally, I think it's OK.
> 2. NXP as other silicon makers makes and gives for free CMSIS
> implementation for Cortex microcontroller families with the idea
> to shorten the applications development cycle. What do you think about?
> Do you use them? Are the NXP libraries useful for your daily use? If not
> why?
>
It is fine for NXP's Cortex uC while you remain within the family. The idea
around the CMSIS, as I understood it originally, should be portability,
which is not met here: it is LPCxxxx-centric (the macros start with "LPC"
as a matter of fact). CMSIS means "Cortex Microcontroller Software
Interface Standard" and, from this point of view, NXP's implementation
makes it more manufacturer-centric than the name indicates.
> 3. If you are using the NXP libraries: do you need also bit definitions?
> Why?
>
Most registers are actually bitfields so, for the sake of readability, it
would make sense to define names for the various bits. This is what I did
in my current project, in the hardware-level header files.
Olivier Gautherot
o...@gautherot.net
On Fri, Mar 2, 2012 at 8:53 AM, M. Manca wrote:
> **
> Il 02/03/2012 11:55, Tim Mitchell ha scritto:
> Hi Tim,
> I am curious about this post because ARM sponsorized CMSIS and because
> NXP (as other silicon makers) gives CMSIS libraries for its Cortex-M
> families of microcontrollers and being a consultant I am interested to
> know more opinions about them.
>
> 1. What do you think about CMSIS? Is is a good idea and a good
> implementation?
>
You will always find people that like and others that dislike a given
implementation. Personally, I think it's OK.
> 2. NXP as other silicon makers makes and gives for free CMSIS
> implementation for Cortex microcontroller families with the idea
> to shorten the applications development cycle. What do you think about?
> Do you use them? Are the NXP libraries useful for your daily use? If not
> why?
>
It is fine for NXP's Cortex uC while you remain within the family. The idea
around the CMSIS, as I understood it originally, should be portability,
which is not met here: it is LPCxxxx-centric (the macros start with "LPC"
as a matter of fact). CMSIS means "Cortex Microcontroller Software
Interface Standard" and, from this point of view, NXP's implementation
makes it more manufacturer-centric than the name indicates.
> 3. If you are using the NXP libraries: do you need also bit definitions?
> Why?
>
Most registers are actually bitfields so, for the sake of readability, it
would make sense to define names for the various bits. This is what I did
in my current project, in the hardware-level header files.
Olivier Gautherot
o...@gautherot.net
Reply by ●March 2, 20122012-03-02
----Original Message----
From: l...
[mailto:l...] On Behalf Of M. Manca
Sent: 02 March 2012 11:53 To: l...
Subject: Re: [lpc2000] bit names in CMSIS
> Hi Tim,
> I am curious about this post because ARM sponsorized
> CMSIS and because
> NXP (as other silicon makers) gives CMSIS libraries for
> its Cortex-M
> families of microcontrollers and being a consultant I am
> interested to
> know more opinions about them.
>
> 1. What do you think about CMSIS? Is is a good idea and a
> good
> implementation?
> 2. NXP as other silicon makers makes and gives for free
> CMSIS
> implementation for Cortex microcontroller families with
> the idea
> to shorten the applications development cycle. What do
> you think about?
> Do you use them? Are the NXP libraries useful for your
> daily use? If not
> why?
> 3. If you are using the NXP libraries: do you need also
> bit definitions?
> Why?
1-Yes I think CMSIS is a good idea for compatibility between different compilers and different device manufacturers.
I do struggle to find good documentation for the NXP implementation, in some cases they have used different register names in the user manual from how they have defined the CMSIS which is a bit stupid.
2-I haven't used the NXP code libraries up to now because mostly I have been recycling code written for NXP ARM7 devices and it is easier to just change the registers where required (mostly not required as NXP have been good at keeping the peripherals the same).
Having adapted a project using the NXP libraries (Embedded Artists LPC1788 development board) they look like they would be useful if I could work out how to use them, but where is the documentation for all the library calls? Have I overlooked something obvious? I couldn't find any useful documentation. It looks like if you're a Code Red user then there is some integration with the IDE, but I'm using Crossworks.
3-If you did the whole thing using library calls, I suppose you wouldn't need bit definitions. However I come from the old school of bit twiddling and I work from the NXP user manual PDF, which documents the registers directly rather than giving any information about the library calls you'd use. If you can point me to a good document for the library calls, and the library is going to be kept standard, then that would be a better way to do it.
--
Tim Mitchell
From: l...
[mailto:l...] On Behalf Of M. Manca
Sent: 02 March 2012 11:53 To: l...
Subject: Re: [lpc2000] bit names in CMSIS
> Hi Tim,
> I am curious about this post because ARM sponsorized
> CMSIS and because
> NXP (as other silicon makers) gives CMSIS libraries for
> its Cortex-M
> families of microcontrollers and being a consultant I am
> interested to
> know more opinions about them.
>
> 1. What do you think about CMSIS? Is is a good idea and a
> good
> implementation?
> 2. NXP as other silicon makers makes and gives for free
> CMSIS
> implementation for Cortex microcontroller families with
> the idea
> to shorten the applications development cycle. What do
> you think about?
> Do you use them? Are the NXP libraries useful for your
> daily use? If not
> why?
> 3. If you are using the NXP libraries: do you need also
> bit definitions?
> Why?
1-Yes I think CMSIS is a good idea for compatibility between different compilers and different device manufacturers.
I do struggle to find good documentation for the NXP implementation, in some cases they have used different register names in the user manual from how they have defined the CMSIS which is a bit stupid.
2-I haven't used the NXP code libraries up to now because mostly I have been recycling code written for NXP ARM7 devices and it is easier to just change the registers where required (mostly not required as NXP have been good at keeping the peripherals the same).
Having adapted a project using the NXP libraries (Embedded Artists LPC1788 development board) they look like they would be useful if I could work out how to use them, but where is the documentation for all the library calls? Have I overlooked something obvious? I couldn't find any useful documentation. It looks like if you're a Code Red user then there is some integration with the IDE, but I'm using Crossworks.
3-If you did the whole thing using library calls, I suppose you wouldn't need bit definitions. However I come from the old school of bit twiddling and I work from the NXP user manual PDF, which documents the registers directly rather than giving any information about the library calls you'd use. If you can point me to a good document for the library calls, and the library is going to be kept standard, then that would be a better way to do it.
--
Tim Mitchell
Reply by ●March 2, 20122012-03-02
Il 02/03/2012 13:21, Olivier Gautherot ha scritto:
> A few inputs to support Tim.
Obviously the questions aren't limited to Tim, I am curious to
understand as much ideas as possible.
> On Fri, Mar 2, 2012 at 8:53 AM, M. Manca wrote:
>
>> **
>> Il 02/03/2012 11:55, Tim Mitchell ha scritto:
>> Hi Tim,
>> I am curious about this post because ARM sponsorized CMSIS and because
>> NXP (as other silicon makers) gives CMSIS libraries for its Cortex-M
>> families of microcontrollers and being a consultant I am interested to
>> know more opinions about them.
>>
>> 1. What do you think about CMSIS? Is is a good idea and a good
>> implementation?
>>
> You will always find people that like and others that dislike a given
> implementation. Personally, I think it's OK.
It is true. Just to clarify my position: I like CMSIS idea but not so
much the implementation. I think to be one of the few that sent to ARM
critics and suggestion to improve their CMSIS standard.
>
>> 2. NXP as other silicon makers makes and gives for free CMSIS
>> implementation for Cortex microcontroller families with the idea
>> to shorten the applications development cycle. What do you think about?
>> Do you use them? Are the NXP libraries useful for your daily use? If not
>> why?
>>
> It is fine for NXP's Cortex uC while you remain within the family. The idea
> around the CMSIS, as I understood it originally, should be portability,
> which is not met here: it is LPCxxxx-centric (the macros start with "LPC"
> as a matter of fact).
This is partially true. I read the original CMSIS standard document
written by ARM. In it you can find that ARM asks to silicon makers to
follow some rules to stay on the standard. I find a big contradiction
between marketing presentations for the Cortex families when they say
"you will not need an assembly startup file, you will do all in C" and
the CMSIS implementation by ARM where they supply the asm version for
all the supported compilers.
> CMSIS means "Cortex Microcontroller Software
> Interface Standard" and, from this point of view, NXP's implementation
> makes it more manufacturer-centric than the name indicates.
>
>> 3. If you are using the NXP libraries: do you need also bit definitions?
>> Why?
> Most registers are actually bitfields so, for the sake of readability, it
> would make sense to define names for the various bits. This is what I did
> in my current project, in the hardware-level header files.
Yes, this is true, but suppose you write by yourself the "ideal" library
to decouple the hw to the sw, will you write functions that will have to
deal with the register bits or not (I mean the calling mechanism not the
internals)?
Thanks to your answers and notes, I appreciate a lot them.
> Olivier Gautherot
> o...@gautherot.net
>
>
>
> A few inputs to support Tim.
Obviously the questions aren't limited to Tim, I am curious to
understand as much ideas as possible.
> On Fri, Mar 2, 2012 at 8:53 AM, M. Manca wrote:
>
>> **
>> Il 02/03/2012 11:55, Tim Mitchell ha scritto:
>> Hi Tim,
>> I am curious about this post because ARM sponsorized CMSIS and because
>> NXP (as other silicon makers) gives CMSIS libraries for its Cortex-M
>> families of microcontrollers and being a consultant I am interested to
>> know more opinions about them.
>>
>> 1. What do you think about CMSIS? Is is a good idea and a good
>> implementation?
>>
> You will always find people that like and others that dislike a given
> implementation. Personally, I think it's OK.
It is true. Just to clarify my position: I like CMSIS idea but not so
much the implementation. I think to be one of the few that sent to ARM
critics and suggestion to improve their CMSIS standard.
>
>> 2. NXP as other silicon makers makes and gives for free CMSIS
>> implementation for Cortex microcontroller families with the idea
>> to shorten the applications development cycle. What do you think about?
>> Do you use them? Are the NXP libraries useful for your daily use? If not
>> why?
>>
> It is fine for NXP's Cortex uC while you remain within the family. The idea
> around the CMSIS, as I understood it originally, should be portability,
> which is not met here: it is LPCxxxx-centric (the macros start with "LPC"
> as a matter of fact).
This is partially true. I read the original CMSIS standard document
written by ARM. In it you can find that ARM asks to silicon makers to
follow some rules to stay on the standard. I find a big contradiction
between marketing presentations for the Cortex families when they say
"you will not need an assembly startup file, you will do all in C" and
the CMSIS implementation by ARM where they supply the asm version for
all the supported compilers.
> CMSIS means "Cortex Microcontroller Software
> Interface Standard" and, from this point of view, NXP's implementation
> makes it more manufacturer-centric than the name indicates.
>
>> 3. If you are using the NXP libraries: do you need also bit definitions?
>> Why?
> Most registers are actually bitfields so, for the sake of readability, it
> would make sense to define names for the various bits. This is what I did
> in my current project, in the hardware-level header files.
Yes, this is true, but suppose you write by yourself the "ideal" library
to decouple the hw to the sw, will you write functions that will have to
deal with the register bits or not (I mean the calling mechanism not the
internals)?
Thanks to your answers and notes, I appreciate a lot them.
> Olivier Gautherot
> o...@gautherot.net
>
>
>
Reply by ●March 2, 20122012-03-02
----Original Message----
From: l...
[mailto:l...] On Behalf Of Olivier
Gautherot Sent: 02 March 2012 12:22 To:
l... Subject: Re: [lpc2000] bit names in
CMSIS
> It is fine for NXP's Cortex uC while you remain within
> the family. The idea
> around the CMSIS, as I understood it originally, should
> be portability,
> which is not met here: it is LPCxxxx-centric (the macros
> start with "LPC"
> as a matter of fact). CMSIS means "Cortex(tm)
> Microcontroller Software
> Interface Standard" and, from this point of view, NXP's
> implementation
> makes it more manufacturer-centric than the name
> indicates.
Aren't nearly all the registers LPCxxxx-centric anyway though? If you move to a different manufacturer, the peripherals would be different anyway wouldn't they? (I've only ever used NXP's ARM so I don't know)
--
Tim Mitchell
From: l...
[mailto:l...] On Behalf Of Olivier
Gautherot Sent: 02 March 2012 12:22 To:
l... Subject: Re: [lpc2000] bit names in
CMSIS
> It is fine for NXP's Cortex uC while you remain within
> the family. The idea
> around the CMSIS, as I understood it originally, should
> be portability,
> which is not met here: it is LPCxxxx-centric (the macros
> start with "LPC"
> as a matter of fact). CMSIS means "Cortex(tm)
> Microcontroller Software
> Interface Standard" and, from this point of view, NXP's
> implementation
> makes it more manufacturer-centric than the name
> indicates.
Aren't nearly all the registers LPCxxxx-centric anyway though? If you move to a different manufacturer, the peripherals would be different anyway wouldn't they? (I've only ever used NXP's ARM so I don't know)
--
Tim Mitchell
Reply by ●March 2, 20122012-03-02
> On Fri, Mar 2, 2012 at 8:53 AM, M. Manca
> >wrote:
> >> 3. If you are using the NXP libraries: do you need also bit definitions?
> >> Why?
> > Most registers are actually bitfields so, for the sake of readability, it
> > would make sense to define names for the various bits. This is what I did
> > in my current project, in the hardware-level header files.
> Yes, this is true, but suppose you write by yourself the "ideal" library
> to decouple the hw to the sw, will you write functions that will have to
> deal with the register bits or not (I mean the calling mechanism not the
> internals)?
>
> Thanks to your answers and notes, I appreciate a lot them.
>
"Ideal" library? Mmmhhh... I'm not even sure I can write one for myself ;-)
We are actually setting some internal standards that meet the common
definitions of our products and derivatives. They are indeed enclosed in a
layer of functions that deal with each aspect of the hardware modules and
give an API to the middleware. However, I prefer to have clear names rather
than magic numbers in the hardware drivers layer - it eases the development.
Thanks for clarifying the CMSIS philosophy, by the way. Really appreciated
your comments.
Cheers
--
Olivier Gautherot
o...@gautherot.net
> >> 3. If you are using the NXP libraries: do you need also bit definitions?
> >> Why?
> > Most registers are actually bitfields so, for the sake of readability, it
> > would make sense to define names for the various bits. This is what I did
> > in my current project, in the hardware-level header files.
> Yes, this is true, but suppose you write by yourself the "ideal" library
> to decouple the hw to the sw, will you write functions that will have to
> deal with the register bits or not (I mean the calling mechanism not the
> internals)?
>
> Thanks to your answers and notes, I appreciate a lot them.
>
"Ideal" library? Mmmhhh... I'm not even sure I can write one for myself ;-)
We are actually setting some internal standards that meet the common
definitions of our products and derivatives. They are indeed enclosed in a
layer of functions that deal with each aspect of the hardware modules and
give an API to the middleware. However, I prefer to have clear names rather
than magic numbers in the hardware drivers layer - it eases the development.
Thanks for clarifying the CMSIS philosophy, by the way. Really appreciated
your comments.
Cheers
--
Olivier Gautherot
o...@gautherot.net
