Featured Articles
Announcing Pi
Technical Specifications
Raspberry Pi FAQs
Win a Pi
GPIO Pinout
Raspberry Pi Wishlist
Comparison Chart
Quiz
Group Actions
Engagement
  • Author Author: BigG
  • Date Created: Date Created
  • Views 3519 views
  • Likes 9 likes
  • Comments 11 comments
Related
Recommended

Google’s new Gemini Code Assist extension for VS Code creates a 6 DoF accelerometer + magnetometer driver for my Raspberry Pico 2 W board.

BigG
Google’s new Gemini Code Assist extension for VS Code creates a 6 DoF accelerometer + magnetometer driver for my Raspberry Pico 2 W board.

Table of Contents

Introduction

Buoyed by my recent success with using Google’s Gemini AI to assist me in creating some I2C driver code for an MCP23017 IC (view the blog here), I wanted to see if this was a complete fluke or whether Gemini could actually reliably help accelerate code development by trying it out with another random sensor. Would it work with something a little more complicated, perhaps?

Of course, I was also dying to test out Google’s recently launched Gemini Code Assist extension for VS Code, which provides a more integrative and immersive experience.

So, I had a browse around the den and found an accelerometer carrier board from Pololu (still in its packaging, unused). The carrier board used an STMicroelectronics LSM303DLM 3-axis accelerometer and 3-axis magnetometer sensor, which after all these years had become obsolete. Still, I felt this was a great use case as there are different versions of this sensor on the market, which require unique settings for the sensor to work, and multiple I2C addresses can be used for the accelerometer and the magnetometer has its own I2C address. On the positive side, the sensor is well documented and there is also plenty of open-source code out there for other microcontrollers - just not for the RP2350.

LSM303DLM

However, before jumping straight in, experience kicks in. It's always well worth confirming that the sensor on the carrier board still actually works.

Validating that the sensor works

To validate sensor functionality, a standard approach I employ, and I suspect many others do as well, is to establish a test bed. I typically start with an Arduino UNO, or a similar board, and wire up the carrier. Then, I locate a relevant library with example code to check the sensor's output. Finding an open-source library is usually straightforward, especially with established sensors, making this my go-to method for initial verification.

This use case was certainly no different. All I had to do was search out and download a library for the LSM303 from within the Arduino IDE (I found two options), then find a suitable sketch and run. Within minutes I was relieved to see that the carrier board does still works.

Challenges switching to MCU of choice

I consistently find the next stage challenging, especially when a dedicated sensor library is unavailable for my target microcontroller SoC. Often, I an tempted or pressured to compromise due to time constraints, resorting to a less-than-ideal but familiar development platform.

This led me to wonder if AI could fundamentally change things for the better.

I wanted to see if it genuinely simplifies sensor integration or just adds another layer of potential headaches.

I hope this blog helps others kickstart a positive change in their own development methodologies.

AI assisted coding workflow

I’ll start with some spoiler alerts…

I got it to work, but it took a few iterations. Developing my driver code for the LM303DLM sensor was almost exclusively a cut and paste exercise.

My observations...

I've just discovered that this approach, where AI handles the majority of the coding process, is referred to as "vibe coding". This is a novel concept to me, as I had no prior experience with, or knowledge of, this term; I simply encountered it on social media: [Wikipedia link]

Anyway, I've now learnt, through this exercise, that the success of using AI-assisted coding to jumpstart a project hinges heavily on the precision of my prompts. Even subtle changes in wording can drastically alter the generated code. I also noticed inconsistencies in coding syntax, particularly with Pico functions for I2C initialization and verification.

When encountering compiler errors or subtle parameter issues—those the compiler misses—the speed of resolution depends significantly on my own sensor expertise. For instance, Gemini fabricated a Pico library function for I2C initialization, leading to a compilation failure. A bizarre error, indeed. However, after pointing it out, Gemini corrected it. Then, when the compiled code failed to work on the Pico, I had to explicitly request Gemini to consult the datasheet, which it did—an impressive feat! Subsequently, a manual review was necessary on my part to highlight the potential parameter error, requiring a further query to Gemini for further verification.

The truly remarkable aspect of AI is its ability to confirm my suspicions, by checking it's own responses. It then provided me with the corrected code.

Conclusion...

Ultimately, Gemini had failed to read the manuals… so it’s universal… no one ever reads the frigging manual!

Here's a detailed walk-through of my setup and embedded development process. Note, videos do not include audio.

