Should we hope for long-term use of stm8?

[Vyacheslav Azarov]

Posted on October 12, 2017 at 14:20

Hello everybody,

Recently, the company has been actively offering to transfer your projects from 8-bit micro-controllers to 32-bit ones. In view of this, I had concerns about the feasibility of future developments with the use of STM8. I like these efficient and inexpensive processors, and I would not want to lose this engineering resource in the near future. If anyone can, anything, say about this, then please participate.

#stm8 #future

[Tesla DeLorean]

Posted on October 12, 2017 at 14:51

To be honest the dynamics in the semi industry have changed in recent decades, if the line remains profitable, and the fab and test equipment don't break down, or get overwhelmed by natural disaster, they are likely to continue, but when said variables turn you'll be out of luck.

Realistically one would need to be adaptive, vastly more engineering resources and fab space are being allocated to the ARM/Cortex designs. The CM0/CM0+ being targeted at 8051 and other lower running 8-bit cores, and for compiler/tool vendors the 8-bit parts are pretty brutal targets, and least profitable.

I'm not saying abandon any platform, just be sufficiently nibble, and prepared to port your work, and have a mindset of writing more portable code.

Look for parts with a '10-Year Guarantee' if that's the time scale you need.

[Vyacheslav Azarov]

Posted on October 12, 2017 at 15:45

Many thanks for reply. You are right, we must always be prepared for the unexpected, although this and requires additional costs. I hope that this wonderful processor will take a stable place in the industry, and annoying errors in the equipment will be corrected.

[Tesla DeLorean]

Posted on October 12, 2017 at 16:25

Just be mindful that decisions will be driven by accountants, not engineers and elegance of solutions.

[Philipp Krause]

Posted on October 17, 2017 at 15:38

I've heard from STM8 users that ST was encouraging them to move to STM32 years ago already. On the other hand, ST is still releasing new STM8 devices (like the 8-pin devices this autumn). From the outside, it seems like there are different factions inside ST wrt. this question.

I guess the STM8S001 being popular far beyond ST's expectations (as can be deduced from the availability at distributors after launch) might help secure a future for the STM8.

Personally, I'd prefer if there was a second source for STM8 devices. The 8051 are still produced by many companies, even though Intel stopped making them long ago.

On the compiler side, SDCC and related free tools are improving. For C developers, I'd expect the the STM8 toolchain situation to look quite good for a long time to come.

Philipp

[Philipp Krause]

Posted on October 17, 2017 at 15:45

Writing portable code will help you even if the hardware will still be available in the future, since it allows for easy switching between compilers. Reduce reliance on implementation-specific behaviour.

Also consider standard-compliance when choosing your compiler (i.e. use SDCC or IAR instead of Raisonance).

Philipp

[Tesla DeLorean]

Posted on October 17, 2017 at 16:57

For ST the key advantage of the STM8 is likely they don't have to pay royalties on the design, and patents on ideas/concepts other might have claim to have expired.

Good tools don't suffer from bit-rot, the platforms they run on may lose support (DOS, Win16), I've got tools from the 1980's and 1990's I can still run and generate code just fine. I've also ported things and rebuilt DOS Extenders, and Linker/Object tools to migrate abandon-ware to run on current equipment, it's not impossible and some people can still do it. Getting support from tool vendors may be very difficult. Just be conscious that the longer you stay with a technology the more of the support/cost burden you will need to shoulder yourself.

[Pavel A.]

Posted on October 20, 2017 at 23:10

My 2C...  Just recently joined a new project involving a STM8L.

They choose it only because they started from a 3rd party reference design based on that chip. Not because of cost of the chip.

A 8-bit micro is good for one-person projects.

With STM8, I have to roll a fragile patchwork of interrupts and 'super-loop', hard to accommodate for other developers.

If they could use 32-bit ARM, it would be possible to bring in a decent RTOS, which is very useful to coordinate work among several developers (break functionality to 'tasks' & rich common infrastructure).

We also consider dangers of proprietary STM8 toolchain vs what is available for ARM. The only opensource compiler there unfortunately is not supported by any GUI which is no-go for the team. (this can be done, but who has extra time? or money?)

Back to the original question - is there still a niche for 8-bits - IMHO only a EE can answer this. 

8-bits are low-density which means more resistant to radiation and temperature. But does this difference matter? can it be compensated by shielding?

Power consumption of ARM M0 is not much higher than STM8 (especially 8L)  but for some applications this difference can be critical too.

-- pa

[Philipp Krause]

Posted on October 21, 2017 at 11:30

Currently, I am not really a RTOS or IDE user. However:

Indeed, ARM has much better RTOS availabilluty. But there are a few

http://www.colecovision.eu/stm8/rtoses.shtml

. Depending on your requirements they might or might not do for you. Atomthreads seems like a reasonable choice, especially due to your concerns about the toolchain situation: Atomthreads supports all 4 toolchains for the STM8 (SDCC, IAR, Cosmic, Raisonance).

Especially in IDE support and on-target debugging, the free toolchain is not yet up to the standard of the non-free alternatives. However, it is improving rapidly. If you write portable code today using a non-free toolchain, it should be easy to change to different free or non-free toolchain later.

There is a

https://stm8-binutils-gdb.sourceforge.io/

. From what I've heard on a German-language µC forum it already works quite well. SDCC 3.7.0 will have even better support for this via improved ELF/DWARF debug info output.

The Code::Blocks IDE has support for SDCC (when I installed and started Code::Blocks a few minutes ago, it detected the installed SDCC, and gave me a choice of GCC vs. SDCC to use as the default compiler for new projects). However the SDCC support in Code::Blocks was written for older SDCC, which shows. Updating it for current SDCC seemed easy, so I

https://sourceforge.net/p/codeblocks/tickets/567/

. I hope it make it into the next Code::Blocks release.

Some use SDCC with NetBeans and Anjuta, but I don't know if there is any support for SDCC in those IDEs or people are just using plain Makefiles with their projects.

Philipp

[Vyacheslav Azarov]

Posted on October 22, 2017 at 05:46

'Context-free' compiler for 'registers-free' processor it is good idea.  I would use the SDCC to build my experimental multitasking kernel, but some of its particular properties are not enabled to do this so until now. Currently, I give the advantage to COSMIC software. In view of the free license and high-quality code optimization. I think that if successful, I will make a port for the SDCC, also.