GITNUXSOFTWARE ADVICE
Technology Digital MediaTop 10 Best Firmware Hardware Software of 2026
Ranking and comparison of firmware hardware software tools, covering SEGGER Embedded Studio and Memfault for selecting options by use case.
How we ranked these tools
Gitnux editors write the brief first: the topic, the inclusion rules, and the frame for what belongs.
Agents extract product evidence with provenance, then collect written reviews and transcribe video reviews and podcasts.
Framework: Features 40% · Ease 30% · Value 30%
Gitnux may earn a commission through links on this page — this does not influence rankings. Editorial policy
SEGGER Embedded Studio is the right core pick for firmware teams that need deep debug and trace integrated with repeatable build artifacts, while PlatformIO works better when you need repeatable build and CI-driven flashing across lots of different boards.
Editor’s top 3 picks
Three quick recommendations before you dive into the full comparison below — each one leads on a different dimension.
SEGGER Embedded Studio
Tightly integrated trace and performance views that align timing anomalies with source-level execution.
Best for: Fits when firmware teams need deep debug and trace integration for repeatable build artifacts.
PlatformIO
Editor pickPlatformIO Unified build and environment configuration ties toolchain selection, flashing, and debugging to one project model.
Best for: Fits when teams need repeatable firmware build and CI-driven flashing for many boards.
Memfault
Editor pickRelease tracking that maps device events back to specific firmware builds and highlights regressions across fleets.
Best for: Fits when firmware teams need version-aware fleet visibility and regression-focused triage.
Comparison Table
SEGGER Embedded Studio
enterpriseCross-platform IDE for ARM and RISC-V firmware with integrated compiler and J-Link debugging.
Tightly integrated trace and performance views that align timing anomalies with source-level execution.
SEGGER Embedded Studio centers on an IDE workflow that connects editor, compiler, debugger, and device trace outputs into one run loop. Integration depth is strongest when projects align with SEGGER debugging and trace tooling and when teams need consistent build artifacts across factory programming and field firmware update pipelines. The data path is largely binary-centric since the core workflow produces debug-friendly ELF plus compiler outputs for flash or update packaging rather than an external firmware schema.
A key tradeoff is that automation and governance are driven through project configuration, makefile style build steps, and IDE-run controls rather than a broad external API surface for third-party systems. Automation works best for teams that can standardize environment variables, target configurations, and build commands so continuous integration can reproduce the same firmware package. It fits organizations that need frequent debugging and performance iteration on the same hardware target family, including regression-style validation on the same board support package setup.
- +Single IDE workflow connects build, debug, and trace views for firmware iteration
- +Cross-compilation projects stay reproducible through target templates and configuration
- +Source-level debugging supports real-time diagnosis with fine-grained trace context
- +Generated firmware binaries integrate directly with common programming and update steps
- –Automation and governance rely more on build scripting than on a rich external API
- –Advanced target workflows can require disciplined configuration of board support packages
Embedded firmware teams
Debug timing faults in RTOS builds
Shorter root-cause cycles
Device platform engineers
Standardize BSP builds across targets
Fewer build mismatches
Show 1 more scenario
Validation engineers
Regression firmware generation for testing
More consistent validation runs
Produce reproducible debug-friendly binaries that align with hardware-in-the-loop test runs.
Best for: Fits when firmware teams need deep debug and trace integration for repeatable build artifacts.
PlatformIO
open-sourceCross-platform build system and IDE for embedded firmware development across hundreds of hardware boards.
PlatformIO Unified build and environment configuration ties toolchain selection, flashing, and debugging to one project model.
PlatformIO is a strong fit for teams that need repeatable embedded builds across boards, because it manages compilers, frameworks, and device definitions per project. Its core workflow centers on a configuration model that pins platforms and frameworks, then produces build outputs ready for flashing and debug sessions. The automation surface includes command targets that can be invoked from local tooling or CI to generate binaries and run device-related steps. Extensibility is handled through a plugin model that can add new workflows, environments, and tool integrations without rewriting the build system.
A tradeoff appears in governance control, because PlatformIO relies heavily on repository conventions and configuration discipline rather than a centralized RBAC and policy layer. It fits teams doing factory programming and validation workflows where consistent firmware packaging and scripted flashing commands matter. It is less suitable when a program must be governed through fine-grained administrative controls and audit log policies tied to enterprise identity systems.
- +Project configuration pins toolchains for consistent cross-board firmware builds
- +Integrated flashing and debug workflow reduces separate setup steps
- +Command targets enable CI automation around generated firmware binaries
- +Extension ecosystem adds board and workflow integrations without custom build scripts
- –Centralized RBAC and audit log controls are not a native governance feature
- –Advanced device provisioning flows often require external scripts or add-ons
Embedded firmware teams
Cross-board builds in one repository
Fewer toolchain drift issues
CI and release engineers
Automate firmware packaging artifacts
Consistent release artifacts
Show 1 more scenario
Hardware validation engineers
Scripted flashing and debug sessions
Higher test repeatability
Invoke unified flashing and debug commands to standardize regression checks on connected boards.
Best for: Fits when teams need repeatable firmware build and CI-driven flashing for many boards.
Memfault
SaaSCloud observability platform for monitoring firmware crashes and device health in deployed hardware.
Release tracking that maps device events back to specific firmware builds and highlights regressions across fleets.
Memfault ingests crash and health events from firmware and correlates them with build and release metadata so engineering teams can see regressions tied to specific firmware packages. It also provides dashboards and alerting for fleet trends, plus workflows that prioritize issues by frequency and impact across device populations. Teams evaluating firmware hardware software observability typically choose Memfault when they need tighter firmware-version correlation than general-purpose APM tools.
A key tradeoff is integration effort because device telemetry requires firmware instrumentation and event mapping before signals become useful. Memfault fits best when the firmware pipeline already produces stable version identifiers and when teams want continuous visibility after over-the-air style updates. It fits less well for organizations that only need passive log streaming without version-aware release analysis.
- +Firmware-version correlated fleet dashboards for release health
- +Event ingestion model tailored to embedded crash and health signals
- +Alerting that targets regressions instead of raw volume
- +Workflow support for turning telemetry into issue triage
- –Firmware instrumentation and event mapping add integration workload
- –Governance controls can feel limited for highly segmented orgs
Embedded firmware teams
Track regressions after firmware rollouts
Faster rollback decisions
Device operations teams
Monitor fleet health over time
Lower mean time to detect
Show 1 more scenario
QA and validation engineers
Close the loop on test findings
Better regression confidence
Compare lab issues against field telemetry to confirm whether fixes behave at scale.
Best for: Fits when firmware teams need version-aware fleet visibility and regression-focused triage.
IAR Embedded Workbench
enterpriseC/C++ compiler and debugger IDE for embedded firmware across 12,000+ microcontroller targets.
Integrated debugger plus compiler option awareness for inspecting behavior tied to the exact generated binary build.
IAR Embedded Workbench focuses on building embedded firmware with a compiler, assembler, and debugger toolchain that targets microcontrollers with board-specific workflows. It pairs code generation controls with hardware-aware debugging so engineers can validate register-level behavior while iterating on binary image builds. Tooling around project configuration and build outputs supports repeatable firmware package creation for teams that need stable version compatibility across targets and variants.
- +Tight integration between compiler options and embedded debugging
- +Deterministic build outputs for reproducible firmware package creation
- +Strong target and device specialization for cross-compilation workflows
- +Good visibility into generated code quality through toolchain diagnostics
- –Automation surfaces around headless builds are less uniform than CI-centric ecosystems
- –Project configuration complexity grows quickly across many device variants
Best for: Fits when firmware teams need compiler-grade control and debugger fidelity for hardware-target iteration.
Arduino IDE
open-sourceOpen-source development environment for writing and flashing firmware to Arduino and compatible boards.
The board and platform package system ties toolchains and upload methods to each selected board profile.
Arduino IDE compiles and uploads sketches to supported Arduino boards and many compatible microcontroller devices through board-specific core packages. It integrates library management, a build pipeline that targets each selected board, and a serial monitor for interactive debugging workflows.
- +Board manager installs toolchains and upload tools per target
- +Library manager supports dependency versioning for Arduino ecosystem workflows
- +Serial Monitor and Plotter support quick instrumentation without external tooling
- +Extensible cores model supports many boards beyond Arduino-branded hardware
- –GUI-first workflow limits automation and review integration compared with CI tools
- –Build caching and incremental compilation remain limited on large multi-file projects
- –Cross-platform builds often require consistent core and tool version pinning discipline
- –Debugging relies on serial logging since the IDE lacks deep source-level debugging
Best for: Fits when teams need fast sketch-to-device iteration for common microcontroller boards with light automation.
OpenOCD
open-sourceOpen-source on-chip debugging tool for flashing and debugging firmware on ARM, MIPS, and RISC-V targets.
Session control via command-line and scripting lets harnesses program and debug embedded targets without interactive tooling.
OpenOCD coordinates firmware debugging and board bring-up by speaking with debug hardware and targets through a unified command and scripting layer. It drives JTAG and SWD flows for flash programming, breakpoint and trace-style workflows, and register level inspection during development.
- +Scripting and CLI control allow deterministic debug sessions in automation
- +JTAG and SWD support covers common microcontroller bring-up workflows
- +Target configuration files encode repeatable board and flash layouts
- +Extensive low-level commands support register inspection and fault isolation
- –Setup depends heavily on correct transport and target scripts for each board
- –Complex workflows need careful sequencing to avoid target state mismatches
- –Error messages can be terse when adapter or pin mapping is wrong
- –Large configurations can become difficult to maintain across many boards
Best for: Fits when firmware teams need repeatable JTAG or SWD control for programming and debug in automated test runs.
NXP MCUXpresso
vertical specialistNXP firmware development tools for LPC, Kinetis, and i.MX RT microcontroller families.
Peripheral configuration and code generation inside MCUXpresso IDE that stays aligned to a selected NXP device family, reducing manual register glue.
NXP MCUXpresso is a full firmware toolchain for NXP microcontrollers, centered on building, debugging, and flashing embedded software within a single integrated workflow. It packages MCUXpresso IDE with board support and peripheral configuration flows that generate low-level driver code from NXP device knowledge.
- +Tight IDE-to-device integration reduces BSP and driver mismatch risk
- +Peripheral configuration flows accelerate correct startup and register setup
- +Debug and flash support maps to NXP boards and common workflows
- +Example-based templates speed initial project scaffolding for NXP chips
- –Automation and API surface depend heavily on IDE project conventions
- –Out-of-NXP device support is limited and shifts complexity to workarounds
- –Generated configuration can be harder to review than hand-written code
- –Toolchain cohesion favors NXP ecosystems over cross-vendor firmware builds
Best for: Fits when NXP firmware teams need one environment for driver generation, debugging, and board-aligned flashing.
FreeRTOS
open-sourceReal-time operating system kernel for embedded firmware on microcontrollers.
FreeRTOS kernel offers configurable scheduling and deterministic task synchronization primitives designed for strict timing budgets.
FreeRTOS is a real-time operating system geared for microcontroller firmware, with tight control over scheduling, memory, and timing behavior. It ships with kernel primitives for task management, synchronization, and inter-task communication that map directly onto embedded constraints.
- +Deterministic scheduler options with fine-grained tick and timing control
- +Broad portability through architecture-agnostic kernel APIs and port layers
- +Lean synchronization primitives for low-latency inter-task signaling
- +Mature project structure with clear upgrade paths across releases
- –System bring-up depends heavily on correct port and interrupt configuration
- –Higher-level device frameworks like drivers and OTA are not included in core
Best for: Fits when firmware teams need deterministic RTOS primitives for constrained microcontrollers and will build drivers and update logic around them.
Microchip MPLAB X IDE
vertical specialistOfficial development environment for PIC, AVR, and SAM microcontroller firmware from Microchip.
MPLAB X IDE links device support configuration directly to debug and programming settings for Microchip targets.
Microchip MPLAB X IDE builds firmware projects for Microchip microcontrollers and supports cross-compilation, code editing, and on-target debugging from a single workspace. The IDE integrates with Microchip toolchains and device support packages so board support package files and device-specific settings stay coupled to the project configuration.
- +Tight integration with Microchip device support packages and toolchains
- +Project-driven debug and flash workflows align with selected target hardware
- +Configurable build outputs that fit firmware package handoff practices
- +Strong breakpoint and variable inspection support for common embedded debug loops
- –Cross-vendor workflows need extra glue when hardware and compilers do not match
- –Automation depends more on external tools than on an exposed IDE API
- –Large projects can slow indexing and increase workspace complexity
- –More setup effort is required for multi-board compatibility testing
Best for: Fits when embedded teams target Microchip microcontrollers and need an IDE-centered debug and build loop.
Edge Impulse
SaaSPlatform for developing and deploying machine learning models into embedded firmware on edge hardware.
Project-to-deployment artifact generation that couples sensor feature preprocessing with embedded inference code for the same target build.
Edge Impulse turns on-device ML development into an end-to-end workflow that covers data capture, model training, and embedding the result into deployable firmware packages. Teams use its project builder to compile sensor feature pipelines and produce inference code tied to specific targets.
- +End-to-end path from sensor dataset creation to on-device inference artifacts
- +Target-specific builds generate firmware-ready components for embedded deployments
- +Project workflow keeps preprocessing and model code coupled to the same configuration
- +Device deployment flows align with the Edge Impulse runtime expectations
- –Best results depend on adopting the Edge Impulse data and project workflow
- –Large-scale fleet automation needs tighter external integration for provisioning
- –Workflow abstractions can feel constraining for custom embedded toolchains
- –Hardware support coverage varies by board and sensor interface expectations
Best for: Fits when teams build sensor-driven embedded inference and want one workflow linking training to firmware artifacts.
Conclusion
After evaluating 10 firmware hardware software, SEGGER Embedded Studio stands out as our overall top pick — it scored highest across our combined criteria of features, ease of use, and value, which is why it sits at #1 in the rankings above.
Use the comparison table and detailed reviews above to validate the fit against your own requirements before committing to a tool.
How to Choose the Right Firmware Hardware Software
Firmware hardware software management spans toolchains for compiling and debugging, device programming interfaces, and the release and provisioning workflows that keep fleets aligned. This guide covers SEGGER Embedded Studio, PlatformIO, Memfault, and the other tools that shape how embedded teams build, flash, trace, and ship.
The sections after each tool review focus on integration depth, automation and API surface, and governance controls where those controls exist in the product workflow. The buying decisions in this guide target teams that need repeatable build artifacts, scripted device access, and traceable firmware-to-device behavior.
Firmware Hardware Software tools for building, flashing, debugging, and releasing embedded systems
Firmware hardware software tools coordinate embedded development inputs like compiler options and board support packages with outputs like firmware package artifacts and programming sessions. SEGGER Embedded Studio emphasizes tightly coupled trace and performance views that map timing anomalies back to source-level execution so debugging stays inside the same workflow.
PlatformIO takes a different approach by tying toolchain selection, flashing, and debugging to a unified project model so teams can standardize builds across many boards. Memfault shifts the emphasis from the lab to the field by correlating firmware builds to fleet events so release health and regressions can be triaged from version-aware dashboards.
Firmware delivery capabilities that decide integration, automation, and governance
Firmware hardware software tools succeed when they keep build inputs and debug or release actions in the same execution story. SEGGER Embedded Studio pairs build, debug, and trace views inside one workflow so timing anomalies map to source-level behavior.
Release and device lifecycle tooling matter when they preserve traceability from a firmware package back to device events in a fleet. Memfault ties device events to specific firmware builds and highlights regressions so release health does not depend on manual spreadsheets.
Traceable debug-to-build workflows
SEGGER Embedded Studio connects build, debug, and trace views in one IDE so timing anomalies align with source-level execution during firmware iteration. IAR Embedded Workbench links compiler option awareness to embedded debugging so inspection stays tied to the exact generated binary build.
Unified build and flashing environment configuration
PlatformIO uses a unified project model that binds toolchain selection, flashing, and debugging to one configuration so multi-board builds stay consistent. Arduino IDE ties board and platform package selection to upload tools through its package system so device upload uses the matching toolchain.
Automation-friendly target programming and deterministic sessions
OpenOCD supports scripted command-line session control so automated harnesses can program and debug targets via JTAG or SWD. FreeRTOS focuses on deterministic scheduling primitives so tests that rely on timing and task synchronization behave predictably on constrained microcontrollers.
Firmware-version correlated release and regression triage
Memfault maintains firmware-version correlated fleet dashboards so regressions can be identified across releases using device events mapped back to builds. SEGGER Embedded Studio focuses on repeatable build artifacts and trace views that reduce guesswork during release preparation when behavior changes between builds.
Device support alignment and configuration-driven driver generation
NXP MCUXpresso generates peripheral configuration inside an IDE aligned to selected NXP device families so register setup and startup code stay consistent. MPLAB X IDE binds device support configuration to debug and programming settings for Microchip targets so selected hardware drives the same tooling loop.
Pick the workflow that matches the team’s firmware lifecycle and governance reality
Teams should start by deciding where firmware truth lives during iteration. SEGGER Embedded Studio keeps firmware behavior and timing context inside one IDE workflow, while PlatformIO centralizes toolchain selection and flashing under a single project model.
Teams should then separate automation needs from governance expectations. OpenOCD and FreeRTOS serve automation paths through scripting and deterministic timing primitives, while Memfault adds release and regression governance through firmware-to-fleet traceability even when core governance controls are limited for highly segmented org structures.
Match the primary iteration loop to how defects get diagnosed
Choose SEGGER Embedded Studio when debug requires trace alignment that maps timing anomalies back to source-level execution inside the same IDE workflow. Choose IAR Embedded Workbench when correctness depends on inspecting behavior with compiler option awareness tied to the exact generated binary.
Decide whether a unified project model or IDE-centric configuration drives builds
Choose PlatformIO when toolchain selection, flashing, and debugging must stay pinned under one project configuration model across many boards. Choose Arduino IDE when board manager and library manager workflows target fast iteration with board profiles and lighter automation needs.
Lock down automated target programming using scripting control
Choose OpenOCD when programming and debug sessions must run via deterministic command-line control in automated harnesses using JTAG or SWD. Choose SEGGER Embedded Studio when automation must be built around internal workflow and build scripting rather than expecting a rich external automation API.
Select the release governance shape the team can actually operate
Choose Memfault when firmware-to-fleet release traceability and regression highlights drive triage and when version-aware dashboards matter more than IDE debug depth. Choose PlatformIO when keeping builds reproducible across boards under a pinned project model is the governance mechanism and fleet governance depends on external systems.
Use vendor device configuration when the device family drives platform correctness
Choose NXP MCUXpresso when peripheral configuration and code generation must align to an NXP device family so register glue stays consistent. Choose MPLAB X IDE when Microchip device support packages should directly configure debug and programming settings without extra bridging layers.
Confirm whether OTA, provisioning, and fleet-scale workflows need external glue
Choose Memfault when release mapping to device events is the primary need, then plan for integration workload caused by firmware instrumentation and event mapping. Choose PlatformIO and Arduino IDE when advanced device provisioning workflows require external scripts or add-ons and when central RBAC and audit log controls are not native governance features.
Teams that get the most from Firmware Hardware Software workflows
Firmware teams benefit most when the tool set matches how they build, diagnose, program, and release firmware across device lifecycles. Build and debug integration matters for engineers who need to correlate behavior changes with specific artifacts.
Fleet visibility matters for teams who need release health and regression triage from device events rather than manual QA results. Governance controls matter only when the product workflow exposes automation and access control surfaces that align with the organization’s processes.
Embedded debug-focused teams building repeatable firmware artifacts
SEGGER Embedded Studio fits when a single IDE workflow must connect build, debug, and trace views for rapid firmware iteration. IAR Embedded Workbench fits when compiler option awareness must stay tied to the exact generated binary during hardware-target iteration.
Multi-board engineering teams standardizing toolchains and CI flashing
PlatformIO fits when cross-board builds need pinned toolchain selection and integrated flashing and debugging under one project model. Arduino IDE fits when team workflows rely on board and platform packages and library dependency versioning for common microcontroller boards.
Automation and manufacturing test teams programming targets at scale
OpenOCD fits when programming and debug sessions must run from scripted command-line control over JTAG and SWD. FreeRTOS fits when deterministic scheduler behavior and timing primitives are required so bring-up and regression tests behave consistently.
Device and reliability teams running firmware release triage from real events
Memfault fits when release tracking must map device events back to specific firmware builds and highlight regressions across fleets. SEGGER Embedded Studio fits when release prep needs tight traceability into source-level execution during troubleshooting.
Vendor-family teams building peripherals and driver generation workflows
NXP MCUXpresso fits when peripheral configuration and code generation must remain aligned to selected NXP device families. MPLAB X IDE fits when Microchip device support configuration should bind directly to debug and programming settings for Microchip targets.
Where Firmware Hardware Software buyers stall and how to avoid it
Common buying failures happen when expectations for automation and governance get set from CI tools rather than from firmware-focused workflows. Another failure mode comes from assuming a desktop-first IDE will provide consistent headless automation or rich external APIs without additional build scripting.
Another failure mode comes from assuming release governance is automatic when firmware instrumentation and event mapping require integration work and when fleet workflows need provisioning glue outside the tool itself.
Choosing an IDE-centric workflow while requiring rich external automation and governance APIs
SEGGER Embedded Studio can rely more on build scripting than on a rich external API for automation and governance. Arduino IDE and MPLAB X IDE depend on external tooling for automation when the workflow needs consistent headless integration.
Assuming fleet release governance exists without firmware instrumentation and event mapping
Memfault requires instrumentation and event mapping work to tie device signals back to firmware builds. PlatformIO can provide reproducible builds but centralized RBAC and audit log controls are not native governance features so governance often shifts to external systems.
Underestimating target-specific setup and sequencing for scripted programming sessions
OpenOCD setup depends heavily on correct transport selection and target scripts for each board. Complex sequencing can cause target state mismatches so programming and debug automation needs careful harness design.
Selecting a build system that does not match the team’s device support coverage
NXP MCUXpresso out-of-NXP device support shifts complexity to workarounds when teams need cross-vendor peripheral configuration. MPLAB X IDE adds extra glue for cross-vendor workflows when hardware and compilers do not match.
Treating firmware RTOS primitives as a complete device platform
FreeRTOS provides deterministic RTOS scheduling and synchronization primitives but it does not include higher-level drivers and OTA workflows in the core. Firmware update logic and device frameworks must be built around the kernel and the team’s existing embedded software stack.
How analysts built the 2026 Firmware Hardware Software shortlist
Analysts started by opening the original publication for each tool and copying every figure that appeared beside a passage describing specific capabilities or fit. Analysts then compared each copied figure against official documentation and the changelog, with an independent review used when it was cited in the publication.
Analysts kept a figure only when it matched across those sources, and analysts included a published benchmark only when it was explicitly the benchmark source. SEGGER Embedded Studio stood out in this workflow because its integrated build, debug, and trace views directly supported the same kind of source-level timing anomaly diagnosis that the rest of the shortlist described only through broader integration or scripting paths.
Frequently Asked Questions About Firmware Hardware Software
Which tool is better for CI-driven firmware build, flashing, and repeatable artifacts: PlatformIO or OpenOCD?
How does SEGGER Embedded Studio help correlate timing regressions to source code during RTOS debugging?
When teams need telemetry tied to firmware builds, how does Memfault’s release tracking differ from using general monitoring stacks?
Which workflow fits teams that must generate board-aligned driver code and keep it consistent across NXP silicon variants: NXP MCUXpresso or Arduino IDE?
What breaks if hardware bring-up needs consistent register-level inspection but the chosen tool lacks a scripting interface: OpenOCD vs Arduino IDE?
How do data migration and schema management typically show up in firmware pipelines that track device state: Memfault or Edge Impulse?
Which tool provides stronger admin controls for developer access and audit trails in embedded debug and deployment workflows: none of the IDEs, or a dedicated telemetry layer like Memfault?
When configuration drift causes device provisioning failures, how do PlatformIO and IAR Embedded Workbench differ in controlling build outputs?
Which tool fits teams building sensor-driven embedded inference where the training pipeline must map directly to deployable firmware: Edge Impulse or FreeRTOS?
Tools reviewed
Primary sources checked during evaluation.
Referenced in the comparison table and product reviews above.
Funding and competing interests
This study was co-funded by several of the vendors assessed in it. No single vendor funded it. Funders could propose the market studied.
They had no role in selecting vendors, setting or weighting criteria, analysing data or drawing conclusions, and they received the same factual-accuracy check as every other vendor assessed.
Market definition, inclusion rules and criteria weights were fixed by an editor before research began and did not change afterwards. Editorial process →
Keep exploring
Comparing two specific tools?
Software Alternatives
See head-to-head software comparisons with feature breakdowns, pricing, and our recommendation for each use case.
Explore software alternatives→In this category
Technology Digital Media alternatives
See side-by-side comparisons of technology digital media tools and pick the right one for your stack.
Compare technology digital media tools→