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?

--
Bill Sloman, Sydney

On Friday, 2 July 2021 at 06:33:59 UTC+1, bill....@ieee.org 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?
The RP2040 looks very interesting. Price: 1 dollar.
Simple? Maybe not. Its definitely worth a look.
There is some stock around at the moment.

John

On 02/07/2021 06: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'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?
>

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.

--
Cheers
Clive

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.

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)

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.

--
Bill Sloman, Sydney

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.

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.

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

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

+1

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.

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

On 7/2/2021 9: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.
>>
>> 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.
>
>

The GreenPAK series of SPLC are cheap and cheerful and (aside from a few
niggles) the designer software is very straightforward to use:

<https://www.dialog-semiconductor.com/greenpak-designer-software>

When you need to do high-speed glue logic on the cheap these are where
it's at

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.

--
Bill Sloman, Sydney

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.

--
Cheers
Clive

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

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

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

On Friday, July 2, 2021 at 1:33:59 AM UTC-4, bill....@ieee.org 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?

Who would know what Timo's inverter is?
100 MHz is difficult to work with in any case.

>
> --
> Bill Sloman, Sydney

On 7/2/2021 11:23 AM, Clive Arthur wrote:
> 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. 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)?
>>
> 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.

Sorry, my comment was intended for the OP's application:

"Press the RED button (legended with '>') to increase the frequency
or the GREEN button (legended with '<') to decrease"

In deeply embedded devices (no real display), I've used a
custom board that sat on the CPU bus -- accompanied by a
"real time monitor" -- to dynamically monitor and modify
arbitrary locations in memory.

It's crude (and not symbolic), but amazingly powerful
when you realize you can dynamically tweek the data that
a particular algorithm is using *now* and observe it's
results, directly -- without having to cajole the actual
sensor(s) to produce the values that would cause these
actions.

With RAM-based code stores (development), you can even patch
the code while its running -- instead of having to rebuild
a binary.

On Fri, 2 Jul 2021 12:21:17 -0700 (PDT), Fred Bloggs
<bloggs.fredbloggs.fred@gmail.com> wrote:

>On Friday, July 2, 2021 at 1:33:59 AM UTC-4, bill....@ieee.org 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?
>
>Who would know what Timo's inverter is?
>100 MHz is difficult to work with in any case.

The 100 MHz is probably the CPU speed or the timer/PWM clock.

We use an ST ARM uP that claims 150 MIPS and can run a timer/PWM block
at 120 MHz. So a 100 KHz PWM will have below 0.1% resolution.

On Friday, July 2, 2021 at 1:33:59 AM UTC-4, bill....@ieee.org 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?

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.

--

Rick C.

- Get 1,000 miles of free Supercharging
- Tesla referral code - https://ts.la/richard11209

On Saturday, July 3, 2021 at 2:51:49 AM UTC+10, Don Y wrote:
> 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?

That seems to be what you are doing here.

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

Obviously.

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

This isn't your application. It's Timo's. See the thread "Low noise, high bias voltage on picoAmp TIA's input, howto?"
> Yes, it's doable. But, not a simple "if the MCU fails, the product just stops working" scenario.

Most products stop working if any of the components fail. What's your point?

--
Bill Sloman, Sydney