really tiny uP

technology.com:

something like this?

df

It's my understanding that GaN has a higher service temperature than silicon; the on-chip sensor wouldn't be measuring the GaN device directly, one hopes. Perhaps it'd be good for cold-junction compensation, though.

Computation could be as simple as a look-up table, if you can, for each four-bit V value, append a four-bit I value to make an address into a 256-entry table. Does that need a full uP?

I'd measure the device current and voltage and compute power dissipation and then estimate GaN junction temperature. That is improved if one also knows the base PCB temperature.

I've done that with big silicon mosfets. It results in much better use of expensive silicon and heat sinks than some dumb current limit.

A uP gets one a lot of resources for under a dollar. The idea is

Measure device voltage drop and current

Compute power dissipation

Lowpass filter and scale to estimate junction temp rise above base (base is measured PCB or heat sink temp, uP temp in my current case)

Add in base temperature to estimate Tj

Shut down if that's above some limit, 150C or so for GaN.

A little testing to destruction would help calibrate things.

--

John Larkin      Highland Technology, Inc 

The best designs are necessarily accidental.

Is milliseconds good enough for protection?

If so, you can go even cheaper than the STM32, with a STM8. That's below 20cents in small volumes

--
Klaus Kragelund

I do not think so. Looking at the graphs of the EPC2038, at 1 ms you have 30 times higher thermal condictivity. But even if still in ohmic regime, P = I * I * R will in only allow about 6 times higher current. In the us range, nearly 10^4 lower thermal impedance will allow 100 times higher current, in the first iteration.

--
Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de 

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt 
--------- Tel. 06151 1623569 ------- Fax. 06151 1623305 ---------

We'd probably run the measurements and the algorithm at about 1 KHz, but the thermal simulation would typically have a time constant more like 100 ms.

Below a dollar, cost isn't a big deal. But I'll look at the STM8. If we pick a small uP, we'd use it in multiple places, so a little horsepower could be handy.

If I'm going 8 bit 8 pin I prefer to pay a little more for a device with a modern development toolchain:

Also the cheapest ST8s don't have onboard ADCs. You get at least one differential over-the-rail ADC channel for e.g. high-side current sensing in the above.

Four single-ended 10 bit ADC channels total, but using all four precludes running off anything but the internal clock which tops out at

16 MHz I think.

I'd pick an AVR over an ST8 any day of the week - partly because they are the only 8-bit devices with a decent toolchain, partly because they are faster than most other 8-bit devices, and partly because of nice peripherals.

However, life is easier with a standard 32-bit core (ARM Cortex-M, or hopefully RISC-V in the future).

I don't know the ST32 family well, but I'm sure they are fine. Other interesting ones from the Kinetis family (NXP, formerly Freescale) include:

MKE04Z8VFK4 (it is 24 pin, but only 4x4 mm HVQFN24), which is 5V tolerant:

MKL03Z8VFG4 (16-pin 3x3 mm HUQFN16) and MKL02Z32CAF4 (20-pin 2x2 mm WLCSP20):

With more than 8 pins, you have more flexibility for other uses. And you can debug the devices sensibly on a board.

The STM8 I was referring to at the cost has ADC

Anyway, a Silabs EFM8BB1 is also very nice. Has 2 fast comparators if you can use those. Also cheaper than the STM32. On the other hand, the STM32 is fast, has nice specs, so you could use it for other products

STM32G07x are good, ARM M0+, good tool chain and support, 28 pin 4mm square QFN up to loads of pins in TQFP. Reasonable 12 bit fast ADC.

I'm working with these now.

TI have MSP430 series parts at under $0.3 in 1k numbers. Toolchain and support less good but cost and power consumption very good. We might use one as an interface processor in a sensor where we don't want critical analogue processing disturbed by asynchronous comms demands.

MK

We already use STM32F207IGT6, but it's a 176-pin, $10 part. Something tiny would be handy for doing simple stuff.

I've received some gripes about the software library, especially the ethernet, but they got it to work.

--

John Larkin      Highland Technology, Inc 

The best designs are necessarily accidental.

mandag den 4. januar 2021 kl. 16.55.42 UTC+1 skrev jla...@highlandsniptechn ology.com:

STM32G0xx is according to ST more like $0.5 and in much smaller packages

but you can still use the same development tools and debugger HW

Hmm, STM8 is supported by SDCC. No C++, but reasonable C. I did a silly benchmark compiling few codes (but not running them) and STM8 code is surprizingly small (looking at instruction set I expected horrible bloat), IIRC significantly smaller than GCC compiled code for Atmel processors. According to published bencharks both AVR cores and STM8 are rather slow, STM8 is probably slower, but not that much.

Concerning peripherials, STM8 peripherials are very similar to STM32 peripherials. For example in STM8S003F3 you get 2

16-bit counters/timers with 7 compare/capture channels in total plus 8-bit interrupt only counter. For me it looks better than ATmega328P timers (where only one is 16-bit). Of course, there are 8-bit quirks like need to read 16-bit registers by uninterrupted sequence of two operations. On paper this does not look worse than AVR quirks. ATmega328P has comparator, absent on STM8S003F3. I am not sure if ATtinys have comparator. AFAICS STM8S003F3 has on thermal sensor on the chip.

STM8 (at least STM8S003F3) seem to be designed for higher power level than most AVR chips. Also, STM8S003F3 officialy can not drive low-frequency crystal. Let me add that personaly I very much dislike AVR distincion between program memory and data memory, no such nonsense on STM8.

