JamesH65
commented
2 years ago Please note, the Pico is developed by Raspberry Pi Ltd, not Foundation.
We are looking in to improving the Windows processes, but you will find Linux systems (including the Raspberry pi itself) much easier to use. We have scripts that install everything for you. You could try the Pico project generator to generate project files for you, that saves a bit of time. Also worth noting that developing you own IDE vendor specific and closed source tools is a very time consuming and expensive business and goes against the open source ethos we try to stick to where we can.
MrYsLab
I'm a fan of raspberry pis, and use them all the time for my job as an avionics engineer working with UAVs. They're a fantastic piece of engineering, both in terms of hardware and software. After trying out the RP2040 and Pico boards, I'm disappointed to learn they fall short of the standards I've come to expect from products from the pi foundation. Why? The development environment is pure torture.
At first, I was excited when ordering the boards. I was excited by the quality of documentation, the tutorials available, the ease of use. I open up the RP2040 datasheet, and I love the ideas outlined in the very first page: "It brings our signature values of high performance, low cost, and ease of use to the microcontroller space" (Emphasis mine). Thank god, I thought, something easy to use but powerful. I've tried microcontrollers by a few different manufacturers - STM, NXP, Texas Instruments, and Microchip. Of those, the only one with a good development and build environment is STM, with STM32CubeIDE, so I thought it would be fantastic to have other microcontrollers in my arsenal that I could develop with and get applications running quickly.
And then I got to creating a build environment. The user's choices are either micropython or the c/c++ SDK. Wanting to see if the RP2040 would be useful in a product, I opted for the C/C++ SDK, since those languages are more suitable for an end-user product. And from the start, everything was a fight. Working from Windows, you have to install 5 different programs - the arm gcc compiler, Cmake, visual studio code, git, and python 3.9. Just to get the environment working! If you want to build a project, you have to open visua studio code, edit path variables, open a terminal, change to git bash, and run a string of cmake build commands, making sure your folder structure is EXACTLY correct, and that visual studio json files or cmakelists.txt files aren't missing anything. CMakeLists.txt! They're ALL called CMakeLists.txt! How is that ease of use? The tutorials show how you can create the pre-determined programs like blink or hello adc, but the second you deviate from them and try to create your own functions you're met with a wall of resistance from the toolchain.
Let's talk about competing products for a second: on the hobbyist end of the scale, the arduino IDE and arduinos boards, and on the more professional end of the scale, stm32cubeide and STM32 microprocessors. This is the kind of space the pi foundation wants to move into, so we would do well to think about whether their product offers anything that the market, on either end of the scale, does not.
To build with the arduino IDE, you hit one button. Then you hit a different one to download. Overwhelmingly simple, but that's the idea - the IDE has all the complexity of the build, link, and compile behind the scenes, and the end user doesn't have to do anything. When you install the IDE, it's all done for you, and you don't have to install five separate tools. The problem with arduinos, if it can be called such, is that they're a bit of a "rubber room", offering less in the way of configuring hardware or creating more "powerful" applications. No matter, at the other end of the scale you have STM32CubeIDE, an IDE created and supported by a multinational corporation, intended for professional development, but still ease of use. STM32CubeIDE guides me from the very start - processor selection based on peripherals, flash, or other filters, then a visual display showing the pinout and what I've configured, as well as a visual display of the clock tree. One button to auto generate code, creating a HAL for each peripheral I've enabled, and copying all the relevant header and initialisation files into a neat, accessible project structure. I don't need to do any peripheral initialisation at all, it's all done for me. If I create a new header file in one of the files, the linker will automatically find it, and all I have to do is put an include at the top.
Compare this with the RP2040. 5 different programs to install, instead of one. An open-source IDE, instead of a developer-supported one. An environment that requires the user to create folder and cmakelists structures, foisting difficulty on them, instead of doing it for you. The RP2040 is not at all easy to use, and after spending a couple of days trying to get a decent environment, I give up. There's no way I would use this in a product at all, because the environment is just too poor. I could save myself huge amounts of time and effort using an environment from a different manufacturer. It doesn't matter how good the hardware is, if the foundation want to sell chips, what matters is ease of use. It's no wonder arduino took off, and it's no wonder there's still thousands of RP2040's in stock when every other chip is sold out. The foundation have created only the hardware and completely forgotten the user experience and development environment, hoping that the """"""""open source community""""""" will mop up their mess.