Can a single platformio.ini have more than one "entry point"

I have a robot that has a raspberry Pi connected via USB to a Teensy. The Teensy “firmware” is pretty complicated and is controlled by the robot software in the Raspberry Pi. The firmware source file happens to be called firmware.ino. Everything works as expected. Normally when I modify the firmware, I use this command: platformio run --target upload -e teensy41 to upload and start it.

I would like to write a much simpler bit of firmware that tests some new libraries and functionality that I have just written, without involving the raspberry pi. Let’s say I call that test.ino. What is the simplest/easiest way for me to upload and run that instead? I rather not create a whole new pio project with libraries, includes and everything else.

  1. get rid of the Arduino’s structure of .ino files → migrate to PlatformIO structure
  2. Use Section [env] — PlatformIO latest documentation
1 Like

What is involved in changing to PlatformIO structure? I think, other than the .ino file extension, I have it:


../firmware
   .pio
   .lib/
   .src/
      firmware.ino
   platformio.ini

And my platformio.ini looks like this:

[env]
platform = teensy
framework = arduino
upload_protocol = teensy-cli
upload_port = /dev/linobase

[env:teensy41] 
board = teensy41

You can very easily create one PlatformIO project that has one or more environments that compile to different firmwares, by excluding or including source files for one firmware or the other. This is done by using build_src_filter.

See e.g.

1 Like

The thing that I am not clear one if you see my directory structure above is this. My “main” is in src/platformio.ino. Nowhere in my platformio.ini is that directory and file name mentioned. So I don’t see immediately how I would indicate a different “main” for the same …/firmware work folder.

The build_src_filter is always relative to src/. So the only thing that needs to be mentioned is what source files are to be built or to be excluded in that folder.

Using .ino makes this more complicated though, as that gets first converted to .cpp and then compiled, so your source filter may need to include both the .ino and .ino.cpp.

If there is more than one .cpp (or .ino) file in the src_filter, which one becomes the “main”?

It’s fine to have multiple .cpp / .ino files in the build src filter but only one of those files may define setup() and loop(), otherwise you will get a “multiple definition of setup/loop” compiler error. If there is e.g. a cpp file with common functionality (that does not include setup / loop), then two main sketches can both compile that file in their environments.