Code Monkey home page Code Monkey logo

pico-sdk's Introduction

Raspberry Pi Pico SDK

The Raspberry Pi Pico SDK (henceforth the SDK) provides the headers, libraries and build system necessary to write programs for the RP2040-based devices such as the Raspberry Pi Pico in C, C++ or assembly language.

The SDK is designed to provide an API and programming environment that is familiar both to non-embedded C developers and embedded C developers alike. A single program runs on the device at a time and starts with a conventional main() method. Standard C/C++ libraries are supported along with C level libraries/APIs for accessing all of the RP2040's hardware include PIO (Programmable IO).

Additionally the SDK provides higher level libraries for dealing with timers, synchronization, USB (TinyUSB) and multi-core programming along with various utilities.

The SDK can be used to build anything from simple applications, to fully fledged runtime environments such as MicroPython, to low level software such as RP2040's on-chip bootrom itself.

Additional libraries/APIs that are not yet ready for inclusion in the SDK can be found in pico-extras.

Documentation

See Getting Started with the Raspberry Pi Pico for information on how to setup your hardware, IDE/environment and for how to build and debug software for the Raspberry Pi Pico and other RP2040-based devices.

See Connecting to the Internet with Raspberry Pi Pico W to learn more about writing applications for your Raspberry Pi Pico W that connect to the internet.

See Raspberry Pi Pico C/C++ SDK to learn more about programming using the SDK, to explore more advanced features, and for complete PDF-based API documentation.

See Online Raspberry Pi Pico SDK API docs for HTML-based API documentation.

Example code

See pico-examples for example code you can build.

Getting the latest SDK code

The master branch of pico-sdk on GitHub contains the latest stable release of the SDK. If you need or want to test upcoming features, you can try the develop branch instead.

Quick-start your own project

These instructions are extremely terse, and Linux-based only. For detailed steps, instructions for other platforms, and just in general, we recommend you see Raspberry Pi Pico C/C++ SDK

  1. Install CMake (at least version 3.13), and GCC cross compiler

    sudo apt install cmake gcc-arm-none-eabi libnewlib-arm-none-eabi libstdc++-arm-none-eabi-newlib
    
  2. Set up your project to point to use the Raspberry Pi Pico SDK

    • Either by cloning the SDK locally (most common) :

      1. git clone this Raspberry Pi Pico SDK repository

      2. Copy pico_sdk_import.cmake from the SDK into your project directory

      3. Set PICO_SDK_PATH to the SDK location in your environment, or pass it (-DPICO_SDK_PATH=) to cmake later.

      4. Setup a CMakeLists.txt like:

        cmake_minimum_required(VERSION 3.13)
        
        # initialize the SDK based on PICO_SDK_PATH
        # note: this must happen before project()
        include(pico_sdk_import.cmake)
        
        project(my_project)
        
        # initialize the Raspberry Pi Pico SDK
        pico_sdk_init()
        
        # rest of your project
        
    • Or with the Raspberry Pi Pico SDK as a submodule :

      1. Clone the SDK as a submodule called pico-sdk

      2. Setup a CMakeLists.txt like:

        cmake_minimum_required(VERSION 3.13)
        
        # initialize pico-sdk from submodule
        # note: this must happen before project()
        include(pico-sdk/pico_sdk_init.cmake)
        
        project(my_project)
        
        # initialize the Raspberry Pi Pico SDK
        pico_sdk_init()
        
        # rest of your project
        
    • Or with automatic download from GitHub :

      1. Copy pico_sdk_import.cmake from the SDK into your project directory

      2. Setup a CMakeLists.txt like:

        cmake_minimum_required(VERSION 3.13)
        
        # initialize pico-sdk from GIT
        # (note this can come from environment, CMake cache etc)
        set(PICO_SDK_FETCH_FROM_GIT on)
        
        # pico_sdk_import.cmake is a single file copied from this SDK
        # note: this must happen before project()
        include(pico_sdk_import.cmake)
        
        project(my_project)
        
        # initialize the Raspberry Pi Pico SDK
        pico_sdk_init()
        
        # rest of your project
        
    • Or by cloning the SDK locally, but without copying pico_sdk_import.cmake:

      1. git clone this Raspberry Pi Pico SDK repository

      2. Setup a CMakeLists.txt like:

        cmake_minimum_required(VERSION 3.13)
        
        # initialize the SDK directly
        include(/path/to/pico-sdk/pico_sdk_init.cmake)
        
        project(my_project)
        
        # initialize the Raspberry Pi Pico SDK
        pico_sdk_init()
        
        # rest of your project
        
  3. Write your code (see pico-examples or the Raspberry Pi Pico C/C++ SDK documentation for more information)

    About the simplest you can do is a single source file (e.g. hello_world.c)

    #include <stdio.h>
    #include "pico/stdlib.h"
    
    int main() {
        setup_default_uart();
        printf("Hello, world!\n");
        return 0;
    }

    And add the following to your CMakeLists.txt:

    add_executable(hello_world
        hello_world.c
    )
    
    # Add pico_stdlib library which aggregates commonly used features
    target_link_libraries(hello_world pico_stdlib)
    
    # create map/bin/hex/uf2 file in addition to ELF.
    pico_add_extra_outputs(hello_world)

    Note this example uses the default UART for stdout; if you want to use the default USB see the hello-usb example.

  4. Setup a CMake build directory. For example, if not using an IDE:

    $ mkdir build
    $ cd build
    $ cmake ..
    

    When building for a board other than the Raspberry Pi Pico, you should pass -DPICO_BOARD=board_name to the cmake command above, e.g. cmake -DPICO_BOARD=pico_w .. to configure the SDK and build options accordingly for that particular board.

    Doing so sets up various compiler defines (e.g. default pin numbers for UART and other hardware) and in certain cases also enables the use of additional libraries (e.g. wireless support when building for PICO_BOARD=pico_w) which cannot be built without a board which provides the requisite functionality.

    For a list of boards defined in the SDK itself, look in this directory which has a header for each named board.

  5. Make your target from the build directory you created.

    $ make hello_world
  6. You now have hello_world.elf to load via a debugger, or hello_world.uf2 that can be installed and run on your Raspberry Pi Pico via drag and drop.

