DEV Community: Rocktech Displays Limited

Aspect Ratios in Embedded Displays: What Developers Need to Know

Kevin zhang — Sat, 12 Jul 2025 05:35:48 +0000

📐 Introduction

When designing an embedded system with a TFT LCD display—whether it's an industrial HMI, a smart thermostat, or a medical interface—the aspect ratio of the screen plays a subtle but crucial role. While often overlooked, the choice between 4:3, 16:9, 1:1, or other ratios can drastically impact everything from UI layout to physical integration.

This article dives deep into how aspect ratios affect embedded applications, why it matters for developers and engineers, and how to make the right choice for your project.

📊 What Is Aspect Ratio?

Aspect ratio is the proportional relationship between the width and height of a display. It is usually expressed as two numbers separated by a colon (e.g., 16:9). A 16:9 screen is 16 units wide for every 9 units tall.

Popular aspect ratios in embedded devices include:

4:3: Traditional and often found in legacy equipment.
16:9: Widely used for video-oriented applications.
3:2 or 5:3: Common in compact HMIs or automotive screens.
1:1 (Square): Emerging in home automation and minimalist UIs.

Understanding these proportions is vital for designing intuitive interfaces and selecting compatible hardware.

🎨 UI/UX Design Considerations

1. Content Layout Flexibility

A 16:9 or 4:3 screen may be ideal for dashboards with data visualizations, while a 1:1 square screen is well-suited for grid-based icons or quick-access scenes in smart homes.

2. Font & Touch Target Sizing

Aspect ratio influences the spacing and grouping of controls. For instance:

4:3 provides vertical space for lists.
16:9 works better for horizontal sliders or navigation bars.

Touch targets must remain within thumb-reachable zones, especially for handheld or wall-mounted devices.

3. Animation and Transitions

A mismatch between animation design (e.g., sliding panels) and display ratio may lead to awkward or clipped transitions.

🧱 Hardware Integration

1. PCB and Enclosure Design

The physical aspect of integrating a display into an enclosure depends on its ratio:

Wider screens (16:9) require more horizontal PCB space.
Square screens (1:1) fit easily into square or round wall boxes.

2. Connector Placement

The aspect ratio can determine where the display connector lies and how flex cables are routed—vital for space-limited embedded designs.

3. Power Management

Wider and higher-resolution screens typically demand more backlight power. This impacts battery life in portable devices.

🧪 Industrial Applications

Let's examine how aspect ratios are chosen in real-world use cases:

Application	Common Ratio	Why It Works
Smart Home Panels	1:1 or 3:2	Balanced layout, aesthetic symmetry
Factory HMI Interfaces	4:3 or 16:9	Room for data + controls
Medical Diagnostics	5:4 or 16:10	High data density and image clarity
Vehicle Infotainment	16:9 or 21:9	Wide layout for multi-zone interaction

🧠 Developer Tips

Check BSP Support: Some embedded boards only support specific display ratios out-of-box. Custom driver or device tree updates may be needed for others.
Design Responsive UIs: Use GUI frameworks like LVGL or Qt with responsive layouts that adapt to aspect changes.
Simulate Early: Emulate various screen ratios in software prototypes before hardware selection.
Consider User Distance: For wall-mounted UIs viewed from afar, choose ratios that prioritize large, readable content.

🔗 External Reference

For a deeper dive into how Android SBCs are shaping embedded display applications, check this post: 👉 Embedded Android Board: The Future of Smart Devices

We welcome collaboration! Drop your thoughts or ask questions in the comments.

🧭 Conclusion

Choosing the right aspect ratio for your TFT display is not just about matching screen real estate — it’s about delivering a better user experience, reducing development cost, and aligning with industrial design needs.

As embedded systems become more UI-driven, aspect ratio decisions will play an even greater role. Make sure yours is informed by both design and engineering needs.

