Embedded Developer

One feature that I want to add to my current project is to add a small file system with files that have been built into the system at compile time. These files would then be available to the application at run time. Let’s look at how we can do can do this with NuttX.

This tutorial assumes that you have NuttX cloned and ready to build, if not then you can find out how to do this in the first article in this series.

Adding SmartFS to the Build

NuttX has a built in configuration for the PicoW with SmartFS already configured. The first thing we need to do is to start with a clean system and then configure the build to include NSH and the flash file system. Start by changing to the NuttX source directory and then executing the following commands:

make distclean
./tools/configure.sh -l raspberrypi-pico-w:nsh-flash

Now we have the system configured we can build the OS and applications by executing the following command:

make -j

This should take a minute or so on a modern machine. Now we can deploy the system to the PicoW either by using openocd or by dragging the uf2 file onto the PicoW drive. Now connect to the PicoW using a serial application and type help to show the menu of commands. You should see something like the following:

SmartFS Builtin Apps

We can check to see if the SmartFS is available checking the contents of the /dev directory with the command ls /dev. This should result in something like the following if SmartFS has been enabled correctly:

Device Directory Listing

We can mount the file system using the command mount -t smartfs /dev/smart0 /data and then check the contents of the /data directory and we should find one file in the directory, test. Checking the contents of the file with the command cat /data/test should find that it contains a single ine of text which should be Hello, world!.

So far, so good, we have built the system and proven that it contains the default file and correct contents.

Adding a New File to the System Image

The next piece of the puzzle is to work out how to add new files to the file system. This took a few hours to figure out, but here goes…

The first attempt lead me searching for RP2040_FLASH_FILE_SYSTEM in the source tree (ripgrep is a great tool for doing this). This lead to a number of possible files. Maybe we can narrow the search down a little.

Second attempt, let’s have a look for Hello, world!. This resulted in a smaller number of files leading to the file arch/arm/src/rp2040/rp2040_flash_initialize.S. This file is well documented and shows how to set up the SmartFS file system and at the end of the file it shows how to create an entry for the file we see when we list the mounted directory. Scrolling down to the end of the fie we find the following:

    sector      3, dir
    file_entry  0777, 4, 0, "test"

    sector      4, file, used=14
    .ascii      "Hello, world!\n"

    .balign     4096, 0xff
    .global     rp2040_smart_flash_end
rp2040_smart_flash_end:

This looks remarkably familiar. So what happens if we change the above to look like this:

    sector      3, dir
    file_entry  0777, 4, 0, "test"
    file_entry  0777, 5, 0, "test2"

    sector      4, file, used=14
    .ascii      "Hello, world!\n"

    sector      5, file, used=14
    .ascii      "Testing 1 2 3\n"

    .balign     4096, 0xff
    .global     rp2040_smart_flash_end
rp2040_smart_flash_end:

Building the system, deploying the code and executing the following commands:

mount -t smartfs /dev/smart0 /data
cd /data
ls

results in the following:

New file added to SmartFS

If we execute the command cat test2 we are rewarded with the output Testing 1 2 3.

Further testing shows that the file system survives through a reset. We can do the following:

• echo “My test” > test3
• rm test
• reboot

These commands should remove the file test, create a new file test3 and then reboot the system. Checking the file system contents shows that the system persists the changes through a reset.

Conclusion

This experiment was a partial success. A simple file system has been made available to an application and the file system survives a reset. One issue remains, adding new files is a little complex. It also requires changes to the NuttX source tree outside of the applications folder. This could result in changes being lost when a new version of NuttX is released.

There could be a solution, ROMFS, stay tuned for the next episode.

In the previous post, we managed to get GDB working with NuttX running on the Raspberry Pi PicoW. In this post we will look at using VSCode to debug NuttX.

For a large part of this post it was case of following Shawn Hymels guide Raspberry Pi Pico and RP2040 – C/C++ Part 2 Debugging with VS Code. This is an excellent guide and I recommend using it as a companion to this post.

We will start with the assumption that you have followed the previous post in this series and have a working NuttX build for the Raspberry Pi PicoW. We will also assume that you have a working VSCode installation with the Cortex-Debug extension installed.

Configuration Files

We will need to create (or modify) three configuration files to allow VSCode to debug NuttX.

• launch.json
• tasks.json
• settings.json

In the first article of this series we created the directory NuttX-PicoW to hold the apps and nuttx folders holding out NuttX code. This directory is the project directory or in VS Code parlance, the workspaceFolder. The workspaceFolder should also contain the Raspberry Pi PicoW SDK and the Raspberry Pi specific version of openocd.

We now add a .vscode directory to the workspaceFolder. This directory will hold the three configuration files listed above.

Start by opening VS Code and opening the workspaceFolder. This should show the four folders already in the workspaceFolder. Now create a .vscode directory in the workspaceFolder if it does not already exist.

setting.json

Only one entry is required in the settings.json file and this is the location of the openocd executable. If you have followed these posts so far this will be in the openocd/src folder. Create a setting.json file in the .vscode folder and add the following to the file.

{
    "cortex-debug.openocdPath": "${workspaceFolder}/openocd/src/openocd"
}

Note that the name of the executable may vary depending upon your operating system this post is being written from a MacOS perspective.

tasks.json

The tasks.json file holds the entry that will be used to build NuttX prior to deployment. In Shawns document the projects being worked on use the cmake system. We need to modify this to build NuttX using make. We want VS Code to use the command make -C ${workspaceFolder}/nuttx -j to build NuttX. The build task below will create a task Build NuttX to do just this:

{
    "version": "2.0.0",
    "tasks": [
        {
          "label": "Build NuttX",
          "type": "cppbuild",
          "command": "make",
          "args": [
            "-C",
            "${workspaceFolder}/nuttx",
            "-j"
          ]
        }
      ]  
}

launch.json