Step 1: Installation and Sign-in

I began by installing the Gemini Code Assist extension for VS Code. Once installed, it was not immediately obvious about any login requirements or login screen. It was only that I noticed something new on my screen… at the bottom right of my VS Code screen was a new gold coloured diamond icon. Clicking on this icon opened up the Google Account login screen. This turns out to be a one-time procedure.

image

Step 2: Create Pico template code

I then generated some C template code for the Raspberry Pi Pico, using the Raspberry Pi Pico VS Code extension. As usual, I incorporated the necessary I2C and USB console access libraries. I also decided to experiment with the optional timer feature (out of curiosity), even though this wasn't necessary for the sensor driver.

image

Once the code was generated I then amended the code to reflect the I2C pins I had used to connect the sensor to the Pico on the breadboard. In my case, I used pins 16 and 17 for I2C0.

image

Step 3: Ask Gemini for driver template code

This is where things got interesting. I prompted Gemini for assistance, using this request syntax: "Create an I2C library for the LSM303DLM sensor to read acceleration and magnetometer data", and within seconds, it provided a response directly within VS Code.

Gemini had generated code for two new library files, namely, "lsm303dlm.h" and "lsm303dlm.c," along with modified code for my main file, "Pico2W_ReadMagAccelData.c". It also provided the necessary text amendments to the CMakeLists.txt file. Even though my template code had included some timer initialisation code and a repeating "hello_world" printf statement, these were both removed in the amended Pico2W_ReadMagAccelData.c code. So if you wanted to keep, don't block copy and paste.

After the code additions/amendments, Gemini then provided a "Explanation and Key Improvements" section, detailing the steps taken in a clear, bullet-point format. I found this quite helpful.

It's worth mentioning that when I didn't specifically request a library in my prompt request, Gemini always returned a modified main project file with the added or amended functions.

Step 4: Ask Gemini to solve problems with the code

