usb lcd display raspberry pi free sample

This is a new Pi Pico display from Waveshare with many more pixels. It is a 2inch LCD display module, designed for Raspberry Pi Pico, with an embedded ST7789VW driver, 65K RGB colours, 320x240 pixels and an SPI interface. A Pi Pico can be plugged into the rear of the screen for very easy connection without any soldering. It sports 4 simple button switches for user input. It is bright, colourful and easy to program. The makers supply an example program (see below), which includes the display driver, making it very easy to get started. The manufacturer"s wiki can be found at:

It"s the perfect DIY screen for makers and content creators. No subscriptions, and no proprietary software is required to display creative engaging content or advertisements! The base of the Digital Signage display is empty for you to install the media player of your choice.

The CAME-TV Digital Signage screen can be powered from any 5V USB source using a Type-C USB connection. This means you can insert a portable USB battery into the case to power your screen at any location. Or if you need the screen to run longer, you can add your own USB cable to wall adapter.

With a full size HDMI Type A input the screen can be connected to any media player. Small media players such as a Chromecast, Amazon Firestick, or Rasberry Pi can be used and stored inside of the base. With an HDMI adapter you can even plug in an Android smartphone, iPod Touch, or iPhone to play videos or photos.

Please note that the LCD Screen inside the frame is mounted vertically inside of the case. Normal videos or photos will be displayed sideways, so prior to displaying, all photos or videos should be rotated. When creating photos or videos, the optimal size is 800 pixels wide by 1280 pixels in height. Images and videos shouuld be rotated clockwise by 90 degrees and then saved / exported so that they display correctly in the Digital Signage screen.

Obliterate the contents of flash. An example of a NO_FLASH binary (UF2 loaded directly into SRAM and runs in-place there). A useful utility to drag and drop onto your Pico if the need arises.

Runs the lwip-contrib/apps/ping test app under FreeRTOS in NO_SYS=0 (i.e. full FreeRTOS integration) mode. The test app uses the lwIP \em socket API in this case.

An LED blink with the pico_bootsel_via_double_reset library linked. This enters the USB bootloader when it detects the system being reset twice in quick succession, which is useful for boards with a reset button but no BOOTSEL button.

A copy of the TinyUSB device example with the same name, but with a CMakeLists.txt which demonstrates how to add a dependency on the TinyUSB device libraries with the Raspberry Pi Pico SDK

This product supports Windows 10/8.1/8/7 OS.：1. Connect the TOUCH interface of LCD to the USB interface of PC . Waiting for a moment, The touch will be recognized by Windows automatically2. Connect the HDMI interface of LCD to the HDMI port of PC. About 5s later, you can see that the LCD display properly.Note:1) If multi-screens are connected to one PC at the same time, you can only control the cursor by this LCD, so please set the LCD as main screen.2) Some of PC cannot support HDMI screen Hot Plug . In this case, restart the PC can solve.3) Sometimes LCD will flicker because of undersupplying from USB cable of PC. You need to connect an external power supply (5V/2A) to DC port.

Orientation settingDisplay orientationYou can adjust the display orientation by display setting.Touch orientationThe physical button on the backside can be used to adjust the orientation of touch. You can hold it for 5s to change.You may need to test multi times for the correct orientation.

Some users want to connect more than one display to their PC. Here we talk about how to setting the touch to make the touchscreen to control its screen separately.Connect touchscreen to PC. Here we use an standard PC monitor and connect an 7inch HDMI LCD (C) for example. We make the monitor as main screen and the touchscreen as secondary screen.

If we want the touch of the touchscreen to control the desktop of the touchscreen itself. Just press Enter key to pass the first screen. And the second screen, when you find that the black text is displayed on the touchscreen, just touch the center of the touchscreen to finish this setting.After this setting, the touch on the screen will just control this touchscreen even thought it is not the main screen.

1 If the first screen and the second screen are touchscreen as well, you can touch them when the text is displayed on the screens. Then you can find that all the touchscreen can work.

When working with Raspberry Pi, you should set the resolution of the LCD by yourself, or else the LCD screen will not work. For more detailed information, please read the following section.

Download the Raspbian image from Raspberry Pi web site. Write the image to a TF card and append the following lines to the config.txt file which is located in the root of your TF card:max_usb_current=1

For Pi Zero / Zero W: if you"ve used an SD card on a Pi 3 and then attached the card to the Pi Zero, the touch screen often doesn"t work. In such cases, you have to write a fresh system image to the SD card. The first boot up must be done on the Pi Zero but not Pi 3, due to initialization for a corresponding device.

Orientation settingDisplay orientationTo change the orientation, you can add the following line to config.txt file and reboot.display_rotate=XX can be 1: 90°; 2: 180°C; 3: 270°For example, if you want to rotate it for 90 degree, you can add the lin display_rotate=1Touch orientationThe physical button on the backside can be used to adjust the orientation of touch. You can hold it for 5s to change.You may need to test multi times for the correct orientation.

To work with Jetson Nano Developer Kit, you just need to connect the LCD and power onConnect the Touch interface of the LCD to the USB port of Jetson Nano

Orientation settingDisplay orientationYou can chagne the display orientation by display setting (system setting -> display setting).Touch orientationThe physical button on the backside can be used to adjust the orientation of touch. You can hold it for 5s to change.You may need to test multi times for the correct orientation.

All orders are processedwithin 24 hoursafter they are placed. Usually, we are able to ship orders the next day. Weekend orders are shipped on the following Monday. You will receive a shipping confirmation email from our system when the shipping information has been uploaded.

Generally, we will ship the orders with Free Shipping, without the minimum order amount requirement. You may check if the free shipping method is available to your country in the Delivery Area below.

As soon as your order is packed and shipped, you"ll receive a shipping confirmation email. You will then be able to track your order through the tracking link on the email. If you haven"t received an email yet, please reach out to us atservice@sunfounder.com, our sales staff will contact you ASAP.

* Delivery Time - These are the delivery estimates provided by our shipping partners and apply from point of dispatch, not from point of sale. Once your parcel leaves our warehouse, we cannot control any delays after that point.

7 inch mini HDMI monitor with HD 1024x600 resolution. This small LCD screen upgrades to IPS screen with larger visible angle and better image quality.

Plug and play, as easy as plugging micro USB cable for touch and power supply, HDMI cable for displaying, both cables included in the package, no driver needed.

The USB capacitive touch control is for Windows and raspberry pi system, free-driver, just connect the 7” screen by the USB port of the computer/ Raspberry Pi.

