Hello everyone,
We are The Engineering Projects (TEP), the developers of the Arduino Library for Proteus shared previously. We have now extended the collection with Wi-Fi board models and simulated laptop and mobile clients. We would welcome technical feedback from Arduino users, especially on API behaviour, example sketches and the differences you encounter when moving to hardware.
Scope upfront. These are functional models for testing application logic, supported peripherals and network interactions. The newer board models use our TEP Boards for Proteus add-on and an internal AVR runtime; they do not execute the original boards' native firmware.
Available board models
Each linked board name opens its download, installation guide, example project and documented limitations.
For existing AVR projects, we also provide the Arduino WiFi Shield (HDG204, Arduino WiFi library) and WiFi Shield 101 (ATWINC1500, WiFi101). These use a simulated shield with an AVR host. The Shield 101 demo uses a Mega 2560 because of the documented IRQ handling limitation on the UNO in our Proteus tests.
Control and monitoring through the TEP Network
The TEP Network is a virtual network inside the Proteus simulation. Supported devices share the TEP-WiFi router and exchange simulated TCP and UDP traffic. Our Laptop WiFi Monitor and Mobile WiFi Monitor provide the other end of those connections, directly on the schematic.
From their built-in browsers, you can open a board's HTTP page, read sensor values and send the commands implemented by its sketch. Their terminals provide TCP client/server and UDP tools; network views show devices and connectivity. This lets you test both the device logic and the client interaction in one project.
A concrete example. The Nano RP2040 Connect colour sorter below reads a TCS34725 over I2C and drives an SG90 servo on D9. The simulated laptop reads its JSON status, while the simulated phone displays the counts and sends a reset command through the board's HTTP interface.
Trying the network. Start with the supplied project and compiled HEX. Run the simulation, wait for the board to join TEP-WiFi, then open its address in either simulated browser. In this example the board serves http://192.168.1.101/ and /json. Change a sensor input, refresh the page and try resetting the counts from the phone.
The network boundary matters. These addresses belong to the simulation. A real phone on your home Wi-Fi, or Chrome on the host PC, cannot open them through this model. There is no bridge to the PC network adapter or public internet; any provided internet host is simulated. The monitor browsers support text, links and HTTP GET, without JavaScript, CSS, embedded images, POST forms or HTTPS/TLS.
Compilation and technical scope
For your own sketches, install the supplied TEP Boards for Proteus add-on and its Arduino AVR Boards dependency, select the matching TEP board, export the compiled HEX and assign it to the model's Program File. The UNO Q also requires its bundled TEPPi runtime and a Python file selected through MAINPY. Follow each package's README for its dependencies and model files.
Keep the board add-on and TEPNET.DLL compatible with the package you are using; an older DLL beside a project can override the installed copy. The supplied demonstrations were tested in Proteus 8.5 on Windows. Proteus 7 is unsupported, and we are not claiming validation across every later Proteus release.
Execution and portability. The eight board models use ATmega2560 execution at 16 MHz, with 8 KB RAM per sketch runtime and 16-bit int. GIGA uses two such runtimes. Code must stay within the implemented API subset; processor registers, native binaries, timing, memory capacity and arbitrary third-party libraries are not interchangeable with the real boards. Rebuild for the actual Arduino core and retest on hardware.
GIGA and UNO Q. GIGA supports two sketches and byte-stream RPC; RPC.bind() and RPC.call() are not implemented, and its M4 runtime is limited to the RGB LED and RPC. UNO Q runs one Python 3.11 program alongside a sketch, with model implementations of Bridge.call(), Bridge.notify() and Bridge.provide(). It does not boot Debian or run App Lab Bricks or Linux native extensions.
Board peripherals. Support varies by model: for example, Nano RP2040 Connect has no RP2040 PIO or second core, and Nano ESP32 has no FreeRTOS or PSRAM. Bluetooth, the original radio firmware and many onboard sensors or interfaces are not modelled. A component drawn on the board does not imply simulation support; check the board's feature and limitation lists.
Network and electrical fidelity. Network delays and signal indications are model values, not RF propagation measurements. The models do not validate real TLS security, throughput, power consumption, battery charging or hardware timing. Observe each README's instance restrictions; several models allow only one instance of that board type per design because of shared hidden pins.
Feedback we would find useful
Which Arduino APIs or project types would make this more useful to you? We are particularly interested in small reproducible examples that expose an unsupported call, incorrect pin behaviour, a networking problem or a difference from real hardware. Please include the board model, Proteus version, TEP add-on/model version, sketch, and expected versus observed result.
The downloads include example source and compiled model DLLs; the model source is not included. These libraries are developed independently by TEP and are not official Arduino or Labcenter products.
Thanks for reading.