1. Retain ERM LRA and piezo as different requested families

Haptic driver describes a product role without identifying every supported actuator family. TI's DRV2605L description explicitly names ERM and LRA, while the DRV2667 description explicitly names piezo haptic actuators. Keep these manufacturer-stated families attached to the named devices. A shared haptic purpose does not make their actuator descriptions interchangeable, and a broad category label should not supply an unstated support claim for a candidate.

The required family is therefore an input to the technical comparison, rather than a conclusion drawn from a host-interface name. A device can describe a digital communication path while serving a particular actuator family. That communication capability alone does not identify the actuator the output is intended to drive. Preserve the actuator requirement independently before assessing control features or waveform handling.

This guide uses the named product descriptions as examples of that distinction. It does not infer actuator construction from a diagram or rank the families by tactile quality. The immediate decision is whether the candidate's documented actuator role corresponds to the required family. A product's place in the same broad haptic category does not answer that narrower question.

2. Compare the named LRA/ERM control descriptions

Within the ERM/LRA description, DRV2605L distinguishes feedback-optimized ERM drive from auto-resonant LRA drive. Preserve those separate control meanings. Auto-resonant wording associated with LRA should not become an assumed universal ERM feature simply because the same device names both actuator families. The useful comparison connects the control description to the family for which TI states it, rather than combining all listed capabilities into one undifferentiated promise.

TI also describes a closed-loop actuator-control system and an internal smart-loop architecture. That identifies a control role inside the named device. It is different from the host's choice of how to provide an effect request or waveform. Keeping the loop description separate makes it possible to ask whether the intended actuator-control requirement is actually covered, without assuming that a supported host path defines the control behaviour.

The product description includes claimed benefits, but this guide does not report achieved acceleration, start time or braking performance in a customer assembly. The supported distinction is the named feedback and resonance-control role. Selecting a device with that description still leaves the exact actuator and application assessment to be established; no calibration method or control setting is supplied here.

3. Keep piezo driver architecture separate

DRV2667 is described as a piezo haptic driver with an integrated boost, amplifier and digital front end. This is a different named actuator architecture from the ERM/LRA description above. Preserve the functional blocks as a qualitative product description. Their presence identifies roles in the device, without establishing a particular output condition or authorising an external component choice for an unspecified actuator.

The boost and amplifier roles belong to the actuator-driving architecture; the digital front end belongs to how the device handles incoming information. Those descriptions can coexist without being the same feature. Treating a digital input as proof of a particular actuator output would skip the architecture question. Conversely, identifying piezo support does not state how the host must deliver the waveform required by a particular application.

A comparison can consequently preserve both the actuator family and the documented functional path. It should not import DRV2605L's ERM/LRA control wording into DRV2667 merely because both products serve haptics. The named description supplies no general piezo connection, boost-setting recipe or accepted waveform. Those implementation questions need the applicable exact-device evidence and the application's actual actuator requirement.

4. Separate host waveform path from actuator acceptance

Host waveform handling is a further decision after actuator family. DRV2605L describes an effect-library path and a real-time playback path in which the host can bypass the library engine. These paths concern how an effect or waveform reaches the device. They do not change ERM into LRA or make an unrelated actuator family supported. Keep the requested path distinct from the family and from the internal control-loop description.

DRV2667 separately describes a digital interface, analog inputs and internal waveform-handling functions. Those features concern the division of waveform-related work between the host and the device. A digital front end or waveform-memory feature is not itself evidence of the tactile effect obtained by the assembled actuator. The interface capability and the physical application result answer different questions, even when the same product description discusses both.

The focused requirement should therefore state the actuator family, the needed documented control function and the intended host waveform relationship. The application assessment can then examine that combination. This differs from classifying stepper and brushed motor drivers or defining a solenoid hold stage. It also avoids turning a library or input-path feature into a guarantee of tactile quality, mechanical response or compatibility with every actuator in the named family.

Sources and further reading

TI's DRV2605L saved product text characters 3700–5350 and DRV2667 characters 3445–4835 were reread on 16 October 2026. Only named actuator, control and waveform-path roles are used. Numerical values, calibration, waveform/boost recipes, full-document verification and tactile-result guarantees are excluded.