USB is strictly host-centric: there is exactly one host (typically the PC, or an OTG-capable MCU acting as host) that controls and schedules all bus traffic, and devices are passive, a device never transmits unless the host explicitly asks it to, by polling or issuing a request. That's the opposite of CAN, which is multi-master with no central controller and nodes arbitrating for the bus, and of I2C, which also allows multiple masters. In USB the host assigns each device an address, initiates every transaction, and decides the schedule, so a device can't spontaneously interrupt, even "interrupt" transfers are really the host polling the device at a guaranteed interval, not the device asserting an interrupt. The practical consequence for an MCU is that as a USB device it implements a reactive stack: it responds to host requests (enumeration, data polls) rather than initiating, and to act as a host it needs OTG hardware and a much heavier host stack. So the mental model is master/slave with one fixed master, versus CAN's peer-to-peer arbitration.
Communication Protocols · Interview question
How is USB's communication model different from I2C or CAN?
A strong answer
What a weak answer sounds like
You know the answer. Do you know what gets you dinged?
Pro breaks down the answer most candidates actually give to this question — and the specific reason an interviewer marks it down. It’s the difference between sounding correct and sounding senior, on all 472 questions.
From the lesson
USB Basics
Host-controlled, self-describing, and far more complex than UART: enumeration, descriptors, endpoints, and the four transfer types, plus device classes like CDC that need no custom driver.