Post Syndicated from Alasdair Allan original https://www.raspberrypi.org/blog/how-to-get-started-with-fuzix-on-raspberry-pi-pico/

FUZIX is an old-school Unix clone that was initially written for the 8-bit Zilog Z80 processor and released by Alan Cox in 2014. At one time one of the most active Linux developers, Cox stepped back from kernel development in 2013. While the initial announcement has been lost in the mists because he made it on the now defunct Google+, Cox jokingly recommended the system for those longing for the good old days when all the source code still fitted on a single floppy disk.

Since then FUZIX has been ported to other architectures such as 6502, 68000, and the MSP430. Earlier in the week David Given — who wrote both the MSP430 and ESP8266 ports — went ahead and ported it to Raspberry Pi Pico and RP2040.

So you can now run Unix on a $4 microcontroller.

Building FUZIX from source

FUZIX is a “proper” Unix with a serial console on Pico’s UART0 and SD card support, using the card both for the filesystem and for swap space. While there is a binary image available, it’s easy enough to build from source.

If you don’t already have the Raspberry Pi Pico toolchain set up and working you should go ahead and set up the C/C++ SDK.

Afterwards you need grab the the Pico port from GitHub.

$ git clone https://github.com/davidgiven/FUZIX.git
$ cd FUZIX
$ git checkout rpipico

Then change directory to the platform port

$ cd Kernel/platform-rpipico/

and edit the first line of the Makefile to set the path to your pico-sdk.

So for instance if you’re building things on a Raspberry Pi and you’ve run the pico_setup.sh script, or followed the instructions in our Getting Started guide, you’d point the PICO_SDK_PATH to

export PICO_SDK_PATH = /home/pi/pico/pico-sdk

After that you can go ahead and build both the FUZIX UF2 file and the root filesystem.

$ make world -j
$ ./update-flash.sh

If everything goes well you should have a UF2 file in build/fuzix.uf2 and a filesystem.img image file in your current working directory.

You can now load the UF2 file onto your Pico in the normal way.

Go grab your Raspberry Pi Pico board and a micro USB cable. Plug the cable into your Raspberry Pi or laptop, then press and hold the BOOTSEL button on your Pico while you plug the other end of the micro USB cable into the board. Then release the button after the board is plugged in.

A disk volume called RPI-RP2 should pop up on your desktop. Double-click to open it, and then drag and drop the UF2 file into it.

The volume will automatically unmount, and your Pico is now running Unix. Unfortunately it won’t be much use without a filesystem.

Building a bootable SD card

The filesystem.img image file we built earlier isn’t a bootable image. Unlike the Raspberry Pi OS images you might be used to, you can’t just use something like Raspberry Pi Imager to write it to an SD card. We’re going to have to get our hands a bit dirtier than that.

The following instructions are for building your file system on a Raspberry Pi, or another similar Linux platform. Comparable tools are available on both MS Windows and Apple macOS, but the exact details will differ.

Go grab a microSD card. As the partitions we’re going to put onto it are only going to take up 34MB it doesn’t really matter what size you’ve got to hand. I was using a 4GB card, as that was the smallest I could find, but it’s not that important.

Now plug the card into a USB card reader and then into your Raspberry Pi or laptop computer. We’re going to have to build the partition table that FUZIX is expecting, which consists of two partitions: the first a 2MB swap partition, and the second a 32MB root partition into which we can copy the root filesystem, our filesystem.img file.

After plugging your card into the reader you can find it from the command line using the lsblk command. If you’ve have a blank unformatted card it will be visible as /dev/sda.

$ lsblk
NAME        MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda           8:0    1  3.7G  0 disk 
mmcblk0     179:0    0 14.9G  0 disk 
├─mmcblk0p1 179:1    0  256M  0 part /boot
└─mmcblk0p2 179:2    0 14.6G  0 part /
$

But if the card is already formatted you might instead see something like this

$ lsblk
NAME        MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda           8:0    1  3.7G  0 disk 
└─sda1        8:1    1  3.7G  0 part /media/pi/USB
mmcblk0     179:0    0 14.9G  0 disk 
├─mmcblk0p1 179:1    0  256M  0 part /boot
└─mmcblk0p2 179:2    0 14.6G  0 part /
$