Designing a Smart Home Control Panel with PX30 and LVGL / Qt5 on Linux Buildroot

Kevin zhang — Fri, 09 May 2025 04:17:15 +0000

Designing a Smart Home Control Panel with PX30 and LVGL / Qt5 on Linux Buildroot

Smart home control panels demand sleek UIs, quick boot times, and reliable performance under varying lighting conditions. Pairing the Rockchip PX30 with a Linux Buildroot stack — and rendering the GUI using either LVGL or Qt5 — offers a flexible, cost-effective solution for modern embedded devices.

Why PX30?

The Rockchip PX30 is a quad-core Cortex-A35 processor that strikes a great balance between performance and power efficiency. For smart home environments, PX30 can handle multi-touch UIs, Wi-Fi communication, and real-time device control — all without active cooling.

Key advantages:

Quad-core Cortex-A35 @ 1.3 GHz
Mali-G31 GPU (OpenGL ES 2.0/3.2)
Dual-channel MIPI-DSI (for TFT panels)
PCIe/SDIO support for 2.4GHz & 5GHz Wi-Fi
Excellent Linux and Buildroot support

Typical deployments use a 7" or 10.1" high-brightness TFT panel with capacitive touch, ideal for kitchens, entry panels, and smart mirrors.

LVGL vs Qt5: Embedded GUI Options

Feature	LVGL	Qt5
Language	C	C++ / QML
Rendering	Software + optional G2D	Hardware-accelerated (OpenGL)
RAM footprint	<10MB	~100MB+
UI tools	SquareLine, LVGL Designer	Qt Designer, QML
Ideal for	Simple dashboards	Multi-page animated UIs

Recommendation:

Use LVGL for lightweight, single-screen interfaces.
Choose Qt5 for richer UIs with transitions, effects, and scalable layouts.

Both frameworks work reliably on PX30 with Buildroot. Qt5 can utilize GPU acceleration via EGLFS, while LVGL runs even with software rendering.

Wi-Fi Configuration & OTA Readiness

PX30 supports dual-band Wi-Fi using PCIe or SDIO modules. We’ve tested Realtek modules such as RTL8821CU and RTL8822CE, which work with wpa_supplicant.

To prepare for OTA (Over-The-Air) updates, Buildroot systems can enable:

OverlayFS or dual-rootfs
A/B partition logic
Lightweight update systems via scp, rsync, or mender

Cloud connectivity via MQTT or REST APIs can be easily added with libmosquitto, libcurl, or even embedded Node.js runtimes.

Backlight and Touch Tuning

TFT panels often require manual tuning for backlight levels and touch responsiveness:

PWM-controlled backlight drivers can be adjusted via sysfs or device tree (pwm1, leds@x).
Capacitive touch controllers like GT911 or FT5336 may require tuning via I2C or firmware upgrade tools.
Environmental calibration is essential in glass/metal panel designs.

Real-World Use Case: Embedded Smart Panel

We deployed a PX30-based embedded SBC with:

Qt5 interface running at 60fps on EGLFS
Dual-band Wi-Fi with MQTT-based automation
Sensors for light, temperature, and air quality
1000+ nits IPS display with capacitive touch
8s boot time from power-on to UI

Buildroot enables a compact system image under 300MB, easily flashable via USB OTG or SD card.

Final Thoughts

PX30, paired with LVGL or Qt5 and tuned using Buildroot, provides a stable and responsive base for building custom smart home hubs and touch-based devices.

📚 Explore more configuration examples, overlays, and integration tips:
https://kevin109.github.io

Rockchip vs NXP – A Deep‑Dive for Product Teams Choosing Their Next Embedded SoC

Kevin zhang — Fri, 09 May 2025 03:51:53 +0000

Selecting the right SoC doesn’t happen in isolation—it dictates the entire single‑board computer (SBC) stack you’ll ship to customers.

If you’d like a visual catalogue of how these chips translate into production boards, browse our continuously updated gallery of embedded single‑board computers ↗ before you dive in.

