On Monday, July 5, 2021 at 3:25:17 PM UTC-4, Ed Lee wrote:
> On Monday, July 5, 2021 at 12:20:21 PM UTC-7, gnuarm.del...@gmail.com wrote:
> > On Monday, July 5, 2021 at 3:17:35 PM UTC-4, Ed Lee wrote:
> > > STM32 micros can run at 180MHz, as well as close to zero (while sleeping, but with timer on). Your FPGA PLL can't be reconfigured at will, at least you haven't tell us how to.
> > A PLL can't run with an output close to zero, at least not at low power.. That's true in both the MCU and FPGA. So how do you think you would do this in an MCU? Maybe the answer to that question will show your misconception.
> It's called sleep();

So what does that do? Where is it documented?

We both know what it does is to shut down the PLL and the fast clock and probably shut off the CPU entirely and switch the low power clock circuit on if it was off. In an FPGA you do the same thing which is what I keep telling you. If it kept the CPU running it would not be called sleep(). It would be something like low_power(1) as opposed to low_power( 2 through 7). Yeah, I've seen MCUs with seven low power modes in addition to shutting off the CPU. But every one is different so it's the wild west out there.

Have they standardized sleep modes in ARMs? I suspect not as much of the distinctions are about clocking the peripherals. As I've said before clocking in MCUs can get very complex.

--

Rick C.

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

On Monday, July 5, 2021 at 12:37:28 PM UTC-7, gnuarm.del...@gmail.com wrote:
> On Monday, July 5, 2021 at 3:25:17 PM UTC-4, Ed Lee wrote:
> > On Monday, July 5, 2021 at 12:20:21 PM UTC-7, gnuarm.del...@gmail.com wrote:
> > > On Monday, July 5, 2021 at 3:17:35 PM UTC-4, Ed Lee wrote:
> > > > STM32 micros can run at 180MHz, as well as close to zero (while sleeping, but with timer on). Your FPGA PLL can't be reconfigured at will, at least you haven't tell us how to.
> > > A PLL can't run with an output close to zero, at least not at low power. That's true in both the MCU and FPGA. So how do you think you would do this in an MCU? Maybe the answer to that question will show your misconception.
> > It's called sleep();
> So what does that do? Where is it documented?

This and many other places to talk about sleep and other modes. I also post the codes for changing PLL.

https://www.disk91.com/2018/technology/hardware/stm32-and-low-power-mode/

>
> We both know what it does is to shut down the PLL and the fast clock and probably shut off the CPU entirely and switch the low power clock circuit on if it was off. In an FPGA you do the same thing which is what I keep telling you. If it kept the CPU running it would not be called sleep(). It would be something like low_power(1) as opposed to low_power( 2 through 7). Yeah, I've seen MCUs with seven low power modes in addition to shutting off the CPU. But every one is different so it's the wild west out there.
>
> Have they standardized sleep modes in ARMs? I suspect not as much of the distinctions are about clocking the peripherals. As I've said before clocking in MCUs can get very complex.

Is complexity the reason to switch from MCU to FPGA, so you can't use them at all?

mandag den 5. juli 2021 kl. 19.19.34 UTC+2 skrev Ed Lee:
> On Monday, July 5, 2021 at 10:08:07 AM UTC-7, lang...@fonz.dk wrote:
> > mandag den 5. juli 2021 kl. 19.05.27 UTC+2 skrev Ed Lee:
> > > On Monday, July 5, 2021 at 9:49:43 AM UTC-7, lang...@fonz.dk wrote:
> > > > mandag den 5. juli 2021 kl. 18.16.25 UTC+2 skrev Ed Lee:
> > > > > 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.
> > > > why would you want to change the clock? if you want lowpower standby, run the housekeeping a the slow clock,
> > > > keep the pll and the fast stuff in reset when you don''t need it
> > > Some function needs special speed. For example, usb needs 48MHz exactly. Others need higher speed just for speed and lower speed for power savings.
> > so what is the question?
> How do you change the PLL setting of the ICE40 FPGA, from the chip itself, not from an external programmer?

why would you want to?

