Rp2040

[Griselda Humbarger]

We are aware of this issue and have sent feedback to R&D to follow up. We apologise for any inconvenience caused.
In fact, when this issue was first released, we already found that some computers would not be able to upload the program, but we have not been able to find the root cause of the problem to cure it. I will urge R&D to resolve the issue as soon as possible.

Note that these steps fix the missing tools blunder that my other post refers to, but does not fix the upper-case blunder that Linux users like @rbehm must fix. (Rather than rename the file, I created a symbolic link.)

With the Arduino tools installed as I showed above, you get a serial port to use with Arduino when you do a non-boot reset. After the very first upload from Arduino the serial port number may (or, maybe, not) change to a new value, which you will use for all subsequent Arduino activity.

In the mean time I solved the download problem myself. I prefer to use a decent C/C++ editor (QtCreator). I use arduino-cli from a makefile. In the makefile I convert the *.elf to *.uf2 and copy it to the device.
But your above description does not solve the SPI problem. Even after restoring the changes you describe.

Now, forward to board package 2.7.2
Now, I2C works. It was not just a matter of renaming some pins in pins_arduino.h, but the Seeed guys worked behind the scenes to get things going with Wire (so all of the libraries that I needed work also).

So far, I have tried to address the original posts in this thread, and with these changes, I could upload and execute programs (including SPI stuff and I2C stuff) from my Windows 10 workstation and from my Raspberry Pi 400.

Footnote:
Just for kicks, I decided to experiment with Arduino 2.0 (Downloaded and installed Arduino IDE 2.0.0-rc9.4 on my Debian workstation). Followed the same procedure to get board package 2.7.2 installed. Same results (rp2040tools are in place, but fails to upload).

From earlier Atmel experience, Atmel Studio allows access to a simulator: you write your C code for a given chip, and can then run the code in the simulator (very, veeery slowly), and do (say) C code tracepoint printout with cycle-leve accuracy; in addition, you can "stimulate" an GPIO input pin with a representation of, say, a UART serial signal, and then see what sort of effect this has on registers. Specifically, I remember this about it:

But barring that - are there any other options for cycle-accurate simulation of RP2040, that could work with an arbitrary .uf2/.elf/.hex executable, and where I could also "stimulate" pins with (say) a digital capture (think .vcd file) of (say) an UART signal?

As far as I know, the Verilog source code of the RP2040 is not open, and is not likely to even be open. The chip contains a lot of 3rd party IP, such as the ARM Cortex-M0+ core, some of the peripherals (the datasheet says that both UART and SPI are based on ARM Primecell), so even if Raspberry Pi wanted, they probably don't have the rights to release the Verilog code of these parts.

In addition, Verilog level model is usually not very useful for simulating the entire chip. The simulation would be very slow, orders of magnitudes slower compared to the actual chip. Synthesizing the verilog model and running it on a capable FPGA chip will probably give you a better performance (if I recall correctly, Raspberry Pi got 40MHz or so when they ran it on FPGA), but that would also be expensive and require some non trivial learning curve to set it up.

I believe that rp2040js is the best bet for you at moment. The simulation is not exactly cycle-accurate (since we don't simulate things like bus contentions, arbitration, etc.), but it's pretty close, and probably a bit more optimistic compared with reality.

Most of the peripherals are there (even though not all the features are present in all of the peripherals), and most notably - the unique PIO peripheral, which is implemented in cycle accurate and is nearly feature complete.

Your program runs in the simulator instruction-by-instruction, so you can do things like single stepping, dumping the registers and poking various memory addresses, and stimulating GPIO pins / reading the results.

You can learn what rp2040js is capable of by watching the free Raspberry Pi Pico and RP2040 - The Deep Dive course. The course uses Wokwi for teaching about the internals of ARM, writing ARM assembly, interacting directly with the peripherals through the registers, debugging your program with GDB, and creating your own PIO state machines.

You asked about using rp2040js outside of a webpage. There are two examples in the repo, using Node.js to run the simulation from the command line: simulating a hex file, and simulating stock MicroPython firmware).

Like many others, I bought the Raspberry Pi Pico (referred to as RP2040 from here on) as soon as it came out. I was incredibly excited by the programmable Input outputs (PIO). The promise of controlling timings and pulses with single clock cycle accuracy is simply amazing.

