我们应该希望长期使用stm8吗？

说实话，半导体行业的动态在最近几十年已发生变化，如果生产线保持盈利，晶圆厂和测试设备不会崩溃，或者被自然灾害所淹没，它们很可能会继续，但是当说变量时转过身来，你会失去运气。
实际上，人们需要自适应，更多的工程资源和工厂空间被分配给ARM / Cortex设计。 CM0 / CM0 +针对的是8051和其他运行较低的8位内核，对于编译器/工具供应商而言，8位部件是非常残酷的目标，而且利润最低。
我不是说放弃任何平台，只是充分蚕食，并准备移植你的工作，并有一种写出更多可移植代码的心态。
如果这是您需要的时间尺度，请查找具有“10年保证”的零件。



以下为原文




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.

非常感谢你的回复。你是对的，我们必须始终为意外做好准备，尽管这需要额外的费用。我希望这个出色的处理器能够在行业中占据稳定的位置，并且可以纠正设备中令人讨厌的错误。



以下为原文




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.

请注意，决策将由会计师，而不是工程师和优雅的解决方案驱动。



以下为原文




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

我从STM8用户那里听说ST已经鼓励他们已经搬到STM32。另一方面，ST仍在发布新的STM8器件（如今年秋季的8引脚器件）。从外面看，似乎ST内部有不同的派系。这个问题。
我想STM8S001远远超出ST的预期（可以从发布后的分销商的可用性推断出来）可能有助于确保STM8的未来。
就个人而言，我更喜欢STM8设备的第二个来源。 8051仍然由许多公司生产，尽管英特尔很久以前就停止生产它们。
在编译器方面，SDCC和相关的免费工具正在改进。对于C开发人员来说，我希望STM8工具链的情况在很长一段时间内看起来都很好。
菲利普



以下为原文




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

编写可移植代码将帮助您，即使硬件将来仍然可用，因为它允许在编译器之间轻松切换。减少对特定于实现的行为的依赖。
在选择编译器时也要考虑标准兼容性（即使用SDCC或IAR而不是Raisonance）。
菲利普



以下为原文




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

对于意法半导体而言，STM8的关键优势可能是它们不必为设计支付版税，其他想法/概念的专利可能声称已经过期。
好的工具不会遭受比特腐烂，他们运行的平台可能会失去支持（DOS，Win16），我有1980年代和1990年代的工具我仍然可以运行并生成代码就好了。我还移植了东西并重建了DOS扩展器和链接器/对象工具来迁移废弃物以在当前设备上运行，这不是不可能的，有些人仍然可以做到这一点。获得工具供应商的支持可能非常困难。请注意，您使用技术的时间越长，您需要承担更多的支持/成本负担。



以下为原文




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.

我的2C ......刚刚加入了一个涉及STM8L的新项目。
他们选择它只是因为它们是从基于该芯片的第三方参考设计开始的。不是因为芯片的成本。
8位微型计算机适用于单人项目。
使用STM8，我必须推出一个脆弱的中断拼凑和“超级循环”，很难适应其他开发人员。
如果他们可以使用32位ARM，就可以引入一个不错的RTOS，这对于协调多个开发人员之间的工作非常有用（将功能分解为“任务”和丰富的通用基础设施）。
我们还考虑了专有STM8工具链与ARM可用的危险。遗憾的是，那里唯一的开源编译器不支持任何对团队来说没有用的GUI。 （这可以做，但谁有额外的时间？还是钱？）
回到最初的问题 - 是否还有8位的利基 - 恕我直言，只有EE可以回答这个问题。
8位是低密度的，这意味着更耐辐射和温度。但这种差异是否重要？可以通过屏蔽来补偿吗？
ARM M0的功耗并不比STM8（尤其是8L）高很多，但对于某些应用来说，这种差异也很重要。
- pa



以下为原文




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

