Im designing a simple BLDC driver circuit with 6 mosfet drivers and 6 mosfets (3 high side P-channels and 3 low side N-channels) which will be run on an atmega328 chip (Arduino Uno).
Im looking at the BLDCDriver6PWM and it seems the class is intended for high side N-channel mosfets based on the documentations chart.
I can see in the source code (_configureComplementaryPair()) that it sets the output modes of high side to inverting and low side non-inverting mode or vice-versa.
My question is if I can simply after driver.init set both outputs to the same mode without having my circuit short. Since P and N switch ON by their opposite voltage it would be safe. Im just wondering if Im missing some other case where the driver will assume all mosfets are N-channels, like for instance free-rolling.
Using P-Channel FETs is not something we see so often, and even when, designs often use inverting drivers so the MCU has active-high logic in the end… So unfortunately, you are correct and the current library version does not support it out of the box.
If you take a look in the dev branch of the code, setting the PWM polarity has now been considered - but so far implemented only on RP2040 and STM32 MCU types, unfortunately not yet for ATMega.
It is controlled via the build flag SIMPLEFOC_PWM_HIGHSIDE_ACTIVE_HIGH which defaults to true. You can set it to false to enable an active low behaviour.
On ATMega, for the moment, your suggestion seems ok to me. There should not be any normal situations in Sine or SpaceVector commutation where it would change the polarity on you.
BUT: please be sure to test it out first without the motor driver attached.
If you have an oscilloscope or logic analyser you can check the PWM waveforms and make sure they look like you expect (high and low sides will look in-phase rather than out-of-phase) and check the dead-time is working as expected, etc.
Only once you’re confident everything looks good, only then attach a driver and motor. If your setup does not have hardware shoot-through protection you should not take any chances.
If you watch for it in future releases you could switch to the build flag once we get it done for ATMega.
I did something similar and used a logic inverter for the P side. I’m not sure however if this is a good advise.
Out of curiosity, why are you doing this? Finding a matched P - N pair of mosfets is really difficult. Also, you will rely only on software dead-time insertion, a little dangerous. Integrated bridge drivers have hardware dead-time check baked into the silicon.
Ill admit Im a beginner with motor drives.
The circuit Im building is for my learning experience and using mosfet drivers + through hole mosfets seemed like the cheapest solution. With an NMOS on the high side I wouldve needed a bootstrap circuit with highly specific values for the capacitors and diodes which I dont feel confident with yet so I ended up with having PMOS on the high side.
I chose a PMOS with very low on resistance (for a PMOS) and their amp ratings are above what I plan to put it through, thats pretty much all I matched them with. Perhaps I need to consider things like fall time as well?
Note though that with the TC4428 there is a variant of the driver you’re using with one inverted channel… just saying
I think you’re right - it reduces the component count significantly. If you can further use either the logic supply voltage or the motor drive voltage as the drive voltage for the FETs, you also don’t need a separate power source for that.
That can make for a really simple driver architecture.
The price you pay for it is reduced efficiency of the PFETs. But for many applications that isn’t really an issue. Not having protection against shoot-through is another disadvantage, Valentine mentioned it. You’ll have to be really careful not to switch on both FETs of a half-bridge at the same time. A PSU with current limiting ability is probably a good idea for testing. I would add pull-up/down resistors on both the driver and the FET gates to ensure the FETs aren’t in an undefined state during power-up.
I have the 4427 version which doesnt have inverted inputs
Sadly I dont have an oscilloscope but I do have a bench PSU with max amp setting and short protection.
Though I have made a rough oscilloscope with another Arduino Uno and using the Serial Plotter and reduce the intended FOC Uno’s timers prescalers from 1 to 64 (reducing the frequency from library hardcoded ~31kHz to ~500Hz) so the Uno oscilloscope have time to run the ADC for each channel. This gives me a rough view of the sequencing.
If I then should have shoot-throughs I assume the fets would get quite hot or that my bench PSU’s short protection will cut off the power?
The PSU should drop the voltage to keep the current within the limit you set. That’s how mine do it, but some might also cut out the power completely I guess.
Either way, this has to happen quickly, or the FETs/driver board can be damaged by high currents.
I agree with @Valentine that almost any kind of oscilloscope would be super-practical… but not that one from Amazon - get one with at least 2 channels, or you won’t be able to compare the waveforms of the high and low sides.
As a cheap solution for the problem at hand, a logic analyser works fine because the PWM is a digital signal. Something like this: https://www.amazon.de/-/en/AZDelivery-Analyzer-compatible-Arduino-including/dp/B01MUFRHQ2/
together with the free software “PulseView” is all you need.
I can’t say I really recommend these analysers (from the fact that they sell in 3 packs for 30 EUR it should already be clear that these aren’t high end ), and they certainly can’t do the 24MHz advertised, but PWM for motors is only in the lower kHz range, and they can manage that just fine.
Do you understand the small spikes in between the bursts? For instance the one for AH at the end where its high for a long duration, then low for a very short duration while AL remains low, then turns high again for a long duration.
The picture is before I did my intended change, except for increasing the prescalers to reduce the frequency.
I was thinking of it being noise but I just wanted to check with you since it seemed so systematic over multiple samples in case it was something the library caused.