diff --git a/documentation/asciidoc/computers/config_txt/overclocking.adoc b/documentation/asciidoc/computers/config_txt/overclocking.adoc index 40768eee4..1c7f33910 100644 --- a/documentation/asciidoc/computers/config_txt/overclocking.adoc +++ b/documentation/asciidoc/computers/config_txt/overclocking.adoc @@ -57,7 +57,7 @@ WARNING: Setting any overclocking parameters to values other than those used by | SDRAM phy voltage adjustment. [-16,8] equates to [0.8V,1.4V] with 0.025V steps. Not supported on Raspberry Pi 4 or later devices. | force_turbo -| Forces turbo mode frequencies even when the ARM cores are not busy. Enabling this may set the warranty bit if `over_voltage_*` is also set. +| Forces turbo mode frequencies even when the Arm cores are not busy. Enabling this may set the warranty bit if `over_voltage_*` is also set. | initial_turbo | Enables https://forums.raspberrypi.com/viewtopic.php?f=29&t=6201&start=425#p180099[turbo mode from boot] for the given value in seconds, or until `cpufreq` sets a frequency. The maximum value is `60`. The November 2024 firmware update made the following changes: @@ -339,9 +339,9 @@ NOTE: There is no need to use `hdmi_enable_4kp60` on Flagship models since Raspb ==== `force_turbo` -By default (`force_turbo=0`) the on-demand CPU frequency driver will raise clocks to their maximum frequencies when the ARM cores are busy, and will lower them to the minimum frequencies when the ARM cores are idle. +By default (`force_turbo=0`) the on-demand CPU frequency driver will raise clocks to their maximum frequencies when the Arm cores are busy, and will lower them to the minimum frequencies when the Arm cores are idle. -`force_turbo=1` overrides this behaviour and forces maximum frequencies even when the ARM cores are not busy. +`force_turbo=1` overrides this behaviour and forces maximum frequencies even when the Arm cores are not busy. === Clocks relationship @@ -349,7 +349,7 @@ By default (`force_turbo=0`) the on-demand CPU frequency driver will raise clock The GPU core, CPU, SDRAM and GPU each have their own PLLs and can have unrelated frequencies. The h264, v3d and ISP blocks share a PLL. -To view the Raspberry Pi's current frequency in KHz, type: `cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq`. Divide the result by 1000 to find the value in MHz. Note that this frequency is the kernel _requested_ frequency, and it is possible that any throttling (for example at high temperatures) may mean the CPU is actually running more slowly than reported. An instantaneous measurement of the actual ARM CPU frequency can be retrieved using the vcgencmd `vcgencmd measure_clock arm`. This is displayed in Hertz. +To view the Raspberry Pi's current frequency in KHz, type: `cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq`. Divide the result by 1000 to find the value in MHz. Note that this frequency is the kernel _requested_ frequency, and it is possible that any throttling (for example at high temperatures) may mean the CPU is actually running more slowly than reported. An instantaneous measurement of the actual Arm CPU frequency can be retrieved using the vcgencmd `vcgencmd measure_clock arm`. This is displayed in Hertz. === Monitoring core temperature [.whitepaper, title="Cooling a Raspberry Pi device", subtitle="", link=https://pip.raspberrypi.com/documents/RP-003608-WP-Cooling-a-Raspberry-Pi-device.pdf] @@ -368,7 +368,7 @@ Divide the result by 1000 to find the value in degrees Celsius. Alternatively, y Hitting the temperature limit is not harmful to the SoC, but it will cause the CPU to throttle. A heat sink can help to control the core temperature, and therefore performance. This is especially useful if the Raspberry Pi is running inside a case. Airflow over the heat sink will make cooling more efficient. -When the core temperature is between 80°C and 85°C, the ARM cores will be throttled back. If the temperature exceeds 85°C, the ARM cores and the GPU will be throttled back. +When the core temperature is between 80°C and 85°C, the Arm cores will be throttled back. If the temperature exceeds 85°C, the Arm cores and the GPU will be throttled back. For the Raspberry Pi 3 Model B+, the PCB technology has been changed to provide better heat dissipation and increased thermal mass. In addition, a soft temperature limit has been introduced, with the goal of maximising the time for which a device can "sprint" before reaching the hard limit at 85°C. When the soft limit is reached, the clock speed is reduced from 1.4GHz to 1.2GHz, and the operating voltage is reduced slightly. This reduces the rate of temperature increase: we trade a short period at 1.4GHz for a longer period at 1.2GHz. By default, the soft limit is 60°C. This can be changed via the `temp_soft_limit` setting in `config.txt`. @@ -378,7 +378,7 @@ It is essential to keep the supply voltage above 4.8V for reliable performance. To monitor the Raspberry Pi's PSU voltage, you will need to use a multimeter to measure between the VCC and GND pins on the GPIO. More information is available in the xref:raspberry-pi.adoc#power-supply[power] section of the documentation. -If the voltage drops below 4.63V (±5%), the ARM cores and the GPU will be throttled back, and a message indicating the low voltage state will be added to the kernel log. +If the voltage drops below 4.63V (±5%), the Arm cores and the GPU will be throttled back, and a message indicating the low voltage state will be added to the kernel log. The Raspberry Pi 5 PMIC has built in ADCs that allow the supply voltage to be measured. To view the current supply voltage, run the following command: diff --git a/documentation/asciidoc/computers/configuration/device-tree.adoc b/documentation/asciidoc/computers/configuration/device-tree.adoc index 248fd63cf..af8aad80b 100644 --- a/documentation/asciidoc/computers/configuration/device-tree.adoc +++ b/documentation/asciidoc/computers/configuration/device-tree.adoc @@ -725,7 +725,7 @@ dtoverlay= [[part3.3]] ==== Board-specific labels and parameters -Raspberry Pi boards have two I2C interfaces. These are nominally split: one for the ARM, and one for VideoCore (the GPU). On almost all models, `i2c1` belongs to the ARM and `i2c0` to VC, where it is used to control the camera and read the HAT EEPROM. However, there are two early revisions of the Model B that have those roles reversed. +Raspberry Pi boards have two I2C interfaces. These are nominally split: one for the Arm CPU, and one for the VideoCore GPU. On almost all models, `i2c1` belongs to the CPU and `i2c0` to the GPU, where it is used to control the camera and read the HAT EEPROM. However, there are two early revisions of the Model B that have those roles reversed. To make it possible to use one set of overlays and parameters with all Raspberry Pis, the firmware creates some board-specific DT parameters. These are: diff --git a/documentation/asciidoc/computers/legacy_config_txt/memory.adoc b/documentation/asciidoc/computers/legacy_config_txt/memory.adoc index 11996ade0..7edd2327a 100644 --- a/documentation/asciidoc/computers/legacy_config_txt/memory.adoc +++ b/documentation/asciidoc/computers/legacy_config_txt/memory.adoc @@ -50,5 +50,5 @@ The `gpu_mem_1024` command sets the GPU memory in megabytes for Raspberry Pis wi === `disable_l2cache` -Setting this to `1` disables the CPU's access to the GPU's L2 cache and requires a corresponding L2 disabled kernel. Default value on BCM2835 is `0`. On BCM2836, BCM2837, BCM2711, and BCM2712, the ARMs have their own L2 cache and therefore the default is `1`. The standard Raspberry Pi `kernel.img` and `kernel7.img` builds reflect this difference in cache setting. +Setting this to `1` disables the CPU's access to the GPU's L2 cache and requires a corresponding L2 disabled kernel. Default value on BCM2835 is `0`. On BCM2836, BCM2837, BCM2711, and BCM2712, the Arm CPUs have their own L2 cache and therefore the default is `1`. The standard Raspberry Pi `kernel.img` and `kernel7.img` builds reflect this difference in cache setting. diff --git a/documentation/asciidoc/computers/os/graphics-utilities.adoc b/documentation/asciidoc/computers/os/graphics-utilities.adoc index b37e8ab81..3c44bfcaf 100644 --- a/documentation/asciidoc/computers/os/graphics-utilities.adoc +++ b/documentation/asciidoc/computers/os/graphics-utilities.adoc @@ -84,7 +84,7 @@ This returns the current frequency of the specified clock. Accepts the following | clock | Description | `arm` -| ARM core(s) +| Arm core(s) | `core` | GPU core diff --git a/documentation/asciidoc/computers/processors/bcm2711.adoc b/documentation/asciidoc/computers/processors/bcm2711.adoc index 70ea47ee8..4d199dfa7 100644 --- a/documentation/asciidoc/computers/processors/bcm2711.adoc +++ b/documentation/asciidoc/computers/processors/bcm2711.adoc @@ -1,12 +1,12 @@ == BCM2711 -This is the Broadcom chip used in the Raspberry Pi 4 Model B, Compute Module 4, and Pi 400. The architecture of the BCM2711 is a considerable upgrade on that used by the SoCs in earlier Raspberry Pi models. It continues the quad-core CPU design of the BCM2837, but uses the more powerful ARM A72 core. It has a greatly improved GPU feature set with much faster input/output, due to the incorporation of a PCIe link that connects the USB 2 and USB 3 ports, and a natively attached Ethernet controller. It is also capable of addressing more memory than the SoCs used before. +This is the Broadcom chip used in the Raspberry Pi 4 Model B, Compute Module 4, and Pi 400. The architecture of the BCM2711 is a considerable upgrade on that used by the SoCs in earlier Raspberry Pi models. It continues the quad-core CPU design of the BCM2837, but uses the more powerful Arm A72 core. It has a greatly improved GPU feature set with much faster input/output, due to the incorporation of a PCIe link that connects the USB 2 and USB 3 ports, and a natively attached Ethernet controller. It is also capable of addressing more memory than the SoCs used before. -The ARM cores are capable of running at up to 1.5 GHz, making the Raspberry Pi 4 about 50% faster than the Raspberry Pi 3B+. The new VideoCore VI 3D unit now runs at up to 500 MHz. The ARM cores are 64-bit, and while the VideoCore is 32-bit, there is a new Memory Management Unit, which means it can access more memory than previous versions. +The Arm cores are capable of running at up to 1.5 GHz, making the Raspberry Pi 4 about 50% faster than the Raspberry Pi 3B+. The new VideoCore VI 3D unit now runs at up to 500 MHz. The Arm cores are 64-bit, and while the VideoCore is 32-bit, there is a new Memory Management Unit, which means it can access more memory than previous versions. The BCM2711 chip continues to use the heat spreading technology started with the BCM2837B0, which provides better thermal management. -*Processor:* Quad-core https://en.wikipedia.org/wiki/ARM_Cortex-A72[Cortex-A72] (ARM v8) 64-bit SoC @ 1.5 GHz. +*Processor:* Quad-core https://en.wikipedia.org/wiki/ARM_Cortex-A72[Cortex-A72] (Armv8-A) 64-bit SoC @ 1.5 GHz. *Memory:* Accesses up to 8GB LPDDR4-2400 SDRAM (depending on model) diff --git a/documentation/asciidoc/computers/processors/bcm2712.adoc b/documentation/asciidoc/computers/processors/bcm2712.adoc index 8adae73ed..e4a97e657 100644 --- a/documentation/asciidoc/computers/processors/bcm2712.adoc +++ b/documentation/asciidoc/computers/processors/bcm2712.adoc @@ -7,7 +7,7 @@ Built around a quad-core Arm Cortex-A76 CPU cluster, clocked at up to 2.4GHz, wi Headline features include: * Quad-core Arm Cortex-A76 @ 2.4GHz -** ARMv8-A ISA +** Armv8-A ISA ** 64KByte I and D caches ** 512KB L2 per core, 2MB shared L3 * New Raspberry Pi-developed ISP diff --git a/documentation/asciidoc/computers/processors/bcm2837.adoc b/documentation/asciidoc/computers/processors/bcm2837.adoc index 16694e5f9..b776c301a 100644 --- a/documentation/asciidoc/computers/processors/bcm2837.adoc +++ b/documentation/asciidoc/computers/processors/bcm2837.adoc @@ -1,10 +1,10 @@ == BCM2837 -This is the Broadcom chip used in the Raspberry Pi 3 Model B, later models of the Raspberry Pi 2 Model B, and the Raspberry Pi Compute Module 3. The underlying architecture of the BCM2837 is identical to the BCM2836. The only significant difference is the replacement of the ARMv7 quad core cluster with a quad-core ARM Cortex A53 (ARMv8) cluster. +This is the Broadcom chip used in the Raspberry Pi 3 Model B, later models of the Raspberry Pi 2 Model B, and the Raspberry Pi Compute Module 3. The underlying architecture of the BCM2837 is identical to the BCM2836. The only significant difference is the replacement of the Armv7 quad core cluster with a quad-core Arm Cortex A53 (Armv8) cluster. -The ARM cores run at 1.2GHz, making the device about 50% faster than the Raspberry Pi 2. The VideoCore IV runs at 400MHz. +The Arm cores run at 1.2GHz, making the device about 50% faster than the Raspberry Pi 2. The VideoCore IV runs at 400MHz. -Please refer to the following BCM2836 document for details on the ARM peripherals specification, which also applies to the BCM2837. +Please refer to the following BCM2836 document for details on the Arm peripherals specification, which also applies to the BCM2837. -* https://datasheets.raspberrypi.com/bcm2836/bcm2836-peripherals.pdf[BCM2836 ARM-local peripherals] +* https://datasheets.raspberrypi.com/bcm2836/bcm2836-peripherals.pdf[BCM2836 Arm-local peripherals] * https://developer.arm.com/documentation/ddi0500/latest/[Cortex-A53 MPCore Processor Technical Reference Manual] diff --git a/documentation/asciidoc/computers/processors/bcm2837b0.adoc b/documentation/asciidoc/computers/processors/bcm2837b0.adoc index 3589bdf10..2ee24cc4b 100644 --- a/documentation/asciidoc/computers/processors/bcm2837b0.adoc +++ b/documentation/asciidoc/computers/processors/bcm2837b0.adoc @@ -1,8 +1,8 @@ == BCM2837B0 -This is the Broadcom chip used in the Raspberry Pi 3 Models A+, B+, and the Raspberry Pi Compute Module 3+. The underlying architecture of the BCM2837B0 is identical to the BCM2837 chip used in other versions of the Raspberry Pi. The ARM core hardware is the same, only the frequency is rated higher. +This is the Broadcom chip used in the Raspberry Pi 3 Models A+, B+, and the Raspberry Pi Compute Module 3+. The underlying architecture of the BCM2837B0 is identical to the BCM2837 chip used in other versions of the Raspberry Pi. The Arm core hardware is the same, only the frequency is rated higher. -The ARM cores are capable of running at up to 1.4GHz, making the 3B+/3A+ about 17% faster than the original Raspberry Pi 3. The VideoCore IV runs at 400MHz. The ARM core is 64-bit, while the VideoCore IV is 32-bit. +The Arm cores are capable of running at up to 1.4GHz, making the 3B+/3A+ about 17% faster than the original Raspberry Pi 3. The VideoCore IV runs at 400MHz. The Arm core is 64-bit, while the VideoCore IV is 32-bit. The BCM2837B0 chip is packaged slightly differently to the BCM2837, and most notably includes a heat spreader for better thermals. This allows higher clock frequencies, and more accurate monitoring and control of the chip's temperature. diff --git a/documentation/asciidoc/computers/processors/rp3a0.adoc b/documentation/asciidoc/computers/processors/rp3a0.adoc index 4ec33136a..6faeed7bf 100644 --- a/documentation/asciidoc/computers/processors/rp3a0.adoc +++ b/documentation/asciidoc/computers/processors/rp3a0.adoc @@ -1,6 +1,6 @@ == RP3A0 -The Raspberry Pi RP3A0 is our first System-in-Package (SiP) consisting of a Broadcom BCM2710A1 — which is the silicon die packaged inside the Broadcom xref:processors.adoc#bcm2837[BCM2837] chip which is used on the xref:raspberry-pi.adoc#raspberry-pi-3-model-b-2[Raspberry Pi 3] — along with 512MB of DRAM. +The Raspberry Pi RP3A0 is our first System-in-Package (SiP) consisting of a Broadcom BCM2710A1 — which is the silicon die packaged inside the Broadcom xref:processors.adoc#bcm2837[BCM2837] chip which is used on the xref:raspberry-pi.adoc#raspberry-pi-3-model-b-2[Raspberry Pi 3] — along with 512MB of DRAM. It is used by the xref:raspberry-pi.adoc#raspberry-pi-zero-2-w[Raspberry Pi Zero 2 W]. @@ -8,12 +8,12 @@ image:images/RP3A0-crosssection.png[width="70%"] The RP3A0 is a Quad-core 64-bit Arm Cortex A53 CPU clocked at 1 GHz, although with a heat sink or other cooling solution in place, the chip can be potentially overclocked to 1.2 GHz. -Please refer to the following BCM2836 document for details on the ARM peripherals specification, which also applies to the BCM2837 and RP3A0. +Please refer to the following BCM2836 document for details on the Arm peripherals specification, which also applies to the BCM2837 and RP3A0. -* https://datasheets.raspberrypi.com/bcm2836/bcm2836-peripherals.pdf[BCM2836 ARM-local peripherals] +* https://datasheets.raspberrypi.com/bcm2836/bcm2836-peripherals.pdf[BCM2836 Arm-local peripherals] * https://developer.arm.com/documentation/ddi0500/latest/[Cortex-A53 MPCore Processor Technical Reference Manual] [NOTE] ==== -The original xref:raspberry-pi.adoc#raspberry-pi-zero[Raspberry Pi Zero] uses Package-on-Package (PoP) DRAM, where the DRAM is soldered directly on top of the xref:processors.adoc#bcm2835[BCM2835] chip. +The original xref:raspberry-pi.adoc#raspberry-pi-zero[Raspberry Pi Zero] uses Package-on-Package (PoP) DRAM, where the DRAM is soldered directly on top of the xref:processors.adoc#bcm2835[BCM2835] chip. ==== diff --git a/documentation/asciidoc/computers/raspberry-pi/boot-gpio.adoc b/documentation/asciidoc/computers/raspberry-pi/boot-gpio.adoc index 6545bc3c9..337261155 100644 --- a/documentation/asciidoc/computers/raspberry-pi/boot-gpio.adoc +++ b/documentation/asciidoc/computers/raspberry-pi/boot-gpio.adoc @@ -87,4 +87,4 @@ NOTE: The various boot modes are attempted in the numerical order of the GPIO li SD0 is the Broadcom SD card/MMC interface. When the boot ROM within the SoC runs, it always connects SD0 to the built-in microSD card slot. On Compute Modules with an eMMC device, SD0 is connected to that; on the Compute Module Lite SD0 is available on the edge connector and connects to the microSD card slot in the CMIO carrier board. SD1 is the Arasan SD card/MMC interface which is also capable of SDIO. All Raspberry Pi models with built-in wireless LAN use SD1 to connect to the wireless chip via SDIO. -The default pull resistance on the GPIO lines is 50KΩ, as documented on page 102 of the https://datasheets.raspberrypi.com/bcm2835/bcm2835-peripherals.pdf[BCM2835 ARM peripherals datasheet]. A pull resistance of 5KΩ is recommended to pull a GPIO line up: this will allow the GPIO to function but not consume too much power. +The default pull resistance on the GPIO lines is 50KΩ, as documented on page 102 of the https://datasheets.raspberrypi.com/bcm2835/bcm2835-peripherals.pdf[BCM2835 Arm peripherals datasheet]. A pull resistance of 5KΩ is recommended to pull a GPIO line up: this will allow the GPIO to function but not consume too much power. diff --git a/documentation/asciidoc/computers/raspberry-pi/bootflow-legacy.adoc b/documentation/asciidoc/computers/raspberry-pi/bootflow-legacy.adoc index 29e7c821d..346c513f5 100644 --- a/documentation/asciidoc/computers/raspberry-pi/bootflow-legacy.adoc +++ b/documentation/asciidoc/computers/raspberry-pi/bootflow-legacy.adoc @@ -39,7 +39,7 @@ Next, the boot ROM checks each of the boot sources for a file called `bootcode.b [NOTE] ==== * If there is no SD card inserted, the SD boot mode takes five seconds to fail. To reduce this and fall back to USB more quickly, you can either insert an SD card with nothing on it or use the GPIO bootmode OTP setting described above to only enable USB. -* The default pull for the GPIOs is defined on page 102 of the https://datasheets.raspberrypi.com/bcm2835/bcm2835-peripherals.pdf[ARM Peripherals datasheet]. If the value at boot time does not equal the default pull, then that boot mode is enabled. +* The default pull for the GPIOs is defined on page 102 of the https://datasheets.raspberrypi.com/bcm2835/bcm2835-peripherals.pdf[Arm Peripherals datasheet]. If the value at boot time does not equal the default pull, then that boot mode is enabled. * USB enumeration is a means of enabling power to the downstream devices on a hub, then waiting for the device to pull the D+ and D- lines to indicate if it is either USB 1 or USB 2. This can take time: on some devices it can take up to three seconds for a hard disk drive to spin up and start the enumeration process. Because this is the only way of detecting that the hardware is attached, we have to wait for a minimum amount of time (two seconds). If the device fails to respond after this maximum timeout, it is possible to increase the timeout to five seconds using `program_usb_boot_timeout=1` in `config.txt`. * MSD boot takes precedence over Ethernet boot. * It is no longer necessary for the first partition to be the FAT partition, as the MSD boot will continue to search for a FAT partition beyond the first one. diff --git a/documentation/asciidoc/computers/raspberry-pi/eeprom-bootloader.adoc b/documentation/asciidoc/computers/raspberry-pi/eeprom-bootloader.adoc index 8be245f72..5ad20922a 100644 --- a/documentation/asciidoc/computers/raspberry-pi/eeprom-bootloader.adoc +++ b/documentation/asciidoc/computers/raspberry-pi/eeprom-bootloader.adoc @@ -152,7 +152,7 @@ The `BOOT_ORDER` property defines the sequence for the different boot modes. It If set to a non-zero value (in seconds), enables a hardware watchdog timer in the bootloader. If the OS is not started within the specified time, the watchdog will reset the system. -The bootloader watchdog is automatically cancelled as soon as the ARM CPU is started. It does **not** monitor the OS after the handover from the bootloader. +The bootloader watchdog is automatically cancelled as soon as the Arm CPU is started. It does **not** monitor the OS after the handover from the bootloader. This is useful for unattended or remote systems to ensure recovery from failed boots (e.g. if the OS never loads). diff --git a/documentation/asciidoc/computers/raspberry-pi/frequency-management.adoc b/documentation/asciidoc/computers/raspberry-pi/frequency-management.adoc index d8baf8c40..e71d65294 100644 --- a/documentation/asciidoc/computers/raspberry-pi/frequency-management.adoc +++ b/documentation/asciidoc/computers/raspberry-pi/frequency-management.adoc @@ -34,7 +34,7 @@ Due to possible system stability problems involved with running an undervoltage, NOTE: This setting has been removed on 5-series devices and is effectively always mode 3. -In addition, a more stepped CPU governor is also used to produce finer-grained control of ARM core frequencies, which means the DVFS is more effective. The steps are now 1500MHz, 1000MHz, 750MHz, and 600MHz. These steps can also help when the SoC is being throttled, and mean that throttling all the way back to 600MHz is much less likely, giving an overall increase in fully loaded performance. +In addition, a more stepped CPU governor is also used to produce finer-grained control of Arm core frequencies, which means the DVFS is more effective. The steps are now 1500MHz, 1000MHz, 750MHz, and 600MHz. These steps can also help when the SoC is being throttled, and mean that throttling all the way back to 600MHz is much less likely, giving an overall increase in fully loaded performance. The default CPU governor is `ondemand`. The governor can be manually changed with the `cpufreq-set` command (from the `cpufrequtils` package) to reduce idle power consumption: @@ -65,7 +65,7 @@ To ensure the best performance for your Raspberry Pi, use an active cooling solu For Raspberry Pi 4, add the https://www.raspberrypi.com/products/raspberry-pi-4-case-fan/[Raspberry Pi 4 Case Fan] to the lid of the Raspberry Pi 4 case. -==== Raspberry Pi 5 fans +==== Raspberry Pi 5 fans For Raspberry Pi 5, use one of the official fan options: diff --git a/documentation/asciidoc/microcontrollers/debug-probe/installing-tools.adoc b/documentation/asciidoc/microcontrollers/debug-probe/installing-tools.adoc index 4ade8e9ca..1ac3f94b4 100644 --- a/documentation/asciidoc/microcontrollers/debug-probe/installing-tools.adoc +++ b/documentation/asciidoc/microcontrollers/debug-probe/installing-tools.adoc @@ -2,7 +2,7 @@ To use the Debug Probe, OpenOCD and the GNU Project Debugger (GDB) are required. An Integrated Development Environment (IDE) may also be useful. -On Raspberry Pi OS, most Linux variants, macOS, and Microsoft Windows, it is recommended to install our VS Code extension. This extension bundles OpenOCD, ARM toolchains, GDB, and register definitions for Pico-series microcontrollers. +On Raspberry Pi OS, most Linux variants, macOS, and Microsoft Windows, it is recommended to install our VS Code extension. This extension bundles OpenOCD, Arm toolchains, GDB, and register definitions for Pico-series microcontrollers. See Chapter 3 of our https://datasheets.raspberrypi.com/pico/getting-started-with-pico.pdf[Getting Started with Raspberry Pi Pico] guide. diff --git a/documentation/asciidoc/microcontrollers/debug-probe/introduction.adoc b/documentation/asciidoc/microcontrollers/debug-probe/introduction.adoc index 89219915a..3703a213c 100644 --- a/documentation/asciidoc/microcontrollers/debug-probe/introduction.adoc +++ b/documentation/asciidoc/microcontrollers/debug-probe/introduction.adoc @@ -4,7 +4,7 @@ image::images/debug-probe.jpg[width="100%"] The Raspberry Pi Debug Probe is a USB device that provides both a UART serial port and a standard Arm Serial Wire Debug (SWD) interface. The probe is designed for easy, solderless, plug-and-play debugging. It has the following features: -* USB to ARM https://developer.arm.com/documentation/ihi0031/a/The-Serial-Wire-Debug-Port\--SW-DP-/Introduction-to-the-ARM-Serial-Wire-Debug\--SWD\--protocol[Serial Wire Debug] (SWD) port +* USB to Arm https://developer.arm.com/documentation/ihi0031/a/The-Serial-Wire-Debug-Port\--SW-DP-/Introduction-to-the-ARM-Serial-Wire-Debug\--SWD\--protocol[Serial Wire Debug] (SWD) port * USB to UART bridge * Compatible with the https://developer.arm.com/documentation/101451/0100/About-CMSIS-DAP[CMSIS-DAP] standard * Works with https://openocd.org/[OpenOCD] and other tools supporting CMSIS-DAP diff --git a/documentation/asciidoc/microcontrollers/debug-probe/swd-connection.adoc b/documentation/asciidoc/microcontrollers/debug-probe/swd-connection.adoc index 33a5f0a2f..7b7fbfa95 100644 --- a/documentation/asciidoc/microcontrollers/debug-probe/swd-connection.adoc +++ b/documentation/asciidoc/microcontrollers/debug-probe/swd-connection.adoc @@ -8,7 +8,7 @@ We recommend the use of the Raspberry Pi Pico VSCode extension, which integrates === Standalone program upload -Once you have built a binary: +Once you have built a binary: [source,console] ---- @@ -21,7 +21,7 @@ NOTE: When you use the Debug Probe to upload a binary the ELF version of the fil This will use `openocd` in server mode, and connect GDB, which gives you breakpoints and single-step over a console interface. -[IMPORTANT] +[IMPORTANT] ====== To allow debugging, you must build your binaries as `Debug` rather than `Release` build type, e.g. @@ -39,7 +39,7 @@ $ make -j4 In a debug build you will get more information when you run it under the debugger, as the compiler builds your program with the information to tell GDB what your program is doing. ====== -NOTE: For computers that are _not_ Raspberry Pis, a variant of GDB that can debug ARM processors is required. Use one of the following alternatives depending on your operating system and device: +NOTE: For computers that are _not_ Raspberry Pis, a variant of GDB that can debug Arm processors is required. Use one of the following alternatives depending on your operating system and device: * On Linux devices, use `gdb-multiarch`. * On macOS and Windows devices, use `arm-none-eabi-gdb` from the toolchain on https://developer.arm.com/downloads/-/arm-gnu-toolchain-downloads[Arm's website] diff --git a/documentation/asciidoc/microcontrollers/silicon/rp2040.adoc b/documentation/asciidoc/microcontrollers/silicon/rp2040.adoc index d6fd01309..f80c1c515 100644 --- a/documentation/asciidoc/microcontrollers/silicon/rp2040.adoc +++ b/documentation/asciidoc/microcontrollers/silicon/rp2040.adoc @@ -37,7 +37,7 @@ power Key features: -* Dual ARM Cortex-M0+ @ 133MHz +* Dual Arm Cortex-M0+ @ 133MHz * 264kB on-chip SRAM in six independent banks * Support for up to 16MB of off-chip Flash memory via dedicated QSPI bus * DMA controller