Fast simple microcontroller

On Friday, July 2, 2021 at 11:40:49 PM UTC+10, Don Y wrote:
> On 7/2/2021 6:32 AM, Chris Jones wrote: 
> > On 02/07/2021 22:56, Anthony William Sloman wrote: 
> >> On Friday, July 2, 2021 at 9:13:58 PM UTC+10, Don Y wrote: 
> >>> On 7/1/2021 10:33 PM, Anthony William Sloman wrote: 
> >>>> 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. 
> >>>> 
> >>>> Has anybody got a favourite part? 
> >> 
> >>> 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. 
> >> 
> >> 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.
>
> I suspect you could (?) lower the bandwidth requirement by sampling, 
> instead, at 45, 495 (360+135), 945 (720+225), etc. -- assuming the system 
> is stable over short time periods.

Of course you could. The resonant frequency is going to drift around a bit as the transformer core and the tank capacitor warm up, but that's going to be slow.

> >> 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. 
> >> 
> >>> Be advised that many newer devices operate, internally, at a variety of 
> >>> different clock rates. 
> >> 
> >> The device wouldn't be doing very much, so that probably wouldn't be a problem.
>
> It's not how much it is doing as much as WHEN it is doing things. 
> There is an invisible skew between the instruction sequence and 
> the I/Os. I.e., "doing something" and then "checking the result" 
> can end up having the "check result" executing before the "doing 
> something" has actually made it out onto the pins.