Can be used as a general-purpose 7 inch HDMI screen connected to your TV box, game console, or mounted inside your PC case as temperature stat panel display, etc.

Connected to RPI 4: Connect to HDMI 0 port when working with Raspberry Pi 4.(Just power the screen by the USB port of the pi if you want to get the touch function available)

Connected to RPI 4:Connect to HDMI 0 port when working with Raspberry Pi 4.(Just power the screen by the USB port of the pi if you want to get the touch function available)

*When working with Raspberry Pi 4, for the system image of Raspberry Pi after 2021-10-30, for example onBullseye, please modify "dtoverlay = vc4-kms-v3d" to "dtoverlay = vc4-fkms-v3d" in the config file, otherwise it may fail to start. But onBuster, please comment out "dtoverlay = vc4-fkms-V3D" by adding #.

Insert the TF Card to Raspberry Pi, connect the Raspberry Pi and LCD by HDMI cable; connect USB cable to one of the four USB ports of Raspberry Pi, and connect the other end of the USB cable to the USB port of the LCD; then supply power to Raspberry Pi; after that if the display and touch both are OK, it means drive successfully (please use the full 2A for power supply).

After execution, the driver will be installed. The system will automatically restart, and the display screen will rotate 90 degrees to display and touch normally.

Wondering what to do with that Raspberry Pi you bought? Can this little device really act as a desktop PC? As a server? As a radio station? Yes, it can!

Along with the Pi itself, the microSD card, and power supply, you"ll need a HDMI cable and a suitable display. For the Pi 3 and 4, you"ll also need a keyboard and mouse – USB or Bluetooth. Later Raspberry Pis have built-in Wi-Fi and Bluetooth. For older models, check elinux.org"s Raspberry Pi Hub for compatible dongles.

Whether you have an old printer that doesn’t have wireless, or one that won’t connect to your network (perhaps due to an old Wi-Fi standard), you can avoid sending it to landfill by employing a Raspberry Pi.

Once this is set up, any computer on your home network can access the printer You can even add AirPrint support to Raspberry Pi, for iPhone and Android devices.

At one time, one of the popular uses for the Raspberry Pi was as a Kodi media center. Several Kodi builds have been released, with OSMC and LibreELEC still going strong.

If you prefer to keep your computer available for other projects, Kodi can be installed on Raspberry Pi OS. It can also be added to retro gaming systems (see below). Installing Kodi comes with some caveats, however. Not all add-ons are available, and of those that are, many will be intended to stream pirated content.

As well as streaming media, the Raspberry Pi is ideal as a retro gaming machine. Compact and powerful enough to be used in several ways, the device is suitable as a full size arcade cabinet, or even as part of a Game Boy-esque handheld.

You probably know that a special version of Minecraft is available for Raspberry Pi OS. But did you know that your Pi can be used as a Minecraft game server, letting you play from anywhere on your home network?

Beyond Minecraft, however, other multiplayer network games can be set up on the Raspberry Pi. Open source ports of Quake, Civilization, Doom, and Open TTD can be installed as game servers on your Raspberry Pi.

Using the Python programming language, a suitable mount (overhead for Gilliam-esque paper craft animation, a standard tripod for clay- or toy-based), and a well-lit area, you’ll also need to rig a button to the Pi’s GPIO.

Combining the Raspberry Pi camera module with a different script creates another use for your Pi: making time-lapse movies. This is done by taking single frames with a timed delay. Again, you’ll need a tripod or mount to keep the camera module steady.

Do you have a message you want to share? Need to communicate with a community that has no internet access? The answer is to broadcast using radio, a secret feature of the Raspberry Pi.

Broadcasting over FM is illegal without a license. Fortunately, the Pi can only broadcast over a short distance, so you should be able to avoid getting into trouble.

But there are a few useful things you can do with a Twitter bot and if your Raspberry Pi has a permanent internet connection, you can create your own.

You"ll need to register a Twitter app to gain access to the Twitter API, and with some code (Python or Node.js) your bot will be ready. You could tweet anything from your Pi’s CPU temperature to a randomly selected quote of the day or even a photo.

Off-the-shelf digital photo frames are attractive, if somewhat limited in space, storage, and purpose. What if they could do more than just display your favorite family photos?

This is one of the best Raspberry Pi projects you will build: a digital photo frame that delivers inspiring messages alongside photos of beautiful scenes. The result is something that dazzles your eyes while making you really think about the message. We used a Raspberry Pi touchscreen display for this project; any compatible LCD display should be suitable.

Alonside the standard Raspberry Pi Camera Module, a No-IR module is also available. This is particularly suitable for nighttime photography. Raspberry Pi No-IR Camera Module.

For instance, you might use time-lapse photography to track the path of the stars and the moon overnight. Or employ a slow shutter speed to get a trace effect. Whatever your plan for night photography, the Raspberry Pi should suit your requirements perfectly.

Several network monitoring tools are available, but none is as easy to install and configure as Nagios. Once installed on your Raspberry Pi, you can monitor uptime, view a visualization of the devices on your network, and more.

Another way to enjoy media streaming on the Raspberry Pi is to configure it as a Plex server. Any PC, TV, or any other device running the standard Plex client app can then view media stored on the Raspberry Pi.

To get started with this project, you"ll need your own YouTube channel ready to use, and the libav-tools package installed. Check our detailed tutorial to streaming live video to YouTube from a Raspberry Pi for the full instructions.

It isn’t as complicated as you might think, with several pre-installed applications in Raspberry Pi OS included to aid basic programming. Among these is Scratch.

With a Raspberry Pi 2 or later you can stream Steam games from your main PC or Steam Deck to a TV. You"ll need to ensure that the Raspberry Pi or the PC (preferably both) are connected to your router via Ethernet. This is because Wi-Fi isn’t fast enough for streaming games without latency.

Ever wanted to catch up with the latest news, movie trailers, pop videos, and traffic and weather information while shaving? The answer is a smart mirror, a device powered by a Raspberry Pi.

Basically, this is a two-way mirror with a special display mounted behind the glass. Any type of mirror can be used for a smart mirror project; you should use one that suits your purposes.

You can emulate classic platforms on a Raspberry Pi, or you can stream games from a PC. If you"re not comfortable setting up streaming or emulators, plenty of games can be installed on the Raspberry Pi natively.

Some great games can be run on your Raspberry Pi without emulators. A great example is Doom, which incredibly can be installed to run on the Raspberry Pi. Other examples include FreeCiv, Quake III, and even the open source SimCity clone, Micropolis.

