Returning to STM32:: STM32U0 vs STM32L0

[AgriPacTe-cs]

Bonjour, (in english below)
J'ai travaillé sur un Nucleo-L053R8 de 2015 à 2019 (j'ai encore le Nucleo)
Je reprends un travail analogue (réseau d'IoT basse énergie(LE) en milieu agricole, capteurs (certains nécessitant ADC), commandes, petits moteurs ...)
Je vois qu'il existe une nouvelle ligne de produits U0
Ma question: Est-ce qu'il est plutôt conseillé (obsolescence) de changer pour un Nucleo-U0 ou je peux travailler pour commencer sur le Nucleo-L0 ?
Question subsidiaire: Est-ce que tous les outils (ST-Link, ...) sont intégrés dans STCube ou je dois tous les installer séparément ?
Accessoirement: Mes dernières créations étaient en Python (interface) et en Rust (certaines libairies). Quel est le contexte de développement le plus adapté à mes dernieres compétences de programmation (C++, Python, Rust) ?

Good morning,
I worked on a Nucleo-L053R8 from 2015 to 2019 (I still have the Nucleo)
I am returning to similar work (low energy IoT (LE) network in an agricultural environment, sensors (some requiring ADC), controls, small motors, etc.)
I see there is a new U0 product line
My question: Is it rather advisable (obsolescence) to change to a Nucleo-U0 or can I work on the Nucleo-L0 to begin with?
Subsidiary question: Are all the tools (ST-Link, ...) integrated into STCube or do I have to install them all separately?
Incidentally: My last creations were in Python (interface) and in Rust (certain libraries). What is the development context best suited to my latest programming skills (C++, Python, Rust)?

[Uwe Bonnes]

More recent devices are normally faster and have mor advanced peripherals. E.g. Usart on U0 has USART FIFO and recent devices on recent rtechnologu turn to be cheaper. But also external support may lag. You have to evaluate yourself/

[waclawek.jan]

> Is it rather advisable (obsolescence)

ST has a rolling 10-year guarantee, for whatever it's worth. So far, only the 'L1 (and the STM8) were taken out of that guarantee (with remaining cca 8 years) and NRND'd. The 'L0 is a relatively recent addition, so at this point it's probably many years until its retirement.

The 'U0 is very fresh at this point, with all advantages and disadvantages this brings.

You may want to review the 'L0->'U0 migration document, AN6091, too.

JW

 

 

[Viktor POHORELY]

Although U0 is good product to replace L0, there are no plans to stop L0 product - plus there is this 10 years longevity program.

However, hearing IoT in the text, I would strongly recommend to move to U0 instead of L0 due to security features embedded in this new product line, as well as security certifications granted for this product.

Moreover, you will get recent versions of IP with various improvements.

[OliM]

If you really mean IoT as being directly connected to the internet via cellular or something similar, I would even look in the direction of the U5. 

[AgriPacTe-cs]

Thanks to all

[DAlbe.3]

It is wonderful that ST makes pin-compatible upgrade paths such as L0 to U0; I expect many customers will want to follow such a path. A few suggestions/observations:

1. It would be very helpful if the ST software support team were aware of this migration.  Making unnecessary changes to CMSIS constants e.g. GPIO_BSRR_BR_0 -> GPIO_BSRR_BR0 (no underscore before the 0) makes porting code unnecessarily difficult. Obviously it's not hard to create a set of mapping defines, but it creates completely unnecessary work for thousands of developers.
   
   
2. Every backward incompatibility is costly.  I realize sometimes it is necessary, and that the U0 flash changed in part to add significant security features, however the complete removal of the EEPROM was especially painful. Most modern embedded systems need to store some persistent data and EEPROM is just the ticket; it was a wonderful feature of the L0 series.  I realize we can add an external EEPROM or do a very ugly EEPROM emulation, but it sure would have been nice if the U0 series offered a cleaner migration path from the L0 series.

Most development is not greenfield - every incompatibility results in a great deal of cost for OEMs as they must make code that supports both processor series (often difficult with limited flash) or maintain two codebases - very costly.  If ST wants to help customers switch quickly to newer series, the single best thing they could do is to maximize backward compatibility.