Runtime limitations

Arduino UNO R3, ESP32, ESP32-C3 and ESP32-S3 use separate browser runtime paths. ESP-IDF ESP32/C3 also have runtime adapters; ESP-IDF S3 build/runtime remains unavailable. Selecting another board does not run its image through the C3 engine. See Supported boards.

A placed component is not proof of modeled firmware interaction. Check the selected target’s runtime capability message. C3 and UNO support the local simulation-test/debug paths. Original ESP32 has GPIO/serial but lacks firmware-visible I²C devices. S3 circuit peripheral inputs/debug remain unavailable.

Compilation success confirms that the toolchain accepted the source. It does not verify physical electrical behavior, all peripheral protocols, or real-time timing. Browser scheduling changes when the tab is hidden or the host is busy; use sensible timing tolerances and verify physical designs on hardware.

Java editor analysis is conservative; full classpath validation happens during compilation. Project JUnit requires a saved project and remote isolated execution. Project tests are advisory and excluded from authoritative teacher grading. Binary Java resources, Maven/Gradle project management, JUnit debugging/coverage and durable JUnit history are unavailable.

Virtual Lab has its own supported adapter and service limits. Managed persistent storage and shared hosted Java peers remain unfinished. Do not assume unrestricted Internet access, host filesystem access, TLS/HTTP2 parity or physical Wi-Fi from a modeled lab. See Virtual Lab.

When behavior fails, first check target, build diagnostics, component power/ground/pin connections and capability messages. An unavailable service or worker is not a failed assertion. Keep a saved/downloaded copy before retrying recovery actions.