I'm using CMSIS headers extensively for M0, M3, and M4.
They are inconsistent in many ways, for example the port register names
differ between devices as do many of the peripheral register names even when
they use the same core peripherals, it's becoming a bit of a pain.
Generally though it does help make the code easier to port, but not as easy
as it was intended to do.
Note that NXP's CMSIS headers to not inline functions properly because
the
function definitions are not in the header files, so you can end up with a
large overhead using some of the more complex functions, leaving code that
can never be executed in your rom image.
I found it better to use the MDK's config wizard for setting up ports
etc,
it was tedious creating the headers initially but now I'm seeing the
benefits, particularly with the 4350 as there are so many config options.
Typically I also use macros where possible, for example
#define BIT(A) (1UL << (A))
For the LPC17xx devices I use
// defines the port mappings for the platform
#define ISR_LED_ON (LPC_GPIO1->FIOSET = BIT(14)) // P1.14
#define ISR_LED_OFF (LPC_GPIO1->FIOCLR = BIT(14))
For the LPC11xx devices I use
// defines the port mappings for the platform
#define SET_GPIO(Port,Bit)(Port->MASKED_ACCESS[(Bit)] = (Bit))
#define CLR_GPIO(Port,Bit)(Port->MASKED_ACCESS[(Bit)] = (0))
#define ISR_LED_ON SET_GPIO(LPC_GPIO3,BIT(0)) // P3.0
#define ISR_LED_OFF CLR_GPIO(LPC_GPIO3,BIT(0))
Using macro's in this way generates efficient code regardless of the
optimization level since the macro's are fully expanded to write a
constant
value to a fixed address prior to code being generated.
Regards
Phil.
From: l... [mailto:l...] On Behalf Of
M. Manca
Sent: 02 March 2012 11:53
To: l...
Subject: Re: [lpc2000] bit names in CMSIS
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?
>
bit names in CMSIS
Started by ●March 2, 2012
Reply by ●March 2, 20122012-03-02
Reply by ●March 2, 20122012-03-02
Il 02/03/2012 13:22, Tim Mitchell ha scritto:
>
>
> ----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.
>
Yes, true I also found these problems.
> 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?
>
No, generally there is a readme.txt. Generally it is necessary to read
the source code.
>
> 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.
>
You can find NXP libraries on the main NXP web site an at
www.lpcware.com where you can find other interesting free libraries.
> 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.
>
Ok, so you think (as me) that you write your own code because every time
you haven't a good library documentation you use the only documentation
you think valuable, in this case datasheets and user manual.
If you have to deal with a complex mcu peripheral do you think that user
manual and datasheets coul be sufficient or you may prefer to have a
more detailed documentation about the specific peripheral and/or
specific examples/application note? When I think to a complex peripheral
I think to CAN module or SCT and SGPIO (serial gpio) of LPC43xx/LPC18xx
microcontrollers, DMA modules, ethernet modules and so on.
> --
> Tim Mitchell
>
>
> ----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.
>
Yes, true I also found these problems.
> 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?
>
No, generally there is a readme.txt. Generally it is necessary to read
the source code.
>
> 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.
>
You can find NXP libraries on the main NXP web site an at
www.lpcware.com where you can find other interesting free libraries.
> 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.
>
Ok, so you think (as me) that you write your own code because every time
you haven't a good library documentation you use the only documentation
you think valuable, in this case datasheets and user manual.
If you have to deal with a complex mcu peripheral do you think that user
manual and datasheets coul be sufficient or you may prefer to have a
more detailed documentation about the specific peripheral and/or
specific examples/application note? When I think to a complex peripheral
I think to CAN module or SCT and SGPIO (serial gpio) of LPC43xx/LPC18xx
microcontrollers, DMA modules, ethernet modules and so on.
> --
> Tim Mitchell
Reply by ●March 2, 20122012-03-02
Il 02/03/2012 13:47, Phil Young ha scritto:
>
>
> I'm using CMSIS headers extensively for M0, M3, and M4.
>
> They are inconsistent in many ways, for example the port register names
> differ between devices as do many of the peripheral register names
> even when
> they use the same core peripherals, it's becoming a bit of a pain.
>
> Generally though it does help make the code easier to port, but not as
> easy
> as it was intended to do.
>
> Note that NXP's CMSIS headers to not inline functions properly because the
> function definitions are not in the header files, so you can end up with a
> large overhead using some of the more complex functions, leaving code that
> can never be executed in your rom image.
>
> I found it better to use the MDK's config wizard for setting up ports etc,
> it was tedious creating the headers initially but now I'm seeing the
> benefits, particularly with the 4350 as there are so many config options.
>
> Typically I also use macros where possible, for example
>
> #define BIT(A) (1UL << (A))
>
> For the LPC17xx devices I use
>
> // defines the port mappings for the platform
>
> #define ISR_LED_ON (LPC_GPIO1->FIOSET = BIT(14)) // P1.14
>
> #define ISR_LED_OFF (LPC_GPIO1->FIOCLR = BIT(14))
>
> For the LPC11xx devices I use
>
> // defines the port mappings for the platform
>
> #define SET_GPIO(Port,Bit)(Port->MASKED_ACCESS[(Bit)] = (Bit))
>
> #define CLR_GPIO(Port,Bit)(Port->MASKED_ACCESS[(Bit)] = (0))
>
> #define ISR_LED_ON SET_GPIO(LPC_GPIO3,BIT(0)) // P3.0
>
> #define ISR_LED_OFF CLR_GPIO(LPC_GPIO3,BIT(0))
>
> Using macro's in this way generates efficient code regardless of the
> optimization level since the macro's are fully expanded to write a
> constant
> value to a fixed address prior to code being generated.
>
Ok, Phil I agree a lot with your notes.
About inlines functions I can say that it is a strange situation because
it depends a lot from the C compiler and how much it is C99 compliant
(because C99 defines the 1st inline standard) if we can try to port
always the same implementation. In my experience defining static inline
functions in header files (to use them across different C files) or
directly in C source files doesn't change how the compiler expands the
code that is more dependent by optimization flags. Some compilers as GCC
have specific directives, attribute or pragmas to force inlining but it
is not very portable. So preprocessor is the rescue in this situations.
>
> Regards
>
> Phil.
>
> From: l...
> [mailto:l... ] On
> Behalf Of
> M. Manca
> Sent: 02 March 2012 11:53
> To: l...
> Subject: Re: [lpc2000] bit names in CMSIS
>
> 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?
> >
>
>
>
>
> I'm using CMSIS headers extensively for M0, M3, and M4.
>
> They are inconsistent in many ways, for example the port register names
> differ between devices as do many of the peripheral register names
> even when
> they use the same core peripherals, it's becoming a bit of a pain.
>
> Generally though it does help make the code easier to port, but not as
> easy
> as it was intended to do.
>
> Note that NXP's CMSIS headers to not inline functions properly because the
> function definitions are not in the header files, so you can end up with a
> large overhead using some of the more complex functions, leaving code that
> can never be executed in your rom image.
>
> I found it better to use the MDK's config wizard for setting up ports etc,
> it was tedious creating the headers initially but now I'm seeing the
> benefits, particularly with the 4350 as there are so many config options.
>
> Typically I also use macros where possible, for example
>
> #define BIT(A) (1UL << (A))
>
> For the LPC17xx devices I use
>
> // defines the port mappings for the platform
>
> #define ISR_LED_ON (LPC_GPIO1->FIOSET = BIT(14)) // P1.14
>
> #define ISR_LED_OFF (LPC_GPIO1->FIOCLR = BIT(14))
>
> For the LPC11xx devices I use
>
> // defines the port mappings for the platform
>
> #define SET_GPIO(Port,Bit)(Port->MASKED_ACCESS[(Bit)] = (Bit))
>
> #define CLR_GPIO(Port,Bit)(Port->MASKED_ACCESS[(Bit)] = (0))
>
> #define ISR_LED_ON SET_GPIO(LPC_GPIO3,BIT(0)) // P3.0
>
> #define ISR_LED_OFF CLR_GPIO(LPC_GPIO3,BIT(0))
>
> Using macro's in this way generates efficient code regardless of the
> optimization level since the macro's are fully expanded to write a
> constant
> value to a fixed address prior to code being generated.
>
Ok, Phil I agree a lot with your notes.
About inlines functions I can say that it is a strange situation because
it depends a lot from the C compiler and how much it is C99 compliant
(because C99 defines the 1st inline standard) if we can try to port
always the same implementation. In my experience defining static inline
functions in header files (to use them across different C files) or
directly in C source files doesn't change how the compiler expands the
code that is more dependent by optimization flags. Some compilers as GCC
have specific directives, attribute or pragmas to force inlining but it
is not very portable. So preprocessor is the rescue in this situations.
>
> Regards
>
> Phil.
>
> From: l...
> [mailto:l... ] On
> Behalf Of
> M. Manca
> Sent: 02 March 2012 11:53
> To: l...
> Subject: Re: [lpc2000] bit names in CMSIS
>
> 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?
> >
>
>
Reply by ●March 2, 20122012-03-02
----Original Message----
From: l...
[mailto:l...] On Behalf Of M. Manca
Sent: 02 March 2012 13:43 To: l...
Subject: Re: [lpc2000] bit names in CMSIS
> Il 02/03/2012 13:22, Tim Mitchell ha scritto:
> > but where is the documentation for all the
> > library calls?
> >
> No, generally there is a readme.txt. Generally it is
> necessary to read
> the source code.
Really, well I'm not very keen on it then, as there are a large number of separate files to go through.
> If you have to deal with a complex mcu peripheral do you
> think that user
> manual and datasheets coul be sufficient or you may
> prefer to have a
> more detailed documentation about the specific peripheral
> and/or
> specific examples/application note? When I think to a
> complex peripheral
> I think to CAN module or SCT and SGPIO (serial gpio) of
> LPC43xx/LPC18xx microcontrollers, DMA modules, ethernet
> modules and so on.
I'm usually happy with user manual/datasheet, and examples are helpful. Unfortunately the NXP user manual is sometimes badly written or does not include some important information - I just spent a long time getting DMA working with SSP because it is not explained well in the user manual.
But it would be really nice if NXP could include the library calls in the user manual with the peripheral descriptions. Then all the information is in the same place.
--
Tim Mitchell
From: l...
[mailto:l...] On Behalf Of M. Manca
Sent: 02 March 2012 13:43 To: l...
Subject: Re: [lpc2000] bit names in CMSIS
> Il 02/03/2012 13:22, Tim Mitchell ha scritto:
> > but where is the documentation for all the
> > library calls?
> >
> No, generally there is a readme.txt. Generally it is
> necessary to read
> the source code.
Really, well I'm not very keen on it then, as there are a large number of separate files to go through.
> If you have to deal with a complex mcu peripheral do you
> think that user
> manual and datasheets coul be sufficient or you may
> prefer to have a
> more detailed documentation about the specific peripheral
> and/or
> specific examples/application note? When I think to a
> complex peripheral
> I think to CAN module or SCT and SGPIO (serial gpio) of
> LPC43xx/LPC18xx microcontrollers, DMA modules, ethernet
> modules and so on.
I'm usually happy with user manual/datasheet, and examples are helpful. Unfortunately the NXP user manual is sometimes badly written or does not include some important information - I just spent a long time getting DMA working with SSP because it is not explained well in the user manual.
But it would be really nice if NXP could include the library calls in the user manual with the peripheral descriptions. Then all the information is in the same place.
--
Tim Mitchell
Reply by ●March 2, 20122012-03-02
Il 02/03/2012 11:59, Paul Curtis ha scritto:
>
>
> > > 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!
>
Hi Paul,
your opinion, as a tool vendor, may be different and interesting to
understand the situation about CMSIS both in the ARM part and in the
silicon makers part (mainly peripheral libs).
Do you think that ARM and silicon vendors may interface well with tool
vendors like Crossworks? Or do you think they could help their customers
better delivering to tools vendors they CMSIS compliant libraries
(actually I know only that we can find their CMSIS libraries on their
web sites)?
Being that many silicon vendors use standard ARM peripherals on their
microcontrollers could be correct that ARM could provide C libraries for
these peripherals saying what microcontrollers are using them to help
silicon makers to reduce their libraries implementations?
Personally I always prefer to use my own libraries (or well tested
libraries) because I am sure to have tested them so I can say "they
works". Do you think that this may generally influence the possibility
to employ CMSIS peripheral libraries? And if the CMSIS libraries
supplier gives also some "unit test" framework so we could repeat all
their tests do you think may increase the possibility to use them?
> --
> Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
> SolderCore running Defender... http://www.vimeo.com/25709426
>
>
> > > 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!
>
Hi Paul,
your opinion, as a tool vendor, may be different and interesting to
understand the situation about CMSIS both in the ARM part and in the
silicon makers part (mainly peripheral libs).
Do you think that ARM and silicon vendors may interface well with tool
vendors like Crossworks? Or do you think they could help their customers
better delivering to tools vendors they CMSIS compliant libraries
(actually I know only that we can find their CMSIS libraries on their
web sites)?
Being that many silicon vendors use standard ARM peripherals on their
microcontrollers could be correct that ARM could provide C libraries for
these peripherals saying what microcontrollers are using them to help
silicon makers to reduce their libraries implementations?
Personally I always prefer to use my own libraries (or well tested
libraries) because I am sure to have tested them so I can say "they
works". Do you think that this may generally influence the possibility
to employ CMSIS peripheral libraries? And if the CMSIS libraries
supplier gives also some "unit test" framework so we could repeat all
their tests do you think may increase the possibility to use them?
> --
> 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
I Agree that in many cases inlining can be done with functions defined in .c
files, but this requires link time code generation since the source code is
not visible to the compiler at compile time.
But there are many instances where a good compiler can perform much better
optimization at compile time, particularly redundant code elimination, which
is possible when constants are passed into functions.
This is generally the case when calling setup functions in embedded
applications since pinout and device configuration is normally fixed.
Since I write all of my code in C++ this is even more relevant since I have
many functions where parameters are given default values, in this case the
compiler can frequently inline most calls to a function, and only use a
function call where the additional parameters make it appropriate, or where
their value is not known at compile time.
My experience with the MDK is that it can make a huge difference at all
optimization levels having the function body available to the compiler, I
also see the same effect in VS even with link time code generation enabled.
Regards
Phil.
From: l... [mailto:l...] On Behalf Of
M. Manca
Sent: 02 March 2012 14:05
To: l...
Subject: Re: [lpc2000] bit names in CMSIS
Il 02/03/2012 13:47, Phil Young ha scritto:
> I'm using CMSIS headers extensively for M0, M3, and M4.
>
> They are inconsistent in many ways, for example the port register names
> differ between devices as do many of the peripheral register names
> even when
> they use the same core peripherals, it's becoming a bit of a pain.
>
> Generally though it does help make the code easier to port, but not as
> easy
> as it was intended to do.
>
> Note that NXP's CMSIS headers to not inline functions properly because the
> function definitions are not in the header files, so you can end up with a
> large overhead using some of the more complex functions, leaving code that
> can never be executed in your rom image.
>
> I found it better to use the MDK's config wizard for setting up ports etc,
> it was tedious creating the headers initially but now I'm seeing the
> benefits, particularly with the 4350 as there are so many config options.
>
> Typically I also use macros where possible, for example
>
> #define BIT(A) (1UL << (A))
>
> For the LPC17xx devices I use
>
> // defines the port mappings for the platform
>
> #define ISR_LED_ON (LPC_GPIO1->FIOSET = BIT(14)) // P1.14
>
> #define ISR_LED_OFF (LPC_GPIO1->FIOCLR = BIT(14))
>
> For the LPC11xx devices I use
>
> // defines the port mappings for the platform
>
> #define SET_GPIO(Port,Bit)(Port->MASKED_ACCESS[(Bit)] = (Bit))
>
> #define CLR_GPIO(Port,Bit)(Port->MASKED_ACCESS[(Bit)] = (0))
>
> #define ISR_LED_ON SET_GPIO(LPC_GPIO3,BIT(0)) // P3.0
>
> #define ISR_LED_OFF CLR_GPIO(LPC_GPIO3,BIT(0))
>
> Using macro's in this way generates efficient code regardless of the
> optimization level since the macro's are fully expanded to write a
> constant
> value to a fixed address prior to code being generated.
>
Ok, Phil I agree a lot with your notes.
About inlines functions I can say that it is a strange situation because
it depends a lot from the C compiler and how much it is C99 compliant
(because C99 defines the 1st inline standard) if we can try to port
always the same implementation. In my experience defining static inline
functions in header files (to use them across different C files) or
directly in C source files doesn't change how the compiler expands the
code that is more dependent by optimization flags. Some compilers as GCC
have specific directives, attribute or pragmas to force inlining but it
is not very portable. So preprocessor is the rescue in this situations.
>
> Regards
>
> Phil.
>
> From: l...
> [mailto:l...
] On
> Behalf Of
> M. Manca
> Sent: 02 March 2012 11:53
> To: l...
> Subject: Re: [lpc2000] bit names in CMSIS
>
> 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?
> >
>
>
files, but this requires link time code generation since the source code is
not visible to the compiler at compile time.
But there are many instances where a good compiler can perform much better
optimization at compile time, particularly redundant code elimination, which
is possible when constants are passed into functions.
This is generally the case when calling setup functions in embedded
applications since pinout and device configuration is normally fixed.
Since I write all of my code in C++ this is even more relevant since I have
many functions where parameters are given default values, in this case the
compiler can frequently inline most calls to a function, and only use a
function call where the additional parameters make it appropriate, or where
their value is not known at compile time.
My experience with the MDK is that it can make a huge difference at all
optimization levels having the function body available to the compiler, I
also see the same effect in VS even with link time code generation enabled.
Regards
Phil.
From: l... [mailto:l...] On Behalf Of
M. Manca
Sent: 02 March 2012 14:05
To: l...
Subject: Re: [lpc2000] bit names in CMSIS
Il 02/03/2012 13:47, Phil Young ha scritto:
> I'm using CMSIS headers extensively for M0, M3, and M4.
>
> They are inconsistent in many ways, for example the port register names
> differ between devices as do many of the peripheral register names
> even when
> they use the same core peripherals, it's becoming a bit of a pain.
>
> Generally though it does help make the code easier to port, but not as
> easy
> as it was intended to do.
>
> Note that NXP's CMSIS headers to not inline functions properly because the
> function definitions are not in the header files, so you can end up with a
> large overhead using some of the more complex functions, leaving code that
> can never be executed in your rom image.
>
> I found it better to use the MDK's config wizard for setting up ports etc,
> it was tedious creating the headers initially but now I'm seeing the
> benefits, particularly with the 4350 as there are so many config options.
>
> Typically I also use macros where possible, for example
>
> #define BIT(A) (1UL << (A))
>
> For the LPC17xx devices I use
>
> // defines the port mappings for the platform
>
> #define ISR_LED_ON (LPC_GPIO1->FIOSET = BIT(14)) // P1.14
>
> #define ISR_LED_OFF (LPC_GPIO1->FIOCLR = BIT(14))
>
> For the LPC11xx devices I use
>
> // defines the port mappings for the platform
>
> #define SET_GPIO(Port,Bit)(Port->MASKED_ACCESS[(Bit)] = (Bit))
>
> #define CLR_GPIO(Port,Bit)(Port->MASKED_ACCESS[(Bit)] = (0))
>
> #define ISR_LED_ON SET_GPIO(LPC_GPIO3,BIT(0)) // P3.0
>
> #define ISR_LED_OFF CLR_GPIO(LPC_GPIO3,BIT(0))
>
> Using macro's in this way generates efficient code regardless of the
> optimization level since the macro's are fully expanded to write a
> constant
> value to a fixed address prior to code being generated.
>
Ok, Phil I agree a lot with your notes.
About inlines functions I can say that it is a strange situation because
it depends a lot from the C compiler and how much it is C99 compliant
(because C99 defines the 1st inline standard) if we can try to port
always the same implementation. In my experience defining static inline
functions in header files (to use them across different C files) or
directly in C source files doesn't change how the compiler expands the
code that is more dependent by optimization flags. Some compilers as GCC
have specific directives, attribute or pragmas to force inlining but it
is not very portable. So preprocessor is the rescue in this situations.
>
> Regards
>
> Phil.
>
> From: l...
> [mailto:l...
] On
> Behalf Of
> M. Manca
> Sent: 02 March 2012 11:53
> To: l...
> Subject: Re: [lpc2000] bit names in CMSIS
>
> 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?
> >
>
>
Reply by ●March 2, 20122012-03-02
Hi,
> > > > 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!
> >
> Hi Paul,
> your opinion, as a tool vendor, may be different and interesting to
understand
> the situation about CMSIS both in the ARM part and in the silicon makers
part
> (mainly peripheral libs).
> Do you think that ARM and silicon vendors may interface well with tool
vendors
> like Crossworks?
Support for ISVs varies across silicon vendors. Let me drop some names from
my perspective. Some are highly capable and highly enthusiastic about
supporting ISVs--I will mention that Energy Micro fits into this category.
Some will support you, as far as it goes, but they have bigger things to do,
so ISV support is not their focus and they probably have their own agenda
and favorites--NXP falls into this category to some degree, although knowing
people within NXP it is easy to request help! And then there are some that
plain can't be bothered to do very much for ISVs that support their silicon
and are not highly motivated apart from maybe one lone engineer--Freescale
fit into this category. Some have real 3P support schemes (Atmel, for
instance) and 3P areas (Texas Instruments for the MSP430 is an excellent
example).
Dealing with all these different vendors, with their silicon release
timescales, device support, and so on, takes a great deal of effort. We now
have over 700 stock ARM boards on our shelves and there is no sign that
Cortex-M device introduction is slowing--if anything it is accelerating!
(New devices & new vendors in the Cortex-M world this week, even though we
knew they were coming...)
> Or do you think they could help their customers better
> delivering to tools vendors they CMSIS compliant libraries (actually I
know
> only that we can find their CMSIS libraries on their web sites)?
The CMSIS portal is now controlled by ARM; every silicon vendor should be
delivering SVD files to ARM for publishing. ARM could curate the things
better, but hey, there's only a certain amount of time in the day!
> Being that many silicon vendors use standard ARM peripherals on their
> microcontrollers could be correct that ARM could provide C libraries for
these
> peripherals saying what microcontrollers are using them to help silicon
makers
> to reduce their libraries implementations?
What you're referring to is the PrimeCell and associated IP, I guess? I
wrote some standard drivers for things like the PL022, PL080, PL230 which
you find in many Cortex-M and ARM7 devices. Yes, ARM could standardize
this, but there isn't much of a point to doing so. I think the CMSIS RTOS
API is going to be a bit of a pig to gain traction. My initial thought was
"Great! Let's write to the CMSIS RTOS API", and then I looked at it, and
enthusiasm drained away as fast as it came.
> Personally I always prefer to use my own libraries (or well tested
> libraries) because I am sure to have tested them so I can say "they
works". Do
> you think that this may generally influence the possibility to employ
CMSIS
> peripheral libraries? And if the CMSIS libraries supplier gives also some
> "unit test" framework so we could repeat all their tests do you think may
> increase the possibility to use them?
I develop my own libraries; it means you know what the peripheral is doing.
It's time consuming, but you don't need to wade through a huge layer of
documentation and function calls just to find a write to a single bit in a
register (StellarisWare comes to mind here...)
--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
SolderCore running Defender... http://www.vimeo.com/25709426
> > > > 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!
> >
> Hi Paul,
> your opinion, as a tool vendor, may be different and interesting to
understand
> the situation about CMSIS both in the ARM part and in the silicon makers
part
> (mainly peripheral libs).
> Do you think that ARM and silicon vendors may interface well with tool
vendors
> like Crossworks?
Support for ISVs varies across silicon vendors. Let me drop some names from
my perspective. Some are highly capable and highly enthusiastic about
supporting ISVs--I will mention that Energy Micro fits into this category.
Some will support you, as far as it goes, but they have bigger things to do,
so ISV support is not their focus and they probably have their own agenda
and favorites--NXP falls into this category to some degree, although knowing
people within NXP it is easy to request help! And then there are some that
plain can't be bothered to do very much for ISVs that support their silicon
and are not highly motivated apart from maybe one lone engineer--Freescale
fit into this category. Some have real 3P support schemes (Atmel, for
instance) and 3P areas (Texas Instruments for the MSP430 is an excellent
example).
Dealing with all these different vendors, with their silicon release
timescales, device support, and so on, takes a great deal of effort. We now
have over 700 stock ARM boards on our shelves and there is no sign that
Cortex-M device introduction is slowing--if anything it is accelerating!
(New devices & new vendors in the Cortex-M world this week, even though we
knew they were coming...)
> Or do you think they could help their customers better
> delivering to tools vendors they CMSIS compliant libraries (actually I
know
> only that we can find their CMSIS libraries on their web sites)?
The CMSIS portal is now controlled by ARM; every silicon vendor should be
delivering SVD files to ARM for publishing. ARM could curate the things
better, but hey, there's only a certain amount of time in the day!
> Being that many silicon vendors use standard ARM peripherals on their
> microcontrollers could be correct that ARM could provide C libraries for
these
> peripherals saying what microcontrollers are using them to help silicon
makers
> to reduce their libraries implementations?
What you're referring to is the PrimeCell and associated IP, I guess? I
wrote some standard drivers for things like the PL022, PL080, PL230 which
you find in many Cortex-M and ARM7 devices. Yes, ARM could standardize
this, but there isn't much of a point to doing so. I think the CMSIS RTOS
API is going to be a bit of a pig to gain traction. My initial thought was
"Great! Let's write to the CMSIS RTOS API", and then I looked at it, and
enthusiasm drained away as fast as it came.
> Personally I always prefer to use my own libraries (or well tested
> libraries) because I am sure to have tested them so I can say "they
works". Do
> you think that this may generally influence the possibility to employ
CMSIS
> peripheral libraries? And if the CMSIS libraries supplier gives also some
> "unit test" framework so we could repeat all their tests do you think may
> increase the possibility to use them?
I develop my own libraries; it means you know what the peripheral is doing.
It's time consuming, but you don't need to wade through a huge layer of
documentation and function calls just to find a write to a single bit in a
register (StellarisWare comes to mind here...)
--
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 15:07, Tim Mitchell ha scritto:
>
>
> ----Original Message----
> From: l...
> [mailto:l... ] On
> Behalf Of M. Manca
> Sent: 02 March 2012 13:43 To: l...
>
> Subject: Re: [lpc2000] bit names in CMSIS
>
> > Il 02/03/2012 13:22, Tim Mitchell ha scritto:
> > > but where is the documentation for all the
> > > library calls?
> > >
> > No, generally there is a readme.txt. Generally it is
> > necessary to read
> > the source code.
>
> Really, well I'm not very keen on it then, as there are a large number
> of separate files to go through.
>
Generally for every peripheral module there is almost a C and an H file
i.e. adc.c and adc.h
To be more correct NXP has released new libraries with documentation
made using Doxygen.
You can download:
http://ics.nxp.com/support/documents/microcontrollers/zip/lpc177x.lpc178x.cmsis.driver.library.zip
to see an example.
In general newest microcontrollers families have this type of library.
The olders a readme.txt
So LPC175x/176x LPC177x/178x LPC18xx and LPC43xx have/will have a CMSIS
peripheral library (sometimes NXP call it PDL)
with this type of documentation.
> > If you have to deal with a complex mcu peripheral do you
> > think that user
> > manual and datasheets coul be sufficient or you may
> > prefer to have a
> > more detailed documentation about the specific peripheral
> > and/or
> > specific examples/application note? When I think to a
> > complex peripheral
> > I think to CAN module or SCT and SGPIO (serial gpio) of
> > LPC43xx/LPC18xx microcontrollers, DMA modules, ethernet
> > modules and so on.
>
> I'm usually happy with user manual/datasheet, and examples are
> helpful. Unfortunately the NXP user manual is sometimes badly written
> or does not include some important information - I just spent a long
> time getting DMA working with SSP because it is not explained well in
> the user manual.
>
> But it would be really nice if NXP could include the library calls in
> the user manual with the peripheral descriptions. Then all the
> information is in the same place.
>
> --
> Tim Mitchell
>
>
> ----Original Message----
> From: l...
> [mailto:l... ] On
> Behalf Of M. Manca
> Sent: 02 March 2012 13:43 To: l...
>
> Subject: Re: [lpc2000] bit names in CMSIS
>
> > Il 02/03/2012 13:22, Tim Mitchell ha scritto:
> > > but where is the documentation for all the
> > > library calls?
> > >
> > No, generally there is a readme.txt. Generally it is
> > necessary to read
> > the source code.
>
> Really, well I'm not very keen on it then, as there are a large number
> of separate files to go through.
>
Generally for every peripheral module there is almost a C and an H file
i.e. adc.c and adc.h
To be more correct NXP has released new libraries with documentation
made using Doxygen.
You can download:
http://ics.nxp.com/support/documents/microcontrollers/zip/lpc177x.lpc178x.cmsis.driver.library.zip
to see an example.
In general newest microcontrollers families have this type of library.
The olders a readme.txt
So LPC175x/176x LPC177x/178x LPC18xx and LPC43xx have/will have a CMSIS
peripheral library (sometimes NXP call it PDL)
with this type of documentation.
> > If you have to deal with a complex mcu peripheral do you
> > think that user
> > manual and datasheets coul be sufficient or you may
> > prefer to have a
> > more detailed documentation about the specific peripheral
> > and/or
> > specific examples/application note? When I think to a
> > complex peripheral
> > I think to CAN module or SCT and SGPIO (serial gpio) of
> > LPC43xx/LPC18xx microcontrollers, DMA modules, ethernet
> > modules and so on.
>
> I'm usually happy with user manual/datasheet, and examples are
> helpful. Unfortunately the NXP user manual is sometimes badly written
> or does not include some important information - I just spent a long
> time getting DMA working with SSP because it is not explained well in
> the user manual.
>
> But it would be really nice if NXP could include the library calls in
> the user manual with the peripheral descriptions. Then all the
> information is in the same place.
>
> --
> Tim Mitchell
Reply by ●March 2, 20122012-03-02
Hi Tim,
There is a help file named "LPC1700 Peripheral Driver Library
Manual.chm" in the CMSIS that I have. It is a windows help file and has
a good bit of information.
One complaint I have is that it is hard to find the NXP CMSIS at all.
They have a couple of versions on their website that you have to really
search for, but then I found some projects on http://sw.lpcware.com/
which is a git repository and that seems to have the latest libraries on
it. Note the sw at the front of that link.
Moses
On 03/02/2012 08:07 AM, Tim Mitchell wrote:
> ----Original Message----
> From: l...
> [mailto:l...] On Behalf Of M. Manca
> Sent: 02 March 2012 13:43 To: l...
> Subject: Re: [lpc2000] bit names in CMSIS
>
>> Il 02/03/2012 13:22, Tim Mitchell ha scritto:
>>> but where is the documentation for all the
>>> library calls?
>>>
>> No, generally there is a readme.txt. Generally it is
>> necessary to read
>> the source code.
>
> Really, well I'm not very keen on it then, as there are a large number of separate files to go through.
>
>> If you have to deal with a complex mcu peripheral do you
>> think that user
>> manual and datasheets coul be sufficient or you may
>> prefer to have a
>> more detailed documentation about the specific peripheral
>> and/or
>> specific examples/application note? When I think to a
>> complex peripheral
>> I think to CAN module or SCT and SGPIO (serial gpio) of
>> LPC43xx/LPC18xx microcontrollers, DMA modules, ethernet
>> modules and so on.
>
> I'm usually happy with user manual/datasheet, and examples are helpful. Unfortunately the NXP user manual is sometimes badly written or does not include some important information - I just spent a long time getting DMA working with SSP because it is not explained well in the user manual.
>
> But it would be really nice if NXP could include the library calls in the user manual with the peripheral descriptions. Then all the information is in the same place.
>
There is a help file named "LPC1700 Peripheral Driver Library
Manual.chm" in the CMSIS that I have. It is a windows help file and has
a good bit of information.
One complaint I have is that it is hard to find the NXP CMSIS at all.
They have a couple of versions on their website that you have to really
search for, but then I found some projects on http://sw.lpcware.com/
which is a git repository and that seems to have the latest libraries on
it. Note the sw at the front of that link.
Moses
On 03/02/2012 08:07 AM, Tim Mitchell wrote:
> ----Original Message----
> From: l...
> [mailto:l...] On Behalf Of M. Manca
> Sent: 02 March 2012 13:43 To: l...
> Subject: Re: [lpc2000] bit names in CMSIS
>
>> Il 02/03/2012 13:22, Tim Mitchell ha scritto:
>>> but where is the documentation for all the
>>> library calls?
>>>
>> No, generally there is a readme.txt. Generally it is
>> necessary to read
>> the source code.
>
> Really, well I'm not very keen on it then, as there are a large number of separate files to go through.
>
>> If you have to deal with a complex mcu peripheral do you
>> think that user
>> manual and datasheets coul be sufficient or you may
>> prefer to have a
>> more detailed documentation about the specific peripheral
>> and/or
>> specific examples/application note? When I think to a
>> complex peripheral
>> I think to CAN module or SCT and SGPIO (serial gpio) of
>> LPC43xx/LPC18xx microcontrollers, DMA modules, ethernet
>> modules and so on.
>
> I'm usually happy with user manual/datasheet, and examples are helpful. Unfortunately the NXP user manual is sometimes badly written or does not include some important information - I just spent a long time getting DMA working with SSP because it is not explained well in the user manual.
>
> But it would be really nice if NXP could include the library calls in the user manual with the peripheral descriptions. Then all the information is in the same place.
>
Reply by ●March 2, 20122012-03-02
Il 02/03/2012 15:36, Paul Curtis ha scritto:
>
>
> Hi,
>
> > > > > 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!
> > >
> > Hi Paul,
> > your opinion, as a tool vendor, may be different and interesting to
> understand
> > the situation about CMSIS both in the ARM part and in the silicon makers
> part
> > (mainly peripheral libs).
> > Do you think that ARM and silicon vendors may interface well with tool
> vendors
> > like Crossworks?
>
> Support for ISVs varies across silicon vendors. Let me drop some names
> from
> my perspective. Some are highly capable and highly enthusiastic about
> supporting ISVs--I will mention that Energy Micro fits into this category.
> Some will support you, as far as it goes, but they have bigger things
> to do,
> so ISV support is not their focus and they probably have their own agenda
> and favorites--NXP falls into this category to some degree, although
> knowing
> people within NXP it is easy to request help! And then there are some that
> plain can't be bothered to do very much for ISVs that support their
> silicon
> and are not highly motivated apart from maybe one lone engineer--Freescale
> fit into this category. Some have real 3P support schemes (Atmel, for
> instance) and 3P areas (Texas Instruments for the MSP430 is an excellent
> example).
>
> Dealing with all these different vendors, with their silicon release
> timescales, device support, and so on, takes a great deal of effort.
> We now
> have over 700 stock ARM boards on our shelves and there is no sign that
> Cortex-M device introduction is slowing--if anything it is accelerating!
> (New devices & new vendors in the Cortex-M world this week, even though we
> knew they were coming...)
>
> > Or do you think they could help their customers better
> > delivering to tools vendors they CMSIS compliant libraries (actually I
> know
> > only that we can find their CMSIS libraries on their web sites)?
>
> The CMSIS portal is now controlled by ARM; every silicon vendor should be
> delivering SVD files to ARM for publishing. ARM could curate the things
> better, but hey, there's only a certain amount of time in the day!
>
> > Being that many silicon vendors use standard ARM peripherals on their
> > microcontrollers could be correct that ARM could provide C libraries for
> these
> > peripherals saying what microcontrollers are using them to help silicon
> makers
> > to reduce their libraries implementations?
>
> What you're referring to is the PrimeCell and associated IP, I guess?
>
Yes.
>
> I
> wrote some standard drivers for things like the PL022, PL080, PL230 which
> you find in many Cortex-M and ARM7 devices. Yes, ARM could standardize
> this, but there isn't much of a point to doing so. I think the CMSIS RTOS
> API is going to be a bit of a pig to gain traction. My initial thought was
> "Great! Let's write to the CMSIS RTOS API", and then I looked at it, and
> enthusiasm drained away as fast as it came.
>
> > Personally I always prefer to use my own libraries (or well tested
> > libraries) because I am sure to have tested them so I can say "they
> works". Do
> > you think that this may generally influence the possibility to employ
> CMSIS
> > peripheral libraries? And if the CMSIS libraries supplier gives also
> some
> > "unit test" framework so we could repeat all their tests do you
> think may
> > increase the possibility to use them?
>
> I develop my own libraries; it means you know what the peripheral is
> doing.
> It's time consuming, but you don't need to wade through a huge layer of
> documentation and function calls just to find a write to a single bit in a
> register (StellarisWare comes to mind here...)
>
Thank you very much for your detailed answer, I appreciate a lot.
> --
> Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
> SolderCore running Defender... http://www.vimeo.com/25709426
>
>
> Hi,
>
> > > > > 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!
> > >
> > Hi Paul,
> > your opinion, as a tool vendor, may be different and interesting to
> understand
> > the situation about CMSIS both in the ARM part and in the silicon makers
> part
> > (mainly peripheral libs).
> > Do you think that ARM and silicon vendors may interface well with tool
> vendors
> > like Crossworks?
>
> Support for ISVs varies across silicon vendors. Let me drop some names
> from
> my perspective. Some are highly capable and highly enthusiastic about
> supporting ISVs--I will mention that Energy Micro fits into this category.
> Some will support you, as far as it goes, but they have bigger things
> to do,
> so ISV support is not their focus and they probably have their own agenda
> and favorites--NXP falls into this category to some degree, although
> knowing
> people within NXP it is easy to request help! And then there are some that
> plain can't be bothered to do very much for ISVs that support their
> silicon
> and are not highly motivated apart from maybe one lone engineer--Freescale
> fit into this category. Some have real 3P support schemes (Atmel, for
> instance) and 3P areas (Texas Instruments for the MSP430 is an excellent
> example).
>
> Dealing with all these different vendors, with their silicon release
> timescales, device support, and so on, takes a great deal of effort.
> We now
> have over 700 stock ARM boards on our shelves and there is no sign that
> Cortex-M device introduction is slowing--if anything it is accelerating!
> (New devices & new vendors in the Cortex-M world this week, even though we
> knew they were coming...)
>
> > Or do you think they could help their customers better
> > delivering to tools vendors they CMSIS compliant libraries (actually I
> know
> > only that we can find their CMSIS libraries on their web sites)?
>
> The CMSIS portal is now controlled by ARM; every silicon vendor should be
> delivering SVD files to ARM for publishing. ARM could curate the things
> better, but hey, there's only a certain amount of time in the day!
>
> > Being that many silicon vendors use standard ARM peripherals on their
> > microcontrollers could be correct that ARM could provide C libraries for
> these
> > peripherals saying what microcontrollers are using them to help silicon
> makers
> > to reduce their libraries implementations?
>
> What you're referring to is the PrimeCell and associated IP, I guess?
>
Yes.
>
> I
> wrote some standard drivers for things like the PL022, PL080, PL230 which
> you find in many Cortex-M and ARM7 devices. Yes, ARM could standardize
> this, but there isn't much of a point to doing so. I think the CMSIS RTOS
> API is going to be a bit of a pig to gain traction. My initial thought was
> "Great! Let's write to the CMSIS RTOS API", and then I looked at it, and
> enthusiasm drained away as fast as it came.
>
> > Personally I always prefer to use my own libraries (or well tested
> > libraries) because I am sure to have tested them so I can say "they
> works". Do
> > you think that this may generally influence the possibility to employ
> CMSIS
> > peripheral libraries? And if the CMSIS libraries supplier gives also
> some
> > "unit test" framework so we could repeat all their tests do you
> think may
> > increase the possibility to use them?
>
> I develop my own libraries; it means you know what the peripheral is
> doing.
> It's time consuming, but you don't need to wade through a huge layer of
> documentation and function calls just to find a write to a single bit in a
> register (StellarisWare comes to mind here...)
>
Thank you very much for your detailed answer, I appreciate a lot.
> --
> Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
> SolderCore running Defender... http://www.vimeo.com/25709426
