Microcontroller Development Advise

[eugene]

If it's hard for you to do all 8 channels from one MCU, you can have 8 very small MCUs each controlling a single FET driver. These small MCUs then can be controlled from a master MCU.

This is a technique that I think has yet to become fully appreciated, (except perhaps by the automotive industry.) I recently needed to coordinate 10 BLDC motors. Obviously, there are no MCUs with 30 PWM channels, so I went all-in with the objected oriented hardware and ended up with 16 individual MCUs, each with their own well defined job to do. It ended up being easier to implement than trying to get a quad core processor to do everything.

So yeah, I still don't understand the OP's application well enough, but I would consider a separate ATtiny for each FET as a possible solution. They're cheap and easy to get working on a breadboard before designing into a full system. And, if part of your goal is to learn about MCUs, there is no easier place than 8 bit AVRs

[PCB.Wiz]

.... I recently needed to coordinate 10 BLDC motors. Obviously, there are no MCUs with 30 PWM channels, so I went all-in with the objected oriented hardware and ended up with 16 individual MCUs, each with their own well defined job to do. It ended up being easier to implement than trying to get a quad core processor to do everything.

I'd agree it is easier to have local focused hardware, especially if each also has gate drivers and high power associated outputs.

That said, there actually are even 8 bit MCUs with 30 or more PWM channels   

The STC STC8G2K64S4 series have 45 channels of 15b PWM, and the SinOne SC95FW40 has 40 channels of 12b PWM - maybe drones with many motors is the market here ?

More common is 8 channels of PWM.

[mawyatt]

So this may be best as two modules ?

You could start with common character LCD modules cheap, and available in larger glass models for better distance reading.
one example  https://www.aliexpress.com/w/wholesale-large-character-LCD-i2c.html
Then you can decide if you need to add more time/effort/cost to a fancier display
example https://www.aliexpress.com/item/1005005297304786.html



That's starting to sound like a programmable waveform generator, which could need a MCU with a bit more RAM.

I'd start with that you already know, and try multiple paths.
Find which is easiest to get working.

The RPi may be to unwieldly, but the Pi-Pico + python might be quick enough.
A generic Ardunio may be 'good enough' ?

or, you might like to try to get your hands on the new Arduino UNO R4  using 5V Renesas RA4M1 (Arm Cortex®-M4)
5V is good for gate driving power MOSFETS

We aren't quite as naive as we indicated regarding the RPi and controlling things. Our last major project was a precision ~15 bit accurate 128 independent channel (expandable) AWG that produced up to +-100V independent outputs. Each channel needed to be Bi-phase modulated and the waveform "average" after modulation needed to be with a few millivolts of 0 on a cycle by cycle basis. All created and controlled from a RPi (developed on RPi 400 and also used with a Pi Zero) with mostly SPI and Python.

The application was highly proprietary, even for us, as we didn't get to attend the first demo of the overall system. We were just given some challenging specs, which were attained first pass, later to be developed into a custom chip set, which apparently Covid has postponed. We had gleaned from discussions which we can disclose, this was the steering controller for a new technology dynamically configurable electronic controlled rapid XY beam steering Phase Array antenna system in MMW based upon Liquid Crystal Technology. Results we got back from 1st test was everything was hooked up according to our documents, powered up, and a beam position command was entered and the narrow MMW beam immediately went to the precise position as commanded. After this initial test, everything went dark as we suspect the use may be sensitive and we have not been asked any questions or been made aware of any problems. This is a tribute to the folks behind this "System" as they are pretty darn good at what they do, and provided the proper specs we needed, but nothing more, so sometimes no news is good news 

Anyway, thanks for the information

Best

[mawyatt]

So yeah, I still don't understand the OP's application well enough, but I would consider a separate ATtiny for each FET as a possible solution. They're cheap and easy to get working on a breadboard before designing into a full system. And, if part of your goal is to learn about MCUs, there is no easier place than 8 bit AVRs

This is certainly a possibility, especially for the system that's requiring pulse shaping by means of PWM. We don't need to worry about the output level as 5V pulses are insufficient to drive the output MOS device, which are multiple balanced ~100A PMOS devices for each of the 8 phases. The gate drive will be upscaled to 0 to +12V, to fully enable the PMOS device channel.