目前，我不是真正的RTOS或IDE用户。然而：
实际上，ARM具有更好的RTOS可用性。但也有一些
http://www.colecovision.eu/stm8/rtoses.shtml
。根据您的要求，他们可能会或可能不会为您做。 Atomthreads似乎是一个合理的选择，特别是由于您对工具链情况的担忧：Atomthreads支持STM8的所有4个工具链（SDCC，IAR，Cosmic，Raisonance）。特别是在IDE支持和目标调试中，免费工具链不是但达不到非自由替代品的标准。然而，它正在迅速改善。如果您今天使用非免费工具链编写可移植代码，以后应该很容易更改为不同的免费或非免费工具链。
有一个
https://stm8-binutils-gdb.sourceforge.io/
。从我在德语ÂμC论坛上所听到的情况来看，它已经很好地运作了。 SDCC 3.7.0将通过改进的ELF / DWARF调试信息输出提供更好的支持.Code :: Blocks IDE支持SDCC（当我几分钟前安装并启动Code :: Blocks时，它检测到已安装的SDCC ，并让我选择GCC与SDCC作为新项目的默认编译器。然而，Code :: Blocks中的SDCC支持是为较早的SDCC编写的，它显示了。为当前的SDCC更新它似乎很容易，所以我
https://sourceforge.net/p/codeblocks/tickets/567/
。我希望它能够进入下一个Code :: Blocks版本。有些人使用SDCC与NetBeans和Anjuta，但我不知道在这些IDE中是否有对SDCC的支持，或者人们只是在他们的项目中使用普通的Makefile。
菲利普



以下为原文




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

对于'无寄存器'处理器的'无上下文'编译器是个好主意。我会使用SDCC来构建我的实验性多任务内核，但是到目前为止还没有启用它的一些特定属性。目前，我给COSMIC软件带来了好处。鉴于免费许可和高质量的代码优化。我想如果成功的话，我也会为SDCC建立一个端口。



以下为原文




'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.

从低端ARM内核的竞争中可以看出，高密度和中密度STM8设备的空气越来越薄。对于大规模产品，特许权使用费起着重要作用，而低密度系列包括汽车设备的情况使得在可预见的未来（包括价值线设备），过剩产能可能继续作为商业产品进行销售。将消费产品中的μC替换为2年的使用寿命很容易 - 从汽车产品的10年交付义务中解脱出来并非如此。



以下为原文




Seen the competition from low-end ARM cores one might argue that the air for High- and Medium-Density STM8 devices is getting thin. For large scale products royalties play a big role, and the circumstance that the low-density family includes automotive devices makes it likely that excess capacities will continued to be marketed as commercial products in the foreseeable future (including Value Line devices). Replacing the µC in a consumer product with 2 years useful life is easy - getting out of 10 year delivery obligations of an automotive product not so.

＆GT;＆GT;
在具有2年使用寿命的消费产品中替换μC很容易 - 从汽车产品的10年交付义务中获取并非如此。
尽管如此，即使有多个来源，也有一大堆“游戏结束”的情况，尤其是旧技术，或具有独特或外生特征的东西。
您应该有合同条款，保护您免受您无法控制的事情。即自然灾害，供应商的失败等



以下为原文




>>
Replacing the µC in a consumer product with 2 years useful life is easy - getting out of 10 year delivery obligations of an automotive product not so.
Still, even with multiple sources there are a whole bunch of 'Game Over' situations, especially with older technology, or things which have unique or exiotic features.
You should have contract clauses that protect you from things which are outside your control. ie Natural disaster, failure of suppliers, etc.

Clive One，我想你是对的。然而，问题在于汽车公司已经在谈判这些条款，Joe Small-Scale不需要太担心（并且可以安全地假设汽车采购部门了解他们的业务）。我曾经在一家中小企业工作过，自然灾害事件对关键部件的可用性产生了影响，大约在4到5年内发生过一次。使用主要用于“汽车”的部件允许继续生产，即使有时难以获得部件。当然，总是让下一个设计准备就绪，并且很好地管理硬件依赖性（例如使用某种抽象层）是明智的，但是在小规模上说起来容易做起来难，并且使用具有主要汽车市场的μC减轻了一些风险。



以下为原文




