DEV Community: piko::tutorial

git log tricks you really should know

piko::tutorial — Mon, 03 Aug 2026 05:00:00 +0000

git log is one of the most powerful and yet most underused inspection tools in Git. While many developers use it only to view basic commit history, it can be turned into a highly flexible data-extraction and data-generation tool. With the right flags and formatting options, git log becomes not just a history viewer, but an element of data pipeline for debugging, analytics and automation.

Below are several advanced usage patterns that go well beyond the default experience.

Structured output with `--pretty=format:`

One of the most powerful features is using --pretty=format: to control exactly how commit data is printed. This is especially useful when you want to process git log output further with some scripts. Instead of nice-looking and human-readable logs, you can output records that are easy to parse:

git log --pretty=format:"%H|%an|%ad|%s" --date=iso

This produces pipe-separated fields:

%H - full commit hash
%an - author name
%ad - author date
%s - commit subject
--date=iso - converts dates from Fri May 22 16:08:53 2025 to 2025-05-22 16:08:53 +0200

Now, you can easily parse it with scripts like:

import subprocess

output = subprocess.check_output([
    "git", "log",
    "--pretty=format:%H|%an|%ad|%s",
    "--date=iso"
]).decode()

for line in output.splitlines():
    commit_hash, author, date, message = line.split("|", 3)

Time-based and path-based history analysis

git log becomes significantly more powerful when you treat history like a queryable dataset:

git log --since="2025-01-01" --until="2025-12-31"

You can also use relative times:

git log --since="2 weeks ago"

Or narrow it down to a single file to inspect how that file evolved:

git log --since="2 weeks ago" -- path/to/file

A useful flag here may be also the --follow flag which tracks renames. If your boundaries are not dates, but certain hashes, you can use them as well:

git log hashA..hashB

What can be of course combined with other flags:

git log hashA..hashB --oneline -- path/to/file

Exporting logs to specific file formats

A less obvious, but powerful use case is treating git log as an export mechanism capable of handling multiple file formats. For example, you can format the git log output as if was a JSON file element and then with jq you can combine it into a valid JSON file:

git log --pretty=format:'{"hash":"%H","author":"%an","date":"%ad","msg":"%s"}' -20 | jq -s '.' > history.json

I used jq -s here to read multiple JSON objects and wrap them into a list, so I end up with a list of dictionaries where each dictionary represents a single commit properties.

AI is powerful. Snippets are instant.

Stop prompting for the same patterns repeatedly. Get almost 100 free VS Code snippets for C++, Python, CMake and Bazel from piko::snippets GitHub repository.

Visualizing history as a graph

git log --graph --oneline --decorate --all

This shows:

branching structure (--graph)
compact commits (--oneline)
branch/tag labels (--decorate)
all references (--all)

Extracting commit statistics for analytics

Another advanced pattern is using git log to compute repository-level insights. For example, if you need to map the author to the number of commits, call:

git log --pretty=format:"%an" | sort | uniq -c | sort -nr

The output can always be limited by providing the amount of past commits that are supposed to be analyzed:

git log --pretty=format:"%an" -20 | sort | uniq -c | sort -nr

Final combo

Let's now construct a final combo command which:

extracts assymetricaly changes between hashA and hashB
filters out changes older than 2 weeks
keeps easily-parsable date formats
formats commit properties into a JSON objects
builds a valid JSON list of dictionaries
saves it into a JSON file

git log hashA..hashB --since="2 weeks ago" --date=iso --pretty=format:'{"hash":"%H","author":"%an","date":"%ad","msg":"%s"}' | jq -s '.' > history.json

Surprisingly necessary explanation of Python venv

piko::tutorial — Mon, 27 Jul 2026 05:00:00 +0000

There is a strange phenomenon in the Python world. People train neural networks, automate infrastructure, write complex tools and maintain applications for years while still having very little understanding of Python virtual environments.

I'm not entirely sure why this happens. Maybe it's because Python has such a low barrier to entry that beginners skip this topic just to get their first script running and then never come back to it as they progress further, focusing on Python syntax and programming skills instead.

At later stages of learning, this leads people to ask questions like:

"How do I back up all dependencies of my Python project?"
"How do I run pip install on a machine without internet access?"
"How do I know which dependencies my application actually uses?"

All of these problems can be solved using basic virtual environment features, but many developers never develop that intuition.

What venv is NOT

A Python virtual environment is not:

a container - because it will not isolate your python process from the rest of the system
a virtual machine - because it will not emulate computer components
a true sandbox - because it will still be able to access the filesystem, network requests etc. (although some people can argue that Python-level isolation is enough to call it a sandbox for the Python software development use case)

A venv is simply a directory where your project-specific interpreter's configuration and project-specific dependencies live. Such an approach gives Python developers many useful features.

Dependency isolation (the one everybody usually knows)

Let’s start with the obvious one. Different projects require different dependencies. Sometimes the same dependencies, but in different versions. Installing everything globally in the system quickly creates chaos because some projects may start working after the dependency update and the others stop working due to the same reason.

Virtual environments solve this by giving each project its own package space:

project_a/.venv
project_b/.venv

Each environment contains independent:

installed packages
dependency versions
console scripts
package metadata

This shifts the problem from "works on my machine" to "works with this venv" which limits debugging only to the content of the used virtual environment.

No need to explicitly activate/deactivate the environment

When you run:

source .venv/bin/activate

the script mainly modifies your shell’s PATH variable so that .venv/bin appears before system directories. As a result, commands like python now resolve to executables inside the virtual environment.

Such activation is optional and when creating automations or running scripts remotely, it is actually a good idea to explicitly run the interpreter directly:

./.venv/bin/python script.py

or:

./.venv/bin/python -m pip install requests

AI is powerful. Snippets are instant.

Stop prompting for the same patterns repeatedly. Get almost 100 free VS Code snippets for C++, Python, CMake and Bazel from piko::snippets GitHub repository.

Build env on one machine and run on another

This is where things start becoming genuinely interesting. You may have already encountered the following setup:

Machine A:

you have full permissions
you can install packages with pip
has internet access

Machine B:

locked-down server
restricted permissions
no internet access

Many people assume this means that their Python tooling cannot be used on Machine B because how would they ensure proper dependencies. The answer is that you can build your dependencies as .whl packages, transfer them via internal network and install them offline on the server side. Let's say you need empy for your application to work. On machine A create the virtual environment:

python3 -m venv machine_a

And then install empty with pip:

./machine_a/bin/python -m pip install empy

After it's done, display the installed packages to make sure it's there:

./machine_a/bin/python -m pip freeze
empy==4.2.1

Now, build a wheel package:

/machine_a/bin/python -m pip wheel empy==4.2.1 -w deps

This creates a deps folder with a empy-4.2.1-py3-none-any.whl file inside. Transfer that folder to the machine B and then create there a new virtual environment:

python3 -m venv machine_b

You can now install the dependency fully offline out of the transferred .whl file:

./machine_b/bin/python -m pip install deps/empy-4.2.1-py3-none-any.whl

App delivery as a packaged virtual environment

Let's restrict the environment of the machine B from the previous paragraph even more and let's say that you can't even install dependencies with pip out of .whl packages. What can you do? You can transfer entire virtual environment folder from machine A to the machine B and run your script there.

The venv package will provide everything that your scripts need (of course, as long as both machines are sufficiently compatible - they share OS family, architecture etc.).

A dependency backup

Virtual environment folder captures your dependencies and their versions, so whenever you need to know what dependencies you actually use and in what versions, you can simply run:

./venv/bin/python -m pip freeze

If you save the output to the file (usually called requirements.txt) you can always re-create your venv by invoking:

./venv/bin/python -m pip install -r requirements.txt

It means that you can just copy your current venv folder, tweak versions of some dependencies, check if your app still works and if yes - start using these new versions. If no, you simply delete the new venv folder and use the old one.

When AI gets C++ bitmask enums almost right

piko::tutorial — Mon, 20 Jul 2026 05:00:00 +0000

Today I want to take a look at a piece of C++ code that Copilot generated for me recently. The code here will not be 1:1 the same because originally it was inserted as a part of the bigger code base - I changed the names and simplified it to focus on the key topic, but the overall idea is exactly the same.

At first glance, the generated code looked perfectly reasonable. In fact, it even compiled. The problem is that it also contained a subtle semantic trap that is very easy to miss if you don't stop and think carefully about what the code is actually meant to do.

The code started with an enum representing permissions where the values are bitmasks:

enum class Permission
{
    kNone = 0,
    kRead = 1 << 0,
    kWrite = 1 << 1,
    kExecute = 1 << 2
};

And then Copilot generated an associated stream operator to print the enum value using std::cout:

std::ostream& operator<<(std::ostream& os, const Permission p)
{
    switch (p) {
        case Permission::kNone:
            return os << "None";
        case Permission::kRead:
            return os << "Read";
        case Permission::kWrite:
            return os << "Write";
        case Permission::kExecute:
            return os << "Execute";
        default:
            return os << "UNKNOWN PERMISSION";
    }
}

So far, everything still looks fine. The next step overloads the bit or operator for the Permission enum:

Permission operator|(const Permission lhs, const Permission rhs)
{
    return static_cast<Permission>(static_cast<int>(lhs) | static_cast<int>(rhs));
}

Nothing immediately suspicious here either, but the things start to look interesting because Copilot generated also a function that, according to some complex logic, returns combinations of permissions in form of:

Permission GetPermissions()
{
    return Permission::A | Permission::B;
}

This is where things start getting tricky. The code is not obviously wrong because representing flags as bitmasks is a completely valid technique, but let's test this with a simple example:

Permission GetPermissions()
{
    return Permission::kNone | Permission::kWrite;
}

int main()
{
    const Permission p = GetPermissions();
    std::cout << "Current permissions: " << p;
}

This works perfectly fine because:

00000000 | 00000010 = 00000010

And 00000010 corresponds exactly to Permission::kWrite, so the output becomes:

Current permissions: Write

However, when the function reaches a path like this:

Permission GetPermissions()
{
    return Permission::kRead | Permission::kWrite;
}

the output suddenly changes to:

Current permissions: UNKNOWN PERMISSION

How is this possible that although all enum values of the Permission enum are covered in switch/case statement, after getting the object p of type Permission and printing it, no valid value of the enum is displayed?

The answer is: the value returned from GetPermissions() is simply not represented by any enum field. Take a look:

Permission::kRead  = 00000001
Permission::kWrite = 00000010

Their bitwise or produces:

00000011

But there is no enum field equal to 00000011 and C++ does not forbid such value from existing inside an enum object.

The key problem

This reveals a deeper conceptual conflict:

enums are designed to represent one value from a closed set
bitmasks are designed to represent combinations of values

