STM32WB – dualcore with 2.4GHz radio

Dualcore – M4 (apps cpu) and M0+ (network cpu) – with 2.4GHz multi-protocol connectivity and w/ a lot of low-power features:

http://www.st.com/en/microcontrollers/s … tId=SS1961

How much per unit and would it fit on the new “F405 & F411 versions of the BluePill” I wonder.

No unit price yet…..

Um~mmmmm…

If it is more than $8.25 then Espressif has the edge with their dual-Core + PSRAM

https://www.aliexpress.com/item/ESP32-W … 09094.html

I got an order in before Chinese New Year for a couple (2) mounted on the Wemos breakout evaluation board.

Opinion by Ray

think 1 day we’d have 4,8,16,64,1024 cores stm32 mcus, we’d be able to compete head on with fpgas with all that arm mcus
oh and much more important is that 2.4 ghz BLE capable radio, finally ST tries to live up to compete vs nrf51822 & esp32

ESP32 is quite fast but I don’t consider it very low-power.

This chip combines an STM32L4 (Cortex M4) with a Cortex-M0+ core, the M0+ handling the 2.4GHz radio and the L4 handling everything else. Even the L4 by itself is impressively low-power, so I expect this combination to be impressive. Can’t wait to get my hands on one…

when i take a closer look at the sku i noted something similar to TI’s CC2640
http://www.st.com/content/st_com/en/pro … b55cg.html

vs TI’s CC2640
http://www.ti.com/product/CC2640/description

basically i read it as ST is now getting serious about bluetooth LE and its integration with mcus
it sounds like we’re going to get an ‘abusive’ ‘explosive growth’ of everything bluetooth LE, mouse, keyboards, fitness trackers, smart watches, beacons, sensors, lights, drones, vending machines, 3d printers & all kinds of pc and mobile phones ‘accessories’ and i think all consumer electronics tvs, radios, clocks, u name it, internet of things become internet of everything

[aonsquared – Sun Feb 25, 2018 9:11 am] –
ESP32 is quite fast but I don’t consider it very low-power.
…

The RF section is the power hog. I do not have numbers (yet) on the ESP32, but the ESP8266 is a nominal uC when RF is turned off:
https://www.hackster.io/rayburne/esp826 … ime-1df8ae
At 80MHz, the no-RF ESP8266 NodeMCU requires less than 40mA.

I expect the same or better from the ESP32.

Ray

Found this in the ESP32 forums:
http://bbs.esp32.com/viewtopic.php?t=2662

i made some test to get an idea of power consumption of ESP32 (devkitC by Olimex). I tried different scenarios and i want to summarize the data in a sort of table:

VCC=5V
N. CORES ACTIVE: DEFAULT

SCENARIO—————————————–CPU80MHz————-CPU160MHz———–CPU240MHz
– CPU + ELECTRONICS + BT———————–113mA——————123mA—————–141mA
– CPU + ELECTRONICS——————————38mA——————- 51mA —————–73mA
– CPU (deep sleep) + ELECTRONICS————-3.5mA——————-3.5mA—————–3.5mA

It seems both cores in the ESP32 are the same type (up to 240MHz per core) which would increase power consumption.

The STM32WB has one M4 and one M0+, and the M0+ should be very efficient (at the price of performance). The M4 should consume about 10-20mA, the M0+ maybe half of that, leaving more current for the BLE radio.

ST claims:
Active-mode MCU + RF (SMPS ON): < 50 μA/MHz
RX: 3.8 mA
TX at 0 dBm: 5.5 mA
It is rather a marketing number, let say it will be 100uA/MHz (a few peripherals on), at 64MHz = 6.4mA + 4.2mA_radio = 11mA..

[aonsquared – Sun Feb 25, 2018 4:55 pm] –
…
It seems both cores in the ESP32 are the same type (up to 240MHz per core) which would increase power consumption.
…

Yes, but as the cores are identical and as Espressif links in the FreeRTOS, the Arduino side can use the core_0 which supports the RF stack… essentially removing the load from core_1. https://www.hackster.io/rayburne/esp32- … res-8dd948