The timing of the pulses is such that each "phase" of the 8 sequential pulses will require identical PWM waveforms, altho time displaced by the overall pulse-width. One idea we were considering in having a single PWM channel create the PWM waveforms, repeated at each time displaced phase, and have each of the 8 phase channels just act as a pulse enable signal to the high current load driver.

Anyway, thanks for the ideas

Best,

[NorthGuy]

The gate drive will be upscaled to 0 to +12V, to fully enable the PMOS device channel.

PMOS would require negative voltage to turn on the FET.

[mawyatt]

The gate drive will be upscaled to 0 to +12V, to fully enable the PMOS device channel.

PMOS would require negative voltage to turn on the FET.

They are arranged as Drain drivers with the Source at +12V, and the Drain drives the Load which has a common ground. So the Gate is driven from +12V to zero to turn ON the PMOS.

[nctnico]

That must be a special MOSFET then. Most MOSFETS have an optimum Vgs between 4V to 9V where the gate charge versus Rdson is minimal and thus switching speed is highest.

[mawyatt]

Switching speed isn't that important, Rdson is

[NorthGuy]

They are arranged as Drain drivers with the Source at +12V, and the Drain drives the Load which has a common ground. So the Gate is driven from +12V to zero to turn ON the PMOS.

So, you have 12V 100A. How big are your inductors?

[mawyatt]

No, the PMOS are >100 amp pulse rated, and must be significantly derated on long pulses or continuous use. Please study up on how power MOS FETs are used and specified. Quite misleading specifications often cause issues with designs that don't take the transient, including power, current and thermal effects into account.

Best,

[NorthGuy]

No, the PMOS are >100 amp pulse rated, and must be significantly derated on long pulses or continuous use. Please study up on how power MOS FETs are used and specified. Quite misleading specifications often cause issues with designs that don't take the transient, including power, current and thermal effects into account.

You're speaking as if you gave us the datasheet to look at. But you keep everybody in the dark ...

To select an MCU, you start by figuring voltages, currents, size of the inductors you switch etc. Then you use this information to calculate rise and fall times. This, in turn, will tell you how accurate your pulses may be. Say, if your rise time is 10 us, this is very long time for a slow MCU, and you can write a sloppy program in C to bit-bang everything sequentially and don't worry about accuracy. Or, if rise/fall times are fast you can place your pulses more accurately (if you need to). Or, if your inductors never saturate then you can use PWM to control inductor's current. These are all different approaches.

[mawyatt]

No, the PMOS are >100 amp pulse rated, and must be significantly derated on long pulses or continuous use. Please study up on how power MOS FETs are used and specified. Quite misleading specifications often cause issues with designs that don't take the transient, including power, current and thermal effects into account.

You're speaking as if you gave us the datasheet to look at. But you keep everybody in the dark ...

To select an MCU, you start by figuring voltages, currents, size of the inductors you switch etc. Then you use this information to calculate rise and fall times. This, in turn, will tell you how accurate your pulses may be. Say, if your rise time is 10 us, this is very long time for a slow MCU, and you can write a sloppy program in C to bit-bang everything sequentially and don't worry about accuracy. Or, if rise/fall times are fast you can place your pulses more accurately (if you need to). Or, if your inductors never saturate then you can use PWM to control inductor's current. These are all different approaches.

Nobody's in the dark except maybe you!! We don't need advice on inductive power switching design nor power MOS FET selection, quite well versed thank you!! And never asked for such, only about microcontroller selection which just needs to generate the basic low frequency pulses we've outlined in the 1st post. BTW the PMOS device we are considering is a AP120P30.

You need to read what we've posted earlier, please do so!! The PWM is for an advanced Premium version not completely specified yet, not the one we've been discussing!! Here's a quote from what we said earlier, note the highlighted text!!

