Deep Dive w/Scott: RP2040 on Raspberry Pi Pico

День тому

I’m sponsored by Adafruit to work on CircuitPython. Support them, and by extension me, by purchasing hardware from adafruit.com
Chat with me and lot of others on the Adafruit Discord at adafru.it/discord.
Deep Dive happens every week. Normally Fridays at 2pm Pacific but occasionally shifted to Thursday at 2pm. Typically goes for two hours or more. Questions are welcome. Next week is Friday as normal.
Links:
Pico from Adafruit - www.adafruit.com/product/4864
Pico w/loose headers from Adafruit - www.adafruit.com/product/4883
CircuitPython for Pico - circuitpython.org/board/raspb...
Getting Started with Pico and CircuitPython - learn.adafruit.com/getting-st...
CircuitPython Essentials Guide - learn.adafruit.com/circuitpyt...
Feather RP2040 - www.adafruit.com/product/4884
CircuitPython for RP2040 - circuitpython.org/board/adafr...
ItsyBitsy RP2040 - www.adafruit.com/product/4888
rp2pio API doc - circuitpython.readthedocs.io/...
pico announcement blog post - www.raspberrypi.org/blog/rasp...
pico getting started - www.raspberrypi.org/documenta...
RP2040 datasheet - datasheets.raspberrypi.org/rp...
CircuitPython PIOASM library - github.com/adafruit/Adafruit_...
0:00 Getting started and hellos
08:41 Housekeeping
11:43 RP2040 and Raspberry Pi Pico board!
19:45 Show how to install CircuitPython on a Pico fresh out of a package.
24:00 Hello World
27:14 RP2040 / pico data resources
28:45 RP2040 data sheet
32:10 CP use of multi-core - “Not Yet”
36:43 Can I use any quad SPI memory with RP2040 like an MRAM memory does UF2 support these memories or only flash memory?
39:20 PIO ( Programmable IO )
41:22 Circuit Python has a list of the supported Flash chips in the source code, easy to find.
41:46 PIO ( Programmable IO ) continued
44:30 IRQ PIO
45:36 NeoPixel example for PIO ( 4 instructions )
46:20 Micropython vs. CP PIO differences
47:42 CP PIO future expansion
48:45 CAN bus in PIO? Possible…
49:20 PIO FIFO
51:50 GPIO functions ( PIO1 and PIO2 peripherals? )
53:52 3.2 PIO Programmer’s Model
55:01 USB Host examples ? ( see the sdk ? )
55:28 back to Programmer’s Model ( PC )
56:10 Output Shift Register
56:34 3.3 PIO Assembler (pioasm) / 3.4 Instruction Set
1:03:42 Examples…( see the SDK chapter 3 - Thanks @Luke)
1:04:06 - live code PIO example on Feather
1:06:49 CP NeoPixel code.py - not PIO
1:07:40 PIO test code (pioasm)
1:09:27 raspberrypi2.StateMachine
1:12:13 Logic Pro 16
1:13:15 square wave pioasm in code.py
1:14:55 Hub75 example does hot patch of the instruction memory (@luke)
1:15:45 Deinit for destroy and recreate pio scheme
1:17:03 plug into channel 4 - see the blink
1:18:28 update the old CP firmware - enter boot loader on the feather
1:20:05 PIO code goes into dedicated PIO instruction memory
1:21:15 you can read by writing PC and reading out SMx_INSTR
1:21:49 loading code.py into cleaned board ( pioasm and support libraries )
1:23:00 switch to 800KHz ( hmm - frequency is 400KHz )
1:23:40 squarewave assembly code
1:24:22 readthedocs.io/en/latest/README.html…
1:25:00 Rp2pio API
1:26:15 Learn.adafruit.com - for wiring tutorials
1:27:19 Iterate on square wave example
1:31:44 State machine “wrap” feature
1:33:15 Alternate logic analyzers ( use an rp2040 )
1:35:36 Tinlylogic friend promo
1:37:40 full speed 125000000 ( 62.5 MHz on the scope? )
1:39:04 Neopixel in 4 instructions
1:41:05 PIO resource sharing CP and user allocation
1:45:05 deep dive into neopixel pioasm
1:46:30 - wifi support from the airlift board via spi ( see Arduino Nano RP2040 )
1:47:05 back to neopixel pioasm ( out, jmp autopull, nop)
1:55:40 Assembler for the other M0 - someone needs to write it still :-)
1:57:15 microDev - s2 risc-v low power core
1:59:45 sm.write to get the bytes from CP to the PIO
2:01:50 assembler can be run on c-python
2:02:50 licensing question for @luke - compare with RISC-V / ARM
2:04:11 adafruit_pioasm.py source
2:09:35 PIO can use DMA
2:10:12 back to the datasheet ( Page 14 - bus overview )
2:12:00 state of GUI in CP
2:13:00 One of the strengths of CP is USB support…
2:14:05 CP porting checklist - what to do first
2:15:00 DisplayIO and HDMI - look for bare metal CP on rPI
2:16:30 CP definition with respect to Micropython
2:19:00 VSCode extension for CP
2:22:00 Double tap to reset doesn’t work yet
2:25:24 wrap up
2:28:54 off