Of the three files we are creating, the launch.json file is the most complex. Much of the file remains the same as that presented by Shawn but there are some differences. The file used here looks like this:

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Pico Debug",
            "cwd": "${workspaceRoot}",
            "executable": "${workspaceFolder}/nuttx/nuttx.elf",
            "request": "launch",
            "type": "cortex-debug",
            "servertype": "openocd",
            "gdbPath" : "arm-none-eabi-gdb",
            "device": "RP2040",
            "configFiles": [
                "interface/cmsis-dap.cfg",
                "target/rp2040.cfg"
            ],
            "svdFile": "${workspaceFolder}/pico-sdk/src/rp2040/hardware_regs/rp2040.svd",
            "runToEntryPoint": "__start",
            "searchDir": ["${workspaceFolder}/openocd/tcl"],
            "openOCDLaunchCommands": ["adapter speed 5000"],
            "preLaunchTask": "Build NuttX"
        }
    ]
}

The following items are the ones that need to be changed:

“executable”: “${workspaceFolder}/nuttx/nuttx.elf”

This is the path to the executable that will be created by the build system. In this cse it is the NuttX ELF file. This may need to be changed to “executable”: “${workspaceFolder}/nuttx/nuttx” depending upon the output of the build system, this may simply be nuttx.

“configFiles”

The recent versions of the picoprobe software use a different interface to talk to the picoprobe. For versions 1.01 and above of the picoprobe software this interface changed from picoprobe.cfg to cmsis-dap.cfg.

“svdFile”: “${workspaceFolder}/pico-sdk/src/rp2040/hardware_regs/rp2040.svd”

We have a version of the Pico SDK specifically for our build requirements and so for this reason the location of the file is changed to reference the workspaceFolder rather than the global PICO_SDK_PATH environment variable.

“runToEntryPoint”: “__start”

This entry replaces the “runToMain”: true entry. Unlike convention C/C++ applications, NuttX does not have a main method. Having the runToMain entry generates an error stating that main cannot be found and stops at the first executable statement in our code, namely in __start. Replacing runToMain with runToEntryPoint achieves the same thing but does not generate the error.

Doing this also removes the need to have the postRestartCommands specified.

“searchDir”: [“${workspaceFolder}/openocd/tcl”]

This entry is used by openocd to look for the interface and target configuration files specified in the configFiles entry.

“openOCDLaunchCommands”: [“adapter speed 5000”]

These commands are executed by openocd when it starts. The change to the adapter speed is required and is documented in Getting Started with Raspberry Pi Pico documentation from the Raspberry Pi Foundation.

“preLaunchTask”: “Build NuttX”

The final entry tells Cortex-Debug how to build NuttX. It references the task we previously defined in the tasks.json file.

Testing

Testing this should simply be a case of saving all of the files above and pressing F5 in VS Code. If the changes have been successful then VS Code will first try to build NuttX in a Terminal window and it will then deploy NuttX to the Pico board and start the debugger. VS Code should look something like this (click on image for full view):

Debugging PicoW with VSCode

The inclusion of the SVD file allows us to examine the PicoW peripheral registers as well as the core registers:

PicoW Peripheral Registers in VSCode	Pico Cortex Registers in VSCode

Conclusion

GDB is a great debugger but it is often more convenient to use an IDE to debug your code. VS Code with the Cortex-Debug extension allow visual debugging of NuttX with a few nice additional features thrown in:

• Easily viewed call stacks for both cores.
• The SVD file allows the peripheral registers to be viewed through VS Code

We should also note that the use of VS Code resolved the issues noted at the end of the previous post as Cortex-Debug is able to deploy a binary using the picoprobe without resorting to the UF2 method of deployment. This results in a seamless build, deploy and debug process.

We have two debug options and it is now down to personal preferences as to which one to use.

At some point in the development lifecycle we will hit some unexpected application behaviour. At this point we reach for the debugger to allow us to connect to the application an interrogate the state and hopefully we will be able to determine the cause of the problem. Working with NuttX is no different from any other application. The only complication we have is connecting to application running on the PicoW requires a debug adapter. Luckily, the Raspberry Pi Foundation has an affordable solution to this problem.

Environment

The getting started guide for the Pico has instructions on how to set up the environment for Linux, Mac and Windows. This post will be following the guide for MacOS adding some hardware to allow for a stable connection between the debug probe and the PicoW.

There are two options for the debug probe:

• The Raspberry Pi debug probe
• Use a Pico programmed as a debug probe

I have a number of Pico and PicoW boards and so the later option, using a Pico programmed as a debug probe, is going to be the most cost effective and this is the route we will look at here.

Hardware

For the purpose of discussion we will use the following terms to describe the two boards:

• Picoprobe – Pico that is programmed to be a debug probe
• Target – PicoW that is running the application we wish to debug

The getting stared guide shows how two Pico boards should be connected to provide both debugging and serial console output through a UART on the target board. This shows the two boards on a breadboard setup (image is taken from the Raspberry Pi Pico getting started guide under CC-BY-ND license).

Picoprobe and Pico Fritzing

The same setup can be reproduced on protoboard. This will make the setup a little more robust and permanent. Breaking out the soldering iron and the parts bin yielded the following:

Pico on Protoboard

The flying leads are needed to connect to the SWD debug headers on the PicoW as it was not possible to connect these through to the protoboard. The black (GND) and red (5V) wires provide power to the target board. This means that we only have one connector to the system, namely to the Picoprobe but we must take care not to exceed the power capabilities of the USB connection.

The white (SWCLK) and blue (SWDIO) flying leads provide the debug connection between the two boards. As with the permanent connections above, the black lead is a GND connection.

The blue and yellow leads connected permanently to the protoboard connect the UART from the target board through to the picoprobe. The picoprobe will use the USB connection to present the host computer with a connection through to the UART on the target board.

Software

The first piece of software needed is the Picoprobe software itself. There are instruction on how to build this but I found the simplest thing to do was to download the latest release from the Picoprobe GitHub repository. At the time of writing this is version 1.0.2. The Picoprobe software is deployed to the Pico being used as a Picoprobe in the usual way, reset the Pico whilst hold the BootSel button and then drag and drop the firmware file onto the drive present to the host computer.