In contrast to my previous blog, the driver library code generated by Gemini Code Assist failed to compile. Gemini had included this function check If (!i2c_is_enabled(i2c){}, which resulted in the compilation error 'implicit declaration of function i2c_is_enabled()'.

I've learned from experience that if I get an 'implicit declaration' error, it almost always means that function or variable isn't in the SDK or the libraries I'm using. However, when prompting Gemini with the error message, it failed to properly check and returned another unworkable suggestion.

So, it's not just me. Even AI struggles to understand error messages. However, in this case I think it should have been fairly obvious.

It required an explicit prompt to check the SDK, before it acknowledged the error and provided a fix.

This solved the compile problem, but the code still did not work.

But, I did get a "sensor failed to initialise" error. Based on my experience, this typically indicates that this is an I2C address issue; however, definitive confirmation required reviewing the datasheets.

I was curious to see if Gemini AI would deduce the I2C address problem. However, the response received, merely highlighted the importance of precise phrasing, as Gemini merely confirmed that SA0 low address it had used was correct, rather than diagnosing the error.

I had to explicitly tell Gemini to check the datasheet before it spotted the error.

Then it finally produced some working code.

Closing remarks

I originally thought that the availability of open-source libraries for platforms like Arduino would be a significant advantage but when I did try (post these results) to get Gemini to port Arduino code across to the Pico 2 W it only introduced other errors (none of which I investigated). Hence, I was proven wrong in this instance.

Having only just begun exploring the potential of AI in embedded driver development, I'm already impressed by its possibilities. I can already see that with a well-documented SDK and a detailed sensor datasheet, AI tools like Gemini can make a significant improvement in developing drivers for sensors. And in this instance, the Raspberry Pi Pico's exceptional documentation makes it a particularly strong platform for leveraging these AI capabilities. Well done to Raspberry Pi. I'm sure they never imagined this benefit when they started.

All I can say is the future is very bright when it comes to productivity improvement. I estimated that this probably took me about 20 minutes in man effort (excluding some thinking time) to develop a new sensor driver for the RP2350 / Pico 2 W board. That is significantly quicker than anything I had done previously. The power comes not in how much code it provided, but in knowing just how much code to provide (all too often when porting any existing library across ourselves we include everything).

Truly remarkable.

  • Here's a short demo using the Arduino IDE's Serial Plotter for visualisation.

  • in reply to michaelkellett

    Ah yes. I was wondering if and where to put the code, as the emphasis of the blog was on the dev process itself. Anyway, here are the files for reference.

    lsm303dlm.h
    // lsm303dlm.h
// Note that this code was generated by Google Code Assist

#ifndef LSM303DLM_H
#define LSM303DLM_H

#include <stdint.h>
#include "hardware/i2c.h"

// LSM303DLM I2C addresses
#define LSM303DLM_ACCEL_ADDR 0x18 // SA0 low
#define LSM303DLM_MAG_ADDR   0x1E // SA0 low

// LSM303DLM Accelerometer Registers
#define LSM303DLM_ACCEL_CTRL_REG1_A 0x20
#define LSM303DLM_ACCEL_CTRL_REG4_A 0x23
#define LSM303DLM_ACCEL_OUT_X_L_A  0x28
#define LSM303DLM_ACCEL_OUT_X_H_A  0x29
#define LSM303DLM_ACCEL_OUT_Y_L_A  0x2A
#define LSM303DLM_ACCEL_OUT_Y_H_A  0x2B
#define LSM303DLM_ACCEL_OUT_Z_L_A  0x2C
#define LSM303DLM_ACCEL_OUT_Z_H_A  0x2D

// LSM303DLM Magnetometer Registers
#define LSM303DLM_MAG_CRA_REG_M    0x00
#define LSM303DLM_MAG_CRB_REG_M    0x01
#define LSM303DLM_MAG_MR_REG_M     0x02
#define LSM303DLM_MAG_OUT_X_H_M    0x03
#define LSM303DLM_MAG_OUT_X_L_M    0x04
#define LSM303DLM_MAG_OUT_Z_H_M    0x05
#define LSM303DLM_MAG_OUT_Z_L_M    0x06
#define LSM303DLM_MAG_OUT_Y_H_M    0x07
#define LSM303DLM_MAG_OUT_Y_L_M    0x08

// Accelerometer Data Structure
typedef struct {
    int16_t x;
    int16_t y;
    int16_t z;
} accel_data_t;

// Magnetometer Data Structure
typedef struct {
    int16_t x;
    int16_t y;
    int16_t z;
} mag_data_t;

// Function Prototypes
bool lsm303dlm_init(i2c_inst_t *i2c, uint sda_pin, uint scl_pin);
bool lsm303dlm_read_accel(i2c_inst_t *i2c, accel_data_t *accel_data);
bool lsm303dlm_read_mag(i2c_inst_t *i2c, mag_data_t *mag_data);

#endif // LSM303DLM_H
    lsm303dlm.c
    // lsm303dlm.c
// Note that this code was generated by Google Code Assist


#include "pico/stdlib.h"
#include "lsm303dlm.h"
#include <stdio.h>
#include "hardware/i2c.h" // Include the i2c header

// Helper function to read a register
static bool lsm303dlm_read_reg(i2c_inst_t *i2c, uint8_t addr, uint8_t reg, uint8_t *data, size_t len) {
    int ret;
    ret = i2c_write_blocking(i2c, addr, &reg, 1, true);
    if (ret < 0) return false;
    ret = i2c_read_blocking(i2c, addr, data, len, false);
    if (ret < 0) return false;
    return true;
}

// Helper function to write a register
static bool lsm303dlm_write_reg(i2c_inst_t *i2c, uint8_t addr, uint8_t reg, uint8_t data) {
    uint8_t buf[2] = {reg, data};
    int ret = i2c_write_blocking(i2c, addr, buf, 2, false);
    if (ret < 0) return false;
    return true;
}

bool lsm303dlm_init(i2c_inst_t *i2c, uint sda_pin, uint scl_pin) {
    // Initialize I2C if not already initialized
    i2c_init(i2c, 100 * 1000);
    gpio_set_function(sda_pin, GPIO_FUNC_I2C);
    gpio_set_function(scl_pin, GPIO_FUNC_I2C);
    gpio_pull_up(sda_pin);
    gpio_pull_up(scl_pin);

    // Initialize Accelerometer
    // Enable all axes, normal mode
    if (!lsm303dlm_write_reg(i2c, LSM303DLM_ACCEL_ADDR, LSM303DLM_ACCEL_CTRL_REG1_A, 0x27)) return false;

    // Set full scale to +/- 2g
    if (!lsm303dlm_write_reg(i2c, LSM303DLM_ACCEL_ADDR, LSM303DLM_ACCEL_CTRL_REG4_A, 0x00)) return false;

    // Initialize Magnetometer
    // Set continuous-measurement mode
    if (!lsm303dlm_write_reg(i2c, LSM303DLM_MAG_ADDR, LSM303DLM_MAG_MR_REG_M, 0x00)) return false;

    // Set gain to +/- 1.3 Gauss
    if (!lsm303dlm_write_reg(i2c, LSM303DLM_MAG_ADDR, LSM303DLM_MAG_CRB_REG_M, 0x20)) return false;

    // Set data rate to 15 Hz
    if (!lsm303dlm_write_reg(i2c, LSM303DLM_MAG_ADDR, LSM303DLM_MAG_CRA_REG_M, 0x14)) return false;

    return true;
}

bool lsm303dlm_read_accel(i2c_inst_t *i2c, accel_data_t *accel_data) {
    uint8_t data[6];
    // Read all 6 accelerometer registers at once
    if (!lsm303dlm_read_reg(i2c, LSM303DLM_ACCEL_ADDR, LSM303DLM_ACCEL_OUT_X_L_A | 0x80, data, 6)) return false;

    // Combine the high and low bytes
    accel_data->x = (int16_t)((data[1] << 8) | data[0]);
    accel_data->y = (int16_t)((data[3] << 8) | data[2]);
    accel_data->z = (int16_t)((data[5] << 8) | data[4]);

    return true;
}

bool lsm303dlm_read_mag(i2c_inst_t *i2c, mag_data_t *mag_data) {
    uint8_t data[6];
    // Read all 6 magnetometer registers at once
    if (!lsm303dlm_read_reg(i2c, LSM303DLM_MAG_ADDR, LSM303DLM_MAG_OUT_X_H_M, data, 6)) return false;

    // Combine the high and low bytes
    mag_data->x = (int16_t)((data[0] << 8) | data[1]);
    mag_data->z = (int16_t)((data[2] << 8) | data[3]);
    mag_data->y = (int16_t)((data[4] << 8) | data[5]);

    return true;
}
    Pico2W_ReadMagAccelData.c
    // Note that this code was primarily generated by the Raspberry Pi Pico extension 
// Google Code Assist then provided changes to the code
// Some elements were changed manually

#include <stdio.h>
#include "pico/stdlib.h"
#include "hardware/i2c.h"
#include "hardware/timer.h"
#include "pico/cyw43_arch.h"
#include "lsm303dlm.h"

// I2C defines
// This example will use I2C0 on GPIO8 (SDA) and GPIO9 (SCL) running at 400KHz.
// Pins can be changed, see the GPIO function select table in the datasheet for information on GPIO assignments
#define I2C_PORT i2c0
#define I2C_SDA 16
#define I2C_SCL 17

// create a delay using the timer method (just for fun)
bool wait_for_user = false;

int64_t alarm_callback(alarm_id_t id, void *user_data) {
    // Put your timeout handler code in here - Gemini auto inserted the state true for wait_for_user
    wait_for_user = true;
    return 0;
}


int main()
{
    stdio_init_all();

    // Initialise the Wi-Fi chip
    if (cyw43_arch_init()) {
        printf("Wi-Fi init failed\n");
        return -1;
    }

    // create a delay using the timer method (just for fun - also helps to show initial printf in serial monitor)
    // Timer example code - This example fires off the callback after 10 seconds
    add_alarm_in_ms(10000, alarm_callback, NULL, false);
    // For more examples of timer use see https://github.com/raspberrypi/pico-examples/tree/master/timer

    // Example to turn on the Pico W LED
    cyw43_arch_gpio_put(CYW43_WL_GPIO_LED_PIN, 1);


    while (wait_for_user == false) {
        sleep_ms(10);
    }

    cyw43_arch_gpio_put(CYW43_WL_GPIO_LED_PIN, 0);
    
    printf("\n\n");
    // Initialize the LSM303DLM sensor
    if (!lsm303dlm_init(I2C_PORT, I2C_SDA, I2C_SCL)) {
        printf("Failed to initialize LSM303DLM!\n");
        while (1) {
            tight_loop_contents();
        }
    }
    printf("LSM303DLM initialized successfully!\n");

    accel_data_t accel_data;
    mag_data_t mag_data;

    while (1) {
        // Read accelerometer data
        if (lsm303dlm_read_accel(I2C_PORT, &accel_data)) {
            printf("Accel: X: %6d, Y: %6d, Z: %6d\n", accel_data.x, accel_data.y, accel_data.z);
        } else {
            printf("Failed to read accelerometer data!\n");
        }

        // Read magnetometer data
        if (lsm303dlm_read_mag(I2C_PORT, &mag_data)) {
            printf("Mag:   X: %6d, Y: %6d, Z: %6d\n", mag_data.x, mag_data.y, mag_data.z);
        } else {
            printf("Failed to read magnetometer data!\n");
        }

        sleep_ms(100);
    }

}
    CMakeLists.txt
    # Generated Cmake Pico project file

cmake_minimum_required(VERSION 3.13)

set(CMAKE_C_STANDARD 11)
set(CMAKE_CXX_STANDARD 17)
set(CMAKE_EXPORT_COMPILE_COMMANDS ON)

# Initialise pico_sdk from installed location
# (note this can come from environment, CMake cache etc)

# == DO NOT EDIT THE FOLLOWING LINES for the Raspberry Pi Pico VS Code Extension to work ==
if(WIN32)
    set(USERHOME $ENV{USERPROFILE})
else()
    set(USERHOME $ENV{HOME})
endif()
set(sdkVersion 2.1.1)
set(toolchainVersion 14_2_Rel1)
set(picotoolVersion 2.1.1)
set(picoVscode ${USERHOME}/.pico-sdk/cmake/pico-vscode.cmake)
if (EXISTS ${picoVscode})
    include(${picoVscode})
endif()
# ====================================================================================
set(PICO_BOARD pico2_w CACHE STRING "Board type")

# Pull in Raspberry Pi Pico SDK (must be before project)
include(pico_sdk_import.cmake)

project(Pico2W_ReadMagAccelData C CXX ASM)

# Initialise the Raspberry Pi Pico SDK
pico_sdk_init()

# Add executable. Default name is the project name, version 0.1

add_executable(Pico2W_ReadMagAccelData Pico2W_ReadMagAccelData.c lsm303dlm.c)

pico_set_program_name(Pico2W_ReadMagAccelData "Pico2W_ReadMagAccelData")
pico_set_program_version(Pico2W_ReadMagAccelData "0.1")

# Modify the below lines to enable/disable output over UART/USB
pico_enable_stdio_uart(Pico2W_ReadMagAccelData 0)
pico_enable_stdio_usb(Pico2W_ReadMagAccelData 1)

# Add the standard library to the build
target_link_libraries(Pico2W_ReadMagAccelData
        pico_stdlib)

# Add the standard include files to the build
target_include_directories(Pico2W_ReadMagAccelData PRIVATE
        ${CMAKE_CURRENT_LIST_DIR}
        ${CMAKE_CURRENT_LIST_DIR}/.
)

# Add any user requested libraries
target_link_libraries(Pico2W_ReadMagAccelData 
        hardware_i2c
        hardware_timer
        pico_cyw43_arch_none
        )

pico_add_extra_outputs(Pico2W_ReadMagAccelData)
  • in reply to BigG

    For the inline guiding, I restrict its logic by expressing in comments everywhere what I'm trying to do, and then it sticks to that.

    Example I did last night (pasted as an image because code highlighting is missing in the editor tools for replies to this post : ( It was code to do some conversion from hex to a floating-point number.

    You can see loads of comments that I typed so that the AI had an idea of what I was trying to do. All the actual code lines were generated by AI, and 95% of the code was correct, I made a few minor tweaks where it went wrong. I would not have known that the int.from_bytes function existed in Python, and that you could pass the required endianness as a parameter to it.. very neat.

    I'm using a paid account for copilot, I don't know the difference between that and the free tier unfortunately. 

    The code still has room for improvement (there's no reason to have broadly similar repeated lines of code for instance, and multiple returns could be reduced); I can do that myself of course, or add a few more lines of comments to guide that along. (And just noticed an error in hex_bytes_to_real, the index on lines 15 and 16 is incorrect, but that function is currently untested, I have not run that function yet). 

    image

  • Could you be so kind as to post the actual generated code (or tell where I haven't looked if you already have).

    MK

  • in reply to shabaz

    Well, it's also free, so what's there not to like. Grinning

    Yes, Gemini provides (unrestricted) inline support - It's my understanding that CoPilot (free version) has limits. I've still to get used to this functionality. It likes to second guess your logic, which as you say can be helpful, but it can also be somewhat annoying as it disrupts my train of thought. For example, it's helpful for cases where say you set up a boolean variable and initialise as, say, false, and then later on in your code you have a function or condition and add that boolean it will set it as true for you.

    Another useful function of Gemini AI is that you can highlight code and then ask it to review.