Hi Julian You could do something like this in software if (input=0){ digitalWrite(pin,High); } else if input=255{ digitalWrite(pin,LOW); } else{ analogWrite(pin,input); } I am sure I read some ware that it’s the analogWrite library that dose this actually doing a digitalWrite instead of setting up PWM if the value is 255 or 0.
I think it is a problem of the arduino analog write, wich looks something like this: pinMode(pin, OUTPUT); if (val == 0) { digitalWrite(pin, LOW); } else if (val == 255) { digitalWrite(pin, HIGH); } else ...... You can find the function in arduino-1.8.3\hardware\arduino\avr\cores\arduino\wiring_analog.c
Correct github.com/arduino/Arduino/blob/master/hardware/arduino/avr/cores/arduino/wiring_analog.c#L112 0 and 255 are not output by way of an oscillator, they just output directly high/low, when using the arduino analogWrite function - it doesn't know or take into account if you inverted the channel. The AVR oscillator controlled output (in at least Fast PWM mode which is what is used here, I don't reall about the other modes) can't hit 0% from memory, it gets close but there's always an on (off when inverted) period. I think this was why Arduino decided to do it this way, people expect 0% and 100% to both be static outputs always off or always on, "almost but not quite off" that the AVR Fast PWM mode can provide isn't good enough. In my opinion Arduino should have flipped the timer output so that it could achieve 0% and almost-but-not-quite 100% instead and done away with the digitalWrite, few people notice a not-quite-100% analogWrite, but not-quite-0% is certainly noticeable. But they will never change it now. @(Julian Ilet) - do you actually need to independently control them? If not, then you can use the complementary outputs for a single oscillator. Consult the datasheet, I'm not sure about any hysteresis which may be necessary to prevent shoot-through on your bridge though. In fact, read the datasheet's timers information, especially output controlled, it's not that complicated and you will be able to make it work exactly how you want.
Yeah that could be it. Julian should do pins with portmode maybe like he did to get the maximum speed video and not having to rely on the translation into assembler, just program in assembler and see what it does.
This is not a quirk of the atmega, because it can and will exactly do what want. The problem is the simple code and the fact that Arduino is hiding too much from the developer. One of the biggest mistakes that the Arduino designers made IMHO. I have seen so many people having problems, because Arduino keeps them from knowing what is actually going on. That said... • Make sure the timer is in *"phase correct PWM"* mode (looks like it is, since the flanks move symmetrically). • *Get rid of the "analogWrite".* Write the timer registers directly. It's much faster than calling analogWrite (since you are changing two values you want that to happen as close together as possible) and more importantly you know what really happens to the timer registers. • *update the timer registers in the timer overflow interrupt.* Otherwise you *will have glitches* that can fry your MOSFETs. If another interrupt triggers just between the two timer value updates, you can end up with two different duty cycles on the outputs for a short time. (again: Arduino isn't helpful here; unless you know exactly what the core and all libraries are doing, there could be a lot of other interrupts happening)
Very good point - getting rid of analogWrite makes a lot of sense. I'll probably put polyfuses in series with the MOSFETs as a precaution, but not totally sure they'll respond quickly enough. Thanks Superdau :)
The issue of the frying MOSFETs (which sounds like a metal band) could be mitigated even without disabling interrupts by limiting the rate of change of the duty cycle. If a non-overlap time of epsilon is necessary for non-frying, then having a steady-state non-overlap of 2*epsilon and limiting changes to 1*epsilon / cycle would prevent smoke release. Even with interrupts, the full update of both outputs needs to execute before the first channel can be updated twice.
You don't need to disable interrupts, just use the one that's there for the timer (ok, since the atmega does not have nested interrupts like an STM32 for example, the result is similar to disabling interrupts). But the other point of using the overflow interrupt is that you know exactly at which point in your PWM you change the value (it's right in the center of the pulse). No need to limit your step size.
Can you seriously not get it working using one of the other PWM peripherals? - it's a while since I've used Atmel but there are 3 seperate PWM peripherals on the ATMega with multiple PWM modes (I assume you've read the datasheet and not just relying on what the Arduino library knows how to set up)
Your project won't need the full span of PWM from 0 to 100%. I'd suggest just finding the safe zone for PWM and not stray outside that. Probably 2%-98%. Hard code the levels outside this is you need to. While using external hardware to do the PWM will work it's overkill and adding to the BOM for no real function. Commercially the extra components would not happen and I think for your project it shouldn't either. Finding issues and concerns, analysing them and deciding if they are important is a large part of the design process.
I, too, thought this might be avoided with software. As for external hardware inversion I'm wondering if the slight delay introduced by it might knock out the critical overlap needed, but I suppose at the frequencies involved this probably won't be an issue in practice.
I suppose this could be worked around with software, but switching the output pins from PWM mode back to regular I/O mode would probably cause a glitch.
Julian Ilett Native arduino libraries swith pin to HIGH or LOW output mode if you set PWM 0 or 255 using analogWrite(); You can see, how they disable pwm in digitalWrite code.
Julian, I was thinking more like if (x == 255) x = 0; and vice versa. I can't imagine that would cause any glitch. Assuming of course that the "PWM error" applies to the two bounary values (0 and 255) only.
Create a function for it void analogWriteB(char value) { switch(value) { case 0: analogWrite(3, 255); break; case 255: analogWrite(3, 0); break; default: analogWrite(3, value); break; } }
Hello, my name is NIRANJAN, I am not getting proper inverting pwm from Arduino Uno, if you have any methods to invert the pwm signal practically. Please let me know if any have.
Thanks for sharing. There are an alternative to a 7400, and that is a MOSFET and a resistor to power supply. end many a sourcefolower afterwords. if you want a low impedance to drive the power MOSFET.. best of luck 😀👍
EDIT: Lots of people beat me to it, but one extra copy of the same thing can only increase the odds of Julian seeing it... It's actually a bug in the analogWrite function. For values 0 and 255, it just digitalWrite's the pin low or high respectively. Add your own inverted wrapper code around analogWrite which handles these two values the opposite way and only use analogWrite (utilising PWM hardware) for 1-254.
I'll second the comments about ditching the Arduino libraries, I'm currently in the process of building a HV high power MPPT controller. I decided to go with talking to the AVR directly using the registers and timers, I first used Fast PWM mode and encountered some nasty spikes when on 0% duty cycle, once I switched to Phase Correct mode they went away and my MOSFET thanked me. This is actually a documented issue in the ATMEL chip data sheet. Not sure about the issues with the inverted PWM but I think Phase Correct would solve the larger problems.
Software workaround? When you get to a writing 0 or 255 PWM values, switch off the inverted PWM and write the corresponding 0 or 1 to the port, for 1-254, switch inverted PWM back on. There might be a few milliseconds of glitching that you'd need to take care of the order of writing so as not to short with both MOSFETs switched on!
Julian are the signals for example if A is at 10% duty cycle and b is at 80%.. mosfet B shuts off before mosfet B . is this correct . Like you I can not have both mosfets on at the same time and I would like to have the code automatically adjust duty cycle for both A and B . for example when I turn the Pot as A adjust lets say to 10% can be also adjust to lets say 88% or what ever max value I want .
Julian; a serious question by someone to whom programming might as well be written in heiroglyphics: Why is an Arduino needed for this? Surely it could be achieved more simply, reliably, and for a lower cost, by using dedicated hardware? Thanks.
I'm wondering if this isn't a bug but a feature - if you push the PWM to to the point where it's no longer a "P", it turns off. That is, the inverted and non-inverted outputs go to the same value which *turns off* the driven load rather than apply pure DC across it.
JULIAN ILETT YOU SHOULD DEFINITELY MAKE A VIDEO EXPLAINING HOW TO BUILD A CIRCUIT, CODE, APP AND ZERO CROSSING CIRCUIT WHICH CAN CONTROL AT LEAST 5 AC LIGHT BULBS AND BE ABLE TO NOT ONLY TURN THEM ON/OFF BUT DIM EACH ONE OF THEM SEPARATELY VIA BLUETOOTH HC-06 AND ANDROID APP. THAT WILL BE A CHALLENGE!!!
I think that's a bug of the arduino library. Tried talking directly to the registers? :) I seem to recall the can't really go 100% on or off but ridiculously close since it still has to pwm
This is a trivial software fix. Just requires a small patch to the library or even just a bit of code in the sketch itself to work around the issue. Why go to all the trouble you are doing when it can be solved in literally minutes? I thought you were smart Julian.
You can solve it un software. It is as easy as adding 2 if. If value= 255 then send 0 else if value=0 then send 255 else send value It is dirty but should solve this stupid problem.
would it be possible to keep the wave form in it's "stock" form and swap the n-type and p-type fets for that half of the bridge. In that arrangement the signal would interact in an inverted say even at extreme duty cycles.
you could fix tat in software. give yourself a 5 percent or less window and if you are within your percentage of fully on turn the pin on and just the opposite for almost fully off. no external hardware.
is there any reason why you can't just have a bit of code that manages your inverted input so that 0 = 255 and 255 = 0, but the values in between are left intact?
try inverting channel A with TCCR2A |= 0xC0, as per the datasheet: "A special case occurs when OCR2A equals TOP and COM2A1 is set. In this case, the Compare Match is ignored, but the set or clear is done at TOP." whereas with TCCR2A |= 0x30 channel B is inverted with the note: "A special case occurs when OCR2B equals TOP and COM2B1 is set. In this case, the Compare Match is ignored, but the set or clear is done at TOP." *If* I interpret this correctly, when channel B is inverted the reset is done at the *TOP* of the triangle wave used to generate the PWM waveform, while when channel A is inverted the reset is done at the *BOTTOM* of the triangle wave. This *might* fix the issue... no promises or, try editing wiring_analog.c "You can find the function in arduino-1.8.3\hardware\arduino\avr\cores\arduino\wiring_analog.c" (Meiestrix) remove the if (val == 0) { digitalWrite(pin, LOW); } else if (val == 255) { digitalWrite(pin, HIGH); } else { (and if you care, fix the indentation issues) or, as other people have said just use some software logic, i.e.: if (valForInvertedPin == 100%dutyCycleAfterInvert){ digitalWrite(invertedPin = HIGH); } else if (valForInvertedPin == 0%dutyCycleAfterInvert){ digitalWrite(invertedPin = LOW); ) else { analogWrite(pinNumber, valForInvertedPin); } woo, longest YT comment i've written ever. lol
Is this the knitting pattern for gloves or the one for for mittens? Just kidding! I found the theory and mathematics of electrons easier to study, back in the mid-70's, than the occult arts of programming. It never fails to amaze me that people can actually understand comments such as yours. I respect that.
Some psuedocode for you Just before the write to the inverted PWM if valueFromPotenetiometer = 255 { valueFromPotenetiometer = 0 } else if valueFromPotenetiometer = 0 { valueFromPotenetiometer = 255 } // write value to PinX
Ok looking at the code this is a simple manner. assuming you are using pin 3 for the inverted PWM, if not substitute for the proper numbers. if (analogRead(A1) == 255) { analogWrite(3, 0); } else if (analogRead(A1) == 0) ( analogWrite(3, 255); } else { analogWrite(3, analogRead(A1) / 4); }
Looks tweekable in software? I think it's how it's handling the edge cases of 0x00 and 0xFF (if for example it was 8 bit resolution) so you could patch the own driver source code 👍
Hmmm. Do you think the value the pot is generating is a range from 0 to 1 (which serves as the frequency seed for the duty cycle). If that's the case, it would explain what's happening here. Since !0 is true/on (which causes it to go from almost always off as you approach 0 to suddenly on when you reach 0) and !1 is false/off (so it goes from almost always on as you approach 1 to suddenly off when you reach 1). So when you hit the limit (0 or 1) it does the opposite of what is expected. So it seems like you could write a condition to check for true or falseness... and while not true or false, invert the value... else return the value. Here's hoping I said that the right way around. In my head I'm actually seeing something like: if(value !=0 || value !=1) return invert(value) else return value;
I'll suggest you to try the IR2110 MOSFET driver, it can drive the high side switch with minimal amount of additional components. Something like this: PWM from Arduino -> hardware inverter -> IR2110 driver. Your DCOI driver is fine, optocouplers are not blazing fast, but neither is your maximum PWM frequency :) I'm curious to see how fast the Arduino will react to the change of input and output, in other words - how good the load and line regulation will be. I'm waiting for the next one!
I've offered you source code, I've suggested the right chip. I've got a whole prototype all wired up that I've offered to post you - a functional MuPPet, having solved most of these problems, fully documented and open. Please, just let me help you. I've faced all these problems you are having. I know how to do this. But I can't quite finish it off - take my work, combine it with your own.
Julian Ilett Because I'm good, but not quite good enough. Also because my attention moved on to other things - mostly radio. I really just hadn't the time, and I did manage to get it working pretty well.
You could just just use a wrapper function for the inverted channel read value of the trim pot, that both inverters the value (fixes the direction issue) and at the limits, sets the value to the opposite max/min value. Pseudo c-code: int invertedValue (int i){ int r = MAX_DURATION - i; if ( i >= MAX_TRIM) { r = MIN_DURATION; } else if ( i
The analogWrite() function has special cases for 0 and 255 inputs. The Arduino core doesn't know that you jiggered with the hardware registers to invert the signal. You could copy analogWrite() from the core and write a version for inverted PWM.
It makes perfect sense when you remember you inverted the output; you're now dealing with negative logic. When you turn the (bottom) pot CW, you're increasing the duty cycle w/respect to 0 volts (which is logic high now), and when you turn the pot CCW, you're decreasing the duty cycle w/respect to 0 volts, so full off (false) = +5 volts! HTH - Cheerios!
I think there's no need to go with external hardware. You haven't begin using the core features of the Atmel chip to tweak the PWM outputs. In particular, some of this is described on the 'Secrets of Arduino PWM' page at www.arduino.cc/en/Tutorial/SecretsOfArduinoPWM. Besides that, your off/on inverting problem is trivial to solve in code, since you won't be directly driving pulse widths from an analog input -- they will come from voltage feedback detection. You'll have to dig into the datasheet further anyway. Your Buck/Boost configuration will require synchronization between 4 PWM channels, and that's only achievable by directly calibrating the relative phase of the input and output sets of PWM outputs.
Well, what ever abstaction layer (arduino stuff) you are using has a bit of extra code at the extremes (that is 0% and 100%). Naturally the AVR timers can only produce one extreme. Default is 0%. If you set it to max duty, you still have a teensy tiny pulse which is one timer tick long. This is becuase of the way the timer handles the counter register overrun. To circumvent this the arduino code just disables the timer at the extremes and forces the pin to the wanted static state. Obviously something goes wrong at that point when inverting the channel. One thing tho. Please do not use the arduino IDE. This is a good example. It realy disconnects you from the hardware. So even if it is not strictly arduinos fault (like in this case) you do not have the insight to understand what is going on. AVR is realy not a complicated arch. Just RTFM. They even give you example code right in the datasheet!
Julian, Instead of fixing this anomaly externally, why not just fix it in the Arduino code? I believe you could nest two conditionals in the main loop and drive the output the way you need it at the top and bottom end of the PWM range. Seems much easier than wiring around this issue -- at least to me. Just wondering...Mike p.s. regardless of how you choose to address the issue, I'll certainly enjoy watching & learning from you talking the rest of us through your thought process. love your videos & please keep them coming.
It might be interesting to see a disassembly of the target code, to see what the Arduino compiler is doing with the source. I have a feeling that it is getting in the way and complicating matters.
Hi Julian, How will you handle the required overlap with external components? Second question: would you ever need 100% PWM on or off in this boost-or-buck converter? Does it then still work? I can imagine the converter to have certain specs for maximum/minimum conversion. I may be mistaken, but I imagine there is no real need for 100 or 0 percent PWM on the two gates in either buck or boost modes. Another suggestion was to just use complimentary mosfets. In that case you wouldn't have to use software inversion and perhaps not be bothered by this weird PWM-effect.
I'll still use the B channel to produce the non-overlap but with an external inversion. 100% MOSFET on in buck mode would be zero voltage reduction (minus losses).
Clear. Would that external inversion by achievable using complementary mosfets, or would that require another (more complicated) setup? (such as a charge pump like you have in the original MuPPeT)
even if you dont need 0 or 100%, if you set PWM to zero, you should expect 0V, not 5V... that can cause some nasty smoking from components, you expect closed mosfet, but it opens fully.
Hi Julian
You could do something like this in software
if (input=0){
digitalWrite(pin,High);
}
else if input=255{
digitalWrite(pin,LOW);
}
else{
analogWrite(pin,input);
}
I am sure I read some ware that it’s the analogWrite library that dose this actually
doing a digitalWrite instead of setting up PWM if the value is 255 or 0.
sorry, not working
I think it is a problem of the arduino analog write, wich looks something like this:
pinMode(pin, OUTPUT);
if (val == 0) {
digitalWrite(pin, LOW);
}
else if (val == 255) {
digitalWrite(pin, HIGH);
}
else
......
You can find the function in arduino-1.8.3\hardware\arduino\avr\cores\arduino\wiring_analog.c
Correct
github.com/arduino/Arduino/blob/master/hardware/arduino/avr/cores/arduino/wiring_analog.c#L112
0 and 255 are not output by way of an oscillator, they just output directly high/low, when using the arduino analogWrite function - it doesn't know or take into account if you inverted the channel.
The AVR oscillator controlled output (in at least Fast PWM mode which is what is used here, I don't reall about the other modes) can't hit 0% from memory, it gets close but there's always an on (off when inverted) period.
I think this was why Arduino decided to do it this way, people expect 0% and 100% to both be static outputs always off or always on, "almost but not quite off" that the AVR Fast PWM mode can provide isn't good enough.
In my opinion Arduino should have flipped the timer output so that it could achieve 0% and almost-but-not-quite 100% instead and done away with the digitalWrite, few people notice a not-quite-100% analogWrite, but not-quite-0% is certainly noticeable.
But they will never change it now.
@(Julian Ilet) - do you actually need to independently control them? If not, then you can use the complementary outputs for a single oscillator. Consult the datasheet, I'm not sure about any hysteresis which may be necessary to prevent shoot-through on your bridge though. In fact, read the datasheet's timers information, especially output controlled, it's not that complicated and you will be able to make it work exactly how you want.
Yeah that could be it. Julian should do pins with portmode maybe like he did to get the maximum speed video and not having to rely on the translation into assembler, just program in assembler and see what it does.
It's the result of mixing direct port access and Arduino code. The Arduino code doesn't know the signal is inverted.
This is not a quirk of the atmega, because it can and will exactly do what want. The problem is the simple code and the fact that Arduino is hiding too much from the developer. One of the biggest mistakes that the Arduino designers made IMHO. I have seen so many people having problems, because Arduino keeps them from knowing what is actually going on. That said...
• Make sure the timer is in *"phase correct PWM"* mode (looks like it is, since the flanks move symmetrically).
• *Get rid of the "analogWrite".* Write the timer registers directly. It's much faster than calling analogWrite (since you are changing two values you want that to happen as close together as possible) and more importantly you know what really happens to the timer registers.
• *update the timer registers in the timer overflow interrupt.* Otherwise you *will have glitches* that can fry your MOSFETs. If another interrupt triggers just between the two timer value updates, you can end up with two different duty cycles on the outputs for a short time. (again: Arduino isn't helpful here; unless you know exactly what the core and all libraries are doing, there could be a lot of other interrupts happening)
Very good point - getting rid of analogWrite makes a lot of sense. I'll probably put polyfuses in series with the MOSFETs as a precaution, but not totally sure they'll respond quickly enough. Thanks Superdau :)
Using Atmel Studio might be helpful.
The issue of the frying MOSFETs (which sounds like a metal band) could be mitigated even without disabling interrupts by limiting the rate of change of the duty cycle. If a non-overlap time of epsilon is necessary for non-frying, then having a steady-state non-overlap of 2*epsilon and limiting changes to 1*epsilon / cycle would prevent smoke release. Even with interrupts, the full update of both outputs needs to execute before the first channel can be updated twice.
You don't need to disable interrupts, just use the one that's there for the timer (ok, since the atmega does not have nested interrupts like an STM32 for example, the result is similar to disabling interrupts). But the other point of using the overflow interrupt is that you know exactly at which point in your PWM you change the value (it's right in the center of the pulse). No need to limit your step size.
Can you seriously not get it working using one of the other PWM peripherals? - it's a while since I've used Atmel but there are 3 seperate PWM peripherals on the ATMega with multiple PWM modes (I assume you've read the datasheet and not just relying on what the Arduino library knows how to set up)
don't overthink this. just add constrain code and keep it with the 1-99%. Boom. done. No extra failure points required.
Why didn't you just swap the wiring around, so that you don't have to do the clockwise and anti clock wise thing!
"analogWrite" -- there's your problem right there. just poke the registers directly and the problem will vanish.
Your project won't need the full span of PWM from 0 to 100%.
I'd suggest just finding the safe zone for PWM and not stray outside that. Probably 2%-98%.
Hard code the levels outside this is you need to.
While using external hardware to do the PWM will work it's overkill and adding to the BOM for no real function.
Commercially the extra components would not happen and I think for your project it shouldn't either.
Finding issues and concerns, analysing them and deciding if they are important is a large part of the design process.
Why (or rather when), do you nees 0 or 100% "PWM"? And if you need it, it could be done in software with a couple of ifs. :)
I, too, thought this might be avoided with software. As for external hardware inversion I'm wondering if the slight delay introduced by it might knock out the critical overlap needed, but I suppose at the frequencies involved this probably won't be an issue in practice.
I suppose this could be worked around with software, but switching the output pins from PWM mode back to regular I/O mode would probably cause a glitch.
Julian Ilett
Native arduino libraries swith pin to HIGH or LOW output mode if you set PWM 0 or 255 using analogWrite();
You can see, how they disable pwm in digitalWrite code.
Julian, I was thinking more like if (x == 255) x = 0; and vice versa. I can't imagine that would cause any glitch. Assuming of course that the "PWM error" applies to the two bounary values (0 and 255) only.
Or why not just analogWrite(3, (1023 - analogRead(A1))/4)
Ah - Bad luck! I hate it when this sort of thing happens. I resorted to a PCA9685 last time I hit a microprocessor PWM glitch :/
why not simply use []analogWrite (3, 255 - analogRead(A1) / 4)[] that way you "invert" the input without additional components.
My thought exactly
Create a function for it
void analogWriteB(char value)
{
switch(value)
{
case 0:
analogWrite(3, 255);
break;
case 255:
analogWrite(3, 0);
break;
default:
analogWrite(3, value);
break;
}
}
Hello, my name is NIRANJAN, I am not getting proper inverting pwm from Arduino Uno, if you have any methods to invert the pwm signal practically. Please let me know if any have.
Thanks for sharing. There are an alternative to a 7400, and that is a MOSFET and a resistor to power supply. end many a sourcefolower afterwords. if you want a low impedance to drive the power MOSFET.. best of luck 😀👍
EDIT: Lots of people beat me to it, but one extra copy of the same thing can only increase the odds of Julian seeing it...
It's actually a bug in the analogWrite function. For values 0 and 255, it just digitalWrite's the pin low or high respectively. Add your own inverted wrapper code around analogWrite which handles these two values the opposite way and only use analogWrite (utilising PWM hardware) for 1-254.
I'll second the comments about ditching the Arduino libraries, I'm currently in the process of building a HV high power MPPT controller. I decided to go with talking to the AVR directly using the registers and timers, I first used Fast PWM mode and encountered some nasty spikes when on 0% duty cycle, once I switched to Phase Correct mode they went away and my MOSFET thanked me. This is actually a documented issue in the ATMEL chip data sheet. Not sure about the issues with the inverted PWM but I think Phase Correct would solve the larger problems.
Software workaround? When you get to a writing 0 or 255 PWM values, switch off the inverted PWM and write the corresponding 0 or 1 to the port, for 1-254, switch inverted PWM back on. There might be a few milliseconds of glitching that you'd need to take care of the order of writing so as not to short with both MOSFETs switched on!
Julian are the signals for example if A is at 10% duty cycle and b is at 80%.. mosfet B shuts off before mosfet B . is this correct . Like you I can not have both mosfets on at the same time and I would like to have the code automatically adjust duty cycle for both A and B . for example when I turn the Pot as A adjust lets say to 10% can be also adjust to lets say 88% or what ever max value I want .
Julian; a serious question by someone to whom programming might as well be written in heiroglyphics: Why is an Arduino needed for this? Surely it could be achieved more simply, reliably, and for a lower cost, by using dedicated hardware? Thanks.
void PWM(int n)
{
int ontime,offtime;
ontime=n;
offtime=(32768-n);
set_one();
while(ontime>0)
{
ontime--);
}
set_zero();
while(offtime>0)
{
offtime--);
}
}
I'm wondering if this isn't a bug but a feature - if you push the PWM to to the point where it's no longer a "P", it turns off. That is, the inverted and non-inverted outputs go to the same value which *turns off* the driven load rather than apply pure DC across it.
JULIAN ILETT YOU SHOULD DEFINITELY MAKE A VIDEO EXPLAINING HOW TO BUILD A CIRCUIT, CODE, APP AND ZERO CROSSING CIRCUIT WHICH CAN CONTROL AT LEAST 5 AC LIGHT BULBS AND BE ABLE TO NOT ONLY TURN THEM ON/OFF BUT DIM EACH ONE OF THEM SEPARATELY VIA BLUETOOTH HC-06 AND ANDROID APP. THAT WILL BE A CHALLENGE!!!
I think that's a bug of the arduino library. Tried talking directly to the registers? :)
I seem to recall the can't really go 100% on or off but ridiculously close since it still has to pwm
This is a trivial software fix. Just requires a small patch to the library or even just a bit of code in the sketch itself to work around the issue. Why go to all the trouble you are doing when it can be solved in literally minutes? I thought you were smart Julian.
You can solve it un software. It is as easy as adding 2 if.
If value= 255 then send 0
else if value=0 then send 255
else send value
It is dirty but should solve this stupid problem.
would it be possible to keep the wave form in it's "stock" form and swap the n-type and p-type fets for that half of the bridge. In that arrangement the signal would interact in an inverted say even at extreme duty cycles.
If you're driving an AC circuit anyhow, why do you care for those extreme DC cases in the first place instead of just disallowing them altogether?
Driving the Mosfets hard on or off will result in no boost or buck as inductor will stop operating as opposed to a H bridge motor drive...
I had the same issue with a PIC18F4620. Fixed it in software using the TMR2 interrupt set at high priority.
you could fix tat in software. give yourself a
5 percent or less window and if you are within your percentage of fully on turn the pin on and just the opposite for almost fully off. no external hardware.
is there any reason why you can't just have a bit of code that manages your inverted input so that 0 = 255 and 255 = 0, but the values in between are left intact?
Thats for use with p-channel mosfets. So 75% normal PWM = 25% pChannel PWM
I expect some smoking MOSFET while debuggin' dis! xDD
you will need AT90PWM3B (but no arduino) or STM32F334
Why not sort it in software, when the duty cycle gets to close to 100% just show hi or low.
Fix the problem in software and save an additional hardware component.
makes me wonder if it's an Arduino IDE/compiler issue....
but in your final project you can take into account this quirk in software.
Inverted signal is supposed to be narrower than the positive, doesn't it?
Maybe just using AVR Timer and Interrupt to output pwm ?
This can be easily fixed in software, see other comments.
try inverting channel A with TCCR2A |= 0xC0, as per the datasheet: "A special case occurs when OCR2A equals TOP and COM2A1 is set. In this case, the Compare Match is ignored, but the set or clear is done at TOP." whereas with TCCR2A |= 0x30 channel B is inverted with the note: "A special case occurs when OCR2B equals TOP and COM2B1 is set. In this case, the Compare Match is ignored, but the set or clear is done at TOP."
*If* I interpret this correctly, when channel B is inverted the reset is done at the *TOP* of the triangle wave used to generate the PWM waveform, while when channel A is inverted the reset is done at the *BOTTOM* of the triangle wave. This *might* fix the issue... no promises
or, try editing wiring_analog.c "You can find the function in arduino-1.8.3\hardware\arduino\avr\cores\arduino\wiring_analog.c" (Meiestrix) remove the
if (val == 0)
{
digitalWrite(pin, LOW);
}
else if (val == 255)
{
digitalWrite(pin, HIGH);
}
else
{
(and if you care, fix the indentation issues)
or, as other people have said just use some software logic, i.e.:
if (valForInvertedPin == 100%dutyCycleAfterInvert){
digitalWrite(invertedPin = HIGH);
}
else if (valForInvertedPin == 0%dutyCycleAfterInvert){
digitalWrite(invertedPin = LOW);
)
else {
analogWrite(pinNumber, valForInvertedPin);
}
woo, longest YT comment i've written ever. lol
Is this the knitting pattern for gloves or the one for for mittens? Just kidding! I found the theory and mathematics of electrons easier to study, back in the mid-70's, than the occult arts of programming. It never fails to amaze me that people can actually understand comments such as yours. I respect that.
Some psuedocode for you
Just before the write to the inverted PWM
if valueFromPotenetiometer = 255
{
valueFromPotenetiometer = 0
}
else if valueFromPotenetiometer = 0
{
valueFromPotenetiometer = 255
}
// write value to PinX
Ok looking at the code this is a simple manner.
assuming you are using pin 3 for the inverted PWM, if not substitute for the proper numbers.
if (analogRead(A1) == 255)
{
analogWrite(3, 0);
}
else if (analogRead(A1) == 0)
(
analogWrite(3, 255);
}
else
{
analogWrite(3, analogRead(A1) / 4);
}
Looks tweekable in software? I think it's how it's handling the edge cases of 0x00 and 0xFF (if for example it was 8 bit resolution) so you could patch the own driver source code 👍
Hmmm. Do you think the value the pot is generating is a range from 0 to 1 (which serves as the frequency seed for the duty cycle). If that's the case, it would explain what's happening here. Since !0 is true/on (which causes it to go from almost always off as you approach 0 to suddenly on when you reach 0) and !1 is false/off (so it goes from almost always on as you approach 1 to suddenly off when you reach 1). So when you hit the limit (0 or 1) it does the opposite of what is expected. So it seems like you could write a condition to check for true or falseness... and while not true or false, invert the value... else return the value.
Here's hoping I said that the right way around. In my head I'm actually seeing something like:
if(value !=0 || value !=1) return invert(value) else return value;
PS. I don't actually code for hardware, so forgive me if I'm off my nut. LOL
all you need to do is to put a if statement to 100 and 0 %
i need oscilloscope program for ardunio uno
why not just use an inverting FET driver? i assume you'll be using a fet driver anyway
Yes, the FET driver I'm planning to use does have an inverting option - I'll probably use that :)
I'll suggest you to try the IR2110 MOSFET driver, it can drive the high side switch with minimal amount of additional components. Something like this: PWM from Arduino -> hardware inverter -> IR2110 driver.
Your DCOI driver is fine, optocouplers are not blazing fast, but neither is your maximum PWM frequency :)
I'm curious to see how fast the Arduino will react to the change of input and output, in other words - how good the load and line regulation will be. I'm waiting for the next one!
interesting for sure.
I've offered you source code, I've suggested the right chip. I've got a whole prototype all wired up that I've offered to post you - a functional MuPPet, having solved most of these problems, fully documented and open. Please, just let me help you.
I've faced all these problems you are having. I know how to do this. But I can't quite finish it off - take my work, combine it with your own.
Why can't you finish it off?
Julian Ilett Because I'm good, but not quite good enough. Also because my attention moved on to other things - mostly radio. I really just hadn't the time, and I did manage to get it working pretty well.
You really need better mic when doing screencapturing.. :F
Nothing wrong with his audio.
You could just just use a wrapper function for the inverted channel read value of the trim pot, that both inverters the value (fixes the direction issue) and at the limits, sets the value to the opposite max/min value. Pseudo c-code:
int invertedValue (int i){
int r = MAX_DURATION - i;
if ( i >= MAX_TRIM) {
r = MIN_DURATION;
} else if ( i
The analogWrite() function has special cases for 0 and 255 inputs. The Arduino core doesn't know that you jiggered with the hardware registers to invert the signal. You could copy analogWrite() from the core and write a version for inverted PWM.
It makes perfect sense when you remember you inverted the output; you're now dealing with negative logic. When you turn the (bottom) pot CW, you're increasing the duty cycle w/respect to 0 volts (which is logic high now), and when you turn the pot CCW, you're decreasing the duty cycle w/respect to 0 volts, so full off (false) = +5 volts! HTH - Cheerios!
I think there's no need to go with external hardware. You haven't begin using the core features of the Atmel chip to tweak the PWM outputs. In particular, some of this is described on the 'Secrets of Arduino PWM' page at www.arduino.cc/en/Tutorial/SecretsOfArduinoPWM. Besides that, your off/on inverting problem is trivial to solve in code, since you won't be directly driving pulse widths from an analog input -- they will come from voltage feedback detection.
You'll have to dig into the datasheet further anyway. Your Buck/Boost configuration will require synchronization between 4 PWM channels, and that's only achievable by directly calibrating the relative phase of the input and output sets of PWM outputs.
trivial software fix.
Well, what ever abstaction layer (arduino stuff) you are using has a bit
of extra code at the extremes (that is 0% and 100%). Naturally the AVR
timers can only produce one extreme. Default is 0%. If you set it to max
duty, you still have a teensy tiny pulse which is one timer tick long.
This is becuase of the way the timer handles the counter register
overrun. To circumvent this the arduino code just disables the timer at
the extremes and forces the pin to the wanted static state. Obviously
something goes wrong at that point when inverting the channel.
One thing tho. Please do not use the arduino IDE. This is a good
example. It realy disconnects you from the hardware. So even if it is
not strictly arduinos fault (like in this case) you do not have the
insight to understand what is going on. AVR is realy not a complicated
arch. Just RTFM. They even give you example code right in the
datasheet!
Julian, Instead of fixing this anomaly externally, why not just fix it in the Arduino code? I believe you could nest two conditionals in the main loop and drive the output the way you need it at the top and bottom end of the PWM range. Seems much easier than wiring around this issue -- at least to me. Just wondering...Mike
p.s. regardless of how you choose to address the issue, I'll certainly enjoy watching & learning from you talking the rest of us through your thought process. love your videos & please keep them coming.
It might be interesting to see a disassembly of the target code, to see what the Arduino compiler is doing with the source. I have a feeling that it is getting in the way and complicating matters.
Hi Julian,
How will you handle the required overlap with external components?
Second question: would you ever need 100% PWM on or off in this boost-or-buck converter? Does it then still work?
I can imagine the converter to have certain specs for maximum/minimum conversion. I may be mistaken, but I imagine there is no real need for 100 or 0 percent PWM on the two gates in either buck or boost modes.
Another suggestion was to just use complimentary mosfets. In that case you wouldn't have to use software inversion and perhaps not be bothered by this weird PWM-effect.
I'll still use the B channel to produce the non-overlap but with an external inversion.
100% MOSFET on in buck mode would be zero voltage reduction (minus losses).
Clear. Would that external inversion by achievable using complementary mosfets, or would that require another (more complicated) setup? (such as a charge pump like you have in the original MuPPeT)
even if you dont need 0 or 100%, if you set PWM to zero, you should expect 0V, not 5V...
that can cause some nasty smoking from components, you expect closed mosfet, but it opens fully.
Check out Great Scott's recent video on AVR timers, it may be of some use.
Just invert the duty cyle yourself with a pwm (100-dc)
I just realized I never saw your face until this video.
YES ! More on DCOI, I'm eager to see it. I love the DCOI.
Ahh Finally I saw his face ! He is handsome..........
unsigned int math resulting in overflow ?