ve6vh
Posts: 2
Joined: Sat May 15, 2021 9:32 pm

First Impressions of building Pico applications on a Windows Platform

Tue May 18, 2021 10:43 pm

Hello All. I recently met the Pico for the first time, and since my development machine is Windows based, I decided to follow the instructions in the documentation, however my journey from scratch to working application was not without some left turns. I downloaded and installed all the recommended tools: VSCode, CMake, the GCC tools and Python. Once running, the first step was to build the examples, then move on to my own code. If you are doing or intend to do the same, here are some pitfalls to avoid:

Square zeroAlways invoke VSCode from the developer console, otherwise the linker phase of the C compiler will not work!

Pitfall #1Unable to get past the C compiler check when attempting to build ELF2UF2. I posted this on the forum earlier, this appeared to be a CMake issue. For some reason best known to itself, V20 wants to default to the 64 bit compiler. The test fails at the linker stage as the libraries are all 32 bi, and the compiled code is not. It manifests itself as unresolved symbols at the link phase. The fix is to text edit CMakeCache.txt in build/elf2uf2 to point to the correct compiler. Fortunately, once built, that step does not have to be repeated.

Pitfall #2Unable to get USB uar/t to work. This turns out to be a GIT problem. There are two ways to clone a git repo on Windows, the first is to download and install git itself to do it, the second is to use the built-in zip file generator on Github. The latter does not work as it does not follow the submodule link, so the lib/tinyusb directory is empty. The fix is to install Git and clone it as you would on Linux.

PItfall #3Unable to find pico I/O libraries in subdirectories. I have a large project that is subdivided into several modules. If you attempt to do any I/O from a module in a subdirectory and need the pico include files, they appear not to be found. The fix is to move all of that to the top level and have only pure code in the subdirectories.

After all of that, I now have a working application.

kilograham
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 610
Joined: Fri Apr 12, 2019 11:00 am
Location: austin tx

Re: First Impressions of building Pico applications on a Windows Platform

Tue May 18, 2021 11:16 pm

ve6vh wrote:
Tue May 18, 2021 10:43 pm
Hello All. I recently met the Pico for the first time, and since my development machine is Windows based, I decided to follow the instructions in the documentation, however my journey from scratch to working application was not without some left turns. I downloaded and installed all the recommended tools: VSCode, CMake, the GCC tools and Python. Once running, the first step was to build the examples, then move on to my own code. If you are doing or intend to do the same, here are some pitfalls to avoid:

Square zeroAlways invoke VSCode from the developer console, otherwise the linker phase of the C compiler will not work!
True; fortunately this is well documented.
Pitfall #1Unable to get past the C compiler check when attempting to build ELF2UF2. I posted this on the forum earlier, this appeared to be a CMake issue. For some reason best known to itself, V20 wants to default to the 64 bit compiler. The test fails at the linker stage as the libraries are all 32 bi, and the compiled code is not. It manifests itself as unresolved symbols at the link phase. The fix is to text edit CMakeCache.txt in build/elf2uf2 to point to the correct compiler. Fortunately, once built, that step does not have to be repeated.
Not sure why i 64 bit compiler would affect elf2uf2; In any case, editing CMakeCache.txt is not a good solution as it will be overridden. what is the forum link? even if you feel you have to edit a CMake variable, pass it on the cmake command line instead.
PItfall #3Unable to find pico I/O libraries in subdirectories. I have a large project that is subdivided into several modules. If you attempt to do any I/O from a module in a subdirectory and need the pico include files, they appear not to be found. The fix is to move all of that to the top level and have only pure code in the subdirectories.
You can certainly use pico libraries from any sub directory within your application, otherwise that'd be very silly. If you are having problems and want to know how to do it properly then ask, don't state "it can't be done"!

User avatar
nick.mccloud
Posts: 1225
Joined: Sat Feb 04, 2012 4:18 pm

Re: First Impressions of building Pico applications on a Windows Platform

Wed May 19, 2021 12:15 am

ve6vh wrote:
Tue May 18, 2021 10:43 pm
Pitfall #2Unable to get USB uar/t to work. This turns out to be a GIT problem. There are two ways to clone a git repo on Windows, the first is to download and install git itself to do it, the second is to use the built-in zip file generator on Github. The latter does not work as it does not follow the submodule link, so the lib/tinyusb directory is empty. The fix is to install Git and clone it as you would on Linux.
This too is fully documented in the documentation from day 0. I'm not sure that there is a concept of 'clone it as you would on Linux' - you either download the Zip file or you clone it, it's very platform agnostic.
Pico/RP2040 ≠ Arduino
Pico = hot rod kit car, Arduino = hot rod kit car wrapped in cotton wool with buoyancy aids & parachute

ronter
Posts: 32
Joined: Thu Nov 12, 2015 3:11 am
Location: Ottawa, Canada

Re: First Impressions of building Pico applications on a Windows Platform

Wed May 19, 2021 12:21 am

My experience with cross compiling on Win10 went very smoothly. I used Visual Studio 2019 Community Edition ( free ) and VisualGDB 5.6 Beta ( paid ). VisualGDB includes its own copy of the PICO SDK, but was easy to replace with the latest SDK build. The only issue is that there's a global option to disable optimization in debug builds; this seems to mess up the inline code in the SDK. I think I got around that by disabling the option and putting #pragma GCC optimize (0) at the head of my modules when I'm debugging.

The SWD is fully integrated, and I'm using a picoprobe with OpenOCD + GDB. Works very well.

kilograham
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 610
Joined: Fri Apr 12, 2019 11:00 am
Location: austin tx

Re: First Impressions of building Pico applications on a Windows Platform

Wed May 19, 2021 1:10 am

ronter wrote:
Wed May 19, 2021 12:21 am
he only issue is that there's a global option to disable optimization in debug builds; this seems to mess up the inline code in the SDK
Should be fixed in the develop branch in the SDK (which will be the next release)

User avatar
nick.mccloud
Posts: 1225
Joined: Sat Feb 04, 2012 4:18 pm

Re: First Impressions of building Pico applications on a Windows Platform

Wed May 19, 2021 8:48 am

ronter wrote:
Wed May 19, 2021 12:21 am
My experience with cross compiling on Win10 went very smoothly.
Mine did too, so much so that I recorded a video of the install on Windows at the end of the first week of release.

And I'm a macOS user ;-)
Pico/RP2040 ≠ Arduino
Pico = hot rod kit car, Arduino = hot rod kit car wrapped in cotton wool with buoyancy aids & parachute

hippy
Posts: 9911
Joined: Fri Sep 09, 2011 10:34 pm
Location: UK

Re: First Impressions of building Pico applications on a Windows Platform

Wed May 19, 2021 5:52 pm

ve6vh wrote:
Tue May 18, 2021 10:43 pm
Square zeroAlways invoke VSCode from the developer console, otherwise the linker phase of the C compiler will not work!
Having to use the developer console, even when not using VS Code, is a PITA.

Fortunately Shawn Hymel's guide to using the alternative MinGW build system - which can be installed by itself alongside the Microsoft build system with everything else left as is - allowed me to use the standard command prompt rather than the developer console.

That should also work for VS Code. I don't use VS Code so can't confirm but probably worth a try.

https://shawnhymel.com/2096/how-to-set- ... th-vs-code

But, for me, the recommend route went fairly smoothly other than trying to build 'picotool' and MicroPython.

Return to “SDK”