The next thing we need is a version of openocd that can talk to the Picoprobe. The machine I am using is used to develop software for multiple boards and so the preferable solution is to build the Raspberry Pi Pico version of openocd for this setup and then reference this locally rather than install the software globally. This is the same approach taken for the various development environment I use to prevent them interfering with each other.

Following the guide (for Mac) we need to execute the following commands:

cd ~/pico
git clone https://github.com/raspberrypi/openocd.git --branch picoprobe --depth=1 $ cd openocd
export PATH="/usr/local/opt/texinfo/bin:$PATH" 1
./bootstrap
./configure --enable-picoprobe --disable-werror 2
make -j4

Check the latest version of the guide for instructions for your OS.

Now to try openocd… This is where I hit a problem caused by having out of date documentation. Following the latest documentation we need to execute the following command:

src/openocd -f interface/cmsis-dap.cfg -f target/rp2040.cfg -c "adapter speed 5000" -s tcl

I was following I hit two errors due to the out of date documentation:

• Error: Can’t find a picoprobe device! Please check device connections and permissions.
• Error: CMSIS-DAP command CMD_DAP_SWJ_CLOCK failed.

Both of these errors were corrected by using the command above to connect to the debug probe. Moral of the story, make sure you are using the latest information. If everything goes well then we should be rewarded with something similar to the following output:

Open On-Chip Debugger 0.11.0-g4f2ae61 (2023-06-10-18:20)
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.org/doc/doxygen/bugs.html
Info : auto-selecting first available session transport "swd". To override use 'transport select <transport>'.
Info : Hardware thread awareness created
Info : Hardware thread awareness created
Info : RP2040 Flash Bank Command
adapter speed: 5000 kHz

Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : Using CMSIS-DAPv2 interface with VID:PID=0x2e8a:0x000c, serial=E66058388356A232
Info : CMSIS-DAP: SWD  Supported
Info : CMSIS-DAP: FW Version = 2.0.0
Info : CMSIS-DAP: Interface Initialised (SWD)
Info : SWCLK/TCK = 0 SWDIO/TMS = 0 TDI = 0 TDO = 0 nTRST = 0 nRESET = 0
Info : CMSIS-DAP: Interface ready
Info : clock speed 5000 kHz
Info : SWD DPIDR 0x0bc12477
Info : SWD DLPIDR 0x00000001
Info : SWD DPIDR 0x0bc12477
Info : SWD DLPIDR 0x10000001
Info : rp2040.core0: hardware has 4 breakpoints, 2 watchpoints
Info : rp2040.core1: hardware has 4 breakpoints, 2 watchpoints
Info : starting gdb server for rp2040.core0 on 3333
Info : Listening on port 3333 for gdb connections

If we have got here then we have the the debug probe programmed and we have a copy of openocd that can communicate with the picoprobe.

Reconfiguring NuttX

In previous posts we used UART over USB to communicate with the host computer. The picoprobe gives us another option, using the UART on the target board which is routed through the picoprobe. We must reconfigure NuttX in order to take advantage of the UART redirection. The configuration we want is raspberrypi-pico-w:nsh, so following the first post in this series and making the change to the configuration we need to execute the following:

make distclean
./tools/configure.sh -l raspberrypi-PicoW:nsh
make -j

At the end of this process we should have a new nuttx.uf2 file configured to use the UART port on the target board to communicate with the NuttX shell. This UF2 file can be deployed using the usual deployment process (Bootsel and reset followed by drag and dropping the file) to the target board.

At this point we should have two Pico boards programmed, one to be the picoprobe and one to be the target board (with NuttX). Now we can connect the boards (in my case using the protoboard shown above) and verify that NuttX is active and communicating through the UART.

Plugging the Pico (picoprobe) and the PicoW (target board) into the protoboard and then connecting the host computer to the picoprobe through USB presents the computer with a new serial port, usbmodem14302. Connecting to this port and hitting enter shows the nsh prompt. Asking for help shows the expected output.

