Fast simple microcontroller

On 03/07/2021 22:25, John Walliker wrote:
> On Saturday, 3 July 2021 at 21:59:38 UTC+1, Michael Kellett wrote:
> 
>> In that case I'd suggest looking at the ST STM32G071 - comes in 32pin
>> packages, 64MHz clock, a little slower than ideal but might well be good
>> enough. Built in RC oscillator within 1%.
>> Nice simple Cortex M0 core with at least one fancy timer that can do
>> compementary digitial drives (going from memory there so check before
>> making irrevocable decisions !).
>>
> But do also check the RP2040.  Two ARM M0+ cores at 133MHz,
> eight programmable i/o state machines and lots of other nice things.
> It costs $1.
> 
> John
> 

I, too, thought it was worth a look, but since looking I've put it 
firmly on the wait-and-see list.
The tool and documentation support is not of the quality I'm used to 
from ST or NXP etc.
The use of the programmable IO controllers as an attempted substitute 
for dedicate peripherals is not new, Parallax, Xmos, Motorola, Cypress 
PSOC and others were all there before - it hasn't caught on in a huge 
way. The Cypress tools are way better than those available for the RP2040.
The ADC on the RP2040 was poorly documented and not very good (when I 
looked last).
RP has no track record as a supplier of micros at chip level.
All these issues may get sorted in time - but I wouldn't bet the farm on it.

MK

On Saturday, July 3, 2021 at 10:34:16 PM UTC-4, bill....@ieee.org wrote:
> On Sunday, July 4, 2021 at 10:13:42 AM UTC+10, gnuarm.del...@gmail.com wrote: 
> > On Saturday, July 3, 2021 at 9:46:38 AM UTC-4, bill....@ieee.org wrote: 
> > > 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 microfabricators, 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. 
> > 
> > The trouble is this has become a bit of the X/Y problem. You ask for X when you are really trying to do Y. "Simple" has no definition, so you can't really expect to get good advice.
> "Simple" - in this context - was a fast fast micro-controller that wasn't designed to do signal processing. I didn't want to pay for options I didn't, or cope with the power consumed by signal processing hardware that I didn't want to use. You figured that it was the kind of problem that needs a micro-controller rather than thinking about the problem I am trying to solve 

Hmmm... you seem to have reversed rolls.  You just defined "simple" in terms of an MCU and then claim I am trying to push you into an MCU???!!!  I'm telling you an FPGA is a more simple way to solve your problem by normal definitions of "simple". 

I don't know enough about your problem to solve it for you, but the info you've provided clearly in this thread shows an FPGA is a perfect tool for the job as many others have said.  You shot that down by saying FPGAs are not "simple" enough and define "simple" as being the perfect MCU.  Yes, by that definition an FPGA will not be "simple" unless you design an MCU in the FPGA perhaps.  I think sequentially executing processors have inherent limitations that make coding them complex as soon as you have more than one asynchronous tasks.  This is a very simple problem to solve in an FPGA with much simpler timing constraints.   


> > > > So it would appear you asked for "simple" but really want minimum price.
> What I explicitly asked for was a fast single chip processor that wasn't weighed down with digital signal processing hardware. You don't seem to have taken that on board.

Oh, yes, and I'm trying to explain that an MCU may not be the best choice of tool to solve this problem.  You said you wanted a "simple" solution and now have defined "simple" as being an MCU.  Ok, I can't argue that point if that is your definition of what you want.  Have at it. 

But I can make the point that such a definition of "simple" means you do not wish to consider other methods that may produce a better solution with less effort and less risk and remain within some given cost range.  That's my idea of "simple" even if it's not yours. 


> > > > 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 
> > I guess you aren't following the ideas. To implement a successive approximation ADC you need a DAC.
> If the successive approximation converter it is buried inside the micro-controller, I get the DAC with micro-controller. If I remember rightly, Siemens did one where the DAC part was a bunch of capacitors (capacitance defined by the lithography) so no 0.1% resistors at all.

