Sonsivri
 
*
Welcome, Guest. Please login or register.
Did you miss your activation email?
December 29, 2024, 03:48:14 03:48


Login with username, password and session length


Pages: [1]
Print
Author Topic: CMSIS vs vendor libraries  (Read 6762 times)
0 Members and 1 Guest are viewing this topic.
dcsmrgun
Newbie
*
Offline Offline

Posts: 34

Thank You
-Given: 13
-Receive: 11


« on: November 19, 2012, 01:54:28 01:54 »

Anyone have any thoughts about using CMSIS over proprietary libraries for someone just starting out? StellarisWare is amazing, but I like the idea of not being tied to a particular vendor.

The downside is that there is very little community information about CMSIS and while the documentation is okay, there's nothing like a good support base.
Logged
mare69
Junior Member
**
Offline Offline

Posts: 89

Thank You
-Given: 50
-Receive: 85



WWW
« Reply #1 on: November 19, 2012, 07:19:28 07:19 »

The idea of CMSIS is "vendor independency". Examples on CMSIS should be more supported by Tool providers rather than IC vendors. I have experience with ST Standard Peripheral Library, but I gave up. There is allways some issue with the "latest version" and porting to one or another tool etc. It is harder to start with CMSIS, but it is good time investment.
Logged
dcsmrgun
Newbie
*
Offline Offline

Posts: 34

Thank You
-Given: 13
-Receive: 11


« Reply #2 on: November 19, 2012, 04:20:00 16:20 »

That's what I'm thinking as well. I really appreciate the vendor agnostic angle of doing it this way. It's a shame there is so little information on the subject. Seems like a great place for someone to make some money writing a book Tongue

So far I found a few lectures on Doulos' website, an ARM training partner, but it's still far removed from having an actual lab to practice in. Oh well, trial and error wins again!
Logged
bigtoy
Active Member
***
Offline Offline

Posts: 238

Thank You
-Given: 340
-Receive: 297


« Reply #3 on: November 20, 2012, 05:21:48 05:21 »

Trial & error has been my experience with CMSIS as well. It is nice to more easily port code between vendors ARM processors. It's worth the effort, the learning curve. Although I love Stellarisware, TI's ARM processors are now falling well short of almost everyone elses, so all our new designs are using non-TI processors, which means no more stellarisware for us. CMSIS is helpful for this.
Logged
dcsmrgun
Newbie
*
Offline Offline

Posts: 34

Thank You
-Given: 13
-Receive: 11


« Reply #4 on: November 21, 2012, 02:02:03 02:02 »

Anyone find any good info?

I think most of what I found is:

http://www.doulos.com/knowhow/arm/Embedded_C_programming_for_Cortex-M_processors/Resources/Presentation/
http://www.webseminare-data.de/rps/009/007/013/index.html

Also, I'm reading The Definitive Guide to the ARM Cortex-M3 which seems to have some CMSIS material in it, but I haven't gotten that far yet.

Logged
Sailor
Junior Member
**
Offline Offline

Posts: 54

Thank You
-Given: 143
-Receive: 57


« Reply #5 on: November 21, 2012, 11:56:08 11:56 »

Here are links to a couple of pages of a site that I landed on today.

http://www.emcu.it/STM32/STM32Library/TwoWordsConcerningSTM32Library.html
http://www.emcu.it/STM32F4xx/STM32F4-Library/STM32F4-Library.html
http://www.emcu.it/STM32.html#TUTORIAL_and_SW_examples

There seems to be some useful information scattered around the site, so it's probably worth a bit of time.
Logged
dcsmrgun
Newbie
*
Offline Offline

Posts: 34

Thank You
-Given: 13
-Receive: 11


« Reply #6 on: November 22, 2012, 04:11:55 04:11 »

Also as far as I can tell, if you download LCPXpresso from NXP, all their examples are just about straight CMSIS. If I'm wrong I apologize, I just started digging into there, but it looks pretty bare bones CMSIS to me.
Logged
dcsmrgun
Newbie
*
Offline Offline

Posts: 34

Thank You
-Given: 13
-Receive: 11


« Reply #7 on: December 11, 2012, 04:46:48 04:46 »

Honestly, after a few weeks of pounding on a few dev boards I can say that CMSIS isn't a big deal. It's not a do-all library for generic cortex development. It's a library that encompasses the very fundamental parts of the Cortex that are common across all the processors like the NVIC, SysTick timer, etc. After that though, all the peripherals are still different for each vendor.

