Programming Arduino MCU and RP2040 on Custom Boards Using Arduino IDE

[Lindley]

Yes, your summary is ok, but you would need some isolation procedure if wanting to use the SPI pins for programming and the user circuit.
Using the typical Serial Pins ( as do the Arduino boards and Serial Monitor)  would seem a better way to  upload the user program.

The AVR chips have been in use for so many years and will doubltess be around for some time, but everything changes with time.

Would suggest you get hold of an Arduino Uno or similar and gain practical expereince of it and the Arduino IDE  before even considering things like the RP controllers.

[tooki]

It’s possible to burn the bootloader onto an AVR using the SPI pins with another Arduino acting as the programmer and the Arduino IDE. Once the AVR has the bootloader, it can be programmed using external USB cables or onboard chips like the CH430/FTDI or still through the SPI pins.

(Since you keep repeating the error over and over: it's CH340, not CH430.)

I think you missed my point: if you program via the SPI pins, you do not need a bootloader. The bootloader's job is to add serial programming. If you use SPI programming, you skip the bootloader altogether. In fact, if you use SPI programming, you will overwrite (=delete) the bootloader if you had flashed it before.

Consider:
-Using AVR with bootloader:
Step 1. Connect SPI programmer.
Step 2. Flash bootloader.
Step 3. Disconnect SPI programmer.
Step 4. Connect serial adapter (if no USB bridge built in) or USB cable (if USB bridge built in)
Step 5. Upload sketch via serial.
Step 6. Disconnect serial adapter or USB cable.

-Using AVR without bootloader:
Step 1. Connect SPI programmer.
Step 2. Flash the sketch.
Step 3. Disconnect SPI programmer.

The sole advantage of using the bootloader is if you want your users to be able to upload new firmware without needing an SPI programmer. Other than that there are no advantages at all.

But what will happen if other devices are on board and connected also to these SPI pins. Will they be damaged during programming??

Depends on your circuit design. Ideally, you'll either leave them free, or share them with things where it does not matter. Otherwise, you can program the MCUs before installing them in the board, and/or use some 0 ohm jumpers to make it possible to isolate the rest of the circuit if need be.

If you use SPI programming, you can completely free up the IO0 and IO1 pins, which are normally used up for serial programming -- as long as you don't need that serial for communication with the running MCU, of course!

The reason I'm pursuing this is that, although I prefer using the Arduino IDE (I'm still fairly new to programming), I can't rely on Arduino boards being around long-term, as they are frequently updated or become obsolete.

LOL what?!?! Arduino keeps most board models around forever! The Arduino Uno has been around since 2010 and is still sold today. (The Uno R3 revision with 328p chip, the most popular Arduino board, has been sold since at least 2013, and is still sold today.) They keep adding new models, but haven't retired all that many. And even when they do, it's no big deal. One of the biggest strengths of the Arduino platform is portability between not just boards, but entire architectures. I can write the same code and run it nearly or entirely unchanged on an Arduino Uno, an ESP32, a Teensy, a Rpi Pico, or STM32 Nucleo board. (All you really need to change is the pin numbers.) The only major MCU architecture that is categorically unsupported on Arduino is PIC -- and there has been some work towards this, but never quite to completion.

