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
Fast simple microcontroller
Started by ●July 2, 2021
Reply by ●July 2, 20212021-07-02
Reply by ●July 2, 20212021-07-02
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.
Reply by ●July 2, 20212021-07-02
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.
Reply by ●July 2, 20212021-07-02
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
Reply by ●July 2, 20212021-07-02
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
Reply by ●July 2, 20212021-07-02
On Saturday, July 3, 2021 at 11:28:33 AM UTC+10, gnuarm.del...@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? > > An FPGA can be used to implement an 8051 or any other MCU architecture you wish at 100 MHz without much trouble. Then you can tailor the peripherals as you choose. Gowin has parts for $3 or less with internal Flash.And the Microchip dsPIC33EPxxxSP50X will do the job for for $3, and throws in a PPL that will multiply up a 7MHz clock to 100MHz as well as an A/D converter that I can use. The aim is to get a single chip processor that is cheaper and simpler of the shelf. -- Bill Sloman, Sydney
Reply by ●July 3, 20212021-07-03
On 02/07/2021 17:59, Don Y wrote:> 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).Another one worth considering (maybe not for your job) is the STM32H750xB - cheapest way I know to get three 16 bit ADCs (3.6MHz sampling rate). Core runs at 480MHz, 1M ram, 128k flash. The LQFP part (100pin) is £5.76 (100 off Farnell) - no stock of course but some due in time for Christmas. You might need to go for one of the BGA packages to get access to enough pins to use all the features you need. MK
Reply by ●July 3, 20212021-07-03
On 02/07/2021 16:45, Klaus Vestergaard Kragelund wrote:> 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 > > KlausLook back a few weeks in SED for thread "Low noise high bias voltage ..." - basically a call for ideas on a low noise high voltage low power inverter. Bill Sloman is now exploring using very fast mcus to generate square wave drive for the current fed center tap push-pull converter he is fascinated with. piglet
Reply by ●July 3, 20212021-07-03
On Saturday, July 3, 2021 at 7:32:56 PM UTC+10, Michael Kellett wrote:> On 02/07/2021 17:59, Don Y wrote: > > 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). > Another one worth considering (maybe not for your job) is the > STM32H750xB - cheapest way I know to get three 16 bit ADCs (3.6MHz > sampling rate). > Core runs at 480MHz, 1M ram, 128k flash. The LQFP part (100pin) is £5.76 > (100 off Farnell) - no stock of course but some due in time for Christmas. > You might need to go for one of the BGA packages to get access to enough > pins to use all the features you need.I suspect that I'd use very few pins indeed. The job needs two output - one for each of the two MOSFet drivers, and one input to the A/C converter. It might need an external clock, but clock stability isn't an issue, since the MCU would be there to make sure that the MOSFets were driven at - or just below - the resonant frequency of the tank circuit which is going to drift around a bit as the inductor and capacitor warm up, and will probably change if the load changes and the dissipation in the circuit - which isn't going to be large -changes in consequence. You might provide a few signalling outputs - maybe two or three - but it's a pretty simple circuit doing a pretty simple job. -- Bill Sloman, Sydney
Reply by ●July 3, 20212021-07-03
On 7/3/2021 2:32 AM, Michael Kellett wrote:> On 02/07/2021 17:59, Don Y wrote: >> On 7/2/2021 9:18 AM, Michael Kellett wrote:> Another one worth considering (maybe not for your job) is the STM32H750xB - > cheapest way I know to get three 16 bit ADCs (3.6MHz sampling rate).In my case, I'd leverage the high sampling rate to time-division multiplex each A/DC for multiple uses (e.g., voltage sense and current sense on each of the converters).> Core runs at 480MHz, 1M ram, 128k flash.The RAM and FLASH would be wasted, for me -- I'd run everything out of TCM (and still have oodles to spare! :> )> The LQFP part (100pin) is £5.76 (100 > off Farnell) - no stock of course but some due in time for Christmas. > You might need to go for one of the BGA packages to get access to enough pins > to use all the features you need.The 64 pin device I mentioned still has more pins than I'd need as there are no "external devices" involved (beyond FETs and sense networks). I'd use a serial interface to communicate with the main CPU and some dedicated pins for things like over-volt/current feedback. It's (psychologically) difficult to design in a part that has so much "excess capacity" than needed -- there is always pressure to convert some of that excess into cost reductions. Barring that, an incentive to imagine *other* functionality that could justify the capacity (and cost). That's kind of hard if it's just being used as a power supply (PD) controller! <frown> Perhaps I can embelish the protocol with the PSE and more tightly integrate the two ends of the wire... (though that's still going to be a very low bandwidth link) I'll give it a closer look, though. Nowadays, "more" may be the new normal; "get used to it"! :-/ Thx!