These are fundamentally different concepts and without writing a logic which actually enforces the rules of how these 2 contradicting worlds co-exist, we end up with a subtle bug hidden behind a clean API. Of course, the solution is not to keep extending the enum with values like:

kReadWrite
kWriteExecute
kReadExecute

because this does not scale. With more flags, the number of combinations grows exponentially. Let's look at how to fix the issue properly.

AI is powerful. Snippets are instant.

Stop prompting for the same patterns repeatedly. Get almost 100 free VS Code snippets for C++, Python, CMake and Bazel from piko::snippets GitHub repository.

Don't lie with the function signature

Using enums to represent individual bitmask values is perfectly fine. It improves the usage and the readability because you no longer need to remember whether "read" permission is equal to 1, 2, or 16. But the moment you start combining those values, the result is no longer guaranteed to be a valid Permission enum value, so the API should reflect that reality.

The first step is changing the overloaded | operator - instead of pretending that the result is still a Permission, return an integer mask explicitly:

int operator|(const Permission lhs, const Permission rhs)
{
    return static_cast<int>(lhs) | static_cast<int>(rhs);
}

Now the operator no longer falsely suggests that combining two permissions produces another valid enum field. Similarly, any function returning combined permissions should return an integer mask instead of Permission:

int GetPermissions()
{
    return Permission::kRead | Permission::kWrite;
}

int main()
{
    const int p = GetPermissions();
    std::cout << "Current permissions: " << p;
}

This now produces:

Current permissions: 3

The value is no longer pretending to be a single enum value. It is simply a bitmask containing multiple flags what is clearily communicated by the API now. If you want, you can print it in a nicer form by using a helper function - here is an example of a simple one:

void PrintPermissions(const int p)
{
    if (p & static_cast<int>(Permission::kRead)) {
        std::cout << "Read";
    }

    if (p & static_cast<int>(Permission::kWrite)) {
        std::cout << "Write";
    }

    if (p & static_cast<int>(Permission::kExecute)) {
        std::cout << "Execute";
    }

    std::cout << std::endl;
}

Now the output becomes:

Current permissions: ReadWrite

10 VS Code snippets essential for every C++ engineer

piko::tutorial — Mon, 13 Jul 2026 05:00:00 +0000

Why use snippets in the era of AI agents?

AI can generate code faster than ever. A single prompt can produce entire classes, build files or test suites in minutes, so it’s fair to ask: why would any engineer still care about VS Code snippets? Because generating code is not the same thing as maintaining flow.

Assuming that you're not a vibe coder, you know that many repetitive engineering tasks are not difficult enough to justify opening an AI chat, writing a prompt, waiting for output, reviewing the result and adjusting it to match your project conventions. Ironically, for small but frequent tasks, AI often introduces the exact thing engineers try to avoid most: context switching.

And context switching is expensive.

Every time you stop coding to ask an AI assistant how to write a constructor, scaffold a test, remember a target_link_libraries signature or recreate a logging macro, you temporarily break concentration. Individually, these interruptions feel insignificant, but across an entire day, they quietly fragment momentum and slow down deep technical work.

Snippets solve a different problem than AI. AI is excellent for exploration:

learning unfamiliar concepts
making PoCs
generating drafts
explaining APIs

Snippets excel at execution:

known patterns
repeated workflows
reliability
muscle-memory

A good snippet system removes friction without requiring a conversation. No prompting and no waiting for the code that may or may not match your expectations. You type a few characters, press Tab and continue thinking. That immediacy matters more than ever.

This article covers 10 VS Code snippets that I consider essential for every C++ developer. You can download all of them for free from my GitHub repository.

Including path copied to the clipboard

Snippet is called incb (abbreviation for: INclude Clip*B*oard) and lets you insert the include directive with whatever you have currently copied to the clipboard. If you work in Bazel environment and all your include paths are relative to the project root, then you can just click RMB on a file, choose "Copy relative path" and type incb.

Declaring new interface class

Snippet is called dif2 (abbreviation for: Declare Inter*Face with **2* method) and lets you declare a new interface class with the number of pure virtual methods specified by the trailing number (in this case 2).

If/else

Snippet is called cife (abbreviation for: C++ IF Else) and lets you insert one of the most frequently typed blocks of code.

Switch-case statements

Snippet is called cswi2 (abbreviation for: C++ SWItch with 2 cases) and lets you insert a ready-to-use skeleton of switch-case statement with the number of cases specified by the trailing number (in this case 2).

Index-based for loops

Snippet is called cfori (abbreviation for: C++ FOR Indexed) and provides a full skeleton of a for loop and the most common default values.

Range-based for loops

Snippet is called cfore (abbreviation for: C++ FOR Element) and lets you insert almost entire range-based for loop in its most common form.

Unique pointer as a class member

Snippet is called suptrm (abbreviation for: Std Unique Poin*TeR* class Member) and utilizes the fact that many C++ projects require naming convention that adds an underscore at the end of every private class member.

Move variable copied to clipboard

Snippet is called somocb (abbreviation for: Std Operation MOve from Clip*B*oard). I often find myself in the situation in which I have a variable which I suddenly realize that needs to be moved. There are basically 2 options in such situation:

Write std::move( in front of the variable, jump to the end of the variable's name and add )
Select the variable, press Ctrl + X, write std::move() and press Ctrl + V to insert the variable between the parenthesis.

This snippet lets you make it even faster by pressing Ctrl + X and writing somocb which will insert std::move together with the name of the copied variable.

Initialize class member on the constructor's list

Snippet is called defi (abbreviation for: DEFine Initialization of class member) and lets you initialize the class member with a constructor input arguement of the same name (except the underscore in the class member name).

Check if container is empty

Snippet is called scem (abbreviation for: Standard Container EMpty) and provides you with an .empty() call on the standard container.

Storing your ATTiny program in...EEPROM?

piko::tutorial — Mon, 06 Jul 2026 05:00:00 +0000

In this proof of concept, we will build a tiny interpreter for the ATtiny85 which executes instructions directly from EEPROM memory instead of FLASH. The goal is not to replace native firmware execution, but to experiment with compact instruction encoding and runtime programmability. Each instruction in this interpreter consists of only 2 bytes: one byte for the command ID and one byte for command arguments packed bit-by-bit.

Scope of this PoC

For this PoC, the interpreter supports three commands.

Set GPIO (0x01) - sets a digital output pin to high or low. The first 3 bits of the arguments byte specify the pin number and the remaining 5 bits define the state.
Delay (0x02) - a non-blocking delay instruction that pauses EEPROM program execution without freezing the MCU itself. The arguments byte contains the delay duration in units of 100 milliseconds.
Map ADC to PWM (0x03) - reads an ADC channel and maps its value proportionally to a PWM output. The arguments byte contains:
- first 3 bits - ADC source pin
- next 3 bits - PWM output pin
- next 1 bit - direct or reversed mapping
- last 1 bit - may be used for smoothing/averaging support in the future (now I skip it)
End of program (0xFF) - marks the end of the EEPROM program and allows the interpreter to loop forever over the program.

The resulting EEPROM “program” looks similar to a compact instruction stream rather than traditional firmware, but because every operation occupies exactly and only two bytes, programs become very dense and easy to parse.

Required dependencies

Before starting, install the AVR toolchain and required utilities:

sudo apt install \
    gcc-avr \
    avr-libc \
    binutils-avr \
    avrdude \
    cmake

The interpreter also requires several AVR-specific headers, definitions, state variables and helper structures:

#include <avr/eeprom.h>
#include <avr/interrupt.h>
#include <stdbool.h>

#define PIN_PB0 0
#define PIN_PB1 1
#define PIN_PB2 2
#define PIN_PB3 3
#define PIN_PB4 4

#define STATE_LOW 0
#define STATE_HIGH 1

#define DIRECT_MAPPING 0
#define REVERSED_MAPPING 1

#define CMD_SET_GPIO 0x01
#define CMD_DELAY 0x02
#define CMD_MAP_ADC_TO_PWM 0x03

#define PROGRAM_END_BYTE 0xFF

uint32_t last_timestamp = 0;
uint32_t delay_end_time = 0;
uint8_t instruction_pointer = 0;
bool delay_active = false;

bool pwm_1_enabled = false;
bool pwm_2_enabled = false;

static const uint8_t kPinToPortbMapping[] = {PB0, PB1, PB2, PB3, PB4};
static const uint8_t kPinToAdcChannelMapping[] = {0xFF, 0xFF, 1U, 3U, 2U};

typedef struct
{
    uint8_t command_id;
    uint8_t arguments;
} Instruction;

A few things are worth mentioning here:

Instruction represents a single EEPROM bytecode instruction.
instruction_pointer acts similarly to a program counter in a CPU.
last_timestamp provides a millisecond-style timing source.
delay_active and delay_end_time will be used for implementing non-blocking delays.
the pin mapping tables translate logical pins into AVR hardware-specific identifiers.

Writing EEPROM programs

Let's take a look at 2 example programs.

Example 1 - classic blink

Instruction EEMEM eeprom_program[] =
{
    {CMD_SET_GPIO, (PIN_PB0 << 5) | STATE_LOW},
    {CMD_DELAY, 10},
    {CMD_SET_GPIO, (PIN_PB0 << 5) | STATE_HIGH},
    {CMD_DELAY, 10},
    {PROGRAM_END_BYTE, PROGRAM_END_BYTE}
};

Example 2 - map 2 ADCs to 2 PWMs

Instruction EEMEM eeprom_program[] =
{
    {CMD_MAP_ADC_TO_PWM, (PIN_PB4 << 5) | (PIN_PB0 << 2) | (DIRECT_MAPPING << 1)},
    {CMD_MAP_ADC_TO_PWM, (PIN_PB3 << 5) | (PIN_PB1 << 2) | (REVERSED_MAPPING << 1)},
    {PROGRAM_END_BYTE, PROGRAM_END_BYTE}
};

How does it work?

The key part is that eeprom_program is not a normal RAM array. It is an EEPROM-resident variable because of the EEMEM attribute:

Instruction EEMEM eeprom_program[] =
{
    ...
};

EEMEM tells the AVR compiler and linker “Place this variable inside EEPROM memory instead of RAM or FLASH.”, so even though it looks like a normal array in C, it actually represents an EEPROM address.

Microcontroller setup

The interpreter requires timer interrupts, ADC initialization, GPIO helpers and PWM support. The following code sets up all required peripherals:

ISR(TIMER0_COMPA_vect)
{
    last_timestamp++;
}

void InitTimer0()
{
    TCCR0A = (1 << WGM01);
    OCR0A = 124;
    TCCR0B = (1 << CS01) | (1 << CS00);
    TIMSK |= (1 << OCIE0A);
}

void InitAdc(void)
{
    ADMUX = 0;
    ADCSRA = (1 << ADEN) | (1 << ADPS2) | (1 << ADPS1);
}

void InitPwm(uint8_t pin)
{
    DDRB |= (1 << pin);
    TCCR0A = (1 << WGM00) | (1 << WGM01);
    TCCR0B = (1 << CS00);

    if(pin == PIN_PB0 && !pwm_1_enabled) {
        TCCR0A |= (1 << COM0A1);
    }
    else if(pin == PIN_PB1 && !pwm_2_enabled) {
        TCCR0A |= (1 << COM0B1);
    }
}

void GpioWrite(uint8_t pin, uint8_t state)
{
    uint8_t hw = kPinToPortbMapping[pin];

    DDRB |= (1 << hw);

    if(state)
        PORTB |= (1 << hw);
    else
        PORTB &= ~(1 << hw);
}

uint8_t GpioRead(uint8_t pin)
{
    uint8_t hw = kPinToPortbMapping[pin];

    DDRB &= ~(1 << hw);

    return (PINB & (1 << hw)) ? 1 : 0;
}

uint16_t AdcRead(uint8_t pin)
{
    uint8_t adc_channel = kPinToAdcChannelMapping[pin];

    if(adc_channel == 0xFF) {
        return 0;
    }

    ADMUX = (ADMUX & 0xF0) | adc_channel;
    ADCSRA |= (1 << ADSC);

    while(ADCSRA & (1 << ADSC));

    return ADC;
}

void PwmWrite(uint8_t pin, uint8_t value)
{
    switch(pin) {
        case PIN_PB0:
            OCR0A = value;
            break;
        case PIN_PB1:
            OCR0B = value;
            break;
        default:
            break;
    }
}

Timer interrupt

The timer compare interrupt ISR(TIMER0_COMPA_vect) increments a global timestamp counter periodically. This provides a lightweight software clock used for delays.

Timer initialization

void InitTimer0() configures Timer0 into CTC mode and generates periodic compare-match interrupts. The prescaler and compare register values determine the interrupt frequency.

ADC initialization

void InitAdc(void) enables the ADC peripheral and configures the ADC clock prescaler.

PWM initialization

void InitPwm(uint8_t pin) configures Timer0 for fast PWM generation and enables the selected PWM output channel.

GPIO helpers

GpioWrite() configures a pin as output and writes HIGH or LOW. GpioRead() configures a pin as input and returns its digital state.

ADC reads

AdcRead() translates logical pins into ADC channels, starts a conversion and waits until conversion completes.

PWM output

PwmWrite() updates the PWM duty cycle register corresponding to the selected PWM output pin.

AI is powerful. Snippets are instant.

Stop prompting for the same patterns repeatedly. Get almost 100 free VS Code snippets for C++, Python, CMake and Bazel from piko::snippets GitHub repository.

Executing instructions from EEPROM

The core of the interpreter is the instruction execution routine:

void ExecuteInstruction(Instruction *instruction)
{
    if(instruction->command_id == 0xFF && instruction->arguments == 0xFF) {
        instruction_pointer = 0;
        return;
    }

    switch(instruction->command_id) {
        case CMD_SET_GPIO: {
            uint8_t pin = (instruction->arguments >> 5) & 0x07;
            uint8_t state = (instruction->arguments & 0x1F) ? 1 : 0;

            GpioWrite(pin, state);

            instruction_pointer++;
            break;
        }
        case CMD_DELAY: {
            uint32_t delay_ms = ((uint32_t)instruction->arguments) * 100UL;

            delay_active = true;
            delay_end_time = last_timestamp + delay_ms;

            instruction_pointer++;
            break;
        }
        case CMD_MAP_ADC_TO_PWM: {
            uint8_t adc_pin = (instruction->arguments >> 5) & 0x07;
            uint8_t pwm_pin = (instruction->arguments >> 2) & 0x07;
            bool reversed_mapping = (bool)((instruction->arguments >> 1) & 0x01);

            InitPwm(pwm_pin);

            uint16_t adc_value = AdcRead(adc_pin);
            uint8_t pwm_value = adc_value >> 2;

            if (reversed_mapping) {
                pwm_value = 255 - pwm_value;
            }

            PwmWrite(pwm_pin, pwm_value);

            instruction_pointer++;
            break;
        }

        default: {
            instruction_pointer++;
            break;
        }
    }
}

The first thing the interpreter checks is whether the instruction equals 0xFF 0xFF which acts as an end-of-program marker. When encountered, execution jumps back to the beginning by resetting the instruction pointer.

The GPIO instruction extracts:

the pin number from the upper 3 bits
the output state from the lower 5 bits

The delay instruction converts the argument byte into milliseconds by multiplying it by 100. The ADC-to-PWM instruction:

extracts ADC and PWM pins,
initializes PWM if not yet initialized,
reads ADC value,
converts the 10-bit ADC result into an 8-bit PWM value,
optionally reverses the mapping,
writes the final duty cycle.

Each executed instruction increments the instruction pointer so the next EEPROM instruction can be fetched.

Main execution loop

The main firmware loop is extremely small because most logic lives inside the ExecuteInstruction function:

int main()
{
    InitTimer0();
    InitAdc();

    sei();

    while(1) {
        if(delay_active) {
            delay_active = (last_timestamp < delay_end_time);
            continue;
        }

        Instruction instruction;

        eeprom_read_block(&instruction,
                          &eeprom_program[instruction_pointer],
                          sizeof(Instruction));

        ExecuteInstruction(&instruction);
    }
}

Peripheral initialization

InitTimer0();
InitAdc();

initializes the timer subsystem and ADC peripheral before execution begins.

Global interrupts

sei();

enables interrupts globally so Timer0 interrupts can start updating timestamps.

Delay handling

The interpreter checks whether a delay is currently active:

if(delay_active) {
    delay_active = (last_timestamp < delay_end_time);
    continue;
}

If the delay has not expired yet, the loop simply waits without advancing instruction execution.

EEPROM instruction fetch

eeprom_read_block(&instruction,
                  &eeprom_program[instruction_pointer],
                  sizeof(Instruction));

copies the next instruction from EEPROM into RAM:

&instruction - destination in RAM
&eeprom_program[instruction_pointer] - source address inside EEPROM
sizeof(Instruction) - number of bytes to copy

Instruction execution

Finally:

ExecuteInstruction(&instruction);

decodes and executes the fetched bytecode instruction.

Building and flashing with CMake

The project can be built entirely using CMake. The following CMakeLists.txt file configures compilation, HEX generation and flashing:

cmake_minimum_required(VERSION 3.15)

project(attiny85_eeprom_interpreter C)

set(MCU attiny85)
set(F_CPU 8000000UL)

set(CMAKE_C_COMPILER avr-gcc)
set(CMAKE_OBJCOPY avr-objcopy)
set(CMAKE_SIZE avr-size)
set(COMMON_FLAGS
    -mmcu=${MCU}
    -DF_CPU=${F_CPU}
    -Os
    -flto
    -fdata-sections
    -ffunction-sections
    -fno-tree-scev-cprop
    -fno-split-wide-types
    -mcall-prologues
    -Wall
)

add_executable(${PROJECT_NAME}.elf
    main.c
)

target_compile_options(${PROJECT_NAME}.elf PRIVATE
    ${COMMON_FLAGS}
)

target_link_options(${PROJECT_NAME}.elf PRIVATE
    -mmcu=${MCU}
    -Wl,--gc-sections
    -Wl,--relax
    -flto
)

add_custom_command(
    TARGET ${PROJECT_NAME}.elf POST_BUILD
    COMMAND ${CMAKE_OBJCOPY}
            -O ihex
            -R .eeprom
            ${PROJECT_NAME}.elf
            ${PROJECT_NAME}.hex

    COMMAND ${CMAKE_SIZE}
            --mcu=${MCU}
            --format=avr
            ${PROJECT_NAME}.elf
)

add_custom_target(flash
    COMMAND avrdude
        -c usbasp
        -p t85
        -U flash:w:${PROJECT_NAME}.hex:i
    DEPENDS ${PROJECT_NAME}.elf
)

add_custom_command(
    TARGET ${PROJECT_NAME}.elf POST_BUILD
    COMMAND ${CMAKE_OBJCOPY}
            -O ihex
            -j .eeprom
            --change-section-lma .eeprom=0
            ${PROJECT_NAME}.elf
            ${PROJECT_NAME}.eep
)

add_custom_target(flash_eeprom
    COMMAND avrdude
        -c usbasp
        -p t85
        -U eeprom:w:${PROJECT_NAME}.eep:i
    DEPENDS ${PROJECT_NAME}.elf
)

add_custom_target(fuses
    COMMAND avrdude
        -c usbasp
        -p t85
        -U lfuse:w:0xE2:m
)

Notice that the flash targets are created without ALL. This is intentional because we do not want the microcontroller to be reflashed every time we simply build the project.

Read also on Medium: How to write Arduino Uno code with Python?.

Set fuses

cmake --build . --target fuses

In this project we set the low fuse to 0xE2 because we want the ATtiny85 to run from its internal 8 MHz oscillator without the default clock divider enabled. By default, many AVR chips ship with the CKDIV8 fuse enabled, which divides the system clock by 8. Even though the internal oscillator runs at 8 MHz, the CPU would actually execute at 1MHz.

That would make all timing calculations incorrect and the behavior would appear 8 times slower. The 0xE2 fuse configuration disables this divider, so the MCU truly runs at the full 8 MHz specified by:

#define F_CPU 8000000UL

Build firmware

cmake --build .

Flash firmware

cmake --build . --target flash

Flashing EEPROM program

Now, after the FW is flashed, you can call:

cmake --build . --target flash_eeprom

while the MCU is running to replace the previous EEPROM program with the new one.

Why this approach is interesting

Although this interpreter is only a proof of concept, it demonstrates several interesting ideas.

The biggest advantage is instruction density. Every operation occupies exactly 2 bytes in EEPROM, which can sometimes be significantly smaller than equivalent compiled C code stored in FLASH memory. Instead of storing large AVR machine instructions, the MCU executes a compact custom bytecode format specifically optimized for the target application.

Other advantages:

runtime-replaceable logic without reflashing firmware,
deterministic instruction size,
extremely small interpreter core,
easy serialization and external generation of programs

This kind of architecture starts resembling a tiny virtual machine for AVR microcontrollers. While it will never match native compiled performance, it can be surprisingly efficient for automation, GPIO sequencing, LED control or sensor mapping tasks where compactness matters more than raw speed.

Bug of the week #12

piko::tutorial — Mon, 29 Jun 2026 05:00:00 +0000

The error we're handling today is a real-life example simplified to the following Python code:

# user inputs several numbers in form of strings (1, 2, 3 and 123)
# which are then used to construct 2 strings
s1 = "".join(["1", "2", "3"])
s2 = "123"

# if the numbers in the constructed strings are different,
# the program flow should stop
if s1 is not s2:
    raise RuntimeError("s1 is not s2!")

# program flow continues...

The variables s1 and s2 both end up being 123, but when we run this code, we see:

Traceback (most recent call last):
  File "/home/main.py", line 9, in <module>
    raise RuntimeError("s1 is not s2!")
RuntimeError: s1 is not s2!

What's even worse, in the other parts of the app, where s1 and s2 are constructed differently, there are the same comparisons:

s1 = "123"
s2 = "123"

if s1 is not s2:
    raise RuntimeError("s1 is not s2!")

# program flow continues...

But this time the exception is not thrown, so the same comparison seems to give different results for the same s1 and s2 strings.

What does it mean?

The issue comes from misunderstanding the difference between identity and equality in Python. The is operator does not check whether two variables contain the same value. It checks whether both variables point to the exact same object in memory.

== asks: “Do these objects have the same content?”
is asks: “Are these literally the same object?”

For example:

s1 = "123"
s2 = "123"

print(s1 == s2)   # True
print(s1 is s2)   # maybe True, maybe False

The first comparison checks the values of the strings, so it reliably returns True. The second comparison depends on Python’s internal memory optimizations. Sometimes Python “interns” strings, meaning it reuses the same object for performance reasons. In those cases, s1 is s2 may accidentally return True, but not always.

In this version:

s1 = "".join(["1", "2", "3"])
s2 = "123"

print(s1 == s2)   # True
print(s1 is s2)   # False

Both strings contain exactly the same text, but they were created differently, so Python stores them as separate objects. This makes is unreliable for value comparison.

How to fix it?

Use == whenever you want to compare values. Correct version:

s1 = "".join(["1", "2", "3"])
s2 = "123"

if s1 != s2:
    raise RuntimeError("s1 is not s2!")

Reserve is for cases where you truly want to check object identity. The most common use is comparing with None:

if value is None:
    print("No value provided")

Sharing variable between bash scripts

piko::tutorial — Mon, 22 Jun 2026 05:00:00 +0000

Sharing Variables

The simplest way to share variables between Bash scripts is to place them in a separate common script and source that script wherever the variables are needed.

# common.sh

#!/bin/bash

export SOME_VAR="Hello"

Then, in another script:

# user.sh

#!/bin/bash

source common.sh

echo "SOME_VAR = $SOME_VAR"

Using source executes the contents of common.sh in the current shell, making the exported variables available to the script.

Sharing Arrays

Arrays can be shared in the same way. Define the array in common.sh and source it from another script.

# common.sh

#!/bin/bash

declare -a SOME_ARRAY=("element1" "element2" "element3")

Then use it in another script:

#!/bin/bash

source common.sh

for element in "${SOME_ARRAY[@]}"
do
    echo "$element"
done

Reading Arrays from a File

In many cases, storing the data in a text file is more convenient than hardcoding it inside a script. You can read a single-line list into an array using read:

#!/bin/bash

read -a SOME_ARRAY < data.txt

for element in "${SOME_ARRAY[@]}"
do
    echo "$element"
done

This approach forces you however to store all elements in a single line like:

element1 element2 element3

For longer lists, where each element is stored on a separate line:

element1
element2
element3
...

it is better to use mapfile:

#!/bin/bash

mapfile -t SOME_ARRAY < data.txt

for element in "${SOME_ARRAY[@]}"
do
    echo "$element"
done

The -t option removes trailing newline characters, making the array elements cleaner to work with.

A 40-line LLM-based bash command executor in Python

piko::tutorial — Mon, 15 Jun 2026 05:00:00 +0000

One of the interesting use cases for local LLMs are the natural language interfaces for the terminal commands generation. Instead of memorizing command syntax, flags and shell quirks, you can simply describe what you want to do like:

Find all PNG files larger than 5 MB and move them to archive

An LLM not only translates that request into a real shell command, but also executes it.

In this article, I will build a minimal implementation of such a tool in Python - a lightweight command-line assistant called piko::ai. The entire Python code fits in less than 40 lines of code, yet it provides:

natural language to bash conversion
configurable LLM backends
structured JSON responses
dangerous command detection
and automatic command execution

The implementation uses a local LLM through Ollama, but the architecture is flexible enough to support almost any provider.

Why build a tool like this?

Shell commands are incredibly powerful, but for complex or chained/piped cases they are also difficult to remember and prone to human error. Even experienced developers regularly search for things like rarely used command switches.

Large language models are surprisingly good at translating intent into shell syntax, so the goal of this tool is to instead of thinking in commands, allow the user to think in actions. For example:

find all jpg files modified in the last 7 days and compress them into images.tar.gz

should generate:

find . -type f -name "*.jpg" -mtime -7 | tar -czf images.tar.gz -T -

For simple commands there is no justification for writing long sentences, but as soon as you start searching the internet or asking AI:

is it -mtime or -dtime?
was it -czf or -xvf for the archive creation?
should there be -T or --files-from or both are fine?

it may be acutally quicker to just type the request directly in the terminal and get the output for that request also directly in the terminal.

The architecture

The entire flow is extremely simple:

User types a natural language request.
Python inserts that request into a prompt template.
The prompt is sent to an LLM.
The LLM returns JSON containing a shell command.
Python checks whether the command is potentially dangerous.
If approved, the command is executed.

If you have never written stuff like that, you will be surprised how little code is actually required.

The Python implementation

For the TL;DR-readers, below is the complete implementation - if you want to test it out, you can clone the piko_ai GitHub repository. I go into details on what exactly does this code do in the paragraphs below:

import os
import sys
import requests
import json
import subprocess

MAIN_FILE_PATH: str = os.path.join(os.path.dirname(os.path.abspath(__file__)))
PIKO_AI_CONFIG_FILE_PATH: str = os.path.join(MAIN_FILE_PATH, "..", "config", "pai_config.json")
PIKO_AI_PROMPT_FILE_PATH: str = os.path.join(MAIN_FILE_PATH, "..", "config", "pai_prompt.txt")

with open(PIKO_AI_CONFIG_FILE_PATH) as file:
    config = json.load(file)
with open(PIKO_AI_PROMPT_FILE_PATH) as file:
    prompt_template: str = file.read()

user_request: str = " ".join(sys.argv[1:])
prompt: str = prompt_template.replace("@USER_REQUEST@", user_request)

request_payload: dict = config["llm_request"]
request_payload["prompt"] = prompt

response = requests.post(config["llm_provider_url"], json=request_payload, timeout=config["llm_request_timeout"])
response.raise_for_status()

command: str = json.loads(response.json()["response"])["command"]

print(f"$ {command}")

for dangerous_command in config["dangerous_commands"]:
    if dangerous_command in command:
        user_response: str = input(f"WARNING: dangerous command detected ({dangerous_command})! Are you sure you want to run it? (y/n)")

        if user_response == "y":
            break

        sys.exit(0)

subprocess.run(command, shell=True)

Let’s break it down piece by piece.

AI is powerful. Snippets are instant.

Stop prompting for the same patterns repeatedly. Get almost 100 free VS Code snippets for C++, Python, CMake and Bazel from piko::snippets GitHub repository.

Step 0: set up constants

import os          # for joining paths
import sys         # for command line arguments and exit
import requests    # for sending requests to LLM
import json        # for JSON parsing
import subprocess  # for executing generated commands

# path to this file which serves as the reference for further paths
MAIN_FILE_PATH: str = os.path.join(os.path.dirname(os.path.abspath(__file__)))
# path to configuration file
PIKO_AI_CONFIG_FILE_PATH: str = os.path.join(MAIN_FILE_PATH, "..", "config", "pai_config.json")
# path to file with the prompt template
PIKO_AI_PROMPT_FILE_PATH: str = os.path.join(MAIN_FILE_PATH, "..", "config", "pai_prompt.txt")

Step 1: loading configuration and prompt files

with open(PIKO_AI_CONFIG_FILE_PATH) as file:
    config = json.load(file)

with open(PIKO_AI_PROMPT_FILE_PATH) as file:
    prompt_template: str = file.read()

Even in the smallest tools, I always like to separate:

application logic
configuration
prompts

This separation makes the tool flexible enough to support:

Ollama
OpenAI-compatible APIs
local inference servers
cloud providers
completely custom backends

For this example however, I will only use local Ollama model.

Step 2: reading the user request

The CLI request is simply reconstructed from command-line arguments. For more complex command line interfaces argparse could come in handy, but in case of this tool, such one-liner is completely enough to concatenate the entire output into a single string, without forcing user to use "" around the request.

user_request: str = " ".join(sys.argv[1:])

So:

pai find all files larger than 55kB

becomes:

"find all files larger than 55kB"

That text is then injected into the prompt template and assigned to a proper field in the request_payload.

prompt: str = prompt_template.replace("@USER_REQUEST@", user_request)

request_payload: dict = config["llm_request"]
request_payload["prompt"] = prompt

Step 3: prompt engineering

The prompt template looks like this:

You are a shell command generator.
User requests from you a bash command in a human readable language and your job is to convert this request into a bash command that the user can immediately invoke.

Requirements:
- If not stated differently, always assume that the command must be executed in the current working directory (.)
- The command must be syntactically valid
- The command must be fully executable
- Prefer a single grep command over pipelines when possible
- Command must be usable out of the box, so don't provide any mock values, but e.g. when the user says "here", it means "."

User request:
@USER_REQUEST@

This prompt emphasizes several important aspects.

Establishing assumptions

This line:

always assume that the command must be executed in the current working directory

greatly improves usability of small models because users are expected to naturally say things like:

find here all markdown files

instead of:

find all markdown files in /home/user/Documents/applications/private_projects/docs”

Biasing command style

This instruction:

Prefer a single grep command over pipelines when possible

helps shape output quality. Small LLMs often overcomplicate shell commands and at the same time (because of their size), make mistakes in these overcomplicated commands. Prompt constraints can push them toward simpler solutions.

Preventing placeholders

Without instructions like:

don't provide any mock values

models often generate unusable outputs like:

grep -r "keyword" /path/to/directory

instead of:

grep -r "keyword" .

The prompt explicitly forces executable commands and not suggestions.

Read also on pikotutorial.com: How to write Arduino Uno code with Python?

Step 4: sending the request to the LLM

response = requests.post(
    config["llm_provider_url"],
    json=request_payload,
    timeout=config["llm_request_timeout"]
)

The configuration file defines the request payload and the output schema.

{
    "llm_request": {
        "model": "qwen2.5-coder:1.5b",
        "format": {
            "type": "object",
            "properties": {
                "command": {
                    "type": "string"
                }
            },
            "required": ["command"]
        },
        "prompt": "TO BE REPLACED BY THE ACTUAL PROMPT",
        "options": {
            "temperature": 0.1,
            "seed": 42
        },
        "stream": false
    },
    "llm_provider_url": "http://localhost:11434/api/generate",
    "model_name": "qwen2.5-coder:1.5b",
    "llm_request_timeout": 60,
}

Several details here are especially important.

Structured JSON output

This is one of the most important implementation details. Instead of asking the model for plain text, the tool requests structured JSON like the one below:

{
    "command": "grep -r \"TODO\" ."
}

Without structured output, models may generate additional explanations or markdown formatting. Structured generation constrains the model into machine-readable output.

Low temperature and a fixed seed

"temperature": 0.1,
"seed": 42

Command generation is not creative writing, so we want deterministic, predictable and reproducible outputs. Low temperature and a fixed seed reduce hallucinations and let the user learn the tool because with the repeatable input-output relation, even if the tool misbehaves for some requests formulations, but improves for others, it lets the user to consistently improve on the tool usage. With unpredictable and non-reproducible outputs, the user would never be able to tune the inputs for the expected outputs.

Why qwen2.5-coder:1.5B?

Such tool is supposed to be a reasonable alternative for just invoking the command or searching for the command and then invoking it. If processing of a request would take several minutes, any other form (googling, copying, asking AI chat bot etc.) would end up being faster than using this tool. I needed to select something small, so that it can run fast locally. Fortunately, our task is highly specialized, so even small code-focused models are capable of handling it.

Step 5: parsing the model response

command: str = json.loads(response.json()["response"])["command"]

The returned command is the bash command extracted from the generated JSON. Then the tool prints it:

print(f"$ {command}")

Users should always see exactly what will be executed.

Step 6: dangerous command detection

This may be actually the most important part of the implementation. The tool scans the generated command for operations defined as dangerous in the config file:

for dangerous_command in config["dangerous_commands"]:
    if dangerous_command in command:
        user_response: str = input(f"WARNING: dangerous command detected ({dangerous_command})! Are you sure you want to run it? (y/n)")

        if user_response == "y":
            break

        sys.exit(0)

After a dangerous operation is detected, the command execution requires explicit confirmation from the user side. Here, by "dangerous" I mean any command that performs any actual modification of the user data.

Warning: this implementation intentionally favors simplicity over perfect security. The current check is only substring matching, so it may overreact e.g. if you have a folder name containg "rm" letters next to each other.

Step 7: Executing the command

Finally:

subprocess.run(command, shell=True)

executes the generated shell command. This is where the it transforms from AI suggestion into actual tool because the generated command is not only displayed, but actually called.

Example usage

Command:

pai find all files larger than 1kB

Output:

$ find . -type f -size +1k
./main.py

Command:

pai list all .py files with find, but filter out findings from ./venv folder

Output:

$ find . -name '*.py' ! -path './venv/*'
./src/main.py

Command:

pai grep for all usages of MAIN_FILE_PATH

Output:

$ grep -r 'MAIN_FILE_PATH' .
./src/main.py:MAIN_FILE_PATH: str = os.path.join(os.path.dirname(os.path.abspath(__file__)))
./src/main.py:PIKO_AI_CONFIG_FILE_PATH: str = os.path.join(MAIN_FILE_PATH, "..", "config", "pai_config.json")
./src/main.py:PIKO_AI_PROMPT_FILE_PATH: str = os.path.join(MAIN_FILE_PATH, "..", "config", "pai_prompt.txt")
./scripts/install.sh:MAIN_FILE_PATH="$PIKO_AI_DIR/src/main.py"
./scripts/install.sh:ALIAS_LINE="alias pai='$VENV_DIR/bin/python3 $MAIN_FILE_PATH'"

GTest and short-circuit evaluation in C++

piko::tutorial — Mon, 08 Jun 2026 05:00:00 +0000

What is short-circuit evaluation in C++?

Short-circuit evaluation is a behavior of logical operators in C++ where the second part of an expression is evaluated only if it is necessary to determine the final result.

For example, in an expression using the logical OR operator, if the left-hand side already evaluates to true, the right-hand side is never executed because the entire expression must already be true.

if (is_admin || hasPermission())
{
    // ...
}

If is_admin is true, the function hasPermission() will never be called. The same rule applies to the logical AND operator in the opposite direction: if the left-hand side is false, the right-hand side is skipped. Such behavior is often beneficial because it avoids unnecessary work.

How does this matter in practice?

Short-circuit evaluation becomes especially important in unit tests when mocking calls used as parts of if statements. Consider the following code:

class PermissionService
{
public:
    virtual bool HasPermission() = 0;
};

bool CanAccess(bool is_admin, PermissionService& service)
{
    if (is_admin && service.HasPermission())
    {
        return true;
    }

    return false;
}

At first glance, one of the unit tests testing the above code could look like this:

class MockPermissionService : public PermissionService
{
public:
    MOCK_METHOD(bool, HasPermission, (), (override));
};

TEST(CanAccessTest, ReturnsTrueForAdmin)
{
    StrictMock<MockPermissionService> service;

    EXPECT_CALL(service, HasPermission()).WillOnce(Return(true));
    EXPECT_FALSE(CanAccess(false, service));
}

However, when you run this test, you'll see that it failed with the following error:

Actual function call count doesn't match EXPECT_CALL(service, HasPermission())...
         Expected: to be called once
           Actual: never called - unsatisfied and active

How is this possible that HasPermission() was never called if we clearily see it in the tested code? The answer is: short-circuit evaluation.

Since is_admin is false, C++ short-circuit evaluation stops the expression immediately. The call to service.HasPermission() is never executed and as a result the mocked method is never called, so the EXPECT_CALL expectation is not satisfied.

The failure is not caused by incorrect production code. The issue is that the test assumes both sides of the condition are evaluated, while the language guarantees that only the necessary side is executed.

The correct test should reflect the actual execution path:

TEST(CanAccessTest, ReturnsTrueForAdmin)
{
    StrictMock<MockPermissionService> service;

    EXPECT_TRUE(CanAccess(false, service));
}

Or if we specifically want to verify the permission check path, we should make the first condition evaluate to false:

bool CanAccess(bool is_admin, PermissionService& service)
{
    if (service.HasPermission() && is_admin)
    {
        return true;
    }

    return false;
}

AI is powerful. Snippets are instant.

piko::tutorial — Mon, 01 Jun 2026 05:00:00 +0000

It’s been a couple of years since the AI hype really took off and if you’re a professional software engineer like me, you’ve probably already found places where it genuinely improves your workflow. At the same time, you’ve also likely realized that despite all the noise online about AI replacing engineers, that’s not really what’s happening. If you're deep in the IT business, you most likely already know there are still many other reasons why you can lose your job long before AI becomes a replacement for the actual work that you do.

But there’s one more thing I keep noticing more and more and every time I see it, I end up asking myself the same question:

Have we forgotten how to use non-AI tools?

A while ago, I was on a call sharing my VS Code screen when one of my snippet shortcuts expanded into a full block of code instantly. Someone immediately asked:

“Wow, that’s great - what AI is that? Can you share the skill or the prompt?”

That reaction stuck with me because VS Code snippets have been part of my workflow for years, to the point where I don’t even think about them anymore. For me, they’re just “how you code.” But that reaction made me realize how many people now assume that anything efficient must be AI. And it’s not just about VS Code snippets - I increasingly see people reaching for AI for things like:

searching for text in a codebase - when a simple grep or IDE search would be faster
renaming functions - which most IDEs already handle in one click (or via basic find & replace if needed)
looking up command documentation - when man pages or official docs are instantly available

And to be clear - AI is useful, I use Copilot on a daily basis in VS Code, but not every automation or productivity problem needs AI-based solution. What's even more interesting is that when you think about that, you realize that a lot of engineering work sits somewhere between:

manual typing of single word or pasting already copied content
asking AI to generate big chunks of implementation across multiple files

Between these two sit small implementation changes and minor bug fixes for which you already know exactly which 5-10 lines need to be written. You just don’t want to type - them or the prompt to get them. That’s where snippets fit for me.

Because this workflow gap feels real, I published a repository with nearly 100 VS Code snippets for C++, Python, CMake and Bazel that I use regularly myself. They’re logically organized and named to make them easy to learn to help you speed up your own workflow as well: piko::snippets.

Bellow you can find 8 examples of these snippets (2 out of each category).

C++

Creating enums and their stream operators at once

Snippet is called cenco3 (abbreviation for C++ ENum Class Operator and 3 values) and lets you define the enum class and its dedicated output stream operator to use it with std::cout or loggers operating on standard streams.

Including file relative to the project root

Snippet is called inrel (abbreviation for INclude RELative path) and lets you include something from the current directory by providing a path relative to the project root.

Python

Iterating over dictionary items

Snippet is called pford (abbreviation for Python FOR item in Dictionary) and lets you insert for loop loop over dictionary items skeleton.

Creating constructor which checks types

Snippet is called dconc3 (abbreviation for: Define CONstructor with 3 argument and Check type) and lets you insert a class constructor which first checks whether the provided objects match the type from the type annotiations and then creates private members with the same name as the constructor's arguments.

CMake

Add target include directories

Snippet is called cmtid (abbreviation for: CMake Target Include Directories) and lets you insert include directories and choose scope keywords from the predefined list.

Install directory with pattern matching

Snippet is called cmindp (abbreviation for: CMake INstall Directory with Pattern) and lets you define installation step by providing only the important parts of the entire statement.

Bazel

Creating C/C++ binary target

Snippet is called bcbin(abbreviation for: Bazel Cc_BINary) and lets you insert a cc_binary skeleton.

Creating test suite

Snippet is called bts (abbreviation for: Bazel Test Suite) and lets you insert Bazel's test_suite.

Summary

I really encourage you to explore the rest of the free snippets because having a solid and reliable toolkit is what actually gets you closer to being a 10x engineer. You can download them from piko::snippets GitHub repo.

From AUTOSAR to S-Core: the first C++ pub/sub implementation

piko::tutorial — Wed, 14 Jan 2026 22:53:00 +0000

Looking at S-Core today feels a bit like walking into a German factory that has just announced a “major transformation initiative.” Before anything actually starts to change, there are:

discussions about processes
and documents about these discussions
and meetings about these documents
and calls to align on how these documents about those processes should be structured
and how such document structure will impact work in 20 years from now

The intention is good, but as my colleague from work pointed out some time ago: "bureaucracy expands to meet the needs of the expanding bureaucracy". It may sound funny, but this is how European automotive software has been built since years.

For a long time, this approach worked surprisingly well. German - and more broadly European - OEMs optimized for correctness, documentation and process, not for speed or innovation. That slowness was not a bug, it was really a feature and part of the mindset. The market was stable, competition was predictable and even strong players like Japanese or Korean manufacturers did not disrupt that golden setup . Nobody was releasing cars like software updates because nobody really had to. Building slowly, reviewing it thoroughly and certifying it carefully was acceptable when everyone played the same game.

However, when Chinese manufacturers entered the market at full speed, they started producing new models at a pace that European processes simply cannot match. Not because the correctness does no longer matter, but because speed and innovation suddenly do.

This is the tension S-Core seems to be trying to address. Unlike many open-source projects that start out fast and experimental and only later attempt to “add automotive”, S-Core approaches the topic how we like it in Europe.

We don't like when the things break, especially when these things are 2 tons SUVs running 140km/h on a highway and especially in an undocumented way, so it starts strict. Process, structure and ASIL-certifiability are part of the baseline, not something to care about in the future. After all, automotive software engineers know that writing code is only part of the job, the other part is to make that code safe, compliant and legally sellable in a heavily regulated market.

At the same time, S-Core wants to be open source, so that the code evolves in a dynamic way, powered by multiple contributors. If this combination works (and not just combines the disadvantages of both approaches), it could be a revolution for the entire automotive industry.

So let's give it a chance and try to implement a minimal S-Core publisher and subscriber using the latest release v0.5.

S-Core development environment setup

Before writing any code, let's setup the development environment. The prerequisites are:

install Docker: https://docs.docker.com/engine/install/ubuntu/
install Bazel: https://bazel.build/install/ubuntu

S-Core provides its development environment as a container in this GitHub repo. To use it, create .devcontainer/devcontainer.json file in the root of your project with the following content:

{
    "name": "eclipse-s-core",
    "image": "ghcr.io/eclipse-score/devcontainer:v1.1.0"
}

Now, open the project with VS Code and click "Reopen in Container" button on the pop-up window.

Read also on pikotutorial.com: How to write Arduino Uno code with Python?

Minimal S-Core publisher/subscriber implementation

With the environment in place, we can finally write some code. The goal here is intentionally simple: a minimal publisher and subscriber where publisher broadcasts a vehicle position as an event and subscriber reads that data. No optimizations, no abstractions - just the smallest example that shows how the pieces fit together in S-Core and how it is different (or similar) to Adaptive AUTOSAR.

Note: although the namespaces coming from S-Core are long, I don't use any using namespace for shortening them and keep all the S-Core types prefixed with their namespaces explicitly. This is on purpose, to make it clear in the example which S-Core type comes from which namespace.

Communication modelling

Before writing publisher or subscriber code, communication must be modeled. The S-Core's documentation says explicitly that S-Core relies only on the source code and does not utilize any domain specific modelling language for modelling of the communication. So why do I call this section "modelling"?

It's just because LoLa (the implementation of S-Core's IPC communication), although it uses pure C++, it requires a very specific way of interface definition, so if you come from Adaptive AUTOSAR, it will be easier for you to understand the purpose of a bit bizarre C++ code that I will write in the next step.