Also, the ESP32 has a completely separate 3rd core which is low-power. I have not played (yet) with the ULP coprocessor but I have high hopes for this little piece of sand. http://esp-idf.readthedocs.io/en/latest … s/ulp.html

My guess is that the STM will still be superior for real-time needs but the ESP32 will be more versatile, especially with the addition of PSRAM.

Ray

[mrburnette – Mon Feb 26, 2018 12:57 am] –
Also, the ESP32 has a completely separate 3rd core which is low-power. I have not played (yet) with the ULP coprocessor but I have high hopes for this little piece of sand. http://esp-idf.readthedocs.io/en/latest … s/ulp.html

Looking forward to seeing your post about it

In the meantime though, assuming 20mA for the M4 and 11mA from Pito’s calculation: 31 mA total for application processor, low-power co-processor *and* Bluetooth is lower power consumption than a Teensy! Great for mobile devices with very limited power budgets.

Wait…sorry, I realised the calculation was for the main M4!

So ST’s marketing says 50uA/MHz and we’ll double that to 100uA/MHz assuming peripherals are on.

M4: 100uA/MHz * 64MHz: 6.4mA
M0+: 100uA/MHz* 32MHz: 3.2mA
Bluetooth active transmit: 5.5mA (0dBm), let’s double that (+3dBm) to 11mA

So with 2 cores running, bluetooth transmitting, is 20.6mA…

Well, when they start showing up in quantities and on some dev boards, *AND* they are a reasonable price, then they will get my attention. Till then we wait and see.

[ahull – Mon Feb 26, 2018 11:44 am] –
Well, when they start showing up in quantities and on some dev boards, *AND* they are a reasonable price, then they will get my attention. Till then we wait and see.

+1
Aye, I’m with the Scotsman

it seemed it may be priced somewhat dearer for a finished board vs BP/MM lol
http://www.st.com/content/st_com/en/abo … p4013.html
Engineering samples of the STM32WB in packages up to 100-pin WLCSP will begin sampling to lead customers in Q1 2018, priced from $1.56 for high-volume orders

hopefully it become a new toy here, BLE stm32duino?

Nordic Semi already have a considerable foothold in this BLE market…

nRf51xxx boards are available for less than $5 on Aliexpress, and the newer nRF52xxx boards are also coming down in price to below $10

Sandeep Mistry already has a very mature Arduino Core for these processors from Nordic, so I think it will be some time before the STM product can catch up.

However, IMHO BLE is hard to use, because generally the main reason to use it, is to allow your smartphone to communicate with your project, and writing code that runs on a variety of smartphone OSes and hardware is much more difficult than it appears.

Believe it or not, the BLE standard does not define a standard BLE service akin to a serial device, so there are no off the shelf apps which will send and receive a stream of character data.

Nordic have their own UART service, in a private service ID number, Red Bear Labs App used a different private service ID, etc etc

Getting your app onto an Apple device requires a developer account with Apple and costs $$ per year.

Android is free, but I found different versions of Android have all sorts of quirks with BLE, and different manufacturers hardware behaves differently.

So unless you absolutely have to connect to a smartphone, and must use low power, then there are loads of better options.

Smartphone and high power usage, just use Wifi..
Non smartphone and low power usage, probably use LoRa

I’ve been using GrumpyOldPizza’s core for the STM32L4 and it’s excellent. The “official” STM L4 arduino core is quite a lot more buggy. If Kris and Thomas make a core and dev board based on the STM32WB and extend the Dragonfly/Ladybug/Butterfly core for it, the Nordic NRF boards will have some serious competition

yup, stm is somewhat late to the party, but i’d guess it’s better late than never, nordic & esp32 & even ti is already ahead in the party, their earlier attempts with ble seemed landed a dud as it tend to be separate from the soc

[ag123 – Wed Mar 07, 2018 9:18 am] –
…
stm is somewhat late to the party …

In this case, being “late” may be a good thing. Some of the design decisions should have the benefit of watching their competitors attempt to find the “sweet” point in the market for IoT. While the ESP8266 from Espressif was a big hit, there were serious issues in power management and the term “low power” was simply never appropriate. The ESP32 is a significantly more flexible product and with three “cores” is the price/performance technology to beat.

