CMSIS for teensy 3.0

Status
Not open for further replies.
Hi,
sorry for bumping an old thread but I think is the right place to ask.
I bought a Teensy 3.1 recently in order to have a cheap and simple platform to get into ARM Cortex developing for robotics applications. I'm not interested in using arduino. I would prefer to program directly on C, Make, etc.
I'm a bit used to programming with PIC so I expected something like some standard libraries to handle peripherals and basic functions.
Looking at the core code (which I took from teensyduino, and I can now compile simple examples using make) I see there's like a mix between custom PJRC code and CMSIS code. It is quite confusing to me to understand which is the correct API to rely on. For example, I was trying to use as much as CMSIS (being a standard) but I saw that, for example, for enabling interrupts (for which there is a CMSIS function) there is an alternate macro (NVIC_ENABLE_IRQ). I don't understand why this is done. Do the functions in core_cmFuncs.h not work for teensy?

I'm struggling a bit to know which functions to call to develop C applications without using arduino.

Thanks!
 
If it's Arduino's IDE you wish to avoid, you may want to use (as I do) Visual Micro, a free plug-in to Atmel Visual Studio which is an adaptation of Microsoft's Visual Studio. Or use Visual Studio itself if you have it.
The Teensyduino hardware library code is extensive and will save a huge amount of work for you. It would be imprudent to start from scratch. The CMSIS code, in my assessment, is not desirable for what students/hobbyists do.

The libraries support many things you will want to do... all the USB/serial, UART serial drivers (w buffered interrupt/FIFO drivers); Ethernet Wiznet IP offload that works well); Several SPI peripherals such as HopeRF /SiLabs data radios, XBee radios, SD card/FAT, new Audio signal processing, and more. Rarely does one have to augment core code - use use libraries that exist, alter them to suit, write your own, and so on.
 
If it's Arduino's IDE you wish to avoid, you may want to use (as I do) Visual Micro, a free plug-in to Atmel Visual Studio which is an adaptation of Microsoft's Visual Studio. Or use Visual Studio itself if you have it.
The Teensyduino hardware library code is extensive and will save a huge amount of work for you. It would be imprudent to start from scratch. The CMSIS code, in my assessment, is not desirable for what students/hobbyists do.

The libraries support many things you will want to do... all the USB/serial, UART serial drivers (w buffered interrupt/FIFO drivers); Ethernet Wiznet IP offload that works well); Several SPI peripherals such as HopeRF /SiLabs data radios, XBee radios, SD card/FAT, new Audio signal processing, and more. Rarely does one have to augment core code - use use libraries that exist, alter them to suit, write your own, and so on.

I guess I should have clarified also some reasons for my question. I work on robotics as a researcher, so my goals/requirements are beyond of a hobbyist (I can care in some cases more about efficiency over ease of programming using C++ classes, as in arduino). I work exclusively on Linux, so Visual Studio is not a solution for me. Moreover, relying on an IDE (which most times is not open source and/or free) is something I wish to avoid, since it is one of the annoyances of working on PIC and relying on its IDE, programmer, etc.

I undestand that teensyduino C/C++ code is quite complete, but there is a strange mix of C and C++ (I guess it comes from the fact that the Arduino libraries uses C++ as a base) and I couldn't quite understand which functions should I use. Moreover, as I said in my previous post, there seemed to be some functions which were already implemented in CMSIS library which were not used and custom macros were used instead. I wasn't sure why these overrides were done since CMSIS seems to be something that provides a standard API for some basic aspects, and by taking advantage of certain Cortex features.
When inspecting the headers, this further confused me on which functions to call. Furthermore, some functionality is available with both C and C++ interfaces and others not. I'm not sure if using a C++ class in a microcontroller may have a cost in efficiency over simple C functions or not.
One final concern is size: I noticed that if I remove all .cpp's from teensy core library, even when using a simple blink.c example, which does not invoke any functions from, for example, IntervalTimer.cpp, the library size is quite smaller. Maybe this could be solved by using special compiler flags, but otherwise I feel inclined to remove all but the functionality I require in order not to waste space.
 
I regularly mix C and C++, and have no issues with regard to speed.
For example, my IP stack is written in C, and I have it interfaced to all sorts of C++ code, and I get 6 to 7ms pings on a 16MHz AVR, and this is with context switching overhead.
 