Unfortunately, the installation of the official SDK on windows is not trivial. Programming the RP2040 from the Arduino IDE is much simpler. Sadly, the Arduino IDE doesn't currently have PIO support. This will change (read more here) but currently, the advice is to use pioasm to compile PIO code and include it then in your main sketch.

This instructable won't teach you how PIO works. That's a whole different set of Instructables. However, it will show you how to compile pioasm and then use it to compile PIO code in the Arduino IDE, on windows. Then you can start learning PIO.

At this point, you run the standard blink example to control your LED. If you are struggling to upload try running 'C:\Users\..\AppData\Local\Arduino15\packages\arduino\hardware\mbed_rp2040\2.0.0\post_install.bat'. I needed to do this on my system due to some admin issues but you may not. Congratulations! You are now blinking on windows in a relatively straightforward manner.

The first step is to write some PIO code. I'm not going to do/explain this. Just download/copy the pio example code here. Once you have this file put the pioasm.exe file in the folder as well. The run the following command at the command prompt from within that folder

Now write the following into an Arduino sketch. Note this is a little different from the Raspberry pi example as it uses the familiar setup() loop() structure. Once you have written and saved the sketch your folder structure should like the one pictured above.

If all that went well you should now be blinking using the PIO. I really hope this gets easier. The PIO is the most attractive feature of the RP2040 and hiding it behind multiple layers of complication is just offputting. I imagine this will change with time.

When It does I am going to seriously consider moving a lot of projects to the RP2040. In the meantime have fun learning about this amazing new microcontroller and its incredibly flexible and precise PIO.

Question/Issue: I am unable to collect microphone data samples through my arduino nano rp2040 connect board: I flashed the rp2040 firmware to the board, and used daemon to connect the board to edge impulse. For the inertial sensor, data is collected just fine. However, when I try to use the on-board microphone, the waveform is blank as data is not being collected from the microphone.

The Arduino Nano RP2040 is not an officially supported board. As such, we do not support the microphone for that board out of the box. Our firmware is built for the Raspberry Pi Pico with some external sensors, which you can read about here: Raspberry Pi RP2040 - Edge Impulse Documentation

Oh, that worked for me on my Arduino RP2040! I honestly did not know we officially supported the microphone on the Arduino RP2040. Do you have Chrome? Can you try using WebUSB (as shown here: -sensor-data-straight-from-your-web-browser) instead of going through the CLI tool to see if that works?

The RP2040 is a simple (dual-core) Arm Cortex-M0+ with no DSP acceleration. As a result, most DSP functions (such as computing MFCCs) are notoriously slow, even though the CPU is running at 133 MHz. If you go to the deployment page, you can see that the MFCC calculations take around 1 sec:

I am completing the second rev of my Dual RP2040 controller which features more I/O as well as CAN bus. The previous rev of the board is working but I did have a catastrophic failure due to some kind of lockup, so I have done my best to reduce the impedance of traces relating to mosfets or their drivers.

A dual channel brushless motor controller based on the RP2040 microcontroller, designed in Kicad. - GitHub - Twisted-Fields/rp2040-motor-controller: A dual channel brushless motor controller based ...

This is really cool, and I would like to have a closer look at things so I can make some more constructive criticism in the future, but the main thing that stands out to me is that you are combining basically two boards into one? Why not just have one board per RP2040?

I have become very much partial to the idea of separating waveform generation from everything else. Waveform generation is by far the most time critical task for many things. It appears to be interfered with greatly and it quickly becomes difficult to write even slightly complicated code when you have to return quickly and do everything fast.

I am already having issues with the lack of floating point that the lepton has when compared to the G431. The RP2040 also does not have floating point. So this is a factor for some applications. However it might be ok.

Also thank you so much for reminding me to change the flash! In an early design review, our reviewer thought the other flash was too big, but now that I have used the board I would really like some space to dump rotating debug logs. I actually had a note to go back to a bigger flash and then forgot to change it, so that was very helpful!

And yes, the biggest feedback I got is that the schematic was a mess. I spent a good bit of time cleaning it up. I have not pushed the changes yet but it is much better now, with better names and clearer organization.

c80f0f1006