A powerful feature of the Raspberry Pi is the row of GPIO (general-purpose input/output) pins along the top edge of the board. A 40-pin GPIO header is found on all current Raspberry Pi boards (unpopulated on Raspberry Pi Zero, Raspberry Pi Zero W and Raspberry Pi Zero 2 W). Prior to the Raspberry Pi 1 Model B+ (2014), boards comprised a shorter 26-pin header. The GPIO header on all boards (including the Raspberry Pi 400) have a 0.1" (2.54mm) pin pitch.

The numbering of the GPIO pins is not in numerical order; GPIO pins 0 and 1 are present on the board (physical pins 27 and 28) but are reserved for advanced use (see below).

Two 5V pins and two 3.3V pins are present on the board, as well as a number of ground pins (0V), which are unconfigurable. The remaining pins are all general purpose 3.3V pins, meaning outputs are set to 3.3V and inputs are 3.3V-tolerant.

A GPIO pin designated as an input pin can be read as high (3.3V) or low (0V). This is made easier with the use of internal pull-up or pull-down resistors. Pins GPIO2 and GPIO3 have fixed pull-up resistors, but for other pins this can be configured in software.

As well as simple input and output devices, the GPIO pins can be used with a variety of alternative functions, some are available on all pins, others on specific pins.

A handy reference can be accessed on the Raspberry Pi by opening a terminal window and running the command pinout. This tool is provided by the GPIO Zero Python library, which is installed by default on the Raspberry Pi OS desktop image, but not on Raspberry Pi OS Lite.

While connecting up simple components to the GPIO pins is perfectly safe, it’s important to be careful how you wire things up. LEDs should have resistors to limit the current passing through them. Do not use 5V for 3.3V components. Do not connect motors directly to the GPIO pins, instead use an H-bridge circuit or a motor controller board.

In order to use the GPIO ports your user must be a member of the gpio group. The pi user is a member by default, other users need to be added manually.

Using the GPIO Zero library makes it easy to get started with controlling GPIO devices with Python. The library is comprehensively documented at gpiozero.readthedocs.io.

You can find more information on how to program electronics connected to your Raspberry Pi with the GPIO Zero Python library in the Raspberry Pi Press book Simple Electronics with GPIO Zero. Written by Phil King, it is part of the MagPi Essentials series published by Raspberry Pi Press. The book gets you started with the GPIO Zero library, and walks you through how to use it by building a series of projects.

The Compliance Support programme is designed to eliminate the burden of navigating compliance issues and make it easier for companies to bring new products to consumers. It provides access to the same test engineers who worked on our Raspberry Pis during their compliance testing, connecting the user to a dedicated team at UL who assess and test the user’s product, facilitated by their in-depth knowledge of Raspberry Pi.

The Powered by Raspberry Pi progamme provides a process for companies wanting to use a form of the Raspberry Pi logo, and covers products with Raspberry Pi computers or silicon inside, and services provided by a Raspberry Pi. If you wish to start the process to apply you can do so online.

All Raspberry Pi models perform a degree of thermal management to avoid overheating under heavy load. The SoCs have an internal temperature sensor, which software on the GPU polls to ensure that temperatures do not exceed a predefined limit; this is 85°C on all models. It is possible to set this to a lower value, but not to a higher one. As the device approaches the limit, various frequencies and sometimes voltages used on the chip (ARM, GPU) are reduced. This reduces the amount of heat generated, keeping the temperature under control.

When the core temperature is between 80°C and 85°C, a warning icon showing a red half-filled thermometer will be displayed, and the ARM cores will be progressively throttled back. If the temperature reaches 85°C, an icon showing a fully filled thermometer will be displayed, and both the ARM cores and the GPU will be throttled back. See the page on warning icons for images of the icons.

For 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, and this can be changed via the temp_soft_limit setting in config.txt.

The Raspberry Pi 4 Model B, continues with the same PCB technology as the Raspberry Pi 3 Model B+, to help dissipate excess heat. There is currently no soft limit defined.

Raspberry Pi 4 devices implement Dynamic Voltage and Frequency Scaling (DVFS). This technique allows Raspberry Pi 4 devices to run at lower temperatures whilst still providing the same performance.

Due to the architecture of the SoCs used on the Raspberry Pi range, and the use of the upstream temperature monitoring code in the Raspberry Pi OS distribution, Linux-based temperature measurements can be inaccurate. However, the vcgencmd command provides an accurate and instantaneous reading of the current SoC temperature as it communicates with the GPU directly:

Whilst heatsinks are not necessary to prevent overheating damage to the SoC — the thermal throttling mechanism handles that — a heatsink or small fan will help if you wish to reduce the amount of thermal throttling that takes place. Depending on the exact circumstances, mounting the Raspberry Pi vertically can also help with heat dissipation, as doing so can improve air flow.

Raspberry Pi 4, 400 and Compute Module 4 computers use an EEPROM to boot the system. All other models of Raspberry Pi computer use the bootcode.bin file located in the boot filesystem.

The scripts and pre-compiled binaries used to create the rpi-eeprom package which is used to update the Raspberry Pi 4 bootloader and VLI USB controller EEPROMs is available on Github.

If an error occurs during boot then an error code will be displayed via the green LED. Newer versions of the bootloader will display a diagnostic message which will be shown on both HDMI displays.

Raspberry Pi OS automatically updates the bootloader for critical bug fixes. The recommended methods for manually updating the bootloader or changing the boot modes are Raspberry Pi Imager and raspi-config

The boot behaviour (e.g. SD or USB boot) is controlled by a configuration file embedded in the EEPROM image and can be modified via the rpi-eeprom-config tool.

The following command loads the current EEPROM configuration into a text editor. When the editor is closed, rpi-eeprom-config applies the updated configuration to latest available EEPROM release and uses rpi-eeprom-update to schedule an update when the system is rebooted:

The following command applies boot.conf to the latest available EEPROM image and uses rpi-eeprom-update to schedule an update when the system is rebooted.

The rpi-eeprom-update systemd service runs at startup and applies an update if a new image is available, automatically migrating the current bootloader configuration.

If the FREEZE_VERSION bootloader EEPROM config is set then the EEPROM update service will skip any automatic updates. This removes the need to individually disable the EEPROM update service if there are multiple operating systems installed or when swapping SD-cards.

Raspberry Pi OS uses the rpi-eeprom-update script to implement an automatic update service. The script can also be run interactively or wrapped to create a custom bootloader update service.