Great. I will have to look into this to be sure if there's any performance hit.
Regarding size, I just applied the ideas posted in this thread: http://forum.pjrc.com/threads/25196-How-to-get-a-little-bit-more-FLASH-room-on-Teensy-3-x
(in few words: put everything on a static library, add flags to avoid linking unused code, force linking mk20dx128.c)
In this way, I can now use all .c and .cpp files and the compiled size is always the same (very little) since I don't require all stuff in the library.

I guess that my approach should be to look into the code of any functionality I require and convince myself that the code is efficient for my purposes. If not, I can change it.

I would still like to hear from Paul as of which is the reason for providing stuff CMSIS already provides. It would be nice to stick to standard interfaces, IMHO.
Good thing is that now I can try to compile CMSIS fully, which should not increase size unless I use something from it.
 
Just my 2c, we ported all of our code to CMSIS, just to come back a few months later and everything had changed. That was over 2 years ago, and I've watched the published "CMSIS" code go through a number of more transformations. None of which I think are all that valuable.

So for now I follow some of the CMSIS conventions, I really just treat it as a code example, that I cut and paste useful things from, or write from scratch in many cases. One of those cases is the clocking, which for some chips is a ridiculous spaghetti of code for something that should really be pretty simple, turn on oscillator, program PLL and go.
 
I would still like to hear from Paul as of which is the reason for providing stuff CMSIS already provides.

When I started working on Teensy 3.0, over 2 years ago, I took a pretty good look at CMSIS. My general feeling was that it added a LOT of complexity for stuff that really ought to be pretty simple.

Different people have different coding styles. My approach could be called "less is more". I generally strive to keep code short and use only basic compiler types, or stdint types (uint8_t, int32_t, etc), and with limited usage of structs and typedefs. My idea of readable code is based on getting it all to fit into a single window (on a large or tall monitor) with as few other windows needed to make sense of the code. CMSIS, at least as it existed 2 years ago, it simply not the way I like to do things.

Another goal of Teensy3 has been providing an environment that "feels" familiar to people with a lot of experience on AVR. I'm honestly not sure how successful that's been. There are a lot of little things I've wanted to do, but never had time. But my opinion was build on top of the CMSIS abstraction layer would feel very foreign to people familiar with 8 bit AVR programming.

It would be nice to stick to standard interfaces, IMHO.

Teensy3 does exactly that, if you consider the Arduino API and the major Arduino libraries and a small but widely-used subset of the 8 bit AVR registers as the standard interface. Well, "standard" is the wrong word, perhaps "de facto" would be better?

Teensy is meant for hobbyists, students, entrepreneurs, and rapid prototyping, where simplicity and ease of learning are the most important goals. Standards like CMSIS are designed for an audience of processional engineers and software developers, who value powerful interfaces and the complexity that comes with them. CMSIS's API depends upon solid knowledge of concepts like pointers and structs, which runs counter to Teensy's goals.

As a business model for PJRC, 2 years ago there were plenty of 32 bit products on the market offering CMSIS compatibility, but Maple was the only board attempting Arduino compatibility. Even now, with many more products entering the market, including Arduino Due, I think it's fairly safe to say (or boast) Teensy3 has by far the widest 32 bit compatibility with Arduino sketches and libraries. It's a place where PJRC can offer something that's actually valuable, and also a space where I'm personally interested. CMSIS is neither of those.
 
Thank you for your replies! I have a clear idea on the software decisions now.
I didn't meant to bash on your choice of not using CMSIS, by the way. I congratulate you for the work on Teensy =) (both software and hardware)
 
I too didn't find CMSIS useful for what I do, non- or para-professional. If I did DSP like things, maybe CMSIS would be useful.
But I too believe that it missed its goal of a semi-universal library for chips in a family, to reduce reinvention of the wheel.

I do embedded hardware/software as a large but fractional part of my professional work - and that is mostly networked wireless, sensor control/data acquisition. I didn't find CMSIS aimed at that, either. Maybe the CMSIS is aimed an automotive engine control unit embedded. Not sure.
 
Considering the fat that the Due and upcoming Zero products are using CMSIS, it may be an excellent way for Paul to go forwards.
Anyone who has enough time and who cares, can always beat generic code. This seems to eat a lot of Paul's time.

The only bits I dislike, are how the Arduino parts that interface CMSIS tends to hide some details, and lock out many useful parts.
The parts I like is that the support for devices is enormous, even if the code is not as tight as Paul has written, it works.