which is a FAT-formatted card with a MBR named “USB”, which your Raspberry Pi has automatically mounted under /media/pi/USB.

If your card has mounted, just go ahead and unmount it as follows:

$ umount /dev/sda1

Then looking using lsblk you should see

$ lsblk
NAME        MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda           8:0    1  3.7G  0 disk 
└─sda1        8:1    1  3.7G  0 part 
mmcblk0     179:0    0 14.9G  0 disk 
├─mmcblk0p1 179:1    0  256M  0 part /boot
└─mmcblk0p2 179:2    0 14.6G  0 part /
$

at which point we can delete the current partition table by zeroing out the first part of the card and deleting the “start of disk” structures.

$ sudo dd if=/dev/zero of=/dev/sda bs=512 count=1

If you run lsblk again afterwards you’ll see that the sda1 partition has been deleted.

Next we’ll use fdisk to create a new partition table. Type the following

$ sudo fdisk /dev/sda

to put you at the fdisk prompt. Then type “o” to create a new DOS disklabel

Command (m for help): o
Created a new DOS disklabel with disk identifier 0x6e8481a2.

followed by “n” to create a new partition:

Command (m for help): n
Partition type
   p   primary (0 primary, 0 extended, 4 free)
   e   extended (container for logical partitions)
Select (default p): p
Partition number (1-4, default 1): 1
First sector (2048-7744511, default 2048): 2048
Last sector, +/-sectors or +/-size{K,M,G,T,P} (2048-7744511, default 7744511): +2M 
Created a new partition 1 of type 'Linux' and of size 2 MiB.

Depending on the initial state of your disk you may be prompted that the partition “contains a vfat signature” and asked whether you want to remove the signature. If asked, just type “Y” to confirm.

Next, we’ll set the type for this partition to “7F“

Command (m for help): t
Selected partition 1
Hex code (type L to list all codes): 7F
Changed type of partition 'Linux' to 'unknown'.

to create the 2MB swap partition that FUZIX is expecting. From here we need to create a second 32MB partition to hold our root file system:

Command (m for help): n
Partition type
   p   primary (1 primary, 0 extended, 3 free)
   e   extended (container for logical partitions)
Select (default p): p
Partition number (2-4, default 2): 2
First sector (6144-7744511, default 6144): 6144
Last sector, +/-sectors or +/-size{K,M,G,T,P} (6144-7744511, default 7744511): +32M

Created a new partition 2 of type 'Linux' and of size 32 MiB.

Afterwards if you type “p” at the fdisk prompt you should see something like this:

Command (m for help): p
Disk /dev/sda: 3.7 GiB, 3965190144 bytes, 7744512 sectors
Disk model: STORAGE DEVICE  
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xe121b9a3

Device     Boot Start   End Sectors Size Id Type
/dev/sda1        2048  6143    4096   2M 7f unknown
/dev/sda2        6144 71679   65536  32M 83 Linux

If you do, you can type “w” to write and save the partition table.

Finally, we can copy our root file system into our second 32MB partition:

$ sudo dd if=filesystem.img of=/dev/sda2
65535+0 records in
65535+0 records out
33553920 bytes (34 MB, 32 MiB) copied, 14.1064 s, 2.4 MB/s
$

You can now eject the SD card from the USB card reader, because it’s time to wire up our breadboard.

Wiring things up on the breadboard

If you’re developing on a Raspberry Pi, and you haven’t previously used UART serial — which is different from the “normal” USB serial — you should go read Section 4.5 of our Getting Started guide.

Here I’m using Adafruit’s MicroSD Card Breakout, and wiring the UART serial connection directly to to the Raspberry Pi’s serial port using the GPIO headers.

However, if you’re developing on a laptop you can use something like the SparkFun FTDI Basic Breakout to connect the serial UART to your computer. Again, see our Getting Started guide for details: Section 9.1.4 if you’re on Apple macOS, or Section 9.2.5 if you’re on MS Windows.

Either way, the mapping between the pins on your Raspberry Pi Pico and the SD card breakout is the same, and should be as follows:

Pico	RP2040	SD Card
3V3 (OUT)	—	+3.3V
Pin 16	GP12 (SPI1 RX)	DO (MISO)
Pin 17	GP13 (SPI1 CSn)	CS
Pin 18	GND	GND
Pin 19	GP14 (SPI1 SCK)	SCK
Pin 20	GP15 (SPI1 TX)	DI (MOSI)

Once you’ve wired things up, pop your formatted microSD card into the breadboarded SD card breakout, and plug your Raspberry Pi Pico into USB power. FUZIX will boot automatically.

Connecting to FUZIX

If you’re connecting using a Raspberry Pi, the first thing you’ll need to do is enable UART serial communications using raspi-config.

$ sudo raspi-config

Go to Interfacing Options → Serial. Select “No” when asked “Would you like a login shell to be accessible over serial?” and “Yes” when asked “Would you like the serial port hardware to be enabled?”

Leaving raspi-config you should choose “Yes” and reboot your Raspberry Pi to enable the serial port. More information about connecting via UART can be found in Section 4.5 of our Getting Started guide.

You can then connect to FUZIX using minicom:

$ sudo apt install minicom
$ minicom -b 115200 -o -D /dev/serial0

Alternatively, if you are working on a laptop from macOS or MS Windows you can use minicom, screen, or your usual Terminal program. If you’re unsure what to use, there are a number of options: for instance, a good option is CoolTerm, which is cross-platform and works on Linux, macOS, and Windows.

After connecting to the serial port you should see something like this:

If you don’t see anything, just unplug and replug your Pico to reset it and start FUZIX running again.

Finally, go ahead and enter the correct date and time, and when you get to the login prompt you can login as “root” with no password.

Welcome to FUZIX!

Wrapping up

While there are still a few problems, the port of FUZIX to Pico has been merged to the upstream repository, which means it’s now an official part of the operating system.

Support for developing for Pico can be found on the Raspberry Pi forums. There is also an (unofficial) Discord server where a lot of people active in the new community seem to be hanging out. Feedback on the documentation should be posted as an Issue to the pico-feedback repository on GitHub, or directly to the relevant repository it concerns.

All of the documentation, along with lots of other help and links, can be found on the Getting Started page. If you lose track of where that is in the future, you can always find it from your Pico: to access the page, just press and hold the BOOTSEL button on your Pico, plug it into your laptop or Raspberry Pi, then release the button. Go ahead and open the RPI-RP2 volume, and then click on the INDEX.HTM file.

That will always take you to the Getting Started page.

The post How to get started with FUZIX on Raspberry Pi Pico appeared first on Raspberry Pi.

Post Syndicated from Alasdair Allan original https://www.raspberrypi.org/blog/keeping-secrets-and-writing-about-raspberry-silicon/

In the latest issue of The MagPi Magazine, Alasdair Allan shares the secrets he had to keep while working behind the scenes to get Raspberry Pi’s RP2040 chip out into the world.

There is a new thing in the world, and I had a ringside seat for its creation. 

For me, it started just over a year ago with a phone call from Eben Upton. One week later I was sitting in a meeting room at Raspberry Pi Towers in Cambridge, my head tilted to one side while Eben scribbled on a whiteboard and waved his hands around. 

Eben had just told me that Raspberry Pi was designing its own silicon, and he was talking about the chip that would eventually be known as RP2040. Eben started out by drawing the bus fabric, which isn’t where you normally start when you talk about a new chip, but it turned out RP2040 was a rather unusual chip.

“I gradually drifted sideways into playing with the toys.”

I get bored easily. I started my career doing research into the high-energy physics of collision shocks in the accretion discs surrounding white dwarf stars, but I gradually drifted sideways into playing with the toys.

After spending some time working with agent-based systems to solve scheduling problems for robotic telescopes, I became interested in machine learning and what later became known as ‘big data’.

From there, I spent time investigating the ‘data exhaust’ and data living outside the cloud in embedded and distributed devices, and as a consequence did a lot of work on mobile systems. Which led me to do some of the thinking, and work, on what’s now known as the Internet of Things. Which meant I had recently spent a lot of time writing and talking about embedded hardware. 

Eben was looking for someone to make sure the documentation around Raspberry Pi Pico, and RP2040 silicon itself, was going to measure up. I took the job.

Rumour mill

I had spent the previous six months benchmarking Machine Learning (ML) inferencing on embedded hardware, and a lot of time writing and talking about the trendy new world of Tiny ML.