The -d flag instructs rpi-eeprom-update to use the configuration in the specified image file instead of automatically migrating the current configuration.

The firmware release status corresponds to a particular subdirectory of bootloader firmware images (/lib/firmware/raspberrypi/bootloader/...), and can be changed to select a different release stream.

Since the release status string is just a subdirectory name, then it is possible to create your own release streams e.g. a pinned release or custom network boot configuration.

You can change which release stream is to be used during an update by editing the /etc/default/rpi-eeprom-update file and changing the FIRMWARE_RELEASE_STATUS entry to the appropriate stream.

If the bootloader update image is called pieeprom.upd then recovery.bin is renamed to recovery.000 once the update has completed, then the system is rebooted. Since recovery.bin is no longer present the ROM loads the newly updated bootloader from EEPROM and the OS is booted as normal.

If the bootloader update image is called pieeprom.bin then recovery.bin will stop after the update has completed. On success the HDMI output will be green and the green activity LED is flashed rapidly. If the update fails, the HDMI output will be red and an error code will be displayed via the activity LED.

The BCM2711 ROM does not support loading recovery.bin from USB mass storage or TFTP. Instead, newer versions of the bootloader support a self-update mechanism where the bootloader is able to reflash the EEPROM itself. See ENABLE_SELF_UPDATE on the bootloader configuration page.

Starting with version 2020-04-16 of the Raspberry Pi 4 bootloader, diagnostic information can be displayed at boot time on an HDMI display. To see this diagnostic information, power down the Raspberry Pi 4, remove the SD card, then power back up. A diagnostic display similar to below should appear on the attached display.

The Raspberry Pi has a number of different stages of booting. This document explains how the boot modes work, and which ones are supported for Linux booting.

USB host and Ethernet boot can be performed by BCM2837-based Raspberry Pis - that is, Raspberry Pi 2B version 1.2, Raspberry Pi 3B, and Raspberry Pi 3B+ (Raspberry Pi 3A+ cannot net boot since it does not have a built-in Ethernet interface). In addition, all Raspberry Pi models except Raspberry Pi 4B can use a new bootcode.bin-only method to enable USB host boot.

The Raspberry Pi 4B does not use the bootcode.bin file - instead the bootloader is located in an on-board EEPROM chip. See Raspberry Pi 4 Bootflow and SPI Boot EEPROM.

Format an SD card as FAT32 and copy on the latest bootcode.bin. The SD card must be present in the Raspberry Pi for it to boot. Once bootcode.bin is loaded from the SD card, the Raspberry Pi continues booting using USB host mode.

This is useful for the Raspberry Pi 1, 2, and Zero models, which are based on the BCM2835 and BCM2836 chips, and in situations where a Raspberry Pi 3 fails to boot (the latest bootcode.bin includes additional bugfixes for the Raspberry Pi 3B, compared to the boot code burned into the BCM2837A0).

Next, connect a suitable USB serial cable to your host computer (a Raspberry Pi will work, although I find the easiest path is to use a USB serial cable since it’ll work out the box without any pesky config.txt settings). Use the standard pins 6, 8 and 10 (GND, GPIO14, GPIO15) on a Raspberry Pi or Compute Module board.

Setup your serial to receive at 115200-8-N-1, and then boot your Raspberry Pi / Compute Module. You should get an immediate serial output from the device as bootcode.bin runs.

The following boot sequence applies to the BCM2837 and BCM2837B0 based models of Raspberry Pi only. On models prior to this, the Raspberry Pi will try SD card boot, followed by USB device mode boot. For the Raspberry Pi 4 boot sequence please see the Raspberry Pi 4 boot flow section.

USB boot defaults on the Raspberry Pi 3 will depend on which version is being used. See this page for information on enabling USB boot modes when not enabled by default.

When the BCM2837 boots, it uses two different sources to determine which boot modes to enable. Firstly, the OTP (one-time programmable) memory block is checked to see which boot modes are enabled. If the GPIO boot mode setting is enabled, then the relevant GPIO lines are tested to select which of the OTP-enabled boot modes should be attempted. Note that GPIO boot mode can only be used to select boot modes that are already enabled in the OTP. See GPIO boot mode for details on configuring GPIO boot mode. GPIO boot mode is disabled by default.

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 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.

The primary SD card boot mode is, as standard, set to be GPIOs 49-53. It is possible to boot from the secondary SD card on a second set of pins, i.e. to add a secondary SD card to the GPIO pins. However, we have not yet enabled this ability.

The USB device boot mode is enabled by default at the time of manufacture, but the USB host boot mode is only enabled with program_usb_boot_mode=1. Once enabled, the processor will use the value of the OTGID pin on the processor to decide between the two modes. On any Raspberry Pi Model B / B+, the OTGID pin is driven to "0" and therefore will only boot via host mode once enabled (it is not possible to boot through device mode because the LAN951x device is in the way).

The USB will boot as a USB device on the Raspberry Pi Zero or Compute Module if the OTGID pin is left floating (when plugged into a PC for example), so you can "squirt" the bootcode.bin into the device. The usbboot code for doing this is available on Github.

The main difference between this and previous products is that the second stage bootloader is loaded from an SPI flash EEPROM instead of the bootcode.bin file on previous products.

The bootloader may also be updated before the firmware is started if a pieeprom.upd file is found. Please see the bootloader EEPROM page for more information about bootloader updates.

tryboot is supported on all Raspberry Pi models, however, on Raspberry Pi 4 Model B revision 1.0 and 1.1 the EEPROM must not be write protected. This is because older Raspberry Pi 4B devices have to reset the power supply (losing the tryboot state) so this is stored inside the EEPROM instead.

If 1 and WAKE_ON_GPIO=0 then sudo halt will switch off all PMIC outputs. This is lowest possible power state for halt but may cause problems with some HATs because 5V will still be on. GLOBAL_EN must be shorted to ground to boot.

Raspberry Pi 400 has a dedicated power button which operates even if the processor is switched off. This behaviour is enabled by default, however, WAKE_ON_GPIO=2 may be set to use an external GPIO power button instead of the dedicated power button.

RPIBOOT is intended for use with Compute Module 4 to load a custom debug image (e.g. a Linux RAM-disk) instead of the normal boot. This should be the last boot option because it does not currently support timeouts or retries.

In order to support unique TFTP boot directories for each Raspberry Pi the bootloader prefixes the filenames with a device specific directory. If neither start4.elf nor start.elf are found in the prefixed directory then the prefix is cleared.