On Monday, July 5, 2021 at 1:02:54 PM UTC-7, lang...@fonz.dk wrote:
> mandag den 5. juli 2021 kl. 19.19.34 UTC+2 skrev Ed Lee:
> > On Monday, July 5, 2021 at 10:08:07 AM UTC-7, lang...@fonz.dk wrote:
> > > mandag den 5. juli 2021 kl. 19.05.27 UTC+2 skrev Ed Lee:
> > > > On Monday, July 5, 2021 at 9:49:43 AM UTC-7, lang...@fonz.dk wrote:
> > > > > mandag den 5. juli 2021 kl. 18.16.25 UTC+2 skrev Ed Lee:
> > > > > > 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.
> > > > > why would you want to change the clock? if you want lowpower standby, run the housekeeping a the slow clock,
> > > > > keep the pll and the fast stuff in reset when you don''t need it
> > > > Some function needs special speed. For example, usb needs 48MHz exactly. Others need higher speed just for speed and lower speed for power savings.
> > > so what is the question?
> > How do you change the PLL setting of the ICE40 FPGA, from the chip itself, not from an external programmer?
> why would you want to?

When usb (host or device) is connected, it runs at 48MHz. Otherwise, 180MHz to sample the analog signals, then sleep in between sampling.

On Monday, July 5, 2021 at 3:50:33 PM UTC-4, Ed Lee wrote:
> On Monday, July 5, 2021 at 12:37:28 PM UTC-7, gnuarm.del...@gmail.com wrote:
> > On Monday, July 5, 2021 at 3:25:17 PM UTC-4, Ed Lee wrote:
> > > On Monday, July 5, 2021 at 12:20:21 PM UTC-7, gnuarm.del...@gmail.com wrote:
> > > > On Monday, July 5, 2021 at 3:17:35 PM UTC-4, Ed Lee wrote:
> > > > > STM32 micros can run at 180MHz, as well as close to zero (while sleeping, but with timer on). Your FPGA PLL can't be reconfigured at will, at least you haven't tell us how to.
> > > > A PLL can't run with an output close to zero, at least not at low power. That's true in both the MCU and FPGA. So how do you think you would do this in an MCU? Maybe the answer to that question will show your misconception.
> > > It's called sleep();
> > So what does that do? Where is it documented?
> This and many other places to talk about sleep and other modes. I also post the codes for changing PLL.
>
> https://www.disk91.com/2018/technology/hardware/stm32-and-low-power-mode/

Not really documentation, just some third party web page, but...

Sleep Mode : CPU is stopped, Memory & Register are retained, some peripheral stays active.

Sleep Mode : CPU is stopped but it can be wake-up by any of the active peripherals. Current is down to 400uA @ 16 Mhz to 1mAh
Low Power Sleep Mode : CPU is stopped and the active peripherals are limited and working at reduce frequency. Basically you can program a 32KHz wake-up in this mode. Current is down to 3,2uA

So, does your call sleep(); invoke sleep mode or low power sleep mode? In both cases the CPU is stopped. Why do you ask about changing the frequency of the PLL if you want to stop the CPU? Those are two different things. This call doesn't seem to do anything with the clock or peripherals, so the chip will still be sucking significant current until you shut those off which needs to be done first.

> > We both know what it does is to shut down the PLL and the fast clock and probably shut off the CPU entirely and switch the low power clock circuit on if it was off. In an FPGA you do the same thing which is what I keep telling you. If it kept the CPU running it would not be called sleep(). It would be something like low_power(1) as opposed to low_power( 2 through 7). Yeah, I've seen MCUs with seven low power modes in addition to shutting off the CPU. But every one is different so it's the wild west out there.
> >
> > Have they standardized sleep modes in ARMs? I suspect not as much of the distinctions are about clocking the peripherals. As I've said before clocking in MCUs can get very complex.
> Is complexity the reason to switch from MCU to FPGA, so you can't use them at all?

Certainly simplicity of use is a big reason to use an FPGA. Even small MCUs are complex things these days and have very large manuals. I suppose FPGAs also have lots of documentation, but most of it is not needed since not many people use the SERDES or the various memory interfaces or the... you get the idea. I know the MCU is similar, but I've not seen a simple MCU clocking scheme in the last 20 years. Once they started with the low power modes out the wazoo the clocking became yet another mine field.

FPGA PLLs are probably the same complexity as MCU PLLs. Everything else is whatever you design. I know Lattice parts have special clock managers to let you shut down a clock or to switch between two clocks without glitches. Otherwise you can design your own clock control circuits.