1 | Executive Summary

Dimension	Rockchip (RK Series)	NXP (i.MX Series)	When It Tips the Scale
CPU / GPU Horsepower	✔ Higher, up to 8 × Cortex‑A76 & Mali‑G610, 8 K decode	Moderate, tops at 4 × A55 & Vivante GC7000	Multimedia, vision, AI inference
Real‑Time Determinism	Good with PREEMPT_RT, but jitter a few µs higher	✔ Better inter‑core scheduler tuning; sub‑ms jitter out‑of‑box	Multi‑arm robotics, hard PLC loops
AI Accelerator (NPU)	Up to 6 TOPS (RK3588)	Up to 2.3 TOPS (i.MX 8M Plus)	Edge‑AI > 3 TOPS
Pricing (≥ 10 k SoC)	✔ ≈ 30 % cheaper	—	Cost‑sensitive mass devices
Longevity & Docs	Roadmap 8–10 yrs, docs improving	✔ Formal 10‑/15‑yr LTS, extensive safety docs	Medical, automotive
Ecosystem & Boards	Dozens of China‑made SBCs & SOMs, fast prototyping	Fewer boards, stronger global disty support	Need rapid low‑cost eval vs. need worldwide support

(Click any row to enlarge on mobile.)

2 | Real‑Time Behaviour: Why NXP Still Wins Ultra‑Deterministic Loads

2.1 Kernel & Scheduler

NXP i.MX BSP ships with fine‑tuned IRQ affinity, CPUFreq governors, and deadline scheduler patches.
Measured latency: ≈ 120 µs worst‑case on PREEMPT_RT (4‑core A53 @ 1.6 GHz) controlling three 6‑DoF arms.
Rockchip RK3568 under identical PREEMPT_RT setup: ≈ 180–220 µs—excellent for HMIs, AGVs, AMRs; borderline for synchronised robotic welding.

If your servo loop must close at ≥ 1 kHz with < 150 µs jitter, pick NXP—or budget time for extra tuning + core isolation on Rockchip. For 95 % of products (digital signage, control panels, edge cameras) Rockchip’s latency is already over‑engineered.

2.2 Practical Take‑Away

NXP i.MX
Best for deterministic multi‑axis robotics, SIL‑rated PLCs.

Rockchip RK
Meets or exceeds real‑time needs in most commercial HMI / multimedia workloads.

3 | Big‑LITTLE Compute & Multimedia Throughput

Benchmark	RK3588 (8 × A76 / A55)	i.MX 8M Plus (4 × A53)
Geekbench 6 Multi‑Core	≈ 240 k	≈ 91 k
4 K → 1080 p HEVC transcode	62 fps	24 fps
ResNet‑50 INT8 / NPU	885 fps (6 TOPS)	306 fps (2.3 TOPS)

RK3588 breezes through Chrome 8 K VP9 playback at < 30 % CPU, something even an i.MX 93 can’t touch.

4 | Cost & Supply‑Chain Economics

SoC delta ≈ ‑30 % (distributor quotes, Q1‑2025).
Passive & power‑tree delta ≈ ‑10 % (China‑made PMICs, DDR from CXMT).
Aggregate SBC delta ≈ ‑30–40 % after PCB, connectors, and local assembly.

Example: Rocktech’s RK3566 Pico‑ITX board hits US\$65 @ 1 k; a comparable i.MX 8M Mini board is roughly US\$95–100.

5 | Software Stacks & Toolchains

Layer	Rockchip	NXP
Android	SDK up to Android 14 (RK3588)	Up to Android 11 on most i.MX variants
Yocto	`meta‑rockchip`, community moving fast	`meta‑freescale`, officially maintained
Mainline GPU	Panfrost for Mali (GLES 2/3), actively improving	Etnaviv for Vivante, mature
RTOS / MCU	No dedicated M‑core	Optional Cortex‑M7 (i.MX 8M Plus) runs FreeRTOS