On earlier models the serial number is used as the prefix, however, on Raspberry Pi 4 the MAC address is no longer generated from the serial number making it difficult to automatically create tftpboot directories on the server by inspecting DHCPDISCOVER packets. To support this the TFTP_PREFIX may be customized to either be the MAC address, a fixed value or the serial number (default).

the concatenation of the fourcc for RPi4 (0x34695052 - little endian), the board revision (e.g. 0x00c03111) (4-bytes), the least significant 4 bytes of the mac address and the 4-byte serial number.

This is intended to be unique but also provide structured information to the DHCP server, allowing Raspberry Pi 4 computers to be identified without relying upon the Ethernet MAC OUID.

Skip rendering of the HDMI diagnostics display for up to N seconds (default 5) unless a fatal error occurs. The default behaviour is designed to avoid the bootloader diagnostics screen from briefly appearing during a normal SD / USB boot.

Previously this property was only checked by the rpi-eeprom-update script. However, now that self-update is enabled the bootloader will also check this property. If set to 1, this overrides ENABLE_SELF_UPDATE to stop automatic updates. To disable FREEZE_VERSION you will have to use an SD card boot with recovery.bin.

You can use this property to change the port used for network install and HTTP boot. HTTPS is enabled when using the default host fw-download-alias1.raspberrypi.com. If HTTP_HOST is changed then HTTPS is disabled and plain HTTP will be used instead.

In order to detect the keyboard, network install must initialise the USB controller and enumerate devices. This increases boot time by approximately 1 second so it may be advantageous to disable network install in some embedded applications.

Setting this to 0 disables the keyboard wait, although network install can still be initiated if no boot files are found and USB boot-mode 4 is in BOOT_ORDER.

One way to view the data is to connect the test Raspberry Pi 4 to another Raspberry Pi running WireShark and select “udp.srcport == 6665” as a filter and select Analyze -> Follow -> UDP stream to view as an ASCII log.

A list of up to 4 VID/PID pairs specifying devices which the bootloader should ignore. If this matches a HUB then the HUB won’t be enumerated, causing all downstream devices to be excluded.

How long to wait in milliseconds before advancing to the next LUN e.g. a multi-slot SD-CARD reader. This is still being tweaked but may help speed up boot if old/slow devices are connected as well as a fast USB-MSD device containing the OS.

During USB mass storage boot, power to the USB ports is switched off for a short time to ensure the correct operation of USB mass storage devices. Most devices work correctly using the default setting: change this only if you have problems booting from a particular device. Setting USB_MSD_PWR_OFF_TIME=0 will prevent power to the USB ports being switched off during USB mass storage boot.

If the VL805 property is set to 1 then the bootloader will search for a VL805 PCIe XHCI controller and attempt to initialise it with VL805 firmware embedded in the bootloader EEPROM. This enables industrial designs to use VL805 XHCI controllers without providing a dedicated SPI EEPROM for the VL805 firmware.

On Compute Module 4 the bootloader never writes to the dedicated VL805 SPI EEPROM. This option just configures the controller to load the firmware from SDRAM.

Do not use this option if the VL805 XHCI controller has a dedicated EEPROM. It will fail to initialise because the VL805 ROM will attempt to use a dedicated SPI EEPROM if fitted.

The embedded VL805 firmware assumes the same USB configuration as Raspberry Pi 4B (2 USB 3.0 ports and 4 USB 2.0 ports). There is no support for loading alternate VL805 firmware images, a dedicated VL805 SPI EEPROM should be used instead for such configurations.

This property is a bit-field which controls the verbosity of USB debug messages for mass storage boot-mode. Enabling all of these messages generates a huge amount of log data which will slow down booting and may even cause boot to fail. For verbose logs it’s best to use NETCONSOLE.

Bit 0 (0x1) indicates that the .elf file is custom firmware. This disables any compatibility checks (e.g. is USB MSD boot supported) and resets PCIe before starting the executable.

If erase_eeprom is set to 1 then recovery.bin will erase the entire SPI EEPROM instead of flashing the bootloader image. This property has no effect during a normal boot.

This option must be used in conjunction with the EEPROM /WP pin which controls updates to the EEPROM Write Status Register. Pulling /WP low (CM4 EEPROM_nEP or Pi4B TP5) does NOT write-protect the EEPROM unless the Write Status Register has also been configured.

This option may be set to 0 to block self-update without requiring the EEPROM configuration to be updated. This is sometimes useful when updating multiple Raspberry Pis via network boot because this option can be controlled per Raspberry Pi (e.g. via a serial number filter in config.txt).

The following config.txt properties are used to program the secure-boot OTP settings. These changes are irreversible and can only be programmed via RPIBOOT when flashing the bootloader EEPROM image. This ensures that secure-boot cannot be set remotely or by accidentally inserting a stale SD card image.

Since there is no dedicated nRPIBOOT jumper on Raspberry Pi 4B or Raspberry Pi 400, an alternative GPIO must be used to select RPIBOOT mode by pulling the GPIO low. Only one GPIO may be selected and the available options are 2, 4, 5, 7, 8. This property does not depend on secure-boot but please verify that this GPIO configuration does not conflict with any HATs which might pull the GPIO low during boot.

Since for safety this property can only be programmed via RPIBOOT, the bootloader EEPROM must first be cleared using erase_eeprom. This causes the BCM2711 ROM to failover to RPIBOOT mode, which then allows this option to be set.

If you run rpi-eeprom-update again after your Raspberry Pi has rebooted, you should now see that the CURRENT date has updated to indicate that you are using the latest version of the bootloader.

The choice between the two boot modes is made by the firmware at boot time when it reads the OTP bits. There are two bits to control USB boot: the first enables USB device boot and is enabled by default. The second enables USB host boot; if the USB host boot mode bit is set, then the processor reads the OTGID pin to decide whether to boot as a host (driven to zero as on any Raspberry Pi Model B / B+) or as a device (left floating). The Raspberry Pi Zero has access to this pin through the OTGID pin on the USB connector, and the Compute Module has access to this pin on the edge connector.

When this boot mode is activated (usually after a failure to boot from the SD card), the Raspberry Pi puts its USB port into device mode and awaits a USB reset from the host. Example code showing how the host needs to talk to the Raspberry Pi can be found on Github.

This page explains how to boot your Raspberry Pi from a USB mass storage device such as a flash drive or a USB hard disk. When attaching USB devices, particularly hard disks and SSDs, be mindful of their power requirements. If you wish to attach more than one SSD or hard disk to the Raspberry Pi, this normally requires external power - either a powered hard disk enclosure, or a powered USB hub. Note that models prior to the Raspberry Pi 4B have known issues which prevent booting with some USB devices.

