Hi friends, I am new to cortex-m3 world. I am working on luminary micro lm3s6965. They have given two "programming model" options to start, 1. Direct register access model Efficient but time consuming 2. Software driver model (API based driverlib) Rapid development but inefficient Another option is CMSIS. But the problem is driverlib & CMSIS are not compatible. So I am bit confused, Is driverlib really inefficient to avoid it?? Should I try creating "own" driverlib compatible with CMSIS?? Regards, Kishore.
Luminary micro "driverlib" Vs CMSIS
Started by ●May 19, 2010
Reply by ●May 19, 20102010-05-19
kishor <kiishor@gmail.com> wrote:> Another option is CMSIS. But the problem is driverlib & CMSIS are not > compatible.CMSIS is a bit of a joke in my opinion. It provides some abstraction for the Cortex-M3 core peripherals (mainly the interrupt controller) and standardises some compiler intrinsics names. These may be useful if you want to write code that is portable across different vendors' MCUs and compilers, but so far CMSIS covers a marginal amount of the whole MCU functionality. The grand plan is supposedly to provide standardised peripheral drivers, but as far as I'm aware so far only one has been produced (a single port serial driver), but even that was promptly removed from the next release.> Is driverlib really inefficient to avoid it??It is supplied in source form, so it's easy enough to judge this for yourself. Using it is obviously going to be slower than directly banging the hardware registers yourself, but I don't think it's too terrible. Now ST's FWLib on the other hand is atrociously slow. ST also seems to be the only ones really supporting CMSIS at the moment. Luminary wrote their driverlib long before CMSIS came about, which may explain why they're so reluctant to make them compatible. -a
Reply by ●May 19, 20102010-05-19
On 19/05/2010 13:38, kishor wrote:> Hi friends, > I am new to cortex-m3 world. > I am working on luminary micro lm3s6965. > > They have given two "programming model" options to start, > 1. Direct register access model > Efficient but time consuming > 2. Software driver model (API based driverlib) > Rapid development but inefficient > > Another option is CMSIS. But the problem is driverlib& CMSIS are not > compatible. > > So I am bit confused, > Is driverlib really inefficient to avoid it?? > Should I try creating "own" driverlib compatible with CMSIS?? > > Regards, > Kishore. > >Another thing to note is that for some of the Stellaris devices, driverlib is in the ROM. That means less code space is needed in flash (the speed should be the same).
Reply by ●May 19, 20102010-05-19
Op Wed, 19 May 2010 15:54:29 +0200 schreef David Brown <david@westcontrol.removethisbit.com>:> On 19/05/2010 13:38, kishor wrote: >> I am new to cortex-m3 world. >> I am working on luminary micro lm3s6965. >> >> They have given two "programming model" options to start, >> 1. Direct register access model >> Efficient but time consuming >> 2. Software driver model (API based driverlib) >> Rapid development but inefficient >> > Another thing to note is that for some of the Stellaris devices, > driverlib is in the ROM. That means less code space is needed in flash > (the speed should be the same).Likely to be slower, since the compiler didn't have the chance to optimize away the function call overhead. -- Gemaakt met Opera's revolutionaire e-mailprogramma: http://www.opera.com/mail/ (remove the obvious prefix to reply by mail)
Reply by ●May 19, 20102010-05-19
Boudewijn Dijkstra wrote:> Op Wed, 19 May 2010 15:54:29 +0200 schreef David Brown > <david@westcontrol.removethisbit.com>: >> On 19/05/2010 13:38, kishor wrote: >>> I am new to cortex-m3 world. >>> I am working on luminary micro lm3s6965. >>> >>> They have given two "programming model" options to start, >>> 1. Direct register access model >>> Efficient but time consuming >>> 2. Software driver model (API based driverlib) >>> Rapid development but inefficient >>> >> Another thing to note is that for some of the Stellaris devices, >> driverlib is in the ROM. That means less code space is needed in >> flash (the speed should be the same). > > Likely to be slower, since the compiler didn't have the chance to > optimize away the function call overhead. >It's a trade-off. If you are going to have function calls anyway, the rom versions are the same speed and are cheaper (in that rom is cheaper than flash). For maximum speed, you'd want the compiler to use the source code versions. With driverlib, you get both options.
Reply by ●May 21, 20102010-05-21
Hi friends, Thanks for reply. I have decided to Start with luminary's "driverlib". Meanwhile I will try to customize driverlib or make own drivers. The ST's library looks more structured & it is compatible with CMSIS also. Do anyone have studied other vendor's library (Codered, code sourcery, etc.) Thanks & Regards, Kishore.
Reply by ●May 21, 20102010-05-21
Hi friends, Thanks for reply. I have decided to Start with luminary's "driverlib". Meanwhile I will try to customize driverlib or make own drivers.> ST's FWLib on the other hand is atrociously slow. > > ST also seems to be the only ones really supporting CMSIS at the moment.The ST's library looks more structured than luminary & it is compatible with CMSIS also. Do anyone have studied other vendor's library (LPC, Atmel, energymicro, etc.) Thanks & Regards, Kishore.