Not in this application. There's nothing "invisible" about the delay from the core to the peripherals - it should be detailed in the data sheet. I've worked with fast logic for quite long enough (some fifty years now - though some of the early stuff wasn't all that fast) to be conscious of the need to pay attention to that sort of delay.

> > You'd probably be better off with a small cheap fpga. Some of them work with open-source software now.
>
> +1 

Wrong. Micro-controllers come with bits that I'd have to provide as well as the fpga. There are situations where an fpga  would makes  sense, but this isn't looking like one of them.

> There are several MCU's that can meet the RT needs. But, you also have 
> to consider the possibility of the processor crashing or getting into a 
> loop that ignores some key feedback signal. 

Watchdog timer to force a reset?
 
> [There are MCUs that have some measures to minimize the ability of 
> a CPU crash screwing up "controls" -- one just has to hope they 
> REALLY work! :-/ ] 
> 
> You might be able to kludge an error signal (over volt, over current, etc.) 
> onto the RESET pin and hope the processor doesn't misbehave entering 
> RESET.

It's a pretty simple application. Like I said, the processor doesn't have to do much at all.

-- 
Bill Sloman, Sydney

On 02/07/2021 07.33, Anthony William Sloman wrote:
> 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 have been a little absent from SED the last couple of months, got a 
consulting gig in parallel with my day job

Can you post a link to the Timo inverter?

Cheers

Klaus

fredag den 2. juli 2021 kl. 16.42.29 UTC+2 skrev bill....@ieee.org:
> On Friday, July 2, 2021 at 11:32:12 PM UTC+10, Chris Jones wrote: 
> > On 02/07/2021 22:56, Anthony William Sloman wrote: 
> > > On Friday, July 2, 2021 at 9:13:58 PM UTC+10, Don Y wrote: 
> > >> On 7/1/2021 10:33 PM, Anthony William Sloman wrote: 
> > >>> 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. 
> > >>> 
> > >>> Has anybody got a favourite part? 
> > > 
> > >> 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. 
> > > 
> > > 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. 
> > > 
> > >> Be advised that many newer devices operate, internally, at a variety of different clock rates. 
> > > 
> > > The device wouldn't be doing very much, so that probably wouldn't be a problem. 
> > > 
> > You'd probably be better off with a small cheap fpga. Some of them work 
> > with open-source software now.
> But I wouldn't get the A/D converter thrown in, and I'd have to make my own 100MHz clock. I've been fond of programmable devices for a long time now - my 1996 paper used the (fairly rudimentrary) ICT PA7024 - but in this application a micro-controller would provide a lot of bang for very few bucks. 
> 

why do you need an A/D? can't just time the zero crossing? why 100Mhz?

that said, it is trivial to setup a complementary squarewave with dead time on an STM32 and trigger the ADC at specific points with the same timer. You can get a board for a few dollars (though maybe not at the moment) 

On 02/07/2021 13:56, Anthony William Sloman wrote:
> On Friday, July 2, 2021 at 9:13:58 PM UTC+10, Don Y wrote:
>> On 7/1/2021 10:33 PM, Anthony William Sloman wrote:
>>> 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.
>>>
>>> Has anybody got a favourite part?
> 
>> 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.
> 
> 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.
> 
>> Be advised that many newer devices operate, internally, at a variety of  different clock rates.
> 
> 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.

MK

On Saturday, July 3, 2021 at 1:50:57 AM UTC+10, lang...@fonz.dk wrote:
> fredag den 2. juli 2021 kl. 16.42.29 UTC+2 skrev bill....@ieee.org: 
> > On Friday, July 2, 2021 at 11:32:12 PM UTC+10, Chris Jones wrote: 
> > > On 02/07/2021 22:56, Anthony William Sloman wrote: 
> > > > On Friday, July 2, 2021 at 9:13:58 PM UTC+10, Don Y wrote: 
> > > >> On 7/1/2021 10:33 PM, Anthony William Sloman wrote: 
> > > >>> 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. 
> > > >>> 
> > > >>> Has anybody got a favourite part? 
> > > > 
> > > >> 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. 
> > > > 
> > > > 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. 
> > > > 
> > > >> Be advised that many newer devices operate, internally, at a variety of different clock rates. 
> > > > 
> > > > The device wouldn't be doing very much, so that probably wouldn't be a problem. 
> > > > 
> > > You'd probably be better off with a small cheap fpga. Some of them work 
> > > with open-source software now. 
>
> > But I wouldn't get the A/D converter thrown in, and I'd have to make my own 100MHz clock. I've been fond of programmable devices for a long time now - my 1996 paper used the (fairly rudimentrary) ICT PA7024 - but in this application a micro-controller would provide a lot of bang for very few bucks. 
> >
> why do you need an A/D? can't just time the zero crossing? Why 100MHz? 

The 100MHz comes from the fact that the  Siliconix Si3440DV DMOSFet that I fancy has a maximum turn-on time of 15nsec and maxim off-time of 30nsec (if you can find half an amp of gate drive current to get the 8uC gate charge in and out) so 100MHz is fast enough for a pair of decent non-overlapping drive waveform, and with a 100MHz master clock you can fiddle the frequency around 100kHz in pretty small steps. You don't need to get it perfect.

Timing the zero-crossings wouldn't be helpful - if resonant tank is driven (in this application) at less than the resonant frequency you get a short period where nothing happens, so there might be a few more zero-crossings than you'd like. If the micro-controller has an A/D anyway, digitising a fraction of of the voltage across the tank circuit could let you look at the voltages where they were better behaved.  There are other ways of doing it, but they all seem to need more components.
 
> that said, it is trivial to setup a complementary squarewave with dead time on an STM32 and trigger the ADC at specific points with the same timer. You can get a board for a few dollars (though maybe not at the moment).

The board is supposed to take in 24V and spit out +/200V. It's got two wound inductors on it. The board that came with STM32 on it wouldn't have that and  would probably have a lot of less than useful bells and whistles. It's is supposed to electromagnetically quiet, and micro-processor boards aren't good for that.

-- 
Bill Sloman, Sydney

On 7/2/2021 8:02 AM, Anthony William Sloman wrote:
>> I suspect you could (?) lower the bandwidth requirement by sampling, 
>> instead, at 45, 495 (360+135), 945 (720+225), etc. -- assuming the system 
>> is stable over short time periods.
> 
> Of course you could. The resonant frequency is going to drift around a bit
> as the transformer core and the tank capacitor warm up, but that's going to
> be slow.
> 
>>>> 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.
>>>> 
>>>>> Be advised that many newer devices operate, internally, at a variety
>>>>> of different clock rates.
>>>> 
>>>> The device wouldn't be doing very much, so that probably wouldn't be a
>>>> problem.
>> 
>> It's not how much it is doing as much as WHEN it is doing things. There is
>> an invisible skew between the instruction sequence and the I/Os. I.e.,
>> "doing something" and then "checking the result" can end up having the
>> "check result" executing before the "doing something" has actually made it
>> out onto the pins.
> 
> Not in this application. There's nothing "invisible" about the delay from
> the core to the peripherals - it should be detailed in the data sheet. I've
> worked with fast logic for quite long enough (some fifty years now - though
> some of the early stuff wasn't all that fast) to be conscious of the need to
> pay attention to that sort of delay.

It's documented, but the architecture of (esp ARMs) isn't as simple/clean
as older processors.  The I/O subsystem and processor operate independently
of each other -- different clocks, etc.  So, one needs to insert R/W barriers
if you want to ensure the two are back in sync at any point in time.

>>> You'd probably be better off with a small cheap fpga. Some of them work
>>> with open-source software now.
>> 
>> +1
> 
> Wrong. Micro-controllers come with bits that I'd have to provide as well as
> the fpga. There are situations where an fpga  would makes  sense, but this
> isn't looking like one of them.

You've described two ~100KHz (nominal) oscillators with some fixed
phase relationship.  Varying frequency and duty cycle are easy to do
in an FPGA.  Similarly, sampling a feedback signal from the transformer
and bumping the frequency up/down, accordingly, is easily accomplished
with a state machine.

If there are other things that need to be handled, you've not indicated
what they are.

>> There are several MCU's that can meet the RT needs. But, you also have to
>> consider the possibility of the processor crashing or getting into a loop
>> that ignores some key feedback signal.
> 
> Watchdog timer to force a reset?

If the MCU is wedged, then what's to stop the WD from triggering again?
And, the controls just looping in a broken state, endlessly?

>> [There are MCUs that have some measures to minimize the ability of a CPU
>> crash screwing up "controls" -- one just has to hope they REALLY work! :-/
>> ]
>> 
>> You might be able to kludge an error signal (over volt, over current,
>> etc.) onto the RESET pin and hope the processor doesn't misbehave
>> entering RESET.
> 
> It's a pretty simple application. Like I said, the processor doesn't have to
> do much at all.

It's not the complexity that is the issue but, rather, the consequences
of the controls (MCU) failing that has to be addressed.

E.g., in my application, there are > 3 power supplies that are derived
from a nominal 48V supply (including the power to run the MCU).  So,
*I* have to ensure a fault doesn't end up toasting any of the devices
whose power is thus derived.  Or, lead to a fire, etc.

[Yes, it's doable.  But, not a simple "if the MCU fails, the product
just stops working" scenario.]

On 7/2/2021 8:01 AM, Clive Arthur wrote:
> On 02/07/2021 15:42, Anthony William Sloman wrote:
>> On Friday, July 2, 2021 at 11:32:12 PM UTC+10, Chris Jones wrote:
> 
> <snipped>
> 
>>> You'd probably be better off with a small cheap fpga. Some of them work
>>> with open-source software now.
>>
>> But I wouldn't get the A/D converter thrown in, and I'd have to make my own 
>> 100MHz clock. I've been fond of programmable devices for a long time now - my 
>> 1996 paper used the (fairly rudimentrary) ICT PA7024 - but in this 
>> application a micro-controller would provide a lot of bang for very few bucks.
>>
> 
> The first thing I do for any hard real time control type project is code some 
> simple functions to use a spare UART as a diagnostics port plugged in to an 
> ANSI terminal emulator on a PC.  TeraTerm works fine.
> 
> Then I use generally single key commands to dump things to the terminal, adjust 
> things, whatever.  On a complicated project I may have several menus focussed 
> on different aspects.  Here's one screen of about ten in a current project...
> 
>     Real Time Clock and Timer test Menu
> 
>     Esc  : Back
> 
>      T   : Read Time
>      D   : Dump RTC chip
>      P   : Show Timestamp Parameters
> 
>     Clock frequency on J6 pin 1
>      0   : Off
>      1   : 100Hz
>      2   : 1kHz
>      3   : 10kHz
>      4   : 100kHz
>      5   : 1MHz
> 
> Pressing 'D' for example displays this...
> 
> RTC chip dump
> 00 : 17 55 14 05 02 07 21 00 00 00 00 00 00 00 00 C8
> 10 : 00 1E C0 00 08 00 00 00 00 00 00 00 00 02 00 14
> 20 : 40 00 00 00 00 00 00 00 00 20 00 00 00 00 00 00...
> 
> And so on.  I can't imagine the pain of not having this.  In Bill's system, you 
> might press '<' or '>' to move the square wave slightly. 'A' might display the 
> current ADC value.  I just add stuff as it's needed and remove stuff which is 
> no longer useful.
> 
> But not in an FPGA.

Why couldn't you have a *button* connected to a pin on the FPGA
(instead of code that decodes a character sent serially)?

On 7/2/2021 9:18 AM, Michael Kellett wrote:
> Your biggest problem right now is finding a part that you can actually buy.

Yup.  Having disti/rep friends is golden, now!  :>

> 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.

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)

> 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.

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).

fredag den 2. juli 2021 kl. 18.20.10 UTC+2 skrev bill....@ieee.org:
> On Saturday, July 3, 2021 at 1:50:57 AM UTC+10, lang...@fonz.dk wrote: 
> > fredag den 2. juli 2021 kl. 16.42.29 UTC+2 skrev bill....@ieee.org: 
> > > On Friday, July 2, 2021 at 11:32:12 PM UTC+10, Chris Jones wrote: 
> > > > On 02/07/2021 22:56, Anthony William Sloman wrote: 
> > > > > On Friday, July 2, 2021 at 9:13:58 PM UTC+10, Don Y wrote: 
> > > > >> On 7/1/2021 10:33 PM, Anthony William Sloman wrote: 
> > > > >>> 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. 
> > > > >>> 
> > > > >>> Has anybody got a favourite part? 
> > > > > 
> > > > >> 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. 
> > > > > 
> > > > > 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. 
> > > > > 
> > > > >> Be advised that many newer devices operate, internally, at a variety of different clock rates. 
> > > > > 
> > > > > The device wouldn't be doing very much, so that probably wouldn't be a problem. 
> > > > > 
> > > > You'd probably be better off with a small cheap fpga. Some of them work 
> > > > with open-source software now. 
> > 
> > > But I wouldn't get the A/D converter thrown in, and I'd have to make my own 100MHz clock. I've been fond of programmable devices for a long time now - my 1996 paper used the (fairly rudimentrary) ICT PA7024 - but in this application a micro-controller would provide a lot of bang for very few bucks. 
> > >
> > why do you need an A/D? can't just time the zero crossing? Why 100MHz? 
> 
> The 100MHz comes from the fact that the Siliconix Si3440DV DMOSFet that I fancy has a maximum turn-on time of 15nsec and maxim off-time of 30nsec (if you can find half an amp of gate drive current to get the 8uC gate charge in and out) so 100MHz is fast enough for a pair of decent non-overlapping drive waveform, and with a 100MHz master clock you can fiddle the frequency around 100kHz in pretty small steps. You don't need to get it perfect. 
> 
> Timing the zero-crossings wouldn't be helpful - if resonant tank is driven (in this application) at less than the resonant frequency you get a short period where nothing happens, so there might be a few more zero-crossings than you'd like. If the micro-controller has an A/D anyway, digitising a fraction of of the voltage across the tank circuit could let you look at the voltages where they were better behaved. There are other ways of doing it, but they all seem to need more components. 
> 
> > that said, it is trivial to setup a complementary squarewave with dead time on an STM32 and trigger the ADC at specific points with the same timer. You can get a board for a few dollars (though maybe not at the moment). 
> 
> The board is supposed to take in 24V and spit out +/200V. It's got two wound inductors on it. The board that came with STM32 on it wouldn't have that and would probably have a lot of less than useful bells and whistles. 

the cheap ones have a regulator and crystal and the cpu

>It's is supposed to electromagnetically quiet, and micro-processor boards aren't good for that. 

you want MCU, but you don't want want MCU because it is not quiet?  how quiet are FETs switching 24V with 0.5A gate drive?

all in one, https://eu.mouser.com/ProductDetail/STMicroelectronics/STEVAL-ESC002V1?qs=l7cgNqFNU1hqucyPrM36%252Bg%3D%3D

On 02/07/2021 17:53, Don Y wrote:
> On 7/2/2021 8:01 AM, Clive Arthur wrote:
>> On 02/07/2021 15:42, Anthony William Sloman wrote:
>>> On Friday, July 2, 2021 at 11:32:12 PM UTC+10, Chris Jones wrote:
>>
>> <snipped>
>>
>>>> You'd probably be better off with a small cheap fpga. Some of them work
>>>> with open-source software now.
>>>
>>> But I wouldn't get the A/D converter thrown in, and I'd have to make 
>>> my own 100MHz clock. I've been fond of programmable devices for a 
>>> long time now - my 1996 paper used the (fairly rudimentrary) ICT 
>>> PA7024 - but in this application a micro-controller would provide a 
>>> lot of bang for very few bucks.
>>>
>>
>> The first thing I do for any hard real time control type project is 
>> code some simple functions to use a spare UART as a diagnostics port 
>> plugged in to an ANSI terminal emulator on a PC.&nbsp; TeraTerm works fine.
>>
>> Then I use generally single key commands to dump things to the 
>> terminal, adjust things, whatever.&nbsp; On a complicated project I may 
>> have several menus focussed on different aspects.&nbsp; Here's one screen 
>> of about ten in a current project...
>>
>> &nbsp;&nbsp;&nbsp; Real Time Clock and Timer test Menu
>>
>> &nbsp;&nbsp;&nbsp; Esc&nbsp; : Back
>>
>> &nbsp;&nbsp;&nbsp;&nbsp; T&nbsp;&nbsp; : Read Time
>> &nbsp;&nbsp;&nbsp;&nbsp; D&nbsp;&nbsp; : Dump RTC chip
>> &nbsp;&nbsp;&nbsp;&nbsp; P&nbsp;&nbsp; : Show Timestamp Parameters
>>
>> &nbsp;&nbsp;&nbsp; Clock frequency on J6 pin 1
>> &nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp; : Off
>> &nbsp;&nbsp;&nbsp;&nbsp; 1&nbsp;&nbsp; : 100Hz
>> &nbsp;&nbsp;&nbsp;&nbsp; 2&nbsp;&nbsp; : 1kHz
>> &nbsp;&nbsp;&nbsp;&nbsp; 3&nbsp;&nbsp; : 10kHz
>> &nbsp;&nbsp;&nbsp;&nbsp; 4&nbsp;&nbsp; : 100kHz
>> &nbsp;&nbsp;&nbsp;&nbsp; 5&nbsp;&nbsp; : 1MHz
>>
>> Pressing 'D' for example displays this...
>>
>> RTC chip dump
>> 00 : 17 55 14 05 02 07 21 00 00 00 00 00 00 00 00 C8
>> 10 : 00 1E C0 00 08 00 00 00 00 00 00 00 00 02 00 14
>> 20 : 40 00 00 00 00 00 00 00 00 20 00 00 00 00 00 00...
>>
>> And so on.&nbsp; I can't imagine the pain of not having this.&nbsp; In Bill's 
>> system, you might press '<' or '>' to move the square wave slightly. 
>> 'A' might display the current ADC value.&nbsp; I just add stuff as it's 
>> needed and remove stuff which is no longer useful.
>>
>> But not in an FPGA.
> 
> Why couldn't you have a *button* connected to a pin on the FPGA
> (instead of code that decodes a character sent serially)?
> 
Not sure how that would give me a system of diagnostics menus.  This is 
on a serial terminal.  I've been doing this for years, probably inspired 
by my Forth programming.  It even catches on with the youngsters.

-- 
Cheers
Clive