That said, there would be nothing preventing Paul from using CMSIS, and replacing the driver bits with his code instead.
CMSIS is actually designed in such a way that it provides an API for it.
The biggest problem that I currently have seen is getting the CMSIS part headers and drivers from Freescale.
Unlike Atmel, which publishes publicly and updates them. getting the same from Freescale is like pulling teeth from a chicken.
 
My long-term plan for CMSIS could be best described as "wait and see". If people need CMSIS for stuff, I may add support. In at least some sense, I've already done this for CMSIS-DSP. The arm-math.h header is in the core library, so you can #include it, and the library is linked, so you can indeed use all the CMSIS stuff. The FFT and FIR filter in the audio library does.

But I'm certainly not going to redo all the low-level I/O stuff which already works very well, and far more efficiently than Arduino Due's CMSIS-based approach, simply for the sake of using CMSIS. I really couldn't possibly care less whether ARM calls it a standard and whether Arduino is using it underneath their core library functions.

I will only add CMSIS support as it's actually needed for real projects people need to do, and as it provides real benefits for people doing real projects with Teensy.
 
My long-term plan for CMSIS could be best described as "wait and see". If people need CMSIS for stuff, I may add support. In at least some sense, I've already done this for CMSIS-DSP. The arm-math.h header is in the core library, so you can #include it, and the library is linked, so you can indeed use all the CMSIS stuff. The FFT and FIR filter in the audio library does.

The idea is that CMSIS would allow more code cross-pollination. I believe that would be ARMs compelling argument for using it.

But I'm certainly not going to redo all the low-level I/O stuff which already works very well, and far more efficiently than Arduino Due's CMSIS-based approach, simply for the sake of using CMSIS. I really couldn't possibly care less whether ARM calls it a standard and whether Arduino is using it underneath their core library functions.
That's the cool part. You don't have to redo them. You use both and/or replace with yours.
All it really requires is some code reorganizations as to where you place them in the tree, and possibly a little bit of code refactoring for anything that would conflict in namespaces. Looking at the Teensy arm core briefly, I don't see any collisions.

I will only add CMSIS support as it's actually needed for real projects people need to do, and as it provides real benefits for people doing real projects with Teensy.

I'd argue here that it may be an advantage to use a mix-- Your excellent code interfaced as an CMSIS 'board'.
This would allow you to keep all that you want, and have worked so hard to develop and tweak, and to use what is provided in Arduino >= 1.5.
Looking at the 1.6 layout, and provided tools, you could eliminate your own arm compiler, newlib, and use the Arduino provided ones.
Any ARM Teensy specific/optimized drivers would go into the ARM teensy library variant directories.

The one bit that I actually totally love about the CMSIS part is that driver components, if not required, won't get included into your binary.
This is an actual gain when you think about it.
For example, if you are not using USB, then you eliminate all the code for it; the current code doesn't do that.
Not only will you save on flash space, but that section of the chip does not get powered up, which saves on battery.
I'll actually be needing to do this in a project that I plan on having completed shortly, which is ran on a Lion battery and recharged by solar.
It will be recording and logging environmental data to SD card, and has to be as low power as possible in order to be able to recharge the battery, and to survive continuous operating at night.
The more sections I can power down on the chip, the better the chances I have at making this cost less -- Smaller battery, smaller solar cells.
 
No amount of theoretic or abstract rhetoric will get me to support CMSIS. Well, not unless it's backed up with an incredible amount of cash.....

I've already integrated CMSIS-DSP, because people wanted to use its functions for real projects. That's the model I intend to follow for future consideration of anything CMSIS.

If you want to avoid all power consumption associated with the USB, just comment out the one line that calls the USB init functon, and of course avoid using any communication that would access the USB.

Eventually, I'm going to integrate many more low power features, more integrated with the Arduino functionality. But that work will (probably) come after releasing 2 more products and probably another good round of audio library development. In the meantime, Duff's library has lots of good resources.

I'm not opposed to CMSIS when there's a compelling need, but I am opposed to CMSIS only for the sake of CMSIS.
 
Good to know that lower power is on the horizon.

I also agree with your opposition to including CMSIS for the sake of CMSIS.
I'm thinking it just may make the transition to 1.6 (and beyond) easier on your behalf.
I'm also a huge fan of code reuse where it makes sense.
In other words, taking the best of everything available, and combining it to end up with something that is simply the best overall, with the least amount of effort and time.

I suppose also there is nothing preventing anyone from placing something on github offers everything for those who would want to take a look and see what that would look like.
Would you be opposed to this?
 
