Raspberry Pi Pico

There is the following Warning in the Getting Started Guide regarding launching VS Code:

https://datasheets.raspberrypi.org/pico/getting_started_with_pico.pdf

If you  start  Visual  Studio  code  by  clicking  on  its  desktop  icon,  or  directly  from  the  Start  Menu  then  the  build 
environment  will  not  be  correctly  configured.  Although  this  can  be  done  manually  later  in  the  CMake  Tools  Settings,
the easiest way to configure the Visual Studio Code environment is just to open it from a Developer Command Prompt Window where these 
environmental variables are already set.

Success on the nmake:

C:\Users\jomodev\Downloads\RPI_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

Now I just waiting to receive that Pico from the ARM Developers Coffee Chat to test the code.

Below is the output of the CMake stage on my Windows 10 system running in the Developer Command Prompt VS 2019 window .

NOTE: I did have to set a Python environment variable for the Python 3.9 install I downloaded.

These are the tools I downloaded and installed. I already had VC Code installed and did the install of the tools and an update to VC Code.

   cmake-3.19.3-win64-x64.msi

   gcc-arm-none-eabi-10-2020-q4-major-win32.exe

   Git-2.30.0.2-64-bit.exe

   python-3.9.1-amd64.exe

   vs_BuildTools.exe

Currently, nmake is running and appears will take some time to complete.

CMake output:

C:\Users\jomodev\Downloads\RPI_Pico\pico-examples\build>setx PICO_SDK_PATH "..\..\pico-sdk"

SUCCESS: Specified value was saved.

C:\Users\jomodev\Downloads\RPI_Pico\pico-examples\build>cmake -G "NMake Makefiles" ..
Using PICO_SDK_PATH from environment ('..\..\pico-sdk')
Pico SDK is located at C:/Users/jomodev/Downloads/RPI_Pico/pico-sdk
Defaulting PICO_PLATFORM to rp2040 since not specified.
Defaulting PICO platform compiler to pico_arm_gcc since not specified.
-- Defaulting build type to 'Release' since not specified.
PICO compiler is pico_arm_gcc
PICO_GCC_TRIPLE defaulted to arm-none-eabi
-- The C compiler identification is GNU 10.2.1
-- The CXX compiler identification is GNU 10.2.1
-- The ASM compiler identification is GNU
-- Found assembler: C:/Program Files (x86)/GNU Arm Embedded Toolchain/10 2020-q4-major/bin/arm-none-eabi-gcc.exe
Defaulting PICO target board to pico since not specified.
Using board configuration from C:/Users/jomodev/Downloads/RPI_Pico/pico-sdk/src/boards/include/boards/pico.h
-- Found Python3: C:/Users/jomodev/AppData/Local/Programs/Python/Python39/python.exe (found version "3.9.1") found components: Interpreter
TinyUSB available at C:/Users/jomodev/Downloads/RPI_Pico/pico-sdk/lib/tinyusb/src/portable/raspberrypi/rp2040; adding USB support.
-- Could NOT find Doxygen (missing: DOXYGEN_EXECUTABLE)
ELF2UF2 will need to be built
PIOASM will need to be built
-- Configuring done
-- Generating done
-- Build files have been written to: C:/Users/jomodev/Downloads/RPI_Pico/pico-examples/build

Considering the attention and the fact they are using a CORTEX-M0, there is already wide support for this.

A bit off topic, but although there is a lack of examples for the Vidor 4000, I found there were ample tools to build a project for it.  It  just takes a bit of work and knowledge of the Intel FPGA tools.  There were limitations considering some licensing things, but those seemed to be worked around.

Price seems to always be a great motivator. I seem to recall ESP8266 started out in much the same way. It was seriously cheap and the open source community figured out how to use it.

I spent about £60 (UK) on the Arduino Vidor 4000 due to the hype, but the support stayed almost non-existant for months and eventually I gave up waiting for support software. I'm sure this board won't go that way though, partly due to the very low-cost equating to a huge uptake...and people like Pi anyway

dougw  wrote:

When you don't need the speed, the time spent developing Python software is much less than something like C.

This all depends on the Python software you are writing.  Simple scripts like blinking an LED might be perhaps simpler, but you can get very complex and convoluted Python programs which would be just easier and more efficient in something like C or C++.  However, what you are getting with Python is all the work that folks have done in C and C++, or other Programming language, to create the back end code and libs so you can get to Blinky with Python.

With the Pico implementation of MicroPython, they are using the UF2 Flashing Format to run the code on the Pcio. 

https://github.com/microsoft/uf2

https://makecode.com/blog/one-chip-to-flash-them-all

This requires a bootloader to run on the Pico which means space and resources are required to run this.  It might be nice for Blinking and LED, but you will hit a space and resource restraint at some point.  It is a good place to start for some folks though.

michaelkellett  wrote:

 

Life is too short - I'm going to wait until a few more people have played with this and there is a bit more discussion on the web.

That was my worry about this new board: too new and untested. I'm sure it won't take long for the community to figure things out and make things much smoother, but until then I'm with you and will cheer on from the sidelines!

-Nico

Thanks for being the guinea pig and blogging about it. I hope they do improve the development environment, and assume they will. I expect there is, or soon will be, an arduino port, so other development environments will need to compete with that.

Micropython allows fast operation for code routines that need it ...... all the way up to assembler type speeds ... if or when you really need it ....

Here is an example blinking an LED at 27 MHz......

https://www.youtube.com/watch?v=hHec4qL00x0&ab_channel=PyConAU

These techniques probably aren't a universal solution, but some impressive speeds can be achieved.

When you don't need the speed, the time spent developing Python software is much less than something like C.