The bootloader in Raspberry Pi 400 and newer Raspberry Pi 4B boards support USB boot by default, although the BOOT_ORDER bootloader configuration may need to be modified. On earlier Raspberry Pi 4B boards, or to select alternate boot modes, the bootloader must be updated.

On the Raspberry Pi 2B v1.2, 3A+, 3B, Zero 2 W, and Compute Module 3, 3+ you must first enable USB host boot mode. This is to allow USB mass storage boot, and network boot. Note that network boot is not supported on the Raspberry Pi 3A+ or Zero 2 W.

To enable USB host boot mode, the Raspberry Pi needs to be booted from an SD card with a special option to set the USB host boot mode bit in the one-time programmable (OTP) memory. Once this bit has been set, the SD card is no longer required.

Note that although the option is named program_usb_boot_mode, it only enables USB host boot mode. USB device boot mode is only available on certain models of Raspberry Pi - see USB device boot mode.

Check that the output 0x3020000a is shown. If it is not, then the OTP bit has not been successfully programmed. In this case, go through the programming procedure again. If the bit is still not set, this may indicate a fault in the Raspberry Pi hardware itself.

If you wish, you can remove the program_usb_boot_mode line from config.txt, so that if you put the SD card into another Raspberry Pi, it won’t program USB host boot mode. Make sure there is no blank line at the end of config.txt.

After preparing the storage device, connect the drive to the Raspberry Pi and power up the Raspberry Pi, being aware of the extra USB power requirements of the external drive.

After five to ten seconds, the Raspberry Pi should begin booting and show the rainbow splash screen on an attached display. Make sure that you do not have an SD card inserted in the Raspberry Pi, since if you do, it will boot from that first.

The default timeout for checking bootable USB devices is 2 seconds. Some flash drives and hard disks power up too slowly. It is possible to extend this timeout to five seconds (add a new file timeout to the SD card), but note that some devices take even longer to respond.

If you are unable to use a particular USB device to boot your Raspberry Pi, an alternative for the Raspberry Pi 2B v1.2, 3A+, 3B and 3B+ is to use the special bootcode.bin-only boot mode. The Raspberry Pi will still boot from the SD card, but bootcode.bin is the only file read from it.

Before attempting to boot from a USB mass storage device it is advisable to verify that the device works correctly under Linux. Boot using an SD card and plug in the USB mass storage device. This should appears as a removable drive. This is especially important with USB SATA adapters which may be supported by the bootloader in mass storage mode but fail if Linux selects USB Attached SCSI - UAS mode. See this forum thread about UAS and how to add usb-storage.quirks to workaround this issue.

Spinning hard disk drives nearly always require a powered USB hub. Even if it appears to work, you are likely to encounter intermittent failures without a powered USB HUB.

When searching for a bootable partition, the bootloader scans all USB mass storage devices in parallel and will select the first to respond. If the boot partition does not contain a suitable start.elf file, the next available device is selected. There is no method for specifying the boot device according to the USB topology because this would slow down boot and adds unnecessary and hard to support configuration complexity.

This section describes how network booting works on the Raspberry Pi 3B, 3B+ and 2B v1.2. On the Raspberry Pi 4 network booting is implemented in the second stage bootloader in the EEPROM. Please see the Raspberry Pi 4 Bootloader Configuration page for more information.

We also have a tutorial about setting up a network boot system. Network booting works only for the wired adapter built into the above models of Raspberry Pi. Booting over wireless LAN is not supported, nor is booting from any other wired network device.

From this point the bootcode.bin code continues to load the system. The first file it will try to access is [serial_number]/start.elf. If this does not result in an error then any other files to be read will be pre-pended with the serial_number. This is useful because it enables you to create separate directories with separate start.elf / kernels for your Raspberry Pis.

To get the serial number for the device you can either try this boot mode and see what file is accessed using tcpdump / wireshark, or you can run a standard Raspberry Pi OS SD card and cat /proc/cpuinfo.

The first thing to check is that the OTP bit is correctly programmed. To do this, you need to add program_usb_boot_mode=1 to config.txt and reboot (with a standard SD card that boots correctly into Raspberry Pi OS). Once you’ve done this, you should be able to do:

You will know whether the Vendor Option is correctly specified: if it is, you’ll see a subsequent TFTP RRQ packet being sent. RRQs can be replied to by either the first block of data or an error saying file not found. In a couple of cases they even receive the first packet and then the transmission is aborted by the Raspberry Pi (this happens when checking whether a file exists). The example below is just three packets: the original read request, the first data block (which is always 516 bytes containing a header and 512 bytes of data, although the last block is always less than 512 bytes and may be zero length), and the third packet (the ACK which contains a frame number to match the frame number in the data block).

The Raspberry Pi will attempt a DHCP request five times with five seconds in between, for a total period of 25 seconds. If the server is not available to respond in this time, then the Raspberry Pi will drop into a low-power state. There is no workaround for this other than bootcode.bin on an SD card.

The Raspberry Pi will only respond to ARP requests when it is in the initialisation phase; once it has begun transferring data, it’ll fail to continue responding.

At boot time, Raspberry Pi broadcasts a DHCPDISCOVER packet. The DHCP server replies with a DHCPOFFER packet. The Raspberry Pi then continues booting without doing a DHCPREQUEST or waiting for DHCPACK. This may result in two separate devices being offered the same IP address and using it without it being properly assigned to the client.

Different DHCP servers have different behaviours in this situation. dnsmasq (depending upon settings) will hash the MAC address to determine the IP address, and ping the IP address to make sure it isn’t already in use. This reduces the chances of this happening because it requires a collision in the hash.

The Raspberry Pi can be configured to allow the boot mode to be selected at power on using hardware attached to the GPIO connector: this is GPIO boot mode. This is done by setting bits in the OTP memory of the SoC. Once the bits are set, they permanently allocate 5 GPIOs to allow this selection to be made. Once the OTP bits are set they cannot be unset so you should think carefully about enabling this, since those 5 GPIO lines will always control booting. Although you can use the GPIOs for some other function once the Raspberry Pi has booted, you must set them up so that they enable the desired boot modes when the Raspberry Pi boots.

