Python library

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 layers of countless factory tools. Until now, connecting these environments to FlashRunner 2.0 required 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.

At a Glance

     •  Full device control over LAN, and USB/Serial (up to 3 Mbaud):

     •  Runs on Windows, Linux, and ARM Linux:

     •  Installed with a single pip command; only two runtime dependencies needed:

     •  Mirrors the C/C++ and C# library conventions — minimal learning curve for existing integrators:

     •  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, keeping integrations straightforward and upgrade paths clean:

     •  FlashRunner — main class; opens the device session and exposes all operations

     •  FR_Logger — independent real-time logger client, available over LAN

     •  FR_Comm_Exception — single exception type for all communication and protocol errors

     •  FR_FileType — enumeration for supported file categories: FRB, PRJ, LIC, LOG, LIB

     •  ProgressHandler — 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.

LAN — the most common production setup:

FlashRunner(“LAN”, “198.162.1.100:1234”)

USB/Serial on Windows:

FlashRunner(“COM3”, “115200”)

USB/Serial on Linux:

FlashRunner(“/dev/ttyUSB0”, “115200”)

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 supports both directions. An optional ProgressHandler delivers percentage updates — useful for console feedback or UI progress bars in 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 single-call. FR_RunProject() blocks until all channels complete or the timeout expires. An optional per-channel callback makes it easy to feed results directly into a 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, without 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;
         suited for 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 — no repeated header transfers, no session management overhead. FR_DynMemResetEncryption()
         closes the session. 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, without a 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.

Key Advantages

     •  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: mirrors the established C/C++ and C# library conventions, so teams already using FlashRunner can
         transition 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.

Conclusions

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 is on a development workstation or embedded in a production line.