Embedded Developer

There is little doubt that the use of AI in coding is improving developer productivity both in the production of code and also diagnosing issues. AI can bring a large corpus of data into one place.

This leads us to the question of which one should we use?

Cloud or Local

The answer to this question will really depend upon the answer to two questions:

• How much can we afford to pay
• Is the code private

This comparison is based upon the following premise, the code is open source and cost needs to be controlled.

Copilot will be used for the cloud service and qwen3-coder-next served by ollama will be used for the local AI.

Copilot has been selected as it is available free for GitHub users. It was also available on a low cost GitHub account. qwen3-coder-next currently appears as one of the top models for software development.

All of the models were accessed through a Command Line Interface (CLI).

The Task

All three models were asked to complete the same task, implement a modal message box on a existing application running on a M5Stack Tab5. All of the models were provided with the same source code and the same specification. The specification was detailed:

## Message Dialog

A modal message dialog can be displayed over the current screen contents at any time by calling:

“`cpp
Display::ShowMessageDialog(const char *title, const char *message);
“`

### Appearance

The dialog is a centred 600 × 300 pixel rounded-rectangle popup (corner radius 16 pixels) drawn over the existing screen contents.

| Layer | Description |
|—|—|
| Outer border | White, 2 pixels |
| Inner fill | Black |

From top to bottom the dialog contains three elements:

#### Title

– Drawn in bold white using `fonts::Font4`.
– Centred horizontally within the dialog.
– Vertically centred within a 56-pixel title band at the top of the dialog.
– The bold effect is achieved by rendering the string twice: once at the nominal position and once shifted one pixel to the right.
– A white horizontal rule separates the title band from the message body.
– The `title` parameter is mandatory and must not be `nullptr` or empty.

#### Message body

– Drawn in white using `fonts::Font4`.
– Centred horizontally within the dialog.
– The text block is vertically centred in the area between the horizontal rule and the OK button.
– Multi-line messages are supported using `\n` as the line separator. Each line is drawn individually at 20-pixel line spacing.

#### OK button

– A rounded-rectangle button (160 × 44 pixels, corner radius 8 pixels) centred horizontally at the bottom of the dialog, 20 pixels above the dialog’s lower edge.
– White border, black fill, white label text (“OK”).

### Behaviour

1. `ShowMessageDialog` draws the dialog immediately, then returns to the caller without blocking.
2. A short-lived FreeRTOS task (`MsgDialogTask`, stack 4096 bytes, priority 5) is spawned to wait for dismissal.
3. The normal panel touch callback (`OnPanelTouch`) is unregistered for the duration; touch events are routed exclusively to the dialog’s own handler (`OnMessageDialogTouch`).
4. `DisplayTask` continues to receive and apply queued `DisplayMessage` state updates while the dialog is visible, but suppresses all draw calls until the dialog is dismissed.
5. When the user taps the OK button, `MsgDialogTask` redraws the full main interface (clearing the dialog) and re-registers `OnPanelTouch`. All 32 storeline dirty flags are forced to `true` before `DrawAllStorelines()` to guarantee a full repaint.
6. `_prevTouched` is set to `true` before re-registering `OnPanelTouch` to prevent the finger-lift from the OK button generating a spurious panel press.

### Thread safety

`ShowMessageDialog` may be called from any task context, including from within a touch callback (e.g. the `LoadCallback` invoked by `TouchTask`). The non-blocking spawn pattern avoids the deadlock that would result from a blocking wait inside `TouchTask`.

All draw calls inside `ShowMessageDialog` and `MsgDialogTask` are serialised by `_displayMutex`.

### Example usage

“`cpp
Display::ShowMessageDialog(“Load Error”, “File not found:\n/sdcard/missing.ssem”);
Display::ShowMessageDialog(“Information”, “Program loaded successfully.”);
“`

Most of the work had already been done so the AI only had to provide the actual implementation.

The Models

The following models were used in this comparison:

• qwen3-coder-next (local)
• gemini-3-flash-preview (cloud)
• GPT-4.1 (cloud)
• Claude 4.6 (cloud)

All of the AIs were given the same prompt:

The Documentation/DisplaySpecification.md file has been updated to include the specification for a modal MessageBox.

Update the project to implement the MessageBox feature.

The local model was run on a laptop with 128 GB of RAM with Ollama consuming around 56 GB when serving qwen3-coder-next.

Results

qwen3-coder-next – 41 Minutes

This model needed some supervision and had to be prompted on several occasions. The model made the following errors:

• Introduced two compiler warnings
• Corrupted the display
• Did not handle blank lines correctly
• Exception due to incorrect code

Prompting and providing additional information enabled the AI to resolve these issues.

Gemini-3-flash-preview – 9 minutes

Completed the task correctly with no errors.

GPT-4.1 – 12 minutes

This model completed the task with only 2 errors:

• Corrupted display
• Main interface not refreshed after the MessageBox was dismissed

