Over. 2 billion stm8 sold

[dannyf]

latest build is STVD 4.3.9 from april 2016

Mine is 4.3.5, from 2013.

Doesn't sound like they are putting a lot of resources into it. Back to iar,

[Kjelt]

Ofcourse not the STM8 is a cashcow, they are milking it not investing too much in it anymore.
I really wonder if there will (ever) be a next generation 8 bit microcontroller (stm9) even from other vendors or that this was it and they are now pushing customers to the cheapo 32 bitters like the F0 series.
Would be a shame (IMO) since a small 8 bitter is an ideal way to start learning embedded programming.

[bazsa56]

Yeah, IAR would be much better, but right now we're not in a position to buy one just for this 1 product where we're using it in. STVD is not that bad, certainly not great but usable.

Regardless of the IDE and compiler, I'm very impressed with the chip itself. Don't mind the quirky architecture at all. I started using it mainly because of the price, but ended up really liking the chip and I see no drawbacks (minus the architecture, which the compiler handles anyway) to it, while I do see some advantages compared to other 8 bit micros. We expect our product to reach somewhat higher volumes then our other products, but the software inside is relatively simple. Our requirements aren't too specific, any chip that has an active current that isn't crazily high and has a hardare multiplier, plus UART and either I2C or SPI is fine. For this specific application I think the STM8 is a no brainer.

[Kjelt]

Just looked for the oldest S207 datasheet I could find in my archive, it is from august 2008, rev4 and it is preliminary.
I guess the STM8S1xx series were already on the market by then 

either I2C or SPI is fine. For this specific application I think the STM8 is a no brainer.

Watch out for that STM8 I2C peripheral it can bite in some applications and it takes time to work around it and lot's of frustration 

[dannyf]

I really wonder if there will (ever) be a next generation 8 bit microcontroller (stm9)

probably not, unless ST wants to compete in the low-end with Chinese / Taiwanese clones.

The CM0 is really the next "8/16" bit chip.

I think the STM8 is a no brainer.

I agree. Liked the TSSOP20 versions of both STM8 / STM32F0. The STM8 is a little bit pin limited. They really should just get rid of the onboard LDO and consolidated the STM8S and STM8L lines: the minimum voltage for STM8S is too high due to the LDO. To me, the 8L is simply a 8S - the LDO.

[dannyf]

Watch out for that STM8 I2C peripheral it can bite in some applications and it takes time to work around it and lot's of frustration 

It is a software problem. Basically those incompetent ST coders failed to clear EV6 in the SPL, as their datasheets clearly demanded. Once you fix that, it is golden.

[dannyf]

The "solutions" ST proposed in the cpal drivers basically render the devices unusable: they all evolve around making the i2c the highest priority process -> a low-speed peripheral taking the highest priority process. That's how crazy those guys are.

Once you code to the datasheet, you should be fine.

[dannyf]

the most amazing thing about the i2c fiasco is that st's own i2c examples would not run on their own hardware. You would think the application teams and the qa teams would have caught that before their distribution.

[Kjelt]

It is a software problem. Basically those incompetent ST coders failed to clear EV6 in the SPL, as their datasheets clearly demanded. Once you fix that, it is golden.

I never used the SPL for the STM8 
But I have to dig into it, I had some problems with hanging clocks in combination with some microchip i/o expander, i wrote both off and used a serial shift register with ultrahigh speed 
If you could post some code and the fix  , would appreciate it, might be usefull for some future project where I can not get past using the I2C unless I bitbang it.

the most amazing thing about the i2c fiasco is that st's own i2c examples would not run on their own hardware. You would think the application teams and the qa teams would have caught that before their distribution.

or at least fixed it when the complaints started pooring in the support forum 

[dannyf]

"
If you could post some code and the fix  , would appreciate it, might be usefull for some future project where I can not get past using the I2C unless I bitbang it."

Cannot give you the code - it was discovered when I was under a contract so it technically is other people's code but I can give you thee general flow when I get to a real computer later.

BTW, I'm only the 2nd person in the world who found the fix. The first person is the datasheet writer. The fix is laid wide open in the data sheet as it provides explicit fix in thee documents. How the SPL code monkeys missed that is beyond me.

[Kjelt]

"
If you could post some code and the fix  , would appreciate it, might be usefull for some future project where I can not get past using the I2C unless I bitbang it."

