Custom Queries, Logging and Advanced Applications

Adding your own functionality

You do not have to modify the existing master or slave workers to add a custom feature.

You can create an additional pipeline using free runtime slots:

custom_tx_query
      ↓
 custom_native
      ↓
custom_rx_query

The existing query.py can be reused. Only the worker in the middle needs a custom implementation.

Minimal custom worker

BEIIS_API = 1

async def main(ctx):
    tx_peer = ctx.config["tx_peer"]
    rx_peer = ctx.config["rx_peer"]

    while True:
        source, channel, payload = await ctx.recv()

        if source != tx_peer:
            continue

        reply = b"reply:" + bytes(payload).upper()
        ctx.send_to(rx_peer, reply, channel)

The repository contains a complete example:

examples/runtime/custom_query_worker.py
examples/runtime/install_custom_query.py
examples/runtime/custom_query_client.py

Install it:

python examples/runtime/install_custom_query.py

Test it:

python examples/runtime/custom_query_client.py "hello world"

Example response:

reply:HELLO WORLD

Logging

The standard runtime already includes:

logging_tx_query
      ↓
 logging_native
      ↓
logging_rx_query

The logging worker can be contacted and its status checked:

python examples/runtime/python_basic.py logging-ping
python examples/runtime/python_basic.py logging-status

Current implementation status

The logging pipeline is prepared, but passive electrical LIN sniffing is not yet implemented.

Therefore the worker intentionally reports:

passive RX unavailable

The interface is designed so that a native receive queue can later be connected behind the same query pipeline.

Runtime taps

A tap is different from an electrical bus sniffer.

A tap receives a copy of host/application data inside the runtime. The original message remains available to its intended recipient.

This can be used to:

• Log protocol events.
• Collect statistics.
• Produce debugging output.
• Add testing and diagnostic paths.

Potential applications

The combination of Linux applications, MicroPython runtime and native C functions offers considerably more than a conventional LIN adapter.

Electronic control unit (ECU) simulator

The microcontroller can provide predefined slave responses and react to selected requests. This allows sensors, actuators or parts of a control unit to be simulated during development and testing.

Automated test bench

A Python or C application can set LIN states, stimulate a control unit, verify its responses and log the results.

Parts of a test procedure can also run inside a runtime worker.

Gateway

A Linux application can translate LIN messages to other protocols such as Ethernet, MQTT, databases or custom IPC interfaces.

Logic directly on the microcontroller

If a reaction must occur without a Linux round trip, implement the logic in a runtime worker on the microcontroller and call native functions there.

Custom protocols over LIN

The query layer transports arbitrary binary data. A custom request/response protocol can therefore be built above the generic LIN operations.

Experiment: IP over LIN

As an architectural experiment, IPv4 packets were fragmented across LIN frames and reassembled. Real Linux endpoints were tested using ICMP, UDP and TCP.

The experiment demonstrates the runtime’s flexibility. Due to LIN’s low data rate and protocol overhead, it is not a general-purpose network replacement.

Basic principle

The lower layers remain generic:

Socket
  ↓
Query
  ↓
Worker
  ↓
Native function

The application determines what the payload means.

The same hardware can thus operate as a simple LIN adapter, an automated tester, a simulator or a specialized gateway.