Should we hope for long-term use of stm8?

Vyacheslav Azarov · ‎2017-10-12

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

Philipp Krause · ‎2017-10-31

Posted on October 31, 2017 at 17:11

Work on having visual debugging in the free toolchain is progressing.

For now, there already is

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

which allows on-target debugging from the Eclipse IDE.

There are a few issues, most notably regarding local variables allocated partially to registers, which gets worse with higher optimization levels; also the generated code is somewhat different from the one without debug info. But in general it works.

Work is in progress on solving the remaining issues (most are already solved in the source repositories). I guess that on-target debugging will be fully working before the end of the year. Also from within Eclipse and Code::Blocks.

Philipp

Vyacheslav Azarov · ‎2017-10-31

Posted on October 31, 2017 at 17:54

Sorry for invading your dialogue. It would be great if it all worked. I like CDT. I highly appreciated it when using Ac6 System Workbench. However, the generator of the code of the SDSS for STM8 desirable to significantly improve. May be I do not known the magic word?

Vasile Guta_Ciucur · ‎2017-11-01

Posted on November 01, 2017 at 09:08

https://sourceforge.net/projects/eclipse-sdcc/?source=directory

There is an Eclipse plug-in for 8051 target that can be easily modified to target STM8 (I did it for PIC18F46K22 just by changing the configuration files

https://betterc18.blogspot.ro/p/eclipse-sdcc.html

)

Philipp Krause · ‎2017-11-01

Posted on November 01, 2017 at 10:22

1) All compilers will be good at some code and not so good for other (see e.g.

https://community.st.com/0D50X00009XkXJKSA3

about such an issue for Cosmic). While ideally compilers would generate very optimized asm for all C input, in reality it helps to know a bit about what coding style the compiler likes and generates efficent code for.

2) Since SDCC is improving rapidly, it helps to use a recent version (the SDCC 3.6.0 release was over a year ago; there will probably a SDCC 3.7.0 release later this year), development versions are available as binary snapshots and source.

3) For a lot of code, the magic word is: --opt-code-size --max-allocs-per-node <value>. Where <value> is some big number. The default is 3000. Larger values make SDCC optimize more (but slow down compilation).

4) If you have a compileable, small code example, where you think that SDCC generates particularly bad code, you can open a feature request at Sourceforge. This might lead to an improvement in SDCC (while sometimes feature requests get implemented quickly, others stay in the tracker for years without anything happening).

Philipp

Philipp Krause · ‎2017-11-01

Posted on November 01, 2017 at 10:24

While that plugin seems to work well for you (on 64-bit GNU/Linux), I've read in other places about people having problems getting it to work (especially when using recent 64-bit Eclipse on Windows). I guess it needs some updating.

Philipp

Vyacheslav Azarov · ‎2017-11-01

Posted on November 01, 2017 at 20:36

Thank you very much for the suggestion, Philip. However, I can not support your project financially. Therefore, I think that I can not demand anything from you. If you are interested I can prepare for you a few examples, soon.

Vyacheslav Azarov · ‎2017-11-07

Posted on November 08, 2017 at 07:11

Reputable Clive One,

Tell me please, what the old high-quality compiler do you use? I also need this. And where it can be acquired?