Claude 4.6 – 5 minutes

Claude completed the task with no errors.

Conclusion

The local model was the slowest to complete the task. It consumed a fair amount of memory but surprisingly did not use a large amount of CPU power. The use of local resources maintains privacy and means there are no usage limits.

Gemini completed the task with no errors but this has a restricted number of tokens available per day.

Accessing Claude through the Copilot CLI was certainly the quickest but this consumes a premium request for each task.

ChatGPT 4.1 is also available through the Copilot CLI. While not perfect, needing guidance, this model offered a balance between cost and speed. There is no additional cost when accessed through Copilot CLI.

Copilot with ChatGPT 4.1 seems a reasonable balance between speed, accuracy and cost for open source projects. Claude 4.6 has proven itself a number of times and this task shows how this can benefit projects where code privacy is not an issue although there is an associated cost.

Some notable resources for anyone starting Rust.

The Rust Programming Language

The third edition of The Rust Programming Language was released on 31st March 2026.

Accessing Hardware in Rust

Ferrous Systems have published a blog post covering the topic of dealing with low level hardware from the safe Rust environment. The post also points to a number of interesting tools available to firmware developers.

Microsoft Rust Training Books

Microsoft have released a number of training books covering Rust. Soe fo the books cover Rust for programmers coming from other programming languages including C/C++, C# and Python. The series of books also cover async and continuous integration.

Introduction to Rust Video Series

Digikey have released a video training series covering the Rust programming language from the basics of the benefits of Rust through to interrupt processing on a Raspberry Pi Pico microcontroller. The full play list can be found at Introduction to Rust Playlist. This series covers (at the time of writing) the following modules:

• What is Rust
• What is Rust
• Blink a LED
• USB Serial Logging and Debugging
• Ownership and Borrowing
• Reading from an I2C Temperature Sensor
• Generics and Traits
• Creating a TMP102 Driver Library and Crate
• Lifetimes and Lifetime Annotations
• Test Driven Development
• Interrupts
• Logging with defmt and Step-through Debugging
• Async Programming with Embassy

Espressif has recently released a cross-platform installation manager for the SDK used with ESP32 boards.
ESP-IDF Installation Manager (EIM)
is available for macOS, Linux, and Windows. The aim of the tool is to simplify the installation of ESP-IDF and its associated tools.

EIM also allows multiple copies of the framework to be installed on the same machine, allowing developers to switch between versions. This is ideal for testing different IDF versions against a code base.

Various IDF archives can be found on the
EIM Offline Installer downloads page.

First Impressions

So far, the tool has delivered on the promise of providing an easy, switchable way to install the various tools and SDKs. Installation of the tool is straightforward, and the SDKs are downloaded as archives and then loaded into the system using EIM. The same tool is used to switch from one IDF version to another.

Aside from one caveat, which will be covered later, the tool does exactly what it says on the tin, offering a simple way to install and switch between IDF versions.

Installing an IDF Version

Installation of the tool itself went smoothly; only two brew commands were needed.

brew tap espressif/eim
brew install eim

It is then necessary to download and install the archives for the IDF versions of interest. This is simply a case of navigating to the
EIM Offline Installer downloads page,
selecting the desired IDF version or versions, and downloading them locally. These archives can be large, with some coming in at 2.5 GB.

Once downloaded, an archive can be installed into the EIM system with a command such as the following:

eim install --use-local-archive archive_vv6.0_macos-aarch64.zst

The downloaded archive file can be deleted once an IDF version has been installed. The full list of installed versions can be obtained using the command:

$ eim list
2026-03-29 09:00:12 -  9 - 03 - INFO - Listing installed versions...
Installed versions:
- v5.5.3 (selected) [/Users/username/.espressif/v5.5.3/esp-idf]
- v6.0 [/Users/username/.espressif/v6.0/esp-idf]

An installed version can be activated with the command:

source /Users/username/.espressif/tools/activate_idf_v5.5.3.sh

This command registers the various environment variables, Python environments, and related settings:

Added environment variable ESP_IDF_VERSION = 5.5
Added environment variable IDF_TOOLS_PATH = /Users/username/.espressif/tools
Added environment variable IDF_COMPONENT_LOCAL_STORAGE_URL = file:///Users/username/.espressif/tools
Added environment variable IDF_PATH = /Users/username/.espressif/v5.5.3/esp-idf
Added environment variable ESP_ROM_ELF_DIR = /Users/username/.espressif/tools/esp-rom-elfs/20241011
Added environment variable OPENOCD_SCRIPTS = /Users/username/.espressif/tools/openocd-esp32/v0.12.0-esp32-20251215/openocd-esp32/share/openocd/scripts
Added environment variable IDF_PYTHON_ENV_PATH = /Users/username/.espressif/tools/python/v5.5.3/venv
Added proper directory to PATH
Activated virtual environment at /Users/username/.espressif/tools/python/v5.5.3/venv
Environment setup complete for the current shell session.
These changes will be lost when you close this terminal.
You are now using IDF version 5.5.
eim select v5.5.3