I'll make a case that today's ARM open source from the vendors is the choice for industrial/professional applications. Especially where there is an OEM board design rather than a generic Arduino-pinned board. A few chip vendors have spent $$$ on all this, with a big staff.
This suite of tools would intimidate most avocational / recreational users.

Not suggesting that it's an alternative for those that want a bridge like Teensyduino to go from 8 bit to 32 bit ARM.

I've been working with CMSIS and the more important ARM Cortex M4 vendor's I/O driver libraries and a system generator tool. I'm so far very impressed with this lot, combined with an SWD debugger.

For each of the MCU family variants and each MCU's on-chip peripherals for (e.g., UARTs, SPIs, ADCs, DACs, timers, I2C, NAND flash parallel interface w/DMA, FATFS, etc.) there are ready to use drivers with your choice of polling, interrupts or DMA. Well done. I'd say that 2-3 years ago, the spartan CMSIS was not enough. But now, with CMSIS from ARM combined with the libraries listed above (vendor-specific), it's a desirable situation.
This may well exist from Freescale too although I elected the other route and am about 3 months into this and still pleased. Even as I began with a $30 M4 small form factor COTS board with 1MB flash and 200K RAM.

But again, there are two worlds here - and Paul's continued Teensyduino work is the unquestionably the best for the casual user/student and certain other situations.
 
Last edited:
I bought teensy 3.0 and 3.1 mainly to develop on.
My largest complaint with freescale tools is that on Linux, they only support redhat/debian offshoots and 64bit for the latest. I don't use either.
Besides, Paul's stuff just works, and his tech support is second to none.

That said, I've managed to extract the CMSIS parts from the latest kit they provide, and I'm actually starting to retro-fit this into Arduino 1.6.0...
My goals are:
  • Support Paul's boards. (of course!)
  • To be able to use my own boards, which are using a different freescale mcu from the same K20 series.

An advantage for me is that I won't have to hack tensyduino code anymore to support my boards, and at the same time I can use the teensy 3.1 to develop on.
The teensy++2 worked out fantastically for this, so it made sense to avoid the usual Arduino boards for ARM, which have various quirks too.
To this day I still use the Teensy++ 2.0 for initial development instead of Arduino's AVR offerings.
 
In my efforts, CMSIS per se is a small part as compared to the I/O libraries from the chip vendor. These are unique to the peripheral devices on the MCU whereas CMSIS is generic to all ARMs and focused on things like DSP rather that I/O drivers.
So, "CMSIS" is a bit player.
 
In my efforts, CMSIS per se is a small part as compared to the I/O libraries from the chip vendor. These are unique to the peripheral devices on the MCU whereas CMSIS is generic to all ARMs and focused on things like DSP rather that I/O drivers.
So, "CMSIS" is a bit player.

Exactly my point. Paul can still use his excellent driver code.
I'm also noticing that the freescale CMSIS support is very lacking in some of the driver departments and MCU support too. This is where Paul's code comes into play.
For example, Freescale doesn't seem to provide USB in CMSIS. This is fine, since Paul already has something that works fantastic.
All that really would need to happen is CMSIS to Teensyduino bindings.
 
For my work, CMSIS isn't really needed. It's the I/O drivers with interrupts and DMA already working, and with NVIC management across all peripherals, and so on. Plus things like code that automatically adjusts clock dividers for peripherals when you change the master clock for power conservation. Lots of nice built-in stuff.
 
What freescale toolset are you using? The free one they provide via SOMNIUM? Keil? Rowley?
 
In any case, Freescale has omitted some chips. This is bad. Worse the CMSIS structure they use is a bit odd... still compatible though.
I checked out Rowley Crossworks versions of these, and... All I have to say is that it is a mess, and lacks even more chip defs.

I can see why Paul has been reluctant to use it. I believe I can roll the missing definitions myself, and move it to the latest API.
 
Well, I have only acquired theTeensy 3.1 because it uses an Arm Cortex M4 and because Wolframs SystemModeler supports it and its Firmata library available for it. I can understand Paul whose "baby" is the "teensy" and its software. But looking to it from a broader view, I want to apply the "Design by Modelling" methodology and do plan to use Mathematica and SystemModeler for some systems I do design. Firmata is a pretty limiting protocol due to its limitations that arise from its background coming from MIDI. If I have understood it properly Firmata basically implements the equivalent to the Layer 6 of the OSI communication model by making it possible to relate physical elements to elements in the SystemModeler. CMSIS in its files and as a result in the API makes a common API to equivalent elements and peripherals of any implementation of the ARM Cortex Mx license by any manufacturer. So by parsing the proper files of a specific instance of CMSIS for a specific instance of a ARM Cortex Mx Controller a piece of software could generate what Firmata does today for relating HW to SystemModeler.

