A bit of advice and CMSIS API document?

[rossarcher42]

Posted on August 13, 2015 at 00:58

Hi folks,

I've been drowning in mountains of non-useful documentation looking for something very simple:  an API document for CMSIS peripheral functions, written for the application developer (not ARM document detailing how a silicon vendor writes CMSIS).

For example, where is 

I2C_CheckEvent(), SPI_ReadWrite(), and other peripheral HAL stuff defined for (say) STM32F1xx?  I found a lot of related things, but not that.

Yes, I can read the source code and seek out examples.  But it would be nice, IF ST has bothered to document their API, to find the document where it's all defined. :)

I found this: https://www.keil.com/pack/doc/CMSIS/Driver/html/group__usb__interface__gr.html

but this seems to assume the presence of an RTOS that I don't presently want.

 

Thanks for any help with my stupid questions! :D

-- ross

#cmsis-stm32cube-hal #cmsis-api-stm32-stm32f103

[Amel NASRI]

Posted on August 13, 2015 at 10:29

Hi archer.ross.002,

Have a look to documents that you may find in

http://www.st.com/web/catalog/tools/FM147/CL1794/SC961/SS1743/LN1897/PF260820

. Check mainly UM1847 and UM1850.

-Mayla-

[rossarcher42]

Posted on August 13, 2015 at 17:44

Hello, Mayla,

Your links, while not exactly what I was seeking, are very helpful, especially the UM1850 document.

I wonder if some kind of document map, that's put clearly at the root of the tree, would help make the huge volume of documents easier to navigate.  At any rate, as usual it seems as if finding the specific information is harder than the coding itself. :)

Thanks again!

-- ross

[Tesla DeLorean]

Posted on August 13, 2015 at 18:05

Thank goodness for Google, I guess.

The older SPL had it's documentation in a Windows Help file format

STM32F10x_StdPeriph_Lib_V3.5.0\stm32f10x_stdperiph_lib_um.chm

With a lot of examples, and library source that's pretty well structured and commented.

The HAL/Cube stuff uses a thicker and more cumbersome paradigm.

[Amel NASRI]

Posted on August 14, 2015 at 12:19

Hi clive1,

Cube packages contain also CHM files.

For STM32CubeF1 for example, you find them under: STM32Cube_FW_F1_V1.1.0\Drivers\STM32F1xx_HAL_Driver.

-Mayla-

[rossarcher42]

Posted on August 15, 2015 at 23:36

This was exactly what I was looking for.  Thank you greatly!

Why on Earth would STM publish something this fundamental in a proprietary Windows format instead of a PDF or basic HTML? It seems odd, as if they believe developers would use only their tools and packages in only their imagined context.  Not sure this is anywhere near as helpful as an application note describing the components, some standard documentation in standard format(s), and a link to the package files in question. :)

From: clive1

Posted: Thursday, August 13, 2015 6:05 PM

Subject: A bit of advice and CMSIS API document?

Thank goodness for Google, I guess.

The older SPL had it's documentation in a Windows Help file format

STM32F10x_StdPeriph_Lib_V3.5.0\stm32f10x_stdperiph_lib_um.chm

With a lot of examples, and library source that's pretty well structured and commented.

The HAL/Cube stuff uses a thicker and more cumbersome paradigm.

[rossarcher42]

Posted on August 15, 2015 at 23:42

Also, the firmware in question uses some of these functions, and also bodge registers directly.  It's still active and will probably remain supported for a few more years.

My choice is whether to:

1. Leave as-is (mix of ''official'' CMSIS calls and lots of direct register reads/writes)

2. Convert register-bodging to ''official'' CMSIS functions so it's 100% official

3. Migrate to apparently newer HAL_ function paradigm.

A new product will replace this, and I'm inclined to use the HAL paradigm found in STM32Cube going forward?

[rossarcher42]

Posted on August 15, 2015 at 23:51

Hi Mayla,

I am glad to see this documentation exists.  One question though:  why would a search for ''STM32 CMSIS (or HAL) API'' fail to take one to a document somewhere on your website containing this information?  It seems as though this is fundamental information needed by a developer and shouldn't be hidden inside software, as helpful as it is to also have this information online within applications... just an observation for what it's worth.