Clive One, I guess you're right. However, the point is that automotive companies already negotiated such clauses, and Joe Small-Scale won't need to worry too much (and it's safe to assume that the automotive purchase departments know their business well). I once worked in an SME, and natural disaster events that had an impact on availability of critical components happened about once in 4-5 years. Using parts primarily used in 'automotive' allowed production to continue, even if it was sometimes difficult to get components. Of course, it's wise to always have the next design ready, and to manage hardware dependencies well (e.g. with some kind of abstraction layer) but at small scale that's easier said than done, and using µCs with a primary automotive market mitigates some of the risk.

STM8是一款产品
http://www.st.com/content/st_com/en/support/resources/product-longevity.html
来自ST。我们通常会在每年年初重申这种长寿承诺。我们最近推出了新的8 PIN STM8设备。 STM8卷不断增长，产品非常成功。



以下为原文




STM8 is a product with a
http://www.st.com/content/st_com/en/support/resources/product-longevity.html
from ST. We typically renew this longevity commitment at the beginning of every year. We recently introduced new 8 PIN STM8 device . STM8 volumes keep on growing, the product is very successful.

我只是看看我在半导体行业的最后10年，并不怀疑你的承诺。如果您的承诺真正受到挑战，那么在8 - 9年，当一个15年的关键测试硬件发生故障并且供应商超过3代时，没有人有备件或更换运行200万美元，或者供应商那个封装包装破产或与竞争对手合并，或工厂在地震/海啸中被摧毁或处于放射性无区域中间。
这些事情最终取决于商业条件。



以下为原文




I'm not doubting your commitment, just looking at my last 10 years in the semiconductor industry. Where your commitment will really get challenged is in year 8-9 when a 15-year old piece of critical test hardware fails and the vendor is 3 generations beyond that, no one has spare parts or the replacement runs $2M, or the vendor that encapsulates the package goes bankrupt or merges with a competitor, or the factory gets destroyed in an earthquake/tsunami or is in the middle of a radioactive no go zone.
These things are ultimately predicated by business conditions.

嗨克莱夫，
实际上，所有这些都是供应链管理和业务连续性计划的问题。
在半导体业务中，产量是维持生产的关键。
如果您要为大量应用程序（例如移动电话）销售定制产品，那么由于您的卷依赖于单个产品/单个应用程序，因此难以承诺10年生产。
STM8和STM32用于数千种终端产品，我们不依赖主要客户来推动我们的产量。我们知道在未来10年内销量不会下降。绝大多数客户的设计周期都非常长。
对于生产设施，我们有一个双重采购政策，无论是运行还是作为备份（晶圆扩散/测试/组装）。



以下为原文




Hi Clive,
Actually, all this is a matter of supply chain management and business continuity plan.
In the semiconductor business, volume is key to maintain production.
If you were to sell a custom product for a very high volume application (such as a mobile phone for instance), it would be difficult to commit on a 10 year production since your volume rely on a single product / single application.
STM8 and STM32 are used in thousands of end products, we do not rely on a major customers to drive our volumes. We know volumes will not drop in the next 10 years. The vast majority of our customers have extremly long design cycles.
For the production facilities, we have a dual sourcing policy either running or as a back up (wafer diffusion / test / assembly).

不幸的是，没有5V容忍设备？我仍然认为它们是Microchip产品的强大（欧洲）替代品，尤其是AVR。



以下为原文




Unfortunately, there are no 5V tolerant devices? I still see them as a strong (European) alternative to the Microchip products, especially AVRs.

STM8S是5V器件。 STM32具有5V容限IO



以下为原文




STM8S is a 5V device. STM32 has 5V tolerant IO

不知道的。仅检查了L变体，因为我已经使用了STM32L 5V耐受微型。我会看到你在店里的东西。如果你让Cube生成SDCC代码，你将能够更多地推广它们。



以下为原文




Didn't knew that. checked only the L variant, as I use already the STM32L 5V tolerant micro. I'll see what you have 'in store' . You'll be able to popularize them even more if you make the Cube to generate the SDCC code.

菲利普，
感谢您提供RTOS建议。 Atomthreads看起来很好，但是最多2K RAM大小，它对堆栈使用RAM可能是令人望而却步的。
关于IDE - 对我们来说唯一重要的方面是可视化调试器。要编辑和构建，我们可以使用任何体面的免费IDE - 甚至是Visual Studio，但由于调试器我们坚持使用STVD。 Cosmic似乎有自己的调试器，但它不包含在他们的免费STM8包中，即使是试用版。这意味着，成本，许可滋扰等...当我们有一个免费且体面的工作调试器时，这不是一个交易。
- pa



以下为原文




Philipp,
Thank you for RTOS suggestions. Atomthreads looks good, but with at most 2K RAM size, its use of RAM for stacks may be prohibitive.
About IDEs - the only important aspect for us is a visual debugger. To edit and build, we can use any decent free IDE - even Visual Studio  but because of the debugger we stick to STVD. Cosmic seems to have their own debugger, but it is not included in their free STM8 package, even as trial. Which means, costs, licensing nuisance and so on... not a deal when we have a free and decently working debugger.
-- pa