Later planned is having a multi-level final pulse for each phase where a high voltage and current is forced into the inductive loads, then quickly tapering off and decaying to a much lower holding level holding current, thus keeping the load and driver dissipation down. The timing of these multi-levels is yet to be determined, but the overall pulse-width and rep rate are roughly the same as previously mentioned. So each of the 8 pulse lines may need to be PWM to achieve the desired driver waveform decaying feature. As of now the concept involves creating the desired waveform in the HV and HC driver with PWM on each of the 8 pulse lines, with a shorter initial pulse, then a couple additional narrow pulses to create the holding current effect. We don't know enough about the various "loads" yet to have a good picture of what this waveform needs to be, and may need to be selectable for specific "loads". However, this is a much higher end System that will be at a Premium, and require another custom PCB and supporting components.

The likely voltage for these loads will be ~90V not 12V, adaptable, and as mentioned the waveform detailed characteristics & shape are mostly unknown at this time for this Premium System. This system will require a completely different controlling scheme (both NMOS & PMOS switching devices), faster pulses with PWM, different Power MOS devices likely a different microcontroller.

So please lets stay with the initial system originally described, it's requirements, and focus on the microcontroller, which is where we need some quidance! We'll have plenty of time to discuss the advanced Premium System at some later date as the requirements materialize and we finalize the initial system to free up time for the Premium System design, hopefully by then we'll a little more proficient in microcontrollers

Best,

[NorthGuy]

So please lets stay with the initial system originally described, it's requirements, and focus on the microcontroller, which is where we need some quidance!

Any MCU, given enough pins, can do what you have described in your first post. It seems you have a good understanding of what you need to do. What sort of guidance do you need?

[PCB.Wiz]

So please lets stay with the initial system originally described, it's requirements, and focus on the microcontroller, which is where we need some quidance!

What we need the microcontroller to do is create a set of 8 sequential non-overlapping pulses of varying width (0.5 to 5ms), at a rate of ~4Hz to ~80Hz selectable. Another output is a selectable timer from ~60sec to ~1800sec. Everything is ~6 bit resolution, except the analog input at ~8bit resolution.
With a pulse train like that, you may be better to define to edge toggle times, and have small slaves you send a pulse-set to, and then trigger.
If that becomes firmly defined, that pulse set can go into code FLASH.

You may be able to scale this, to fit into the common 16 bits timer size
eg if you need 0.5ms to 6 bits, that 10us LSB can define to 0.655 seconds

AVR's have  timer prescalers with fairly coarse choices, but that may be  'good enough'.
The 8051 families have a PCA with a HSO mode, which toggles a pin on a match setpoint, and finer prescaler choices.
The SiLabs EFM8BB5x series have 50MHz sysclks, which gives good headroom.
The BB52 has 3 PCA channels, but you can shift them along the pins, so if your pulses never overlap, you can have more pulsing pins.

If you need precision PWM, the STC8H family have 8 x 16b PWM's with a nice fine 16b /N prescaler and TSSOP20/TQFP32 packages

Some 8b MCU's are getting > 100MHz PWMs, but you are not quite pushing that territory.
Maybe get some low cost eval boards, and try creating some example pulse trains.

If I was coding an experimental/flexible pin pulse generator, I might pick a EFM8BB52, and allocate 4 bytes per edge : The lower 2 are HW timer match, 3rd byte is SW timer match, and upper byte is pin select + toggle enable + spares.
Pulses longer than 2^16 would need some packer values, ie time stamps without toggles, as HW simply left alone will toggle once every 2^16.
Software updates times place a rule on shortest possible pulse, something less than maybe 100 sysclks would need care, ~2us tho more HW via CLU logic or external XOR could drop to 1 sysclk.

A RPi or any host could generate and send those pulse records and then trigger the MCU's on a trigger pin.

You did not explicitly state the edge precision and total number of edges, or the total timing precision (on chip OSC or external OSC) ?

[Siwastaja]

Jitter was not specified but assuming it's not critical, the frequencies sound low enough that I would just pick any random Cortex-M microcontroller and implement the whole generation logic in a periodic timer interrupt handler and run the UI in main loop.

[larsdenmark]

While it is not too difficult to obtain the pulse widths you're looking and driving a LCD display it is easy to screw things up when both have to be carried out unless you have more than one core.

