Prev: Maxim Security ICs - Alternatives?
Next: Barcode scanner reverse engineering
From: kishor on 19 May 2010 07:38
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.


From: Anders.Montonen on 19 May 2010 08:12
kishor <kiishor(a)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
From: David Brown on 19 May 2010 09:54
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).

From: Boudewijn Dijkstra on 19 May 2010 12:54
Op Wed, 19 May 2010 15:54:29 +0200 schreef David Brown
<david(a)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)
From: David Brown on 19 May 2010 15:21
Boudewijn Dijkstra wrote:
> Op Wed, 19 May 2010 15:54:29 +0200 schreef David Brown
> <david(a)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.
 |  Next  |  Last
Pages: 1 2
Prev: Maxim Security ICs - Alternatives?
Next: Barcode scanner reverse engineering