Does it belongs to STM32F070RBT?

[Md Mubdiul Hasan]

Posted on December 21, 2016 at 09:16

Dear Sir,

Can you tell me HAL_MspInit(void) function belongs to which STM device ?

Doesnt  it belongs to

stm32f7xx?

I have srearch in this document, but didnt find

UM1785 User manual

Description of STM32F0xx HAL and Low-layer drivers

?

[AvaTar]

Posted on December 21, 2016 at 09:58

Doesnt  it belongs to

stm32f7xx?

No.

It is shown as an element of

stm32f0xx_hal_msp.c

, thus is a function implemented in this file.

Those tree elements are basically Eclipse -standard, and look alike in most Eclipse-based IDEs.

Perhaps your question contains a spelling mistake, and you meant

stm32f

0

7x. In this case, the answer would be yes.

ST had been pretty consistent in this naming.

stm32fxxx

would include all F devices,

stm32f0xx

all F0 devices (e.g. F03x, F05x, F07x, ...) and

stm32f07x

all F07 family devices.

The STM32F7 is a quite different animal ...

[Md Mubdiul Hasan]

Posted on December 21, 2016 at 10:11

Dear Sir Avartar,

Nice to get you here again!

Thank you to clear my confusion.

Dont you think, I can use that mentioned manual.

Perhaps your question contains a spelling mistake, and you meant stm32f07x.

While searching in online, I got to know most of the people use 

stm32f7xx

Take a look in this link, 

http://www.tjaekel.com/eth/doxygen/group___s_p_i___exported___functions___group1.html

 

Again I am on a mad question, perhaps for my ignorance, )for your kind information I have stared using Ecilipse, gave up co-coox and mdk-keil, using just state, utility files)

Dont you think, something wrong in cubemx?

[AvaTar]

Posted on December 21, 2016 at 13:07

Dont you think, something wrong in cubemx?

I think not - at least not in this regard ... 😉

As mentioned earlier, Eclipse uses two 'tools':

• the compiler/linker to actually build the application
• the parser to 'assist' during editing

I know this yellow hints in your picture all-too-well. This is the parser who cannot (for what reason soever) find/resolve all includes. If it builds, there is no real issue with the code.

Please don't ask me how to get that parser thing right ...

I just like to postulate that the parser sometimes fails on #includes embraced with #if / #endif, or includes depending on #defines.

[Md Mubdiul Hasan]

Posted on December 22, 2016 at 01:47

I think not - at least not in this regard ... 😉

Its confusing, if your selected peripheral from stm32cubemx would absent or exists on  main.c ( if we do intentionally)  somehow  it could make  such error.

Forsure , things should not be exists twice.

This is the parser who cannot (for what reason soever) find/resolve all includes. If it builds, there is no real issue with the code.

Do you mean considering parser is less important as priority should be given in 

compiler/linker?

Please don't ask me how to get that parser thing right ..

.Lets avoid it as long as anybody could explain.

[AvaTar]

Posted on December 22, 2016 at 08:02

Do you mean considering parser is less important as priority should be given in 

compiler/linker?

It would be great if it worked. I searched once for a remedy (on a proprietary, Eclipse/GCC based toolchain) and found nothing - at least not in an acceptable time frame. Thus I learned to ignore it.

Perhaps someone can tell you how to do it - not me.

I'm not even sure if an Eclipse-specific forum would be helpful ...

[Md Mubdiul Hasan]

Posted on December 22, 2016 at 08:24

I'm not even sure if an Eclipse-specific forum would be helpful ..

Yes, that forum is often keep silence!