Render a webpage on a microcontroller or use an SBC

Does the page itself have to appear

A browser engine is built for operating-system-class hardware: Linux, Android, the desktop. There is no build for bare microcontrollers, and that settles the question of rendering a real page on one. The one workaround, hand-parsing a static HTML file and drawing it yourself, only covers a page with no dynamic elements, and at that point you have rebuilt the UI anyway with worse tools.

So the deciding question is what the page actually is. If it is JavaScript, live-updating charts, a layout a web team maintains, it is a real web app and it needs the board: plan the RAM in the hundreds of megabytes for the OS and the engine together, and budget tens of seconds from power to first rendered page. If it is a skin over sensor data, a title, some numbers, one graph and a few buttons, the browser is doing nothing you need. Rebuild those screens with an embedded UI toolkit on the microcontroller. The documented floor is low: a 16, 32 or 64-bit processor, 16 MHz clock recommended, and a minimal build in 32 kB of RAM and 128 kB of flash.

The two routes side by side

The rows that move most projects are power and USB: 2 W against 0.75 W decides the battery, and the USB class decides whether the microcontroller can even read the sensor.

Why the webserver examples don't help

Search for running a webpage on a microcontroller and nearly every hit is a webserver project: the board hosts the files and serves them to a phone or laptop, which renders them with its own browser. That is serving, a different job. Your screen stays blank in that design because the rendering happens on the client. Since the goal is the page on your own display, those examples answer the wrong half of the question, which is why the search keeps dead-ending.

Where the small Linux board wins

Take it when any of these holds. The page exists and is owned by someone else: a web team ships layout changes and you stay out of the loop. The page leans on JavaScript charts or live widgets that would be expensive to rebuild. The sensor only ships a Linux library or driver. Or the device lives on a bench or a vehicle with power on tap, where battery run time stops being the constraint.

Then plan the costs: about 2 W for the board, before the display. And power cuts, which you design for once: run the root filesystem read-only, or add a clean-shutdown input, and a cut stops being a card-corruption event.

Where the microcontroller wins

Take it when the device is carried, battery-powered, or switched on for a 30-second reading and off again. There is no OS boot: first frame in well under a second. The toolkit drives the touch panel, resistive or capacitive depending on what the display module carries. RAM stays small because the toolkit renders through a partial buffer, one tenth of the screen by its documentation, and the whole UI lands in the figures in the table above. Power sits near 150 mA at 5 V with a small backlit TFT, and the example below turns that into hours.

Two jobs move onto your desk: you rebuild the screens in the toolkit, and you write the sensor decoding unless the device speaks one of the two common USB classes. If your panel is a small SPI TFT, playing video from an SD card on a small SPI TFT shows what driving one involves. To skip the toolkit entirely, put an HMI panel in front of the microcontroller and talk to it over the bus; connecting an HMI panel to a microcontroller over Modbus RTU walks through that pairing. Whichever way you build it, keep the sensor decoding out of the drawing code; a write-up on bridging an LVGL HMI with a device state machine shows the async split that keeps the UI responsive.

The USB sensor is its own decision

Name the standard before buying anything: USB device classes. If the sensor enumerates as a CDC-ACM serial port or as a HID device, the two USB-IF classes for serial and human-interface data, mainstream microcontroller USB host stacks speak them and your code reads plain bytes on either route. If the sensor uses a vendor-proprietary protocol, you implement it from the vendor's command document on the microcontroller, and you implement it on the Linux board too: the OS doesn't know a proprietary protocol either. Put two questions to the sensor maker first, which USB class the device enumerates as, and whether they will send the protocol document. If the only supported interface is their desktop application, both routes stall until that document exists.

Example: a field day on one power bank

Scenario: a handheld tester reads a USB sensor array on plant walkrounds, 8 hours of screen-on time per charge, charged overnight from a 5,000 mAh USB power bank.

Usable energy: the bank's capacity is rated at the cell's 3.7 V, so 5 Ah × 3.7 V = 18.5 Wh stored. The 5 V boost converter delivers about 85% of that: 18.5 × 0.85 = 15.7 Wh at the output.

Board route: 400 mA × 5 V = 2.0 W for the board, plus 0.5 W for a small backlit TFT, 2.5 W total. Run time: 15.7 ÷ 2.5 = 6.3 hours, short of the day. The 8 hours need 8 × 2.5 = 20 Wh, which is 20 ÷ 0.85 = 23.5 Wh stored, or 23.5 ÷ 3.7 V = 6.4 Ah, so the board route wants the 10,000 mAh bank, and even that yields 37 × 0.85 ÷ 2.5 = 12.6 hours.

Microcontroller route: 150 mA × 5 V = 0.75 W with the backlight on. Run time: 15.7 ÷ 0.75 = 20.9 hours. The pocket bank covers the day about two and a half times over.

The 150 mA assumes a small panel at moderate backlight. The backlight dominates the draw and scales with panel diagonal and brightness, so a bigger panel moves the total more than the processor does. If the bank lives in a tool bag, check it for swelling before each trip and retire it at the first sign: a damaged lithium pack in a closed bag is the real hazard in this design.

Decision: the microcontroller route does the field day on a 5,000 mAh bank; the board route needs the 10,000 mAh size for the same day.

When to pick something else

Two cases fall outside the comparison.

A one-off field tool that gets charged overnight: use a consumer tablet. The battery, screen, touch layer and browser are already integrated, so the page runs as written with no firmware work. The costs move to logistics: a charger in the bag, and the tablet's own kiosk mode to set up so the page fills the screen and nothing else launches.

Bolted to a bench or a machine, with power on tap, software yours: then it is a fixed-station screen, which is our side of the business. A panel-mount Android signage display plays its content offline from a card or USB when the site has no network, and it runs your own Android app, so the rebuilt UI goes on a ready-made, touch-equipped panel. Size it for the reading distance with the screen size and viewing distance guide, and check where a small screen fits on a shop floor before cutting the mounting panel. The panel-mount displays list cut-outs, touch options and brightness options per size.

Recommendation

Recommendation: Rebuild the UI natively whenever the screens are yours to design. The microcontroller route comes up with no boot wait, draws near 0.75 W against 2.5 W, and triples the run time of the same power bank. Reserve the small Linux board for the page-as-written cases, JavaScript you don't own, a web team updating layouts, or a sensor that only ships a Linux library, and then plan 2.5 W with the display, a read-only root filesystem against power cuts, and the battery one size up. In both cases, get the sensor's USB class and protocol document before ordering hardware; that answer ends more of these projects than the board choice does.

Questions