Where n is the bank of GPIOs which you wish to use. Then reboot the Raspberry Pi once to program the OTP with this setting. Bank 1 is GPIOs 22-26, bank 2 is GPIOs 39-43. Unless you have a Compute Module, you must use bank 1: the GPIOs in bank 2 are only available on the Compute Module. Because of the way the OTP bits are arranged, if you first program GPIO boot mode for bank 1, you then have the option of selecting bank 2 later. The reverse is not true: once bank 2 has been selected for GPIO boot mode, you cannot select bank 1.

Once GPIO boot mode is enabled, the Raspberry Pi will no longer boot. You must pull up at least one boot mode GPIO pin in order for the Raspberry Pi to boot.

USB in the table above selects both USB device boot mode and USB host boot mode. In order to use a USB boot mode, it must be enabled in the OTP memory. For more information, see USB device boot and USB host boot.

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 ohm, as documented on page 102 of the BCM2835 ARM peripherals datasheet. A pull resistance of 5K ohm is recommended to pull a GPIO line up: this will allow the GPIO to function but not consume too much power.

The latest version of Raspberry Pi OS supports booting from NVMe drives. To check that your NVMe drive is connected correctly, boot Raspberry Pi OS from another drive and run ls -l /dev/nvme*; example output is shown below.

If you need to connect the NVMe drive to a PC or Mac you can use a USB adaptor: search for "NVME PCI-E M-Key Solid State Drive External Enclosure". The enclosure must support M key SSDs.

To boot from NVMe you need a recent version of the bootloader (after July 2021), and a recent version of the VideoCore firmware and Raspberry Pi OS Linux kernel. The latest Raspberry Pi OS release has everything you need, so you can use the Raspberry Pi Imager to install the software to your SSD.

You might need to use rpiboot to update the CM4 bootloader. Instructions for building rpiboot and configuring the IO board to switch the ROM to usbboot mode are in the usbboot Github repository.

You must have the latest versions of the VideoCore firmware and Raspberry Pi OS Linux kernel to boot directly from an NVMe SSD disk. The Raspberry Pi Bullseye and Buster Legacy releases have everything needed.

This boot behaviour is controlled via the BOOT_ORDER setting in the EEPROM configuration: we have added a new boot mode 6 for NVMe. See Raspberry Pi 4 Bootloader Configuration.

If the boot process fails, please file an issue on the rpi-eeprom Github repository, including a copy of the console and anything displayed on the screen during boot.

You could for example add this to your BOOT_ORDER as a fall-back boot method, or put it behind a GPIO conditional to initiate HTTP boot from your own server when a GPIO pin is pulled low.

To use HTTP boot you need to use the LATEST / STABLE bootloader configuration and update to a bootloader dated 10th March 2022 or later. HTTP boot only works over ethernet, so you need to connect your Raspberry Pi to your network via an Ethernet cable, e.g. to a socket on the back of your router.

All HTTP downloads must be signed. The bootloader includes a public key for the files on the default host fw-download-alias1.raspberrypi.com. This key will be used to verify the network install image unless you set HTTP_HOST and include a public key in the eeprom. This allows you to host the Raspberry Pi network install images on your own server.

An up-to-24-bit parallel RGB interface is available on all Raspberry Pi boards with the 40 way header and the Compute Modules. This interface allows parallel RGB displays to be attached to the Raspberry Pi GPIO either in RGB24 (8 bits for red, green and blue) or RGB666 (6 bits per colour) or RGB565 (5 bits red, 6 green, and 5 blue).

One of the alternate functions selectable on bank 0 of the Raspberry Pi GPIO is DPI (Display Parallel Interface) which is a simple clocked parallel interface (up to 8 bits of R, G and B; clock, enable, hsync, and vsync). This interface is available as alternate function 2 (ALT2) on GPIO bank 0:

There are various ways that the colour values can be presented on the DPI output pins in either 565, 666, or 24-bit modes (see the following table and the output_format part of the dpi_output_format parameter below):

Note that all other peripheral overlays that use conflicting GPIO pins must be disabled. In config.txt, take care to comment out or invert any dtparams that enable I2C or SPI:

The output format (clock, colour format, sync polarity, enable) can be controlled with a magic number (unsigned integer or hex value prefixed with 0x) passed to the dpi_output_format parameter in config.txt created from the following fields:

In firmware dated August 2018 or later, the hdmi_timings config.txt entry that was previously used to set up the DPI timings has be superseded by a new dpi_timings parameter. If the dpi_timings parameter is not present, the system will fall back to using the hdmi_timings parameter to ensure backwards compatibility. If neither are present and a custom mode is requested, then a default set of parameters for VGAp60 is used.

The dpi_group and dpi_mode config.txt parameters are used to set either predetermined modes (DMT or CEA modes as used by HDMI) or a user can generate custom modes.

dpi_timings= <frame_rate>

A Linux Device Tree overlay is used to switch the GPIO pins into the correct mode (alt function 2). As previously mentioned, the GPU is responsible for driving the DPI display. Hence there is no Linux driver; the overlay simply sets the GPIO alt functions correctly.

A "full fat" DPI overlay (dpi24.dtb) is provided which sets all 28 GPIOs to ALT2 mode, providing the full 24 bits of colour bus as well as the h and v-sync, enable and pixel clock. Note this uses all of the bank 0 GPIO pins.

A second overlay (vga666.dtb) is provided for driving VGA monitor signals in 666 mode which don’t need the clock and DE pins (GPIO 0 and 1) and only require GPIOs 4-21 for colour (using mode 5).

These overlays are fairly trivial and a user can edit them to create a custom overlay to enable just the pins required for their specific use case. For example, if one was using a DPI display using vsync, hsync, pclk, and de but in RGB565 mode (mode 2), then the dpi24.dtb overlay could be edited so that GPIOs 20-27 were not switched to DPI mode and hence could be used for other purposes.

General Purpose I/O (GPIO) pins can be configured as either general-purpose input, general-purpose output, or as one of up to six special alternate settings, the functions of which are pin-dependent.

The GPIO connections on the BCM2835 package are sometimes referred to in the peripherals data sheet as "pads" — a semiconductor design term meaning "chip connection to outside world".

All GPIO pins revert to general-purpose inputs on power-on reset. The default pull states are also applied, which are detailed in the alternate function table in the ARM peripherals datasheet. Most GPIOs have a default pull applied.

Each GPIO pin, when configured as a general-purpose input, can be configured as an interrupt source to the ARM. Several interrupt generation sources are configurable:

The normal rising/falling edge detection has a small amount of synchronisation built into the detection. At the system clock frequency, the pin is sampled with the criteria for generation of an interrupt being a stable transition within a three-cycle window, i.e. a record of "1 0 0" or "0 1 1". Asynchronous detection bypasses this synchronisation to enable the detection of very narrow events.

