[riot-notifications] [RIOT-OS/RIOT] cpu/rpx0xx: port RIOT to the Raspberry Pi RP2040 MCU (#16609)

benpicco notifications at github.com
Thu Jul 8 00:15:25 CEST 2021


@benpicco commented on this pull request.

looks good!
What's the output of `tests/periph_gpio`'s `auto_test`?

> +
+(*) Since the switch is connected to the chip-select pin of the QSPI interface the flash chip RIOT
+is running from via XIP, the switch is difficult to read out from software. This is currently not
+supported.
+
+### Pinout
+
+![Pinout Diagram of RPi Pico](https://projects-static.raspberrypi.org/projects/getting-started-with-the-pico/f009ad94826c2f0cd7573a295897e76955301096/en/images/Pico-R3-Pinout.png)
+
+## Flashing the Board
+
+### Flashing the Board Using OpenOCD
+
+Currently (June 2021), only two methods for debugging via OpenOCD are supported:
+
+1. Using a bit-banging low-level adapter, e.g. via the GPIOs of a Raspberry Pi 4B

Wouldn't any SWD compatible adapter work here?

> +![Pinout Diagram of RPi Pico](https://projects-static.raspberrypi.org/projects/getting-started-with-the-pico/f009ad94826c2f0cd7573a295897e76955301096/en/images/Pico-R3-Pinout.png)
+
+## Flashing the Board
+
+### Flashing the Board Using OpenOCD
+
+Currently (June 2021), only two methods for debugging via OpenOCD are supported:
+
+1. Using a bit-banging low-level adapter, e.g. via the GPIOs of a Raspberry Pi 4B
+2. Using a virtual CMSIS-DAP adapter provided by the second CPU core via
+   https://github.com/majbthrd/pico-debug
+
+Since option 2 requires no additional hardware, this is currently the default. However, you need to
+first "flash" the gimme-cache variant of [pico-debug](https://github.com/majbthrd/pico-debug)
+into RAM using the UF2 bootloader. This will result in the Raspberry Pi Pico showing up as
+CMSIS-DAP debugger. Afterwards run:

How is this done?
Or will the build system take care of that? 

> +bootloader. Once this is done, debugging is as simple as running:
+
+```
+make BOARD=rpi-pico debug
+```
+
+***Beware:*** The `rpi-pico` virtual debugger is not persistent and needs to be "flashed" into RAM
+again after each cold boot. The initialization code of RIOT now seems to play well with the
+debugger, so it remains persistent on soft reboots. If you face issues with losing connection to
+the debugger on reboot, try `monitor reset init` in GDB to soft-reboot instead.
+
+## Known Issues / Problems
+
+### Early state Implementation
+
+Currently no support for the following peripherals is implemented:

we should add the second CPU core to this list

> +#ifndef PERIPH_CONF_H
+#define PERIPH_CONF_H
+
+#include <stdint.h>
+
+#include "cpu.h"
+#include "periph_cpu.h"
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+static const uart_conf_t uart_config[] = {
+    {
+        .dev = UART0,
+        .rx_pin = GPIO_PIN(0,1),

```suggestion
        .rx_pin = GPIO_PIN(0, 1),
```

> @@ -0,0 +1,19 @@
+PICO_DEBUG      ?=
+ROM_LEN         ?= 2097152 # = 2 MiB used in the RPi Pico

since the MCU doesn't come with flash, shouldn't this always be set by the board? 

> +
+#include "macros/units.h"
+#include "cpu_conf_common.h"
+#include "vendor/RP2040.h"
+
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+/**
+ * @brief   ARM Cortex-M specific CPU configuration
+ * @{
+ */
+#define CPU_DEFAULT_IRQ_PRIO            (1U)
+#define CPU_FLASH_BASE                  (0x10000000)

Should we re-use `ROM_START_ADDR` here?

> + */
+
+#include "board.h"
+#include "bitarithm.h"
+#include "irq.h"
+#include "mutex.h"
+#include "periph/gpio.h"
+#include "periph/uart.h"
+#include "periph_cpu.h"
+#include "periph_conf.h"
+#include "io_reg.h"
+
+#include "assert.h"
+
+static uart_isr_ctx_t ctx[UART_NUMOF];
+static mutex_t tx_lock = MUTEX_INIT_LOCKED;

not
```suggestion
static mutex_t tx_lock[UART_NUMOF];
```
?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/RIOT-OS/RIOT/pull/16609#pullrequestreview-701481788
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.riot-os.org/pipermail/notifications/attachments/20210707/6ee21390/attachment-0001.htm>


More information about the notifications mailing list