There is nothing to guarantee that the GPIO registers are at the same memory address on an NXP chip vs a Texas Instruments chip, and even if they were there's no guarantee that the registers will be the same so you can't just write generic code that will target all processors.

The best solution so far seems to be to just get as low to the registers as you can. If you write low level enough code then porting your code from one uC to another will be a matter of leaving the logic the same and switching out registers and addresses. That's probably as close to vendor independence as we'll get any time soon.

I will still avoid using any vendor specific libraries. It's easy enough to port code when all you need to do is swap out register names and values. Once you abstract that into driver libs then you've got to modify a lot more code (in my opinion anyway).

So if anyone is looking to get started coding for an ARM Cortex processor, honestly right now the best thing I can point you at is a good set of AVR programming tutorials available at http://newbiehack.com/ -- they are AVR specific but the code is generally presented at a low enough level that the concepts will easily transfer over to ARM development. There are differences in how you work with interrupts and the port assignments are different, but for the most part the code and ideas behind the code port over very easily. Even for someone like me who has precious little prior experience with ARM-C.
Logged
miserable
Newbie
*
Offline Offline

Posts: 15

Thank You
-Given: 11
-Receive: 17


« Reply #8 on: February 04, 2013, 01:24:27 13:24 »

Hi All,

I am trying to vendor independent and CMSIS compliant code for ARM. But it seem very difficult for some reasons.

NXP or Atmel have published HW isolation functions for CMSIS. For example;

void GPIO_SetDir(uint8_t portNum, uint32_t bitValue, uint8_t dir)    NXP
uint8_t PIO_Configure(const Pin *list, uint32_t size)                          Atmel

As you can see function names and parameters are different. It is impossible to port a code from one vendor to another without modification. Because peripheral registers and their capabilities differs from vendor to vendor. Also their coding approahs are different.

If all vender had a functions like below
GPIO_SetDir(0, 0xFFFFFFFF, 0);    

it will be possible to vendor agnostic coding. But after a couple of days of strugling, I decide to use
CMCSIS register definition standard, but not relavant functions.

So using
LPC_GPIO0->FIODIR = 0x00000000;   is not portable

but more feasible than using
GPIO_SetDir(0, 0xFFFFFFFF, 0);    

I have loked for the CMSIS documentation if there are some explanations about the function definitions for peripherals but could not find. I think they did not find a proper way for standartization. I thing TI just published just CMSIS style register definitions but not driver functions for HW isolation for that reason.

Best regards.
Logged
dcsmrgun
Newbie
*
Offline Offline

Posts: 34

Thank You
-Given: 13
-Receive: 11


« Reply #9 on: February 04, 2013, 01:36:18 13:36 »

After a little bit of work with ARM I pretty much found that there is no way to be completely vendor independent. Like I said before, even if there were a way to standardize the address that GPIO0->FIODIR is found at, there is no guarantee that the bits will perform the same function.

Since I've been developing on two uCs, an LPC and a TI Stellaris, I found that the easiest way for me to handle this is to just write my own abstraction layer or not worry about vendor independence. I can write my own GPIO_SetDir function and #define which CPU I'm using to specify the proper address and bits for GPIO0 for example. It's a little more work, but sadly that's the state of things.

ARM made no effort to standardize peripheral access, sadly.

I'm still against using vendor libraries, but unfortunately even direct register access is different for each uC you plan to use :/
Logged
dcsmrgun
Newbie
*
Offline Offline

Posts: 34

Thank You
-Given: 13
-Receive: 11


« Reply #10 on: February 14, 2013, 11:11:46 11:11 »

This interesting project just poppped up on my horizon:

http://www.libopencm3.org/wiki/Main_Page

Looks like an attempt to create a library to address different uCs, but I'm currently too busy to do any real research about how well it works.
Logged
Pages: [1]
Print
Jump to:  


DISCLAIMER
WE DONT HOST ANY ILLEGAL FILES ON THE SERVER
USE CONTACT US TO REPORT ILLEGAL FILES
ADMINISTRATORS CANNOT BE HELD RESPONSIBLE FOR USERS POSTS AND LINKS

... Copyright © 2003-2999 Sonsivri.to ...
Powered by SMF 1.1.18 | SMF © 2006-2009, Simple Machines LLC | HarzeM Dilber MC