Let's then define our interface between publisher and subscriber. Create model/position_interface.h:

#ifndef MODEL_POSITION_INTERFACE_H
#define MODEL_POSITION_INTERFACE_H

#include "score/mw/com/types.h"

struct Point
{
  std::uint32_t x;
  std::uint32_t y;
};

template <typename Trait>
class PositionInterface : public Trait::Base
{
  public:
    using Trait::Base::Base;

    typename Trait::template Event<Point> center{*this, "center"};
};

using PositionInterfaceProxy = score::mw::com::AsProxy<PositionInterface>;
using PositionInterfaceSkeleton = score::mw::com::AsSkeleton<PositionInterface>;

#endif // MODEL_POSITION_INTERFACE_H

Let's now break it down:

Point represents the structure of the data being exchanged between the publisher and subscriber - in this case it's just a 2D point representing the coordinates.
PositionInterface represents the interface which connects publisher and subscriber - both of them will have access to its elements.
Event<Point> center defines an element of the interface. S-Core promises supports for events, fields and methods, but at the time of writing this article, methods are not supported yet. In our example, we define center as an Event with an underlying data structure being Point. Single interface may have multiple events.
PositionInterfaceProxy - type of the object via which the subscriber will access the center event to read the data.
PositionInterfaceSkeleton - type of the object via which the publisher will access the center event to write the data.