nsh> help
help usage:  help [-v] [<cmd>]

    .         cat       df        free      mount     rmdir     truncate  
    [         cd        dmesg     help      mv        set       uname     
    ?         cp        echo      hexdump   printf    sleep     umount    
    alias     cmp       env       kill      ps        source    unset     
    unalias   dirname   exec      ls        pwd       test      uptime    
    basename  date      exit      mkdir     reboot    time      usleep    
    break     dd        false     mkrd      rm        true      xd        

Builtin Apps:
    nsh  sh   
nsh>

So we have a good UART connection and openocd can connect to the picoprobe.

Now we need to connect the debugger to openocd.

Debugging

To debug the board we will start with GDB, specifically arm-none-eabi-gdb-py as this has Python scripting enabled. We can use the scripting engine to automate some tasks later.

First thing to do is add a .gdbinit file to the directory we will be executing GDB from, in this case we will use the nuttx directory. The following commands should setup GDB and openocd ready for debugging. The nuttx ELF file will be loaded for us so by the time the GDB prompt is show we will have the symbol file loaded. Our .gdbinit file should look something like this:

set history save on
set history size unlimited
set history remove-duplicates unlimited
set history filename ~/.gdb_history

set output-radix 16
set mem inaccessible-by-default off

set remote hardware-breakpoint-limit 4
set remote hardware-watchpoint-limit 2

set confirm off

file nuttx
add-symbol-file -readnow nuttx

target extended-remote :3333
mon gdb_breakpoint_override hard

To debug we will need two terminal sessions open. In the first session run openocd as described above. In the second session start GDB (simply enter the command arm-none-eabi-gdb-py in the terminal session) making sure that you are in the directory containing the nuttx file and the .gdbinit file. If you are successful then you will see something like this:

GNU gdb (GDB) 13.1
Copyright (C) 2023 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-apple-darwin22.3.0".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word".
add symbol table from file "../nuttx/nuttx"

We can now start to debug the application on the board. A few simple tests, firstly, reset the board with the GDB command mon reset halt. We should see something like this:

target halted due to debug-request, current mode: Thread
xPSR: 0xf1000000 pc: 0x000000ea msp: 0x20041f00
target halted due to debug-request, current mode: Thread
xPSR: 0xf1000000 pc: 0x000000ea msp: 0x20041f00

We can now set a breakpoint, say in nsh_main (b nsh_main) and run the application to the breakpoint (c). If we then ask for information about the threads (info thre) we should see something like this:

  Id   Target Id                                           Frame
* 1    Thread 1 (Name: rp2040.core0, state: breakpoint)    nsh_main (argc=0x1, argv=0x20003170) at nsh_main.c:58
  2    Thread 2 (Name: rp2040.core1, state: debug-request) 0x000000ea in ?? ()

Conclusion

Getting debugging up and running took a little more effort than I expected but was not expensive due to the ability to use a Pico to debug a Pico. There is some excellent debugger documentation on the NuttX web site. This suggests that openocd should support NuttX however I was not able to get this working with the Raspberry Pi release of openocd. It was a question of having Pico support or NuttX support. I’m going with the Pico support for the minute.

I was hoping to use the picoprobe board to deploy the application meaning that we only have one connection between the host computer and the development hardware. A little more research is going to be necessary to see if this can be done.

So far in this series we have configured NuttX to build C++ applications on the PicoW and we have created our own custom application and successfully deployed this to the board.

In this post we will look at configuring the system to use both cores on the RP2040 processor using the configuration we have developed over the previous posts. NuttX includes a SMP configuration already, raspberrypi-pico-w:smp, this uses UART0 for communication rather than USB hence we will look at add this configuration on top of the USB configuration.

Default Configuration

It appears that the default configuration for NuttX running on the PicoW is to run the processor as a single core processor. Running the ps in the NuttX shell yields the following output:

   PID GROUP PRI POLICY   TYPE    NPX STATE    EVENT     SIGMASK           STACK COMMAND
    0     0   0 FIFO     Kthread N-- Ready              0000000000000000 001000 Idle Task
    1     1 100 RR       Task    --- Running            0000000000000000 002000 nsh_main   

From the output we see that there are only two tasks running on the system. From this we can deduce that only one of the cores is enabled. If both cores were running then we should see two Idle Tasks running, one on each core plus the nsh_main task. This is confirmed in the SMP Documentation where we find the statement:

Each CPU will have its own IDLE task.

Now we have this confirmed, let’s move on to reconfiguring the system.

Enabling SMP

According to the documentation we need set three options through the configuration system in order to turn on SMP:

• CONFIG_SMP
• CONFIG_SMP_NCPUS
• CONFIG_IDLETHREAD_STACKSIZE

Starting the configuration system with the make menuconfig we are presented with the top level options screen:

NuttX configuration system

This poses the question “How do I find CONFIG_SMP and the rest of the options?”. Luckily, kconfig has a search option, pressing the / key presents the user with a search dialog box:

Search dialog here.

Typing SMP and pressing return shows a number of results, some are relevant to use, some are not. The longer the search term the more accurate the results will be. In our case, searching for SMP yields a number of results that are irrelevant. However, the top result looks like it is the one for us:

SMP Search results image Here.

The results give us a fair amount of information about the configuration options. If we look at the top entry for SMP (this is actually the option that we need to turn on) the system is giving us the following information:

• The option name (SMP) which will translate to CONFIG_SMP in the various include files
• The location of the option, in this case RTOS Features -> Tasks and Scheduling
• In which file (and the line number) the option is defined, sched/Kconfig, line 271
• Any other options that this option depends upon.
• Any options that will be turned on as a result of selecting this option

You will also note a number in brackets at the side of Tasks and Scheduling. This is the short cut key, in this case 1 and pressing 1 will take us to the appropriate place in the configuration system.

RTOS Features options.

Selecting Tasks and Scheduling by pressing enter we are presented with the following:

Tasks and scheduling, no SMP.

Notice that there is no option to turn on SMP. Confused, so was I the first time I saw this. Pressing the ESC key a few times should take us back to the search results. Reading these more carefully we note the following:

Depends on: ARCH_HAVE_MULTICPU [=y] && ARCH_HAVE_TESTSET [=y] && ARCH_INTERRUPTSTACK [=0]!=0

So we have to ensure that three conditions are met in order to enable SMP:

• HAVE_MULTICPU is set to turned on, this looks to be the case (ARCH_HAVE_MULTICPU [=y])
• HAVE_TESTSET is turned on, again this looks to be the case (ARCH_HAVE_TESTSET [=y])
• INTERRUPTSTACK has a non-zero value, this appears to be false (ARCH_INTERRUPTSTACK [=0]!=0)

It appears that we have not met all of the conditions to activate SMP. We need to look at defining a size for the interrupt stack. So using the search system again but this time for ARCH_INTERRUPTSTACK we get the following results:

Interrupt stack search results

Pressing the 1 key takes us directory to the entry we need to change. Setting the value to 2048 should be a reasonable starting point. We can always adjust this later if we find it is causing problems.

Exiting this menu and the search for ARCH_INTERRUPTSTACK we can search for SMP again. Pressing the 1 key in the search results presents us with a different view, this time we are taken to the SMP option and we can now turn this on. If we do this the system will add some new entries to the menu, one of which defines the number of CPUs available and this is set to 4. We will need to change this value to 2.

SMP Configured image.

We are now ready to build the system.

Build and Deploy NuttX

We should now be ready to build and deploy the system to the PicoW. Executing the following command will build NuttX and create the UF2 file ready for deployment:

make clean
make -j

At the end of the build process we can deploy the UF2 file to the board by putting the board in bootloader mode and dropping the file to the drive that is shown on the host computer. Se the first article in this series for more information on how to do this.

Time to connect our serial terminal to the PicoW and run the ps command once again:

SMP Enabled ps output.

As you ca see from the screen shot above, we now have two ide tasks as expected and the ps command has some additional information, notably the CPU that each task is allocated to.

Conclusion

Adding SMP to the system was not as simple as it first sounded. The main lesson from this was to check the dependencies in the search results. The requirement for an interrupt stack was not discussed in the SMP documentation and this caused some confusion initially. The help in the configuration system came to our rescue and the situation was easily recoverable.

If you have been following the series we are now at the point where we have think about some serious development. We now have space for our own application code, C++ is enabled and we are able to use both cores on the RP2040 microcontroller.

At this point the series will slow down a little as some of the features now need some in depth investigation most notable:

• Using SMP correctly in NuttX
• Interprocess communication between tasks running on different cores
• RP2040 PIO and NuttX

So far we have seen how to deploy NuttX to a Raspberry Pi PicoW and enable C++ in NuttX. Next up we will create our own application and deploy it to the PicoW.

Creating a New Application

The build system for NuttX applications uses a a makefile that is written in such a way that all we have to do to add a new application is simply create a directory containing some template files. The easiest way to do this is to use an existing application as a template. So let us start by making a copy of the helloxx application. This can be found in the apps repository in the examples directory. So we will start by making a recursive copy of this directory and renaming it ssem.

Looking inside the ssem directory we find a number of files:

helloxx_main.cxx
Make.defs
Kconfig
Makefile

Time to start editing the files.

helloxx_main.cxx

We will start by renaming the file to represent the application name, so we will rename this to ssem_main.cxx. Now editing the file we change all occurrences of helloxx_main to ssem_main. This will allow us to verify that we have indeed deployed the application.

Makefile

Make a similar change to the Makefile by changing all occurrences of helloxx to ssem. Make changes to the comments to reflect that this application is a new application. Our Makefile should now look something like this:

include $(APPDIR)/Make.defs

# SSEM Application

MAINSRC = ssem_main.cxx

# ssem built-in application info

PROGNAME = ssem
PRIORITY = SCHED_PRIORITY_DEFAULT
STACKSIZE = $(CONFIG_DEFAULT_TASK_STACKSIZE)
MODULE = $(CONFIG_EXAMPLES_SSEM)

include $(APPDIR)/Application.mk

Make.defs

The Make.defs file conditionally adds the new application to the list of configured applications and ensures that the file will be built. This file should be edited to look something like this:

ifneq ($(CONFIG_EXAMPLES_SSEM),)
CONFIGURED_APPS += $(APPDIR)/examples/ssem
endif

Kconfig

The Kconfig file allows us to define and change application parameters, something we may look at later. For the moment it simply defines the application name and title and tells the configuration system how to turn compilation on or off. Making changes similar to the above we will have a file that contains something like this:

config EXAMPLES_SSEM
tristate "SSEM example"
default n
depends on HAVE_CXX
---help---
    Enable the SSEM application

Build the SSEM Application

Now we have set up the application we can start to reconfigure the build system and deploy the application. First thing to do is to clean the current build environment in order to make NuttX aware of the presence of the application. Issuing the command make clean will remove the previous build components.

Now we can configure the environment by issuing the make menuconfig command. This will present the configuration menuing system we saw in the previous post. So now head over to the following menu items and disable the Hello, world example and enable the SSEM example.

• Main menu -> Application Configuration -> “Hello, World!” C++ example
• Main menu -> Application Configuration -> SSEM example

We should now be ready to build the system, so execute the command make -j to build the system. The build system should show output similar to the following if the changes to the system have been made correctly:

Create version.h
LN: platform/board to /Projects/NuttX/apps/platform/dummy
Register: ssem
Register: nsh
Register: sh
CPP:  /Projects/NuttX/nuttx/boards/arm/rp2040/raspberrypi-pico-w/scripts/raspberrypi-pico-flash.ld-> /Projects/NuttX/nuttx/boards/arm/rp2040/raspberrypi-pico-w/scripts/raspberrypi-pico-flash.lLD: nuttx
Generating: nuttx.uf2
tools/rp2040/elf2uf2 nuttx nuttx.uf2;

Time to deploy NuttX to the board and check to see if the application has built correctly. So copy the NuttX.uf2 file to the board and connect a serial console to the serial port. Press enter a few times until the nsh prompt appears and now type help. The new application should appear in the list of built in applications:

Builtin Apps:
    nsh   sh    ssem  

Executing the ssem application should now present something similar to the following (depending upon how you modified the helloxx_main application code):


nsh> ssem
ssem_main: Saying hello from the dynamically constructed instance
CHelloWorld::HelloWorld: Hello, World!!
ssem_main: Saying hello from the instance constructed on the stack
CHelloWorld::HelloWorld: Hello, World!!
nsh>


Conclusion

The process of creating a new application and having this included in the NuttX build system is not a difficult task, it simply means editing a few files.

One key step is the make clean step as omitting this from a system which already contains build artefacts may not include the new application in the configuration process and hence exclude the files from the build.

In the next post we will add SMP to the configuration.

In the last article we looked at getting NuttX running on the Raspberry Pi Pico. The system deployed the default applications which are written in C. In this post we will look at enabling C++ support.

The first thing to do is to follow the instructions in the previous post to get the development system downloaded and deployed. Next up we can clean any object files that may be remaining from any previous builds:

make distclean
./tools/configure.sh -l raspberrypi-pico-w:usbnsh

Now we have a clean system wew can enabled C++ compiler support. This is done through the configuration system which is accessed by executing the command:

make menuconfig

This will show the main menu for the configuration system:

NuttX configuration system

Using the arrow and enter keys we need to navigate the menus and change the following options:

• Main menu -> Library Routines -> Have C++ compiler
• Main menu -> Application Configuration -> “Hello, World!” C++ example

Turning on the C++ compiler will show the following additional menu items:

Enable C++ compiler support

The 12.1 release of the PicoW implementation deploys some additional applications which are not needed so we will turn these off in order to save memory. The two application to be disabled are:

• ostest
• getprime

These applications can be turned off using the configuration system, the menu items can be found here:

• Application Configuration -> Testing -> OS test example
• Application Configuration -> Testing -> getprime example

The system would be ready to be built using the make -j command. Once built, deploy the application to the board by copying the UF2 file to the board as discussed in the previous post. The board should reset automatically so connect a serial console to the board and hit enter a few times to get to the nsh prompt. Typing help at the command problem should show the built in commands plus the additional commands that have been deployed:

Builtin Apps:
    helloxx  nsh      sh

Finally we should verify that the C++ application has been built and deployed correctly by running the helloxx application. If all is well then the serial console should show the following output:

helloxx_main: Saying hello from the dynamically constructed instance
CHelloWorld::HelloWorld: Hello, World!!
helloxx_main: Saying hello from the instance constructed on the stack
CHelloWorld::HelloWorld: Hello, World!!

Conclusion

This is a small step forward getting C++ enabled ready for developing a new C++ application which we will look at in the next post.

In the next post we will add a new C++ user application to the system.

Currently taking a few weeks break and after a few days away from the computer I decided to do a little bit of research into the PicoW and NuttX. So time for a quick attempt at getting the system up and running.

I have for the last few years been working on the Meadow F7 board for Wilderness Labs. This board aims to provide a full .NET development environment bringing embedded development to a wider audience. There are three main technologies underpinning this board:

• Mono
• Nuttx
• FreeRTOS

I spend much of my time working with NuttX and FreeRTOS so as you can gather, I’m not worried about working with C or C++. This gives a few options for working with the board:

• Native development using the Pico SDK
• NuttX
• FreeRTOS

I decided to start with a look at NuttX as I am currently spending a lot of time working with this RTOS.

Let’s Follow the Guide

First thing to do is head over the the documentation for NuttX on the RP2040. The getting started guide is really good and I thought I would be able to use the copy of the Pico SDK I had already on my machine.

This is where I hit my first problem. NuttX requires a specific version of the Pico SDk and using this version would impact any other Pico development that I would undertake in the future. To overcome this I decided to take a second copy of the Pico SDK specifically for use when developing with NuttX.

Having said we would follow the guide, we are deviating already.

So first up we create a development environment for the PicoW (all instructions are for working on a Mac but should also work on Linux).

mkdir NuttX-PicoW
cd NuttX-PicoW
git clone -b 1.1.2 https://github.com/raspberrypi/pico-sdk.git
export PICO_SDK_PATH=$PWD/pico-sdk

Now we need to clone the NuttX OS and applications repositories:

git clone https://github.com/apache/nuttx.git nuttx
git clone https://github.com/apache/nuttx-apps.git apps
cd nuttx

Now we have the NuttX components cloned we need to make sure we are on the current releases. This is done using git to checkout the correct branches. At the time of writing the current release is 12.1 so the following commands will checkout the correct branches:

cd apps
git checkout releases/12.1
cd ../nuttx
git checkout releases/12.1

Now we have the correct branches we need to configure the system to work with the PicoW. There are several different boards and configurations available using the RP2040, not just the pico. The following command will list all of the available board configurations available for the Pico series of boards (not just the PicoW but all of the Pico boards):

./tools/configure.sh -L | grep pico

For NuttX 12.1 this returns the following list:

raspberrypi-pico:lcd1602
raspberrypi-pico:waveshare-lcd-1.3
raspberrypi-pico:usbmsc
raspberrypi-pico:nshsram
raspberrypi-pico:nsh-flash
raspberrypi-pico:nsh
raspberrypi-pico:audiopack
raspberrypi-pico:composite
raspberrypi-pico:st7735
raspberrypi-pico:displaypack
raspberrypi-pico:spisd
raspberrypi-pico:smp
raspberrypi-pico:enc28j60
raspberrypi-pico:ssd1306
raspberrypi-pico:usbnsh
raspberrypi-pico:waveshare-lcd-1.14
raspberrypi-PicoW:lcd1602
raspberrypi-PicoW:waveshare-lcd-1.3
raspberrypi-PicoW:usbmsc
raspberrypi-PicoW:nshsram
raspberrypi-PicoW:nsh-flash
raspberrypi-PicoW:nsh
raspberrypi-PicoW:audiopack
raspberrypi-PicoW:composite
raspberrypi-PicoW:st7735
raspberrypi-PicoW:displaypack
raspberrypi-PicoW:spisd
raspberrypi-PicoW:smp
raspberrypi-PicoW:enc28j60
raspberrypi-PicoW:ssd1306
raspberrypi-PicoW:usbnsh
raspberrypi-PicoW:waveshare-lcd-1.14
raspberrypi-PicoW:telnet

The configuration that is interesting here (to get started) is the raspberrypi-PicoW:usbnsh configuration. This will redirect the console output from NuttX over USB to the host machine using serial communication. This will allow a simple terminal application to connect to the board without the need for any additional hardware. So let’s configure NuttX and build the system.

First up, clean the system and set the configuration:

make distclean
./tools/configure.sh -l raspberrypi-PicoW:usbnsh

This should clear any previous configurations (distclean) and then set the board type and specific configuration to be built.

Now we should be able to build the system.

make

You can also tell make to use as many cores on your system as possible with the command make -j. After a short time the system will compile the NuttX OS and applications and create a UF2 file that can be uploaded to the PicoW.

The board can be programmed by starting the board in bootloader mode (press and hold the BOOTSEL button while plugging in the USB cable). The Pico should now present itself as a USB drive on the host computer. Drag and drop the nuttx.uf2 file onto the Raspberry Pi Pico drive on the host computer. The file will be copied to the board and the board will restart.

Connecting to NuttX

Time to check that the board has been programmed correctly. Open your favourite terminal application and set your connection settings to 115200,n,8,1 and connect to the serial port presented by the PicoW. The default is something like usbmodem01. Connect to the PicoW and hit enter a couple of times. On doing this you should be presented with something like this:


NuttShell (NSH) NuttX-12.1.0
nsh>
nsh>


If you have got this far then you have successfully built NuttX and deployed the OS to the PicoW. Typying help in the serial console should reveal the list of deployed applications.

Conclusion

At this point we have NuttX running on the PicoW. This opens up some new channels for investigation:

• Using both cores on NuttX
• C++ application development

In the next post we will look at enabling C++ development in NuttX.

Threaded insert in pillar

Way back in 2019, Hackaday posted an article on Threading 3D Printed Parts: How to Use Heat-set Inserts which discussed how to use brass inserts in 3D printed parts to make connecting parts easier and more robust. The article presented the changes you should make to prints in order to make adding the inserts easier to locate and some of the tools that could be purchased to make using these inserts easier.

I have been using these type of inserts for a few years now and this month came up with a slight variation on the method discussed in the above article. The process of laying out the part remains the same, the change made is to the method of fixing the brass threaded insert into the 3D printed part.

The original article discussed using special tools for heating the threaded insert and pushing the heated part into the 3D printed model. This article presents an alternative to a specialist part by using nothing more than some scrap protoboard. The beauty of this technique is that it does not require any special tools.

Requirement

I regularly use a number of different microcontroller development boards and debug probes for firmware development. These boards commonly have components on the bottom of the boards and / or through hole parts where the legs of the components protrude through the board and potentially damage desks / work surfaces.

A 3D printed mount or frame keeps any components away from work surfaces protecting them from scratches and also reduces the possibility of shorting components on the boards themselves.

The process will be illustrated with a Spresense board and external adapter.

The technique should meet the following requirements:

• Use tools that any maker should have in their workshop
• Present a flat surface around the insert
• Keeps tools clear of any melted material

3D Design

The external Spresense adapter board has four mounting holes and the intention is to use two of the holes to acts as locators and two holes to fix the board in place. The mount will have four pillars under the holes in the external adapter board. Two of these will have printed pins to act as locators. Two of the pillars will use threaded inserts to allow screws to fix the board in place. A picture is worth a thousand words so here is how the final design looks:

Fusion 360 design for Spresense mount

Adding the Threaded Insert

The starting point of the process is the 3D printed frame with the objective of embedding the threaded insert securely into the printed part. The pillar is a simple cylinder with a hole running through to the base of the frame.

Pillar on mount

The first step is to prepare the threaded insert for insertion into the frame. This is done by using a screw matching the insert mating the two through a piece of protoboard:

Threaded insert on protoboard

Next up, the insert in placed in the hole in the pillar and the protoboard is used to hold the insert in place. The tip of a hot soldering iron is placed on the head of the screw and a slight pressure is applied using the protoboard:

Adding threaded insert (stage 1)

Continue applying pressure using the protoboard as the part sinks into the 3D printed part:

Adding threaded insert (stage 2)

By continuing to apply pressure, the protoboard will finally hit the top of the pillar. At which point remove the soldering iron and hold the protoboard in place for a few seconds. This will allow the PLA to set around the insert.

Adding threaded insert (stage 3)

Finally, remove the screw from the board to reveal the insert which should now be firmly embedded into the pillar.

Threaded insert in pillar

Conclusion

The technique presented uses simple tools which are available in many makers workshops or are relatively cheap to purchase. It achieves the objectives set out earlier in this post as well as those in the original Hackaday article.

Finally, here is the assembled board and mount.

Spresense external carrier board on mount

The first post about the NE555 presented the theory of operation of the NE555 using an astable clock circuit. This circuit is the basis of a simple low frequency (by todays standards) digital clock or PWM circuit. A clock can be used to synchronise the various components in a digit circuit and PWM is useful in circuits for such things as light (LED) brightness.

This post will look at how the circuit in the first post can be modified to provide a variable clock for a digital circuit. A variable clock can prove useful when debugging a digital circuit.

Basic Astable Circuit

A simple astable circuit looks something like the following:

Astable Logical Layout

The two resistors R₁, R₂ and the capacitor control the timing and characteristics of the pulses seen on the output pin of the NE555.

Timing Calculations

The timing calculations given in the data sheet for the NE555 are as follows.

Note that in the following calculations, resistance is expressed on Ohms, capacitance in Farads and time in seconds.

Charge Time

The charge time depends upon the capacitor and the two resistors R₁ and R₂ as current flows through the two resistors to charge the capacitor. The time taken to charge is given as:

t_charge = 0.693 * (R₁ + R₂) * C

Discharge Time

The discharge time is only dependent upon the capacitor and R₂ as current does not flow through R₁ when the circuit is discharging. The time take to discharge is given as:

t_discharge = 0.693 * R₂ * C

Period

The period is the sum of the two timings t_charge and t_discharge. This can be expressed as:

Period = 0.693 * (R₁ + (2 * R₂)) * C

Frequency

The frequency of a signal is defined as ¹/_Period. The period of a signal from an astable NE555 is:

Frequency = 1.44 / ((R₁ + 2 * R₂) * C)

Duty Cycle

The duty cycle of a signal is the percentage of time the signal is high compared to the period of the signal. Thus the duty cycle is given by the following formula:

Duty Cycle (%) = 100 * (R₁ + R₂) / (R₁ + 2 * R₂)

Fixed Clock

A fixed clock can be set up easily by changing one or more of the two resistors R₁, R₂ or the capacitor and a simple spreadsheet will allow you to calculate the circuit characteristics. Doing this allows for the creation of a low (by modern standards) frequency clock quickly and cheaply.

Variable Clock

A variable clock can be useful in debugging digital circuits. The ability to slow the speed of the system can allow the system to be probed easily while maintaining the ability to run the circuit using a free running clock.

As with a fixed clock, the clock characteristics can be changed by varying the value of one or more of R₁, R₂ or the capacitor.

Variable capacitors and resistors are both available but variable resistors (potentiometers) are more readily available to the hobbyist and so we will follow this option.

This gives two options, changing R₁ or R₂. Looking at the calculations above it is clear that R2 has the most impact on virtually every operating characteristic of the NE555 and is the only one that can influence the discharge time.

Looking at the t_discharge formula:

t_discharge = 0.693 * R₂ * C

the discharge time could theoretically be reduced to zero if R₂was allowed to approach 0 Ohms. This can be prevented by replacing R₂ with a combination of a fixed value resistor and a potentiometer. The fixed resistor provides for a lower limit for the discharge time of the capacitor.

A quick spreadsheet shows how the circuit will behave as R₂ and C are varied:

NE555 Calculations

From the results above it looks like a minimum value for R₂ of 1 KOhm and a maximum of 100 KOhm would give a reasonable frequency for a low speed clock.

Schematic

Lowering the value of R₂ 1 KOhm and adding a 100 KOhm potentiometer results in the following schematic:

Variable Speed Clock Schematic

The value of the fixed resistor and the potentiometer gives a range of 1 KOhm to 101 KOhm. The additional 1 KOhm of resistance should not impact the frequency too much when the potentiometer is set to its maximum resistance as the calculation is dominated by the 100 KOhm potentiometer.

So that is the theory, how does this work in practice?

Potentiometer Set to 0 Ohms

If we set the potentiometer to 0 Ohms then according to the calculations above, the frequency should be about 48 KHz. The output on the oscilloscope is:

Potentiometer set to 0 Ohm

Potentiometer Set to 100 KOhms

Changing the potentiometer to 100 KOhms we should get a frequency of 712 Hz. The output on the oscilloscope is:

Oscilloscope output when potentiometer set to 100 KOhm

And Somewhere in the Middle

By slowly changing the resistance of the potentiometer we can achieve a steady slow clock of approximately 1 kHz:

NE555 generating a 1 KHz signal

Conclusion

Clocks provide the heartbeat of most digital circuits, computers certainly require a regular pulse to synchronise the various components in the circuit. The NE555 provides a simple way to generate a variable clock albeit at low frequencies.

The output on the oscilloscope varies from the ideal values given by the calculations. This can be explained by the variations in the tolerances of the various components in the circuits and from the capacitance of the breadboard itself.

It is essential that when a computer (or any other electrical device) starts, that it starts in a known good state. For a computer, this is accomplished with a power on reset circuit. This circuit is responsible for holding the various reset signals in a known state for a defined period of time when power is applied. Some computers also utilise a reset switch to manually trigger this same reset process.

This post will look at a simple reset circuit from the 1980s using the NE555 timer.

Requirements

The circuit under consideration should perform the tasks:

1. Provide two reset signals, one high (Reset) and one low (Reset).
2. Hold the reset lines in a known state when power is applied.
3. Provide a manual reset facility.

All of the above can be achieved using a modified monostable NE555 circuit.

Schematic

The modified schematic for the monostable circuit looks like this:

NE555 Reset Circuit Schematic

The basic theory of this circuit is that a low pulse on the trigger pin generates a single shot pulse on the output pin of the NE555.

The resistor and capacitor in the right-hand part of the circuit form a standard monostable configuration. This circuit is taken from the NE555 datasheet. Using the formula in the datasheet, the period of the stable, high pulse on the output is given by the formula:

Period = 1.1 * R * C

Using the values in the circuit, R = 47K and C = 10uF. Plugging these values into the equation we find that the period of the stable pulse is 0.517 seconds.

The inverter provided by the 74LS04 allows for the generation of both a high and a low (Reset and Reset) signals from the circuit.

The resistor and capacitor on the left hand side of the circuit debounce the switch connected to the trigger of the circuit. They also hold the trigger under the 1.67V threshold for a short period of time following startup. This provides the power on reset element of the circuit.

This circuit can also be viewed using the logical layout discussed in the previous aricle on the theory of operation:

NE555 Logical Layout

Implementation

Putting the above circuit together on breadboard gives something like the following:

NE555 Reset Circuit on Breadboard

Observations

In the following, all images from the oscilloscope will show the NE555 output in yellow and where present, the signal on the trigger pin will be in blue.

At startup, it is expected that there should be a short (500ms approx) signal on the output pin of the NE555.

NE555 Power on Reset Oscilloscope Output

So far, so good. The next requirement is to allow the user to manually reset the system. This is done using the switch connected to the trigger pin on the NE555. Pressing the button shows the following on the oscilloscope:

NE555 Reset Circuit Short Button Press

The short press on the button generates the required reset pulse on the output pin of the NE555.

The datasheet for the NE555 warns against holding the trigger pin low for a period of time longer than the duration of the output pulse. So in this case, the trigger pin should not be held low for longer than 517ms. This could be a problem as it is easy to exceed this period in normal use. So what happens if the trigger pin is held low for an extended period of time? Changing the scale on the oscilloscope to 250ms per division and we see the following:

NE555 Reset Circuit Multiple Button Presses on Oscilloscope

The leftmost pulse is the result of a short press of the button. As expected, the output of the NE555 goes high for 517ms.

The middle pulse shows what happens when the button is pressed and held for an extended period of time. In this case, the button was pressed for about 2s. As you can see, the reset pulse remains high for the duration of the button press and then returns low.

The rightmost pulse shows what happens when the switch is pressed once more for a short period. As you can see, the NE555 returns to its normal mode of operation and generates a 517ms pulse.

Conclusion

The NE555 really does deserve it’s reputation as a versatile chip. This simple circuit provides a digital circuit with the ability to start in a known state by providing a reset pulse when power is applied to the system. It also provides a mechanism for resetting a system on demand using a switch connected to the trigger pin.

And now for a piece of history, circuits such as this appeared in many of the early 8-bit computers from the 1980s.