--

Rick C.

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

On Monday, July 5, 2021 at 4:07:53 PM UTC-4, Ed Lee wrote:
> On Monday, July 5, 2021 at 1:02:54 PM UTC-7, lang...@fonz.dk wrote:
> > mandag den 5. juli 2021 kl. 19.19.34 UTC+2 skrev Ed Lee:
> > > On Monday, July 5, 2021 at 10:08:07 AM UTC-7, lang...@fonz.dk wrote:
> > > > mandag den 5. juli 2021 kl. 19.05.27 UTC+2 skrev Ed Lee:
> > > > > On Monday, July 5, 2021 at 9:49:43 AM UTC-7, lang...@fonz.dk wrote:
> > > > > > mandag den 5. juli 2021 kl. 18.16.25 UTC+2 skrev Ed Lee:
> > > > > > > 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.
> > > > > > why would you want to change the clock? if you want lowpower standby, run the housekeeping a the slow clock,
> > > > > > keep the pll and the fast stuff in reset when you don''t need it
> > > > > Some function needs special speed. For example, usb needs 48MHz exactly. Others need higher speed just for speed and lower speed for power savings.
> > > > so what is the question?
> > > How do you change the PLL setting of the ICE40 FPGA, from the chip itself, not from an external programmer?
> > why would you want to?
> When usb (host or device) is connected, it runs at 48MHz. Otherwise, 180MHz to sample the analog signals, then sleep in between sampling.

If you are using USB you can run that at 48 MHz all the time. The rest of the chip can run at 180 MHz all the time. Where's the issue?

--

Rick C.

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

mandag den 5. juli 2021 kl. 22.07.53 UTC+2 skrev Ed Lee:
> On Monday, July 5, 2021 at 1:02:54 PM UTC-7, lang...@fonz.dk wrote:
> > mandag den 5. juli 2021 kl. 19.19.34 UTC+2 skrev Ed Lee:
> > > On Monday, July 5, 2021 at 10:08:07 AM UTC-7, lang...@fonz.dk wrote:
> > > > mandag den 5. juli 2021 kl. 19.05.27 UTC+2 skrev Ed Lee:
> > > > > On Monday, July 5, 2021 at 9:49:43 AM UTC-7, lang...@fonz.dk wrote:
> > > > > > mandag den 5. juli 2021 kl. 18.16.25 UTC+2 skrev Ed Lee:
> > > > > > > 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.
> > > > > > why would you want to change the clock? if you want lowpower standby, run the housekeeping a the slow clock,
> > > > > > keep the pll and the fast stuff in reset when you don''t need it
> > > > > Some function needs special speed. For example, usb needs 48MHz exactly. Others need higher speed just for speed and lower speed for power savings.
> > > > so what is the question?
> > > How do you change the PLL setting of the ICE40 FPGA, from the chip itself, not from an external programmer?
> > why would you want to?
> When usb (host or device) is connected, it runs at 48MHz. Otherwise, 180MHz to sample the analog signals, then sleep in between sampling.

we were talking a 100kHz smps and now you want USB? host even, and 180MHz but why??

On Monday, July 5, 2021 at 1:19:12 PM UTC-7, lang...@fonz.dk wrote:
> mandag den 5. juli 2021 kl. 22.07.53 UTC+2 skrev Ed Lee:
> > On Monday, July 5, 2021 at 1:02:54 PM UTC-7, lang...@fonz.dk wrote:
> > > mandag den 5. juli 2021 kl. 19.19.34 UTC+2 skrev Ed Lee:
> > > > On Monday, July 5, 2021 at 10:08:07 AM UTC-7, lang...@fonz.dk wrote:
> > > > > mandag den 5. juli 2021 kl. 19.05.27 UTC+2 skrev Ed Lee:
> > > > > > On Monday, July 5, 2021 at 9:49:43 AM UTC-7, lang...@fonz.dk wrote:
> > > > > > > mandag den 5. juli 2021 kl. 18.16.25 UTC+2 skrev Ed Lee:
> > > > > > > > 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.
> > > > > > > why would you want to change the clock? if you want lowpower standby, run the housekeeping a the slow clock,
> > > > > > > keep the pll and the fast stuff in reset when you don''t need it
> > > > > > Some function needs special speed. For example, usb needs 48MHz exactly. Others need higher speed just for speed and lower speed for power savings.
> > > > > so what is the question?
> > > > How do you change the PLL setting of the ICE40 FPGA, from the chip itself, not from an external programmer?
> > > why would you want to?
> > When usb (host or device) is connected, it runs at 48MHz. Otherwise, 180MHz to sample the analog signals, then sleep in between sampling.
> we were talking a 100kHz smps and now you want USB? host even, and 180MHz but why??