pico-sdk's People

Contributors

4ilo avatar alastairpatrick avatar andygpz11 avatar arturo182 avatar bruelltuete avatar cmfcmf avatar dusterthefirst avatar earlephilhower avatar engineerwill avatar facchinm avatar fivdi avatar flaviut avatar foopub avatar hathach avatar jamesh65 avatar jeremygrosser avatar jkomlodi avatar jonathangjertsen avatar kilograham avatar kkitayam avatar liamfraser avatar lurch avatar majbthrd avatar monocasa avatar mrgreensworkshop avatar peterharperuk avatar reneg973 avatar usedbytes avatar wren6991 avatar zodiusinfuser avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

pico-sdk's Issues

"Always true" comparison

With warnings on, gcc will complain that:

assert(lock_num >= 0 && lock_num < NUM_SPIN_LOCKS);

error: comparison of unsigned expression >= 0 is always true [-Werror=type-limits]
   25 |     assert(lock_num >= 0 && lock_num < NUM_SPIN_LOCKS);

which is indeed true. Perhaps a little picky, but by definition the unsigned parameter lock_num is >= 0.

Ditto in lock_core.c:10

NMAKE Fails to Build the Project

Well, we have a new problem and I couldn't find anybody referenced this in any reported issues.

Setup : VS Code, Windows 10 x64.

Tried building the examples from Developer Command Prompt for VC 2019. NMake makefile generation was success, but building from them failed with the following output.

C:\Pico\pico-examples\build>nmake

Microsoft (R) Program Maintenance Utility Version 14.28.29336.0
Copyright (C) Microsoft Corporation.  All rights reserved.

Scanning dependencies of target bs2_default
[  0%] Building ASM object pico_sdk/src/rp2_common/boot_stage2/CMakeFiles/bs2_default.dir/boot2_w25q080.S.obj
[  0%] Linking ASM executable bs2_default.elf
[  0%] Built target bs2_default
Scanning dependencies of target bs2_default_bin
[  0%] Generating bs2_default.bin
[  0%] Built target bs2_default_bin
Scanning dependencies of target bs2_default_padded_checksummed_asm
[  0%] Generating bs2_default_padded_checksummed.S
[  0%] Built target bs2_default_padded_checksummed_asm
Scanning dependencies of target ELF2UF2Build
[  0%] Creating directories for 'ELF2UF2Build'
[  0%] No download step for 'ELF2UF2Build'
[  0%] No update step for 'ELF2UF2Build'
[  0%] No patch step for 'ELF2UF2Build'
[  0%] Performing configure step for 'ELF2UF2Build'
-- The C compiler identification is MSVC 19.28.29336.0
-- The CXX compiler identification is MSVC 19.28.29336.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - failed
-- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio/2019/BuildTools/VC/Tools/MSVC/14.28.29333/bin/Hostx86/x86/cl.exe
-- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio/2019/BuildTools/VC/Tools/MSVC/14.28.29333/bin/Hostx86/x86/cl.exe - broken
CMake Error at C:/Program Files/CMake/share/cmake-3.19/Modules/CMakeTestCCompiler.cmake:66 (message):
  The C compiler

    "C:/Program Files (x86)/Microsoft Visual Studio/2019/BuildTools/VC/Tools/MSVC/14.28.29333/bin/Hostx86/x86/cl.exe"

  is not able to compile a simple test program.

  It fails with the following output:

    Change Dir: C:/Pico/pico-examples/build/elf2uf2/CMakeFiles/CMakeTmp

    Run Build Command(s):nmake /nologo cmTC_171d1\fast &&       "C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\VC\Tools\MSVC\14.28.29333\bin\HostX86\x86\nmake.exe"  -f CMakeFiles\cmTC_171d1.dir\build.make /nologo -L                  CMakeFiles\cmTC_171d1.dir\build
    Building C object CMakeFiles/cmTC_171d1.dir/testCCompiler.c.obj
        C:\PROGRA~2\MICROS~2\2019\BUILDT~1\VC\Tools\MSVC\1428~1.293\bin\Hostx86\x86\cl.exe @C:\Users\VISHNU~1\AppData\Local\Temp\nm9649.tmp
    testCCompiler.c
    Linking C executable cmTC_171d1.exe
        "C:\Program Files\CMake\bin\cmake.exe" -E vs_link_exe --intdir=CMakeFiles\cmTC_171d1.dir --rc=rc --mt=CMAKE_MT-NOTFOUND --manifests -- C:\PROGRA~2\MICROS~2\2019\BUILDT~1\VC\Tools\MSVC\1428~1.293\bin\Hostx86\x86\link.exe /nologo @CMakeFiles\cmTC_171d1.dir\objects1.rsp @C:\Users\VISHNU~1\AppData\Local\Temp\nm9698.tmp
    RC Pass 1: command "rc /fo CMakeFiles\cmTC_171d1.dir/manifest.res CMakeFiles\cmTC_171d1.dir/manifest.rc" failed (exit code 0) with the following output:
    The system cannot find the file specifiedNMAKE : fatal error U1077: '"C:\Program Files\CMake\bin\cmake.exe"' : return code '0xffffffff'
    Stop.
    NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\VC\Tools\MSVC\14.28.29333\bin\HostX86\x86\nmake.exe"' : return code '0x2'
    Stop.





  CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
  CMakeLists.txt:2 (project)


-- Configuring incomplete, errors occurred!
See also "C:/Pico/pico-examples/build/elf2uf2/CMakeFiles/CMakeOutput.log".
See also "C:/Pico/pico-examples/build/elf2uf2/CMakeFiles/CMakeError.log".
NMAKE : fatal error U1077: 'echo' : return code '0x1'
Stop.
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\VC\Tools\MSVC\14.28.29333\bin\HostX86\x86\nmake.exe"' : return code '0x2'
Stop.
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\VC\Tools\MSVC\14.28.29333\bin\HostX86\x86\nmake.exe"' : return code '0x2'
Stop.

The same error appears when trying to build with VS Code also. Looks like some "not found" error. What could be wrong ?

Reading from the error log, the culprit could be,

