RP2040 board compiler error on stdio.h

I have the Adafruit Feather with USB Host RP2040 board and cannot get everything setup in PlatformIO. Here’s my platform.ini:

[env:rpi2040]
platform = raspberrypi
board = pico
framework = arduino
lib_deps = https://github.com/sekigon-gonnoc/Pico-PIO-USB
build_flags = 
  -DUSE_TINYUSB_HOST
  -DCFG_TUSB_CONFIG_FILE=\"tusb_config.h\"

I want my project to be able to connect to another Arduino board via the Host port and use a serial interface to talk to the board there.

When I compile my project, I get an error from the Pico SDK:

Processing rpi2040 (platform: raspberrypi; board: pico; framework: arduino)
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------Verbose mode can be enabled via `-v, --verbose` option
CONFIGURATION: https://docs.platformio.org/page/boards/raspberrypi/pico.html
PLATFORM: Raspberry Pi RP2040 (1.14.0) > Raspberry Pi Pico
HARDWARE: RP2040 133MHz, 264KB RAM, 2MB Flash
DEBUG: Current (cmsis-dap) External (cmsis-dap, jlink, raspberrypi-swd)
PACKAGES:
 - framework-arduino-mbed @ 4.1.5
 - tool-rp2040tools @ 1.0.2
 - toolchain-gccarmnoneeabi @ 1.90201.191206 (9.2.1)
LDF: Library Dependency Finder -> https://bit.ly/configure-pio-ldf
LDF Modes: Finder ~ chain, Compatibility ~ soft
Found 50 compatible libraries
Scanning dependencies...
Dependency Graph
|-- Pico PIO USB @ 0.6.1+sha.fe9133f
|-- Adafruit TinyUSB Library @ 3.3.3
|-- SPI
Building in release mode
Compiling .pio\build\rpi2040\src\main.cpp.o
Compiling .pio\build\rpi2040\lib365\Pico PIO USB\pio_usb.c.o
Compiling .pio\build\rpi2040\lib365\Pico PIO USB\pio_usb_device.c.o
Compiling .pio\build\rpi2040\lib365\Pico PIO USB\pio_usb_host.c.o
In file included from .pio\libdeps\rpi2040\Pico PIO USB\src\usb_crc.h:4,
                 from .pio\libdeps\rpi2040\Pico PIO USB\src\pio_usb_device.c:16:
C:\Users\<user>\.platformio\packages\framework-arduino-mbed\cores\arduino/mbed/targets/TARGET_RASPBERRYPI/TARGET_RP2040/pico-sdk/common/pico_stdlib/include/pico/stdlib.h:11:10: fatal error: pico/stdio.h: No such file or directory
   11 | #include "pico/stdio.h"
      |          ^~~~~~~~~~~~~~

I looked in that folder C:\Users<user>.platformio\packages\framework-arduino-mbed\cores\arduino/mbed and nowhere is there a “stdio.h” file anywhere!?

Have I missed an install somewhere? Am I doing something wrong?

This is ArduinoCore-mbed. Did you try it with the Arduino-Pico core instead? Just enable Win32 Long paths and Git long paths, then use the platformio.ini

[env:rpi2040]
platform = https://github.com/maxgerhardt/platform-raspberrypi.git
board = rpipico
framework = arduino
lib_deps = https://github.com/sekigon-gonnoc/Pico-PIO-USB
build_flags = 
  -DUSE_TINYUSB_HOST
  -DCFG_TUSB_CONFIG_FILE=\"tusb_config.h\"

Thank you! I guess I am not familiar enough with the various frameworks and options available.

This almost compiles now, errors are in my code now.
What I’m noticing now is that I can’t do either of these:

#include "Adafruit_USBH_CDC.h"
#include "Adafruit_TinyUSB.h"

since they are not found. Using <Adafruit...> also doesn’t work. Instead I need this huge path:

#include "../../../.platformio/packages/framework-arduinopico/libraries/Adafruit_TinyUSB_Arduino/src/arduino/cdc/Adafruit_USBH_CDC.h"
#include "../../../.platformio/packages/framework-arduinopico/libraries/Adafruit_TinyUSB_Arduino/src/Adafruit_TinyUSB.h"

Do I need to update the PATH somehow? Or should I delete .pio folder from my project and re-init, maybe there are old things in there from my previous attempts?

[Later]
Hmm, even after the long path includes, the linker fails with all the Adafruit references. I wonder if this library isn’t properly referenced…

You’re missing -DUSE_TINYUSB to trigger the regular TinyUSB library inclusion. Otherwise it’s explicitly excluded.

The arduino/device_info/device_info.ino compiles fine for me.

Awesome! That was it, thanks you soooo much :slight_smile:

OK, I have a new issue. So I had to reset the board by copying the blink.ino.elf.uf2 file to the board as a storage device on my Win10 machine. Then it appears as COM10, but the LEDs don’t blink (not sure if that’s relevant). Then I successfully upload the rpi project, but after upload no COM port comes back. Even after pressing reset or unplugging and reconnecting. In fact, I have to hold down BOOT button while connecting for it to re-appear on my machine.

Any ideas why the sketch doesn’t make the board appear as a serial device after flashing?

It happens happens with your unmodified RP2040 USB Host project as well, upload succeeds, but no port comes back.

When -DUSE_TINYUSB -DUSE_TINYUSB_HOST is activated, the tusb_config.h choses a configuration that does not have “USB Device” capabilities turned on, only “USB Host”. As thus, the firmware will not open a USB CDC Serial. The hardware serial (Serial1) is still usable though. I’m not sure of the inner workings of this, or why it would not be possible for the Pico ot be a USB device on one set of pins and simulatenously be a USB host at other pins.

Frankly I’m not even sure why you need that library at all, if Adafruity_TinyUSB is working, you should be able to use that sketch without any additional libraries like that Pico-PIO-USB. You can also see that they deliberately used Serial1 here to output to the hardware UART, they don’t try to be device and host at the same time.

I’m essentially trying to replicate what this project is doing:

So I tried removing PIC-PIO-USB, but now it’s complaining about SPI.h not being present.

In file included from .pio\libdeps\rpi2040\Adafruit TinyUSB Library\src\arduino\Adafruit_USBH_Host.cpp:36:
.pio\libdeps\rpi2040\Adafruit TinyUSB Library\src\arduino\Adafruit_USBH_Host.h:30:10: 
fatal error: SPI.h: No such file or directory

I thought that was standard for Arduino?

Yes, but PIO’s LDF doesn’t recognize the dependency:

Oh boy, so an 8 month old issue on PlatformIO… are there any workarounds? Sounds like going back to 2.2.2 might work?