Publisher implementation

Create src/publisher/main.cpp in your project. First add the necessary S-Core headers:

#include "score/mw/com/impl/instance_specifier.h"
#include "score/mw/com/runtime.h"

And the header to our interface definition:

#include "model/position_interface.h"

Define constant values to use. Don't worry about the kPathToComConfig for now - I will explain it later.

static constexpr const char* kPathToComConfig {"config/communication_config.json"};
static constexpr const char* kInstanceSpecifier {"SomeInstanceSpecifier"};

Now let's implement the main function. First, set the path to the communication configuration defined above:

score::StringLiteral runtime_args[2U] = {"--service_instance_manifest", kPathToComConfig};
score::mw::com::runtime::InitializeRuntime(2, runtime_args);

Next create the service instance specifier, unique for each service:

const score::Result<score::mw::com::InstanceSpecifier> instance_specifier_result = score::mw::com::InstanceSpecifier::Create(std::string{kInstanceSpecifier});

if (!instance_specifier_result.has_value())
{
    std::cerr << "Error: failed to create instance specifier!" << std::endl;
    return 1;
}

const score::mw::com::InstanceSpecifier instance_specifier = instance_specifier_result.value();

Use the created instance_specifier to build the skeleton via which we will send the data from the publisher. Notice that PositionInterfaceSkeleton is the type alias declared in model/position_interface.h:

