📋 Assessment Module 0.2 4 Sections · 20 Questions

Software to Install —
Toolchain Readiness Assessment

Verify your understanding of every software tool required for embedded systems development, before relying on that environment throughout the rest of the course.

Module0.2 — Software to Install
TopicToolchain Readiness for the Full Course
PurposeVerify the complete development environment

About This Assessment

This assessment checks that every required piece of embedded development software is installed correctly and that you understand why each tool exists —not just how to click through its installer. It’s organized into four sections:

Section A — Multiple Choice

10 questions covering the core role of each tool.

✏️

Section B — Short Answer

5 questions requiring a written explanation in your own words.

🧠

Section C — Scenario-Based

4 real-world troubleshooting and decision-making scenarios.

📋

Section D — Verification Checklist

A practical checklist confirming every install actually works.

ASection A

Multiple Choice Questions

Each question shows the verified correct answer along with the reasoning behind it.

A1
Why does the course recommend VS Code with PlatformIO over the Arduino IDE for serious work?
Correct Answer
(b) PlatformIO supports ESP-IDF, STM32, nRF, and many MCUs from one consistent interface, along with proper Git and CI integration.
Explanation

PlatformIO provides a professional development environment where multiple embedded platforms can be developed using the same editor and workflow, rather than switching tools every time the target board changes.

A2
STM32CubeIDE is recommended for STM32 work because:
Correct Answer
(b) It bundles CubeMX (graphical pin/clock configurator), Eclipse editor, and GDB debugger in one installer.
Explanation

STM32CubeIDE provides everything required for STM32 development —configuration, coding, debugging, and flashing —in a single install.

STM32CubeIDE — one installer CubeMX pin/clock config Eclipse Editor code editor GDB Debugger breakpoints, vars ST-Link Support (flash + debug) uploads & connects to hardware

Everything needed for STM32 development ships together —no separate CubeMX install required.

A3
nRF Connect SDK (NCS) is built on top of:
Correct Answer
(b) Zephyr RTOS
Explanation

The nRF Connect SDK uses Zephyr RTOS as its foundation and adds Nordic-specific libraries and tools on top.

A4
Why is WSL2 (or native Linux) required for Module 13 (Embedded Linux)?
Correct Answer
(a) Yocto and Buildroot only run on Linux hosts.
Explanation

These Linux build systems require a genuine Linux environment, which WSL2 provides directly inside Windows.

A5
Which tool should you use first if your I²C sensor is reading incorrect values?
Correct Answer
(b) PulseView
Explanation

PulseView captures and decodes I²C communication at the wire level, making it easy to verify the actual data being transmitted between the sensor and the microcontroller.

A6
Wireshark is mainly used from Module 11 onward for:
Correct Answer
(b) Inspecting Ethernet, TCP, MQTT, TLS, and other network packets.
Explanation

Wireshark analyzes network traffic and helps debug communication over network protocols, distinct from the hardware-bus debugging PulseView handles.

PulseView — Hardware Buses Logic Analyzer Capture UART · SPI · I²C · CAN · RS-485 decodes raw signal transitions on wires Physical / Wire-level layer Wireshark — Computer Networks Network Packet Capture Ethernet · TCP/IP · HTTP · MQTT · TLS decodes packets on a network connection Network / Internet layer Same goal —visibility into raw communication —at two different layers

Hardware bus vs network: same debugging instinct, applied at two completely different layers of the stack.

A7
PuTTY or screen are primarily used as:
Correct Answer
(b) Serial console clients for communicating with UART over USB.
Explanation

They allow developers to view serial output (printf) and send commands directly to the microcontroller.

A8
ESP-IDF v5.x is best installed through:
Correct Answer
(b) PlatformIO's framework = espidf
Explanation

PlatformIO automatically manages the ESP-IDF toolchain, its dependencies, and version updates —no need to manage them manually.

A9
Why is Git introduced in Module 0.2?
Correct Answer
(b) Every project in the course uses Git, while detailed Git concepts are covered in Module 0.3.
Explanation

Git helps track project changes and manage source code throughout the course, so it needs to be installed early even though it’s taught in depth later.

A10
Why are both PulseView and Wireshark required?
Correct Answer
(b) PulseView analyzes physical communication buses, while Wireshark analyzes network communication.
Explanation

Both tools decode different layers of communication and serve different debugging purposes —one for the wire, one for the network.

BSection B