Irrelevant.  Now you understand why the DAC is needed in the FPGA solution if you don't want to add a low cost ADC chip.  So you add a few resistors to the design and viola, you have an ADC that runs fast enough for your sampling requirement.  So adding an ADC to an FPGA costs maybe $0.10. 


> > You set the msb to the DAC and if the comparator indicates the DAC output is greater than the ADC input, you back off that bit and set the next lesser bit. lather, rinse, repeat. With an adequately fast DAC you can get MHz sample rates. This is what they are most likely using in the MCUs at 500 kSPS and 12 bits.
> Perhaps. Why would I care how they did it? 

Exactly.  You don't.  Just as you don't care that it is easy to add an ADC to an FPGA using resistors. 


> > > > 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.
> > 
> > Yeah, as I said, you aren't following the concepts.
> Not the concept that you have decided that I ought to be worrying about.

I'm just answering your questions.  You did come here to ask questions, no?  You didn't seem to understand that a DAC is required to make a successive approximation ADC, so I explained that to you.  Now you seem to be getting defensive.  If you don't want answers, why do you ask the questions? 


> > > > 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 frequency as it cahnges withb load and room temperature. It's not rocket science.
> > 
> > Yes, I'm sure it's not, but what you describe does not explain how you get from ±17% to 11 bits of resolution on a 100 kHz output counter. If you want to explain enough for others to understand, fine. If not, that's fine too.
> 100kHz is a 10usec clock period. To divide a 100MHz clock down to 100kHz you need to count 1000 edges - not quite 2^10 (1024). If I needed 17% slower clock (83kHz) I'd need to count 1170 edges (more than 1024) so I'd need a 11-bit counter which could get up to 2048.

Ok, so you are just talking implementation details.  You only need 10 us resolution.  Fine.  You can have an 11 bit counter in an FPGA.  No problem.  In most MCUs the counters are multiples of 8 bits, so no problem there either. 


> > But as I have said very clearly, this is all a slam dunk in an FPGA unless there are parts to the design you aren't explaining. That's what I think of when someone asks for "simple", something that is easy and straight forward to implement.
> If I've got to add bits to a FPGA that I'd get built into the microcontroller, life becomes less simple. You don't seem to have grasped this. 

???  I don't consider it to be anything other than simple to add the "bits" you seem to be talking about.  I haven't seen a clear explanation of the calculations you need to do and I have seen no description of the processing flow with timing.  These are the complex matters in the design.  Banging out a counter or even a UART in HDL is pretty simple no matter what.  What "bits" do you see as being not simple?  Or are you just going to hand wave "all of them"? 

Please keep in mind this is just a conversation.  No one is attacking you.  Batting around ideas.  But if you reject ideas without consideration you are cutting off a branch of potential solutions.  Perhaps the issue is that you are not comfortable with HDL coding?  

-- 

Rick C.

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

On 04/07/2021 03:40, Anthony William Sloman wrote:
> On Sunday, July 4, 2021 at 10:39:54 AM UTC+10, gnuarm.del...@gmail.com wrote:
>> On Saturday, July 3, 2021 at 8:35:49 PM UTC-4, Clifford Heath wrote:
>>> On 4/7/21 5:55 am, Tom Gardner wrote:
>>>> You still can, for the 32-core 4000MIPS xCORE processors.
>>>>
>>>> In fact the IDE will tell you the exact max timings from
>>>> here to there in you, for /all/ of the code paths in between.
>>> What you just said implies that they have solved the halting problem.
>>>
>>> Which makes it clear that you are more enthusiastic than factual.
>>>
>>> It still sounds like they have a nice feature there, even if it cannot
>>> do what you say.
>> What you just said shows you don't understand the halting problem. Can you state it in a few words? Maybe that will help you understand why your claim is not correct.
> 
> The halting problem - as discussed by Turing in 1936 - is that you can't work out whether an arbitrary computer program will ever halt. It may get stuck in an endless loop.
> 
> The claim that the IDE "will tell you the exact max timings from  here to there in you, for /all/ of the code paths in between" does imply that you can work out all the possible paths, which does seem to be over-optimistic.

