Wondering about the STM8L151

[RandoSY]

Hello!,

I don't need the LCD driver support, so I was wondering if there was any issues about using the STM32L151, with the existent image for the '152? Do I need to make any changes?

Thanks as always!

[TG9541]

Hi,
you surely mean the STM8L151?

As far as I can see it that would only require setting HAS_LCD = 0 in globconf.inc of STM8L-DISCOVERY.

Cheers,
Thomas

[RandoSY]

Hi Thomas,

Oops, sorry, way too much time looking at the ST datasheets I'm afraid. Yes I mean the STM8L151, thanks for the kind consideration of your prompt response.

The STM8L151 give me a single channel, 12-bit static DAC for less than 1$. Cool beans!!!

Randy

[TG9541]

You're right - the 12bit DAC is a nice feature - don't know about the accuracy, though (at 3.3V we're talking about just 800µV/digit) - one has to be very careful with the PCB design. Devices that don't have separate Vref pins (28 or 32 pin packages) will have a lot of trouble meeting the specs.

Will you need a configuration? Do you think it makes sense to provide a standard configuration or do you want to tailor it to your application?

[RandoSY]

I really haven't thought it out completely, my original idea was that it would make sense to have as much resolution on the signal output, as I did on the A2D input.

I will be synthesizing an analog voltage to a quality DVM as kind of a process follower, so nothing for it, but to do some real testing to see how it works. I wanted something to contrast/compare with the standard PWM output DAC, which is a good inexpensive candidate as my speed requirement is quite low.

Just the kind of simple testing that works out so well in Forth, in my experience. :)

[TG9541]

There is no doubt that the DAC will have a higher bandwidth than any PWM (and drift etc. will be better as well).

Right now I'm working on some STM8 boards - maybe I should think of a STM8L151 board since I should get more familiar with the Low Power devices and their more modern set of peripherals. Which device would you suggest for such a board?

[sbridger]

I have been looking at a low-power, lowest cost precision temperature logger. STM8L151G6 is the most likely choice as pcb would be sized around CR2032 or CR2450 battery. Not sure if you are interested in a collaboration Thomas?

The concept is around data storage in internal flash, and using the live 4th to minimise the amount of flash code storage to only what is required for logging, with data-readout, testing, calibration, configuration, linearisation code being downloaded only as needed during those phases

[RandoSY]

Hi Thomas,

I was looking at this as a resource ... most all under the magic 1$ price point, esp. X10 quantity.

https://lcsc.com/search?q=STM8L151

Exact packaging of course would depend on the subtleties of your requirements. If you get a set of Gerbers that you happy with I would love to send off and get a PCB to follow along. Surface mount no problem, as I am looking for a cool project to finally make the jump.

I have a preheat plate and hot air gun still in the box raring to go!

Thanks so much for your great work on this project!

Randy

[TG9541]

@sbridger my "creative time" is currently quite limited (too many interesting/risk-related things going on at work). Temperature logging sounds interesting - I've seen at least one project on HaD with a 20mm diameter logger.

• Any idea about the sensor choice?
• 28K memory is, depending on the rate, little or a lot. What are the specs that you have in mind?
• what about time accuracy / synchronization?

@RandoSY: do you have some experience with KiCad? It's much easier to get started than it sounds. The workflow is easy to learn if you don't expect it to work exactly like the commercial tool X or Y that many people are used to. In fact, found it easier to learn than most tools.

[RandoSY]

Thanks for the tip, I found (esp.) Eagle and Altium to both be a quagmire, although I persevered until I could generate Gerber files, and get them "fabed" in China for a pittance. I just update KiCad to the latest and greatest (5.1.2) and started a class on Udemy on the subject.

https://www.udemy.com/kicad-like-a-pro-2e/

[TG9541]

Wow - there is a Udemy course on KiCad? When I started V4 was still the stable, and by watching various on-line tuturials I quickly learned that switching to V5 would be worth the trouble (even if that meant starting over).
My recommendation: go through the cycle quickly once with a really simple board.

[sbridger]

Precision NTC thermistor would be the primary sensor. Some sample units in the population would have a second precision I2C sensor to provide an independent cross-calibration reference which has a different ageing mode.

I plan to use internal oscillators, and diurnal temperature for long term calibration.
I have been experimenting with some waterproof data i/o methods,

STM8L151 has these advantages (on paper)

• decent ADC performance (some of the common cheap arms have awful ADC specs)
• stable RC oscillators against T and Vcc
• compact Forth
• IRDA uart mode

[TG9541]

@sbridger an interesting discussion!

• do you have a summary of how ADC12 compares in STM8L vs. STM32?
• How about using a 32.768 kHz crystal as the reference clock source? Isn't the RTC of the STM8L (or STM32) chips sufficiently lightweight? Hopefully I'll find an opportunity to discuss clock offset estimation with diurnal temperature with one of my colleagues, who is an expert on the topic.
• STM8 eForth compactness has made a step forward with the latest changes on the master (there is now a method for deciding how much of the dictionary to should be "ephemeral").
• IRDA data I/O is interesting in it's own right.

[sbridger]

@TG9541 I'm not sure how the STM32 adc goes.

I was wanting to achieve:

• Ultimately low total cost so large numbers can be deployed, and significant numbers of them lost.Crystal RTC doesn't seem to be really important to the data - time is not really an actual data value.
  -Totally sealed, with fully sealed comms method
• No sacrifice of absolute Temp accuracy, without calibration being required. (calibration happens in fact, as loggers should be checked for accuracy each year)
• Good battery / waterproofing life e.g. 5 years mean
• Possible to replace batteries and keep loggers running for 15 years
• Long project lifetime of 30 years possible i.e it should be possible to read and analyse them in 30 years time. To me this rules out hi-tech communications like BLE, which are dependent on a fragile and complicated stack, and very specific chipsets.
  This is another advantage of 4th, as changes to the usage can be made on sealed units , throughout the life.

[TG9541]

@sbridger: some challenges:

• any possibility to replace batteries complicates the problem (re-sealing)
• a wireless (e.g. optical) data transmission needs to work after the battery is empty - simplest would be data recovery after un-sealing
• retrieving data with an optical link will require some amount of energy - how to factor that in into expected life?

[sbridger]

@TG9541
At the moment my sealing plan is paraffin wax, which is very cheap and easy to rework.
I want to have normal operation not require unsealing, which is certain to be the most difficult, and the least reliable part of the thing. So a 5 year sealed life sounds good. Again 4th lets the program change, while they stay sealed.

Wireless transmission doesn't need much power, you can energise from the reader, I have several very simple (at the logger) schemes.

However optical over a range of 2.5mm really doesn't need much either. IRDA is based on 1.6us pulses for each 0. So 24kB@60% 0s = 200ms total on time for the led or 100nAh @2ma led current. Using a red led looks like a good choice at the moment, as I think that it is an asset for even the simplest device to have a visible go light.

More of an issue is that a CR2032 can only deliver a couple of mA before it loses energy to the internal R. Most BLE devices with tiny lithiums would be losing a lot, or most of the battery capacity by using too high currents. A decent storage cap, and pacing the data flow at low battery has a big effect on when it ceases to operate.

[TG9541]

It was good to keep this thread open because of the nice conversation, but there is finally support for the STM8L151 :-)