Perhaps, too, STM, will devote some resources to deliver an “approved” Arduino implementation as has Espressif. While “ArduinoIDE” is often thought of as a “hobby class” IDE, a significant number of engineers are always working “in home workshops” trying to get to the next big concept … the noise generated in these workshops drive a significant amount of Internet news coverage and interest.

[aonsquared – Tue Mar 06, 2018 10:16 pm] –
I’ve been using GrumpyOldPizza’s core for the STM32L4 and it’s excellent. The “official” STM L4 arduino core is quite a lot more buggy. If Kris and Thomas make a core and dev board based on the STM32WB and extend the Dragonfly/Ladybug/Butterfly core for it, the Nordic NRF boards will have some serious competition

STM32WB will be supported soon Similar core to STM32L0/STM32L4. However it’s my understanding that parts will ship only 2H 2018.

Any suggestion for what BLE Arduino API de jour to use ?

what’s a little fun to note is that while we are getting excited over a forthcoming new ble toy that’s yet unreleased, intel has been there done it and dumped it (discontinued), i’m not too sure if intel would dust it and offer it for sale again
https://store.arduino.cc/usa/arduino-101
https://www.arduino.cc/en/Reference/CurieBLE
https://www.adafruit.com/product/3033

nordic seemed to have given an api a shot as well
https://github.com/NordicSemiconductor/ble-sdk-arduino
http://bleduino.cc/

and from st as well
https://github.com/stm32duino/SPBTLE-RF

and another
https://github.com/pauloborges/blessed

i think 1 of the issues is that a formal BLE protocol stack is rather large (pretty similar to usb) in terms of the large number of formal use cases and protocols defined. i’d imagine the headers and classes would reflect gap, gatt/att, l2cap and it (the ble ‘library’) talks HCI commands (which could be serial/spi etc) to the ‘radio’ side of things

(app side)
GAP | GATT / ATT
L2CAP
———-
HCI
LL
PHY
(ble radio side)

At the moment I’m using the Zentri AMS001 which is a UART BLE module: https://www.zentri.com/ble-modules/

It’s practically a Cortex-M3 controlled by serial commands, so I don’t really have the experience of direct firmware control of BLE. The AMS001 is really good except for the characteristics being fixed, for example. However what I like about it is that encryption is quite easy to implement, simply:

bl e e (encryption enable)
bl e k [passkey]

[ag123 – Thu Mar 08, 2018 2:26 pm] –
i think 1 of the issues is that a formal BLE protocol stack is rather large (pretty similar to usb) in terms of the large number of formal use cases and protocols defined. i’d imagine the headers and classes would reflect gap, gatt/att, l2cap and it (the ble ‘library’) talks HCI commands (which could be serial/spi etc) to the ‘radio’ side of things

Actually that is the messy part. A lot of the code I have seen in this area was trying to be too simplisitic on one side, and to much hardware oriented on the other side. ATT/L2CAP/HCI don’t really matter. All that’s important are the GATT and GAP interfaces.

Conceptually something like this here (yes, this is a REST type API, but it conveys pretty much the interesting aspects for a BLE central):

https://www.bluetooth.org/docman/handle … _id=285911 (GAP)
https://www.bluetooth.org/docman/handle … _id=285910 (GATT)

The Arduino 101 library is interesting. It started off the the BLE-peripheral library, tried to fix up many parts, broke compatibility (not surprising given the limited scope of BLE-peripheral), and then being forced back to be compatible again … However no way to deal with indications and notifications …

Haven’t seen any arduino style code that would properly get the concepts of central/peripheral/broadcaster/observer vs. client/server and such …

The code stack is not too big it seems. BlueNRG-1 does this in about 72k. The LoRaWAN stack is about 40k compared to that …

I’ve had a bit of experience with low level BLE, very much looking forward to find some cheap STM32 BLE to play with.

I can confirm that yes, most BLE implementations offer NO SECURITY, even with the default AES encryption properly set up, as its specification is broken (maybe this has improved in more recent chips?).