SMPS is only part of my app. There are other functions involved.

mandag den 5. juli 2021 kl. 22.21.27 UTC+2 skrev Ed Lee:
> On Monday, July 5, 2021 at 1:19:12 PM UTC-7, lang...@fonz.dk wrote:
> > mandag den 5. juli 2021 kl. 22.07.53 UTC+2 skrev Ed Lee:
> > > On Monday, July 5, 2021 at 1:02:54 PM UTC-7, lang...@fonz.dk wrote:
> > > > mandag den 5. juli 2021 kl. 19.19.34 UTC+2 skrev Ed Lee:
> > > > > On Monday, July 5, 2021 at 10:08:07 AM UTC-7, lang...@fonz.dk wrote:
> > > > > > mandag den 5. juli 2021 kl. 19.05.27 UTC+2 skrev Ed Lee:
> > > > > > > On Monday, July 5, 2021 at 9:49:43 AM UTC-7, lang...@fonz.dk wrote:
> > > > > > > > mandag den 5. juli 2021 kl. 18.16.25 UTC+2 skrev Ed Lee:
> > > > > > > > > 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.
> > > > > > > > why would you want to change the clock? if you want lowpower standby, run the housekeeping a the slow clock,
> > > > > > > > keep the pll and the fast stuff in reset when you don''t need it
> > > > > > > Some function needs special speed. For example, usb needs 48MHz exactly. Others need higher speed just for speed and lower speed for power savings.
> > > > > > so what is the question?
> > > > > How do you change the PLL setting of the ICE40 FPGA, from the chip itself, not from an external programmer?
> > > > why would you want to?
> > > When usb (host or device) is connected, it runs at 48MHz. Otherwise, 180MHz to sample the analog signals, then sleep in between sampling.
> > we were talking a 100kHz smps and now you want USB? host even, and 180MHz but why??
> SMPS is only part of my app. There are other functions involved.

if you want to run USB you need a separate 48MHz pll/clock for that, it won't run on 180MHz

On Monday, July 5, 2021 at 4:12:22 PM UTC-7, lang...@fonz.dk wrote:
> mandag den 5. juli 2021 kl. 22.21.27 UTC+2 skrev Ed Lee:
> > On Monday, July 5, 2021 at 1:19:12 PM UTC-7, lang...@fonz.dk wrote:
> > > mandag den 5. juli 2021 kl. 22.07.53 UTC+2 skrev Ed Lee:
> > > > On Monday, July 5, 2021 at 1:02:54 PM UTC-7, lang...@fonz.dk wrote:
> > > > > mandag den 5. juli 2021 kl. 19.19.34 UTC+2 skrev Ed Lee:
> > > > > > On Monday, July 5, 2021 at 10:08:07 AM UTC-7, lang...@fonz.dk wrote:
> > > > > > > mandag den 5. juli 2021 kl. 19.05.27 UTC+2 skrev Ed Lee:
> > > > > > > > On Monday, July 5, 2021 at 9:49:43 AM UTC-7, lang...@fonz.dk wrote:
> > > > > > > > > mandag den 5. juli 2021 kl. 18.16.25 UTC+2 skrev Ed Lee:
> > > > > > > > > > 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.
> > > > > > > > > why would you want to change the clock? if you want lowpower standby, run the housekeeping a the slow clock,
> > > > > > > > > keep the pll and the fast stuff in reset when you don''t need it
> > > > > > > > Some function needs special speed. For example, usb needs 48MHz exactly. Others need higher speed just for speed and lower speed for power savings.
> > > > > > > so what is the question?
> > > > > > How do you change the PLL setting of the ICE40 FPGA, from the chip itself, not from an external programmer?
> > > > > why would you want to?
> > > > When usb (host or device) is connected, it runs at 48MHz. Otherwise, 180MHz to sample the analog signals, then sleep in between sampling.
> > > we were talking a 100kHz smps and now you want USB? host even, and 180MHz but why??
> > SMPS is only part of my app. There are other functions involved.
> if you want to run USB you need a separate 48MHz pll/clock for that, it won't run on 180MHz

