ek-lm4f120xl and CMSIS ?

Hi,

I cannot speak for TI - however there is a document describing the use of CMSIS DSP library with LM4F devices here: http://www.ti.com/lit/an/spma041a/spma041a.pdf.

Petrei

Hi Petrei,

I was primarily thinking of the "ordinary" CMSIS files, not of the DSP lib. As the core peripherals of respective Cortex controllers are supposed to be identical,  I wonder why TI does not include the mentioned ARM files. And since the linked document states in section 3.1 "To compile the CMSIS DSP libraries using Code Composer Studio, you must modify the DSP library include files. ", there are obviously no such header files provided by TI.

Second, I view the solution of having individual #defines for each peripheral register second-best. The mentioned ARM provided files use structure overlays, i.e. they define structs at the respective peripheral addresses. That has the distinct advantages of a new name space to avoid collisions, and, more important, allows more type safety than a preprocessor #define.

And third, the Stellarisware driverlib obviously doesn't use CMSIS compatible headers. This might have  historical reasons, but is obstructive to portability IMHO.

Having dealt mostly with ARM Cortex controllers from NXP and ST up to now, I'm just surprised by the way TI is handling this.

Hi,

Both your mentioned page in the first post and the document mentioned by me states you should download CMSIS files from onarm.com site. The document is useful for describing how to integrate everything within CCS - I do not know what is your tool chain - but can be useful if using other tool chains (and in such cases nothing to be modified). As for header files from TI, if I remember well, I downloaded them once (when the document was posted), don't know where is it now.  

As for portability I am reserved, since there are a many differences between the peripherals from various manufacturers.  

Petrei 

 Hi,

> Both your mentioned page in the first post and the document mentioned by me states you should download CMSIS files from onarm.com site.

sure I could do that. But this is not what I have asked for. I guess you have never worked with NXP and ST parts, and their version of peripheral libraries. The CMSIS file from ARM only provide the core peripheral layer, in the style mentioned in my earlier post. I would like to have such headers for all peripherals, and this would have to come from TI (as it comes from NXP and ST in the mentioned cases).

Asking to change the CMSIS header files (as in the document you linked to) suggests to me that TI does not have CMSIS conforming headers, nor intends to deliver it. I surely not going to do this.

Well, for bare-metal projects, one can go with the mentioned lmxxx.h header files. But saying "second best" in my first post, it has been an euphemism for bad coding style. Even Microchip had turned away from the "thousands of #defines" - method for their age-old PIC16/PIC18 controllers.

> As for portability I am reserved, since there are a many differences between the peripherals from various manufacturers.

Well, you are right here, that's one of the main points of having different vendors at all. And I have no statistics how often ARM Cortex projects are cross-ported, i.e. to a controller from another vendor. I do it much more often for my private projects than commercially.

>The document is useful for describing how to integrate everything within CCS - I do not know what is your tool chain - but can be useful if using other tool chains (and in such cases nothing to be modified).

I'm using CrossWorks, as it supports lots of controllers from different vendors. And I'm not a fan of Eclipse, but that is a matter of taste...

  Frank

Hi Frank,

Today I had a little more time to look at your problem. Searching my archives and projects I found the kind of files you looking for are in the package CMSIS_v1P30.zip (still can be downloaded with Google) - they are released by old Luminary Micro company. 

As for working with CMSIS, well, I worked with LPC1768 and LPC11C12. A STM board is still in waiting stage to gain attention, but no time.

Petrei

 Hi Petrei,

thanks for the information - albeit I begin to wonder even more...

I did expect some correlation to the acquisition of Luminary by TI. And I know there have been pre-CMSIS efforts of vendor specific libraries. It seems TI dropped LM's efforts to create a CMSIS compatible library, which is somehow confusing to me. I would really be interested in TI's opinion. I can judge TI's strategy only by it's actions, which contradict the announcements sometime. Possibly some internal faction compromise. As another example, a TI sales representative made the statement that there will be no M0 from TI - it is seen as an internal competition to the MSP430 devices. Atmel has a similiar strategy here, which only accelerates their fall into oblivion.

> ...I found the kind of files you looking for are in the package CMSIS_v1P30.zip (still can be downloaded with Google) - they are released by old Luminary Micro company.

I guess it does not help for the LM4F, which did not exist at this time...