Nordic’s solution to the large flash requirements of the stack was basically a code generator with only your specified protocols and features.

And yes, Android BLE is an absolute mess internally (not gonna say it was the reason my startup failed, but it definitely didn’t help), but Android >= 5.4 is fairly workable. Just forget about backwards compatibility with old phones, it’s a completely different API and not reliable at all and a battery drain.

at the moment it would still seem to be that ST is only targeting the volume customers
https://www.st.com/en/microcontrollers/ … tId=SS1961
order volumes is 10000 (no distributor availability) and it seemed no ‘discovery’ or ‘nucleo’ boards are spotted in the wild yet
as stm32s has quite a bit of on soc peripherals this may be targetted at smart watches, fitness bands or ‘iot’ use cases
in some ways this is still pretty much similar to TI’s cc2640 series
www.ti.com/product/CC2640

BLE is of poor security and a privacy breach, it keeps advertising in a non-connected state as this is the use case of BLE ‘beacons’
i’d think the design is deliberate given the intent to use it for ‘beacons’. unfortunately this is the biggest game in town given the
increasing number of socs and devices supporting ble and there is no doubt it is a growing market. AES can be pretty secure but while reading the specs i had a hard time understanding the protocol specifics, i think the various parts at the ‘lower’ level which is the main BLE stack couldn’t be secured, what can be secured is after the connect linkup is negotiated.

the other thing about BLE protocol stack is that is is simplier, hence it’d likely be easier and smaller to write an app which is pretty much one’s own GATT/GAP

i’ve this strange feeling that BLE is after all a ‘new USB’ i.e. the de-facto wireless connectivity between devices (keyboards, mice, smart watches, fitness trackers, ble scales etc)

I got this kind of late, but ST are holding some STM32WB Workshops and providing STM32WB dev boards in early 2019:

https://www.st.com/content/st_com/en/ab … -2018.html

Registration is free, and hopefully I’ll be going to the 13th February one in Bristol.

sounds like it is finally going into mass production
there is now ‘competition’ at least alternatives vs NRF51822 and TI’s CC2640
ST’s soc tend to be ‘expensive’ hopefully it is priced competitively in the mass market
and that distributors distribute them

i stumbled into this web
https://www.st.com/content/st_com/en/su … ining.html

and for the impatient you can jump straight to that bluetooth core
https://www.st.com/content/ccc/resource … gy-BTH.pdf
https://www.st.com/content/ccc/resource … iew-RF.pdf

interestingly the comms between the smaller CM0 core which runs the bluetooth services is thru a ‘shared memory mailbox’ seen by the ‘app’ as a 2 wire UART interface.

happy reading

this should ‘blow away’ the ble competition as it seem to state Bluetooth 5.0 2 mbps but still plain slow compared to 100 – 1 Gbps wifi

and the fun thing is uno headers seem to be a ‘must have’ foot prints on ‘development boards’ these days, and the usb dongle version seem to be the ‘new mini’
https://www.st.com/content/ccc/resource … Boards.pdf

[ag123 – Sat Mar 02, 2019 9:37 am] –
i stumbled into this web
https://www.st.com/content/st_com/en/su … ining.html

and for the impatient you can jump straight to that bluetooth core
https://www.st.com/content/ccc/resource … gy-BTH.pdf
https://www.st.com/content/ccc/resource … iew-RF.pdf

interestingly the comms between the smaller CM0 core which runs the bluetooth services is thru a ‘shared memory mailbox’ seen by the ‘app’ as a 2 wire UART interface.

happy reading

I actually attended ST’s STM32WB workshop about 2 weeks ago. You misread that slide a bit – if the STM32WB dongle is in RF test mode, it appears as a UART to the host PC that you send ACI commands to like a serial terminal.

The IPCC and HSEM commands don’t appear as UARTs while programming the microcontroller – it’s actually quite seamless, callbacks are generated for each BLE event and you just execute BLE function calls in your user code whenever needed.

Anyway, finally they have the STM32WB Nucleo and bare chips available. AVNET co-sponsored the workshop in Bristol so it seems like they’re the first distributor to get the chips and dev boards, but Mouser seems like they will be in stock pretty soon.