In fact, I often do this when first developing algorithms for a sketch: write and debug on an Uno, then use it on an ESP32. (Compiling for ESP32 takes way longer than compiling for AVR, so it's faster to develop on AVR.) If possible, I do SPI programming since it uploads even faster.


Where things get hairier is if you start using hardware features specific to the MCU in question. You can sometimes use libraries that abstract this away in a way that is hardware-agnostic (or that actually uses each MCU's hardware features to do it). For example, the TaskmanagerIO library lets you schedule things, and under the hood it will use the timers of the MCU you're using, or of the underlying FreeRTOS on the ESP32 or Rpi Pico. With the Uno being fairly basic, moving up to a bigger MCU is rarely a problem.



In the end, chances are you will want to migrate away from AVR sooner than any other factor would force you to.

The AVR chips, on the other hand, are likely to outlast them, so I'm considering directly integrating the AVRs into my designs.

Arduino is open source, so as long as Microchip keeps making the chips, clone makers will keep making Arduino boards if there's demand for them, regardless of what Arduino itself decides to do. You can also do it yourself quite easily. But there is absolutely no reason to assume Arduino itself will stop, and as I said, even if they did, it doesn't matter.


I assume we are talking about hobby projects here. I would not integrate Arduino boards into a commercial product. You'd integrate a modern MCU directly.

I agree that performance-wise, these devices aren't the best. That's why I'm also researching RP2040 devices and, eventually, the RP2350. I still need to figure out their bootloading and programming processes as bare chips, but that might be a topic for another discussion.

It's fundamentally the same as a Rpi Pico. The bootloader is factory-programmed in ROM. See e.g. https://raspberrypi.stackexchange.com/questions/145812/how-to-program-a-rp2040-chip-i-dont-have-a-pico-board-just-the-chip-im-bui

You must provide the Flash memory chip, then the factory bootloader lets you program it.

[dobsonr741]

How can I program an RP2040 using Picoprobe and the Arduino IDE if I design my own board around the RP2040?

The RP2040 has the bootloader in ROM, as it comes from the factory. Simple as that. Just plug into USB, hold BOOTSEL down, reset.

If interested in the bootloader source, here it is: https://github.com/raspberrypi/pico-bootrom-rp2040

More on the boot process: https://vanhunteradams.com/Pico/Bootloader/Boot_sequence.html#Hardware-controlled-boot-sequence

[brucehoult]

If you do decide to use a bootloader and USB-serial bridge, instead of the CH340 or other no-name Chinese chip, I'd use an FT232 or CP2102N. The FTDI chips are the best supported out of the box on a wide array of OSes.

WCH are not a "no name" Chinese company. They have been around for a long time, and large numbers of manufacturers have switched from FTDI to CH340 for price, features, and non-being-bastards reasons.

SparkFun, for example, uses the CH340 on a lot of products now, and have driver install instructions here...

https://learn.sparkfun.com/tutorials/how-to-install-ch340-drivers/all

Maybe not OOTB (yet), but not exactly hard.

[westfw]

WCH are not a "no name" Chinese company.

Also, They’ve done an impressive job of providing documentation and support for “western” users.
(And particularly low volume and hobbyist users.)
Between WCH, Espressif, and Seeed, the whole landscape has shifted, wrt using “Chinese technology”
Hopefully it won’t be destroyed by the next US administration.

[tooki]

If you do decide to use a bootloader and USB-serial bridge, instead of the CH340 or other no-name Chinese chip, I'd use an FT232 or CP2102N. The FTDI chips are the best supported out of the box on a wide array of OSes.

WCH are not a "no name" Chinese company. They have been around for a long time, and large numbers of manufacturers have switched from FTDI to CH340 for price, features, and non-being-bastards reasons.

SparkFun, for example, uses the CH340 on a lot of products now, and have driver install instructions here...

https://learn.sparkfun.com/tutorials/how-to-install-ch340-drivers/all

Maybe not OOTB (yet), but not exactly hard.

My wording was suboptimal; I intended it as CH340 + (no-name Chinese chips), not as WCH being no-name.

However, my advice to not use it stands, insofar as FTDI and SiLabs are much better known, and meet OP’s request of being available from DigiKey and Mouser.

[brucehoult]

Between WCH, Espressif, and Seeed, the whole landscape has shifted, wrt using “Chinese technology”

Yeah, Seeed have been around for a while now. I think the below were my first two orders from them, in May and June 2013. Some 433 MHz transmitters (which I used to control Jaycar remote control 240V sockets from an Arduino), then nRF2401 for things that needed 2-way or at least ACK'd communication. Those things were like $3 each at a time when Zigbee, WIFI, BT cost a fortune.

The nRF2401 were basically a UDP-like thing with limited size (32 byte) packets, but you could build whatever protocol you wanted on top of them. The code size to drive them was trivial. Soon after I got them I demonstrated at a conference using one attached to a Freetronics LeoStick (ATmega32U4) stuck in a USB port on my MacBook Pro, communicating across a room to a battery powered Pro Mini with a couple of 5g RC servos attached. I whipped up a quick and dirty Mac app using Interface Builder (ObjC) that let me wiggle sliders on the Mac screen and the RC servos moved in sync with them.

[Sariel]

Thank you all for the additional insights.

To summarize:

There are two main options for programming standalone bare AVR devices:

1. SPI Programming via Arduino (or compatible programmer): Using the ISP method, you can burn the bootloader. Once the bootloader is in place, you can program the device using the serial communication method (e.g., USB to UART) via an FTDI-USB cable or onboard chip.

2. Direct Programming via SPI Pins: This option skips the bootloader entirely, allowing you to directly program the device through the SPI pins.

Since I'd like to allow other users to reprogram my board easily, I'll stick with the USB-UART method, meaning I'll need to burn the bootloader.


I also need to ensure that any other devices connected to the SPI lines are disconnected during programming.
This can be done using a 2x3 pin header connector (0.1” pitch) with jumpers or by using jumper resistors.

When using ISP programming, the CS pin isn't used, correct?



Regarding the RP2040, since it comes with a built-in ROM bootloader, I can simply hold the reset button while powering and connecting via USB, allowing me to upload the program file through drag-and-drop. But how do I upload code through the Arduino IDE? If I stick to the Arduino HAL while still working with the RP2040?

Lastly, I need onboard Flash for storing programs. Isn't the RP2040’s internal Flash sufficient for simple programs?

And how difficult is the transition from Arduino IDE with AVR to RP MCUs? Is it just a slight increase in complexity (a few dB) or more like a 30-40dB jump?

[tooki]

When using ISP programming, the CS pin isn't used, correct?

See https://ww1.microchip.com/downloads/en/Appnotes/Atmel-0943-In-System-Programming_ApplicationNote_AVR910.pdf

Regarding the RP2040, since it comes with a built-in ROM bootloader, I can simply hold the reset button while powering and connecting via USB, allowing me to upload the program file through drag-and-drop. But how do I upload code through the Arduino IDE? If I stick to the Arduino HAL while still working with the RP2040?

https://letmegooglethat.com/?q=rpi+pico+how+to+upload+from+arduino+ide

Lastly, I need onboard Flash for storing programs. Isn't the RP2040’s internal Flash sufficient for simple programs?

What internal Flash? It doesn't have any! The last digit in "RP2040" (the ones column) refers to the amount of built-in nonvolatile memory: RP2040 = 0kB.

Rpi has plenty of information on building your own RP2040 boards, including the design files for the Rpi Pico series, a KiCad project for the minimum viable system, and a "Hardware Design with RP2040" design guide. All on https://www.raspberrypi.com/documentation/microcontrollers/silicon.html#rp2040

See e.g. https://datasheets.raspberrypi.com/rp2040/hardware-design-with-rp2040.pdf page 8

And how difficult is the transition from Arduino IDE with AVR to RP MCUs? Is it just a slight increase in complexity (a few dB) or more like a 30-40dB jump?

As I said above: for simple sketches, there is zero additional complexity, other than initial configuration of the IDE to add board support. I thought I made it abundantly clear that one of the Arduino platform's biggest strengths is the ease of moving from architecture to architecture.

[tooki]

P.S.

Since I'd like to allow other users to reprogram my board easily, I'll stick with the USB-UART method, meaning I'll need to burn the bootloader.

FYI, on both ESP32 and Rpi Pico with Wifi, you can do OTA (over-the-air) updates. I haven't done it on Rpi Pico yet, but on ESP32 it's ridiculously easy to set up. Huge advantage to this is closed-box firmware updates, and no chance that your USB-serial bridge chip will require driver installation, which some users may be unable to do.

[Sariel]

Is there also a need to change the pin numbers in the code, sometimes when moving from one architecture to another?

[tooki]

Is there also a need to change the pin numbers in the code, sometimes when moving from one architecture to another?

I already explained this yesterday.

...
One of the biggest strengths of the Arduino platform is portability between not just boards, but entire architectures. I can write the same code and run it nearly or entirely unchanged on an Arduino Uno, an ESP32, a Teensy, a Rpi Pico, or STM32 Nucleo board. (All you really need to change is the pin numbers.) ...

[Lindley]

Hey @Sariel,   wondered which direction you had decided on , the AVR or Pico route with the Ardunio IDE ?

Your interest in the Pico and Pico2 (RP2350) made us have a closer look at the latter and just received a basic board which has loaded a test program ok, but as you can see from this forum thread about the Pico2 it has a lot points to consider so probably worthwhile you starting off with the AVR, though as we do not know in any detail what you are expecting such a chip to do on your boards is hard to be sure if either will do what you want.

https://www.eevblog.com/forum/microcontrollers/possible-click-bait-title-the-raspberry-pi-pico-2-now-has-extra-risc-v-cores/

[Sariel]

Hey @Sariel,   wondered which direction you had decided on , the AVR or Pico route with the Ardunio IDE ?

Your interest in the Pico and Pico2 (RP2350) made us have a closer look at the latter and just received a basic board which has loaded a test program ok, but as you can see from this forum thread about the Pico2 it has a lot points to consider so probably worthwhile you starting off with the AVR, though as we do not know in any detail what you are expecting such a chip to do on your boards is hard to be sure if either will do what you want.

https://www.eevblog.com/forum/microcontrollers/possible-click-bait-title-the-raspberry-pi-pico-2-now-has-extra-risc-v-cores/

After reviewing all the responses and consolidating the information, I've developed a structured work and learning plan for myself.

I'll begin by focusing on AVR devices, working initially with Arduino modules. I plan to establish communication with some of the devices I commonly use and test code transfer between different modules. Once I get comfortable with this, I'll design my own AVR board or a stamp-sized version and integrate it into my circuits.

Next, I'll move on to the RP2040 (PICO board) and then aftwerward experiment with direct integration.
I noticed that the Pico board has a lot of unused area, making it less efficient for my needs.
I have a strong feeling that the RP2040 will remain relevant for a few more years, making it a solid choice for integration, even in some of my more advanced modules. I don't thing these MCU will have any longevity problems.

Since I primarily use MCUs for control and monitoring rather than data processing, these devices should be more than adequate.
Once I gain more confidence, I'll move on to STM32 devices and start using the Cube HAL library for more complex projects.

[SiliconWizard]

The nRF2401 were basically a UDP-like thing with limited size (32 byte) packets, but you could build whatever protocol you wanted on top of them. The code size to drive them was trivial.

The later revision was the nRF24L01+ with some improvements. It's now obsoleted, which is a shame. It was very easy to use, drew minimal power and allowed you to implement custom protocols in a much easier way than what you can do these days with their MCU-based RF chips, which require firmware inside the chip with a much steeper learning curve (unless you just use ready-to-use examples with one of the standard protocols).

I still have a bunch of nRF24L01+. You can more or less find "equivalents" (although more expensive, but also with deeper FIFOs and more features) from Semtech now, both for the 2.4GHz band and for the sub-GHz bands.