Register or Standard Peripheral Library

[we]

Posted on March 31, 2012 at 17:58

Hello,

I am new to

this forum

.

Is there anyone

who

does not use Standard Peripheral Library for programin STM32F4 ? I'm don't like SPL and 

and

programmed

using registers

for set the uC.

I greet

[frankmeyer9]

Posted on April 03, 2012 at 08:04

This is your decision alone. If you get your project working, it's fine.

Your probably have never been asked to port some nontrivial project to another controller, or worked on a project intended to support several controllers/families. These cases are the standard in commercial development, and you gain a lot with something like a standardized peripheral library.

[Tesla DeLorean]

Posted on April 03, 2012 at 15:23

On occasion it makes sense, but you're basically requiring yourself to completely understand the register minutia of the specific part you're using, and significantly better than the average user.

This will likely result in spending a lot of time debugging and chasing down issues, and producing code others will find impossible to maintain or port.

[Andrew Neil]

Posted on April 04, 2012 at 02:06

''I'm don't like SPL''

  Why, specifically, do you not like it?

[we]

Posted on April 04, 2012 at 16:55

In my opinion all information about uC are in RM. When I use SPL I must read RM, and SPL documentation, what isn't comfortable, and quickly.

For example :

<br>TIM
2
->ARR = 
4199
;<br>TIM
2
->PSC = 
0
;<br>TIM
2
->DIER = TIM_DIER_UIE;<br>TIM
2
->CR
2
= TIM_CR
2
_MMS_
1
;<br>TIM
2
->CR
1
= TIM_CR
1
_CEN;

SPL require structure initialization where we need know right the order. Function SPL have a lot of assert functions which is not optimal.

Of course it's my opinion so you so

you do not have

to agree

with me

. But I wanted to know your opinion.

[we]

Posted on April 04, 2012 at 16:58

In my opinion all information about uC are in RM. When I use SPL I must read RM, and SPL documentation, what isn't  comfortable,  and quickly.

For example use the only register:     TIM2->ARR = 4199;     TIM2->PSC = 0;     TIM2->DIER = TIM_DIER_UIE;     TIM2->CR2 = TIM_CR2_MMS_1;     TIM2->CR1 = TIM_CR1_CEN; SPL require structure initialization  where we need know right the order. Function SPL have a lot of assert functions  which is not optimal.

Of course it's my opinion so you so

you do not have

to agree

with me

. But I wanted to know your opinion.

[tony2399]

Posted on April 04, 2012 at 21:27

You can actually disable all the assertions in production code by defining NDEBUG in the preprocessor; they will then be referenced to (void*(0)) which most compilers will just optimize away.

Anyway, here's an interesting article by Dan Saks comparing various methods of writing memory-mapped peripheral interfaces:

http://www.eetimes.com/discussion/other/4231152/Judgment-calls

As he pointed out, it's certainly a judgement call; as long as it works well and performs efficiently in your environment, it's up to you.As an aside, I'm not a big fan of Saks' penchant for C++ 😉Tony

[Tesla DeLorean]

Posted on April 04, 2012 at 22:55

In my opinion all information about uC are in RM. When I use SPL I must read RM, and SPL documentation, what isn't  comfortable,  and quickly.

SPL require structure initialization  where we need know right the order. Function SPL have a lot of assert functions  which is not optimal. Of course it's my opinion so you so

you do not have

to agree

with me

. But I wanted to know your opinion. Well, I think a lot of the subtlety is not fully expressed in the reference manual, and using the libraries requires a lot less attention to the manuals and minutia than a purely register approach. As for ''knowing the right order'', poking the part at the register level requires a lot more specific attention to the right order. Some features/behaviours you'll no doubt spend a lot of time discovering. Much of the extraneous code in the library disappears with suitable compiler and preprocessor options, typically seen when compiling in ''Release'' vs ''Debug''. The library code also permits a mix-n-match approach,  so writing directly to registers can be achieved where it makes sense, ie TIM2->CRR1 = 1234; People will no doubt argue the relative merits, but you're not programming an 8051, and it's not 1980.