Official announcement on ST.com

Information on the latest releases
User avatar
RogerClark
Posts: 5470
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: 404
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: 20
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: 5470
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: 224
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: 129
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: 20
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: 298
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

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

Re: Official announcement on ST.com

Postby ag123 » Wed Apr 05, 2017 9:31 pm

this thread is a little dated even as of today, as STM 'official' duino has released an F4 build
viewtopic.php?f=48&t=1943

however, given the memory hog (viewtopic.php?f=48&t=1564) issue,
pin mapping e.g. STM 'official' core seem nucleo based & left bluepill, etc in the cold (i'm not sure if it is fixed as of this post) (viewtopic.php?f=49&t=1639)
issues et.al.

my personal 2cents is that ultimately, there may be divergent 'cores'. this isn't really a bad thing imho
a 'hal' based core would be 'tidier' & as mentioned by daniel, codes written for F1 may 'just work' without recoding on various other cores e.g. from F0 - L7, while then for the 'enthusiast' who needs every byte of ram and flash on the blue pill & wants to overclock that, a 'lean and mean' highly optimised 'core' for F103 may be preferred
and that's not all there could be n number of 'flavours' (with / without 'toppings'), hence we'd probably see and is probably a good thing to have multiple 'cores' (implementations) of stm32duino, this is similar to linux 'distributions' in which there are many linux distributions out there today

arduino, especially stm32duino has created a new ecosystem that adds to the already large 'iot' landscape
it is no longer the humble 'old' arduino led blinky

'unofficial' stm32duino f103xx (e.g. blue pill) comes 'full powered' with adc, tft displays, sd card 'file systems', touch screen, rotary encoders, usb interface to pc (and with serial commands) and a 'gui' & we are trying to do a 1 msps oscilloscope, overclock, all that in blue pill stm32f103c8t6 20k sram 64k flash
viewtopic.php?f=19&t=107
oh and maybe as an 'add on' after that, play an mp3 file via i2s audio while displaying the scopes and maybe add fft for a dancing frequency display) - still 20k sram 64k flash
viewtopic.php?t=519
oh and may be if it gets too cramp in 1, do i2c multi-processing connecting 1024 blue pill together on the i2c bus
:lol:

aramperez
Posts: 9
Joined: Thu May 12, 2016 1:34 am

Re: Official announcement on ST.com

Postby aramperez » Fri Apr 14, 2017 11:22 pm

I have a Chinese MapleMini and was using the original STM32duino code. I tried this ST version but now there is no pinMode(xx, PWM) :( . Does anyone know the equivalent?

Thanks,
Aram


Return to “Builds and Announcements”

Who is online

Users browsing this forum: Bing [Bot] and 1 guest