(Android digital‑signage devs lean Rockchip; SIL‑ready Yocto teams favour NXP.)

6 | Security & Compliance

Feature	RK356x	i.MX 8M Plus
Secure Boot	✔	✔ (plus CAAM)
TRNG / PUF	Basic	EdgeLock®
Safety (IEC 61508)	Via partners	✔ TÜV‑certified libs
PSA‑Certified	Road‑map	✔

7 | Real‑World Case Studies

7.1 High‑Speed Pick‑&‑Place Robot (SMT)

Chosen SoC: i.MX 8M Plus
Why: 2.3 TOPS NPU was fine; sub‑100 µs jitter essential for multi‑arm sync; 15‑year longevity clause in OEM contract.
Result: 90 µs worst‑case jitter, SIL‑2 package reused across 4 SKUs.

7.2 4 K Retail Smart Mirror

Chosen SoC: RK3588
Why: Real‑time 3‑D face mesh on 6 TOPS NPU, dual 4 K HDR cams, AR overlay at 60 fps.
Result: Unit cost 32 % below i.MX 93 prototype; passive cooled via heat‑pipe chassis.
Display Stack: For display interface options in SBCs powering smart mirrors and kiosks, refer to our Display Interface Breakdown.

7.3 Battery‑Powered Smart Lock Hub

Chosen SoC: i.MX 6ULL
Why: Sub‑1 W idle, EdgeLock secure element, guaranteed supply till 2035.
Result: 2‑year battery life on dual 18650.

8 | Decision Tree

Hard real‑time (< 150 µs) & functional safety? → NXP (i.MX 8M Plus / i.MX 93).
Ultra‑high‑res video, heavy AI (> 3 TOPS), cost‑sensitive? → Rockchip (RK3588 / RK3568).
Kiosk / HMI, Android UI, BOM < US\$100? → Rockchip RK3566.
Fan‑less, headless, sub‑5 W & 15‑yr life? → NXP i.MX 6ULL / 7ULP.

9 | Key Tips When Switching Vendors

Topic	Rockchip → NXP	NXP → Rockchip
DDR Training	Use NXP DDR Tool GUI	Use `rkbin` & `dmc-test` scripts
Secure Boot	CAAM keyblob workflow	`unify‑image.sh` + `upgrade_tool`
Display DT nodes	`dcss` / `ldb` endpoints	`vop` / `route` / `endpoint` nodes
NPU SDK	eIQ ML toolkit	RKNN‑ToolKit + quantiser

10 | Conclusion

For 95 % of modern projects, Rockchip’s blend of performance and cost is the fastest path from POC to mass production.

When sub‑100 µs determinism, SIL certificates, or 15‑year guarantees rule the spec, NXP remains the go‑to.

For more technical articles and updates on embedded SBCs, you can also visit my Rakuten Blog.

How to Design Displays for Outdoor or High Ambient Light Environments

Kevin zhang — Sun, 27 Apr 2025 14:30:55 +0000

When designing devices intended for outdoor use or areas with strong ambient lighting, a standard TFT display often falls short. In these conditions, visibility and readability become critical — and ensuring that users can clearly see and interact with the screen is a major design challenge.

At Rocktech, we’ve worked extensively on addressing these issues across a wide range of projects. Here’s a look at two common approaches to building sunlight-readable displays, and how to choose the right solution depending on your application needs.

⸻

Option 1: Transflective TFT Displays

Transflective displays use a special structure that reflects ambient light to enhance readability without depending solely on backlight brightness.

Pros:
• Excellent readability under direct sunlight
• Lower power consumption (since backlight usage decreases under bright conditions)

Cons:
• Much higher cost compared to standard mass-produced TFT modules
(see our TFT Factory Overview for how Rocktech handles high-volume, cost-optimized display production)
• Limited color vibrancy compared to transmissive displays
• Typically longer lead times and limited panel options