RPi Pico and ESP32 have two cores and should require the same amount of coding to get everything going. Rpi Pico (RP2040) has programmable IO (PIO) that can be used for extremely fast and/or precise timing for the pulses (but PIO is not entry level stuff). Both can be programmed using Arduino libraries.

Running on some memory limited, single core Arduino processor doesn't make any sense for the number of devices you are talking about.

Being familiar with RPi is a plus when programming the first system, but you'll have a hard time purchasing them in the hundreds.

[mawyatt]

Any MCU, given enough pins, can do what you have described in your first post. It seems you have a good understanding of what you need to do. What sort of guidance do you need?

Mainly in a development platform and specific microcontroller(s) that are easy for a someone relatively new to the microcontrollers to get up and running that can produce the simple pulse scheme described.

Best,

[mawyatt]

To address some additional information on the pulse requirements, this is for the initial system, and NOT the Premium System which will employ PWM for waveform tailoring at a later timeframe.

The pulses are not critical at all, could be ~5% without issue, even have a little overlap, and many microseconds of jitter. The 8 pulses are all the same tho, just displaced in time, and should match within ~1%, i.e. pulse 1 should be the same as pulse 2 or 8, or 5, or any other pulse and pulse-width match within 1%, the pulse-width can vary ~5% without issue, as can the repetition rate vary by ~5% without issue.

In fact we have a test PCB that's going to be utilized to further understand and model the various loads, some unknown at this time, and this is just a single channel based upon a couple 555 timers with pots to set the pulse-width and repetition rate. Will also include the high current load driver to evaluate various PMOS devices under various loads.

Anyway, thanks folks for the valuable responses and information

Best,

[Siwastaja]

Many microseconds of jitter -> ISR & GPIO approach is more than fine. Pretty easy, just increment a counter and turn inputs on/off based on the counter value; sounds like it could even cater the "premium" PWM version. You can easily have a 10kHz periodic interrupt on a simple AVR, or a 100kHz interrupt on a higher-end 32-bit MCU.

Arduino ecosystem would soften the initial hit as you could just buy a display "shield" and start working with things like lcd.display("Hello World"); with the display library which would work out of the box.

[NorthGuy]

Mainly in a development platform and specific microcontroller(s) that are easy for a someone relatively new to the microcontrollers to get up and running that can produce the simple pulse scheme described.

For a project like yours, I don't think there is any significant difference between different MCUs. The development platform is provided by MCU's manufacturer. It consists of IDE and development tools (C compiler, linker). You'll also need a programmer, which may also be a debugger, although I don't think you'd need a debugger for such a simple project. Your development process will be roughly the same - you'll write C code and run it on your MCU.

[nctnico]

For writing code you'll need clear documentation and a microcontroller that works as described. In this alone differences are huge between manufacturers. Pile manufacturer supplied libraries on top and you can be hunting documentation / reality discrepancies for days.

I agree with Siwastaja here. A much better option for the OP is to look for something similar that already exists (and works well) as an Arduino project and start from there IF the goal is to actually finish the project within a reasonable timeframe. Depending on the OP's ability to spot the difference between bad/good code examples quickly, using existing software can help to save time.

At some point the timer control could be programmed directly if/when more control over the hardware is needed. But this will be a small, incremental step.

Another question is: how much can be re-used to make the second, premium version of this device? Does it need fancy graphics on the display or is it just more timer features?

My initial impression for this project was that it would need a GUI / display with fancy graphics to give it some appeal (wow factor) to the bean counters in order to get it over the counter. But that doesn't seem to be the case.

[sokoloff]

My initial impression for this project was that it would need a GUI / display with fancy graphics to give it some appeal (wow factor) to the bean counters in order to get it over the counter. But that doesn't seem to be the case.

That insightful comment gives me an idea:

Have you considered using a tablet (Android or iPad) or laptop, running a web browser, and talking to the prototype device over http over WiFi?

Serve that up from an ESP32 and you have a cheap/easy system to at least demo and can build whatever interface you want during development.

