A removable drive needs a USB host and a TF card needs an SD controller. When your board has neither, SPI, eMMC or raw BGA NAND is the correct answer.
UDP (USB Disk in Package) modules and TF cards are removable storage that assume your board already has a USB host port or an SD controller. When it has neither, the right part changes. SPI flash suits small boot and parameter storage on a microcontroller. eMMC suits an embedded Linux or Android board that needs managed NAND soldered in place. Raw BGA NAND suits a design whose processor runs its own flash translation layer. All three are soldered, non-removable answers to a different question than the one a finished drive answers. Match the interface to the host first and the capacity second, and be honest about which question your design is actually asking.
TL;DR
UDP (USB Disk in Package) modules and TF cards are removable storage that assume your board already has a USB host port or an SD controller. When it has neither, the right part changes. SPI flash suits small boot and parameter storage on a microcontroller. eMMC suits an embedded Linux or Android board that needs managed NAND soldered in place. Raw BGA NAND suits a design whose processor runs its own flash translation layer. All three are soldered, non-removable answers to a different question than the one a finished drive answers. Match the interface to the host first and the capacity second, and be honest about which question your design is actually asking.
The part is decided by the host
Buyers usually arrive with a capacity in mind — 8GB, 16GB, 32GB. The capacity is rarely what decides the part. The host decides it. A storage device is useless without something on the other end that knows how to talk to it, and the talking is governed by which controllers your board carries.
There are three common situations, and they lead to three different answers.
What a removable drive assumes
A UDP module is a complete USB device. The NAND die and the controller are bonded onto one board and sealed into a single body — ours measure 11.3 × 24.8 × 1.45 mm and weigh 0.819 g, with capacities from 128MB to 128GB. Plug it into any USB host port and it enumerates; no driver, no carrier, no soldering. A TF card makes a parallel assumption, that your board carries an SD controller and a slot. Ours measures 15 × 11 × 1 mm at 0.25 g, from 4GB to 256GB.
Both are removable. Both are accepted by any PC, camera or reader. Both assume your design has a place for a plug or a slot — and a reason for the user to reach in.
The bus ceilings are public numbers
When people argue about removable interfaces they quote bus speeds, and the published figures are worth having straight. The USB Implementers Forum defines USB 2.0 High-Speed at 480 Mbit/s raw, USB 3.2 Gen 1 — the line still widely called USB 3.0 — at 5 Gbit/s, Gen 2 at 10 Gbit/s and Gen 2x2 at 20 Gbit/s. The SD Association sets its own ladder for cards: Default Speed at 25 MB/s, High Speed at 50 MB/s, UHS-I at 104 MB/s, UHS-II at 312 MB/s, UHS-III at 624 MB/s, with SD Express reaching 985 MB/s. Both bodies state the same catch: the host and the card must support the mode. Put a UHS-II card in a UHS-I slot and it runs at the 104 MB/s UHS-I ceiling.
These are industry standards published by the USB Implementers Forum and the SD Association — none of the figures above is a WINTEL measurement, and the exact limits are subject to the latest official wording.
The practical point differs from the use these numbers usually get. Even the slowest rung on either ladder outruns most custom flash media. The reason to check the interface is not throughput. It is whether your host speaks that bus at all.
When SPI is the answer
A microcontroller running a sensor, a meter, a motor or a lock often has no USB host stack and no SD controller. What it has is a few spare pins and a storage problem that looks like this: some boot code, a calibration table, a serial number, a short log. SPI flash solves exactly that. Four signal lines, a controller already inside most MCUs, code that runs before any operating system exists.
A removable drive is the wrong shape of answer there. Nobody pulls the storage out of a water meter to read it on a laptop, and if they could, that would be a security failure. If the storage job ends when the device is opened, it was never a removable-storage job.
When eMMC is the answer
An embedded Linux or Android board needs a home for the root filesystem — an operating system, application binaries, configuration. The conventional part is eMMC: managed NAND with the controller integrated into the package, defined by JEDEC and shipped in a ball grid array meant to be soldered and never touched again.
A TF card can physically hold the same files, and designers do try it. On a bench it works. In a product that vibrates, heats and ships to strangers, a card in a slot is a service item — it works loose, it gets removed, it gets lost. Storage an end user can extract is storage that will eventually go missing. If the filesystem is the product, solder it down.
When raw BGA NAND is the answer
The third situation is a design team that wants cost and control. Raw NAND in a BGA package costs less per gigabyte than managed alternatives, and the processor’s controller runs its own flash translation layer. The trade is responsibility — wear levelling, bad-block management and error correction become your firmware’s job instead of somebody else’s silicon.
The NAND itself arrives in package formats the market shares across all of these designs. The list we source against runs TSOP, BGA, LGA, COB and eMMC; COB — bare die bonded straight to the board — is the same construction our UDP and card lines are built on. The silicon is often the same family. The socket, the controller and the warranty are what differ.
The decision in one table
| Your host | The right part | The part to avoid |
|---|---|---|
| PC, laptop, TV port — user carries it | UDP module or finished drive | eMMC, raw NAND |
| Camera, reader, anything with an SD slot | TF card | SPI flash |
| Microcontroller, no OS, small data | SPI flash | Any removable drive |
| Embedded Linux or Android | eMMC or raw BGA NAND | TF card as system disk |
| Custom board with its own FTL | Raw BGA NAND | Managed parts in general |
Read the right-hand column as the expensive mistakes. A removable drive specified where an operating system was expected does not fail in the lab. It fails in the field, as a support ticket with your logo on it.
What we ask before we quote
Five facts sort almost every enquiry. Which processor or board is the host. Which operating system runs, if any. Whether the storage must be removable in the field. What capacity the files actually need. What the environment looks like — temperature, vibration, handling.
With those five answers we can usually say in one reply whether the right build is a UDP module, a TF card or one of our semi-finished boards at 12 × 44 × 4.5 mm and 3.2 g. When the answers point somewhere else — a boot chip on SPI, soldered eMMC, raw NAND with your own translation layer — we say that too, and describe what to ask the supplier who builds it.
When you should not buy a drive from us
Be suspicious of any supplier, us included, who quotes a finished removable drive against the three situations above. If your board is a microcontroller with a few hundred kilobytes of RAM waiting on boot code, do not order custom USB drives — a component-distributor SPI part is cheaper, smaller and the correct engineering answer. If your product runs Linux from storage the user must never remove, a card in a slot is a defect you shipped on purpose. If your throughput case leans on UHS-II or USB 3.x, confirm the host supports the mode first, because those ceilings only exist when both ends do.
We build removable flash — UDP modules, TF cards, semi-finished boards — and we would sooner lose an order than put a removable drive inside a design that needed soldered silicon. Tell us the host and we will tell you which side of that line your project sits on.
Frequently asked questions
What is a UDP module?
UDP stands for USB Disk in Package. The NAND die and the USB controller are bonded directly onto a single board and sealed into one body, so the module plugs into any standard USB host with no reader, no carrier and no drivers. Our UDP modules measure 11.3 × 24.8 × 1.45 mm at 0.819 g and run from 128MB to 128GB.
When should I choose SPI flash instead of a removable card?
When the host is a microcontroller with no USB host stack and no SD controller, and the storage job is boot code, calibration tables or a small parameter set. Four signal lines and a small array of cells do that job. A removable drive is the wrong shape of answer for it.
Is eMMC just a soldered TF card?
Functionally close, mechanically different. Both are managed NAND with an integrated controller, but eMMC is a JEDEC-defined package meant to be soldered and never removed, while a TF card sits in a removable slot on the SD bus. An operating system root filesystem belongs on the soldered part.
Does WINTEL supply eMMC or raw BGA NAND?
We source NAND in TSOP, BGA, LGA, COB and eMMC package formats, and COB bonding is the construction our UDP and card lines are built on. Our finished lines, though, are removable products — UDP modules, TF cards and semi-finished boards. If your design points to soldered eMMC, we will say so plainly and tell you what to ask for instead.
Will a faster interface fix a slow design?
Rarely. The SD Association's ceilings require both ends — a UHS-II card drops to the UHS-I limit of 104 MB/s in a UHS-I host — and a 5 Gbit/s USB 3.x port sits idle behind media that cannot feed it. Check the host before you check the catalogue.
What should I send before asking for a quote?
The host processor or board, the operating system if any, whether the storage must be removable in the field, the capacity your files need, and the environment. With those five facts we can usually say in one reply whether a UDP module, a TF card or a semi-finished board is the right build — and when none of them is.