I've been thinking about Timo's inverter, and it looks as if a micro-controller that offered a 100MHz clock rate would be fast enough to do a decent job of switching the Siliconix Si3440DV DMOSFet that I fancy.
I've found a PIC part that's fast enough, and pretty cheap, but it is designed for digital signal processing, which makes it more complicated than necessary. A nice, dumb but quick 8051 would be good enough.
Somebody is apparently offers a 600MHz part, but I want something cheap and simple - if fairly fast (but not that fast). Browsing element-14 threw up a few candidates, but I didn't find their search engine all that helpful.
If you're thinking of the dsPIC uCs, they're basically PIC24s with a DSP engine added, same instruction set, just extra ones for the DSP. I don't think Microchip make a PIC24 which runs at 100MIPS like the newer dsPICs, probably no point.
So, just use a dsPIC and ignore the DSP part. Some of them at least have a very high resolution (up to 250ps) PWM, though I haven't used that. And how can they do a 32/16 divide in six cycles? Voodoo.
That depends on what you want the MCU to *do*. If you are just trying to implement a PWM in software, you could, instead, use an MCU with *hardware* for that purpose (even if the software had to tweek the duty cycle from one cycle to the next). If you want to be able to "talk" to it (i.e., to change it's current operating conditions), then you would have to decide bandwidth requirements for that channel.
Be advised that many newer devices operate, internally, at a variety of different clock rates. And, the relationship of activities happening in one part of the SoC to those in other parts isn't often clear-cut. E.g., you may be able to issue op-codes at a faster rate than you can issue "I/O" commands (like "toggle DIO #2 OFF"). And, as the I/O and "core" operate concurrently, the time when the DIO actually toggles is skewed wrt the instruction stream (you can't casually expect to observe the consequences of toggling it until you know the I/O command has actually made its way through to the pins!)
I'm currently exploring candidates for a PoE PD controller, moving all of the protocol into the MCU (trivial) as well as control over the converter (*nontrivial* as you have to consider the potential for the MCU to "crash" and apply 48VDC to your load!). Cost also being an issue as using a COTS PD controller and bolting-on the additional smarts represents a maximum cost metric against which to design (assuming the real estate constraints can be met)
The isn't even PWM. It's just got to produce two non-overlapping roughly 100kHz square waves.
The trick would be to look at the output of the inverter, and get the nominally 100kHz square wave to run exactly at the resonant frequency of the tank circuit (100kHz +/-17%), or very slightly slower.
Probably the easiest way to do that would be to sample the +/-2.5V output from a single turn wound onto the inverter transformer at 45, 135, 225 and 315 degrees. That's sampling at at up to to 468kHz, and the dsPIC33EP parts can do 12 bits at 500kHz.
If the frequency is just below resonance the 45 degree sample is going to be just bigger than 135 degree sample, and the 225 degree sample just lower than the 315 degree sample.
The device wouldn't be doing very much, so that probably wouldn't be a problem.
Your biggest problem right now is finding a part that you can actually buy. In normal times I'd have suggested an STM32Fxxxx part, there are chips with multiple ADCs capable of > 2MHz sampling rates in small packages - but the trick will be finding stock. If you just want a cheapo development board then one of the Nucleo boards from ST will do you nicely. Farnell have 924 of the Nucleo F429ZI in stock (but no chips until 2022) It's overkill for your job perhaps - but might be the best way to start work. If you just want to do it on paper I'd suggest you need to pick a processor with at least 2 ADCs capable of the rate you need. You need a fast clock to have fine enough control over the pulse generator frequency. That's the easy route but perhaps not the most cost effective if you care about production in volume.
It would be tempting to try an STM32G071 - Cortex M0 core, 64MHz, very cheap, tiny packages which would (maybe) be just capable but make a really nice (small and cheap) controller. Problem is finding any in less than 6 months.
I've been eying the STM32F730R8T6 -- a reasonably small package, a bit pricey (almost $3 at 10K) and WAY overkill. But, I like some of the features that can help "lock" the hardware into a particular configuration that, hopefully, keeps the circuit "safe".
I've not yet reviewed the security provisions, etc. (but the CPU is overkill for my needs)
Samples (from a good contact) *or* buy a prebuilt "module" and, use as is, or disassemble to salvage the components.
Or, find someone who's using it already (again, a friendly rep can leak the name of other customers to approach).
An FPGA can be used to implement an 8051 or any other MCU architecture you wish at 100 MHz without much trouble. Then you can tailor the peripherals as you choose. Gowin has parts for $3 or less with internal Flash.
And the Microchip dsPIC33EPxxxSP50X will do the job for for $3, and throws in a PPL that will multiply up a 7MHz clock to 100MHz as well as an A/D converter that I can use.
The aim is to get a single chip processor that is cheaper and simpler of the shelf.
Another one worth considering (maybe not for your job) is the STM32H750xB - cheapest way I know to get three 16 bit ADCs (3.6MHz sampling rate). Core runs at 480MHz, 1M ram, 128k flash. The LQFP part (100pin) is £5.76 (100 off Farnell) - no stock of course but some due in time for Christmas. You might need to go for one of the BGA packages to get access to enough pins to use all the features you need.
Look back a few weeks in SED for thread "Low noise high bias voltage ..." - basically a call for ideas on a low noise high voltage low power inverter.
Bill Sloman is now exploring using very fast mcus to generate square wave drive for the current fed center tap push-pull converter he is fascinated with.
Single chip is not synonymous with simple. "Cheap" is relative and you haven't really looked at the total price. For example you seem to think supplying a 7 MHz clock and using a PLL to the MCU is somehow cheaper than the same process with an FPGA. The clock is not an expensive part by any means. Likewise, a one input ADC is not an expensive part either.
So you are not looking for cheap as much as "cheapest possible". I hope you can get the timing to work with a single instruction stream processor. With the sort of timing requirements your design seems to need it can be tricky to make a sequential processor responsive enough.
An FPGA, on the other hand, will do the job with very high resolution and not break a sweat... or more accurately, the programmer won't break a sweat. You won't be limited to 100 MHz as the internal PLLs and the logic in FPGAs often work at much higher frequencies, even the low power devices. This project in an FPGA is a slam dunk with probably the shortest development time and smallest risk.
So it would appear you asked for "simple" but really want minimum price.
Sigma-delta converters are often the choice for FPGAs, but successive approximation is easily done as well. The hard part is the DAC output you need. You can get 0.1% resistors for an R-2R ladder without too high a price. It's not clear if that would be adequate or not. The I/O supplies on each bank of FPGA I/Os are separate, so noise from the FPGA internals is minimal.
I seem to recall a 100 MHz 8051 created some years ago with the same idea as the propeller that peripherals can be implemented in software. Anyone remember that?
There's also the various Cypress PSOC lines with an emphasis on low cost by trading off fixed peripherals for programmable analog and logic. The processor may not run at 100 MHz, but if you can off load some of the heavy lifting to the programmable portions maybe the lower clock rate is good enough.
Obviously not. Back when I was working with electron beam microfabicators, the floor plan of a single layer of single chip could be as complex as the street map of New York. Minimum features sizes have gone down quite a bit since then.
Actually the Microchip dsPIC33EPxxxSP50X does seem to have an internal RC oscillator, which would probably be good enough for what I need to do. The circuit has to drive the resonant tank at (or just below) it's resonant frequency and the control loop could also cope with drift in the internal oscillator frequency.
Clearly.
I'm actually looking for "simple" and it looks as if the Microchip part would cost about as much as the Si3440DV MOSFet switches, which is cheap enough.
Not in this application.
I don't need a DAC at all. All the micro-controller would do would change the period of the square wave-drive to keep it at (or just below) the resonant frequency of the tank circuit
I do know about 0.1% resistors. I've specified lots of them. This isn't an application that seems to need them
A 100MHz 8051 would do exactly what I need. At one point I spent a couple of weeks learning about 8051 assembler - it's a pretty rudimentary processor, but does everything I'd need
The idea is is to get two roughly 100kHz square waves. With a 100MHz clock, that's a 10-bit counter. Since there is +/17% tolerance on that 100kHz resonant frequency, you might need 11-bits to cope with the worst case. You then have tweak that "100kHz" to fit the tank circuit you've got, and keep tweaking it track the actual resonant frequecy as it cahnges withb load and room temperature. It's not rocket science.
The trouble is this has become a bit of the X/Y problem. You ask for X when you are really trying to do Y. "Simple" has no definition, so you can't really expect to get good advice.
I guess you aren't following the ideas. To implement a successive approximation ADC you need a DAC. You set the msb to the DAC and if the comparator indicates the DAC output is greater than the ADC input, you back off that bit and set the next lesser bit. lather, rinse, repeat. With an adequately fast DAC you can get MHz sample rates. This is what they are most likely using in the MCUs at 500 kSPS and 12 bits.
Yeah, as I said, you aren't following the concepts.
Yes, I'm sure it's not, but what you describe does not explain how you get from ±17% to 11 bits of resolution on a 100 kHz output counter. If you want to explain enough for others to understand, fine. If not, that's fine too.
But as I have said very clearly, this is all a slam dunk in an FPGA unless there are parts to the design you aren't explaining. That's what I think of when someone asks for "simple", something that is easy and straight forward to implement.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.