Official announcement on ST.com

Information on the latest releases
User avatar
RogerClark
Posts: 5466
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Official announcement on ST.com

Postby RogerClark » Fri Feb 03, 2017 10:28 am

Frederic @ ST has just emailed me to say that their core has now been publicly announced on ST's community site

https://community.st.com/community/stm3 ... rduino-ide

User avatar
BennehBoy
Posts: 386
Joined: Thu Jan 05, 2017 8:21 pm
Location: Yorkshire
Contact:

Re: Official announcement on ST.com

Postby BennehBoy » Fri Feb 03, 2017 10:49 am

Cool.

I might have to do some playing about with that core too, I must say that coming into this cold from Arduino land has been a little bit of a struggle - so I might volunteer myself to create some 'idiot proof' (referring to myself!) guides to get going with the maple & ST cores - although I only have maple mini's to test with.

I'm still not sure what Cube MX & HAL MX are?
-------------------------------------
https://github.com/BennehBoy

User avatar
leavesw
Posts: 19
Joined: Fri Jun 24, 2016 2:25 am

Re: Official announcement on ST.com

Postby leavesw » Fri Feb 03, 2017 4:47 pm

Still not convinced if the HAL driver is the direction to go - personally, I found there are a lot of overhead in the HAL drivers - and it is not necessarily a unified layer across all series (which means library for any series needs to be separately maintained). I can understand that it is definitely the way ST wants (as they are promoting their HAL and Cube MX libraries).

I am wondering what is the community's vision about the libraries - as there are multiple threads discussing about it on the forum - and I am under the impression that "it is a can of worms".

Moreover, I did not find the bootloader code on the github - I am not sure whether they are using DfuSe as ST's extension in the ROM or the standard DFU bootloader.

User avatar
RogerClark
Posts: 5466
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Re: Official announcement on ST.com

Postby RogerClark » Fri Feb 03, 2017 8:06 pm

The ST core will be good for anyone who wants to use the HAL functions.

IMHO, Currently the ST core is really still in development and will take time to mature.

User avatar
sheepdoll
Posts: 216
Joined: Fri May 22, 2015 12:58 am
Location: Silicon Valley Vortex
Contact:

Re: Official announcement on ST.com

Postby sheepdoll » Fri Feb 03, 2017 8:32 pm

Still no direct support for the STM32F4.

As I and others noted in the architecture thread, Using Cube and HAL seems to work better with a debugging IDE such as eclipse. One can still use the Arduino libraries, with more selectivity as to what gets built and compiled.

I do think, for the arduino IDE, that Cube needs to generate the sketch (.ino) directly and configure the whole core and include the needed libraries on the fly. Where it really gets messy (like loam fresh full of worms.) Is when one has more than one development board that crosses a number of Architectures. The net result is a lot of duplicated support code. Not to mention a tangled tree of file folders and include paths.

I have mentioned elsewhere that the Arduino core is so closely tied to bit banging the AVR peripheral registers, that much of the code becomes an AVR I/O emulator. The short of this is that the libraries need then to be created from scratch for each sub variant depending on the footprint of the device.

The Cube tool does it's best to handle the footprint differences. HAL is designed for configuring the template boilerplate code. Neither really works well to open the system up to configuring the system the way an Arduino user expects. So the net result is to enable every possible I/O stream is included. Just in case the user wants to call begin() on the function.

danieleff
Posts: 105
Joined: Thu Sep 01, 2016 8:52 pm
Location: Hungary
Contact:

Re: Official announcement on ST.com

Postby danieleff » Sat Feb 04, 2017 6:51 am

leavesw wrote:Still not convinced if the HAL driver is the direction to go - personally, I found there are a lot of overhead in the HAL drivers - and it is not necessarily a unified layer across all series (which means library for any series needs to be separately maintained).
sheepdoll wrote:Where it really gets messy (like loam fresh full of worms.) Is when one has more than one development board that crosses a number of Architectures. The net result is a lot of duplicated support code. Not to mention a tangled tree of file folders and include paths.

The short of this is that the libraries need then to be created from scratch for each sub variant depending on the footprint of the device.

