I'm starting to think that in order to get what I need/want out the Due I'm going to need t dive into the CMSIS.
Am I correct in assuming that CMSIS is supported by the Ardiuno 1.5.6 IDE?
Also, does any one have suggestions for how to get started with some basic functions?
Thanks,
Bill
Isn't CMSIS just a heap of definitions for registers etc?
Rob
Rob,
I did a lot of research on it yesterday, and it seems that CMSIS is a heck of a lot more than that. CMSIS is actually a fully functional layer that sits on top of the registers etc. The idea with CMSIS is that there is a "simple" and standard interface that can be used to program any ARM Cortex M0-M4 mcu from any manufacture!
There is a whole lot of stuff in there! All kinds of cool math functions, DSP stuff, really cool ADC functions, etc. But I'm still pretty lost on how to work with it.
Also, the CMSIS functions appear to be available natively in the Arduino 1.5.6 IDE via gcc! For example, when you dig down into the libraries for the Due, the basic Arduino functions like analogRead() for example are appear to be implemented in CMSIS.
While I am able to hack together various bits and pieces by rummaging through the Arduino libraries and seeing how things are implemented, I'm still not able to figure out how to get access to functions that aren't actively used in the libraries... and there appear to be a lot of them, and they appear to be super cool.
I haven't even been able to find a reference that lists their names yet! Though there are plenty of documents outlining their structure, architecture, and coding style?
I'm still just groping around in the dark.
B
My impression is that CMSIS was designed to be a layer (API ?) for cortex, but it looks like not all chip makers follow this idea.
I've seen STM, and arduino alike Maple (STM32F103) project was completely build on CMSIS, but it isn't the case for Atmel.
He invented ASF, and I don't know where you find ADC implementation in CMSIS, but what I can see in my arduino installation, all hardware API calling to ASF, leaving to CMSIS just headers and registers definition, as already noted above.
http://asf.atmel.com/docs/latest/architecture.html
http://asf.atmel.com/docs/latest/sam3x/html/group__sam__drivers__adc__group.html
Good info, keep it coming as you learn more. Every once in a while I pick up an ARM datasheet and think I need to learn more. Haven't found the time/motivation to get serious yet though :~
My understanding is that CMSIS is a hardware abstraction layer for the Cortex-M series meant to provide a common interface to various vendor's chips. I'm not clear how successful it is, or to what extent various vendors comply with it.
I saw a question whether NXP had abandoned CMSIS, but they replied that their LPCOpen framework was CMSIS-compliant. With Atmel, I think that ASF comprises their effort for CMSIS compliance.
I've been looking a little at the Atmel SAM D series and also the NXP LPC800 series. NXP gets points for removing restrictions on the free version of their LPCXpresso IDE, namely C++ support is now included, and code size limitations eased or removed.
For me, one of the big selling points with Arduino is built-in or easily added common interfaces such as I2C, SPI, asynchronous serial, etc. I don't particularly care to reinvent those wheels for ARM but I'm hoping that CMSIS may be an answer.
I've done quite a lot of programming on LPCs (great chips and environment BTW) and I confess that I'm still not 100% sure how useful CMSIS is. Yes it's supposed to be an abstraction layer for the ARM, but how many people actually work with the ARM core? Answer, almost none.
Here is a snippet from my main() func
// Enable AHB clock for GPIO ports
LPC_SYSCON->SYSAHBCLKCTRL |= _BV(AHB_GPIO1) | _BV(AHB_GPIO0);
The definitions here are from an H file in the CMSIS folder, but this is very LPC specific, no way that code will run on a SAM or ST. So there is a small abstraction level there but not much and certainly not portable.
Here is some more setup code
LPC_SYSCON->SYSOSCCTRL = 0;
LPC_SYSCON->PDRUNCFG &= ~(1 << 5);
LPC_SYSCON->SYSOSCCTRL = 1;
This is obviously dealing with the ARM core which will be the same on all M0 chips, but the left values at least have an LPC_ prefix so once again this code won't work on another family, even is if all boils down to the same address, offsets and code.
And this is working directly with the M0 core, almost nobody does that except maybe a little setup code, most code is either generic C/C++ that will run anywhere or deals with the chip's peripherals which are totally different on all families.
So for the average user I see almost no benefit to CMSIS, they need a real HAL framework like the Arduino.
NXP gets points for removing restrictions on the free version of their LPCXpresso IDE, namely C++ support is now included, and code size limitations eased or removed.
Yes, I ported most of the Arduino core to LPC122x, but that was before they opened up the compiler and I had to do it all in C so things like Serial.begin() had to be SerialBegin() etc. I got it to the stage where you could run a simple Arduino sketch with very few changes to the code.
Now that C++ is free I've started porting the code to C++. I haven't got far with the conversion though because I have too many other things to do.
Rob
Graynomad:
I've done quite a lot of programming on LPCs (great chips and environment BTW) ...
Thanks, I was wondering about that. I can see a consistent HAL for the ARM core (i.e. the CPU) but as you say, peripherals are different from every vendor so I was wondering how well that could work.
I poked around a bit on arm.com and found the CMSIS "specification" which I downloaded. It has "drivers" for things like Ethernet, I2C, SPI, USART, USB, external memory, etc. At this point I don't have a clue how to use them or whether they can be used. Looks like it's just .h files so just defining the interface. Probably each vendor would have to implement code to the specs. Throw things like switch matrices into the mix and I can see it getting crazy enough that I'd prefer just to program down the the bare metal, ha!
Thanks guys.
That is all fascinating! So it sounds like I may have been barking up the wrong tree with the CMSIS in the first place.
It seems that there is a pretty wide difference between what the SAM chip is capable of and the functions that are easily available through the standard Arduino and other available libraries. What I am really after is a way to get access to those cool SAM capabilities.
Sounds like ASM is the way to go for that. Perhaps I ought to start a new thread asking about how to get started with ASM?
Thanks.
Bill
These days there's almost never a need for ASM, most (probably all) of the hardware is available to a C program and the code that does this will normally boil down to a single ASM instruction anyway.
There is sometimes a reason to delve into ASM if you really have to control the exact order of instructions etc, but it's been years since I've even thought about doing that, even with fast comms programming.
The last time I used ASM was for a monitor program that displayed all the CPU registers, program counter, stack pointer etc. and these days I doubt many people need a "monitor" program or indeed even know what one is 
Rob
Ahhh... yes.
I now realize that ASM is just assembly language. I believe the TLA (Three Letter Acronym) I meant to use was ASF... one letter makes all the difference ;).
I've found this reference for ASF which I'm hoping will be very helpful.
http://asf.atmel.com/docs/latest/index.html
Thanks for the input. I'll keep you all posted.
one letter makes all the difference
Sure does
Rob
first of all, apologies for bringing back zombie thread.
I too was excited to see the CMSIS DSP library and such. I've download Atollic TrueStudio and thought STM32 was the way to go. All i want is a cheap ARM (maybe Cortex M4) to do audio DSP stuff with.
Was I barking up the wrong tree too?
STM32 seems open, but arduino even more open. Can someone point me in the right direction? I want to do FFT and reverse FFT in real time for audio.
I'm just so overwhelmed and if someone familiar can point me in the right direction it'd make me a happy pepe.
Check out the Teensy 3 Audio Library for real-time digital audio effects and filters.