Working out all possible paths for a given set of code is a relatively 
easily solved problem. McCabes CCI complexity metric does exactly that. 
Every decision point becomes a node and the code inbetween a line on a 
graph whose length can be proportional to execution time.

For most paths between decision points you can work out a minimum and 
maximum number of machine cycles it is likely to take. Where it gets 
very tricky though is when branch prediction and speculative execution 
is involved. Classical gofaster code like loop unrolling can even go 
slower if it no longer fits nicely into execution cache.

Even working out a minimal subset of CCI test vectors that will execute 
every possible path at least once is still pretty simple to do. And also 
quite worthwhile since the last bugs tend to reside in the least trodden 
paths (which turn out to be in rare but vital critical error recovery).

What *is* impossible is showing that a program will always terminate in 
finite time for every possible set of inputs.

-- 
Regards,
Martin Brown

On Saturday, July 3, 2021 at 10:40:32 PM UTC-4, bill....@ieee.org wrote:
> On Sunday, July 4, 2021 at 10:39:54 AM UTC+10, gnuarm.del...@gmail.com wrote: 
> > On Saturday, July 3, 2021 at 8:35:49 PM UTC-4, Clifford Heath wrote: 
> > > On 4/7/21 5:55 am, Tom Gardner wrote: 
> > > > You still can, for the 32-core 4000MIPS xCORE processors. 
> > > > 
> > > > In fact the IDE will tell you the exact max timings from 
> > > > here to there in you, for /all/ of the code paths in between. 
> > > What you just said implies that they have solved the halting problem. 
> > > 
> > > Which makes it clear that you are more enthusiastic than factual. 
> > > 
> > > It still sounds like they have a nice feature there, even if it cannot 
> > > do what you say. 
> > What you just said shows you don't understand the halting problem. Can you state it in a few words? Maybe that will help you understand why your claim is not correct.
> The halting problem - as discussed by Turing in 1936 - is that you can't work out whether an arbitrary computer program will ever halt. It may get stuck in an endless loop. 
> 
> The claim that the IDE "will tell you the exact max timings from here to there in you, for /all/ of the code paths in between" does imply that you can work out all the possible paths, which does seem to be over-optimistic. 

Ok, I recalled a slightly different statement which included the provision that the solution be found more quickly than just running the program.  The combination of varied inputs makes the running time of a program unconstrained and so infinite loops could not be detected by repetition of state. 

However, the halting problem applies to general programs.  The timing of logic applies to programs with only finitely defined loops.  Since HDL synthesis programs must be realizable in finite hardware the iterative nature must be constrained to known limits.  I think that changes the nature of the halting problem for this class of programs. 

-- 

Rick C.

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

On Sunday, July 4, 2021 at 4:49:00 AM UTC-4, Clifford Heath wrote:
> On 4/7/21 10:39 am, Rick C wrote: 
> > On Saturday, July 3, 2021 at 8:35:49 PM UTC-4, Clifford Heath wrote: 
> >> On 4/7/21 5:55 am, Tom Gardner wrote: 
> >>> You still can, for the 32-core 4000MIPS xCORE processors. 
> >>> 
> >>> In fact the IDE will tell you the exact max timings from 
> >>> here to there in you, for /all/ of the code paths in between. 
> >> What you just said implies that they have solved the halting problem. 
> >> 
> >> Which makes it clear that you are more enthusiastic than factual. 
> >> 
> >> It still sounds like they have a nice feature there, even if it cannot 
> >> do what you say. 
> > 
> > What you just said shows you don't understand the halting problem. Can you state it in a few words? Maybe that will help you understand why your claim is not correct. 
> >
> If you know how to compute the upper limit of execution time of some 
> arbitrary bit of code, you know how to solve the halting problem. It's 
> the same problem.

