56 thoughts on “Are ARM CMSIS-Pack the Future of Software Components?”

1. I’m convinced that the future of software components is based on some kind of packs, but, as you mentioned, the CMSIS Packs are now too MDK & ARM CC centric, which limits their use. And, as long as ARM/Keil will continue to use the Packs as a marketing tool to promote their MDK, things will not change very fast.

   Another component based technology is [yotta](http://yottadocs.mbed.com) from mbed, which comes with an interesting component [repository](http://yotta.mbed.com/#/module/ilg-arm-cmsis/4.5.0-7). Unfortunately, their design also has some characteristics that makes integration with IDEs difficult (see [#606](https://github.com/ARMmbed/yotta/issues/604)).

   For GNU ARM Eclipse I’ll try to complement the CMSIS Packs with additional metadata (xPacks/XCDL metadata), and try to pack everything as yotta packages.

   The future GNU ARM Eclipse Packs Manager will be able to manage both CMSIS & XCDL packages, to download packs from any CMSIS Packs site, from yotta repository and from GitHub projects.

   Any help in this endeavour will be highly appreciated.

   Liviu

   LikeLike

   Reply ↓

   • Hi Liviu,
     I agree that the future is some kind of package manager. Thanks for the links to yotta: it strikes me that ARM is (again?) doing one thing with mbed and another thing with CMSIS/MDK. I see the advantage of yotta to be less XML loaded and with the ability to use command line tools (which is great for build automation and testing). But as you say: it lacks good IDE integration.
     As for myself, I will get a bit deeper into CMIS-Pack and will port some of my modules and then see how it works out. But I already realized that building up my first two packs is a lot of efforts, and it will be even more to maintain them. At least with your plugins it is not an ARM MDK only thing anymore. It is the third time now that I invested a lot of time and efforts into a technology, and then the vendor decided to drop it. I don’t want to have that again. If mbed goes away, I’m sure that yotta will not last long. And if MDK goes away, not sure what will happen with CMSIS-Pack?

     LikeLike

     Reply ↓

     • > yotta to be less XML loaded and with the ability to use command line tools

       I gave this subject a lot of thinking, and, to cut a long story short, the final decision is between XML and JSON (or derivative). Since now JSON also benefits from using schema validation tools, the distinction narrows to how convenient is to create/edit such files. Well, at first sight XML appears to win, there are lots of tools to manually create and maintain XML files, but… actually this is a wrong approach, a sign of poor tools design. The tools should not expect these files to be manually edited, but provide nice command line and GUIs to create and maintain the configuration. And in this respect JSON wins.

       So in xPacks/XCDL all metadata is stored in .json, and everything will be edited by tools (a command line tool, like yotta, and some Eclipse plug-ins), not manually.

       > At least with your plugins it is not an ARM MDK only thing anymore

       🙂

       LikeLike

       Reply ↓

2. Hi,
   We have for several years used the PEx to ease the configuration of various HC12 projects, and when we switched to ARM it was nice to find PEx also here. To my great surprise it seems that NXP is abandoning this now, and I honestly doesn’t understand what they are thinking.

   We are a small company and our products will last for 15-20 years, and we could not and will not jump to new technologies just because some vendor has a new idea. In my simple mind I thought that Freescale was delivering PEx and KSDK to make a competing edge against other ARM vendors, but now it seems that they are killing it all, and what remain then is price, so special strings will attach me to Freescale/NXP, so maybe the next project will be ST…

   As of your work, I have not dared to incorporate it in our projects, one reason is that there was competing beans from Freescale and McuOnEclipse.

   A wish for the future:
   Could you please now make your packages with a unique prefix, so that it will be easier to use packages from different sites.

   As a general idea, I’m very pleased with your thoughts regarding packages, and I will follow it with great interest, I totally agree that some kind of processor independent packages will be a very valuable contribution to the various projects.

   Thanks for your contribution.

   LikeLiked by 2 people

   Reply ↓

   • Hi Ole,
     Thanks for your comments and thoughts! ‘Abandoning’ depends on how to look at it: I think it will be still around for some years, but not for new devices. Similar to what happened to CodeWarrior for Microcontrollers a few years ago. And some of the Processor Expert functionality will go into the Kinetis Expert concept. So there is something replacing that, but it is not the same, so I need some way of migration, thus I’m looking into CMSIS-Pack.
     As for your point about using a unique prefix: You can distinguish Processor Expert components with different repositories. But if you are on S12, then this will not help you as Processor Expert has not been moved to Eclipse for S12/HC12.
     Otherwise, that problem is nicely solved with CMSIS-Pack too: there is a ‘vendor’ field in CMSIS-Packs allowing to easily distinguish packages. And it has version management built in. So from this perspective, CMSIS-Pack is a viable approach. But it is only a subset of the Processor Expert technology. CMSIS-Pack is only about packaging and dependencies, but has no intelligence (or I have not seen it) to configure software and drivers.

     LikeLike

     Reply ↓

   • I agree with Ole here. We have a long (and sometime turbulent) history designing products around Freescale MCUs and using their dev tools. For our latest generation of products we had decided on ARM cores, but given the choice between the various ARM vendors ST and NXP (LPC-series) were also high on our list. After much deliberation, the Freescale Kinetis parts were chosen largely due to the SDK and the Processor Expert tools. We later discovered that the SDK doesn’t support the MKE0x series parts, and now processor expert is deprecated. So much for our choice…
     -Mike

     LikeLiked by 1 person

     Reply ↓

3. to spin the whell a bit further…. wouldn’t it be nice to have a standardized HAL for different microcontrollers?

   There is a bit of a mess when it comes to such things like APIs across vendors or even their product families. In my understanding CMSIS was a good idea, but does not cover enough to make software easily portable.

   I have stumbled across some projects trying to unify the programming of microcontrollers at a HAL-Level.
   one of it is stm32plus which tries to ease the programming of stm32parts with a unified API
   https://github.com/andysworkshop/stm32plus

   some time was thinking about the arduino platform as a good reference. there exist ports for nearly any kind of processor. The support varies and highly special features like DMA-Triggering and fancy timer chaining are not seen at all.

   If i was a bit more certain which way would be the right one, I would have little trouble to find good arguments to put some of my work into supporting such a project.

   this would also ease the creation of a “ARM Cortex-M Software Repository”…

   what other HALs do you know which ease the support of writing embedded software as chip-vendor independent as possible?

   thank you!

   LikeLike

   Reply ↓

   • Hi Peter,
     very good thoughts! What comes to my mind is AUTOSAR (http://www.autosar.org/) which basically does what you are proposing (and which you might know already?): a unified vendor neutral API for programming automotive applications.
     I don’t expect ARM or any of the ARM vendors to come up with something like this, because every vendor tries to separate and keep things under their control, with the way they want it.
     In the AUTOSAR case the ‘customers’ (BMW, BOSCH, Continental, Daimler, Ford, GM, PSA, Toyota, VW) have forced the silicon vendors to get together and define a common API and standard. Along the line “if your silicon and software does not conform to the AUTOSAR, we won’t buy from you anymore”. In this case the group of customers was big and strong enough to get AUTOSAR established. ARM in my option is doing similar with CMSIS in my view, but has a much weaker position: ARM can suggest the standard, but not enforce it because the silicon vendors are the customers of ARM. Putting all the CMSIS together gives a good marekting story, but falls short if still everyone is doing its own thing to protect its business? On the other end I think that big companies like Google and others are big enough to make their own HAL and to control their own destiny, because it is strategic for them and they can affort it.
     Moving things even to a higher level (my university point of view): development, quality of software support for Intel parts are better than for ARM, to the point that I see software development for Intel easier than for ARM (see as well http://appleinsider.com/articles/15/01/16/five-barriers-that-might-hold-apple-back-from-moving-intel-macs-to-custom-arm-chips). From my own engineering perspective I love the ARM core, but I have to admit that the development for Intel parts (again in my personal view) is easier and better. I’m not a Microsoft fan, but I have to admit that their Visual Studio environment is a different class of tools, with a GDB for Visual Studio here: http://visualgdb.com. My 1 cent is that I think such a unified API or HAL needs to come from the bottom, and won’t be able to come from the top in the case of ARM. Or that simply engough customers demand standard X (which could be from ARM).

     LikeLike

     Reply ↓

4. Hi Erich,

   highly appreciate all your work around PEx, it’s pretty amazing!
   Regarding the article:

   I think CMSIS aim is different from the PEx one significantly, although some principles (packaging) used on both might look very similar.

   Within design of PEx at the start I intended not to give user just control over the SW “BOM” capable to be build using different environments, but to have intelligent set of components interacting with the MCU knowledge system and helping user with the MCU/board resources management and configuration under RAD principles.

   Regarding the HAL, we came with PEx components API and inheritance capability several years before Autosar. I totally support idea to HAL should come from the bottom – as mentioned on the previous reply. But, why to build something new from scratch, better to reuse proven APIs on many MCU architectures…..

   LikeLike

   Reply ↓

5. What do you think about ARM concept of standardised driver API here http://www.keil.com/pack/doc/CMSIS/Driver/html/index.html ?

   LikeLike

   Reply ↓

   • Hi Milroad,
     My view is that the intention is a good one, and would play well with CMSIS-Pack concept. But given the vast majority of different ways to implement an API, and given the passion (or disputes) about APIs I think this one will be even harder to get a common standard than CMSIS-Pack. I think overall it could work for ARM, but not for the individual silicon vendors. It *might* work for the middleware vendors. But I see the middleware (RTOS, stacks, etc) provided for free mostly by the silicon vendors, so I think they have no interest in making that part common. I think CMSIS-Driver could be technically the ‘AUTOSAR’ for ARM. But as long there are no big OEMs demanding it, the future of CMSIS-Driver is unknown to me. It would be interesting to hear why ARM is doing CMSIS-Driver, and the same time using something completely different with mbed.

     LikeLike

     Reply ↓

     • It looks like mbedOS has the CMSIS-Driver API in plan (last post):
       http://forums.mbed.com/t/cmsis-flash-interface-in-mbed-os/1156/4

       LikeLike

       Reply ↓

       • Yes, ARM is pushing this (and mbed is part of ARM). I’m not convinced yet that CMSIS-Driver will succeed if not more are adopting it. Only the future will tell 🙂

         LikeLike

     • I switched to CMSIS Drivers for USART and USB, and, at least for F4/F7, they’re fine. I even wrote a USB CDC driver that behaves like a USART driver.

       The only design problem that I encountered is that callbacks are non-reentrant, if you have multiple devices you need to write a callback for each one, you cannot reuse callbacks with a parameter.

       Given some time, they’ll probably succeed.

       LikeLiked by 1 person

       Reply ↓

     • > Given some time, they’ll probably succeed.

       just for the records, I’m currently moving away from CMSIS Drivers, the rate of progress is way too slow, so I’m no longer endorsing the CMSIS Drivers. If you live inside the Keil MDK ecosystem, you’re probably ok, but otherwise the CMSIS Drivers are constant source of pain (mainly due to the design, but also the implementation).

       LikeLike

       Reply ↓

6. On the topic of HAL unification and “abstraction”, how about the opposite approach? I mean the “inversion of control” applied to this domain? I would say that the chip vendor should provide the “framework” part of the event-driven, inverted control logic, while application programmers plug in their product-specific extensions to form “the app”. For example, the framework provides “onInitDone()” event (callback, extension point) where one could call some APIs to enable and configure the UART, later “OnUartDataReceived()” event (callback) gets fired by the framework and our MODBUS driver (for example) gets busy. In this context my MODBUS protocol engine (middleware, component) become totally platform independent (including ARM vs MIPS vs xxx). This is often associated with “node.js” style where one could implement complex applications in a single threaded environment … Sure this needs some more work to be hard real time proof, but there comes the active objects and “event service threads”.
   The main point is to avoid “forwarding” configuration and connection information through multiple layers (e.g. to avoid the situation where HMI component needs “COM port number” configuration field, which is passed to the MODBUS component’s “COM Port number” input, which is passed to some kind of “resource manager” that could resolve the “COM1” name to precise handle and so on. This style (the “forward control”) leads to exploding dependencies between components that bring more and more abstractions. While this (“forward”) approach might be useful for general-purpose operating systems (Windows, Linux, Arduino) because of simplicity where one expects that anyone could build new applications (so called “web programmers”), it does not fit in embedded world where product quality and availability (up time) is important as well. How often one needs to change the index of the UART (or SPI, or I2C) port where the EEPROM is soldered, after the point when the firmware get compiled and linked?
   My point is that if we learn how to create SW components that strictly perform only the direct work they are designed for, and find a way to simplify connections between those “self-sufficient” components, that we don’t need abstractions and common interfaces.
   As we see from the comment of Ole Asbjorn Fadum, depending too much on technology from given vendor always bring the risk of getting dissapointed. So we need approach that could “interconnect” different technologies. This could be based on simple, plain ANSI C – in the form of “glue logic” at places that don’t stick together naturally.
   Another example could be a protocol middleware – in case of inverted control, this one would be separated in independent serialization functions and transport functions. Whenever one uses it he/she needs to make the “glue” – to call the serializations and to use the result as argument for second call to the transport layer (for example, Eclipse mqtt Paho embedded C source base). The “forward” approach would give one function that will make both (serialization and sending) and would require some kind of handle to the transport channel. Maybe TCP based at first. To switch to another interface (e.g. Serial) one needs to develop another class that implements exactly the same interface. And this “abstraction” might be not usable for serial transport (for example, because TCP defined IPv4 addressing information while Serial needs 4096 byte long string to be able to resolve “\\\\.\\xxxxx\iiiii\COM245”).
   If we want to do the same in “inverted control” style, we would not touch the serialization routines, we just call the serial access functions (and not some particular style or interface, we can easily call any available API being it Linux, Windows, ChibiOS, mbed, arduino…).

   LikeLike

   Reply ↓

7. I know that I am not a good speaker, and English is not my native language, a great overview for reference:
   http://www.state-machine.com/doc/concepts.html

   LikeLike

   Reply ↓

8. Hi Erich,

   You are writing ” … I have found out that even if a software components does not depend on a device or a given compiler, you *have* to restrict it with a dependency to a device or compiler, otherwise it does not show up in the ‘Runtime Environment’”.

   That is incorrect, a component can be entirely generic (no “condition” attribute is provided) or define only software dependencies in its condition. I have specially tested that it works in uVision and in CMSIS-Pack Eclipse plug-in.

   LikeLike

   Reply ↓

   • Hi Evgueni,
     thanks for that input. I’ll have to check what exactly happened, as I was changing the file back and forward. It could be that I have indeed made a mistake somehow, or it was a refresh issue.
     I will try to reproduce it (but won’t be able probably before the weekend) and report back. But what I remember is that I have run the .pdsc through the normal batch file (which includes the checker?), but I have not seen a warning or error? Maybe I missed it?
     Many thanks!

     LikeLike

     Reply ↓

     • The batch file does not perform the formal schema check, it should be done by an XML editor.
       The PackChk executable only validates pack consistency that goes beyond formal schema check: physical existence of listed files, presence of referred conditions, etc.
       see: http://www.keil.com/pack/doc/CMSIS/Pack/html/_create_pack_util.html

       LikeLike

       Reply ↓

       • Hi Evgueni,
         indeed, I was that not correctly reading, and indeed the batch file does not do such a check :-(. I have now verified the files (https://mcuoneclipse.com/2016/02/20/xml-editor-checker-for-cmsis-pack-in-eclipse/) and fixed them, and things are looking OK now.
         Many thanks for that important information!
         Erich

         LikeLike

   • Hi Evgueni,
     Yes, you are indeed correct and I was wrong. I guess I was on the wrong path due other issues, plus as you pointed out on GitHub my XML file was not according to the schemata. I updated the article and files.
     Thanks!
     Erich

     LikeLike

     Reply ↓

9. Hello

   I’ve just installed the CMSIS Pack plugin and I’ve downloaded the packs. Also I’ve configured both paths to point to where the packs are installed and the “Installed CMSIS Packs” and “CMSIS Devices” views are empty. How can I populate them? I can’t find the option to refresh the view 😦

   Thanks!!

   LikeLike

   Reply ↓

   • Hi Manuel,
     I assume that you have used GNU ARM Eclipse pack manager from gnuarmeclipse to install the packs. That plug-in is independent from CMSIS-Pack Plug-in from ARM.
     Those plug-ins do not share the same preferences snd should be configure separately.
     You need to set “Window->Preferences->CMSIS Packs -> CMSIS Pack root folder” to the location where packs are installed to make CMSIS-Pack plug-in work.

     LikeLike

     Reply ↓

     • Thank you for helping! Nevertheless, the “package folder” configuration from the GNU ARM eclipse and the “CMSIS pack root folder” configuration from the ARM CMSIS-Pack plugins are pointing at the same path as explained in the post but I still can’t see the ARM CMSIS-Pack Plugins views populated.

       LikeLike

       Reply ↓

   • Have you tried to restart Eclipse?
     If it does not help, please check if packs are correctly installed:
     ${CMSIS_PACK_ROOT}/Vendor/Name/Version
     Please note that you cannot install packs to a hidden directory or directory starting with ‘.’ or directory that already contains a *.pdsc file.

     LikeLike

     Reply ↓

     • I checked the installation path and I didn’t have any folder, then I realized that I had just hit the yellow refresh arrows but I had’t actually installed any package. I right-clicked all the packages I need and now I can see them.

       But thanks anyway for helping since your suggestion helped me to realize this!! 🙂

       LikeLike

       Reply ↓

10. Hello,

    So, is it time for a guide for an eclipse based DIY development environment without PEx?
    I tried, but the KSDK plugin installation fails. It looks like there is a PEx dependency.

    Iñigo

    LikeLike

    Reply ↓

    • Which KSDK plugin did you try to install? Yes, the SDK v1.x have a dependency on PEx, but not the SDK v2.x one.

      LikeLike

      Reply ↓

      • That’s the key.
        Thank you.

        LikeLike

        Reply ↓

11. Pingback: XML Editor & Checker for CMSIS-Pack in Eclipse | MCU on Eclipse

12. Hi Erich,

    Thank you for your updating article. It has raised my already growth concern regarding Kinetis family. I have been using KL15s, KL16s and K10s always with PE and IAR. I have used your PE components very often so thank you very much for making my live easier. PE seems to be reaching its EOL and it looks like it won’t be supporting any new processors. I was hoping I would be able to keep using the IAR Embeeded Wrokbench with this new CMSIS package approach to reuse code have some kind of trusted HAL that allows me to jump into new processors within a short time. Have you done some research about IAR supporting CMSIS package? Do you know if that will even be possible in future? I know the is no “the best compiler + IDE” since each one has its ups and downs; but if I had to move from IAR in order to use CMSIS packages what tool would you recommend me to used?

    William

    LikeLike

    Reply ↓

    • Hi William,
      I don’t know about plans of IAR, but my guess is that if CMSIS-Pack takes off and gets the industry attention, they problably have to support it in one way or the other. Unfortunately I cannot be at the Embedded World in Nürnberg next week, otherwise I would have asked them there.
      As to which IDE to use otherwise: There is an Eclipse version of IAR (see https://mcuoneclipse.com/2013/11/03/tutorial-replacing-iar-ew-with-eclipse-ide/), but I have not used that recently, but should still be a valid option. If you don’t want to use Eclipse, of course there is the Keil MDK. What you could use in any case is to install the Keil MDK (you don’t need to buy a license) and then use the CMSIS-Pack package manager: that way you get the packs independent of the IDE. Then use the pack files with your IAR. You won’t have the RTE (as shown in this post), but that might not be that much of a deal. And you can continue to use the IAR tools/compiler.
      I hope this helps,
      Erich

      Erich

      LikeLike

      Reply ↓

      • Hi Erich,

        Thank you very much for your reply. I will explore the IAR plugin for eclipse option, I was using PE + IAR anyway so I guess this won’t be much of a change for me. Thank you again for your help and keep up with your blog, it is awesome.

        William

        LikeLike

        Reply ↓

13. What is the difference between creating the project as “CMSIS RTE” and creating the project with the “KSDK V2.0 project wizard”? I mean, what should I use?

    I’m just starting to work on this MCUs and I’m confused with all the ways a project can be created.

    I think it would be very beneficial if you could create a new post in the blog highlighting the differences.

    Thanks!

    LikeLike

    Reply ↓

    • Hi Manuel,
      The CMSIS RTE project wizard is provided by ARM and is a wizard on its own. It creates CMSIS compliant projects using CMSIS-Pack using RTE. The KSDK v2.x project wizard creates NXP projects using the Kinetis SDK driver library.

      LikeLike

      Reply ↓

14. Hello Erich
    I was taking a look into the CMSIS-pack approach and I have a question. I was able to create the CMSIS RTE project but I see that there is no peripheral driver added and nowhere to add one right? I can only add the startup code, the CMSIS Core, and the CMSIS DSP.

    I was reading at the CMSIS website in the CMSIS-Driver documentation that the CMSIS-Driver specification is just a software API comprised just by header files. These header files are the reference for the implementation of the standardized peripheral driver interfaces and that these implementations are published typically in the Device Family Pack of a related microcontroller family under the Component Class CMSIS Driver.

    Then at the “Reference Implementation” in the same site I read that the CMSIS installation contain some implementation templates that have empty functions that match the API specification.

    This means that, for instance freescale (NXP) should provide the drivers implementation in such a way that can be used with this CMSIS-Driver API specification right?

    Or maybe at this stage of the project I should write my own CMSIS-Driver implementations based on the KSDK drivers to be able to use them with CMSIS-Driver API.

    Is this correct?

    Thanks!!

    LikeLike

    Reply ↓

    • Hi Manuel,

      The CMSIS RTE is only a manager of CMSIS-Packs, regardless what is in the packs. And you see some CMSIS-Core and CMSIS-DSP because you have these packs installed on your machine.

      The CMSIS-Driver is an API, so you are correct, it provides the interface. The silicon vendors have to provide the driver implementation, and this is missing in this case. You are free to implement that, but I would think that’s not a simple task, depending on how many drivers you need.

      Erich

      LikeLike

      Reply ↓

15. Liviu Ionescu pointed me to this: CMSIS++
    homepage: http://micro-os-plus.github.io/
    git: https://github.com/micro-os-plus/cmsis-plus

    for me this sounds very promising if it gets big.

    what do you think?

    LikeLike

    Reply ↓

16. Hi Erich,
    I went to https://github.com/ARM-software/cmsis-pack-eclipse-prebuilt but I get a network 404 error.
    Anyway I installed CMSIS pack from http://gnuarmeclipse.github.io/plugins/packs-manager/, followed all instructions (I hope 🙂 ), but I can’t see any peripheral for KE02.
    I installed only latest version of KExx_DFP which currently is 1.7.0: debugger is connected by I can’t see anything in Peripheral View.

    Best Regards
    Roberto

    LikeLike

    Reply ↓

    • > I can’t see anything in Peripheral View

      use a supported JTAG probe, and it should work. J-Link is a good choice.

      LikeLike

      Reply ↓

      • Hi Liviu.

        What about P&E Multilink FX I’m using?

        It is debugging, I can see memory and CPU registers I only can’t see peripherals.

        Thanks a lot

        LikeLike

        Reply ↓

        • > What about P&E Multilink FX I’m using?

          no idea, not one of my plug-ins.

          LikeLike

        • ok, thanks a lot.
          I will try with J-Link.

          Best Regards
          Roberto

          LikeLike

    • Hi Roberto,
      The https://github.com/ARM-software/cmsis-pack-eclipse-prebuilt repository does not exist anymore. The pre-built plug-ins can be found here:
      https://github.com/ARM-software/cmsis-pack-eclipse/releases

      LikeLike

      Reply ↓

      • Thank you very much Evgueni!
        @Liviu Ionescu: with J-Link is ok, so it’s a P&E micro issue

        Best Regards
        Roberto

        LikeLike

        Reply ↓

17. Hello Erich,
    thank you very much for your posts as usual… Very very very helpful!

    Anyway I must apologize for my BIG ignorance but I can’t understand the reason why if I install GNU ARM Eclipse CMSIS pack I should also install the ARM CMSIS pack.
    Shall I install both or only one of them?

    Moreover I tried to create a project with CMSIS C/C++ for KE02 and KE15 but I can’t see the C startup file despite the Device.Startup property is selected: in fact I have system_MKExxx.c file created with SystemInit function but I was expecting to find a vector table and the reset handler with a branch with link to main.
    Something is missing because I get a linker error (“undefined reference to _exit in exit.c”) but I neither can find exit.c in the project 😥

    Thanks again
    Best Regards
    Roberto

    LikeLike

    Reply ↓

    • Hi Roberto,
      you don’t need both plugins, and you could go with the GNU ARM Eclipse plugins alone. I have both installed because both plugins have their pros and cons, and with both I can use both pros :-).
      If you get an error about a missing _exit(), then this usually is a problem that a ‘no sys’ linker flag is missing. As embedded applications usually do not use exit, you might simply add something like
      void exit(int dummy) {} to your code to make the linker happy.
      About the vector table: at least the Freescale/NXP code has it in the assembly startup file.
      I hope this helps,
      Erich

      LikeLike

      Reply ↓

      • Hi Erich,
        thanks a lot.
        Anyway I thought to get the C startup file starting a CMSIS Pack based project.
        Moreover, as a matter of facts, we only need 1 C startup onle for CM0+, no matter the vendor.

        Thanks again

        Best Regards
        Roberto

        LikeLike

        Reply ↓

18. Hi Erich,
    I don’t know if it’s you or maybe Evgueni Driouk that can reply to me about it.
    Anyway I made a clean Eclipse Neon.3 installation with only Gcc and Build tools installed.
    Then I installed GNU ARM Eclipse Plugin without GNU ARM CMSIS Pack installed.
    I installed ARM CMSIS Pack plugin and tried to create a project for NXP Kinetis KE02.

    If I choose Cross ARM GCC I don’t get the startup file! 😦
    Anyway if I choose Cross GCC (but I have to enter GCC and build tools path) I get the startup .s file.

    Next step is to re-include GNU ARM CMSIS Pack: what I noticed is that ARM one helps me create the project, when I was not able to do it with GNU ARM Eclipse one.
    On the other hand I’m sure I’m able to debug and view Peripherals with GNU ARM plugins, so I think I may use both, as you described in this post.

    My aim is to create an Eclipse “distribution” (at least for ARM) not depending on silicon vendor, and I don’t think I’m so far from this target.

    Thank you very much for your support.
    This blog is a mine, and even supported by great developers…

    Best Regards
    Roberto

    LikeLike

    Reply ↓

19. Hi Roberto,
    Please note that ARM CMSIS-Pack Eclipse Plug-in has a limited usage in a generic Eclipse CDT.
    Its primary goal to allow IDE developers to enhance their tools with CMSIS pack support.
    You still need a toolchain integration and a debugger integration (other parts of an IDE).
    The pre-built plug-in only supports Cross ARM GCC toolchain (because it is very good implemented and provided as an open source).
    If you want to use another toolchain you need to write you own “toolchain adapter” plug-in.
    The ARM CMSIS-Pack Eclipse Plug-in itself does not provide any standardized way for debugger integration, but does provide API to query device information that a debugger plug-in can query.

    As far as startup files are concerned, Keil.Kinetis_KExx_DFP.1.7.0. has limited support for GCC (you should still see system_MKE02Z2.c file from Device.Startup component).
    However you can implement your version of a Device.Startup component including all required GCC startup and linker script files and then create a CMSIS pack to distribute it.

    Best regards,
    Evgueni

    LikeLike

    Reply ↓

    • Hello Evgueni thanks for your kind reply.
      Sorry for late reply but I don’t have a lot of time to dedicate to this project
      What you mean is clear to me.
      First of all I will add GCC device Cstartup and linker file manually and then export the project: my colleagues can import it and start working after setting up eclipse IDE.
      Then I will try and create a CMSIS pack to distribute.
      Is this post quite enough to understand how we can do it or do I need additional material? If so can you provide some links?

      Thank you very much

      LikeLike

      Reply ↓

      • Hi Roberto,

        all you need to know about creating and publishing CMSIS Packs can be found in the CMSIS documentation at http://www.keil.com/pack/doc/CMSIS/Pack/html/index.html.

        I would like to invite you to use our GitHub issue list at https://github.com/ARM-software/CMSIS_5/issues if you have further questions and/or feedback.

        Regards,
        Jonatan

        LikeLike

        Reply ↓

20. Just wondering if the CMSIS RTOS is AUTOSAR compliant? Or if it comes from OSEK, the RTOS that AUTOSAR built on?
    I’ve gone from STM32f10x parts to Kinetis K25 and mKL03z to KL26z and mKL82 and now back to STM32MP157 (for Linux) and next i.MXRT1020 (for non-Linux Ai), so standardized SW portability is of great interest to me

    LikeLike

    Reply ↓

    • As far as I know, AUTOSAR is a large collection of rules, but I don’t know how many of them apply to the API and how many apply to the implementation. CMSIS RTOS is just an API definition, and the implementation is Keil RTX, so the question is if CMSIS RTOS + RTX are AUTOSAR; since I could not find references to AUTOSAR in the documentation (https://www.keil.com/pack/doc/CMSIS/RTOS2/html/index.html), my guess is that they are not.

      LikeLike

      Reply ↓

    • To my understanding, AUTOSAR and CMSIS RTOS are two different things: AUTOSAR is a common API defined by the automotive industry and not necessarily bound to ARM cores. While CMSIS RTOS is coming from ARM (or Keil RTX) and is basically an ARM only (to my knowledge) thing.

      LikeLike

      Reply ↓

This site uses Akismet to reduce spam. Learn how your comment data is processed.