Integrating FlashRunner 2.0 into Python-Based Production Workflows

Modern production lines and automated test environments increasingly rely on Python. It runs natively on embedded Linux boards, integrates directly into CI/CD pipelines, and powers the automation layer of countless factory tools. Until now, connecting those environments to FlashRunner 2.0 meant bridging through a C/C++ or C# integration layer — an additional dependency that not every team can afford to maintain.

The fr_comm Python library removes that constraint. It delivers a standard pip-installable wheel that exposes the complete FlashRunner communication interface — device commands, file transfers, project execution, data encryption and real-time logging — directly from Python 3.10 or newer, on Windows, Linux and ARM Linux.

• Full device control over LAN and USB/Serial, at up to 3 Mbaud
• Runs on Windows, Linux and ARM Linux
• Installed with a single pip command; only two runtime dependencies
• Mirrors the C/C++ and C# library conventions, so existing integrators face a minimal learning curve
• Requires Python 3.10 or newer

Getting started

Install the wheel:

python -m pip install fr_comm_python-1.0.0.0-py3-none-any.whl

Verify the installation:

python -c "import fr_comm; print('import ok')"
python -c "from fr_comm import FR_GetDllVersion; print(FR_GetDllVersion())"

That is all the setup required. The following minimal example opens a LAN session, queries the device status and handles errors — ready to extend into a full production script:

from fr_comm import FlashRunner, FR_Comm_Exception

try:
    with FlashRunner("LAN", "192.168.1.100:1234") as fr:
        fr.FR_SendCommand("#GETENGSTATUS")
        print(fr.FR_GetAnswer(1500))
except FR_Comm_Exception as exc:
    print(exc)

A focused, stable public API

Customer applications interact through six public symbols. The surface is deliberately small, which keeps integrations straightforward and upgrade paths clean:

• FlashRunner — the main class; opens the device session and exposes all operations.
• FR_Logger — an independent real-time logger client, available over LAN.
• FR_Comm_Exception — a single exception type for all communication and protocol errors.
• FR_FileType — enumeration of the supported file categories: FRB, PRJ, LIC, LOG, LIB.
• ProgressHandler — an optional callback interface for file transfer progress reporting.
• FR_GetDllVersion() — returns the library version string for runtime validation.

Flexible connection options

A FlashRunner instance opens the connection immediately on construction. Using a with block is the recommended pattern: the session is closed automatically and correctly even if an exception occurs mid-operation.

FlashRunner("LAN", "192.168.1.100:1234")   # LAN, the most common production setup
FlashRunner("COM3", "115200")              # USB/Serial on Windows
FlashRunner("/dev/ttyUSB0", "115200")      # USB/Serial on Linux

Both 115200 and 3000000 baud are supported. FlashRunner starts at 115200; to switch to 3 Mbaud, send #55*SETSERIALBAUDRATE HIGH at 115200 first, then match the baud rate on the host before continuing. This makes high-throughput transfers practical even over a direct USB connection.

Device operations

Command execution follows a simple send/receive pattern. FR_SendCommand() delivers any FlashRunner command string; FR_GetAnswer() collects the device response with a configurable timeout:

fr.FR_SendCommand("#GETENGSTATUS")
answer = fr.FR_GetAnswer(1500)   # timeout in ms

For multi-channel scenarios, FR_SendCommand_Ex() targets an explicit channel list and builds the channel header automatically, eliminating manual string formatting in the calling code:

fr.FR_SendCommand_Ex([1, 2], "RUN Project.prj")
answer = fr.FR_GetAnswer(1500)

File transfer works in both directions. An optional ProgressHandler delivers percentage updates, which is useful for console feedback or UI progress bars during longer transfers:

fr.FR_SendFile(r"C:\FlashRunner\app.frb", FR_FileType.FRB)
fr.FR_GetFile("app.frb", r"C:\FlashRunner\dest", FR_FileType.FRB)

Project execution is a single call. FR_RunProject() blocks until all channels complete or the timeout expires. An optional per-channel callback makes it easy to feed results straight into an MES or test reporting system:

def on_done(channel: int, result: bool) -> None:
    print(f"channel {channel}: {'OK' if result else 'FAIL'}")

fr.FR_RunProject("demo.prj", [1, 2, 3], 120000, on_done)

Built-in data encryption for dynamic memory

Applications that write protected content to FlashRunner dynamic memory can perform RSA/AES encryption entirely within Python, with no external tooling. FR_GetPublicKey() retrieves and stores the device public key; two encryption modes are then available, depending on the workload:

• Single-shot (FR_EncryptData) — each call generates a fresh AES key and IV, and returns both the encrypted payload and the RSA-wrapped header. The header must be sent to the device before each data block. Simple and self-contained, and well suited to isolated or infrequent writes.
• Session-based (FR_DynMem*) — FR_DynMemBeginEncryption() establishes the session key once and returns a single header to send to the device. FR_DynMemEncryptData() then encrypts multiple consecutive blocks with automatic CBC IV chaining, so there are no repeated header transfers and no session management overhead. FR_DynMemResetEncryption() closes the session. This is the preferred approach when writing a sequence of blocks to the same dynamic memory area.

Typical application scenarios

• Automated test benches that flash firmware, run a validation project on multiple channels, and feed pass/fail results into a test framework or MES — entirely over LAN, with no Windows host requirement.
• Production line controllers running on embedded Linux boards, managing FlashRunner sessions and reporting programming outcomes to a central system in real time.
• CI/CD pipelines that upload updated firmware binaries to FlashRunner, trigger a programming run, and assert the outcome programmatically as part of a build verification step.
• Migration paths for existing Python factory tools that need FlashRunner support without introducing a C/C++ or C# dependency into the project.

Why it matters

• Cross-platform with no code changes: the same wheel runs on a Windows workstation, a Linux server and an embedded Linux board on the factory floor.
• Minimal integration cost: one pip command, two dependencies, one import — from zero to a working device session in minutes.
• Familiar API: it mirrors the established C/C++ and C# library conventions, so teams already using FlashRunner can move to Python without relearning the integration model.
• Session-oriented design: a single FlashRunner instance manages the full connection lifetime, keeping integration code clean and predictable.
• Structured error handling: all failures surface through FR_Comm_Exception with an optional machine-readable error code, making automated error classification straightforward.

The fr_comm library extends FlashRunner 2.0 to Python-based production and test environments without compromise. Every operation available through the C/C++ and C# libraries — commands, file transfers, project execution, encryption and real-time logging — is accessible through a single pip-installable wheel, on any platform where Python 3.10 runs.

For teams building automation around FlashRunner, this means shorter integration cycles, fewer toolchain dependencies, and a direct path from a Python script to a fully controlled programming station — whether that station sits on a development workstation or is embedded in a production line.