Sorry, I was recalling a professor's statement from 40+ years ago.  I either recalled it incorrectly or he was not talking about the theoretical halting problem but just a practical issue with the Univac we were using.  

However, the halting problem is about a general algorithm to determine if an arbitrary program would halt.  That is not the problem at hand.  To be implementable in hardware HDL programs are restricted in looping and so the "halting" nature of timing analysis can be resolved.  If your HDL program has timing paths that are indeterminate, it means you have a combinatorial loop which is considered bad form and can't be verified by most HDL tools.  In other words, don't do that!  

-- 

Rick C.

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

On Sunday, July 4, 2021 at 4:50:31 AM UTC-4, Clifford Heath wrote:
> On 4/7/21 6:06 pm, Tom Gardner wrote: 
> > On 04/07/21 01:35, Clifford Heath wrote: 
> >> What you just said implies that they have solved the halting problem.
> > Under some conditions the timing analyzer is unable to 
> > prove timing without additional information. Examples 
> > of common conditions include:
> > * The route contains a loop with a data-dependent exit condition.
> ^^^^^ This is the halting problem 

Yes, and this is not appropriate for hardware design.  If you can't calculate the timing, you can't validate the design or even make it work in most cases.  So the loop is detected and an error/warning flag is thrown.  The loop can be detected.  The halting problem addresses the nature of code and input interactions.  We don't care about input interactions.  The loop can be detected physically and is flagged even if there is no input combination that would make it an infinite loop.  For example a loop with two AND gates driven by the true and compliment of a single input signal.  I don't know if the tools would understand that one or the other of the gates would prevent the loop.  It just considers the fact there exists a combinational path.  

There are reasons for the various methods and limitations of logic design.  I recall when ​Level Sensitive Scan Design LSSD (the basis of JTAG scan chains) was being promoted as a way to make designs verifiable and testable.  New ideas in the 1980s.  

-- 

Rick C.

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

On Saturday, July 3, 2021 at 5:37:45 PM UTC-7, gnuarm.del...@gmail.com wrote:
> On Saturday, July 3, 2021 at 8:19:39 PM UTC-4, Ed Lee wrote: 
> > On Saturday, July 3, 2021 at 5:17:50 PM UTC-7, gnuarm.del...@gmail.com wrote: 
> > > On Saturday, July 3, 2021 at 11:04:33 AM UTC-4, Ed Lee wrote: 
> > > > On Saturday, July 3, 2021 at 6:30:21 AM UTC-7, Chris Jones wrote: 
> > > > > 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. 
> > > You need to learn about FPGAs before you post. That is simply not correct. There's more than one brand that has 100 uA or less sleep modes. 
> > And with timer and interrupt to wakeup? Which one?
> There are some low idle current parts from the company that used to be Actel until they were bought by Microsemi who was bought by Microchip, Polar something I think. I never researched them much. The ones I know more about are the ICE40 parts from Lattice. There are some versions that have idle currents in the ~50 uA range. If you keep a fast clock running there will be additional current just like in an MCU. Run a slow clock for a timer and it will draw virtually no additional current. 

Yes, you can idle it at 50uA at 32KHz if the input and output are blocked and isolated.  To wake it up and reprogram the clock at max of 48MHz, not sure if it can be done internally, or be reconfigured by an external storage.  There is no ADCs or comparators, they will be external.  Very soon, we are talking about board level design rather than single chip solution.

The ICE40s are really very small, barely FPGA, topping out with 7680 LUTs at the high end.  For that, you have to go with BGAs.  Xilinx and Altera FPGAs are in millions of LUTs.