I sense the 5V Vusb at startup and set the PLL to 48MHz for data upload to PC. Otherwise, PLL to 180MHz while running on battery and acquiring signal.. The output counter also drive a 12V inverter, but only need to adjust the output counter based on the battery voltage periodically.

On Monday, July 5, 2021 at 8:55:32 PM UTC-4, Ed Lee wrote:
> I sense the 5V Vusb at startup and set the PLL to 48MHz for data upload to PC. Otherwise, PLL to 180MHz while running on battery and acquiring signal. The output counter also drive a 12V inverter, but only need to adjust the output counter based on the battery voltage periodically.

Sounds complicated. Too bad you aren't working in an FPGA were you can dedicate a 48 MHz PLL to the USB and run the rest of the design at whatever rate you want with a second PLL.

--

Rick C.

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

On 04/07/2021 15:32, Don Y wrote:
> On 7/4/2021 6:14 AM, Martin Brown wrote:
>>> 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.
>
> But you can't put an execution time on those lines unless you know the
> *data* values associated.  I.e., you can tell me that the time "around"
> a loop of code; but you can't know how many times that loop will be
> executed and, thus, the total time that it will take to GET PAST it.

You still known how long it takes to execute between the two nodes but
not how many times the nodes doing the controlling will make it execute.
>
>> 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).
>
> Tools like KLEE can be used to help create test cases to exercise branches.
> But, you still can't guarantee that every path WILL be traversed as that
> implies there are no bugs in the code that prevent that from happening:
>
>      if (x odd) {
>          if (x even) {
>              foo;
>          } else {
>              bar;
>          }
>      }
>
> there's no set of inputs that will reach "foo".   So, any metric that
> provides
> a time for that "foo" branch is meaningless -- we KNOW it will never
> happen.

Several of the compilers I use will recognise that at compile time
during dataflow analysis as an unreachable statement. Others will quite
happily optimise the unreachable chunk of code out of existence without
any mention of a problem. Chances are good such code is an error.

One of my favourite teaching compilers codes a hard runtime trap for
invalid pointers or uninitialised variables. You can make it a compile
time error but the default for teaching purposes is to fail at runtime.

--
Regards,
Martin Brown

On 7/6/2021 1:35 AM, Martin Brown wrote:
> On 04/07/2021 15:32, Don Y wrote:
>> On 7/4/2021 6:14 AM, Martin Brown wrote:
>>>> 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.
>>
>> But you can't put an execution time on those lines unless you know the
>> *data* values associated. I.e., you can tell me that the time "around"
>> a loop of code; but you can't know how many times that loop will be
>> executed and, thus, the total time that it will take to GET PAST it.
>
> You still known how long it takes to execute between the two nodes but not how
> many times the nodes doing the controlling will make it execute.

statement1
loopingconstruct
statement2

How long from statement 1 to statement 2?

statement1
longjmp()
statement2

Again?

>>> 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).
>>
>> Tools like KLEE can be used to help create test cases to exercise branches.
>> But, you still can't guarantee that every path WILL be traversed as that
>> implies there are no bugs in the code that prevent that from happening:
>>
>> if (x odd) {
>> if (x even) {
>> foo;
>> } else {
>> bar;
>> }
>> }
>>
>> there's no set of inputs that will reach "foo". So, any metric that provides
>> a time for that "foo" branch is meaningless -- we KNOW it will never happen.
>
> Several of the compilers I use will recognise that at compile time during
> dataflow analysis as an unreachable statement. Others will quite happily
> optimise the unreachable chunk of code out of existence without any mention of
> a problem. Chances are good such code is an error.

No, assume this is ASM. Does the assembler optimize away the statements?

Or, assume the odd/even are two less obvious but mutually exclusive
conditions: "modelA" and "optionB" and some other criteria ensures
modelA and optionB can't coincide.

A compiler (or data flow analysis tool) can only make *deductions*
about things that it knows about.

> One of my favourite teaching compilers codes a hard runtime trap for invalid
> pointers or uninitialised variables. You can make it a compile time error but
> the default for teaching purposes is to fail at runtime.

*Compilers*, nowadays, can pick up most of these sorts of issues.
Even if they can't *conclude* that something is being used
before initialization, they can warn of their *suspicions* in
those cases.

But, that's for compiled code. What if I'm writing *under* that level
(ASM)? What liberties *can* the tool take with my code?

foo: jump fred
jump barney
jump wilma

looks like there are two unreachable statements, there (given there are
no labels associated with the last two). But, what if some other piece
of code overwrites the statement at foo with a NOP? If the jump barney
had been elided as unreachable, the resulting code wouldn't work.

(do you add a switch to tell the tool that the code is immutable?
at what level does the coder assume godlike abilities and responsibilities?)

05.07.21 05:47, Rick C wrote:
>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 micro
>
>Where is it simple to implement?
>
Using a controller IC designed for resonant control. UCC25600

--
Klaus

On Tuesday, July 6, 2021 at 5:13:18 PM UTC-4, Klaus Kragelund wrote:
> 05.07.21 05:47, Rick C wrote:
> >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 micro
> >
> >Where is it simple to implement?
> >
> 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.

--

Rick C.

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

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.

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?

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

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

Best regards, Piotr

Ed Lee wrote:

> But FPGA cannot do the deep sleep as micro. Many micros can sleep in 100uA.

Some FPGAs can go well below that, e.g. MachXO2. And this is a lot for
an MCU; MSP430 can go well below 1uA in sleep mode. They say it is in
the 100nA range, but I have never had the need to go that low, so I
can't confirm.

But the FPGA addresses the hard real time requirements of a switched
converter in a very natural way. In the case of an MCU it is always a PITA.

Best regards, Piotr

Rick C wrote:

> If you are using USB you can run that at 48 MHz all the time. The rest of the chip can run at 180 MHz all the time. Where's the issue?

Anything useful running on an ICE40 at 180MHz? Boy, I would like to see
that. My experience shows it is a decent small FPGA for the 50-100MHz
range, but hardly more without heroic pipelining.

Best regards, Piotr

Ed Lee wrote:

> STM32 micros can run at 180MHz, as well as close to zero (while sleeping, but with timer on). Your FPGA PLL can't be reconfigured at will, at least you haven't tell us how to.

Then use a tiny FPGA that allows dynamic PLL configuration, e.g.
MachXO2. But it is a fancy feature I have never used. What would be the
point of doing so if you can have multiple outputs from a PLL and can
disable the unused ones? And the MachXO2/3 series is much faster than
the ICE which would have trouble working at 180MHz. IO gearboxing that
would allow you to enter the GHz IO switching realm is another feature
out of the box.

Best regards, Piotr

On Sun, 1 Aug 2021 17:07:45 +0200, Piotr Wyderski
<bombald@protonmail.com> wrote:

>Ed Lee wrote:
>
>> But FPGA cannot do the deep sleep as micro. Many micros can sleep in 100uA.
>
>Some FPGAs can go well below that, e.g. MachXO2. And this is a lot for
>an MCU; MSP430 can go well below 1uA in sleep mode. They say it is in
>the 100nA range, but I have never had the need to go that low, so I
>can't confirm.
>
>But the FPGA addresses the hard real time requirements of a switched
>converter in a very natural way. In the case of an MCU it is always a PITA.
>
> Best regards, Piotr
>
>

Analog comparators are cheap and don't need code!

--

John Larkin Highland Technology, Inc

The best designs are necessarily accidental.

On Sunday, August 1, 2021 at 12:30:12 PM UTC-4, jla...@highlandsniptechnology.com wrote:
> On Sun, 1 Aug 2021 17:07:45 +0200, Piotr Wyderski
> <bom...@protonmail.com> wrote:
>
> >Ed Lee wrote:
> >
> >> But FPGA cannot do the deep sleep as micro. Many micros can sleep in 100uA.
> >
> >Some FPGAs can go well below that, e.g. MachXO2. And this is a lot for
> >an MCU; MSP430 can go well below 1uA in sleep mode. They say it is in
> >the 100nA range, but I have never had the need to go that low, so I
> >can't confirm.
> >
> >But the FPGA addresses the hard real time requirements of a switched
> >converter in a very natural way. In the case of an MCU it is always a PITA.
> >
> > Best regards, Piotr
> >
> >
> Analog comparators are cheap and don't need code!

Stupid thread started by Sloman hallucinating about something he can't build in a million years. And all this in response to that mediocre moron Habib posing as an engineer again.

>
>
>
> --
>
> John Larkin Highland Technology, Inc
>
> The best designs are necessarily accidental.

jlarkin@highlandsniptechnology.com wrote:

> Analog comparators are cheap and don't need code!

The need for code I took for granted, don't know Bill's requirements.
But you are sort of right, an analog comparator driven by a DAC turns
out to be a way cheaper and much faster option than an ADC followed by
fully digital processing. Hybrid approaches work best.

Best regards, Piotr

On Sun, 1 Aug 2021 09:34:07 -0700 (PDT), Fred Bloggs
<bloggs.fredbloggs.fred@gmail.com> wrote:

>On Sunday, August 1, 2021 at 12:30:12 PM UTC-4, jla...@highlandsniptechnology.com wrote:
>> On Sun, 1 Aug 2021 17:07:45 +0200, Piotr Wyderski
>> <bom...@protonmail.com> wrote:
>>
>> >Ed Lee wrote:
>> >
>> >> But FPGA cannot do the deep sleep as micro. Many micros can sleep in 100uA.
>> >
>> >Some FPGAs can go well below that, e.g. MachXO2. And this is a lot for
>> >an MCU; MSP430 can go well below 1uA in sleep mode. They say it is in
>> >the 100nA range, but I have never had the need to go that low, so I
>> >can't confirm.
>> >
>> >But the FPGA addresses the hard real time requirements of a switched
>> >converter in a very natural way. In the case of an MCU it is always a PITA.
>> >
>> > Best regards, Piotr
>> >
>> >
>> Analog comparators are cheap and don't need code!
>
>Stupid thread started by Sloman hallucinating about something he can't build in a million years. And all this in response to that mediocre moron Habib posing as an engineer again.

S hasn't designed anything in decades. The only thing he creates now
and silly droning insults.

Being retired is mostly a choice, and that makes some people happy,
but being a bitter old git sounds boring. It doesn't take much space
or money to have a workbench and play with electronics.

I recently did a class-D power amp for my alternator simulator. People
wanted to make that digital, but the PWM loop just took a few analog
parts, and that was easy to Spice first.

https://www.dropbox.com/s/uqcd5vh3aggwxyc/P900_17.jpg?raw=1

https://www.dropbox.com/s/mi8ijm3oqqpbf9q/P902B_3.jpg?raw=1

It's really a hybrid. The basic class-D amp is analog, but the outer
loop, current limiting and impedance control and stuff, is done in an
FPGA and ultimately controlled by a uP. Sort of three levels of
control.

--

John Larkin Highland Technology, Inc

The best designs are necessarily accidental.

On Sun, 1 Aug 2021 18:48:19 +0200, Piotr Wyderski
<bombald@protonmail.com> wrote:

>jlarkin@highlandsniptechnology.com wrote:
>
>> Analog comparators are cheap and don't need code!
>
>The need for code I took for granted, don't know Bill's requirements.
>But you are sort of right, an analog comparator driven by a DAC turns
>out to be a way cheaper and much faster option than an ADC followed by
>fully digital processing. Hybrid approaches work best.
>
> Best regards, Piotr
>
>

My recent class-D amp uses analog stuff for the PWM, and has isolated
ADCs to acquire the output voltage and current. Current limiting is
done in an FPGA, but that's a relatively slow loop. I use two ADUM7703
isolated delta-sigma ADCs per amp. That needs sinc3 filters in the
FPGA, which gives accuracy but limits bandwidth.

--

John Larkin Highland Technology, Inc

The best designs are necessarily accidental.

On 8/1/2021 8:07 AM, Piotr Wyderski wrote:
> Ed Lee wrote:
>
>> But FPGA cannot do the deep sleep as micro. Many micros can sleep in 100uA.
>
> Some FPGAs can go well below that, e.g. MachXO2. And this is a lot for an MCU;
> MSP430 can go well below 1uA in sleep mode. They say it is in the 100nA range,
> but I have never had the need to go that low, so I can't confirm.
>
> But the FPGA addresses the hard real time requirements of a switched converter
> in a very natural way. In the case of an MCU it is always a PITA.

There are MCUs that address those needs. The advantage of an MCU is that
it is considerably easier to get it to do *other* things, as well.