Because of the high cost and complex supply chain, transflective solutions are often reserved for mission-critical, specialized industries like aviation or military-grade equipment.

⸻

Option 2: High-Brightness TFT Displays

The more practical and widely used method is simply boosting the backlight brightness of the TFT display.

Modern high-brightness displays can reach 1000 nits or more, providing excellent visibility even under direct sunlight. This approach balances performance, cost, and availability.

At Rocktech, we offer a wide range of High Brightness Display options — making it easier to design devices for outdoor kiosks, smart parking systems, agricultural equipment, marine displays, and more.

If you’re looking for an effective and cost-efficient sunlight-readable solution, high-brightness TFTs are typically the way to go.

⸻

Don’t Forget the SBC!

Designing a sunlight-readable display is only half the challenge — you also need a powerful, reliable embedded platform to drive it.

Whether you’re building a smart outdoor controller, a rugged HMI, or an industrial tablet, choosing the right Single Board Computer (SBC) is key.

At Rocktech Embedded SBC Solutions, we provide customizable Android/Linux SBCs designed for industrial use, supporting high-brightness TFTs out of the box.

👉 If you’re looking for display configuration examples for Rockchip-based SBCs, you can explore this TFT Display Configuration Hub with ready-to-use DTS overlays and panel drivers.

⸻

Final Thoughts

When designing for bright environments, understanding your display technology options makes all the difference.
• If cost is no concern and maximum readability is required: consider transflective panels.
• For most commercial and industrial applications: high-brightness TFTs offer the best balance of cost, availability, and performance.

With the right combination of high-brightness displays and rugged embedded systems, you can ensure your product delivers an outstanding user experience — no matter how bright the surroundings are.

How to Design a Custom SBC That Supports Multiple Displays Interfaces and Sizes

Kevin zhang — Thu, 24 Apr 2025 12:47:20 +0000

In the world of embedded hardware, one thing is certain: display requirements vary a lot. Some products need a 4” screen, others use 7” or even 10.1”. The interfaces could also differ: RGB, LVDS, or MIPI-DSI.

So how can we design a custom single board computer (SBC) that can support multiple display types — without changing the main hardware?

This post shares some practical design strategies we use in real-world projects involving Rockchip-based Android/Linux SBCs.

⸻

The Challenge: Varying Display Requirements

In many custom product designs, we often face the following situations:
• The same device may need different screen sizes for different markets.
• Some product lines want a high-end model with a MIPI screen and a budget model with an RGB display.
• The final display is undecided when hardware design starts.

Without proper planning, any change in screen type can lead to PCB redesigns, cost increases, and delays.

⸻

Solution: Designing SBCs for Multi-Screen Compatibility

To solve this, we follow three main strategies during custom SBC design.

Reserve Multiple Display Interfaces on Hardware

We typically include all of the following:
• 24-bit RGB interface for standard TFT LCDs
• LVDS channels for industrial or higher resolution displays
• MIPI-DSI (2/4 lane) for modern, high-PPI screens

With some jumper settings, GPIO control, or optional resistors, we can switch between display types without changing the core board.

⸻

Dynamic Software Configuration

Even with the same interface (e.g., MIPI), different displays may require different:
• Resolution and timing
• Backlight control
• Power-on sequences
• VCOM or I²C initialization settings

We use:
• Device Tree overlays in Linux
• Android panel driver configs
• Parameter tables in XML/JSON formats

This allows us to load the right settings at runtime based on screen model.

⸻

Driver Abstraction for Multiple Panels

In our Android/Linux BSPs, we implement modular panel drivers like this:

&panel {
    compatible = "rocktech,7inch-lvds";
    backlight = <&backlight>;
    power-supply = <&vcc3v3>;
    ...
}

We can switch between compatible panels via boot arguments or compile-time flags — no need to rebuild the whole kernel.