LINK : fatal error LNK1104: cannot open file 'kernel32.lib'

CMakeError.log
CMakeOutput.log

uart_set_baudrate() reports success for out-of-range baud rates

Section 4.2.3.1 of the RP2040 data sheet details limits on the possible baud rates for a given UARTCLK frequency. The code in uart_set_baudrate() has a check for this, but only in an invalid_params_if() macro, which does nothing if asserts are not enabled. In release builds with asserts off, the function goes ahead and programs the baud rate incorrectly, but returns a baud rate approximately equal to the requested baud rate, falsely indicating success.

For example, if I ask for 100 baud, I get an actual baud rate of about 621 (measured on hardware), but uart_set_baudrate() returns 100.

It should either calculate the actual baud rate programmed and return that, or else it should refuse to change the baudrate at all and return a flag value like 0, or the old baud rate. Or, perhaps, the API should change to not return a value at all.

Documentation for UART should list the range of valid baud rates for default/common value(s) of the peripheral clock (clk_peri) frequency. Ideally it should also include a description of how (or whether) to slow down clk_peri in order to achieve low baud rates, and possibly a pointer to PIO as an alternative.

pioasm/pioasm.exe is missing and no known rule to make it

I was trying to build the examples from VS Code and encountered the following error.

[main] Building folder: pico-examples 
[main] Configuring folder: pico-examples 
[proc] Executing command: "C:\Program Files\CMake\bin\cmake.EXE" --no-warn-unused-cli -DCMAKE_EXPORT_COMPILE_COMMANDS:BOOL=TRUE -DCMAKE_BUILD_TYPE:STRING=Debug -Hc:/Pico/pico-examples -Bc:/Pico/pico-examples/build -G Ninja
[cmake] Not searching for unused variables given on the command line.
[cmake] Using PICO_SDK_PATH from environment ('C:\Pico\pico-sdk')
[cmake] Pico SDK is located at C:/Pico/pico-sdk
[cmake] Defaulting PICO_PLATFORM to rp2040 since not specified.
[cmake] Defaulting PICO platform compiler to pico_arm_gcc since not specified.
[cmake] PICO compiler is pico_arm_gcc
[cmake] PICO_GCC_TRIPLE defaulted to arm-none-eabi
[cmake] -- The C compiler identification is GNU 9.3.1
[cmake] -- The CXX compiler identification is GNU 9.3.1
[cmake] -- The ASM compiler identification is GNU
[cmake] -- Found assembler: C:/Program Files (x86)/GNU Arm Embedded Toolchain/9 2020-q2-update/bin/arm-none-eabi-gcc.exe
[cmake] Using regular optimized debug build (set PICO_DEOPTIMIZED_DEBUG=1 to de-optimize)
[cmake] Defaulting PICO target board to pico since not specified.
[cmake] Using board configuration from C:/Pico/pico-sdk/src/boards/include/boards/pico.h
[cmake] -- Found Python3: C:/Users/Vishnu Mohanan/AppData/Local/Programs/Python/Python39/python.exe (found version "3.9.1") found components: Interpreter 
[cmake] TinyUSB available at C:/Pico/pico-sdk/lib/tinyusb/src/portable/raspberrypi/rp2040; adding USB support.
[cmake] Compiling TinyUSB with CFG_TUSB_DEBUG=1
[cmake] -- Could NOT find Doxygen (missing: DOXYGEN_EXECUTABLE) 
[cmake] ELF2UF2 will need to be built
[cmake] PIOASM will need to be built
[cmake] -- Configuring done
[cmake] -- Generating done
[cmake] -- Build files have been written to: C:/Pico/pico-examples/build
[build] Starting build
[proc] Executing command: "C:\Program Files\CMake\bin\cmake.EXE" --build c:/Pico/pico-examples/build --config Debug --target all -- -j 18
[build] ninja: error: 'pioasm/pioasm.exe', needed by 'adc/dma_capture/CMakeFiles/adc_dma_capture_resistor_dac_pio_h', missing and no known rule to make it
[build] Build finished with exit code 1

All dependencies are installed with correct path variables. The machine is Windows 10.

VS Code was opened from "Developer Command Prompt for VS 2019" as mentioned in the getting started document.

pioasm python IN command generated incorrectly

I built pioasm in ~/pico/pico-sdk/tools/pioasm/build

Its python output is wrong for the IN command. it generates "in", but it should be "in_".

Example: input file blah:

.program blah

.wrap_target
bitloop:
        IN pins, 1
.wrap

Running pioasm -o python blah generates:

# -------------------------------------------------- #
# This file is autogenerated by pioasm; do not edit! #
# -------------------------------------------------- #

import rp2
from machine import Pin
# ---- #
# blah #
# ---- #

@rp2.asm_pio()
def blah():
    wrap_target()
    in(pins, 1)                           # 0
    wrap()