On Sunday, July 4, 2021 at 11:07:08 PM UTC+10, gnuarm.del...@gmail.com wrote:
> On Saturday, July 3, 2021 at 10:34:16 PM UTC-4, bill....@ieee.org wrote: 
> > On Sunday, July 4, 2021 at 10:13:42 AM UTC+10, gnuarm.del...@gmail.com wrote: 
> > > On Saturday, July 3, 2021 at 9:46:38 AM UTC-4, bill....@ieee.org wrote: 
> > > > 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 microfabricators, 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. 
> > > 
> > > The trouble is this has become a bit of the X/Y problem. You ask for X when you are really trying to do Y. "Simple" has no definition, so you can't really expect to get good advice. 
> >
> > "Simple" - in this context - was a fast fast micro-controller that wasn't designed to do signal processing. I didn't want to pay for options I didn't, or cope with the power consumed by signal processing hardware that I didn't want to use. You figured that it was the kind of problem that needs a micro-controller rather than thinking about the problem I am trying to solve
>
> Hmmm... you seem to have reversed rolls. You just defined "simple" in terms of an MCU and then claim I am trying to push you into an MCU???!!! I'm telling you an FPGA is a more simple way to solve your problem by normal definitions of "simple".

It's more parts - at least in the problem that I'm talking about. 

> I don't know enough about your problem to solve it for you, but the info you've provided clearly in this thread shows an FPGA is a perfect tool for the job as many others have said.

It would do part of the job perfectly, but a fast micro-controller  would do rather more of it. 

>  You shot that down by saying FPGAs are not "simple" enough and define "simple" as being the perfect MCU. 

What I was asking for was fast microcontroller - as fast as the Microchip dsPIC33EPxxxSP50X and simpler in not including the digital signal processing parts which I don't actually need.

The subject line is "Fast simple microcontroller". I wasn't asking for a simple solution to a problem,  but a simple example of a particular part 

> Yes, by that definition an FPGA will not be "simple" unless you design an MCU in the FPGA perhaps. I think sequentially executing processors have inherent limitations that make coding them complex as soon as you have more than one asynchronous tasks. This is a very simple problem to solve in an FPGA with much simpler timing constraints.

Since whatever the problem  you want to talk about doesn't have much to do with  the problem that I am tackling, this isn't a useful observation.

> > > > > So it would appear you asked for "simple" but really want minimum price. >
> > What I explicitly asked for was a fast single chip processor that wasn't weighed down with digital signal processing hardware. You don't seem to have taken that on board.
> Oh, yes, and I'm trying to explain that an MCU may not be the best choice of tool to solve this problem. You said you wanted a "simple" solution and now have defined "simple" as being an MCU. Ok, I can't argue that point if that is your definition of what you want. Have at it. 
> 
> But I can make the point that such a definition of "simple" means you do not wish to consider other methods that may produce a better solution with less effort and less risk and remain within some given cost range. That's my idea of "simple" even if it's not yours.
> > > > > 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 
> > > I guess you aren't following the ideas. To implement a successive approximation ADC you need a DAC. 
> > If the successive approximation converter it is buried inside the micro-controller, I get the DAC with micro-controller. If I remember rightly, Siemens did one where the DAC part was a bunch of capacitors (capacitance defined by the lithography) so no 0.1% resistors at all.
> Irrelevant. Now you understand why the DAC is needed in the FPGA solution if you don't want to add a low cost ADC chip. So you add a few resistors to the design and viola, you have an ADC that runs fast enough for your sampling requirement. So adding an ADC to an FPGA costs maybe $0.10.
> > > You set the msb to the DAC and if the comparator indicates the DAC output is greater than the ADC input, you back off that bit and set the next lesser bit. lather, rinse, repeat. With an adequately fast DAC you can get MHz sample rates. This is what they are most likely using in the MCUs at 500 kSPS and 12 bits. 
> > Perhaps. Why would I care how they did it?
> Exactly. You don't. Just as you don't care that it is easy to add an ADC to an FPGA using resistors.
> > > > > 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. 
> > > 
> > > Yeah, as I said, you aren't following the concepts. 
>
> > Not the concept that you have decided that I ought to be worrying about.
>
> I'm just answering your questions. You did come here to ask questions, no? You didn't seem to understand that a DAC is required to make a successive approximation ADC, so I explained that to you. Now you seem to be getting defensive. If you don't want answers, why do you ask the questions?