> As for working with CMSIS, well, I worked with LPC1768 and LPC11C12. A STM board is still in waiting stage to gain attention, but no time.

ST's peripheral library is rather heavy leaned toward CMSIS. And they seem comitted to release a separate library version for each family. I made my first steps in the ARM - Cortex world with a STM32, so that's what I'm used to.

Conclusion: having some LM4F120 launchpad boards, I can obviously forget about CMSIS compatibility, and dive into the proprietary StellarisWare framework.

  Frank

Sorry for the delay in an "official" response. I've been looking into this in the background and have just found out the answer. Firstly, the reason that StellarisWare is different from CMSIS is purely that our architecture predated CMSIS by 2 or 3 years. It provides C APIs for all peripherals and, as far as I can gather, offers a lot more function that CMSIS at least as far as peripheral drivers are concerned. That said, it is, of course, different from CMSIS so doesn't help you if you are moving code from someone else's part to Stellaris.

We have produced a CMSIS example for the lm3s parts in the past but, as you note, this isn't particularly helpful for the new parts. In the software group, we are actually building CMSIS headers for every part and I gather the intention was that these would be provide to ARM to include on their site. We are now looking into adding them to the ti.com/stellarisware download site since it seems logical to have them there for people who come here looking for them. They are not posted yet, though, so if you can send me a private message telling me the particular parts you are interested in, I'll try to get the headers to you.

You mention the "inc/lmxxxx.h' headers. These are intended for people who want to program the parts using nothing but direct register access and whose code is specific to one particular part. I would not recommend using them if you intend to make use of the C functions provided in DriverLib since they are intended to support a totally different programming model. For driverlib, use the headers that you can find in the driverlib directory instead. The vast majority of these can be used without having to include any of the low level hardware or part-specific headers found in the "inc" folder (with the exception of the general "hw_types.h", "hw_memmap.h" and probably "hw_ints.h" files). If you do need direct access to the registers of a given peripheral, you can include the peripheral-specific header ("inc/hw_<periph>.h") and access the registers with the provided HWREG() macro.

Hi Dave,

First, thanks for the info - this is what I was looking for.

Firstly, the reason that StellarisWare is different from CMSIS is purely that our architecture predated CMSIS by 2 or 3 years.

I was aware of this, and that's quite comprehensible. And LM was rather popular for that.

By the way, others have similiar "legacy" libraries, like Atmels ASF.

It provides C APIs for all peripherals and, as far as I can gather, offers a lot more function that CMSIS at least as far as peripheral drivers are concerned. That said, it is, of course, different from CMSIS so doesn't help you if you are moving code from someone else's part to Stellaris.

As I understood, CMSIS dos not provide any peripheral functionality at all, except very basic core-related stuff like e.g. NVIC configuration. All the code related to the "interesting" peripherals has to come from the vendor - both the headers defining the register level, and a first hardware abstraction layer. For porting code from vendor A to vendor B, CMSIS compatibility plays just a small part. Actually, code accessing the periphery needs to be rewritten, and not ported. That is at least my experience

We are now looking into adding them to the ti.com/stellarisware download site since it seems logical to have them there for people who come here looking for them. They are not posted yet, though, so if you can send me a private message telling me the particular parts you are interested in, I'll try to get the headers to you.

Nice to hear it's in preparation.Thought I added the related part to the Thread tags...

You mention the "inc/lmxxxx.h' headers. These are intended for people who want to program the parts using nothing but direct register access and whose code is specific to one particular part. I would not recommend using them...

This "inc/xxx.h" file have a CMSIS counterpart, therefore my particular question. They follow the same pattern there, but define the register addresses according to the ARM style (C struct overlay). But there, they form the basis of the higher-level peripheral library functions. The high-level functions include this controller-specific header. I assumed the same relation for the Stellarisware at first...

I would not recommend using them if you intend to make use of the C functions provided in DriverLib since they are intended to support a totally different programming model.

Albeit being a "professional SW developer", I am in the fortunate position to investigate ARM controllers solely for private interest. So I can choose programming model at free will. And I will surely not start on a new controller with bare-metal code on register level.

By the way, at my day job I'm still messing with PIC18 for mass market products. It's a pity TI doesn't consider a Cortex M0. My company ponders over moving to ARM controllers, and eyes with a STM32F0.

  Frank