The daily datasheet thing continues. It's been surprisingly easy to get in at least one a day, mostly because a lot of them are quite short. This week, one day was taken up with reading a big pile of datasheets for motor driver ICs, which was repetitive but educational.
Aluminum Electrolytic Capacitor Application Guide (Cornell Dubilier)
Who ever knew electrolytic capacitors were so complicated? Actually some very interesting stuff in here about how the dielectric layer is formed in these things that I did not know.
The Power of Ten - Rules for Developing Safety Critical Code (Gerard J. Holzmann)
This is a set of ten rules to make C nicer for safety-critical programming. Some of the rules aren't too onerous, but some of them are quite restrictive. It all seems quite Draconian, but it's intended for safety critical stuff, so is probably justifiable.
This was only written in 2006, so it's interesting to compare this approach (basically "C plus rules/human factors") with using higher level languages. It seems as though there ought to be more interest in using higher level languages, to be honest. I know it's been done for a few NASA projects, but a lot of the transport industry still relies on MISRA C and programmer discipline. (Discipline enforced by random drug and alcohol tests at work in some places. A place I used to work, we did a lot of naval stuff, aerospace and transport. The transport people used to get random drug tests, while those of us working on sonar systems for Her Majesty's nuclear submarines were down the pub.)
There's a fair bit of emphasis in "The Power of Ten" on using static analysis tools. One form of static analysis tool that using C rules out is a (much) smarter compiler. There's a perspective on this that comes from the programming languages community, where people often talk about the kinds of type systems you get in languages like Haskell and similar as being lightweight formal methods that the compiler can apply automatically every time you build your code. I tend to have more trust in systems like that than in the human factors approach, but I guess the ideal would be to have both.
(I could write more about this, but it's slightly out of scope... Just one tiny point: one argument for using C is that it's a simpler language than something like Haskell or Rust or whatever the flavour of the month in PL circles is. That argument may hold water if you compare a C compiler from 1990 with today's Haskell compiler. But comparing GCC or Clan + LLVM with a Haskell compiler today, things are much more evenly balanced!)
So many motor driver datasheets...
Lots. And lots. And lots. 11 from TI, 8 from Toshiba, one each from Diodes Inc., Maxim, Rohm and ST.
Some interesting stuff in them though: I learnt quite a bit about the current regulation strategies these drivers use, and I'm feeling much more confident about the idea of doing a design with one of them.
Advantages of integrated current sensing (TI SLVAE68)
Super-short app note from TI. You have to love those 2 page app notes!
For current sensing with motor drivers for brushed DC motors, the usual approach is to include a shunt resistor to ground in the motor current path. For higher power applications, these shunt resistors are inconveniently large (often 1206 or bigger footprints, i.e. bigger than the motor driver chip!).
Some TI motor drivers include current sensing circuitry in the driver, and output a signal proportionate to the current so you can get current monitoring without needing a big external sense resistor.
(Unfortunately, the drivers that provide this functionality are all for supply voltages greater than what I'm using for my current project, so they're not an option for that. I don't think it's going to be an issue anyway, since the current levels I'm dealing with are low.)
Current Recirculation and Decay Modes (TI SLVA321)
Mostly about the DRV88xx series of motor drivers, but interesting more generally as I know very little about all this yet...
The basic problem behind this stuff is: how do you switch inductive loads on and off safely using a H-bridge? The main example of this here is doing PWM control for the coils in a motor.
When you're running you motor, there's some current through the motor coil. When your PWM signal switches off, the current wants to continue. So you need to offer it a safe path to dissipate, otherwise you risk damaging the H-bridge MOSFETs. (Thinking of an "off" MOSFET as an open circuit is fine until you have an inductor trying to push an amp of current through your "off" FET with potentially hundreds of volts of back EMF behind it...)
Most motor drivers have "freewheeling" diodes in parallel with the H-bridge FETs. They're oriented to allow current to flow from ground to the positive rail, and conduct when the FETs are switched off in response to the coil back EMF.
The main point of the app note is that it's more efficient to manage the current flow from the back EMF by sequencing FET on/off states differently: there are a couple of these current recirculation methods -- they aim to give the motor coil current route to flow until it dissipates, without FET shoot-through.
All switching transitions need some dead time to avoid FET shoot-through. Most motor drivers seem to implement this internally, so there's no need to worry about it yourself, which makes for simpler PWM control.
The app note sums up the differences between the approaches with a bit of terminology:
Asynchronous decay is the approach using freewheeling diodes: the exact switch-on time of the diodes isn't known, which can be a problem, and it's commone to use Schottky diodes to make the switch-on faster.
Synchronous decay is an approach that uses the on resistance of FETs in the H-bridge as a safe path for current decay: the motor driver coordinates the FET states to do this, and this means that switch-on times are known and controlled precisely.
There are three main recirculation approaches:
Fast decay aims to get the motor coil current to dissipate as quickly as possible, and works by switching off the conducting path FETs in the H-bridge. Then the driver either (asynchronous) allows freewheeling diodes on the opposite current path to conduct, or (synchronous) switches on the FETs on opposite current path. This approach imposes the Vcc-GND potential across the coil in the opposite direction to the original driving current, which gives the fastest possible current decay.
Slow decay works by switching off the high-side FET in the conducting path and switching on the low-side FET on the same side, resulting in a situation where both low-side FETs on. This gives a slower current decay since we're not imposing the supply voltage against the direction of coil current flow. The current decay time is determined by the motor coil inductance and the resistance in low-side loop, i.e. twice the FET on-resistance, so , which can be a long time for FETs with very small on resistance.
Mixed decay has a bit of fast decay, then switches to slow decay. This gives finer control over how fast and how much the coil current is reduced between PWM pulses and is used by more sophisticated drivers.
What the Nyquist Criterion Means to Your Sampled Data System Design (Analog MT-002)
The first section of this is about why you need sample and hold in ADCs. Without sample and hold, if you sample at 100ksps, you can only handle a bandwidth of 9.7 Hz (!) if you want the signal not to move by 1 LSB during a sample period!!! (Yeah, 9.7 Hz. I thought that was a misprint at first...)
The rest of the app note is a medium-detailed explanation of the Nyquist criterion, aliasing and anti-aliasing filters.
There's also some coverage of oversampling and undersampling (I didn't understand all of this).