Short Answer Questions

Each answer is written out in full, in your own words.

B1
Your friend says “Why not just use Arduino IDE for everything in the course?” Give two concrete capabilities of PlatformIO + VS Code that you will need in later modules and Arduino IDE cannot provide.

Arduino IDE is a good choice for beginners and small projects, but it has limited features for professional embedded development. PlatformIO with VS Code supports many different boards such as ESP32, STM32, and Nordic nRF, allowing us to use one editor throughout the course instead of learning a different IDE for every manufacturer.

Another important capability is debugging. PlatformIO supports GDB debugging, which lets us set breakpoints, inspect variables, and troubleshoot programs far more effectively than Arduino IDE allows. It also provides better Git integration and project management for larger embedded applications.

B2
Explain the difference between STM32CubeIDE and STM32CubeMX. Do you need both?

STM32CubeMX is a graphical configuration tool used to configure STM32 microcontrollers. It helps us select GPIO pins, configure clocks, enable peripherals like UART, SPI, and I²C, and automatically generate initialization code.

STM32CubeIDE is a complete Integrated Development Environment. It includes CubeMX along with a code editor, compiler, debugger, and flashing tools. Since CubeMX is already bundled inside CubeIDE, installing CubeIDE alone is enough for most users —no separate CubeMX install is required.

STM32CubeMX
Configuration tool only.
Pins, clocks, peripherals.
Generates init code.
STM32CubeIDE
Complete IDE.
Includes CubeMX + editor + debugger.
One install covers everything.
B3
List three pieces of software from the parts list that you’d be unable to use if you skipped the WSL2 install on Windows, and explain why.

Without WSL2, several Linux-based tools required later in the course would not work properly:

  • Yocto Project — used to build custom Embedded Linux systems, and requires a Linux environment.
  • Buildroot — another Linux build system that depends on Linux commands and utilities.
  • Linux bash scripts and command-line tools — many automation scripts used in embedded development are written for Linux and run smoothly inside WSL2.

WSL2 provides a genuine Linux environment on Windows, allowing these tools to work without installing a separate Linux operating system.

Windows Host WSL2 — Linux Environment Yocto Buildroot Bash Scripts & CLI Tools

WSL2 doesn’t replace Windows —it runs alongside it, giving Linux-only build systems somewhere to actually execute.

B4
After installing nRF Connect for Desktop you must also install at least one nRF Connect SDK version via the Toolchain Manager. Why is this two-step?

nRF Connect for Desktop is mainly a launcher that provides access to various Nordic development tools. By itself, it cannot compile or build embedded applications.

The actual development environment is provided by the nRF Connect SDK, which is downloaded using the Toolchain Manager. The SDK includes Zephyr RTOS, compilers, libraries, and other required development tools. Keeping the SDK separate from the launcher also allows multiple SDK versions to be installed side by side for different projects.

B5
You finish Module 0.2 and check your install by trying to blink an LED on every board. Which boards/toolchains will you actually validate, and what command or action proves each toolchain is working?

To verify that every software installation is working correctly, a simple Blink program is built and uploaded to each supported board:

Board / ToolchainAction that proves it works
ESP32 (Arduino IDE)Upload the Blink example and verify the LED blinks.
ESP32 (PlatformIO + ESP-IDF)Run pio run -t upload and confirm the LED blinks.
STM32 NucleoBuild and flash the Blink project using STM32CubeIDE.
nRF52840 DKBuild and flash the blinky sample using the nRF Connect SDK.
Raspberry Pi / Linux SBC (if available)Boot Linux successfully and run a simple GPIO test.

If each board successfully builds, flashes, and runs the Blink program, the corresponding toolchain is confirmed working.

CSection C

Scenario-Based Questions

Real troubleshooting and decision-making situations you’ll actually run into.

C1
Your STM32CubeIDE refuses to detect your ST-Link. What is the order of checks you would run?

If STM32CubeIDE cannot detect the ST-Link, the following checks are run in order:

1
Check the USB cable
Verify it supports both power and data transfer —many cables are charge-only.
2
Check board power
Ensure the STM32 board itself is powered correctly.
3
Check OS-level detection
Use Device Manager (Windows) or lsusb (Linux) to confirm the ST-Link is even detected at the operating system level.
4
Install or update drivers
Reinstall or update the ST-Link drivers if the device isn’t recognized.
5
Update ST-Link firmware
Use the ST-Link Upgrade utility to bring the probe’s own firmware current.
6
Restart and reconnect
Restart STM32CubeIDE and reconnect the board fresh.
7
Try another cable or port
If the issue persists, swap the USB cable or try a different USB port.
💡
Why This Order
Following these steps in sequence helps isolate whether the problem is caused by the physical connection, board power, drivers, firmware, or the IDE itself —cheapest and most likely causes checked first.
C2
You have ESP-IDF v5.x and Arduino-ESP32 framework installed via PlatformIO. Are they conflicting? Why or why not?

No, they do not conflict with each other.

PlatformIO manages each project separately. Every project contains a platformio.ini file where the required framework —Arduino or ESP-IDF —is chosen explicitly. Since each project uses its own isolated build environment, both frameworks can be installed on the same computer and used independently without affecting one another.

Same machine — isolated PlatformIO projects Project A platformio.ini framework = arduino board = esp32dev Project B platformio.ini framework = espidf board = esp32dev

Each project’s platformio.ini defines its own framework and build environment —no shared state, no conflict.

C3
You need to inspect what’s actually being sent on a Modbus RTU bus during Module 7. Pick the right tool and explain how it differs from Wireshark.
Correct Tool
PulseView

PulseView works with a logic analyzer to capture signals directly from communication buses such as UART, SPI, I²C, CAN, and Modbus RTU. It decodes the transmitted data and displays the actual communication frames.

Wireshark is different because it captures network traffic such as Ethernet, Wi-Fi, TCP/IP, MQTT, and HTTP. Since Modbus RTU uses serial communication rather than a network, PulseView is the correct tool for this task —the same distinction covered in A5/A10 above.

C4
List the five tools you should keep running simultaneously during a typical Module 5 STM32 debug session.

During an STM32 debugging session, it is useful to keep these five open at once:

A Typical Module 5 Debug Workspace STM32CubeIDE write, build, flash, and debug firmware PuTTY / Serial Term. monitor UART output and debug messages PulseView + Logic Analyzer monitor UART/SPI/I²C protocol traffic Digital Multimeter verify voltages and hardware connections STM32 Reference Manual check peripheral registers and hardware details

Five tools, five different vantage points on the same bug —firmware, serial output, bus traffic, hardware voltages, and the datasheet itself.

1
STM32CubeIDE — writing, building, flashing, and debugging the firmware
2
PuTTY (or another serial terminal) — monitoring UART output and debug messages
3
PulseView with a Logic Analyzer — monitoring UART, SPI, and I²C traffic
4
Digital Multimeter — verifying voltages and hardware connections
5
STM32 Reference Manual / Datasheet — checking peripheral registers and hardware details
DSection D

Software Installation Verification Checklist

A practical, repeatable way to confirm every tool actually works —not just that it installed.

SoftwareVerification Method
VS CodeOpens successfully and creates a new project
PlatformIO ExtensionBuilds and uploads a sample project successfully
C/C++ ExtensionIntelliSense and code completion work correctly
Arduino IDEBlink sketch compiles and uploads successfully
ESP-IDF (PlatformIO)pio run -t upload completes successfully
STM32CubeIDEBuild, flash, and debug a Blink project
ST-Link DriversBoard is detected and firmware update works
nRF Connect for DesktopOpens and launches applications successfully
nRF Connect SDKBuilds and flashes the blinky sample
nRF Connect VS Code ExtensionDetects installed SDK and creates projects
nRF Connect MobileConnects successfully to a BLE device
Gitgit --version, git init, and git clone work correctly
PuTTY / Screen / PicocomOpens the serial port and displays UART output
WiresharkCaptures and displays network packets
PulseViewDetects the logic analyzer and captures signals
WSL2 + UbuntuUbuntu launches successfully and Linux commands execute correctly
How to Use This Table
Work down the list in order, completing the verification action for each tool before moving on. If any row fails, resolve it before continuing —a broken toolchain caught here is far cheaper to fix than one discovered mid-module.
Close

Summary

By completing this assessment, we verify that…
  • All required development software is installed correctly.
  • Each embedded platform (ESP32, STM32, nRF, and Linux SBC) has a working toolchain.
  • Essential debugging and communication tools are ready for future modules.
  • The development environment is prepared for building, flashing, debugging, and testing embedded applications throughout the course.

End of Assessment — Module 0.2

Embedded Systems Foundations — Assessment, Module 0.2: Software to Install