I am at beginer level with STM8, so my views may change with experience. Currently, for me ATmega328P has advantage of being bigger than STM8S003F3 (but when I need bigger I would rather go 32-bit). When small processor is good enough I like MSP430G2553, but it is more expensive than STM8.

--
                              Waldek Hebisch

Hi, John:-

1ms is fairly brief for an 8-bit processor to do much. You might want to have your guys benchmark the algorithm before settling on something (and if it takes more than 500usec I would upgrade). Especially may be an issue if there is much division or multiplication. Of course there are 8-bit processors with >50MHz clock these days.

I would be tempted to look at the 32-bit Cortex-M0+ core processors such as the ATSAMD10D13A, which is $0.49 in 100's in 24QFN. 12-bit ADC. Only 8K of flash but that may be enough.

Not for this application, but on the other end of the spectrum and still a bit light on flash for the horsepower, the STM32H7 series (Cortex-M7) has members with 128k of flash and a DP FPU that can run at 550MHz and cost < $5 in 100's.

Best regards, Spehro Pefhany

No, not "reasonable C" - merely "reasonable C given that you are running on a brain-dead 8-bit device". If you want to program an STM8 efficiently, you have to write code in "SDCC C for the STM8" rather than in C. The same applies to all these 8-bit CISC cores - and also to the AVR, though less so.

SDCC is an impressive tool, and the best choice for a lot of those 8-bit devices, but no sane software developer would choose an 8-bit CISC core with SDCC (or even expensive tools like IAR) over a 32-bit RISC core with gcc (or other good compiler).

(There are a few 16-bit cores still in existence, primarily the msp430, which are a middle ground.)

You would find that in practice, the AVR with gcc is likely to be a good deal faster. But you'll find a Cortex-M with the same clock speed to be faster still - and for arithmetic and calculations, it could easily be more than an order of magnitude faster at the same clock speed.

Who cares if a silly benchmark results in marginally shorter code on one of these 8-bit devices, if you can easily have many times more code space on a better device?

Now, there /are/ good reasons for picking an STM8, or an AVR, or a PIC, or an MSP430, over a Cortex-M microcontroller. I've seen PIC's

specified to 3.3 V running at 8 V. An STM8 can be cheaper than the bypass capacitors for a bigger microcontroller, and an AVR can be so low power it runs on fresh air.

But there is never any doubt that the software tools for 32-bit devices are better, and the 32-bit devices are vastly superior for calculations. If nothing else, it is a matter of fit for the language - C (in reality, though not by the language standards) requires 16-bit registers and ALU, it requires a data stack, it requires pointer+offset addressing, it requires an unlimited return stack, it requires a linear memory system. Chips like the STM8 have none of these, and they all have to be emulated by a mix of smart compiler and careful developer - that is never going to be as convenient, smooth and efficient as using a chip that handles C code naturally.

Peripherals and packaging are often the main deciding factors. The OP will need to decide himself on his needs there.

Well, you seem to make big deal of code speed and disregard code size. If device is too slow I would move to faster (probably

32-bit) device. So, the real question is which problem can be comfortably (without silly workarounds) run on small 8-bitters. Personaly I find that RAM is significant limitation, but that may be specific to my coding style and problems that I want to solve. The second limitation is code size, and most folks seem to be limited by this. Processor speed looks to me less important: usually it is fast enough.

Hmm, datasheet of STM8S003F3 says it needs two bypass capacitors, one at least 470 nF. Recommended bypassing for STM32F030F4 is also two capacitors, but smaller. So bypass capacitors for STM8S003F3 probably will be more expensive than for STM32F030F4 (which is definitely bigger microcontroller).

Have you actually used STM8? You write like you have first hand experience, but much of what you wrote contradicts what I know about STM8. In particular there is single linear address space with reasonable pointer+offset addressing. STM8 have (mis)-feature that IIUC on STM8S003F3 limits size of single stack to about half of available RAM. While not "unlimited", it does not look like very serious limitation. STM8 have essentially no general purpose registers. However, (two) index registers are 16-bit. Stack pointer covers whole RAM (logically it is 24-bit, but it looks that hardware implements only "needed" bits). Accumulator is 8-bit, but it is 8-bitter after all. AFAICS STM8 is intended to do most work on memory, which is less efficient than register machines. But I see nothing in the architecture that would go against HLL-s, in particular C.

--
                              Waldek Hebisch

Hi, Spehro,

This board has an isolated uP per channel, managing a 4-20 mA acquisition or control loop.

It's an NXP LPC1754 (32 bit M3) which we have a distributor program for us. The IRQ that runs the acquition and filtering and PID loop runs at 100 KHz, and we cranked the clock down to save power.

I'll probably stick with 32 bit parts in the future, since they are cheap.

It's impressive how much you can get done in a small uP if you program bare metal without a lot of bloat.

NXP is EOLing a lot of chips lately. We hope ST will be a little better.

--

John Larkin      Highland Technology, Inc 

The best designs are necessarily accidental.

I once used the Aztek c-compiler for Z80 for control and data collection for an incubation chamber. I experienced no restrictions with respect to c whatsoever.

Much can be hidden by a decent c-compiler. Isn't that what a high level language is for?

Groetjes Albert

--
This is the first day of the end of your life. 
It may not kill you, but it does make your weaker. 
If you can't beat them, too bad. 
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst