On Sunday, July 4, 2021 at 6:51:42 PM UTC-4, Klaus Kragelund wrote:> On 03/07/2021 13.58, 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? > >> > >> Cheers > >> > >> Klaus > > 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. > > > 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 microWhere is it simple to implement? -- 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 5, 20212021-07-05
Reply by ●July 5, 20212021-07-05
On Sunday, July 4, 2021 at 8:46:42 PM UTC-7, gnuarm.del...@gmail.com wrote:> On Sunday, July 4, 2021 at 4:22:35 PM UTC-4, Ed Lee wrote: > > On Sunday, July 4, 2021 at 1:05:11 PM UTC-7, gnuarm.del...@gmail.com wrote: > > > On Sunday, July 4, 2021 at 3:46:16 PM UTC-4, Ed Lee wrote: > > > > On Sunday, July 4, 2021 at 12:41:24 PM UTC-7, gnuarm.del...@gmail.com wrote: > > > > > On Sunday, July 4, 2021 at 3:29:35 PM UTC-4, Ed Lee wrote: > > > > > > On Sunday, July 4, 2021 at 12:16:38 PM UTC-7, lang...@fonz.dk wrote: > > > > > > > søndag den 4. juli 2021 kl. 21.10.20 UTC+2 skrev Ed Lee: > > > > > > > > On Sunday, July 4, 2021 at 12:07:12 PM UTC-7, gnuarm.del...@gmail.com wrote: > > > > > > > > > On Sunday, July 4, 2021 at 2:50:39 PM UTC-4, Ed Lee wrote: > > > > > > > > > > On Sunday, July 4, 2021 at 11:40:11 AM UTC-7, gnuarm.del...@gmail.com wrote: > > > > > > > > > > > On Sunday, July 4, 2021 at 10:54:29 AM UTC-4, Ed Lee wrote: > > > > > > > > > > > > On Sunday, July 4, 2021 at 7:39:50 AM UTC-7, gnuarm.del...@gmail.com wrote: > > > > > > > > > > > > > On Sunday, July 4, 2021 at 10:24:24 AM UTC-4, Ed Lee wrote: > > > > > > > > > > > > > > We are talking about something that can fit in OP's app: 48V (or something, likely battery) to 220V inverter, and power budget matter. > > > > > > > > > > > > > How many LUTs is that? 10, 1,000, 100,000? > > > > > > > > > > > > An 8051 would need more than 7680. > > > > > > > > > > > I don't think that is right, but if so, another CPU would be advised. The sort of stack processors that are often used on FPGAs are as small as 500 LUTs. But why use a processor if it's not required? The point is everything I've heard about this does not require a processor at all. > > > > > > > > > > > > > I designed a circuit that decodes a B120 time code signal to a bit stream (as well as recreates it on the other end) then later added logic to add a digital input multiplexed with the time code as well as multiple sample rate, two channels of audio input and output with mulaw and A-law encoding/decoding and various test functions in a 3kLUT device with no multipliers. > > > > > > > > > > > > > > > > > > > > > > > > > > I've not heard a very complete description of the task (there are often many details left out of such a conversation) but it sounds to me like a 1kLUT device would do the job easily. > > > > > > > > > > > > Perhaps some, but not all features. It would be tough to do 100KHz sampling loop and low long term power budget with FPGA. > > > > > > > > > > > Again, you know nothing about it. A 100 MHz timer is a very low power entity. The power used by any counter is treated as one FF toggling at the clock rate since each FF toggles at half the rate of the next faster one, so clock rate * (1/2 + 1/4 + 1/8...) ~= 1 * clock rate no matter the length. Add a comparator and you get 2 FF equivalent at 100 MHz. Not much current there. Counters are best implemented as down counters using the carry chain for the terminal count down from a variable starting value instead of a comparator so back to 1 FF if that will work in this app (it means you make the decision about cycle length when you load the counter, rather than as it approaches the end of the count). > > > > > > > > > > Perhaps you should read the datasheet also. The ICE40 max out at 48MHz, it won't run at 100MHz. And i never said it need 100MHz counter. I only mention 100KHz sampling loop. At 48MHz, we are talking about mA supply current, not uA. > > > > > > > > > Sorry, you are reading the wrong data. You might be looking at the configuration clock or something. The internal logic runs at hundreds of MHz. Go back and read some more. > > > > > > > > The ICE40 internal RC peak at 48MHz. Stm32 internal RC peak at 180MHz. If we are comparing single chip solution, we should be comparing internal RC. > > > > > > > it has a pll that can do several 100MHz > > > > > > OK, it can go to 180MHz. The question is whether this is set by the bit stream or run-time configuration. Namely, can it switch between 32KHz and 180MHz at run time. > > > > > I don't know what you think you've found that says 180 MHz, but they typically don't give you a toggle rate for FFs as it is a meaningless number in any real design and only used for marketing purposes. Here is the spec on the PLL. > > > > > > > > > > Table 4.18. sysCLOCK PLL TimingParameterDescriptionsConditionsMinMaxUnitfINInput ClockFrequency (REFERENCECLK, EXTFEEDBACK)—10 133MHzfOUTOutput Clock Frequency (PLLOUT)—16 275MHz > > > > > > > > > > Unfortunately that's how it copies from the PDF. If you want to see it clearly find table 4.18. > > > > > > > > > > The max logic speed depends on the logic in your circuit. A decent job of design will let a counter run at the full 275 MHz of the PLL. > > > > Page 34: Maximum global clock of 185MHz. Anyway, the critical issue is whether you can switch between low speed (32KHz) and high speed (185MHz) as in a micro. Micros have registers to write into, not FPGA. > > > Table 4.17. iCE40 Ultra External Switching Characteristics > > > > > > Did you see the word "external" there? That's the max rate on the I/O pin, not the internal clocking. > > > > > > Try reading the data sheets and learn how it works. > > > > > > Why do you want to switch the clock speed? Just run the parts that need 32 kHz from 32 kHz and run the fast parts from the fast clock. What's the point of running the fast parts from a slow clock? You are stuck in the hugely awkward mindset of MCUs which do things in a certain way because they don't have choices. > > > > > > Do you want to generate a 100 kHz waveform from a 32 kHz clock? I thought you wanted to run a slow timer so it would be low power and shut off the clock to the rest of the chip so it would not draw power. Do I have this wrong somehow? >. > > > > > This is always your problem. You can't let go of your mindset or even explain it enough to communicate. > > Your problem is just always making assumptions in your favour. It's very common to run micros at maximum speed to process the loop, then sleep (basically dropping to lowest speed) and wait for timer/interrupt. > Which is exactly what an FPGA would do. You still have zero understanding of the problem and the solution.OK, i am asking you a very simply question. How do you change the clock speed on the fly for the FPGA. It's a simple write to registers in micro.
Reply by ●July 5, 20212021-07-05
On Monday, July 5, 2021 at 1:46:42 PM UTC+10, gnuarm.del...@gmail.com wrote:> On Sunday, July 4, 2021 at 4:22:35 PM UTC-4, Ed Lee wrote: > > On Sunday, July 4, 2021 at 1:05:11 PM UTC-7, gnuarm.del...@gmail.com wrote: > > > On Sunday, July 4, 2021 at 3:46:16 PM UTC-4, Ed Lee wrote: > > > > On Sunday, July 4, 2021 at 12:41:24 PM UTC-7, gnuarm.del...@gmail.com wrote: > > > > > On Sunday, July 4, 2021 at 3:29:35 PM UTC-4, Ed Lee wrote: > > > > > > On Sunday, July 4, 2021 at 12:16:38 PM UTC-7, lang...@fonz.dk wrote: > > > > > > > søndag den 4. juli 2021 kl. 21.10.20 UTC+2 skrev Ed Lee: > > > > > > > > On Sunday, July 4, 2021 at 12:07:12 PM UTC-7, gnuarm.del...@gmail.com wrote: > > > > > > > > > On Sunday, July 4, 2021 at 2:50:39 PM UTC-4, Ed Lee wrote: > > > > > > > > > > On Sunday, July 4, 2021 at 11:40:11 AM UTC-7, gnuarm.del...@gmail.com wrote: > > > > > > > > > > > On Sunday, July 4, 2021 at 10:54:29 AM UTC-4, Ed Lee wrote: > > > > > > > > > > > > On Sunday, July 4, 2021 at 7:39:50 AM UTC-7, gnuarm.del...@gmail.com wrote: > > > > > > > > > > > > > On Sunday, July 4, 2021 at 10:24:24 AM UTC-4, Ed Lee wrote:<snipped tedious bitching >> > Your problem is just always making assumptions in your favour. It's very common to run micros at maximum speed to process the loop, then sleep (basically dropping to lowest speed) and wait for timer/interrupt. > > Which is exactly what an FPGA would do. You still have zero understanding of the problem and the solution.It's what an FPGA might do, if you programmed it to do that.> > The purposed app is 24V to 200V DC/DC, if i read previous posts correctly. The micro or fpga does not need to run constantly,It does.> > especially if there is storage device (battery or cap) involved.There isn't - or at least not enough to give the micro-controller time to take a nap.> > All i am saying is that micro will have better power management than fpga. > > Whatever. You don't know a damn thing about FPGAs, but you are hell bent on proving your assertion regardless of the facts. Since you know your conclusion you don't need toactually do anything to learn about FPGAs. > > Enough said. Enjoy your ignorance.And Rick is happy to ignore the actual problem so that he can keep on telling us that an FPGA is the right solution. PCKB. -- Bill Sloman, Sydney
Reply by ●July 5, 20212021-07-05
On 04/07/2021 01:01, Clive Arthur wrote:> 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.I do that too in firmware, but it is not ideal. When you put in code to trigger/capture the timers, the timing changes, so then you have to leave all the debugging code in for production, or just hope that the timing will still be right when you take it out. And if the compiler gets upgraded, all bets are off. Perhaps you write in pure assembler so you don't care about that. I would be less productive without a compiler.> 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.Clearly you understand that there are some tasks better achieved using a FPGA, as you just admitted to your colleague using one. I just pointed out that you would be wrong to suggest that user-friendly debugging is impossible with a FPGA.
Reply by ●July 5, 20212021-07-05
On Monday, July 5, 2021 at 8:51:42 AM UTC+10, Klaus Kragelund wrote:> On 03/07/2021 13.58, 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? > >> > >> Cheers > >> > >> Klaus > > 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. > > > 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-linearity. That is not simple to implement in a micro.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. -- Bill Sloman, Sydney
Reply by ●July 5, 20212021-07-05
On Monday, July 5, 2021 at 1:13:28 AM UTC-4, Chris Jones wrote:> On 04/07/2021 01:01, Clive Arthur wrote: > > 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. > I do that too in firmware, but it is not ideal. When you put in code to > trigger/capture the timers, the timing changes, so then you have to > leave all the debugging code in for production, or just hope that the > timing will still be right when you take it out. And if the compiler > gets upgraded, all bets are off. Perhaps you write in pure assembler so > you don't care about that. I would be less productive without a compiler.People talk as if coding an MCU is a piece of cake, mostly because this is what they are familiar with. The comfort factor is high even if they know there can be difficult to solve problems mostly having to do with the timing issues that result from sharing a sequential process between multiple, separate functions. In the most simple cases there are no real problems. In more difficult cases the problems can become quite complex. There are methods for managing these issues, but they are often not well understood or implemented. FPGAs on the other hand have separate hardware for nearly everything unless you intentionally design hardware to be shared between tasks such as designing a CPU in the FPGA. So these sorts of problems just don't happen without intent. I have added debugging code to FPGAs before and left it in with no ill effect on performance.> > 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. > > Clearly you understand that there are some tasks better achieved using a > FPGA, as you just admitted to your colleague using one. I just pointed > out that you would be wrong to suggest that user-friendly debugging is > impossible with a FPGA.Because of the ease of extensive simulation in HDL and the ease of adding debugging features that do not impact the thing being debugged (in particular signals brought to I/O pins), I find debugging in FPGAs to be much easier than in MCUs. -- Rick C. +--- Get 1,000 miles of free Supercharging +--- Tesla referral code - https://ts.la/richard11209
Reply by ●July 5, 20212021-07-05
On Monday, July 5, 2021 at 12:01:26 AM UTC-4, Ed Lee wrote:> OK, i am asking you a very simply question. How do you change the clock speed on the fly for the FPGA. It's a simple write to registers in micro.However you wish. The circuit is yours to design. How would you like it to work? I like the fact that you keep talking about a "simple write to registers" as if you were programming a sequential processor with a linear address space like an MCU no matter what the device is. (I would also point out that the clocking controls are some of the most complex in any given MCU, so not often a "simple" register write). How would you adjust the clock speed in a discrete circuit design? An FPGA is just discrete logic inside a chip with programmable interconnects. Do you write to registers in analog designs too? I will repeat the problem. You continue to be stuck in the MCU mindset and are not willing to learn enough about FPGAs to actually understand them. You won't understand them until you stop pretending FPGAs are just different MCUs. Open your mind. Learn something. -- Rick C. +--+ Get 1,000 miles of free Supercharging +--+ Tesla referral code - https://ts.la/richard11209
Reply by ●July 5, 20212021-07-05
On Monday, July 5, 2021 at 6:23:38 AM UTC-7, gnuarm.del...@gmail.com wrote:> On Monday, July 5, 2021 at 12:01:26 AM UTC-4, Ed Lee wrote: > > OK, i am asking you a very simply question. How do you change the clock speed on the fly for the FPGA. It's a simple write to registers in micro. > However you wish. The circuit is yours to design. How would you like it to work? > > I like the fact that you keep talking about a "simple write to registers" as if you were programming a sequential processor with a linear address space like an MCU no matter what the device is. (I would also point out that the clocking controls are some of the most complex in any given MCU, so not often a "simple" register write). How would you adjust the clock speed in a discrete circuit design? An FPGA is just discrete logic inside a chip with programmable interconnects. Do you write to registers in analog designs too? > > I will repeat the problem. You continue to be stuck in the MCU mindset and are not willing to learn enough about FPGAs to actually understand them. You won't understand them until you stop pretending FPGAs are just different MCUs. Open your mind. Learn something.Not if you keep side-stepping the question. I ask a very simple and direct question: How do you reconfig the PLL from the chip within? For micro: RCC_OscInitStruct.OscillatorType = RCC_OSCILLATORTYPE_HSE; RCC_OscInitStruct.HSEState = RCC_HSE_ON; RCC_OscInitStruct.HSEPredivValue = RCC_HSE_PREDIV_DIV1; RCC_OscInitStruct.HSIState = RCC_HSI_ON; RCC_OscInitStruct.PLL.PLLState = RCC_PLL_ON; RCC_OscInitStruct.PLL.PLLSource = RCC_PLLSOURCE_HSE; RCC_OscInitStruct.PLL.PLLMUL = RCC_PLL_MUL6; if (HAL_RCC_OscConfig(&RCC_OscInitStruct) != HAL_OK) { Error_Handler(); }
Reply by ●July 5, 20212021-07-05
On Monday, July 5, 2021 at 11:24:12 AM UTC-4, Ed Lee wrote:> On Monday, July 5, 2021 at 6:23:38 AM UTC-7, gnuarm.del...@gmail.com wrote: > > On Monday, July 5, 2021 at 12:01:26 AM UTC-4, Ed Lee wrote: > > > OK, i am asking you a very simply question. How do you change the clock speed on the fly for the FPGA. It's a simple write to registers in micro. > > However you wish. The circuit is yours to design. How would you like it to work? > > > > I like the fact that you keep talking about a "simple write to registers" as if you were programming a sequential processor with a linear address space like an MCU no matter what the device is. (I would also point out that the clocking controls are some of the most complex in any given MCU, so not often a "simple" register write). How would you adjust the clock speed in a discrete circuit design? An FPGA is just discrete logic inside a chip with programmable interconnects. Do you write to registers in analog designs too? > > > > I will repeat the problem. You continue to be stuck in the MCU mindset and are not willing to learn enough about FPGAs to actually understand them. You won't understand them until you stop pretending FPGAs are just different MCUs. Open your mind. Learn something. > Not if you keep side-stepping the question. I ask a very simple and direct question: How do you reconfig the PLL from the chip within?No side stepping. That was not the question you asked before. Clock control is done using the logic resources inside the FPGA. If you are asking about programming the PLL, every device family is different. You can read about it in the data sheet for the clock distribution or some brands have a separate document just for the PLL. They tend to be more complex than a UART, so just listing the bits in registers doesn't explain it. I don't have any of this info memorized, so you will need to look at the docs yourself. MCUs tend to have clock distribution trees with enables and dividers at various points. FPGAs tend to have a number of global clock paths as well as a few secondary clock paths. You drive them as you wish from a source you control, internal or external, PLL or logic. It's easy to turn off a clock and later turn it back on under control of logic in a different clock domain. You get to design the logic for this, so you are not limited by the preconceptions of the MCU designer. You are used to driving rental cars and know how to put luggage in the trunk. FPGAs are more like a pickup where you can put the luggage inside or in the bed or construct an enclosure in the back for your luggage. Freedom to solve YOUR problems rather than the problems the chip designers expect you to have. -- Rick C. +-+- Get 1,000 miles of free Supercharging +-+- Tesla referral code - https://ts.la/richard11209
Reply by ●July 5, 20212021-07-05
On Monday, July 5, 2021 at 8:51:20 AM UTC-7, gnuarm.del...@gmail.com wrote:> On Monday, July 5, 2021 at 11:24:12 AM UTC-4, Ed Lee wrote: > > On Monday, July 5, 2021 at 6:23:38 AM UTC-7, gnuarm.del...@gmail.com wrote: > > > On Monday, July 5, 2021 at 12:01:26 AM UTC-4, Ed Lee wrote: > > > > OK, i am asking you a very simply question. How do you change the clock speed on the fly for the FPGA. It's a simple write to registers in micro. > > > However you wish. The circuit is yours to design. How would you like it to work? > > > > > > I like the fact that you keep talking about a "simple write to registers" as if you were programming a sequential processor with a linear address space like an MCU no matter what the device is. (I would also point out that the clocking controls are some of the most complex in any given MCU, so not often a "simple" register write). How would you adjust the clock speed in a discrete circuit design? An FPGA is just discrete logic inside a chip with programmable interconnects. Do you write to registers in analog designs too? > > > > > > I will repeat the problem. You continue to be stuck in the MCU mindset and are not willing to learn enough about FPGAs to actually understand them. You won't understand them until you stop pretending FPGAs are just different MCUs. Open your mind. Learn something. > > Not if you keep side-stepping the question. I ask a very simple and direct question: How do you reconfig the PLL from the chip within? > No side stepping. That was not the question you asked before.I asked you how to change the clock speed, which is driven by the PLL. It's the same question. And we, those who know nothing about FPGA, want you to tell us how to do that with the ICE40 FPGA you recommended.> Clock control is done using the logic resources inside the FPGA. If you are asking about programming the PLL, every device family is different. You can read about it in the data sheet for the clock distribution or some brands have a separate document just for the PLL. They tend to be more complex than a UART, so just listing the bits in registers doesn't explain it. I don't have any of this info memorized, so you will need to look at the docs yourself.I know how to do that from the Actel designer, but not from within the chip. If you want us to replace our micro with this ICE40 CPLD/FPGA, you should at least give us the link to do it. Otherwise, it's beyond our knowledge to attempt to use this CPLD/FPGA.