Of course I understand that, but the successive approximation A/D converter built into many micro-controllers does include that DAC, so I don't have to worry about i. 

> > > > > 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 frequency as it chnges withb load and room temperature. It's not rocket science. 
> > > 
> > > Yes, I'm sure it's not, but what you describe does not explain how you get from ±17% to 11 bits of resolution on a 100 kHz output counter. If you want to explain enough for others to understand, fine. If not, that's fine too. 
>
> > 100kHz is a 10usec clock period. To divide a 100MHz clock down to 100kHz you need to count 1000 edges - not quite 2^10 (1024). If I needed 17% slower clock (83kHz) I'd need to count 1170 edges (more than 1024) so I'd need a 11-bit counter which could get up to 2048.
>
> Ok, so you are just talking implementation details. 

You asked for an explanation. 

>You only need 10 us resolution. Fine. 

I want a roughly 10usec clock period. It's got to match the resonant frequency of a tank circuit to rather better than 1%, possibly 0.1% so I want a 10MHz c;\lock to get a resolution of 10nsec.

> You can have an 11 bit counter in an FPGA. No problem. In most MCUs the counters are multiples of 8 bits, so no problem there either.
>
> > > But as I have said very clearly, this is all a slam dunk in an FPGA unless there are parts to the design you aren't explaining. That's what I think of when someone asks for "simple", something that is easy and straight forward to implement. 
>
> > If I've got to add bits to a FPGA that I'd get built into the microcontroller, life becomes less simple. You don't seem to have grasped this.
>
> ??? I don't consider it to be anything other than simple to add the "bits" you seem to be talking about.

Since when does adding extra components make a design simpler?

> I haven't seen a clear explanation of the calculations you need to do and I have seen no description of the processing flow with timing. 

You could find them on the thread "Low noise, high bias voltage on picoAmp TIA's input, howto?". Not all that clearly spelled out because it is a pretty simple circuit.

>These are the complex matters in the design. Banging out a counter or even a UART in HDL is pretty simple no matter what. What "bits" do you see as being not simple? Or are you just going to hand wave "all of them"? 

They aren't complex matter in this design
 
> Please keep in mind this is just a conversation. No one is attacking you. Batting around ideas. But if you reject ideas without consideration you are cutting off a branch of potential solutions. Perhaps the issue is that you are not comfortable with HDL coding? 

I've never used HDL coding. It's got to be more comfortable than the primitive schemes I have used. I do a text on the subject on my bookshelf, but that project evaporated before I'd read much of it.

-- 
Bill Sloman, Sydney

On Sunday, July 4, 2021 at 9:49:24 AM UTC-4, Ed Lee wrote:
> On Saturday, July 3, 2021 at 5:37:45 PM UTC-7, gnuarm.del...@gmail.com wrote: 
> > On Saturday, July 3, 2021 at 8:19:39 PM UTC-4, Ed Lee wrote: 
> > > On Saturday, July 3, 2021 at 5:17:50 PM UTC-7, gnuarm.del...@gmail.com wrote: 
> > > > On Saturday, July 3, 2021 at 11:04:33 AM UTC-4, Ed Lee wrote: 
> > > > > On Saturday, July 3, 2021 at 6:30:21 AM UTC-7, Chris Jones wrote: 
> > > > > > 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. 
> > > > You need to learn about FPGAs before you post. That is simply not correct. There's more than one brand that has 100 uA or less sleep modes. 
> > > And with timer and interrupt to wakeup? Which one? 
> > There are some low idle current parts from the company that used to be Actel until they were bought by Microsemi who was bought by Microchip, Polar something I think. I never researched them much. The ones I know more about are the ICE40 parts from Lattice. There are some versions that have idle currents in the ~50 uA range. If you keep a fast clock running there will be additional current just like in an MCU. Run a slow clock for a timer and it will draw virtually no additional current.
> Yes, you can idle it at 50uA at 32KHz if the input and output are blocked and isolated. To wake it up and reprogram the clock at max of 48MHz, not sure if it can be done internally, or be reconfigured by an external storage. There is no ADCs or comparators, they will be external. Very soon, we are talking about board level design rather than single chip solution. 