Cannot give you the code - it was discovered when I was under a contract so it technically is other people's code but I can give you thee general flow when I get to a real computer later.

BTW, I'm only the 2nd person in the world who found the fix. The first person is the datasheet writer. The fix is laid wide open in the data sheet as it provides explicit fix in thee documents. How the SPL code monkeys missed that is beyond me.

Thanks, that would be great, also a direct quote from the datasheet where the issue exactly is located would be ok, then there are also no contractual issues  .

[dannyf]

No problem. I will show you a picture of the datasheet. Just a little bit later.

[eck]

Thanks, that would be great, also a direct quote from the datasheet where the issue exactly is located would be ok, then there are also no contractual issues  .

As the STM32F1 and STM8 I2C peripherals are basically the same, you can check in either reference manual The key is the diagram called "Transfer sequence diagram for master transmitter". It explains what to do when - specifically, one gotcha is to clear the ADDR flag in SR1. To clear that flag, you need to read SR2 (STM32) or SR3 (STM8). The STM32F1 reference manual mentions this actually three times for good measure (first in the description of the diagram and then twice in the description of the SR2 register).

The other quirky thing with the I2C peripheral is the need to generate the STOP condition three bytes prior to the last byte in multibyte read transfers.

However, all of this is pretty clearly explained in the reference manuals, including pictures.

[dannyf]

eck got that right.

this is from the f1 datasheet, with the ev6 condition highlighted. Essentially, the code in F1 SPL does not follow that.

my code, for a i2c block writes, goes like this:

1. test for bus condition. if busy, return -1;
2. send a start condition;
3. load up device address + i2c command;
4. clear SR1/SR2 through two dummy reads. you don't even need to read them into anything.
5. load up the register address, ........

you will need to test conditions along the way and be prepared to handle exceptions. similar operations with read.

identical process with STM8, different register names.

[dannyf]

Short of the cpal solutions, any i2c code on those chips that do not follow the protocol above is unlikely to work. and there are quite a few such pieces floating around claimed by their creators to be "working",

I wonder if they actually tested their code,

[Kjelt]

Ah thanks, I will have to look into that if my code has it.
Still what a mess with all those states don't you think, you would expect it could have been made so much simpler, but then as we talked about in the other thread, probably not 

[dannyf]

The best i2c routines I have seen are those done by NXP  - fully state machine driven and incredibly easy to add / change exception handling regimes.

yes, I think the i2c implementation, both hardware and software, here and on ST chips in general is a mess.

[Kjelt]

Weird huh, the other peripherals like the timers, dac and uart are fine, no problems what so ever.

[richardman]

Yes, when I coded the I2C routines, I coded using the datasheet rather than the SPL/HAL examples and tested the heck out of them. There are definitely typos etc. in those SPL code!!

[westfw]

IAR supports it. If you program micros for a living, you have IAR, right?

there's a weak implication here that adding an additional target cpu to IAR is cheaper than buying a whole new compiler.
Is that actually the case?

The STM8F030 is priced like a low-end 8bit microcontroller.  In that area, you don't ALWAYS need a C compiler...

[nctnico]

IAR supports it. If you program micros for a living, you have IAR, right?

there's a weak implication here that adding an additional target cpu to IAR is cheaper than buying a whole new compiler.
Is that actually the case?

The STM8F030 is priced like a low-end 8bit microcontroller.  In that area, you don't ALWAYS need a C compiler...

I recall a project where only one engineer could change the software because my employer at that time was too cheap to buy a compiler so the project was coded in assembly. Using the STM8 ended up costing 10 times more than the savings in part costs and the product was already a kludge with an 8051 controller for the main tasks and the STM8 doing something I/O related 

There really has to be a compelling reason to use these archaic non-mainstream (=no GCC support) microcontrollers and that is volume volume volume. If that doesn't apply to your projects then by all means don't use these kinds of controllers because they will end up costing way more than the savings in part costs.

[dannyf]

when I coded the I2C routines, I coded using the datasheet

Yeah. As long as you code to the datasheet, it is ok.

There are definitely typos etc. in those SPL code!!

Yeah. Take a look at STM8S SPL's handling of HSE_Value. Total retards.

[bazsa56]

I can confirm as well that using the datasheet the I2C works just fine. Just finsihed writing my own routines for it, works quite well actually once you get it worked out. Not using the SPL at all for my project, the STM8 is simple enough to just poke the registers directly.