While it might be tempting to lump Single Board Computers (SBC’s) and Dev Boards together, as many retailers do for the sake of convenience, SBCs and Dev Boards have distinct roles and functionalities which separate them. Here’s how to tell the two apart and decide which board, or combination of the two (there are no rules!), will be right for your next project or mass-market, whizzbang IoT gadget:
Lower cost, lower profile, and ready-to-go, single board computers are the svelte system option when you need more processing oomph than a microcontroller, yet can’t cant afford the space or power budget that a full size motherboard or server requires. SBC’s contain everything you need to run a proper “full” operating systems such as Windows 10 IoT and many flavors (insert list here) of Linux, although it’s important to note that the main processor architecture of the SBC, be it ARM, x86/x64, Allwinner etc. will largely limit what kernels and drivers are available without extensive low-level programming and configuration. However, you will find the following key features common to many SBCs:
- Consumption in the 10s of watts or less
- Fanless or minimal airflow with compact heatsink operation
- Low power draw allows cheaper and readily available PSUs
- HDMI, DVI, MIPI, LVDS, VGA, COMPOSITE display connections
- WiFi and Bluetooth
- 3.5mm line in/out
- Full size USB 2.0/3.x common for I/O
- Direct GPIO (General Purpose Input/Output) access
- RJ-45 connections for PoE, Gigabit networking
- CSI (Camera Serial Interface)
- Processor and RAM typically fixed
- GPIO access isn’t typically capable of real-time control
- Limited graphical processing capabilities and extensibility
- Analog to digital conversion usually requires external hardware
Applications and Usage:
- Suitable as embedded systems for use in connected security systems, computer vision, point-of-sale, digital signage devices etc.
- Mass availability for 1000’s of units for reliable supply chain and predictable EoL
- Capable of running software that requires high-level programming languages and scripts
What is a Development Board?
Contrary to their larger single board cousins, Dev Boards are focused to provide an accessible PCB breakout for an MCU (microcontroller unit) and typically have the minimal passives, oscillators, and hardware communication ICs necessary to test out the feature-set of said microcontroller. Some boards may have more advanced features such as hardware debugging, or extensive, built-in IO, like arrays of switches, LEDs, IMUs (Inertial Measurement Units), displays, and potentiometers to allow yet more rapid setup with no fuss.
At the end of the day though, most Dev Boards aren’t the end product the manufacturer is trying to sell, barring educational/hobby boards like the Arduino platform. The Dev Board is the showpiece with all the bells and whistles to entice you away from competing products, so that you (the engineer) feel it’s the best option for your next widget, of which you intend to make 50,000 units, and thus incorporate their core microcontroller into your design. This is why they’re called “Development” Boards.
However some manufacturers bridge the gap into mass manufacturing and release boards with castellated edges, effectively turning them into a SoM (system on module), which can save on valuable design and manufacturing time.
Here are some of the key features by which Dev Boards are set apart:
- Low power consumption on the scale of milliwatts
- Often able to run off a single cable for data transfer and power
- USB (typically micro or mini variants at 2.0 spec)
- Limited bulk availability, thus not suitable for incorporating into finished products
- unpredictable EoL, making long term supply chain management/curriculum development difficult
Applications and Usage:
- Serve as reference designs
- Interactive art installations
- Low volume (<1000) goods
The distinction between a Dev Board with a high-end ARM processor capable of running Linux and a proper single board computer is certainly fuzzy. There’s certainly a gradient between an mcu programmed in raw assembly up to an 86x system running a “full” OS, but the tiers along the way certainly matter, so I hope the comparison above has clarified what separates Dev Boards and SBCs in a way you find useful. If not, politely let me know in the comments below which areas you’d like to see me expand upon!