This is not an MCU, you don't "reprogram" the clock.  You have a 32 kHz clock driving the logic that runs at 32 kHz and you have a fast clock driving the logic that runs fast.  You *can* multiplex clocks to logic, but it typically is not done that way as there is little purpose.  So the fast clock is disabled in some way that matches your turn on time requirements and power consumption requirements just as with an MCU. 


> The ICE40s are really very small, barely FPGA, topping out with 7680 LUTs at the high end. For that, you have to go with BGAs. Xilinx and Altera FPGAs are in millions of LUTs.

Sorry, but just as you are never going to sleep an Intel megalith processor at 100 uA, you aren't going to sleep a megalith FPGA at 100 uA.  I thought you were talking about smaller devices that can run with low power and sleep with very low power. 

-- 

Rick C.

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

On Sunday, July 4, 2021 at 7:10:04 AM UTC-7, gnuarm.del...@gmail.com wrote:
> On Sunday, July 4, 2021 at 9:49:24 AM UTC-4, Ed Lee wrote: 
> > On Saturday, July 3, 2021 at 5:37:45 PM UTC-7, gnuarm.del...@gmail.com wrote: 
> > > On Saturday, July 3, 2021 at 8:19:39 PM UTC-4, Ed Lee wrote: 
> > > > On Saturday, July 3, 2021 at 5:17:50 PM UTC-7, gnuarm.del...@gmail.com wrote: 
> > > > > On Saturday, July 3, 2021 at 11:04:33 AM UTC-4, Ed Lee wrote: 
> > > > > > On Saturday, July 3, 2021 at 6:30:21 AM UTC-7, Chris Jones wrote: 
> > > > > > > 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. 
> > > > > You need to learn about FPGAs before you post. That is simply not correct. There's more than one brand that has 100 uA or less sleep modes. 
> > > > And with timer and interrupt to wakeup? Which one? 
> > > There are some low idle current parts from the company that used to be Actel until they were bought by Microsemi who was bought by Microchip, Polar something I think. I never researched them much. The ones I know more about are the ICE40 parts from Lattice. There are some versions that have idle currents in the ~50 uA range. If you keep a fast clock running there will be additional current just like in an MCU. Run a slow clock for a timer and it will draw virtually no additional current. 
> > Yes, you can idle it at 50uA at 32KHz if the input and output are blocked and isolated. To wake it up and reprogram the clock at max of 48MHz, not sure if it can be done internally, or be reconfigured by an external storage. There is no ADCs or comparators, they will be external. Very soon, we are talking about board level design rather than single chip solution.
> This is not an MCU, you don't "reprogram" the clock. You have a 32 kHz clock driving the logic that runs at 32 kHz and you have a fast clock driving the logic that runs fast. You *can* multiplex clocks to logic, but it typically is not done that way as there is little purpose. So the fast clock is disabled in some way that matches your turn on time requirements and power consumption requirements just as with an MCU.

So, FPGA is not same as micro in power management.  STM32F4 can sleep in 100uA and run at full speed of 180MHz, or somewhere in between.

> > The ICE40s are really very small, barely FPGA, topping out with 7680 LUTs at the high end. For that, you have to go with BGAs. Xilinx and Altera FPGAs are in millions of LUTs.
> Sorry, but just as you are never going to sleep an Intel megalith processor at 100 uA, you aren't going to sleep a megalith FPGA at 100 uA. I thought you were talking about smaller devices that can run with low power and sleep with very low power. 

We are talking about something that can fit in OP's app: 48V (or something, likely battery) to 220V inverter, and power budget matter.