Fast simple microcontroller

Anybody who had looked at the the thread "Low noise, high bias voltage on picoAmp TIA's input, howto?" which started on the 21st May, and has had 66 posts and 480 views.

Not if it is confined inside a micro-controller.

I've been looking at the Microchip dsPIC33EP parts, and they seem to offer a 7.4MHz internal oscillator, an internal VCO which can get up to 120MHz, and a "divide by n" option which can let you lock the divided output of the VCO to the 7.4MHz internal clock. So I'd have a choice of 96.2MHz or 103.6 MHz. The internal oscillator can be tweaked up or down by up to about 0.5% in steps of about 0.03%.

There a PWM outputs that could let me divide this down to 83kHz to 117kHz range that I'd need. It all seems to be doable inside the micro-controller.

I have worked with an 800MHz system clock, and I do know the problems that this entails (and how to solve them), but here the problems are safely buried inside the bought-in part.

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.

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.

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.

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

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?

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.

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

Thanks, I searched back and found it :-)

Very nice discussion, and also this thread which is technical instead of all that OT.

In fact I am working on something vaguely similar. Also a micro driving a converter. Right now it is hard-driven, but have been thinking about using it in resonant mode

Resonant mode is a little difficult in that the loop gain is nonlinear. Most resonant controllers use a charge transfer principle, to avoid this non-liniarity. That is not simple to implement in a micro

I am also planning on same with inductor or transformer, driving with high frequency counter. Non-linear loop gain is not a problem, as long as the output is above the target, excess energy will be dumped into the super-caps or batteries. Power transfer efficiency is more important.

Where is it simple to implement?

The ripple cancelling trick might make the converter a bit more linear - and a bit more efficient. Picking the output off the peak of a half-sine leads to rather peaky output currents, and the power dissipated in the winding resistance goes up as the square of the current. Of course there's also more winding resistance, but Piglet's variation added a output inductor, which also adds winding resistance.

Using a controller IC designed for resonant control. UCC25600

So why is an MCU being discussed in this thread? I assume there is a reason to do this in an MCU rather than a dedicated chip. In that case what makes it hard to do in an MCU? If the math was worked out for a dedicated chip, it must be practical. Or are you saying it's hard math to solve for a low dollar budget? We don't know what the NRE budget is for this project. We just know the recurring costs need to be very low... or it appears that way.

Both switching on and off are simple IO operations and any MCU should do. I presume the speed is required to decide if the FET should be turned on or off -- what exactly are you trying to calculate?

Maybe you should give simple CPLD/FPGA a try? Any safety concerns? What would happen if the MCU misses a deadline?

Best regards, Piotr