Almost all of the GPIO pins have alternative functions. Peripheral blocks internal to the SoC can be selected to appear on one or more of a set of GPIO pins, for example the I2C buses can be configured to at least 3 separate locations. Pad control, such as drive strength or Schmitt filtering, still applies when the pin is configured as an alternate function.

The table below gives the various voltage specifications for the GPIO pins for BCM2835, BCM2836, BCM2837 and RP3A0-based products (e.g. Raspberry Pi Zero or Raspberry Pi 3+). For information about Compute Modules you should see the relevant datasheets.

The table below gives the various voltage specifications for the GPIO pins for BCM2711-based products (e.g. Raspberry Pi 4 and Raspberry Pi 400). For information about Compute Modules you should see the relevant datasheets.

GPIO drive strengths do not indicate a maximum current, but a maximum current under which the pad will still meet the specification. You should set the GPIO drive strengths to match the device being attached in order for the device to work correctly.

The Raspberry Pi 3.3V supply was designed with a maximum current of ~3mA per GPIO pin. If you load each pin with 16mA, the total current is 272mA. The 3.3V supply will collapse under that level of load.

Big current spikes will happen, especially if you have a capacitive load. That will "bounce" around all the other pins near it. It is likely to cause interference with the SD card or even the SDRAM behaviour.

Beware of SSO (Simultaneous Switching Outputs) limitations which are device-dependent as well as dependent on the quality and layout of the PCB, the amount and quality of the decoupling capacitors, the type of load on the pads (resistance, capacitance), and other factors beyond the control of Raspberry Pi.

If there is no kernel driver available, and a program needs to access a peripheral address directly with mmap, it needs to know where in the virtual memory map the peripheral bus segment has been placed. This varies according to which model of Raspberry Pi is being used, so there are three helper functions in bcm_host.c to help provide platform independence.

The Raspberry Pi is often used as part of another product. This documentation describes some extra facilities available to use other capabilities of the Raspberry Pi.

The device private key rows can only be read via the vcmailbox command which requires access to /dev/vcio which is restricted to the video group on Raspberry Pi OS.

Raspberry Pi computers do not have a hardware protected key store. It is recommended that this feature is used in conjunction with secure-boot in order to restrict access to this data.

The rpi-otp-private-key script wraps the device private key vcmailbox APIs in order to make it easier to read/write a key in the same format as OpenSSL.

This is available via device-tree in /proc/device-tree/chosen/rpi-boardrev-ext and for testing purposes this OTP value can be temporarily overridden by setting board_rev_ext in config.txt.

The power supply requirements differ by Raspberry Pi model. All models require a 5.1V supply, but the current required generally increases according to model. All models up to the Raspberry Pi 3 require a micro USB power connector, whilst the Raspberry Pi 4 and Raspberry Pi 400 use a USB-C connector.

Exactly how much current (mA) the Raspberry Pi requires is dependent on what you connect to it. The following table gives various current requirements.

If you need to connect a USB device that will take the power requirements above the values specified in the table above, then you must connect it using an externally-powered USB hub.

From the Raspberry Pi B+ onwards, 1.2A is supplied to downstream USB peripherals. This allows the vast majority of USB devices to be connected directly to these models, assuming the upstream power supply has sufficient available current.

Very high-current devices, or devices which can draw a surge current such as certain modems and USB hard disks, will still require an external powered USB hub. The power requirements of the Raspberry Pi increase as you make use of the various interfaces on the Raspberry Pi. The GPIO pins can draw 50mA safely (note that that means 50mA distributed across all the pins: an individual GPIO pin can only safely draw 16mA), the HDMI port uses 50mA, the Camera Module requires 250mA, and keyboards and mice can take as little as 100mA or as much as 1000mA! Check the power rating of the devices you plan to connect to the Raspberry Pi and purchase a power supply accordingly. If you’re not sure, we would advise you to buy a powered USB hub.

For these measurements we used a standard Raspberry Pi OS image (current as of 26 Feb 2016, or June 2019 for the Raspberry Pi 4), at room temperature, with the Raspberry Pi connected to a HDMI monitor, USB keyboard, and USB mouse. The Raspberry Pi 3 Model B was connected to a wireless LAN access point, the Raspberry Pi 4 was connected to Ethernet. All these power measurements are approximate and do not take into account power consumption from additional USB devices; power consumption can easily exceed these measurements if multiple additional USB devices or a HAT are connected to the Raspberry Pi.

On all models of Raspberry Pi since the Raspberry Pi B+ (2014) except the Zero range, there is low-voltage detection circuitry that will detect if the supply voltage drops below 4.63V (+/- 5%). This will result in a warning icon being displayed on all attached displays and an entry being added to the kernel log.

If you are seeing warnings, you should improve the power supply and/or cable, as low power can cause problems with corruption of SD cards, or erratic behaviour of the Raspberry Pi itself; for example, unexplained crashes.

Voltages can drop for a variety of reasons, for example if the power supply itself is inadequate, the power supply cable is made of too thin wires, or you have plugged in high demand USB devices.

The USB specification requires that USB devices must not supply current to upstream devices. If a USB device does supply current to an upstream device then this is called back-powering. Often this happens when a badly-made powered USB hub is connected, and will result in the powered USB hub supplying power to the host Raspberry Pi. This is not recommended since the power being supplied to the Raspberry Pi via the hub will bypass the protection circuitry built into the Raspberry Pi, leaving it vulnerable to damage in the event of a power surge.

Raspberry Pi computers are equipped with a number of SPI buses. SPI can be used to connect a wide variety of peripherals - displays, network controllers (Ethernet, CAN bus), UARTs, etc. These devices are best supported by kernel device drivers, but the spidev API allows userspace drivers to be written in a wide array of languages.

SPI0, with two hardware chip selects, is available on the header of all Raspberry Pis; there is also an alternate mapping that is only available on Compute Modules.

On the Raspberry Pi 4, 400 and Compute Module 4 there are four additional SPI buses: SPI3 to SPI6, each with 2 hardware chip selects. These extra SPI buses are available via alternate function assignments on certain GPIO pins - see the BCM2711 ARM Peripherals datasheet.

In bidirectional SPI mode the same SPI standard is implemented, except that a single wire is used for data (MOMI) instead of the two used in standard mode (MISO and MOSI). In this mode, the MOSI pin serves as MOMI pin.

The LoSSI standard allows issuing of commands to peripherals (LCD) and to transfer data to