score::Result<PositionInterfaceSkeleton> skeleton_result = PositionInterfaceSkeleton::Create(instance_specifier);

if (!skeleton_result.has_value())
{
    std::cerr << "Failed to create skeleton for instance specifier "
              << instance_specifier.ToString() << std::endl;
    return 1;
}

auto& position_skeleton = skeleton_result.value();

Service offering must be done explicitly with OfferService():

const auto offer_result = position_skeleton.OfferService();

if (!offer_result.has_value())
{
    std::cerr << "Failed to offer service "
              << instance_specifier.ToString() << std::endl;
    return 1;
}

Now it's time for the actual work - create the data and send it to the world. I add a 1 second delay between each send to make it easier to see what's going on in the terminal later.

for (std::uint32_t i=0U; i<50U; i++)
{
    Point data {
        .x = i,
        .y = i * 2U
    };

    std::cout << "Sending data ("
              << data.x << ", " << data.y << ")" << std::endl;

    position_skeleton.center.Send(data);
    std::this_thread::sleep_for(std::chrono::seconds(1U));
}

After sending the data 50 times, stop offering the service and exit:

position_skeleton.StopOfferService();

return 0;

Subscriber implementation

The subscriber begins similarly to the publisher, so first we add the necessary headers in src/subscriber/main.cpp:

#include "score/mw/com/impl/instance_specifier.h"
#include "score/mw/com/runtime.h"

#include "model/position_interface.h"

