Skip to main content
This topic has been closed for replies.

5 replies

P
Philipp KrauseAuthor
Visitor II
December 20, 2017
Posted on December 20, 2017 at 12:38

I would like to see more support for STM8 IoT use. There should be STM8 development boards with short- and medium-range wireless netowrking. Ideally, there would be STM8 variants with direct support for such technologies. But some reference designs that require a few extra chips for communication (as long as this does not impact the energy budget too much) would help, too.

Philipp

R
raimond
Visitor II
December 20, 2017
Posted on December 20, 2017 at 17:52

1. Better accuracy of the HSI. +/-1% for the entire temperature range (and VCC).

2. A simple PLL. Even a clock doubler would be good, from 4-8MHz to 8-16MHz. A clock doubler is very very simple to implement.

3. RWW eeprom for more parts if not all.

4. More support for SDCC.

5. Some bug fixes from errata sheets would be good too.

T
Tesla DeLorean
Graduate II
December 20, 2017
Posted on December 20, 2017 at 18:33

>>1. Better accuracy of the HSI. +/-1% for the entire temperature range (and VCC). 

Hugely difficult to do across process variations, and to test, trim and guarantee in specifications.

P
Philipp KrauseAuthor
Visitor II
December 20, 2017
Posted on December 20, 2017 at 22:11

It would also be nice to have devices with 16 KB of RAM (maybe also 8 KB or 12 KB, but those seem less important to me).

Philipp

H
henry.dick
Visitor II
January 31, 2018
Posted on January 31, 2018 at 15:09

More toolchain options would be great. Sdcc isn't for prime time. Iar is great but expensive. Maybe atollic under St ownership can offer something in the near future?

The parts themselves are great. However, I have seen more people gravitating towards cm0 parts instead, given more performance, better upward mobility, and minimum cost differentials. Maybe St should focus those parts as pic/avr killers. To do that, more interesting peripherals in pin limited parts would be help.

I would suggest a better pin remap mechanism (aka pic24), dac, adc with internal calibration and differential inputs, high speed programmable oscillator, opamp and programmable gates...

V
Vasile Guta_Ciucur
Visitor II
February 28, 2018
Posted on February 28, 2018 at 16:59

dhenry wrote:

... I have seen more people gravitating towards cm0 parts instead, given more performance, better upward mobility, and minimum cost differentials. Maybe St should focus those parts as pic/avr killers. ...

I would suggest a better pin remap mechanism (aka pic24), dac, adc with internal calibration and differential inputs, high speed programmable oscillator, opamp and programmable gates...

PIC24 is a cm0 killer. Better pin remapping, better speed, lots of good peripherals, great case/capsule options for beginners and hobbyists, almost on par with cm3, excellent documentation.

All I want from STM8S series, is DIP encapsulation (or at least, big smd sizes as Microchip offers - tqfp and ssop ) for all lines (Value, Access, Performance). And then, no need of cm0 or 'Discovery/Nucleo' boards that can't be used in commercial products.

H
henry.dick
Visitor II
February 28, 2018
Posted on February 28, 2018 at 23:01

Yeah. Pic24 is a great chip that's grossly underappreciated by users and under marketed by microchip.

P
Philipp KrauseAuthor
Visitor II
March 19, 2018
Posted on March 19, 2018 at 14:38

Regarding the stack roll-over limit:

1) For new stm8 devices, please do not implement a stack roll-over (or at least make it configurable)

2) Please properly document the stack roll-over limit for existing devices.

Philipp

P.S.: The stack roll-over limit of 0x1400 of the STM8AF5288 is documented. But recently I worked with the STM8S208. I did not find any information on presence or value of a roll-over limit for that chip. But from the behaviour of my software, the STM8S208 also has a roll-over limit somewhere between 0x1000 and 0x1400.

R
raimond
Visitor II
March 23, 2018
Posted on March 23, 2018 at 18:25

Page 34 of the STM8S207/208 datasheet. In the figure 8. Memory map you get the '1024 bytes stack' text in the ram area.

It seems that this is all documentation you can get about the stack roll-over limit in the STM8 datasheets.

Terms & ConditionsAccessibility statement