The problem is that the line in(pins,1 should read in_(pins,1).

Pico SPI in master mode asserts/deasserts chip select around every byte sent

This behaviour breaks SPI chips which expect the complete transaction to be framed by chip select assert/deassert.

E.g. To request a reading from a MCP3008 on channel 0 you might send the bytes 0x01, 0x80, 0x00. A CS deassert after 0x01 makes the MCP3008 think the command has been cancelled.

A workaround is to leave CS in SIO (rather than SPI) mode and toggle the line in software.

This appears to be a known bug/feature as the SPI C examples bme280_spi, mpu9250_spi, and spi_flash each toggle CS in software.

Why does second stage bootloader not set VTOR and SP?

Having to make 0x100 in flash a function as opposed to a vector table complicates the use of other programming languages and SDKs, which assume flash starts with a vector table.

Is there a reason why the second stage bootloader doesn't set VTOR to 0x1000_0100, SP to [0x1000_0100] and then jump to [0x1000_0104]?

Python code generated by pioasm does is not correct

python code generated using the -o python option in pioasm generates incorrect code

example mov isr ~x
generates the python code mov(isr, not x) which does not give the expected result

the correct code should be mov(irs, invert(x))

mutex_init() fails to initialize the 'owned' field

mutex_init() fails to initialize the 'owned' field of mutex_t. So a malloc'ed mutex or a mutex on the stack is likely to be locked (owned != 0) after mutex_init.

Also 'owner' is not initialized. It might make sense to '#ifndef NDEBUG' initialize it to -1 (like mutex_exit).

Add CMSIS-Core headers

Please add standard CMSIS-Core headers and register definitions. Ideally these would replace the bespoke headers to avoid fracturing of the ecosystem.

The common CMSIS header files are here. It's not uncommon to include the entire CMSIS_5 repo as a submodule, and it's just as common to copy the headers into your SDK.

CMSIS-Core documentation

CMSIS-standard register definitions can be generated with the SVDConv utility.

No CMAKE_CXX_COMPILER could be found

ELF2UF2 will need to be built
-- Could NOT find Doxygen (missing: DOXYGEN_EXECUTABLE)
-- Configuring done
-- Generating done
-- Build files have been written to: /home/apache/github/pico-sdk
apache@ubuntu20:~/github/pico-sdk$ make
[ 0%] Built target bs2_default
[ 0%] Performing configure step for 'ELF2UF2Build'
-- The CXX compiler identification is unknown
CMake Error at CMakeLists.txt:2 (project):
No CMAKE_CXX_COMPILER could be found.

Tell CMake where to find the compiler by setting either the environment
variable "CXX" or the CMake cache entry CMAKE_CXX_COMPILER to the full path
to the compiler, or to the compiler name if it is in the PATH.

-- Configuring incomplete, errors occurred!
See also "/home/apache/github/pico-sdk/elf2uf2/CMakeFiles/CMakeOutput.log".
See also "/home/apache/github/pico-sdk/elf2uf2/CMakeFiles/CMakeError.log".
make[2]: *** [test/pico_stdlib_test/CMakeFiles/ELF2UF2Build.dir/build.make:107:test/pico_stdlib_test/elf2uf2/src/ELF2UF2Build-stamp/ELF2UF2Build-configure]

FPGA related code still needed?

I was looking at blink..dis and found:
10000460 <running_on_fpga>:
10000460: 4b02 ldr r3, [pc, #8] ; (1000046c <running_on_fpga+0xc>)
10000462: 6818 ldr r0, [r3, #0]
10000464: 0780 lsls r0, r0, #30
10000466: 0fc0 lsrs r0, r0, #31
10000468: 4770 bx lr
1000046a: 46c0 nop ; (mov r8, r8)
1000046c: 4006c000 .word 0x4006c000

It is defined here:

bool running_on_fpga() {

and is called here:

if (running_on_fpga()) {

What to do?

add define like RUNNING_ON_FPGA
remove FPGA referring code?
leave in for debug and remove for release?
or?

boot stage2: double reset to uf2

Hi hi, thank you for the pico.

It is great to have uf2 built into the bootrom, as maintainer of similar tinyuf2 (cross-platform uf2 bootloader), I kind of miss the double tap on reset button to enter uf2 feature. Which set a sram location to a magic number and wait for 0.5 second. If another reset occurs (double reset) during wait time then mcu will enter uf2 mode as following code does:

https://github.com/adafruit/tinyuf2/blob/master/src/main.c#L84

  • pros: it requires only 1 button (RST) for small form factor PCB and in general easier to operate than press reset and hold BOOTSEL.
  • cons: it does introduce additional 0.5s to boot process.

I wonder if RPI would be interested in adding this feature, my approach would be modify boot stage2 for double reset detection then use watchdog reset to jump to UF2. https://github.com/raspberrypi/pico-sdk/tree/master/src/rp2_common/boot_stage2

Thanks

Technical issues in Doxygen configuration

I encountered a couple of smaller Doxygen issues while attempting to build the SDK documentation locally. The proposed fixes are small, but took some fiddling to get right. Everything was tested in the following environment:

  • OSX Catalina
  • Doxygen v1.9.1
  • Cmake v3.19.2
  • Pico SDK v1.0.1

Stray tag in DoxygenLayout.xml

There's a stray <tab> tag in DoxygenLayout.xml, probably copy-pasted from the <navindex> section. The documentation builds fine, but Doxygen issues a warning.

--- DoxygenLayout.xml	2021-02-03 23:20:40.000000000 +0100
+++ DoxygenLayout.xml	2021-02-04 23:11:51.000000000 +0100
@@ -146,8 +146,7 @@
   </namespace>

   <!-- Layout definition for a file page -->
-  <file>    <tab type="modules" visible="yes" title="Libraries" intro="Here is a list of all the libraries supported in the Raspberry Pi Pico SDK"/>
-
+  <file>
     <briefdescription visible="yes"/>
     <includes visible="$SHOW_INCLUDE_FILES"/>
     <includegraph visible="$INCLUDE_GRAPH"/>

Missing briefs

The current configuration does not pick up briefs for most groups. The resulting API overview page looks like this:

Screenshot 2021-02-05 at 12 03 52

This can be fixed by adding JAVADOC_AUTOBRIEF = YES to Doxyfile.in. Alternatively, the \brief annotation could be added to the source code documentation.

Configured project number is overwritten

The variable PROJECT_NUMBER is defined twice in Doxyfile.in. The resulting version number is hard-coded to 1.0.

PROJECT_NUMBER         = @VERSION_MAJOR@.@VERSION_MINOR@.@VERSION_PATCH@
PROJECT_NUMBER = 1.0

Code fragments are formated in a variable-width font

This problem can be fixed with small tweaks to the style sheet:

--- main.css	2021-02-03 23:20:40.000000000 +0100
+++ main.css	2021-02-04 23:54:25.000000000 +0100
@@ -7,7 +7,7 @@
 }

 h1, h2, h3, h4, h5, h6, p, a, li, span, blockquote, input, textarea, select, label {
-    font-family: 'Roboto', sans-serif !important;
+    font-family: 'Roboto', sans-serif;
 }

 p {

@@ -98,4 +100,8 @@
 }


-
+div.line,
+div.line a,
+div.line span {
+	font-family: monospace;
+}

Inconsistent Function Names

Various function names seem (at least to me) to have inconsistent names.
Examples:

  • pio_sm_set_enabled() vs. pio_set_sm_mask_enabled():
    For the latter, I would have expected "pio_sm_set_mask_enabled()"
    (or, looking at the examples below, even "pio_sm_set_enabled_mask()").
  • pio_sm_restart() vs. pio_restart_sm_mask():
    For the latter, I would have expected "pio_sm_restart_mask()".
  • pio_sm_clkdiv_restart() vs. pio_clkdiv_restart_sm_mask():
    For the latter, I would have expected "pio_sm_clkdiv_restart_mask()".
  • pio_sm_claim() vs. pio_claim_sm_mask():
    For the latter, I would have expected "pio_sm_claim_mask()".
  • pio_sm_unclaim() vs. pio_claim_unused_sm():
    For the latter, I would have expected "pio_sm_claim_unused()".

But maybe it is already too late for such changes, as possibly thousands of people have already started to make use of the API and expect stability?

Callback use of user_data is inconsistent or unavailable across SDK

The use of user_data in callbacks is of importance because it can allow callback to a class method when using C++/OOP via a non capturing Lambda function, which is great.

There is an inconsistency with how the user_data is implemented or if it is implemented in some cases.
The two different schemes are the alarm scheme where user_data is passed as a second argument to the callback:

typedef int64_t (*alarm_callback_t)(alarm_id_t id, void *user_data);

And the repeating timer scheme where the user_data is passed to the callback inside the repeating_timer_t:

typedef bool (*repeating_timer_callback_t)(repeating_timer_t *rt);
struct repeating_timer {
    int64_t delay_us;
    alarm_pool_t *pool;
    alarm_id_t alarm_id;
    repeating_timer_callback_t callback;
    void *user_data;
};

Having a consistent scheme between the two would be great, with the alarm scheme being more idiomatic from what I can tell.

Also of concern is the lack of user_data on the following callbacks and types.

typedef void (*gpio_irq_callback_t)(uint gpio, uint32_t events); 

typedef void(* resus_callback_t )(void);

typedef void (*rtc_callback_t)(void);

typedef void(* hardware_alarm_callback_t )(uint alarm_num)

With the lack on IRQs my primary concern as it makes for example a Sensor class for a hall effect sensor difficult.

pico_time/time.c using GPIO pins

I've been having a problem with calls to functions in time.c (eg. sleep_ms()) having side effects on GPIO pins.

I'm pretty sure this is related to the DEBUG_PINS macros; changing #define PICO_DEBUG_PIN_BASE 19u in src/rp2_common/hardware_gpio/include/hardware/gpio.h to something else changes the GPIO pins that are affected. (My project is using GPIO 21 as an output, which is how I discovered this.)

I don't immediately see how to turn this off!

set_sys_clock_khz() cannot be called multiple times

For automatically determining maximal overclock frequency, too high clock frequencies need to be tested (binary search). I stripped down my code to very short example demonstrating the inconsistent behavior for frequency 424000 KHz.

Minicom output:

Press CTRL-A Z for help on special keys

tud_cdc_connected()
foobar
ok
40_000,424000,440000
408000,424000,440000

*** PANIC ***

System clock of 424000 kHz cannot be exactly achiev

The ok output shows that set_sys_clock_khz(424000, false) returned true.
But calling set_sys_clock_khz(424000, true) afterwards results in assert(panic).

Code:

#include "pico/stdlib.h"
#include "hardware/vreg.h"
#include <tusb.h>

#define N 1000000

int main() {
    stdio_init_all();
    while (!tud_cdc_connected()) { sleep_ms(100);  }
    printf("tud_cdc_connected()\n");

    gpio_init(3);  gpio_set_dir(3, GPIO_OUT);

    vreg_set_voltage(VREG_VOLTAGE_1_30);
    sleep_ms(1);

    int mi, lo = 408000, hi = 440000;
    do
    {
      set_sys_clock_48mhz(); sleep_ms(200); printf("foobar\n");

      mi = (lo+hi)/2;
      if (set_sys_clock_khz(mi, false))
        printf("ok\n");

      printf("%d,%d,%d\n",lo,mi,hi);
      printf("%d,%d,%d\n",lo,mi,hi);
      fflush(stdout);
      set_sys_clock_khz(mi, true);
    }
    while (hi-lo>1);

    printf("done\n");
}

I need to figure out if a I can set system clock to a specific value. In case above behavior is considered OK (hopefully not), another function is needed to query whether setting system clock with 2nd argument true would panic or not.

Unable to download the SDK

Hello dear maintainers , I am unable to download the SDK. Please help.
This command works:
git clone -b master https://github.com/raspberrypi/pico-sdk.git
but when I enter git submodule update --init
It ends with no success.

Failed to clone 'lib/tinyusb'. Retry scheduled
Cloning into 'D:/Education/Tutorials/raspberry pi pico/sdk_examples/pico-sdk/lib/tinyusb'...

Rust Pico SDK

Hello!
I am about to implement this library with rust.
Are there any helpful suggestions and tips? I thought about making it an FFI but decided to make it pure rust.
Also the name pico-sdk-rs sounds like a fine name?

Multiple missing 'extern "C"'

The following header files are all missing __cplusplus ifdef'ed 'extern "C"'

src/rp2_common/hardware_claim/include/hardware/claim.h
src/rp2_common/hardware_divider/include/hardware/divider.h
src/rp2_common/hardware_flash/include/hardware/flash.h
src/rp2_common/hardware_rtc/include/hardware/rtc.h
src/rp2_common/hardware_watchdog/include/hardware/watchdog.h
src/rp2_common/pico_bootrom/include/pico/bootrom.h
src/rp2_common/pico_stdio_semihosting/include/pico/stdio_semihosting.h
src/rp2_common/pico_stdio_uart/include/pico/stdio_uart.h
src/rp2_common/pico_stdio_usb/include/pico/stdio_usb.h

Also the following header-only files ... might want to add it for consistency:

src/rp2_common/hardware_base/include/hardware/address_mapped.h
src/rp2_common/hardware_resets/include/hardware/resets.h

pio.h: sm_config_set_sideset(): bad assertion

pio.h says:

static inline void sm_config_set_sideset(pio_sm_config *c, uint bit_count, bool optional, bool pindirs) {
assert(bit_count <= 32);
c->pinctrl = (c->pinctrl & ~PIO_SM0_PINCTRL_SIDESET_COUNT_BITS) |
(bit_count << PIO_SM0_PINCTRL_SIDESET_COUNT_LSB);

However, according to RP2040 datasheet, table 397, SIDESET_COUNT occupies bits 31:29, that is only 3 bits, not 5. That is, the maximum valid value is 7, not 32.

gettimeofday() does not work

struct timeval seconds are always 0, regardless how much time passed (also for sleep_ms(3333)):

tud_cdc_connected()                                    
0 / 536877456                                          
0 / 3758157056                                         
0 / 536873932

Code:

#include <stdio.h>
#include "pico/stdlib.h"
#include <tusb.h>
#include <sys/time.h>

int main(void)
{
  stdio_init_all();
  while (!tud_cdc_connected()) { sleep_ms(100);  }
  printf("tud_cdc_connected()\n");

  struct timeval tv0,tv1,tv2;
  gettimeofday(&tv0, NULL);
  sleep_ms(1);
  gettimeofday(&tv1, NULL);
  sleep_ms(2);
  gettimeofday(&tv2, NULL);

  printf("%ld / %u\n",tv0.tv_sec,tv0.tv_usec);
  printf("%ld / %u\n",tv1.tv_sec,tv1.tv_usec);
  printf("%ld / %u\n",tv2.tv_sec,tv2.tv_usec);

  return 0;
}

Ethernet?

Is there any support for Ethernet, yet?

The PIOs should be capable of talking to 100 Mbit PHYs. I have a working prototype for the receive side with RMII and a LAN8720 PHY: https://github.com/BBBSnowball/pico-examples/tree/master/pio/rmii

Is this something we would want to have in pico-sdk or pico-extras? Are there any existing efforts that I have overlooked? I can hardly believe that I'm the only one working on this ;)

multicore_sleep_core1() causes compile failure, missing core1_hang

I originally posted this on the Pico forum at raspberrypi.org and jamesh informed me to post it over here. The following is an excerpt of what I posted there.

Hi All
I was thoroughly enjoying my testing of the Pico's dual processors last night when I think I discovered either a bug or a serious lack of documentation, or both. My intention was to see if I could put core 1 to sleep while core 0 did something for a little while, then wake it back up to continue on. At this point, I'm not doing anything serious with the Pico, this is all just test code that will simply output the index of a loop to the serial port. (I have successfully had two separate counting loops running one in each core, each outputting their count via printf() to the serial, and it works fine.) So, in the documentation, I found the reference to multicore_sleep_core1() and I thought I would try it. I called it from core 0. When I recompiled the code, I got

16% Linking CXX executable mctest.elf
/usr/lib/gcc/arm-none-eabi/9.2.1/../../../arm-none-eabi/bin/ld: CMakeFiles/mctest.dir/home/tkunz/pico/pico/pico-sdk/src/rp2_common/pico_multicore/multicore.c.obj: in function multicore_sleep_core1': multicore.c:(.text.multicore_sleep_core1+0x94): undefined reference to core1_hang'
collect2: error: ld returned 1 exit status
make[2]: *** [CMakeFiles/mctest.dir/build.make:972: mctest.elf] Error 1
make[1]: *** [CMakeFiles/Makefile2:1454: CMakeFiles/mctest.dir/all] Error 2
make: *** [Makefile:84: all] Error 2

I searched the SDK code for "core1_hang" and could only find references to it, but no definition of it!

I can post the code sample to recreate this if needed, but I'm thinking you can easily reproduce it by putting multicore_sleep_core1 into anything and trying to compile it.

I was also then advised that this function is a one-way sleep and puts core1 out of action and it can't be re-awakened from that sleep and to use other means of saving power.
Thanks
Tom

Thanks,
Tom

Install C++ sdk on Mac OS m1

Hello
I cannot execute the commands sudo apt on Mac OSX big sur m1. I cannot do the full install. Any way of doing that ?
Thank you

Mark headers as SYSTEM includes in CMake

The include paths are set using:

    target_include_directories(pico_stdlib_headers INTERFACE include)

(e.g. in src/common/pico_stdlib/CMakeLists.txt)

As they're not marked as SYSTEM, enabling warnings (e.g. -Wall) will erroneously be tagged in the system headers.

pico-sdk/src/rp2040/hardware_regs/include/hardware/regs/addressmap.h:56:20: error: type qualifiers ignored on cast result type [-Werror=ignored-qualifiers]
   56 | #define TIMER_BASE 0x40054000

for example. If the headers are tagged SYSTEM then CMake uses -Isystem or equivalent which tells the compiler to suppress warnings coming from those includes.

A potential fix is:

$ git grep -l target_include_directories | xargs perl -pi -e 's/target_include_directories(.*)INTERFACE/target_include_directories$1SYSTEM INTERFACE/'

calling `sleep_ms` inside an interrupt handler causes lockup

Summary: when you call sleep_ms inside of an interrupt handler, some sort of infinite loop occurs inside of the hardware timer. Specifically, picoprobe/gdb is pointing to the code hanging somewhere in this function:

uint32_t hi_target = target >> 32u;

To reproduce: build/flash https://github.com/Lard4/pico-irq-test then when GP22 goes high (gets the interrupt), it turns off the LED then hangs.

Start main binary at 0x10001000 to allow for standalone second stage loader?

Since the (Q)SPI flash bootloader is possibly part specific, it would be nice if (for simple cases) firmware could "just work" with a pre-flashed second stage, rather than having to be compiled for a specific flash part.

The first step to enable this would be to align the main image to start at the next erase unit (0x1000 offset) so it can be reflashed without disrupting the second stage.

For more complex projects that need to access the flash other than just reading from it via the XIP window, a function table could be provided for optimized, part-specific low level flash access (replacements for the ROM flash functions).

enforce that gcc toolchain only used thumb code

on my distro of choice, the gcc currently lacks a thumb version of crtbegin.o, so it silently inserted an arm32 version into all of my pico builds, resulting in nothing working
fixing that problem is outside of the scope of pico-sdk

but, detecting it, and warning/failing is probably within the scope of pico-sdk, and is very simple to do:

[nix-shell:~/apps/rpi/pico/pico-examples]$ readelf --arch-specific build/hello_world/usb/hello_usb.elf
Attribute Section: aeabi
File Attributes
  Tag_CPU_name: "ARM v6K"
  Tag_CPU_arch: v6K
  Tag_CPU_arch_profile: Microcontroller
  Tag_ARM_ISA_use: Yes
  Tag_THUMB_ISA_use: Thumb-1
  Tag_ABI_PCS_wchar_t: 4
  Tag_ABI_FP_denormal: Needed
  Tag_ABI_FP_exceptions: Needed
  Tag_ABI_FP_number_model: IEEE 754
  Tag_ABI_align_needed: 8-byte
  Tag_ABI_enum_size: small

[nix-shell:~/apps/rpi/pico/pico-examples]$ readelf --arch-specific build-ubuntu/hello_world/usb/hello_usb.elf
Attribute Section: aeabi
File Attributes
  Tag_CPU_name: "6S-M"
  Tag_CPU_arch: v6S-M
  Tag_CPU_arch_profile: Microcontroller
  Tag_THUMB_ISA_use: Thumb-1
  Tag_ABI_PCS_wchar_t: 4
  Tag_ABI_FP_denormal: Needed
  Tag_ABI_FP_exceptions: Needed
  Tag_ABI_FP_number_model: IEEE 754
  Tag_ABI_align_needed: 8-byte
  Tag_ABI_enum_size: small

when gcc did the wrong thing, it added a Tag_ARM_ISA_use: Yes into the arch specific flags on the resulting elf binary
it should be pretty simple to just check those flags after linking, and then fail if gcc somehow put arm32 code into the final elf

Misleading hint when tinyusb submodule not present

  1. Clone sdk
  2. Clone examples
  3. Set path to sdk and configure CMake to build examples per instructions
  4. CMake shows warning:
TinyUSB submodule has not been initialized; USB support will be unavailable
--
11 | hint: try 'git submodule update --init'.
  1. Run git submodule update -- init per hint. (no errors displayed)
  2. Re-run cmake ..

Expected result: tinyusb is available and examples built.
Actual result: tinyusb is not available.

When building a project it's not clear at first glance that the hint's command must be run in the sdk repository. If building the examples, it's reasonable to assume the tinyusb dependency should be bundled with the project, so it's easy to miss even for experienced users :).

Forum post with the same issue: https://www.raspberrypi.org/forums/viewtopic.php?f=144&t=301092#p1808695

Suggest hint: try 'git submodule update --init' from the pico-sdk git repository.

N_GPIOS was not declared in this scope, unless gpio.h is explicitly included

I'm not sure this qualifies as an "issue" since I fixed it with: pimoroni/pimoroni-pico@6a13dc5#diff-ddd42d56faea5530bfb4a0200db4bbecaf574481ae9cfa7d66e8b296783ce838

However if don't explicitly:

#include "hardware/gpio.h"

before:

#include "hardware/pwm.h"

Then compiling will fail with:

[build] /home/phil/Development/pico/pico-sdk/src/rp2_common/hardware_pwm/include/hardware/pwm.h: In function 'uint pwm_gpio_to_channel(uint)':
[build] /home/phil/Development/pico/pico-sdk/src/rp2_common/hardware_pwm/include/hardware/pwm.h:86:33: error: 'N_GPIOS' was not declared in this scope
[build]    86 |     valid_params_if(PWM, gpio < N_GPIOS);
[build]       |                                 ^~~~~~~
[build] /home/phil/Development/pico/pico-sdk/src/rp2_common/hardware_pwm/include/hardware/pwm.h:86:5: note: in expansion of macro 'valid_params_if'
[build]    86 |     valid_params_if(PWM, gpio < N_GPIOS);
[build]       |     ^~~~~~~~~~~~~~~
[build] /home/phil/Development/pico/pico-sdk/src/rp2_common/hardware_pwm/include/hardware/pwm.h:86:33: note: the macro 'N_GPIOS' had not yet been defined
[build]    86 |     valid_params_if(PWM, gpio < N_GPIOS);
[build]       |                                 ^~~~~~~
[build] /home/phil/Development/pico/pico-sdk/src/rp2_common/hardware_pwm/include/hardware/pwm.h:86:5: note: in expansion of macro 'valid_params_if'
[build]    86 |     valid_params_if(PWM, gpio < N_GPIOS);
[build]       |     ^~~~~~~~~~~~~~~
[build] In file included from /home/phil/Development/pico/pico-sdk/src/rp2_common/hardware_adc/include/hardware/adc.h:12,
[build]                  from /home/phil/Development/pico/pimoroni-pico/libraries/pico_explorer/pico_explorer.cpp:5:
[build] /home/phil/Development/pico/pico-sdk/src/rp2_common/hardware_gpio/include/hardware/gpio.h:136: note: it was later defined here
[build]   136 | #define N_GPIOS 30

It does strike me that pwm.h should do this implicitly if it cannot build without that definition. But I could be doing something silly?

LTO support and C/CXX flags override hard to achieve

First of all thanks for making this so painless. It worked basically right out of the box even with a different arm-none-eabi toolchain.

LTO support
Linking is failing with these errors:

/tmp/ccbJpNID.s: Assembler messages:
/tmp/ccbJpNID.s:25: Error: selected processor does not support `sev' in ARM mode
/tmp/ccbJpNID.s:53: Error: selected processor does not support `blx r3' in ARM mode
/tmp/ccbJpNID.s:117: Error: selected processor does not support `blx r3' in ARM mode
/tmp/ccbJpNID.s:406: Error: selected processor does not support `bkpt #0' in ARM mode
/tmp/ccbJpNID.s:427: Error: selected processor does not support `bkpt #0' in ARM mode
/tmp/ccbJpNID.s:449: Error: selected processor does not support requested special purpose register -- `mrs lr,PRIMASK'
/tmp/ccbJpNID.s:452: Error: selected processor does not support `cpsid i' in ARM mode
/tmp/ccbJpNID.s:463: Error: selected processor does not support `dmb' in ARM mode
/tmp/ccbJpNID.s:501: Error: selected processor does not support `dmb' in ARM mode
/tmp/ccbJpNID.s:510: Error: selected processor does not support requested special purpose register -- `msr PRIMASK,lr'
/tmp/ccbJpNID.s:583: Error: selected processor does not support `blx r3' in ARM mode
/tmp/ccbJpNID.s:618: Error: selected processor does not support `blx r3' in ARM mode
/tmp/ccbJpNID.s:714: Error: selected processor does not support `blx r2' in ARM mode
/tmp/ccbJpNID.s:729: Error: selected processor does not support `blx r3' in ARM mode
lto-wrapper: fatal error: /opt/devkitpro/devkitARM/bin/arm-none-eabi-g++ returned 1 exit status
compilation terminated.
/opt/devkitpro/devkitARM/lib/gcc/arm-none-eabi/10.1.0/../../../../arm-none-eabi/bin/ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status
make[2]: *** [CMakeFiles/blink.dir/build.make:691: blink.elf] Fehler 1
make[2]: Verzeichnis „/home/blub/pico/blink/build“ wird verlassen
make[1]: *** [CMakeFiles/Makefile2:1494: CMakeFiles/blink.dir/all] Fehler 2
make[1]: Verzeichnis „/home/blub/pico/blink/build“ wird verlassen
make: *** [Makefile:103: all] Fehler 2

These errors are quite strange since it's usually the other way around with something not being supported in thumb mode. Have not digged too deep yet to find out what's causing these.

C/CXX flags
I tried to override the C and linker flags to have different optimization than default by doing

cmake .. -DCMAKE_C_FLAGS="-O2 -flto -fno-data-sections" -DCMAKE_EXE_LINKER_FLAGS="-O2 -flto"

The result is this order of flags to the compiler:
...-I/home/blub/pico/pico-sdk/src/rp2_common/pico_stdio_uart/include -O2 -flto -fno-data-sections -O3 -DNDEBUG -ffunction-sections -fdata-sections -o CMakeFiles/blink.dir/home/blub/pico/pico-sdk/src/rp2_common/pico_stdio_uart/stdio_uart.c.obj -c /home/blub/pico/pico-sdk/src/rp2_common/pico_stdio_uart/stdio_uart.c
Which means it's basically overriding my flags instead of the other way around. Somewhere it's including the override flags before the usual SDK given flags.

Would be nice if at least the C/CXX flags issue can be fixed. I understand if LTO is not happening for a while since it tends to uncover undefined behavior or bugs not seen without but in my experience it does help shrink down code size more.

Full build log: https://gist.github.com/profi200/718e20b9d3ebec87db60f78d0deb994b

Minimum CMake version needs to be incremented

The readme indicates that cmake v3.12 is required at a minimum. This seems to be incorrect, as I get the following error when configuring cmake for the pico-examples repository:

[cmake] CMake Error at pico-sdk/src/rp2_common/boot_stage2/CMakeLists.txt:24 (target_link_options):
[cmake]   Unknown CMake command "target_link_options".

The documentation for cmake indicates target_link_options was added in v3.13. I suggest updating the readme and value in cmake_minimum_required (probably also in the pico-examples repo as well as here). The SDK/getting started PDF's might also need updating.

FYI, platform is Windows 10 but I don't think that matters as the cmake docs are pretty clear this was added in 3.13.

I also haven't yet tested with v3.13 explicitly, so I can't discount other things requiring an even higher version!

ninja: error: FindFirstFileExA

Setup

  • Windows 10
  • VS Code

Using VS Code I can build the project but after every build I have to manualy remove the content of ".\build" if I do not I get the following error.

[main] Building folder: test [build] Starting build [proc] Executing command: "C:\Program Files\CMake\bin\cmake.EXE" --build c:/Users/{USERNAME}/Documents/pico/test/build --config Debug --target all -- -j 14 [build] ninja: error: FindFirstFileExA(c/:/users/{USERNAME}/documents/pico/pico-sdk/src/common/pico_stdlib/include/pico): The filename, directory name, or volume label syntax is incorrect. [build] [build] Build finished with exit code 1

In VS Code if I do Clean or Clean and Reconfigure I get the same error!

Values of the _SELECTED registers in the clock controllers are not explained

I was not able to find any documentation for the values of the _SELECTED registers in the clock controllers.

In the SVD file, they are simply described as 32-bit registers, but not specified in more detail. The other clock controller registers,
like the _CTRL registers, have fields with enumerated values. It would be very nice to have this for the _SELECTED registers as well.

The datasheet does also not offer more help, it says that the values are one-hot encoded, but it doesn't say what the bits mean.

Is this documented somewhere?

No windows support?

Hi, great that there is an SDK all done but how can I use my Windows based dev machine to compile code for the Pico?

copying `pico_sdk_import.cmake` vs referring to it directly.

The official docs recommend copying external/pico_sdk_import.cmake into your project. I found that since PICO_SDK_PATH has to be set anyway, this works as well, and keeps it a bit DRYer.

include($ENV{PICO_SDK_PATH}/external/pico_sdk_import.cmake)

If there aren't any downsides to this (and there very well may be, I'm not that experienced with cmake), it might be worth mentioning in the docs.

No ujson/json library included?

Hi there,

Excited to get my hands on a Pico this week and have been playing around for a few days. I noticed that a few standard Micropython libraries are not included with the default, including ujson. Any plans to support this in an upcoming release?

Thanks!

Unable to build in Visual Studio Code

I followed the instructions in the PDF and successfully setup Windows to build from the command line. However when trying to build from VSC it reports the following error:

[main] Building folder: pico-examples
[build] Starting build
[proc] Executing command: "C:\Program Files\CMake\bin\cmake.EXE" --build c:/Users/barry/Downloads/pico-examples/build --config Debug --target all -- -j 8
[build] ninja: error: FindFirstFileExA(c/:/users/barry/downloads/pico-sdk/src/rp2_common/boot_stage2): The filename, directory name, or volume label syntax is incorrect.
[build]
[build] Build finished with exit code 1

If I paste the same command line into a VS cmd box it reports the same issue. This also happens if I select build all or a specific code set e.g. blink

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.