The rumours of what I was going to be doing for Raspberry Pi started flying on social media almost immediately. The somewhat pervasive idea that I was there to help support putting a Coral Edge TPU onto Raspberry Pi 5 was a particularly good wheeze. 

Instead, I was going to spend the next year metaphorically locked in a room building a documentation toolchain around – and of course writing about – a totally secret product.

I couldn’t talk about it in public, and I talk about things in public a lot. Only the fact that almost everyone else spent the next year locked indoors as well kept too many questions from being asked. I didn’t have to tell conference organisers that I couldn’t talk about what I was doing, because there weren’t any conferences to organise.

I’m rather pleased with what I’ve done with my first year at Raspberry Pi, and of course with how my work on RP2040 and Raspberry Pi Pico turned out.

Much like a Raspberry Pi is an accessible computer that gives you everything you need to learn to write a program, RP2040 is an accessible chip with everything you need to learn to build a product. It’s going to bring a big change to the microcontroller market, and I’m really rather pleased I got a ringside seat to its creation.

The post Keeping secrets and writing about Raspberry silicon appeared first on Raspberry Pi.

Post Syndicated from Liam Fraser original https://www.raspberrypi.org/blog/the-journey-to-raspberry-silicon/

When I first joined Raspberry Pi as a software engineer four and a half years ago, I didn’t know anything about chip design. I thought it was magic. This blog post looks at the journey to Raspberry Silicon and the design process of RP2040.

RP2040 has been in development since summer 2017. Chips are extremely complicated to design. In particular, the first chip you design requires you to design several fundamental components, which you can then reuse on future chips. The engineering effort was also diverted at some points in the project (for example to focus on the Raspberry Pi 4 launch).

Once the chip architecture is specified, the next stage of the project is the design and implementation, where hardware is described using a hardware description language such as Verilog. Verilog has been around since 1984 and, along with VHDL, has been used to design most chips in existence today. So what does Verilog look like, and how does it compare to writing software?

Suppose we have a C program that implements two wrapping counters:

void count_forever(void) {
    uint8_t i = 0;
    uint8_t j = 0;
    while (1) {
        i += 1;
        j += 1;
    }
}

This C program will execute sequentially line by line, and the processor won’t be able to do anything else (unless it is interrupted) while running this code. Let’s compare this with a Verilog implementation of the same counter:

module counter (
    input wire clk,
    input wire rst_n,
    output reg [7:0] i,
    output reg [7:0] j
);

always @ (posedge clk or negedge rst_n) begin
    if (~rst_n) begin
        // Counter is in reset so hold counter at 0
        i <= 8’d0;
        j <= 8’d0;
    end else begin
        i <= i + 8’d1;
        j <= j + 8’d1;
    end
end

endmodule

Verilog statements are executed in parallel on every clock cycle, so both i and j are updated at exactly the same time, whereas the C program increments i first, followed by j. Expanding on this idea, you can think of a chip as thousands of small Verilog modules like this, all executing in parallel.

A chip designer has several tools available to them to test the design. Testing/verification is the most important part of a chip design project: if a feature hasn’t been tested, then it probably doesn’t work. Two methods of testing used on RP2040 are simulators and FPGAs. 

A simulator lets you simulate the entire chip design, and also some additional components. In RP2040’s case, we simulated RP2040 and an external flash chip, allowing us to run code from SPI flash in the simulator. That is the beauty of hardware design: you can design some hardware, then write some C code to test it, and then watch it all run cycle by cycle in the simulator.

The downside to simulators is that they are very slow. It can take several hours to simulate just one second of a chip. Simulation time can be reduced by testing blocks of hardware in isolation from the rest of the chip, but even then it is still slow. This is where FPGAs come in…

FPGAs (Field Programmable Gate Arrays) are chips that have reconfigurable logic, and can emulate the digital parts of a chip, allowing most of the logic in the chip to be tested. 

FPGAs can’t emulate the analogue parts of a design, such as the resistors that are built into RP2040’s USB PHY. However, this can be approximated by using external hardware to provide analogue functionality. FPGAs often can’t run a design at full speed. In RP2040’s case, the FPGA was able to run at 48MHz (compared to 133MHz for the fully fledged chip). This is still fast enough to test everything we wanted and also develop software on.