And define the constants, but here there is one more than in the publisher - the size of the buffer of the incoming data (once again - don't worry about the config path for now):

static constexpr const char* kPathToComConfig {"config/communication_config.json"};
static constexpr const char* kInstanceSpecifier {"SomeInstanceSpecifier"};
static constexpr std::size_t kBufferSize {3U};

In the main function we start with setting the config file path and the instance specifier creation:

score::StringLiteral runtime_args[2U] = {"--service_instance_manifest", kPathToComConfig};
score::mw::com::runtime::InitializeRuntime(2, runtime_args);

const score::Result<score::mw::com::InstanceSpecifier> instance_specifier_result = score::mw::com::InstanceSpecifier::Create(std::string{kInstanceSpecifier});

if (!instance_specifier_result.has_value())
{
    std::cerr << "Error: failed to create instance specifier!" << std::endl;
    return 1;
}

const score::mw::com::InstanceSpecifier instance_specifier = instance_specifier_result.value();

Now comes the important part - actually finding the service that our publisher offers. In general, there are 2 ways of finding the service:

synchronous with FindService function
asynchronous (non-blocking) with StartFindService function

In this example I will use FindService to make the example as explicit as possible by iterating and waiting 1 second after each failed iteration:

score::mw::com::ServiceHandleContainer<score::mw::com::impl::HandleType> services{};

do
{
    const auto services_result = PositionInterfaceProxy::FindService(instance_specifier);

    if (!services_result.has_value())
    {
        std::cerr << "Error: failed to find services for specifier "
                  << instance_specifier.ToString() << ": "
                  << services_result.error() << std::endl;
        return 1;
    }

    services = services_result.value();

    if (services.size() == 0U)
    {
        std::this_thread::sleep_for(std::chrono::seconds(1U));
    }
} while (services.size() == 0);

const auto service = services.front();

When the service is found, create the proxy via which subscriber will receive the data sent by the publisher:

auto proxy_result = PositionInterfaceProxy::Create(service);

if (!proxy_result.has_value())
{
    std::cerr << "Failed to create proxy for the found service!" << std::endl;
    return 1;
}

auto& position_proxy = proxy_result.value();

Now the most important part - the implementation of receiving the data. You do that by setting a receive handler on the center event. When the receive handler is called, it means that the new data is ready to be read. Inside of that receive handler implementation, you call GetNewSampes which let's you to actually access the received data:

position_proxy.center.SetReceiveHandler([&position_proxy](){
    score::Result<std::size_t> num_samples_received = position_proxy.center.GetNewSamples(
    [](score::mw::com::SamplePtr<Point> point) noexcept {
        if (!point) {
            std::cerr << "Received data is invalid" << std::endl;
            return;
        }

        std::cout << "Received data ("
                  << point->x << ", " << point->y << ")" << std::endl;
    },
    kBufferSize);

    if (!num_samples_received.has_value()) {
        std::cerr << "num_samples_received does not have a value!" << std::endl;
        return;
    }

    std::cout << "Received " << num_samples_received.value()
              << " new samples" << std::endl;
});

After that, S-Core knows how you want to read the data, but to actually start receiving it, you must subscribe to the center event:

position_proxy.center.Subscribe(kBufferSize);

Because calling the receive handler is done asynchronously in the background, add the loop preventing application from exiting. You can base it on the signal handler, but for purpose of this simple example, I'll just go with:

while (true) {}

If you however go with the proper signal handling, you may want to add a cleanup after the loop which unsubscribes from the center event:

position_proxy.center.Unsubscribe();
return 0;

Communication configuration

Ok, now it's the time to start bother about the line which both publisher and subscriber share and which I earlier told you not to worry about:

static constexpr const char* kPathToComConfig {"config/communication_config.json"};

The implementation of the publisher and subscriber is not enough - the communication must still be configured in the JSON file by providing at least information presented below. Create the config/communication_config.json file with the following content:

Note: I keep instance specifier as SomeInstanceSpecifier and service type name as SomeServiceTypeName instead of something like PositionService or Point to show that the names in the configuration file does not need to be the same or even related to the names in the interface model. They need to be however in sync inside the configuration file, so if you set serviceTypeName to SomeServiceTypeName in the serviceTypes list, you must use the same serviceTypeName in the serviceInstances list.

{
  "serviceTypes": [
    {
      "serviceTypeName": "SomeServiceTypeName",
      "version": {
        "major": 1,
        "minor": 0
      },
      "bindings": [
        {
          "binding": "SHM",
          "serviceId": 1,
          "events": [
            {
              "eventName": "center",
              "eventId": 1
            }
          ]
        }
      ]
    }
  ],
  "serviceInstances": [
    {
      "instanceSpecifier": "SomeInstanceSpecifier",
      "serviceTypeName": "SomeServiceTypeName",
      "version": {
        "major": 1,
        "minor": 0
      },
      "instances": [
        {
          "instanceId": 1,
          "asil-level": "QM",
          "binding": "SHM",
          "events": [
            {
              "eventName": "center",
              "numberOfSampleSlots": 3,
              "maxSubscribers": 10
            }
          ]
        }
      ]
    }
  ]
}

AI is powerful. Snippets are instant.

Stop prompting for the same patterns repeatedly. Get almost 100 free VS Code snippets for C++, Python, CMake and Bazel from piko::snippets GitHub repository.

Building the project

General project setup

Create empty WORKSPACE file in the root of your project. Then create the Bazel runtime configuration .bazelrc file with the following content:

common --@score_baselibs//score/mw/log/detail/flags:KUse_Stub_Implementation_Only=False
common --@score_baselibs//score/mw/log/flags:KRemote_Logging=False
common --@score_baselibs//score/json:base_library=nlohmann
common --@score_communication//score/mw/com/flags:tracing_library=stub

common --registry=https://raw.githubusercontent.com/eclipse-score/bazel_registry/v0.5.0-beta/

common --registry=https://bcr.bazel.build

After that, configure thirdparty modules in MODULE.bazel file:

bazel_dep(name = "score_toolchains_gcc", version = "0.5", dev_dependency=True)

gcc = use_extension("@score_toolchains_gcc//extensions:gcc.bzl", "gcc", dev_dependency=True)
gcc.toolchain(
    url = "https://github.com/eclipse-score/toolchains_gcc_packages/releases/download/0.0.1/x86_64-unknown-linux-gnu_gcc12.tar.gz",
    sha256 = "457f5f20f57528033cb840d708b507050d711ae93e009388847e113b11bf3600",
    strip_prefix = "x86_64-unknown-linux-gnu",
)

use_repo(gcc, "gcc_toolchain", "gcc_toolchain_gcc")

bazel_dep(name = "rules_boost", repo_name = "com_github_nelhage_rules_boost")
archive_override(
    module_name = "rules_boost",
    urls = ["https://github.com/nelhage/rules_boost/archive/refs/heads/master.tar.gz"],
    strip_prefix = "rules_boost-master",
)

bazel_dep(name = "boost.program_options", version = "1.87.0")
bazel_dep(name = "score_baselibs", version = "0.2.2")
bazel_dep(name = "score_communication", version = "0.1.2")

bazel_dep(name = "trlc", version = "0.0.0")
git_override(
    module_name = "trlc",
    commit = "ede35c4411d41abe42b8f19e78f8989ff79ad3d8",
    remote = "https://github.com/bmw-software-engineering/trlc.git",
)

Interface model setup

Create position_interface target in model/BUILD file:

load("@score_baselibs//score/language/safecpp:toolchain_features.bzl", "COMPILER_WARNING_FEATURES")

cc_library(
    name = "position_interface",
    hdrs = [
        "position_interface.h",
    ],
    features = COMPILER_WARNING_FEATURES,
    deps = [
        "@score_communication//score/mw/com",
        "@score_baselibs//score/language/futurecpp",
    ],
    visibility = [
        "//src/publisher:__pkg__",
        "//src/subscriber:__pkg__"
    ]
)

Configuration setup

Our configuration is a single JSON file, so there's nothing to build per se, but we need to export the configuration file, so that it can be later used by publisher and subscriber targets as a target in data attribute. In config/BUILD add:

exports_files([
    "communication_config.json",
])

Publisher setup

In src/publisher/BUILD create publisher binary target:

load("@score_baselibs//score/language/safecpp:toolchain_features.bzl", "COMPILER_WARNING_FEATURES")

cc_binary(
    name = "publisher",
    srcs = ["main.cpp"],
    data = ["//config:communication_config.json"],
    features = COMPILER_WARNING_FEATURES,
    deps = [
        "//model:position_interface",
        "@score_communication//score/mw/com",
    ],
)

Subscriber setup

In src/subscriber/BUILD create subscriber binary target:

load("@score_baselibs//score/language/safecpp:toolchain_features.bzl", "COMPILER_WARNING_FEATURES")

cc_binary(
    name = "subscriber",
    srcs = ["main.cpp",],
    data = ["//config:communication_config.json"],
    features = COMPILER_WARNING_FEATURES,
    deps = [
        "//model:position_interface",
        "@score_communication//score/mw/com",
    ],
)

Building both applications

Now, to build the publisher, call:

bazel build //src/publisher

And to build the subscriber call:

bazel build //src/subscriber

Note: during my tests I was not able to successfully build the project without adding --copt=-Wno-error=deprecated-declarations to the above build commands.

Running

It's finally time to run both applications. Open 2 terminals. In the first one call:

bazel run //src/publisher

And in the second one call:

bazel run //src/subscriber

In the publisher's terminal you should see logs like:

Sending data (5, 10)
Sending data (6, 12)
Sending data (7, 14)

And in the subscriber's terminal you should see logs like:

Received data (5, 10)
Received 1 new samples
Received data (6, 12)
Received 1 new samples
Received data (7, 14)

How to write Arduino Uno code with Python?

piko::tutorial — Tue, 14 Oct 2025 07:15:00 +0000

Recently I came across a Reddit thread where someone asked:

"I was thinking about using an Arduino, but I have been learning Python and do not want to learn a whole other programming language to do basic things that an Arduino can. (Planning on making a robot, will be using raspberry pi also, but have seen motor controls and such are best done with Arduino).

What experience have you had programming an Arduino with python? How is it and is it difficult?"

There are more threads on the similar topic (like this and that) and when you scroll through the responses on all of these threads, you see people responding with messages like:

"you can’t program an arduino with python"

Or:

"Arduino does not have sufficient resources to run python."

Or:

"It's going to be extremely difficult to get any kind of Python script running directly on the Arduino."

Or:

"You gotta use pyfirmata"

What surprised me was that everyone seemed to be answering a question the original poster didn’t actually ask. The guy who started the thread didn’t say that he wanted to literally run Python on the Arduino and definitely he didn't want to just control the Arduino from the host (like the answer about pyfirmata suggests). To me, it sounds more like he just wanted to write his Arduino code in Python - and that he wouldn’t really care if the board ended up running an ordinary C++.

I thought that it shouldn't be that hard to write some reasonable MVP which does exactly that. This gave me the idea for an experimental project: PyBedded. It’s a tool that lets you write Arduino code in Python and then flash it to your board by just running your Python script. You still get the simplicity of Python, but the Arduino ends up running the same C++ firmware as it would normally do.

TL;DR

If you're here to just use the tool and not read about its details, download the GitHub repository and read the README to learn how to use it.

What this project is NOT

At the beginning, to avoid any disappointments after reading, I'd like to clearly outline what to not expect from this project:

as mentioned in the introduction, this is not another Firmata-like project. The original post on Reddit mentioned about the ability to program Arduino which could run as an independent device, so controlling the board with a Python script from host doesn't fulfill that requirement
I won't try to deploy the actual Python interpreter on the Arduino board or use Micro/CircuitPython which are supported only by some subset of all boards - my assumption is that someone has an old Arduino (like Uno, Nano, Mega2560 etc.) and wants to write a Python code
it's not (only) about the Python to C++ conversion - I want the tool to be "self-contained" meaning, that the user doesn't need to use tool A to convert the Python code, tool B to compile it, tool C to flash it etc. This tool should actually flash the board just by running the script with Arduino code written in Python

Read also on pikotutorial.com: UDP multicasting with Python

Challenges

Workflow

The main challenge was to define a workflow that would fulfill all the assumptions made in the previous paragraph . In the end, I wanted user to just write an ordinary Python script (with a reasonable amount of additional boilerplate code), run it and have the program running on the Arduino board.

The framework ended up looking as following - user uses an externally defined type ArduinoBoard which provides context manager functionality. The entire code contained within this block will be treated as code which is intended to run on Arduino.

with ArduinoBoard("/dev/ttyUSB0", Board.UNO):
    # Arduino code

The Arduino users are used to a specific main file structure which requires definition of setup and loop functions. Let's make them mandatory also in PyBedded. Python supports function definition inside the context manager's block, so the minimum required code looks like this:

with ArduinoBoard("/dev/ttyUSB0", Board.UNO):
    def setup() -> None:
        pass

    def loop() -> None:
        pass

Such structure gives also another benefit - the ease of finding where the Arduino code starts.

I mentioned above, that everything below the context manager block will end up flashed to Arduino, but how to actually find it in the file? I don't want to rely on hardcoding the line number because the user may add something above it. I also don't want to rely on searching of substring like "ArduinoBoard(" because if the name will be changed, I would have to change code extraction logic.

However, because I know that the user always uses context manager, I can use the inspect module to check from what file and which line in that file ArduinoBoard's context manager has been called:

import inspect

frame: FrameInfo = inspect.stack()[2]
file_path: str = frame.filename
start_line: int = frame.lineno

LOGGER.debug(f"Python code available in {file_path}, starting at line {start_line}")

Support for Arduino and external libraries

At the beginning one of my concerns was how to provide support for all the Arduino's core API (stuff like digitalWrite, digitalRead etc.) and all the libraries associated with it (like Servo, Ethernet etc.), but then I realized that actually the only thing that's needed to write a valid Python code, is the list of corresponding function's and classes' definitions. For example, to enable PyBedded user to set digital pin state, the only thing that needs to be provided is:

def digitalWrite(pin: int, state: int) -> None:
    pass

The call of this function will look exactly the same both in Python and C++ what makes the code conversion easier. Appropriate C++ header will be included in the generated code depending on the functions used in the code.

Toolchain

The main tool that will be used underneath will be Arduino CLI. The following commands will be especially useful in this project:

arduino-cli lib install - I will use it to in the installation script to install all the currently supported libraries which can be used in the sketch
arduino-cli core install - I will use it in the installation script to install all the currently supported boards
arduino-cli compile - compilation of the generated C++ code
arduino-cli upload - flashing Arduino with the compiled firmware

Design

The design relies almost entirely on the Python's context manager functionality - as soon as the with ArduinoBoard... block finishes, the following steps are executed:

read the script's path and the line where Arduino code starts
extract Python code from the script which is going to be converted to C++
create Arduino project (folder and .ino file)
compile the code
upload the code to the Arduino board
remove Arduino project folder and .ino file

The flow is nice and easy, so let's now look at the Python-to-C++ code conversion.

Python to C++ conversion

There are whole books about writing compilers, code transpilation, parsers, lexers etc., but because this proof of concept is rather focused on the Python framework for Arduino programming, I decided to implement a simple Python to C++ converter with the following structure:

Python code -> PythonParser -> code model -> CppGenerator -> C++ code

PythonParser takes as an input Python code from the user's script and converts it to a common, language-agnostic model. In practice, PythonParser will be responsible for recognizing certain language features and creating their models like this:

for python_line in python_code:
    if is_function_definition(python_line):  
        # parsing
        return FunctionDefinitionModel(...)  
    elif is_for_loop(python_line):  
        # parsing  
        return ForLoopModel(...) 
    elif is_if_statement(python_line):  
        # parsing
        return IfStatementModel(...)
    # etc

Then this model is taken as an input by the CppGenerator which runs over all the models and converts these models to the actual C++ code line depending on the type of the each model object:

cpp_code: str = ""

for model in models:
    if isinstance(model, FunctionDefinitionModel):
        cpp_code += generate_function_definition(model)
    elif isinstance(model, ForLoopModel):
        cpp_code += generate_for_loop(model)
    elif isinstance(model, IfStatement):
        cpp_code += generate_if_statement(model)
    # etc

Such logic is simple, but not perfect - it makes it ease to add support for the new features in simple scenarios (you just add a single elif in PythonParser and elif in CppGenerator), but can introduce some unexpected behavior because the parser actually relies on the order of the elifs.

To make it work, the least inclusive conditions must be placed earlier in the elif "ladder" and more inclusive ones must be placed later. For example, in the following code, the second condition will never be triggered because "if" is contained both in "if" and "elif", so it would never generate any "else if" in the C++ code.

if "if" in python_line:
    # process
elif "elif" in python_line:
    # process

So "elif" (as the less inclusive condition) must be checked before "if" (which is more general condition and matches more cases):

if "elif" in python_line:
    # process
elif "if" in python_line:
    # process

Ok, so let's now take a look on how to actually write the Arduino code with PyBedded and what C++ code it is being converted to.

AI is powerful. Snippets are instant.

Stop prompting for the same patterns repeatedly. Get almost 100 free VS Code snippets for C++, Python, CMake and Bazel from piko::snippets GitHub repository.

Variable definition

Variable definition looks just as they do in Python with one addition - types annotations are no longer optional, but mandatory since C++ requires them. So the following code:

sensor_value: int = 0

Ends up as:

int sensor_value = 0;

In the resulting sketch.

Function definition

Python allows to define new functions almost everywhere, so user places custom functions definitions inside the Arduino context manager's block (in the same way as setup and loop functions are defined). The syntax is a typical Python's syntax, but again, type annotations are mandatory:

def do_something(a: int, b: unsigned_int) -> None:
    pass

The above code will be converted to:

void do_something(int a, unsigned int b)
{}

Notice 2 things:

None is an equivalent of void
types like unsigned int, unsigned longetc. are not supported by default in Python, so PyBedded adds such support by defining new aliases like:

unsigned_long = int  
unsigned_int = int

This way user can use such types and still be able to write a valid Python code.

Control statements

There are control statements whose syntax is very similar in Python and C++ (e.g. ifor while loop) and control statements whose syntax is completely different (e.g. for loops).

In case of the first category, generation boils down mainly to adding parenthesis and converting logic operators to the ones used in C++, so that this:

if not Serial and (a == 1 or b == 2):
    pass

becomes that:

if (!Serial && (a == 1 || b == 2))
{}

In case of the second category, you still write an ordinary Python syntax, but underneath Python-to-C++ converter tries to match the corresponding values to the C++'s syntax. Input:

# 1
for i in range(10):
    pass
# 2
for i in range(2, 10):
    pass
# 3
for i in range(2, 10, 3):
    pass
# 4
for i in range(10, 0, -1):
    pass

Output:

# 1
for (int i=0; i<10; i += 1)
{}
# 2
for (int i=2, i<10; i += 1)
{}
# 3
for (int i=2; i<10; i += 3)
{}
# 4
for (int i=10, i>0; i += -1)
{}

Preprocessor directives

Python is not a compiled programming language, so preprocessor directives like #define or ifdef must be supported by some kind of a convention.

In case of #define, I decided to rely on a naming convention - if a variable is declared using all uppercase letters, then it will end up as a compile-time constant. So the following Python code:

SENSOR_PIN: int = 4
sensor_value: int = 0

is converted to:

#define SENSOR_PIN 4
int sensor_value = 0;

When it comes to compile-time conditions, PyBedded just provides 3 special functions: IFDEF, IFNDEF and ENDIF:

IFDEF("SOME_FLAG")
sensor_value += 1
ENDIF()

C++ code equivalent:

#ifdef SOME_FLAG
sensor_value += 1;
#endif

Read also on pikotutorial.com: Hacking Python functions by changing their source code

Examples

Blink

Python code:

# create ArduinoBoard object providing the port it is connected to
# and the board's type 
with ArduinoBoard("/dev/ttyUSB0", Board.UNO):  
    def setup() -> None:
        # set pin mode  
        pinMode(LED_BUILTIN, OUTPUT)  

    def loop() -> None:
        # set pin state to high
        digitalWrite(LED_BUILTIN, HIGH)
        # wait 1000ms  
        delay(1000)  
        # set pin state to low
        digitalWrite(LED_BUILTIN, LOW)
        # wait 1000ms  
        delay(1000)

The generated C++ code:

void setup() {  
    pinMode(LED_BUILTIN, OUTPUT);  
}  
void loop() {  
    digitalWrite(LED_BUILTIN, HIGH);  
    delay(1000);  
    digitalWrite(LED_BUILTIN, LOW);  
    delay(1000);  
}

Blink without delay

Python code:

with ArduinoBoard("/dev/ttyUSB0", Board.UNO):  
    led_pin: int = LED_BUILTIN  
    led_state: int = LOW  
    previous_millis: unsigned_long = 0  
    interval: long = 1000  

    def setup() -> None:  
        pinMode(led_pin, OUTPUT)  

    def loop() -> None:
        global previous_millis, led_state  

        current_millis: unsigned_long = millis()  

        if current_millis - previous_millis >= interval:  
            previous_millis = current_millis  

            if led_state == LOW:  
                led_state = HIGH  
            else:  
                led_state = LOW  

            digitalWrite(led_pin, led_state)

The generated C++ code:

int led_pin = LED_BUILTIN;  
int led_state = LOW;  
unsigned long previous_millis = 0;  
long interval = 1000;  
void setup() {  
    pinMode(led_pin, OUTPUT);  
}  
void loop() {  
    unsigned long current_millis = millis();  
    if (current_millis - previous_millis >= interval) {  
        previous_millis = current_millis;  
        if (led_state == LOW) {  
            led_state = HIGH;  
        }  
        else {  
            led_state = LOW;  
        }  
        digitalWrite(led_pin, led_state);  
    }  
}

Servo sweep

Python code:

with ArduinoBoard("/dev/ttyUSB0", Board.UNO):  
    myservo: Servo = Servo()  
    pos: int = 0  

    def setup() -> None:  
        myservo.attach(9)  

    def loop() -> None:  
        for pos in range(180):  
            myservo.write(pos)  
            delay(15)  
        for pos in range(180, 0, -1):  
            myservo.write(pos)  
            delay(15)

The generated C++ code:

#include <Servo.h>  
Servo myservo = Servo();  
int pos = 0;  
void setup() {  
    myservo.attach(9);  
}  
void loop() {  
    for (int pos=0; pos<180; pos += 1) {  
        myservo.write(pos);  
        delay(15);  
    }  
    for (int pos=180; pos>=0; pos += -1) {  
        myservo.write(pos);  
        delay(15);  
    }  
}

Debugging options

While working with PyBedded I found it useful to e.g. compile the code, but not upload it to the board or compile and debug the compilation error by analysing the generated C++ code, so ArduinoBoard object accepts couple of additional parameters-flags:

compile - by default True, omits compilation step if set to False
upload - by default True, omits board flashing if set to False
clean_up - by default True, omits Arduino project folder removal if set to False

Maturity of the project

Currently the project supports all the features used in the examples available in Arduino IDE, except custom classes/structs definition.

DEV Community: piko::tutorial

git log tricks you really should know

Structured output with --pretty=format:

Time-based and path-based history analysis

Exporting logs to specific file formats

Visualizing history as a graph

Extracting commit statistics for analytics

Final combo

Surprisingly necessary explanation of Python venv

What venv is NOT

Dependency isolation (the one everybody usually knows)

No need to explicitly activate/deactivate the environment

Build env on one machine and run on another

App delivery as a packaged virtual environment

A dependency backup

When AI gets C++ bitmask enums almost right

The key problem

Don't lie with the function signature

10 VS Code snippets essential for every C++ engineer

Why use snippets in the era of AI agents?

Including path copied to the clipboard

Declaring new interface class

If/else

Switch-case statements

Index-based for loops

Range-based for loops

Unique pointer as a class member

Move variable copied to clipboard

Initialize class member on the constructor's list

Check if container is empty

Storing your ATTiny program in...EEPROM?

Scope of this PoC

Required dependencies

Writing EEPROM programs

Example 1 - classic blink

Example 2 - map 2 ADCs to 2 PWMs

How does it work?

Microcontroller setup

Timer interrupt

Timer initialization

ADC initialization

PWM initialization

GPIO helpers

ADC reads

PWM output

Executing instructions from EEPROM

Main execution loop

Peripheral initialization

Global interrupts

Delay handling

EEPROM instruction fetch

Instruction execution

Building and flashing with CMake

Set fuses

Build firmware

Flash firmware

Flashing EEPROM program

Why this approach is interesting

Bug of the week #12

What does it mean?

How to fix it?

Sharing variable between bash scripts

Sharing Variables

Sharing Arrays

Reading Arrays from a File

A 40-line LLM-based bash command executor in Python

Why build a tool like this?

The architecture

The Python implementation

Step 0: set up constants

Step 1: loading configuration and prompt files

Step 2: reading the user request

Step 3: prompt engineering

Establishing assumptions

Biasing command style

Preventing placeholders

Step 4: sending the request to the LLM

Structured JSON output

Low temperature and a fixed seed

Why qwen2.5-coder:1.5B?

Structured output with `--pretty=format:`