⸻

Benefits of Multi-Screen Compatible SBCs

By following this design approach, our customers enjoy:
• 🧩 One SBC fits multiple models — reduced production complexity
• ⚡ Faster sample delivery and testing
• 🔄 Flexible supply chain and display sourcing
• 💡 Seamless screen replacement without hardware changes

⸻

Final Thoughts

In today’s competitive embedded market, flexibility is key. Designing SBCs that support multiple display types makes your product future-proof, cost-effective, and easier to scale.

We’ve successfully applied this approach to various Rockchip SoCs like PX30, RK3566, and RK3288 — building custom Android/Linux boards with flexible display support.

If you’re developing a smart terminal, control panel, or HMI device and want to support different screens with one board — feel free to connect and share your requirements. We’re happy to help!

👉 Learn more:
🔗 Custom SBC Solutions

Related Project

If you’re looking for a real-world implementation of this concept, check out our setup example using a Rockchip PX30 SBC with the RK050BHD335 display:
👉 PX30 + RK050BHD335 Android Display Configuration

DEV Community: Rocktech Displays Limited

Aspect Ratios in Embedded Displays: What Developers Need to Know

📐 Introduction

📊 What Is Aspect Ratio?

🎨 UI/UX Design Considerations

1. Content Layout Flexibility

2. Font & Touch Target Sizing

3. Animation and Transitions

🧱 Hardware Integration

1. PCB and Enclosure Design

2. Connector Placement

3. Power Management

🧪 Industrial Applications

🧠 Developer Tips

🔗 External Reference

🧭 Conclusion

Designing a Smart Home Control Panel with PX30 and LVGL / Qt5 on Linux Buildroot

Designing a Smart Home Control Panel with PX30 and LVGL / Qt5 on Linux Buildroot

Why PX30?

LVGL vs Qt5: Embedded GUI Options

Recommendation:

Wi-Fi Configuration & OTA Readiness

Backlight and Touch Tuning

Real-World Use Case: Embedded Smart Panel

Final Thoughts

Rockchip vs NXP – A Deep‑Dive for Product Teams Choosing Their Next Embedded SoC

1 | Executive Summary

2 | Real‑Time Behaviour: Why NXP Still Wins Ultra‑Deterministic Loads

2.1 Kernel & Scheduler

2.2 Practical Take‑Away

3 | Big‑LITTLE Compute & Multimedia Throughput

4 | Cost & Supply‑Chain Economics

5 | Software Stacks & Toolchains

6 | Security & Compliance

7 | Real‑World Case Studies

7.1 High‑Speed Pick‑&‑Place Robot (SMT)

7.2 4 K Retail Smart Mirror

7.3 Battery‑Powered Smart Lock Hub

8 | Decision Tree

9 | Key Tips When Switching Vendors

10 | Conclusion

How to Design Displays for Outdoor or High Ambient Light Environments

Option 1: Transflective TFT Displays

Option 2: High-Brightness TFT Displays

Don’t Forget the SBC!

Final Thoughts

How to Design a Custom SBC That Supports Multiple Displays Interfaces and Sizes

The Challenge: Varying Display Requirements

Solution: Designing SBCs for Multi-Screen Compatibility

Final Thoughts

Related Project

Rockchip vs NXP – A Deep‑Dive for Product Teams Choosing Their Next Embedded SoC

1 | Executive Summary

2 | Real‑Time Behaviour: Why NXP Still Wins Ultra‑Deterministic Loads

3 | Big‑LITTLE Compute & Multimedia Throughput

4 | Cost & Supply‑Chain Economics

5 | Software Stacks & Toolchains

6 | Security & Compliance

7 | Real‑World Case Studies

7.2 4 K Retail Smart Mirror

7.3 Battery‑Powered Smart Lock Hub

8 | Decision Tree

9 | Key Tips When Switching Vendors

10 | Conclusion