FPGAs also have debug logic built into them. This allows the hardware designer to probe signals in the FPGA, and view them in a waveform viewer similar to the simulator above, although visibility is limited compared to the simulator.

The RP2040 bootrom was developed on FPGA, allowing us to test the USB boot mode, as well executing code from SPI flash. In the image above, the SD card slot on the FPGA is wired up to SPI flash using an SD card-shaped flash board designed by Luke Wren.

In parallel to Verilog development, the implementation team is busy making sure that the Verilog we write can actually be made into a real chip. Synthesis takes a Verilog description of the chip and converts the logic described into logic cells defined by your library choice. RP2040 is manufactured by TSMC, and we used their standard cell library.

Chip manufacturing isn’t perfect. So design for test (DFT) logic is inserted, allowing the logic in RP2040 to be tested during production to make sure there are no manufacturing defects (short or open circuit connections, for example). Chips that fail this production test are thrown away (this is a tiny percentage – the yield for RP2040 is particularly high due to the small die size).

After synthesis, the resulting netlist goes through a layout phase where the standard cells are physically placed and interconnect wires are routed. This is a synchronous design so clock trees are inserted, and timing is checked and fixed to make sure the design meets the clock speeds that we want. Once several design rules are checked, the layout can be exported to GDSII format, suitable for export to TSMC for manufacture.

(In reality, the process of synthesis, layout, and DFT insertion is extremely complicated and takes several months to get right, so the description here is just a highly abbreviated overview of the entire process.)

Once silicon wafers are manufactured at TSMC they need to be put into a package. After that, the first chips are sent to Pi Towers for bring-up!

A bring-up board typically has a socket (in the centre) so you can test several chips in a single board. It also separates each power supply on the chip, so you can limit the current on first power-up to check there are no shorts. You don’t want the magic smoke to escape!

Once the initial bring-up was done, RP2040 was put through its paces in the lab. Characterising behaviour, seeing how it performs at temperature and voltage extremes.

Once the initial batch of RP2040s are signed off we give the signal for mass production, ready for them to be put onto Pico boards that you have in your hands today.

A chip is useless without detailed documentation. While RP2040 was making its way to mass production, we spent several months writing the SDK and excellent documentation you have available to you today.

The post The journey to Raspberry Silicon appeared first on Raspberry Pi.

Post Syndicated from Alasdair Allan original https://www.raspberrypi.org/blog/how-to-add-a-reset-button-to-your-raspberry-pi-pico/

We’ve tried to make it as easy as possible for you to load your code onto your new Raspberry Pi Pico: press and hold the BOOTSEL button, plug your Pico into your computer, and it’ll mount as a mass storage volume. Then just drag and drop a UF2 file onto the board.

However, not everybody is keen to keep unplugging their micro USB cable every time they want to upload a UF2 onto the board. Don’t worry — there’s more than one way around that problem.

Firstly, if you’re developing in MicroPython there isn’t any real need to unplug and replug Pico to write code. The only time you’ll need to do it is the initial upload of the MicroPython firmware, which comes as a UF2. From there on in, you’re talking to the board via the REPL and a serial connection, either in Thonny or some other editor.

However, if you’re developing using our C SDK, then to upload new code to your Pico you have to upload a new UF2. This means you’ll need to unplug and replug the board to put Pico into BOOTSEL mode each time you make a change in your code and want to test it.

No more unplugging with SWD?

The best way around this is to use SWD mode (see Chapter 5 of our C/C++ Getting Started book) to upload code using the debug port, instead of using mass storage (BOOTSEL) mode.

This gets you debugger support, which is invaluable while developing, and involves adding just three more wires. Afterwards, you’ll never have to unplug your Pico again.

Keep on dragging and dropping

But if you want to stick with uploading by drag-and-drop, adding a reset button to your Raspberry Pi Pico is pretty easy.

All you need to do is to wire the GND and RUN pins together and add an extra momentary contact button to your breadboard. Pushing the button will reset the board.

Then, instead of unplugging and replugging the USB cable when you want to load code onto Pico, you push and hold the RESET button, push the BOOTSEL button, release the RESET button, then release the BOOTSEL button.