КОМЕНТАРІ: 14

@SimonEllwood 3 роки тому

Great Video, Thanks.

@sebastianabrilvera5080 2 роки тому

Thanks for the video!!! I have a question that I still can't solve, how can I set in visual code a different RP2040 based board, such as the adafruit feather. Thank you very much.

@st3ddyman 3 роки тому

Great video as always, thanks. The PIO is really exciting and will replace FPGA for some functions. Do you know if and when the chips will become available for putting on DIY boards?

@adafruit 3 роки тому

Raspberry Pi has said Q2 for availability.

@st3ddyman 3 роки тому

@@adafruit sorry, I missed that bit in the video. Thanks for the information. Do you have any idea what price range they will be in?

@stephenvalente3296 3 роки тому

I've been trying to find out about the RP2040 IC availability, so good to hear they are going to available to buy at some point.

@tannewt 3 роки тому

@@st3ddyman I haven't seen any pricing.

@davidthacher1397 3 роки тому

Yes and no. The PIO assembly will be useful and much easier to use. However it is mostly a software approach, which means it will have a frequency response problem. It can have internal semantic problems. That being said it is very interesting addition. Initially I thought the PRU for BeagleBone Black was small FPGA. FPGAs can be a mess. However I am interested in them being used in MCU/MPUs. The issue that exists is the pin routing functions. Microchip MCUs support this with PPS and CLC. CLC is mostly a CPLD like device. It has limits, but can be very useful. There are a number of issues which can exist here in terms of timing. Simple CPLDs and software processors avoid these concerns. However they have limited functionality. Pin management can cause routing issues internally which can cause performance loss. These can be solved however this can drive up the cost of the circuits. However I doubt this applies much today except for high clock signals. Software processors will not work here as they will need a multiple times faster. Routing delays will cause issues for these signals also. Analog input is probably easier with software processor. However will likely have system bus contention concerns. FPGA can solve this also. However I do not know how many of the MCUs/MPUs will use the space for these types of things. There is a lot they can add, but economically it may not be viable. FPGAs will likely become more common place. However the programming model is still kind of a nightmare. Microchip also took a different approach to dual core MCU with the PIC24CH. It uses hardware FIFO and mailboxes for IPC. This actually can allow you to make the secondary core behave like a block of hardware. RP2040 uses a more cost optimized and general purpose approach. RP20240 actually is faster in certain applications. The Pi has issues with its IO subsystem which this avoids. In terms of IPC, multiple SRAM approach has been used in BeagleBone Black and ST32. These usually share IO space while the PIC24CH mostly kept them separate. There is reasons for each approach. The concern for software execution performance becomes a challenge. People dump into RAM to avoid this in embedded Linux. ISR, branches, etc. all take hit from cache/memory miss. Hardware does not need instructions, so this can be avoided. However has different programming model. Strong CPU core is useful for closing event response and configuration time. Heavy load handled by hardware in controllers. Edit: It has FIFOs and mailboxes. You make the RP2040 secondary core look like hardware! This can allow for some interesting C software tricks. You can use a PIO or core to spoof HUB75 interface internally. I may have buy one, just to have one around.

@SgtScourge 3 роки тому

"On-chip programmable LDO to generate core voltage" Does this allow me to run the pico at 2.75v or maybe communicate with an analog 2.75v device? If not, what does this feature do?

@tannewt 3 роки тому

If I remember right the io can only do 3.3v or 1.8v.

@davidthacher1397 3 роки тому

I think this is supported. In this case you would just power the everything at 2.75. There may be some performance loss. You may need to configure the IO buffers slightly, but probably not. (See RP2040 VOLTAGE_SELECT register, RP2040 GPIOx registers and RP2040 Section 2.19.4) If working with the RP2040 chip directly there is a lot of options. However the Pico is designed to work at 3.3V. If willing to risk damage to the Pico you could try the following: The Pico uses regulator to drop/up the USB VBUS or VSYS voltage to 3.3V. This regulator appears to support a shutdown function with the 3V3_EN signal. You could possibly back power the main 3V3 rail to 2.75. It may be recommended to disable regulator by grounding 3V3_EN, when doing this. (Pico Section 4.4) The internal logic runs at 1.1V. You can provide power directly to the core on DVDD. (RP2040 Section 2.9.2) The LDO allows you to power the core from the IOVDD power rail. You must pass a voltage between 1.8 and 3.3V. (RP2040 Section 2.9.1 and 2.9.3) The ADC can be powered externally via ADC_AVDD. However the IOVDD sets limits for the pins. (RP2040 Section 2.9.5) Would have been nice if you could cut the trace for the regulator. (However that is not easy here, but is possible.) Note for analog performance you may want to consider GPIO23. (Pico Section 4.4) Usually for analog you use linear regulator, but that may be nonsense. You may be able to just lift the regulator from the Pico using hot air. This may be repairable later on or perhaps you just use it with external supply. IOVDD is set to 1.62 to 3.63. With IOBUF settings for ranges equal to or larger than 2.5 and less than or equal to 1.8. IO standard compliance is likely somewhere around 1.8 and 3.3. 2.5 is another standard, but I am not sure it was considered. (RP2040 Section 5.3) Take this with a grain of salt.