I want to add a strong argument for CMSIS and consequently to the ARM Cortex Mx. As software developers that build their software using the API provided by CMSIS can compared to other means relatively easily switch to another supplier of Cortex M controllers and/or to another ARM Cortex Mx device. Further as all licensees of ARM Cortex Mx make very similar devices in terms of the API required to use them suppliers/manufacturers/designers have to put heavy effort into winning customers for their specific implementation of a device.

That pressure due to the competitive situation has a lot of benefits we all benefit from:

1. Suppliers need to make it easy to potential clients to select their offering!

This has led to free IDEs, cheap and smart development and evaluation kits, so the entry ticket is so low, that it does not represent a barrier!

2. Suppliers need to configure their devices in the most effective way to be used in target applications!

The combination of the ARM Cortex Mx functions and the set of peripherals has to be implemented in a way compelling to potential clients!

3. Investment in efficient compelling hardware design of ARM Cortex Mx instances for specific target markets demands an efficient library CMSIS implementation not to waste the effort invested in a smart design of the hardware by loosing the benefits due to poor software implementation of CMSIS library elements.

4. Make sure there is at least one IDE that generates most efficient software possible so that both the efforts invested in hardware and CMSIS library are integrated in a most efficient possible executable of the software. I like to mention NXP who purchased "Code Red" to have full control of the IDE and as a result the efficiency of the executables generated.

This competitive situation helps us users of ARM Cortex mx controllers by representing a moving target were suppliers are forced to continuously invest in making available for their instances of ARM Cortex mx controllers the best possible environment! It further keeps prices of the devices low, prices for Eval and Dev boards low and powerful IDEs for free! So investing in any software to use the CMSIS API defined by ARM for their ARM Cortex Mx controllers ensures that a code will benefit from the efforts of the supplier to continuously improve the quality of their drivers, of their IDEs and their offering of ARM Cortex Mx devices!

For a software developer and even an aficionado the use of CMSIS is a relatively easy thing if he chooses the proper sources of information from the ARM Cortex Mx ecosystem! lets take i.e. the NXP offering reflected in cheap LPCXpresso boards of which I use the LPCXpresso1769 with an ARM Cortex M3. When I start the IDE from NXP, for free up to 256kBytes of code with an LPCXpresso board the IDE recognizes the LPCXpresso board type and version and configures itself properly. For each peripheral on the ARM Cortex Mx controller you find an example how that particular peripheral is used. So combining code from those examples y can start from an example that works and add my proprietary code! What can be easier.

If Paul loves his software babies, I do understand him! If he tries to enforce to use his babies I will follow as long as I must! If Paul, opposed to reinventing the wheel puts his expertise and genius into improving library elements of CMSIS, he would only have to focus on where his genius leads to the best benefit and his efforts to the most efficient use! I repeat, being Pauls babies, we all who are parents love our babies and consider them superior to any other. If we are smart professionals we know that different from human babies, software babies are subdued to the real life competitivity and the total cost of ownership plays a key role the smarter our clients are! So I will follow Paul as long as total ownership cost and benefits make it required and justifiable!

By the way, I know Freescale as for nearly 10 years i worked for Motorola Semiconductor, I did know National Semiconductor, now acquired by TI. I know that industry! Motorola once used to be a leading supplier of SmartCards and and a large german electronic giant, its former semiconductor branch that recently acquired IR, asked me to contact the right people at Motorola for a cooperation! The response i got from the was. S... who? no joke less than half a year later those same people within Motorola contacted me to initialize a cooperation with this company. The response I got was: Motorola who? Another example happened at national Semiconductor who developed and sold the very first 32 bit Processor architecture, NS32000. One day in Santa Clara, CA, came 2 individuals to express they would be interested to use National Semiconductor CPU. They were asked how many CPU they would purchase and their response was that not them, but those that would use their board to drive Laser Printers would! So they denied to support those individuals which led to the MC68000 to become the processor of choice for all postscript laser printers! Both stories exemplify one think! Arrogance is the killer of the good!
 
Status
Not open for further replies.
Back
Top