On Friday, July 2, 2021 at 10:35:11 PM UTC-4, bill....@ieee.org wrote:> 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.Single chip is not synonymous with simple. "Cheap" is relative and you haven't really looked at the total price. For example you seem to think supplying a 7 MHz clock and using a PLL to the MCU is somehow cheaper than the same process with an FPGA. The clock is not an expensive part by any means. Likewise, a one input ADC is not an expensive part either. So you are not looking for cheap as much as "cheapest possible". I hope you can get the timing to work with a single instruction stream processor. With the sort of timing requirements your design seems to need it can be tricky to make a sequential processor responsive enough. An FPGA, on the other hand, will do the job with very high resolution and not break a sweat... or more accurately, the programmer won't break a sweat. You won't be limited to 100 MHz as the internal PLLs and the logic in FPGAs often work at much higher frequencies, even the low power devices. This project in an FPGA is a slam dunk with probably the shortest development time and smallest risk. So it would appear you asked for "simple" but really want minimum price. Sigma-delta converters are often the choice for FPGAs, but successive approximation is easily done as well. The hard part is the DAC output you need. You can get 0.1% resistors for an R-2R ladder without too high a price. It's not clear if that would be adequate or not. The I/O supplies on each bank of FPGA I/Os are separate, so noise from the FPGA internals is minimal. I seem to recall a 100 MHz 8051 created some years ago with the same idea as the propeller that peripherals can be implemented in software. Anyone remember that? There's also the various Cypress PSOC lines with an emphasis on low cost by trading off fixed peripherals for programmable analog and logic. The processor may not run at 100 MHz, but if you can off load some of the heavy lifting to the programmable portions maybe the lower clock rate is good enough. -- Rick C. + Get 1,000 miles of free Supercharging + Tesla referral code - https://ts.la/richard11209
Fast simple microcontroller
Started by ●July 2, 2021
Reply by ●July 3, 20212021-07-03
Reply by ●July 3, 20212021-07-03
On Saturday, July 3, 2021 at 9:58:11 PM UTC+10, piglet wrote:> 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? > > Look back a few weeks in SED for thread "Low noise high bias voltage > ..." - basically a call for ideas on a low noise high voltage low power > inverter. > > Bill Sloman is now exploring using very fast mcus to generate square wave drive for the current fed center tap push-pull converter he is > fascinated with.I've liked the Baxanadall Class-C oscillator since I was a graduate student - there's an example of the circuit in my Ph.D. thesis, not that I ever used it. The circuit it was intended to replace was pretty horrible, but worked well enough that I never bothered to actually dump it. There's a copy of Baxandall's 1959 paper on my web-site. http://sophia-electronica.com/Baxandall1959JM.pdf and a discussion of what it does, and of a couple of variations on the original circuit http://sophia-electronica.com/Baxandall_parallel-resonant_Class-D_oscillator1.htm I don't know whether I am fascinated by the circuit - it is neat and is useful in some odd applications. I think I've used it twice for commercial applications. The more recent one - 1986 - was in a retrofit to excite a linear variable differential transformer used to measure the progressively increasing mass of a single crystal of gallium arsenide (GaAs) being grown in the Metals Research GaAs Liquid-Encapsulated Czochralski (LEC) crystal puller, which was pretty exotic. The circuit it replaced had been developed a decade earlier and used components that had become obsolete in 1986. It's certainly not the only circuit I've ever thought about, and it wasn't involved in any of the three patents I've got. -- Bill Sloman, Sydney
Reply by ●July 3, 20212021-07-03
On 03/07/2021 01:01, 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. >You could do it in an FPGA. Obviously you could put a CPU with UART in the FPGA design, with the CPU running whatever code to make a menu you would have put on a micro, (but with peripherals that do exactly whatever fast logic you need, unlike those on most microcontrollers), though there are much more efficient ways. There are for example logic analyzers that you can drop into your fpga design, that connect to an external PC for debugging. This is much better than some printf statements to a uart, as you can get timing information about when things happen, that is much more accurate than over a UART. I think most of the bugs are usually caught in simulation so the need for debugging on the hardware may be rare anyway.
Reply by ●July 3, 20212021-07-03
On Saturday, July 3, 2021 at 11:00:29 PM UTC+10, gnuarm.del...@gmail.com wrote:> On Friday, July 2, 2021 at 10:35:11 PM UTC-4, bill....@ieee.org wrote: > > 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. > > Single chip is not synonymous with simple.Obviously not. Back when I was working with electron beam microfabicators, the floor plan of a single layer of single chip could be as complex as the street map of New York. Minimum features sizes have gone down quite a bit since then.> "Cheap" is relative and you haven't really looked at the total price. For example you seem to think supplying a 7 MHz clock and using a PLL to the MCU is somehow cheaper than the same process with an FPGA. The clock is not an expensive part by any means.Actually the Microchip dsPIC33EPxxxSP50X does seem to have an internal RC oscillator, which would probably be good enough for what I need to do. The circuit has to drive the resonant tank at (or just below) it's resonant frequency and the control loop could also cope with drift in the internal oscillator frequency.> Likewise, a one input ADC is not an expensive part either.Clearly.> So you are not looking for cheap as much as "cheapest possible".I'm actually looking for "simple" and it looks as if the Microchip part would cost about as much as the Si3440DV MOSFet switches, which is cheap enough.> I hope you can get the timing to work with a single instruction stream processor. With the sort of timing requirements your design seems to need it can be tricky to make a sequential processor responsive enough.Not in this application.> An FPGA, on the other hand, will do the job with very high resolution and not break a sweat... or more accurately, the programmer won't break a sweat. You won't be limited to 100 MHz as the internal PLLs and the logic in FPGAs often work at much higher frequencies, even the low power devices. This project in an FPGA is a slam dunk with probably the shortest development time and smallest risk. > > So it would appear you asked for "simple" but really want minimum price.> Sigma-delta converters are often the choice for FPGAs, but successive approximation is easily done as well. The hard part is the DAC output you need.I don't need a DAC at all. All the micro-controller would do would change the period of the square wave-drive to keep it at (or just below) the resonant frequency of the tank circuit> You can get 0.1% resistors for an R-2R ladder without too high a price. It's not clear if that would be adequate or not. The I/O supplies on each bank of FPGA I/Os are separate, so noise from the FPGA internals is minimal.I do know about 0.1% resistors. I've specified lots of them. This isn't an application that seems to need them> I seem to recall a 100 MHz 8051 created some years ago with the same idea as the propeller that peripherals can be implemented in software. Anyone remember that?A 100MHz 8051 would do exactly what I need. At one point I spent a couple of weeks learning about 8051 assembler - it's a pretty rudimentary processor, but does everything I'd need> There's also the various Cypress PSOC lines with an emphasis on low cost by trading off fixed peripherals for programmable analog and logic. The processor may not run at 100 MHz, but if you can off load some of the heavy lifting to the programmable portions maybe the lower clock rate is good enough.The idea is is to get two roughly 100kHz square waves. With a 100MHz clock, that's a 10-bit counter. Since there is +/17% tolerance on that 100kHz resonant frequency, you might need 11-bits to cope with the worst case. You then have tweak that "100kHz" to fit the tank circuit you've got, and keep tweaking it track the actual resonant frequecy as it cahnges withb load and room temperature. It's not rocket science. -- Bill Sloman, Sydney
Reply by ●July 3, 20212021-07-03
On 03/07/2021 14:30, Chris Jones wrote: <snip>> You could do it in an FPGA. Obviously you could put a CPU with UART in > the FPGA design, with the CPU running whatever code to make a menu you > would have put on a micro, (but with peripherals that do exactly > whatever fast logic you need, unlike those on most microcontrollers), > though there are much more efficient ways. > > There are for example logic analyzers that you can drop into your fpga > design, that connect to an external PC for debugging. This is much > better than some printf statements to a uart, as you can get timing > information about when things happen, that is much more accurate than > over a UART. I think most of the bugs are usually caught in simulation > so the need for debugging on the hardware may be rare anyway. >There are lots of timers. Timing information is garnered from them and printed (though not with printf). On occasion a spare I/O pin might trigger a scope. The particular system I'm working on ATM requires highly accurate timing and tracking with a one instruction cycle granularity. All it needs is a little imagination, and you have a wealth of built-in diagnostics which are useful both for the developer and the service guys. Oh, there is an FPGA doing some relatively simple but fast stuff including ECC things. Luckily, the FPGA guy sees the sense in allowing the processor access to various registers. Seriously, I've been doing this for years. You usually get the mumble mumble debugger stuff from people, particularly the younger ones who only know what they've been taught, but they always come round. -- Cheers Clive
Reply by ●July 3, 20212021-07-03
On Saturday, July 3, 2021 at 6:30:21 AM UTC-7, Chris Jones wrote:> On 03/07/2021 01:01, 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. > > > You could do it in an FPGA. Obviously you could put a CPU with UART in > the FPGA design, with the CPU running whatever code to make a menu you > would have put on a micro, (but with peripherals that do exactly > whatever fast logic you need, unlike those on most microcontrollers), > though there are much more efficient ways.But FPGA cannot do the deep sleep as micro. Many micros can sleep in 100uA.
Reply by ●July 3, 20212021-07-03
On 7/3/2021 8:01 AM, Clive Arthur wrote:> Seriously, I've been doing this for years. You usually get the mumble mumble > debugger stuff from people, particularly the younger ones who only know what > they've been taught, but they always come round.The oversight is that there are multiple TYPES of debuggers. If all you've seen is gdb (and the like), then you're missing out on a whole assortment of debugging techniques! This is the problem with "teaching to the (current) technology" instead of teaching technology itself.
Reply by ●July 3, 20212021-07-03
On Friday, 2 July 2021 at 17:51:49 UTC+1, Don Y wrote:> 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.The M0+ ARMs seem to have very tight coupling between the cpu and the i/o pins. ARM claim: "The processor optionally implements a single-cycle I/O port that provides very high speed access to tightly-coupled peripherals, such as general-purpose-I/O (GPIO)." Microchip claim: "The Arm® Cortex®-M0+ CPU's local bus (IOBUS) provides a direct connection between the CPU and the PORT. IOBUS transactions bypass the Advanced High-performance Bus (AHB) bus allowing I/O pins to be manipulated in a single instruction cycle. IOBUS transactions are not subject to any wait-states induced by AHB bus arbitration. ST claim: "The Cortex ® -M0+ also features a Single-cycle I/O Port, enabling the CPU to access data with a 1-clock latency. In the STM32G0, the Single-cycle I/O Port is used to access GPIO port registers, enabling these ports to work at the processor frequency." John
Reply by ●July 3, 20212021-07-03
On 7/3/2021 9:55 AM, John Walliker wrote:> On Friday, 2 July 2021 at 17:51:49 UTC+1, Don Y wrote: > >> 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. > > The M0+ ARMs seem to have very tight coupling between the cpu and the i/o pins. > ARM claim: > "The processor optionally implements a single-cycle I/O port that provides > very high speed access to tightly-coupled peripherals, such as > general-purpose-I/O (GPIO)." > > Microchip claim: > "The Arm® Cortex®-M0+ CPU's local bus (IOBUS) provides a direct connection > between the CPU and the PORT. IOBUS transactions bypass the Advanced > High-performance Bus (AHB) bus allowing I/O pins to be manipulated in a single > instruction cycle. IOBUS transactions are not subject to any wait-states induced > by AHB bus arbitration. > > ST claim: > "The Cortex ® -M0+ also features a Single-cycle I/O Port, > enabling the CPU to access data with a 1-clock latency. > In the STM32G0, the Single-cycle I/O Port is used to > access GPIO port registers, enabling these ports to work > at the processor frequency."The I/O complement includes more than just GPIOs -- and the AHB provides access to more than just the I/O complement! (e.g., FLASH accesses happen at a rate an order of magnitude slower than the CPU clock). The days of (hand-)counting clock cycles to determine the execution time of a code fragment are long past. There's a reason data sheets are now hundreds of pages!
Reply by ●July 3, 20212021-07-03
On Saturday, 3 July 2021 at 18:39:14 UTC+1, Don Y wrote:> The days of (hand-)counting clock cycles to determine the execution > time of a code fragment are long past. > > There's a reason data sheets are now hundreds of pages!True enough. However, there are other options with some of the ARMs such as co-processors in some of the TI and other devices. The RP2040 has a programmable state machine which looks very deterministic and of course the Xcore devices which have been mentioned here provide another approach to deterministic systems. For low-speed applications, the AT-tiny 13 or 2313 are still nice. John