(Again, this is all spitballing without deep insight into the unstated product requirements.)

I have an ESP8266 connected to my old boiler and I just now opened up a port on my firewall to NAT that page out to the internet.
http://73.126.96.83:55555/

That page is not designed to be pretty, but you could certainly make a pretty one.

[PCB.Wiz]

To address some additional information on the pulse requirements, this is for the initial system, and NOT the Premium System which will employ PWM for waveform tailoring at a later timeframe.

The pulses are not critical at all, could be ~5% without issue, even have a little overlap, and many microseconds of jitter. The 8 pulses are all the same tho, just displaced in time, and should match within ~1%, i.e. pulse 1 should be the same as pulse 2 or 8, or 5, or any other pulse and pulse-width match within 1%, the pulse-width can vary ~5% without issue, as can the repetition rate vary by ~5% without issue.

That's quite relaxed, you might be able to even use the RPi for that, for initial testing
Google finds this
https://forums.raspberrypi.com//viewtopic.php?f=72&t=67741#p496306
which configures a PWM and says
You can't really get a regular gap, you seem to get at least 150 microseconds between pulses whatever you do.


Google also finds this for RPi

I also did some experimenting with the allowable range of values for pwmSetClock() and pwmSetRange(). As noted in one of the other answers, the valid range for pwmSetClock() seems to go from 2 to 4095, while the valid range for pwmSetRange() is up to 4096 (I didn't attempt to find a lower-limit).
The Raspberry Pi PWM clock has a base frequency of 19.2 MHz.

So it looks like 12 bit prescaler and 12 bit compare fields, with some ability to further change the default 19.2MHz.  ie Quite basic, but could be 'good enough'.


The PiPico may be better - tho this is still a more complex production solution than a 8 it MCU, it is easy to play around with.
Pi Pico HW PWM :   Duty cycle resolution 16 bits PWM Clock 125MHz
Prescaler 8.4 so up to 256,  so longest timebase 125M/2^16/256 = 7.45Hz

or there is the PIO state engine, if you dig that deep.

Addit : for the specs of  create a set of 8 sequential non-overlapping pulses one simplification you can apply here, to almost any solution, is to add a 74HC138/74HC238 as that avoids the need to re-map peripherals to pins.
You simply increment the MUX and have a single pin generating the pulse train.

[PCB.Wiz]

Mainly in a development platform and specific microcontroller(s) that are easy for a someone relatively new to the microcontrollers to get up and running that can produce the simple pulse scheme described.

Already mentioned are AVR and 8051 cored parts, which are well under $1 and able to manage this easily.

Low cost eval boards exist for both - SiLabs EFM8BB52
https://www.digikey.com/en/products/detail/silicon-labs/BB52-EK2701A/15276600

and new AVRs, with DEBUG on board
https://www.digikey.com/en/products/detail/microchip-technology/DM164151/12177481
https://www.digikey.com/en/products/detail/microchip-technology/EV35L43A/13174972

or, if you are ok with Chinese, STC have a wide range 
https://ec-buying.aliexpress.com/store/1762106/search?SearchText=STC

[tggzzz]

When using the RPi and equivalent computers for hard real time systems, you have to ensure the worst case performance matches your needs. Such computers have many optimisations to increase the average performance.

That raises an obvious question how do you know what the worst case performance actually is? If the principal timings are guaranteed by hardware (e.g. timers), then you still have to verify the software responds to inputs sufficiently fast and to verify the software is fast enough to generate all the outputs. The design tools provide zero help with this, since they cannot determine the effects of all the different types of cache misses.

The only way is by measurement, and hoping that you have captured the worst case performance. While that may be acceptable in some circumstances, it is unsatisfying.

If you are running a fully-fledged operating system such as linux, then the effects of that have to be assessed and measured.

Personally for hard real time operation I prefer having a very simple processor with "poor" but repeatable performance. Preferably it run on bare silicon without an OS, but an RTOS may be beneficial.

Ideally the IDE should inspect the compiled code to determine the min/max timings, and the equivalent of an RTOS should be implemented in hardware. Such (single source) systems do exist, and can be bought at DigiKey.