Could you explain why you think HAL is not unified, and it needs lot of duplicated support code?
For example the following code compiles on all series from F0 to L7, and is the heart of setting up pins, peripherals, sending some data:

Code: Select all

__HAL_RCC_GPIOC_CLK_ENABLE();

GPIO_InitTypeDef GPIO_InitStruct;
GPIO_InitStruct.Pin = GPIO_PIN_13;
GPIO_InitStruct.Mode = GPIO_MODE_OUTPUT_PP;
GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_HIGH;
HAL_GPIO_Init(GPIOC, &GPIO_InitStruct);

HAL_GPIO_WritePin(GPIOC, GPIO_PIN_13, GPIO_PIN_SET);
HAL_Delay(1000);


SPI_HandleTypeDef hspi = {0};
hspi.Instance = SPI1;
hspi.Init.Mode = SPI_MODE_MASTER;
hspi.Init.Direction = SPI_DIRECTION_2LINES;
hspi.Init.DataSize = SPI_DATASIZE_8BIT;
hspi.Init.CLKPolarity = SPI_POLARITY_LOW;
hspi.Init.CLKPhase = SPI_PHASE_1EDGE;
hspi.Init.NSS = SPI_NSS_SOFT;
hspi.Init.BaudRatePrescaler = SPI_BAUDRATEPRESCALER_2;

uint8_t out[1];
uint8_t in[1];
HAL_SPI_Init(&hspi);
__HAL_RCC_SPI1_CLK_ENABLE();

HAL_SPI_TransmitReceive(&hspi1, out, in, 1, 1000);


UART_HandleTypeDef huart;
huart.Instance = USART1;
huart.Init.BaudRate = 115200;
huart.Init.WordLength = UART_WORDLENGTH_8B;
huart.Init.StopBits = UART_STOPBITS_1;
huart.Init.Parity = UART_PARITY_NONE;
huart.Init.Mode = UART_MODE_TX_RX;
huart.Init.HwFlowCtl = UART_HWCONTROL_NONE;
huart.Init.OverSampling = UART_OVERSAMPLING_16;
HAL_UART_Init(&huart1);
__HAL_RCC_USART1_CLK_DISABLE();

HAL_UART_Transmit(&huart, out, 1, 1000);

The difference is you #include stm32l0xx_hal.h instead of stm32f3xx_hal.h etc...

I have no idea why wi6labs decided to copy to different repositories for the different series, when the code is mostly the same.
I know there are some differences between the xxxTypeDef-s (biggest is I think 2 ways to setup I2C on different series), but it hardly justifies that "libraries need then to be created from scratch for each sub variant ".

Will it create the smallest, fastest, lowest power consumption code? No.
But it could be the one with "will it run on my ST board too"? Yes.
The critical sections can be optimized to use CMSIS anyway...

User avatar
leavesw
Posts: 19
Joined: Fri Jun 24, 2016 2:25 am

Re: Official announcement on ST.com

Postby leavesw » Sun Feb 05, 2017 7:31 pm

Well - IMHO, I do not think any library can actually provide a unified interface across all series due to the difference in the hardware and their use cases.

As I am working on F3 and L0 series, the clock configuration is totally different and the routine to configure them is different due to their different use cases (one you do not care too much about power, but the other you pay attention to power management a lot). Their Flash interface differs a lot and different erase/program sequence is needed. With my experience in the recent projects I have finished, I found that understanding the functionality in register level is inevitable - and much easier to debug if your codes are talking to register directly - and HAL library will create another software layer to learn (whose implementation differs between chip series) and hard to track down if anything goes wrong. In the case of Arduino library, if anything goes wrong, it means you have two layers of software APIs to learn before you reach the actual registers.

I do agree that the HAL library does provide a good starting point for a standalone project, but for serving as a backbone of a library - I am not yet convinced.

ag123
Posts: 66
Joined: Thu Jul 21, 2016 4:24 pm

Re: Official announcement on ST.com

Postby ag123 » Sun Feb 12, 2017 4:16 am

this is very cool news :D


Return to “Builds and Announcements”

Who is online

Users browsing this forum: No registered users and 2 guests