- Sun Aug 07, 2016 8:36 am
#52406
Thanks for your explanation!
I am not completely content though
I am aware of mosfet issues. That is why I am using a mosfet gate driver. The ESP itself will very probably not be able to pump charge in and out of the mosfet's gate fast enough to obtain a reasonable frequency. And even if it does, one would risk blowing the output due the large currents flowing to and fro. So I am always using drivers.
I don't need the whole range of 16 bits resolution, but I do need the lowest 0.0015 % duty factor that comes with it. I have a string of led lights in my son's room, and it needs to be on at night, but only so very slightly that they're only barely visible. It appears one really needs the 16 bit resolution to have an acceptable lowest duty. Currently using the SDK code that's almost acceptable.
I do notice, however, a slight flickering, which I would not expect running at > 100 Hz. I guess that would be the trick the SDK code is using, so it's really running at a lower frequency and my counter is being fooled, right? Without this trick I would see 67 Hz, right?
If I understand correctly, you implemented a frequency+phase-correct PWM implemention (in ATMel terms). They always also offer a "fast" PWM mode, which is not frequency nor phase correct, but twice as fast. The "correct" implementation makes the timer go to top and then back to zero again, which makes the period twice as long, as opposed to the "fast" mode, that makes the timer only go up and then wraps to zero immediately. I think the "fast" mode is sufficient for lighting, I would be interested in having such a mode if indeed it halves the effective period.
Please add an option to use the NMI interrupt, I guess I won't be the only one using software timers...
BTW this morning I did some tests, also with the SDK implemention, using a simple bright blue led connected directly to the mosget gate driver (no power mosfet itself connected) and I could distinctly see the difference between duty cycles 1,2 and 3 (using 16 bits resolution...). This is something I didn't expect, but was quite clear. I didn't test that (yet) with your code.
I am not completely content though
I am aware of mosfet issues. That is why I am using a mosfet gate driver. The ESP itself will very probably not be able to pump charge in and out of the mosfet's gate fast enough to obtain a reasonable frequency. And even if it does, one would risk blowing the output due the large currents flowing to and fro. So I am always using drivers.
I don't need the whole range of 16 bits resolution, but I do need the lowest 0.0015 % duty factor that comes with it. I have a string of led lights in my son's room, and it needs to be on at night, but only so very slightly that they're only barely visible. It appears one really needs the 16 bit resolution to have an acceptable lowest duty. Currently using the SDK code that's almost acceptable.
I do notice, however, a slight flickering, which I would not expect running at > 100 Hz. I guess that would be the trick the SDK code is using, so it's really running at a lower frequency and my counter is being fooled, right? Without this trick I would see 67 Hz, right?
If I understand correctly, you implemented a frequency+phase-correct PWM implemention (in ATMel terms). They always also offer a "fast" PWM mode, which is not frequency nor phase correct, but twice as fast. The "correct" implementation makes the timer go to top and then back to zero again, which makes the period twice as long, as opposed to the "fast" mode, that makes the timer only go up and then wraps to zero immediately. I think the "fast" mode is sufficient for lighting, I would be interested in having such a mode if indeed it halves the effective period.
Please add an option to use the NMI interrupt, I guess I won't be the only one using software timers...
BTW this morning I did some tests, also with the SDK implemention, using a simple bright blue led connected directly to the mosget gate driver (no power mosfet itself connected) and I could distinctly see the difference between duty cycles 1,2 and 3 (using 16 bits resolution...). This is something I didn't expect, but was quite clear. I didn't test that (yet) with your code.
The pin change interrupt is flaky at best, so better use a polling mechanism anyway.