Once complete, the selected IDF version is ready to use.

Scripting

Now to the caveat mentioned earlier.

Using idf.py from the command line works fine, as do all the other tools. Things are a little different when it comes to scripting.

On macOS, EIM exposes idf.py via a shell alias. In practice, it looks something like this:

alias idf.py='/Users/username/.espressif/tools/python/v5.5.3/venv/bin/python /Users/username/.espressif/v5.5.3/esp-idf/tools/idf.py'

As mentioned, this works on the command line. However, it does not work in a bash script, as aliases are not normally expanded in non-interactive bash scripts. The solution is to define a variable in the bash script that points to the idf.py Python script file:

IDF=$IDF_PATH/tools/idf.py

It then becomes a simple case of replacing idf.py with $IDF within the script. So far, this solution has worked both locally and in a GitHub Action.

EIM GUI

Espressif also offers a GUI version of the installation manager. This was installed briefly but removed after Malwarebytes detected an attempt to access a website that it identified as potentially serving a Trojan.

This was did not seem to be a problem with the command line version of EIM.

Conclusion

EIM provides a simple way to install ESP-IDF versions and switch between them. It should make the setup process more straightforward, particularly for users on platforms where ESP-IDF installation has traditionally been less convenient.

The previous post installed the toolchain and verified that the tools had been installed. Now it is time to create a project and and run the tools to test and simulate a part. The 74LS245 Bus Transceiver with three state output.

Creating a Project

First step is to create the project directory and create a file containing the PIO project configuration file, apio.ini. Starting a terminal and executing the following commands:

mkdir Project
cd Project
apio create -b upduino31

This should create the apio.ini file in the Project directory containing the board name and the name of the top module. Additional configuration items are defined in the FPGA Wars documentation.

Basic Implementation of the 74LS245

The 74LS245 provides a way of connecting or isolating a circuit to / from a bus. The chip provides a tristate interface. This enables signals to flow in both directions as well as the possibility of isolation from the bus. This device has the following signals / connections:

• 8 Data lines on the A bus connection
• 8 Data lines on the B bus connection
• Direction signal
• Output enable signal

Output Enable (OE) determines if the 74LS245 allows data to flow between the data busses. This is an active low signal so 0 enables the connection and 1 disables the connection.

Direction determines the direction of data, does data flow from bus A to bus B or vice versa? A value ot 0 takes the data signals on bus B and copies them to bus A. 1 connects the busses in reverse.

The basic implementation in Verilog could look something like the following:

//
//  74LS245 - Octal bus transceiver with 3-state outputs.
//
module ttl245_transceiver 
#(PROPAGATION_DELAY = 32, RISE_TIME = 1, FALL_TIME = 1)
(
    inout wire [7:0] A,    // 8-bit bidirectional bus A.
    inout wire [7:0] B,    // 8-bit bidirectional bus B.
    input wire DIR,        // Direction control: 0=B to A, 1=A to B.
    input wire OE_n        // Output Enable (active low, tri-state when high).
);
    //
    //  Internal signals for direction control.
    //
    reg [7:0] A_out;
    reg [7:0] B_out;

    //
    // OE  DIR  Function
    // ----------------------
    //  0   0   B to A
    //  0   1   A to B
    //  1   X   Outputs disabled (high-impedance)
    //
    assign A = ((OE_n == 1'b0) && (DIR == 1'b0)) ? A_out : 8'bz;
    assign B = ((OE_n == 1'b0) && (DIR == 1'b1)) ? B_out : 8'bz;
    
    always @(A or B or DIR or OE_n)
    begin
        if (OE_n == 1'b0) begin
            if (DIR == 1'b1)
            begin
                #PROPAGATION_DELAY B_out <= A;
            end else
            begin
                #PROPAGATION_DELAY A_out <= B;
            end
        end else
        begin
            #(PROPAGATION_DELAY)
            A_out <= 8'bz;
            B_out <= 8'bz;
        end
    end

endmodule

The values for the rise and fall times are not used in this implementation. The propagation delay is used to mimic the fact that signals are not mirrored between the busses immediately.

Testing

APIO offers two methods of checking the implmentation:

• Testing
• Simulation

Both of these methods require a test bench also implemented in Verilog.

//
//  Test the implementation of the 74LS245 octal bus transceiver.
//
`timescale 1 ns / 10 ps

module ttl245_tb();
    reg [7:0] A_drive;
    reg [7:0] B_drive;
    reg DIR;                // Direction control: 1 = A to B, 0 = B to A.
    reg OE_n;               // Output Enable (active low).
    wire [7:0] A;
    wire [7:0] B;
    
    reg A_enable;
    reg B_enable;

    //
    // Drive A and B buses conditionally.
    //
    assign A = A_enable ? A_drive : 8'bz;
    assign B = B_enable ? B_drive : 8'bz;
    
    //
    // Instantiate the ttl245_transceiver module using the default propagation delay.
    //
    ttl245_transceiver uut (
        .A(A),
        .B(B),
        .DIR(DIR),
        .OE_n(OE_n)
    );

    localparam PROPAGATION_DELAY = 50;     // Delay to allow for propagation with some overhead.

    initial begin
        $dumpvars(0, ttl245_tb);
    end

    initial begin
        //
        //  Setup the initial conditions.
        //
        A_drive = 8'b00000000;
        B_drive = 8'b00000000;
        DIR = 1'b0;                 // Initial direction B to A.
        OE_n = 1'b1;                // Outputs disabled.
        A_enable = 1'b0;
        B_enable = 1'b0;

        //
        //  Test 1: A to B direction (DIR = 1).
        //
        DIR = 1'b1;              // Set direction A to B.
        OE_n = 1'b0;             // Enable output.
        A_enable = 1'b1;         // Drive A bus.
        B_enable = 1'b0;         // Release B bus (will be driven by chip).
        A_drive = 8'b10101010;   // Drive A with test pattern.
        #PROPAGATION_DELAY
        if (B != A_drive) begin
            $error("Error: Test 1a, B bus did not match expected value.");
        end

        //
        //  More tests go here.
        //

        $display("74LS254 - End of Simulation");
        $finish;
    end

endmodule

The code above shows just one test with the insertion point for further tests to be added. The two files (implmentation and test bench) should be placed in the Project directory and the following structure is suggested:

Project/
├── apio.ini
├── Source/
│ └── ttl245.v
├── Tests/
│ └── ttl245_tb.v

APIO will process all of the files in the current directory and any subdirectories. It also expects that the files with the suffix _tb are test bench files.

Running the Test

The tests can be run using the apio test. This command takes an optional file name which when specified will run the tests in the specified file. So the command:

apio test Tests/ttl245_tb.v

will run the tests in the file Tests/ttl245_tb.v. Running this command results in output similar to the following:

APIO can also run all of the test benches (files with the _tb suffix) with the command:

apio test

In this case this will run the only test bench file. It will run the tests in all of the _tb files if more that one exists.

Simulation

Another option is to run a test bench in simulation mode. In this mode the run output is displayed in gtkwave. This output is useful for displaying the relationship between various signals. A simulation is run using the following command:

apio sim Tests/ttl245_tb.v

This will run the simulation and collect the output in a vcd file. This is then processed and gtkwave started. Zooming in on the output we can see the data being loaded on to the busses and the signals showing the relationship between the A, B, DIR and OE_n signals:

By placing markers we can measure the propagation delay between the data appearing on the A bus and the same data being transferred to the B bus:

By default, APIO starts gtkwave and waits until gtkwave exits before returning control to the terminal. It is possible to return control to the terminal immediately using the command:

apio sim Tests/ttl245_tb.v --detach

Conclusion

It is looking promising so far, it should be possible to build the individual chips in the design and finally combine instances of the chips into a fuller design.

Next up, identify the 7400 chips required and implement the chips and test benches.

An upcoming project is going to require the use of a number of logic gates from the 7400 series of integrated circuits. The project is low speed but it will require a fairly large number of gates.

Could an FPGA provide a suitable proving ground for the project?

This blog has occasionally covered FPGA development boards and simulation software and the free model foundry. The simulation posts used VHDL and commercial simulation software.

But that was over 10 years ago now. Time to revisit the subject.

UPduino 3

The UPduino 3 is a small FPGA development board based upon the Lattice UltraPlus ICE40UP5K FPGA. It is a low cost board and looks ideal for starting with FPGA development.

The software stack for development is the open source APIO toolset and a Visual Studio Code extension available.

Step 1 – Remove Installed Software

The first step in getting started was to remove any previously installed software, namely an old version of APIO and icarus-verilog.

pip uninstall apio
brew uninstall icarus-verilog

Step 2 – Install Visual Studio Code Extension

Instructions for installing the APIO extension can be found in the Installing the APIO IDE documentation.

Step 3 – Check the Installation

Executing the command

apio -h

should result in the following output:

Usage: apio [OPTIONS] COMMAND [ARGS]...

  WORK WITH FPGAs WITH EASE.

  Apio is an easy to use and open-source command-line suite designed to
  streamline FPGA programming. It supports a wide range of tasks,
  including linting, building, simulation, unit testing, and programming
  FPGA boards.
.
.
.

Looks like we have the software installed.

Next Up

Simulating some code.

The Raspberry Pi Foundation have recently announced an update to the Visual Studio Code (VS Code) extension. The update now supports developing embedded firmware for Pico using Rust or Zephyr. The announcement is timely given my current aim of learning Rust with the aim of developing on embedded platforms.

Time to give the extension a spin.

TL;DR It just works.

Updates and Pre-requisites

The post starts by giving an overview of what the extension can do as well as:

• Overview of Rust
• Overview of Zephyr
• Getting (or updating) the extension
• Installing any pre-requisites

The development platform used when researching this post is MacOS and a previous version of the VS Code extension had already been installed on the platform. Upgrading the extension was as easy as simply using the VS Code Check for Updates… menu item.

Creating a Rust Project

First step in creating an application is to activate the Raspberry Pi extension by clicking on the Pico Extension icon on the Primary Side bar:

Next select the New Rust Project:

This will show the New Rust Project options:

Here we just need to supply a name for the project and the location for the project files. One point to note is that the project name appears to be restricted:

• Lower case letters only
• Start with a letter
• Numbers
• – or _

It was necessary to check and deploy the SDK when this was run for the first time and this took a minute or so.

Subsequent runs took about 5 seconds to create and configure a new project.

Finally, VS Code will open the Directory view which shows all of the project files:

Running the Application

By default the project appears to be configured as a 2350 project. The original post from Raspberry Pi states:

supports both RP2040– and RP2350-based devices — including the RISC-V target — which you can later select in the toolbar, next to the Run button.

I must admit, this took a little while to locate. The Run button appears at the far right on the bottom toolbar:

Clicking on the chip name allows the target chip to be selected in the command palette:

Final steps, setting some breakpoints in the application and debugging the application. This is achieved using the Debug and Run facility in Debug view (alternatively press F5):

A few seconds later deployment had completed and the first breakpoint was hit:

Additional Components

The post recommends installing three optional components/extensions:

• Probe-rs
• Cortex Debug
• Rust analyzer

These had already been deployed to the development machine and are simple to install.

Conclusion

There were a couple of points of confusion, one when the extensions downloaded a few components (this made the creation of the first application take a while). The second was changing the target chip type, it took a minute or so to find the Run button.

Having installed several embedded toolchains over the years I think this was the simplest and probably the best experience and is on a par with commercial toolchains such as Keil.

Enums in Rust have some properties over and above those found in C/C++

• Data can be associated with them
• Methods can be implemented for an enum

The final item in the list was only briefly covered in chapter 6 of The Rust Programming Language book so we will expand on this here.

Simple Enums

As with C/C++, simple enums are symbolic representations of a concept or value. You don’t necessarily need to know what the value is, you can simply use the symbolic name.

enum Message {
    MoveByOffset,
    MoveTo
}

The above code could represent an operation in a game to move a sprite/character etc. This is very much like C/C++, it becomes more interesting when we associate data to an enum.

Enums Can be Associated with Data

Enums can also have data associated with them. So the above enum could be embellished to have the offset and coordinate data associated with the move operations:

enum Message {
    MoveByOffset { x: i32, y: i32 },
    MoveTo { x: i32, y: i32 }
}

Another feature of enums is that not all of the symbolic names (variants) need to have the same data type associated with them. The Message enum could be expanded to encompass more operations:

enum Message {
    Quit,
    Move { x: i32, y: i32 },
    Write(String),
    ChangeColor(i32, i32, i32),
}

Here we have messages with different data associated with them and even one without any data. We can even have methods implemented for an enum:

impl Message {
    fn call(&self) {
        // method body would be defined here
    }
}

let m = Message::Write(String::from("hello"));
m.call();

Here, we have a call method that can be executed for a Message enum.

Differentiating Between Enums

So far everything looks pretty much like the code in chapter 6 of the Rust book.

The thing that is not covered at this point is how to access the data in the different messages and just as importantly, determine the exact variant of the enum that has been instantiated. For this we need the match statement along with the self parameter in the call method. This is best illustrated by an example:

enum Message {
    Quit,
    Move { x: i32, y: i32 },
    Write(String),
    ChangeColor(i32, i32, i32),
}

impl Message {
    fn call(&self) {
        match self {
            Message::Quit => println!("Quit message received"),
            Message::Move { x, y } => println!("Move to coordinates: ({}, {})", x, y),
            Message::Write(text) => println!("Write message: {}", text),
            Message::ChangeColor(r, g, b) => { println!("Change color to RGB({}, {}, {})", r, g, b) }
        }
    }
}

fn main() {
    let m1 = Message::Write(String::from("Hello"));
    m1.call();

    let m2 = Message::Move { x: 10, y: 20 };
    m2.call();

    let m3 = Message::ChangeColor(255, 0, 0);
    m3.call();

    let m4 = Message::Quit;
    m4.call();
}

Running this application results in the following output:

Write message: Hello
Move to coordinates: (10, 20)
Change color to RGB(255, 0, 0)
Quit message received

Here, self is used to determine which variant of the Message is calling the method call and match ensures that the appropriate action is taken.

Conclusion

The above application is a trivial illustration of using match to work with enums with different variants but it was not covered very well in the text. A little investigation was required.

Next Up

Project Structure.

An aide-memoire post about using the const keyword in function declarations in C/C++. This keyword can have two meanings for pointers depending upon where it is placed:

• The pointer is constant and cannot be changed
• The data pointed to by the pointer is constant and cannot be changed

The following application will be used to illustrate the various cases:

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

void func(char *string)
{
    printf("%s\n", string);
    printf("%s\n", ++string);
    *string = 's';
    printf("%s\n", string);
}

int main(int argc, char**argv)
{
    char *str = strdup("Hello, World!");
    func(str);
    
    free(str);
    return(0);
}

The focus on the definition for func to illustrates the differences. The code fragments that follow will focus on just the definition of func as the rest of the code remains unchanged.

Simple Cases – No const, All const

There are two simple cases:

• No const – both pointers and data can be changed
• Both parameters are const – both data and pointer cannot be changed

In the first case, no const, we have the following code:

void func(char *string)
{
    printf("%s\n", string);
    printf("%s\n", ++string);
    *string = 's';
    printf("%s\n", string);
}

Compiling and running this application results in the following output:

Hello, World!
ello, World!
sllo, World!

As we can see, the pointer string and the data pointed to by string can both be changed.

Modifying the code to make make both the pointer and the data pointed to by the pointer string constant, the function definition becomes:

void func(const char * const string)
{
    printf("%s\n", string);
    printf("%s\n", ++string);
    *string = 's';
    printf("%s\n", string);
}

Compiling the application generates the following output:

Const.c:8:20: error: cannot assign to variable 'string' with const-qualified type 'const char *const'
    8 |     printf("%s\n", ++string);
      |                    ^ ~~~~~~
Const.c:5:30: note: variable 'string' declared const here
    5 | void func(const char * const string)
      |           ~~~~~~~~~~~~~~~~~~~^~~~~~
Const.c:9:13: error: read-only variable is not assignable
    9 |     *string = 's';
      |     ~~~~~~~ ^
2 errors generated.

This shows that these lines contain logic errors:

printf("%s\n", ++string);
*string = 's';

This is expected as printf(“%s\n”, ++string); attempts to modify the pointer and *string = ‘s’; attempts to modify the data.

Making the Pointer Constant

The definition of func can be modified to make just the pointer constant and allow the data to be modified:

void func(char * const string)

Compiling the application generates the following output from the compiler:

Const.c:8:20: error: cannot assign to variable 'string' with const-qualified type 'char *const'
    8 |     printf("%s\n", ++string);
      |                    ^ ~~~~~~
Const.c:5:24: note: variable 'string' declared const here
    5 | void func(char * const string)
      |           ~~~~~~~~~~~~~^~~~~~
1 error generated.

Making the Data Constant

There are two ways of allowing the pointer to change wile maintaining the integrity of the data:

void func(const char *string)

and

void func(char const *string)

Compiling an application with either of these function definitions generates and error such as:

Const.c:9:13: error: read-only variable is not assignable
    9 |     *string = 's';
      |     ~~~~~~~ ^
1 error generated.

Function definitions such as the above are useful for functions such as strlen where we want to walk through an array of data in a read-only mode.

Conclusion

This post aims to clear up the confusion about what is constant given that const can appear on both the left and right side of a variable in a function definition. The following table summaraises what is constant for the various options for const:

So the general rule is the item to the left of the const key word is the item that cannot be changed. With one exception and that is when a variables type is prefixed by const. In which case the const applies to the type and not any pointer definition.

In the words of Connor MacLeod from Highlander

There can be only one.

Every value in a Rust application has one owner and only one owner. When the owner of an value goes out of scope then the value is disposed of and is no longer valid.

The Rust Programming Language (Chapters 4 and 5)

These chapters cover the following topics:

• Ownership
• References and Borrowing
• Slices
• Structs and Methods

Ownership, references and borrowing determine how an object can be accessed and potentially modified. The strict rules are designed to reduce the possibility of common C/C++ issues such as use after free and general pointer access violations.

Structs and methods are the start of the journey into object orientated programming.

Scopes

Scoping rules pretty much follow the same rules as C/C++ and as such are familiar. Any pair of braces open and close a new scope. So a function introduces a new scope. A new scope can also be created with a pair of braces inside an existing scope.

Ownership, References and Borrowing

As Connor MacLeod said, “There can be only one” and in this case, there can be only one owner of a value.

Calling a function can change the ownership of a variable depending upon the type of the variable. Some types implement the copy trait which makes a copy of the variable on the stack. Types that do not implement the copy trait will have their ownership transferred to the function. The transfer of ownership means that the original variable is no longer valid when the function returns.

Consider the following code:

fn print_integer(x: i32) {
    println!("Integer value: {}", x);
}

fn print_string(s: String) {
    println!("String value: {}", s);
}

fn main() {
    let x: i32 = 42;
    println!("Original integer: {}", x);
    print_integer(x);
    println!("Original integer after function call: {}", x); // This line works fine since integers implement the Copy trait.

    let s: String = String::from("Hello, world!");
    println!("Original string: {}", s);
    print_string(s);
    println!("Original string after function call: {}", s); // This line will cause a compile-time error due to ownership rules.
}

Compiling the above code generates the following error output:

error[E0382]: borrow of moved value: `s`
  --> src/main.rs:24:57
   |
21 |     let s = String::from("Hello, world!");
   |         - move occurs because `s` has type `String`, which does not implement the `Copy` trait
22 |     println!("Original string: {}", s);
23 |     print_string(s);
   |                  - value moved here
24 |     println!("Original string after function call: {}", s); // This line will cause a compile-time error due to owne...
   |                                                         ^ value borrowed here after move
   |
note: consider changing this parameter type in function `print_string` to borrow instead if owning the value isn't necessary
  --> src/main.rs:16:20
   |
16 | fn print_string(s: String) {
   |    ------------    ^^^^^^ this parameter takes ownership of the value
   |    |
   |    in this function
   = note: this error originates in the macro `$crate::format_args_nl` which comes from the expansion of the macro `println` (in Nightly builds, run with -Z macro-backtrace for more info)
help: consider cloning the value if the performance cost is acceptable
   |
23 |     print_string(s.clone());
   |                   ++++++++

For more information about this error, try `rustc --explain E0382`.
error: could not compile `hello_world` (bin "hello_world") due to 1 previous error

An awful lot of output to digest.

Calls to print_integer work because the i32 type is simple and this implements the copy trait. This means a copy of the value in x is made on the stack. The function print_integer therefore operates on the copied value and not the variable x defined in main.

print_string works differently as it is operating on a complex value that does not implement the copy trait. Complex values are usually allocated on the heap. Calling print_string moves the ownership of s to the print_string function and the object is dropped at the end of the function making future uses of s in main invalid.

References

The compiler suggested one option for the problem in the above code, to clone the string and pass this to the print_string function. Another solution is to use references. Here the application allows the use of the object without transferring ownership. In this case the object passed is not dropped at the end of the function.

This is known as borrowing.

The above code can be modified to use references:

fn print_string(s: &String) {
    println!("String value: {}", s);
}

fn main() {
    let s: String = String::from("Hello, world!");
    println!("Original string: {}", s);
    print_string(&s);
    println!("Original string after function call: {}", s); // This line will cause a compile-time error due to ownership rules.
}

Running this code with cargo run generates the following output:

Original string: Hello, world!
String value: Hello, world!
Original string after function call: Hello, world!

No more compiler errors.

Function parameters can also be declared as mutable meaning that the original variable can be modified by the function. Modifying the above code to the following:

fn print_string(s: &mut String) {
    println!("String value: {}", s);
    s.push_str(", world!");
}

fn main() {
    let mut s = String::from("Hello");
    println!("Original string: {}", s);
    print_string(&mut s);
    println!("Original string after function call: {}", s);
 }

Running the application results in the following output:

Original string: Hello
String value: Hello
Original string after function call: Hello, world!

print_string is now able to borrow the parameter and modify the value.

I suspect that a lot of time (initially) will be spent fighting the borrow checker.

Structs and Methods

Structs provide the ability to collect together related data items and are similar to structs in C/C++. Methods are functions related to a struct giving us the basics of object orientated programming. The methods are implemented against a type:

struct Rectangle {
    width: u32,
    height: u32,
}

impl Rectangle {
    fn area(&self) -> u32 {
        self.width * self.height
    }
}

In the above code, the area method is implemented against the Rectangle structure.

Language Highlights

One stand out feature with structs is the ability to easily copy unchanged fields from one structure to a new version of the same type of structure. This is best illustrated with an example.

#[derive(Debug)]
struct Person {
    name: String,
    house_number: u16,
    street: String,         // Rest of address fields omitted for brevity.
    mobile_number: String
}

fn update_mobile(person: Person, new_mobile_number: String) -> Person {
    Person {
        mobile_number: new_mobile_number,
        ..person
    }
}

fn main() {
    let person = Person {
        name: String::from("Fred Smith"),
        house_number: 87,
        street: String::from("Main Street"),
        mobile_number: String::from("+44 7777 777777")
    };
    println!("Before update: {:?}", person);
    let updated_person = update_mobile(person, String::from("+44 8888 888888"));
    println!("After update: {:?}", updated_person);
}

Running this application with cargo run generates the following output:

Before update: Person { name: "Fred Smith", house_number: 87, street: "Main Street", mobile_number: "+44 7777 777777" }
After update: Person { name: "Fred Smith", house_number: 87, street: "Main Street", mobile_number: "+44 8888 888888" }

A contrived example maybe but it illustrates the use of ..person to copy the unchanged fields into the new new Person structure.

Another nice feature is the field initialisation for structure members. If a field has the same name as the value being used to initialise it then we can omit the field name. For instance we could modify the update_mobile function above to the following:

fn update_mobile(person: Person, mobile_number: String) -> Person {
    Person {
        mobile_number,
        ..person
    }
}

Note the change to the parameter name to mobile_number to match the field name in the Person struct.

Conclusion

The borrow checker is going to be frustrating for a while with the benefit that if the code compiles it is highly likely to be bug free. The borrow checker also aid in the safety of multithreaded applications.

New Links

Came across a new tool for code linting: Clippy.

Consider the following function:

fn print_integer_and_increment(x: &mut i32) {
    println!("Integer value: {}", x);
    *x = *x + 1;
}

This code compiles without error and works as expected. Running the command cargo clippy to lint the code results in the following output:

warning: manual implementation of an assign operation
  --> src/main.rs:18:5
   |
18 |     *x = *x + 1;
   |     ^^^^^^^^^^^ help: replace it with: `*x += 1`
   |
   = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#assign_op_pattern
   = note: `#[warn(clippy::assign_op_pattern)]` on by default

warning: `hello_world` (bin "hello_world") generated 1 warning (run `cargo clippy --fix --bin "hello_world"` to apply 1 suggestion)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.11s

Running the command cargo clippy –fix –bin “hello_world” –allow-dirty makes the suggested change automatically.

Next Up

Enums, Pattern Matching, Modules and Project structure.

With the tools installed it is time to start learning some language basics:

• Variables
• Functions
• Control structures (if and loops)

The above are covered in the first three chapters of The Rust Programming Language.

Installing the Tools (Update)

Installation of the tools went pretty smoothly and took only a few hours. The Rust in Visual Studio Code page proved to be a nice addition to the links in the blog post.

The page provides information on:

• Intellisense
• Linting
• Refactoring
• Debugging

plus more.

The Rust Programming Language (Chapters 1 through 3)

The initial chapters of the The Rust Programming Language covers the basics of Rust:

• Variables
• Immutability and mutability
• Functions
• Control flow

It was interesting to discover that Rust has a greater degree of distinction between expressions and statements:

Function bodies are made up of a series of statements optionally ending in an expression. So far, the functions we’ve covered haven’t included an ending expression, but you have seen an expression as part of a statement. Because Rust is an expression-based language, this is an important distinction to understand. Other languages don’t have the same distinctions, so let’s look at what statements and expressions are and how their differences affect the bodies of functions.

This difference means that there is no analogy to the following C code:

int x, y;
x = y = 1024;

The basic rule is statements perform actions and expressions return a result. So functions that return a result must return an expression. The general rule being that a statement also ends with a semicolon and an expression does not need one.

Now consider this simple (and admittedly contrived example):

fn add_or_multiply(value : i32) -> i32 {
    if value > 5 {
        return value * 2;
    }
    //  Maybe do some other stuff...
    value + 1
}

fn main() {
    for number in 0..10 {
        let result = add_or_multiply(number);
        println!("Number: {number}, Result: {result}");
    }
}

Running the above generates the following output:

     Running `target/debug/hello_world`
Number: 0, Result: 1
Number: 1, Result: 2
Number: 2, Result: 3
Number: 3, Result: 4
Number: 4, Result: 5
Number: 5, Result: 6
Number: 6, Result: 12
Number: 7, Result: 14
Number: 8, Result: 16
Number: 9, Result: 18

The line return value * 2; can be changed to:

return value * 2

Note the semicolon has been removed. Running the resultant application also generates the same output. Further investigation is required to determine why this works and also what is considered best practice amongst the Rust community.

Language Highlights

From a C/C++ programmers perspective, two Rust constructs are appealing due to their convenience and ability to make code tidier:

• Using if statements in assignments
• Labelled loops

The first construct is alien to the C/C++ developer but should be familiar to Python developers. This is the ability to use an if statement in an assignment operation:

let x = if y <= MAXIMUM { MAXIMUM } else { y };

This means the trivial function add_or_multiply in the above application could have been written as:

const MAXIMUM: i32  = 5;

fn add_or_multiply(value : i32) -> i32 {
    let result = if value > MAXIMUM { value * 2 } else { value + 1 };
    result
}

Nice little feature that can make code more compact and readable.

The second nice feature is the ability to label loops. This allows the application to break in an inner loop to also break an outer loop.

'outer_loop: loop {
    //  Setup for the inner loop...
    loop {
        if remaining == MAXIMUM {
            break;
        }
        if (count % 2) == 0 {
            break 'outer_loop;  // Ignore even numbers.
        }
        // More inner loop processing...
    }
    // More outer loop processing...
}

The inner loop may be a contrived version of a while loop but it serves to illustrate the language feature. The break ‘outer_loop allows the inner loop to skip even numbers without the need run unnecessary nested if statements.

Conclusion

A slow start but some interesting language features:

• Immutability by default
• Using if statements in assignments
• Labelled loops

Next up is ownership.