If your board is in BOOTSEL mode and you want to start code you’ve already loaded running again, all you have to do now is briefly push the RESET button.

We’ve see some people use the 3V3_EN pin instead of the RUN pin. While it’ll work in a pinch, the problem with disabling 3.3V is that GPIOs that are driven from powered external devices will leak like crazy while 3.3V is disabled. There is even the possibility of damage to the chip. So it’s much better to use the RUN pin to make a reset button than the 3V3_EN pin.

What about the other button?

As an aside, if you want to break out the BOOTSEL button as well — perhaps you’re intending to bury your Pico inside an enclosure — you can use TP6 (that is, Test Point 6) on the rear of the board to do so. See Chapter 2 of the Pico Datasheet for details.

Where to find more help and information

Support for developing for Pico can be found on the Raspberry Pi forums. There is also an (unofficial) Discord server where a lot of people active in the new community seem to be hanging out. Feedback on the documentation should be posted as an issue to the pico-feedback repository on GitHub, or directly to the relevant repository it concerns.

All of the documentation, along with lots of other help and links, can be found on the same Getting Started page from which we grabbed our original UF2 file.

If you lose track of where that is in the future, you can always find it from your Pico: to access the page, just press and hold the BOOTSEL button on your Pico, plug it into your laptop or Raspberry Pi, then release the button. Go ahead and open the RPI-RP2 volume, and then click on the INDEX.HTM file.

That will always take you to the Getting Started page.

The post How to add a reset button to your Raspberry Pi Pico appeared first on Raspberry Pi.

Post Syndicated from Ashley Whittaker original https://www.raspberrypi.org/blog/raspberry-pi-pico-what-did-you-think/

The best part of launching a new product is seeing the reaction of the Raspberry Pi community. When we released Raspberry Pi Pico into the world last Thursday, it didn’t take long for our curious, creative crew of hackers and tinkerers to share some brilliant videos, blogs and photos.

If you’ve spotted other cool stuff people have done with Raspberry Pi Pico, do comment with a link at the end of this post so we can check it out.

Graham Sanderson’s BBC Micro emulation

YouTube went wild for this Raspberry Pi Pico-powered BBC Micro and BBC Master emulation. Graham Sanderson‘s little bit of fun with our latest creation emulates the fine detail of the hardware required to get the best games and graphics demos to run.

He’s put together an entire playlist showing off the power of Raspberry Pi Pico, and it’s a retro gamer’s dream.

Alex Glow

Alex Glow went live for almost an hour unboxing our teeny tiny microcontroller, deep-diving into our getting started materials as well.

She has a good look around our launch blog post on camera too, unpacking some of the technical aspects of how Raspberry Pi Pico is powered, and also explaining why it’s so exciting that we’ve built this ourselves.

Jeff Geerling

Jeff Geerling has used his Pico for good, creating a baby-safe temperature monitor for his little one’s bedroom. In his video, he shows you around some of Raspberry Pi Pico’s “party tricks”, and includes the all-important build montage sequence.

If you prefer words to videos, Jeff has also put together a big ole blog post about our new microcontroller board.

Brian Corteil

Can not believe how popular this tweet has been nearly 100,000 impressions, 777 likes! Oh 😳 as pointed out by Sarah, Tom is 11 not 10. https://t.co/vpFYa1snoo

— Brian Corteil 🤖 (@CannonFodder) January 25, 2021

Brian Corteil took to Twitter to share his eleven-year-old’s pro soldering skills, proving that Raspberry Pi is for everyone, no matter how young, old, or inexperienced, or expert.

Look at the finish on those pins!

16MB Pico modification

Daniel Green did what you were all thinking – desoldered the onboard 2MB QSPI flash chip and replaced it with a 16MB version. Say hello to the first Pico in the world with this special modification. 

Eben himself!

On top of all the brilliant comments, projects, and guidance our community has already shared, Raspberry Pi CEO Eben Upton will be joining the Digital Making at Home crew on Wednesday to show young coders around Raspberry Pi Pico.

Set a reminder for yourself (or your kids) to watch live on YouTube, or join in on Facebook, Twitter or Twitch at 7pm UK time.

The post Raspberry Pi Pico – what did you think? appeared first on Raspberry Pi.