View source for Electronics project notes/Microcontroller and computer platforms

{{#addbodyclass:tag_tech}}
{{electronics notes}}


=Microcontrollers and their common platforms (or otherwise comparatively slow)=


Some pointers for choosing:
* programmability ease - if it means an expensive programmer, hobbyists won't be so interested. If you can do it via an USB/serial cable, yay.

* memory size 
** (...and limits imposed by architecture)
** 8KB isn't much if you want one complex library
** External RAM/ROM is possible, but often bothersome

* physical packaging - if it has a tiny-pitch SMT, you'll probably rely on buying pre-built boards, while 0.1" DIP is more flexible, and can be cheaper than said boards.


<!--
For reference, people tend to call things a microcontroller (MCU) when it's a standalone chip, 
and a microprocessor (MPU) when it relies on nearby chips.

For example, Cortex-M are considered MCUs and Cortex-A considered MPUs,
because they respectively rely on internal (S)RAM like and external (D)RAM.

...but yes, the difference has been getting fuzzy for years.


-->

==On speed==
{{stub}}


Usually depend on what you want.

The point of microcontrollers is often to do a single job well and quickly, with a small device.

{{comment|Somewhat ironically, certain timing becomes ''easier'' to guarantee on something much less powerful,
just because once you start getting something fast, often want to multitask lots of stuff on it, 
and complain that real-time code to solve that is haaard.  In a way, the limitation becomes an upside.)}}


This still ''does'' beg the question how much speed your main task needs.

And that sometimes a perhipheral might make your main task ''so'' much easier than on others,
almost regardless of speed. 
Maybe that FPU saves your use. Maybe that Programmable IO does.


Looking at few details, you might say that:

* Teensy 4 are faster than most of the below (because Cortex-M7), but also pricier

* ESP32s can be a good features-per-price for various projects
:: though its FPU isn't as good as ''some'' (e.g. STM32F4)

* STM32F4 (black pills) (Cortex-M4F)

* RP2040 and RP2350 - speed of a single core is slower than a bunch of STM32s
:: though having two of them can be great, and the PIO can make a few projects more possible than even on beefier hardware
:: and they compare great against varied arduino, especially for their price

* and STM32F1 (blue pills, Cortex-M3) and ESP8266


Arduino Due, and Teensy 3, are presumably comparable to blue pills {{verify}}
 

<!--
https://www.youtube.com/watch?v=337rDuCGeYs
-->

==On RAM==

<!--

'''Most microcontroller/embedded platforms have relatively little embedded (S)RAM'''. 

As such, if you need only moderate amounts of read-write area, then off-chip SRAM is often preferable (see e.g. SPI PSRAM).

This is often an order of magnitude or two slower, but still fast enough for many uses.



The amount is ''roughly'' proportional to general complexity, 
with 2KB for the simplest AVRs, to hundreds of KByte on most others,
but rarely more than that, and if so may involve separate banks.

This is for a few reasons 
* it takes a significant amount of silicon area - and thereby relates to cost. 

* most applications don't need much RAM - it is rare to need significant RAM and ''not' need roughly proportionally more CPU power 
: the cases that do have other options (like external SRAM)

* at some point, you can't have single-cycle access anymore - which means caches and complexity

* DRAM is 
** more power-hungry
** noisier (also less of an option with SoCs that also do RF)

-->

==AVR and Arduino==

The Arduino was classically based on Atmel AVR[http://www.atmel.com/products/avr/], 8-bit microcontrollers. 
With recent models this is shifting.


Probably the main reason for its initial popularity is the fairly low price combined with the ease of prototyping (both for standalone and for slave-to-a-PC projects). 

Arduinos/AVRs technically always were slowish for their price, in that were better speed-for-price choices, but most also require more investment of time and peripheral hardware. 

In short, Arduino was great for hobby stuff (more than bare AVR or bare PIC - even though neither are very hard to deal with, and the two are largely similar)


You get
* programmability without a costly hardware programmer
:: for most boards you only need a USB cable
:: and in some minimal boards you need a USB-to-serial device (or other Arduino to do this for you)
* an IDE were you don't have to dig deep to get started
* a bunch of IO pins that you can leverage using just a few bits of code {{comment|(bunch of GPIO pins, a 10 bit ADC multiplexed to some of them, PWM on some of them)}}, 

The arduino board is a very convenient wrapper, even if the AVR chip is still most of what's there at all (AVR ICs costs ~EUR 5 or less, and you can build stripped-down versions yourself).


When you do want more speed, video {{comment|([http://www.linusakesson.net/scene/phasor/ color composite video generation] is about the limit, and you need an AVR pretty much dedicated to it)}}, audio intput/output, USB, Ethernet at faster-than-serial-port speeds, or such you probably want boards with things like ARM processors and chips dedicated to such input and ouput. [[#Beagleboard|beagleboard]] and [[#sheevaplug|sheevaplug]] come to mind. 



See [[Electronics project notes/Arduino notes]] for some more detailed notes.

==ARM Cortex==


{{zzz|For context|

ARM is a company[https://en.wikipedia.org/wiki/Arm_Holdings]. 


ARM is probably best known for its [https://en.wikipedia.org/wiki/ARM_architecture ARM architecture], 
a specific RISC-style CPU architecture that lends itself to a wide range of embedded processing, SoCs,
and can be scaled up to actually quite serious calculation.

And at the lower end, ARM may be comparable to microcontrollers.

At the higher end, it's a serious challenger to other big-name CPUs, and has since become a more normal option '''as a main CPU''', in part because because major OSes started supporting it (...with footnotes), and in part because its lower energy cost is interesting both to industry and to mobile use.


ARM itself does not actually manufacture any silicon, but has various design series, and [https://en.wikipedia.org/wiki/Arm_Holdings#Licensees various companies have licensed derivations], which means it is now seen in ''varied'' hardware, including some that you wouldn't classically consider general CPUs. You may e.g. recognize 
* Qualcomm's Snapdragon, e.g. used in phones and tablets.

* Microsoft [https://en.wikipedia.org/wiki/List_of_Qualcomm_Snapdragon_systems_on_chips#SQ SQ1 or SQ2] (also Qualcomm), used in Surface

* [https://en.wikipedia.org/wiki/Apple_silicon 'Apple silicon'], better known for its A-series and M-series <!-- ([https://en.wikipedia.org/wiki/Apple_M1 M1], [https://en.wikipedia.org/wiki/Apple_M2 M2], [https://en.wikipedia.org/wiki/Apple_M4 M4]) --> {{comment|(but also more specific R-, T-, S-, C-, R-, W-, and U-series, and an unrelated older M-series{{verify}})}} is ''mostly'' ARM }}


<!--
 -- mostly still in the mobile sense of "scales from efficient to decently powerful" (less in the desktop/gamer sense of "don't care what it guzzles as long as it gives me more fps), with both windows and OSX now running on ARM {{comment|(see Apple's M1, MS's Surface and now ARM dev kit promising more.   That said, most programs you install on both platforms are compiled against x86 so will have be be run in "emulate intel on ARM" mode, which which defeats most of those gains for now[https://www.techrepublic.com/article/windows-on-arm-this-is-how-well-64-bit-emulation-is-working/] yet this might be a good way to get things moving in that direction at all)}}  Point is, in in mobile-ish situations it's great that they 
have better (or at least more predictable) low-lower modes, 
and offer better performance per Watt than a lot of x86.
--> 


Of the wide options in ARM, the '''embedded/DIY realm''' is often interested specifically in the simpler '''ARM Cortex''' family 
(and then often '''ARM Cortex-M'''), so easier to handle in terms of external components, required code.

Cortex is split into three series: 

: [https://en.wikipedia.org/wiki/ARM_Cortex-M Cortex-M] made for low cost and low power
:: which makes it the most interesting for 'like microcontrollers but rather faster' uses

: [https://en.wikipedia.org/wiki/ARM_Cortex-A Cortex-A] 
:: which is fast enough for a basic OS (e.g. used in Raspberry Pi)

: there's also [https://en.wikipedia.org/wiki/ARM_Cortex-R Cortex-R]
:: similar to Cortex-A but geared towards real-time uses (e.g. no [[MMU]])
:: apparently used for things like media players, storage controllers, networking equipment 



===Teensy===

{{comment|(For more lower-level notes, see [[Teensy notes]])}}


'''Teensy 2''' are ATMega AVRs (at 16MHz so comparable to Arduino Mini/Micro/Nano):
: Teensy 2.0 is an ATMEGA32U4
: Teensy++ 2.0 is an AT90USB1286

More interesting is what came after:


{{comment|'''Teensy 3''' is ARM [[Cortex-M]]}}
: {{comment|Teensy LC is an ARM Cortex-M0+ at 48MHz,    ~EUR13}}
: {{comment|Teensy 3.0 is an ARM Cortex M4 48MHz,       ~EUR20}}
: {{comment|Teensy 3.1 is an ARM Cortex M4 72MHz,       ~EUR20}}
: {{comment|Teensy 3.2 is an ARM Cortex-M4 at 72MHz,    ~EUR20}}
: {{comment|Teensy 3.5 is an ARM Cortex-M4F at 120MHz,  ~EUR30}}
: {{comment|Teensy 3.6 is an ARM Cortex-M4F at 180MHz,  ~EUR35}}
: '''consider the 3 series discontinued''', because the specific CPUs used aren't really made anymore


'''Teensy 4''' is also ARM [[Cortex-M]]
: Teensy 4.0 and 4.1 are an ARM Cortex-M7 at 600MHz 
:: 4.0 is more bare-bones (2 Mbyte flash, 1 Mbyte RAM), for EUR25
:: 4.1 adds an Ethernet IC, SD card socket, 5-pin USB header.  ~EUR30


----



'''Voltage'''
: Teensy 3 and 4 are 3.3v devices and not [[5V tolerant]] (some exceptions?{{verify}}).


'''Current draw'''
: Teensy 3 up to ~40mA?{{verify}} <!-- https://forum.pjrc.com/threads/36241-NXPK66-vs-STM32L4?p=127260&viewfull=1#post127260 -->
: Teensy 4 ~100mA at 600MHz


'''RAM'''
* 64KB for 3.2
* 256KB for 3.5 and 3.6 
* 1024KB for 4.0, 4.1 though, note it's in banks.
:: note: 4.1 also has pads for [[PSRAM]] and/or more flash


<!--
IO
* ADC
** Teensy3 has a 16 bit ADC of which about 14 bits are stable
** Teensy4 has a 12 bit ADC of which about 10 bits are stable
* DAC: Teensy 3 have, 4 does not

* PWM 
** Teensy3: a handful of pis
** Teensy4: most pins, some higher res

* Serial: 3 and 4 have a handful

* Teensy4.1 is available with and without ethernet (DP83825 PHY)


-->

===Atmel SAM (Arduino Zero, Due; Seeed XIAO)===

[https://www.microchip.com/en-us/products/microcontrollers-and-microprocessors/32-bit-mcus/sam-32-bit-mcus SAM is a larger set of ARM Cortex-M based series]; Arduino and similar seems to mostly use the SAMD21 and the somewhat faster SAMD51.


https://en.wikipedia.org/wiki/Atmel_ARM-based_processors


Boards interesting to DIYers include:

* [https://store.arduino.cc/arduino-zero Arduino Zero] uses ATSAMD21G18, which is Cortex-M0+

* [https://store.arduino.cc/arduino-due Arduino Due] uses AT91SAM3X8E, which is Cortex-M3

* [https://wiki.seeedstudio.com/Seeeduino-XIAO/ Seeed XIAO]

* https://docs.simplefoc.com/samd_mcu

===STM32===

STM32 are a licensed[https://en.wikipedia.org/wiki/STMicroelectronics] bunch of series of [[Cortex-M]] based devices.


There are many individual models, over various series, 
but (currently) ''broadly'' with speeds somewhere between 20 and 200MHz, and with SRAM and flash up to a few hundred KB.

A subset of pins are 5V tolerant (when you disable pullup/pulldown), others are not,
so you should probably consider this a 3.3V device (sometimes run down to 2V)


That puts it squarely in the "Decent microcontroller and DIY" range.
: '''For more DIYer notes'''
:: see [[STM32 notes]]'''
:: see DIY-oriented board such as
::: {{imagesearch|STM32 blue pill|Blue Pill}}
::: {{imagesearch|Leaflabs Maple}}[https://www.leaflabs.com/maple]
::: {{imagesearch|Nucleo board}}[https://www.st.com/en/evaluation-tools/nucleo-f030r8.html]

===Raspberry microcontrollers (RP2)===
{{stub}}

Comparisons these elicit
* Small ARM-based board - like SAMD21 based Arduino, or [[Teensy LC]].

* Pi Pico W may be an interesting alternative to the ESP8266 / ESP32 (and arguable somewhere between them)

* Arduino and with more SRAM (~264kB)


Can be programmed with 
* MicroPython 
* barer C++
* Arduino IDE


ARM TrustZone, optional boot signing


====RP2040 and Raspberry Pi Pico====

The RP2040 is just the core IC, 
initially sort of made for the Pi Pico 
but there are various [https://en.wikipedia.org/wiki/RP2040#Boards other boards using the RP2040].


* Voltage:
:: RP2040 is a 3.3V device
:: Pico and Pico W add a buck-boost regulator make the RP2040 work from a 1.8 to 5.5V input 
::: (nice for battery powered projects, though there are reasons that e.g. three AAs is more efficient than two[https://forums.raspberrypi.com/viewtopic.php?t=359317])
:: seems to be 5V tolerant in practice, though not 


* CPU: RP2040, 2-core [[ARM Cortex]]-M0+ 
: often run at speeds like 125MHz or 133 MHz 
: fairly overclockable
:: seems stable up to 250MHz{{verify}}
:: CPU can be pushed up to around 400MHz but peripherals start misbehaving, not least of which the external flash)


* 264 KB SRAM (internal)

* Pico adds has 2 MB of external flash

* QSPI dedicated to optional flash (which on various boards is 2 MB or more)


* 3x 12 bit ADCs (technically four but )

* 2x UART
* 2x SPI
* 2x I2C
* it seems most pins can do PWM, at rates rather higher than e.g. Arduino {{verify}}

* the PIO (programmable IO - very simple but high speed)

* USB 1.1 controller
:: host and device

* the raspberry pico board add a buck-boost converter which means it will work off batteries with low voltages
: ...though the low power mode isn't as good as some alternatives

====Raspberry Pi Pico W====

Like Raspberry Pi Pico, but adds {{search|CYW43439}} wireless chip for
: which can do b/g/n WiFi
: Bluetooth and BLE  (came a year after launch, needs firmware update [https://www.raspberrypi.com/news/new-functionality-bluetooth-for-pico-w/])



====RP2350 and Raspberry Pi Pico 2 ====


Compared to RP2040: 
* also dual core CPU, but different: frequently introduced as "two ARM Cortex-M33 cores, and two RISC-V (Hazard3) cores", but it's an either-or (and note that some coprocessors are tied to the ARM cores). {{verify}}

* 520 KB SRAM 

* set of 4 PIO cores{{verify}}

* some more PWM

* variants with more ADC

* variants with internal Flash

* RNG, SHA-256

====Raspberry Pi Pico 2W====

Like Raspberry Pi Pico 2




====More on the PIO====
{{stub}}


PIO describes what amounts to multiple separate but ''extremely simple'' cores. 

There are only nine instructions, and this limits your options to what you can mostly view as a state machine,
which most of the time is used to push data through quickly with well-controlled timing.


There are multiple such cores -- apparently blocks of four (two such blocks in the RP2040, three in the RP2350) which matters in that each block shares 
: instruction memory,
: four read ports (which allows some parallel access without blocking)

They cannot communicate data with each other, 
: ...but they can synchronize (down to the cycle?{{verify}}) using interrupts, so they can still coordinate to output something more complex


You could see it as hardware bit-banging - in the sense that it's programmable,
which doesn't occupy the main CPU cores or interrupts, and it seems the designers figured 
we don't need as many dedicated peripherals when we have these - it's already been seen to used
to talk
: more UART
: more I2C
: more SPI
: I2S

: neopixels
: small LCD panels
: VGA,
: Arbitrary waveform generator [https://www.instructables.com/Arbitrary-Wave-Generator-With-the-Raspberry-Pi-Pic/]
: [https://github.com/sekigon-gonnoc/Pico-PIO-USB additional USB]

: a [https://github.com/raspberrypi/pico-examples/blob/master/pio/logic_analyser/logic_analyser.c logic analyser]



Programmable IO [https://www.youtube.com/watch?v=yYnQYF_Xa8g]

<!--
a clock division to run the program at (default is board speed)
: 16 int
:: so 125MHz / 65535 = ~1907 is the minimum speed
: plus 8 fractional
:: which helps you set rates not exact divisions of the board speed
-->


Each such state machine contains:
: input FIFO, output fifo  (each four 32-bit) 
:: to communicate to CPU, DMA, etc.
:: configurable so that if you only need one direction you can effectively double the size

: PC register

: two scratch registers (32 bit)
:: conditions are based on these

: two shift registers (32 bit), in and out
:: connected to the FIFOs (towards the CPU)
::: can read from GPIOs - and multiple at once

: clock divider

: IRQ
:: alerting CPU
:: syncing state machines
:: eight flags, four of which are exposed to the CPU


: each instruction takes one cycle 
:: though each instruction can request up to 31 clocks of idle (takers 5 bits of each 16-bit instruction)
:: and WAIT has the job of stalling until a condition is met

: flexible mapping to GPIO pins
:: input, output, set, sideset



Docs: https://www.raspberrypi.com/documentation/microcontrollers/raspberry-pi-pico.html

===Others===

==ESP8266, ESP32, etc.==

See [[Electronics project notes/ESP notes]]

="Haven't personally used yet" list=
{{stub}}

==PIC==
{{stub}}

Comparable with AVR in many ways, has a wider range of choices and features,
sometimes the more capable choice for a given project.

The main difference for starter hobbyists is that it lacks and Arduin-style standard board.

Also, people stick to what they already know, though, so for a large part, PIC people use PIC, AVR people use AVR.


==nRF24, nRF51, nRF52, nRF53==
{{stub}}

A few series of IC from Nordic, of which nRF24L01 is probably best known by DIYers but various others.

(see also [[Electronics_notes/Various_wireless_notes#ESB_(nRF_series)]] for some comparison in the RF sense)


SoC with ARM Cortex CPUs, 

The RF part speaks Bluetooth BLE, and also [[ANT]], Thread (802.15.4), and Nordic's own ESB{{verify}}

<!--
PWM, 

PDM input,
-->
 

The nRF24 mostly just a transceiver with SPI interface, while e.g. 
the NRF52 can functionally be thought of as a NRF24 ''plus'' an ARM Cortex M4{{verify}}
that you can actually program.


* nRF51
: nRF51824
: nRF51822
: nRF51802
: nRF51422
: For new projects, you might see nRF51 can be seen as an older variant of the nRF52. 

* nRF52  
: The variants ''within'' the NRF52 are mostly differences in features like ADC, I2S, 
: some do NFC (nRF5283x and nRF5284x?)
: nRF52810/nRF52811
: nRF52820
: nRF52832
: nRF52833
: nRF52840

They are similar so code should be portable
The features they share should be compatible 
hardware PWM, PDM, I2S, NFC, ++), 

* nRF53
: Bluetooth, 8.15.4, NFC
: direction finding
: nRF5340



* nRF70 
: 2.4 and 5GHz WiFi (b/g/n/ac/ax)
: nRF7002
: nRF7001 2.4 GHz only
: nRF7000

* nRF91
: LTE?
: 700-2200 MHz 
: nRF9161
: nRF9160


You can get a lot of comparison out of {{search|Nordic Product Guide}}

<!--


Of the thee nRF5x series, apparently the NRF52 is most comparable with (and compatible with) the NRF24, 


Arduino Nano 33 IoT is mostly a NINA B306 - which seems to be a nRF52840 plus PCB antenna.


-->

https://www.nordicsemi.com/products/nrf24-series

==CH32==

===CH32V===

RISC-V based. There are more variations, but the two you seem to be able to get for DIY:

<!--
https://github.com/openwch/ch32v002_004_005_006_007

CH32V103 
https://github.com/openwch/ch32v20x

-->

====CH32V003====

<!--
This is a ''very'' stripped down microcontroller.

Programmable, ''very'' cheap (you can get it on a board for EUR1.5),
but also ''minimal'' features:
* RISC-V at 48MHz, 
* 2KB SRAM
* 16KB Flash
* 10-bit ADC
* USART
* I2C
* SPI
* DMA
serial debug interface
-->

====CH32V307====

<!--
A RISC-V at 144MHz, 
64KB SRAM
256KB Flash

-->

===CH32F===

<!--
CH32F203

ARM based

-->

==STM8==
<!--

8-bit microcontrollers that can be likened to Arduino, 
though whether it's similar features for similar price or not depends on your option.


Like the STM32 you may be familiar with, it consists of a bunch of subfamilies, 
though the DIY side has mostly focused on STM8S (and occasionally the lower power STM8L){{verify}}.

...and a bunch of models within each, within STM8S 

STM8S001
STM8S003
STM8S005
STM8S103
STM8S105
STM8S207


STM8S103

STM8S105


https://en.wikipedia.org/wiki/STM8

-->


==HT66F002==
<!--

-->

==LGT8F328p==
<!--

Seemingly a drop-in replacement for ATmeaga328p 
with very comparable specs overall, and some improvement:
: Higher system clock (32Mhz)
: 12-bit ADC (instead of 10) 
: 8-bit DAC (instead of none)

-->

==Max32==
<!--
Based on a PIC32, 
physical designed similar to an Arduino,

80 MHz
512K of flash
128K of SRAM 
USB 2 OTG controller
10/100 Ethernet MAC
CAN
-->

==Wiring==

There is a [http://wiring.org.co/hardware/ Wiring board], made for the [http://wiring.org.co/ Wiring software].

The basic Wiring board is comparable to an Arduino Mega, with a few differences.


(sold e.g. [http://www.sparkfun.com/commerce/product_info.php?products_id=9663 here])

==(MIT) HandyBoard==

Based on (Freescale) 6811 microcontrollers (at 2MHz?)

...and cricket?

http://www.handyboard.com/

===Parallax===
http://www.parallax.com/ProductInfo/Microcontrollers/tabid/121/Default.aspx


'''Basic Stamp'''

https://www.parallax.com/microcontrollers/basic-stamp


'''Propeller'''

https://www.parallax.com/microcontrollers/propeller


==BUG==
http://www.buglabs.net/


==PICAXE==
{{stub}}
http://www.rev-ed.co.uk/picaxe/


==(NetMedia) BasicX (BX)==
<!--


Such as BasicX-24 (BX24), BasicX-35 (Just the CPU used in the BX24), BasicX-01



[http://www.basicx.com/]

(variation on Basic Stamp?)
-->
==Forebrain==
<!--

32bit ARM (Cortex M3) at 72MHz.

Somewhat like a souped up arduino

http://www.universalair.co.uk/forebrain
-->

==(Leaflabs) Maple==
<!--

32bit ARM (Cortex M3) at 72MHz.

Somewhat like a souped up arduino

http://leaflabs.com/devices/maple/
-->

<!--
==Unsorted==
BasicATOM



6812
(Technological Arts) NanoCore [http://www.nanocore12.com/]
FreeScale 68HC12, a.k.a. HC12

Since the mid-nineties

8-bit ALU
16-bit addressing
16MHz
4 KB EEPROM
1 KB RAM
[[SPI]]
SCI
    * 8 channel 16 bit timer (Input Capture/Output Compare)
    * 8 channel 8 bit A/D converter
    * up to 80 I/O pins
-->

=PLCs=

<!--

Programmable Logic Controllers lives in the same sort of area as SCADA - names a grouping of devices that is pragmatic enough to get a name (where SCADA is often more encompassing setup with software, PLCs are more individual/standalone).


PLCs were designed to replace systems that used relays for logic in commercial/industrial systems,
and today we might compare them with microcontrollers - IO and a program, 
...but 
* in a rugged housing,
* with a standardized power supply (usually 24V), sometimes built in,
* probably rail mounted,
* has relays (for actuation, not logic) and/or transistor output,
* often with visible input and output,
* with certain protections (e.g. isolation).

...it's that specific because they are primarily made for industry, 
where minimizing downtime is most important, so ruggedness, 
ease of debugging in use, and backwards compatibility (including the code - within a brand)
are more important than unit cost.


In this "robust automation", they are arguably a more flexible variation on things like cam timers.


They are programmable is a relatively basic way; more complex than a handful of relays, 
but also simpler than even the simplest of today's microcontrollers{{verify}}



Their code is something like 
if/then
with a state machine 
plus some timers


These days they look a lot like microcontrollers - and in fact can be implemented that way now. [https://www.controllino.com/],
yet the old style is still made a lot, because why break what was well engineered, and this way replacing them is so much easier.




-->

=Computer-like=
==Some thin clients, netbooks, palm/pocket sized stuff==
{{old}}

Effectively a middle way (in capabilities and price) between things like the beagleboard and a regular computer.

Often less great on the amount of IO you want in projects, 
but if you want a fancier thing to interact with, e.g. it's a ''lot'' easier to use a ready-made thing with an IDE for it than try to drive a tiny LCD from a microcontroller.


You may find options in the EUR/USD100-250 range, which often isn't a whole lot more than some dedicated-purpose devices, and can be a lot more flexible since they give you common interfaces and may let you run something general-purpose like linux.

At some point netbooks may become interesting, as from this perspective they are battery-backed, small and nicely boxed devices with built-in screens and start in this price range.


Currently often based on one of:
* Intel Atom[http://en.wikipedia.org/wiki/Intel_Atom] (x64)

* AMD's newer low-power chips (Competitors to Atom, CULV, and such), including Huron (Neo) and Geneva {{comment|(Yukon and Nile refer to portable platforms that include the Huron and Geneva, respectively)}}

* VIA Nano[http://en.wikipedia.org/wiki/VIA_Nano] (x64)

* VIA C7[http://en.wikipedia.org/wiki/VIA_C7] (x86)
* VIA C3[http://en.wikipedia.org/wiki/VIA_C3] (x86)
* VIA Eden[http://en.wikipedia.org/wiki/VIA_Eden] (x86)

* ARM7[http://en.wikipedia.org/wiki/ARM7] (ARM architecture[http://en.wikipedia.org/wiki/ARM_architecture] is often used for specific-purpose embedded applications, and can be very good for their price)
* ARM9[http://en.wikipedia.org/wiki/ARM9]
* ARM11[http://en.wikipedia.org/wiki/ARM11]
* (ARM) Cortex

ARM processors span a wide range of speeds (stopping short of being part of the competitive netbook market, making it fit for various embedded and mobile uses. Quite a few phones use ARMs (often ARM11, occasionally ARM9), as do various tablets, the [http://en.wikipedia.org/wiki/Nintendo_DS Nintendo DS] <!--{{comment|(a combination of ARM9 (mostly for gameplay, video) and ARM7 (mostly for wifi, audio))}}.
-->

==NVidia Jetson==
<!--

Based on [https://en.wikipedia.org/wiki/Tegra Tegra] SoC, which is an ARM CPU and scaled down versions of current nVidia GPUs.

(Tegra is also seen in some phones, tablets, chromebooks and similar, Nintendo Switch)





https://www.nvidia.com/en-us/autonomous-machines/embedded-systems/

https://developer.nvidia.com/embedded/develop/sftware

-->

==Raspberry Pi==

Comparable to a plug computer, but more like a real PC in use.


Architecture is ARM rather than x86, though.

Could run anything you can compile for ARM.

Which typically means people run linux on it.
Some distros have tooling to make this easier, and often ready-made pi-specific builds (e.g. Arch, Debian).

Various hardware (e.g. WiFi, sound in) could be added via USB dongles,
assuming the driver is compiled for ARM. 


For years this excluded windows completely (they didn't like ARM until later), but there is now an a Windows 10 for ARM (related to products like the Surface Pro X), and there is [https://worproject.com/ a project that helps install it].  Initially this meant only ARM apps (so basically ''none'' of your everyday apps), but now there is x86 and x64 emulation letting you run them, and it's not even that slow.

Driver support (for the Pi's own devices) seems to also not be too bad.



<!--
The video playing ability is fairly impressive, where particularly on the first generation doing anything else on the CPU feels relatively sluggish.
-->

Initial boot is from SD card({{verify}} - I've seen people boot it from M.2).


See also:
* http://elinux.org/RPi_Low-level_peripherals


===Board variants===

====Larger boards====
'''First-gen (A or B)'''
* [http://www.broadcom.com/products/BCM2835 BCM2835] package, contains
** CPU: a 700 MHz ARM11  (ARMv6 arch)
** GPU: a [http://en.wikipedia.org/wiki/VideoCore Videocore] 4
*** capable of 40MBits/s H.264 steams (~H.264 high profile, 1080p, though for some video may need the 256MB or 512MB RAM models of the board)
*** [[OpenGL ES]] (and [[openVG]])
** USB
** SDRAM
*** memory has been specced higher in later variants. 128MB, 256MB, or 512MB RAM (not physically upgradable)
* Composite video out
* audio out
** 3.5mm jack, PWM based rather than a DAC
** audio via HDMI
* the 26-pin is e.g. for the DIY crowd {{comment|(there's also the VideoCore's JTAG, the USB/Ethernet chip's JTAG, but few will be interested in those)}}
** 3.3V (50mA limit), 5V (direct from power source)
** GPIO pins
*** some of which have specializations like SPI, I2C, UART, PWM, JTAG
*** Most can hook to interrupt handlers{{verify}}
*** note that the exact layout has changed between board revisions. Pay attention.

'''Model A''' - above, but...
* no Ethernet
* just the one internal USB port

'''Model B''' - as above, but in the comparison to A and B+ ...
* 10/100 wired Ethernet (via USB2, so gigabit wouldn't make sense)
:: uses a {{search|LAN9514}} to serve USB2+FE (see e.g. [https://www.element14.com/community/community/raspberry-pi/blog/2017/01/16/raspberry-pi-3-block-diagram this diagram for a Pi3]) (also why this 100Mbit ethernet had share bandwidth with USB)
* Two USB ports (via on-board hub device)
* [http://en.wikipedia.org/wiki/Mobile_Industry_Processor_Interface MIPI] (for 15-pin camera interface. Not very usable yet?{{verify}})


'''Model B+''': Like B, but...
* 14 more GPIO pins
* ''Four'' USB ports, better hotplug and overcurrent behaviour (much less likely to reset at USB insert)
* micro-SD slots instead of SD (and click instead of friction-lock)
* a little more power efficient (swithing [[regulator]] instead of a linear one)
* audio circuit less noisy
* composite video out is now part of the 3.5" jack, not a separate RCA plug (nor broken out elsewhere)
:: It's a [[TRRS]] plug, with the ordering (from sleeve to tip) Video, Ground, Left Right -- see notes below.



'''Raspberry Pi 2'''
* BCM2836, ARM Cortex-A7 (ARMv7 arch), 900MHz 4-core
: VideoCore 4 @ 900MHz
: CPU up to ~2x as fast as Pi1 B+
* 1GB RAM


'''Raspberry Pi 3''' - mainly faster and more memory:
* BCM2837, ARM Cortex-A53 (ARMv8 arch), 1200MHz 4-core
: VideoCore 4 @ 400MHz {{verify}}
: ~60% faster than Pi 2 in best case{{verify}}
* 1GB RAM (DDR2)
* WiFi (11ac, 2.4+5ghz)
* Bluetooth 4

'''Raspberry Pi 3+'''
: Ethernet+USB: Changed chips to a {{search|LAN7515}} technically gigabit though in practice tops out at maybe 300Mbit, and is sharing with USB {{verify}}
: wifi is dual band: {{verify}}
: https://www.rs-online.com/designspark/raspberry-pi-3-model-b-vs-3-model-b


'''Raspberry Pi 4'''
* BCM2711, Cortex-A72 (ARMv8 arch) 1500MHz 4-core
: VideoCore 6 @ roughly 500MHz
* 1/2/4GB RAM (DDR2{{verify}})
* bluetooth 5
* wifi (11ac, 2.4+5ghz)
* adds USB3 (though with initial hiccups)
: {{search|VL805}} for 2xUSB2, 2xUSB3
* ethernet port is gBit capable (switched to a {{search|BCM54213PE}})
* dual video output / 4K res now at 60p 
* reported issues:
:: at maximum use the CPU you will likely hot enough to throttle, so you want some more cooling
:: Powering from a proper USB-C power source has issues that can lead to a proper USB-C charger (sensibly) refusing to charge i.e. power it
::: due to a slight misdesign, it can misreport what it is, depending both on charger and cable you use[https://arstechnica.com/gadgets/2019/07/raspberry-pi-4-uses-incorrect-usb-c-design-wont-work-with-some-chargers/])}}
::: There are easy workarounds, like running it via an {{imagesearch|USB micro to USB-C adapter|adapter}} from a basic USB-A wallwart (given it's ~2A-capable, though ~3A is preferable?{{verify}})


'''Raspberry Pi 5'''
* Broadly similar to 4; differences include
* BCM2712, Cortex-A76 (ARMv8 arch) 2.4GHz 4-core
: VideoCore 7 @ roughly 1 GHz {{verify}}
* up to 8GB RAM (LPDDR4{{verify}})
* Adds PCIx, e.g. allowing M.2 (on a HAT)
* Peak draw is ~25W so you'd want a USB-C ideally capable of perhaps 5A (at 5V){{verify}}

====Pi Zero====

'''Raspberry Pi Zero'''
* BCM2835 (same as 1st gen Pi, though clocked 40% faster)
* 512MB RAM
* smaller board, and GPIO pins come unpopulated to stay slim.
* USB/power via USB
* USB host port is ''also'' micro style, so you need a {{imagesearch|USB OTG cable}} to get that into a more standard USB A
* TV out is on two (unpopulated) pins
* On sound:
: Omits the headphone-jack-and-RC-filter (and a opamp buffer on B+ and 2 models) that the basic Pis have
:: if you want, you ''can'' reproduce that externally, see e.g. 
::: https://learn.adafruit.com/introducing-the-raspberry-pi-zero/audio-outputs
::: https://www.raspberrypi.org/forums/viewtopic.php?f=91&t=86609
:: HDMI sound is still there
:: USB sound can be done cheap, but not all are supported, and quality of most cheap dongles still isn't great
:: if you care about good quality analog sound, you want a decent DAC anyway (is available HAT-style)

'''Raspberry Pi Zero W'''
* like Zero, adds WiFi (11n) and bluetooth (4)
: {{comment|(side note: this allows using a bluetooth keyboard/mouse instead of USB-OTG fiddling)}}

'''Raspberry Pi Zero 2 W'''
* like the Zero W, but the RP3A0 SiP contains the same BCM2710A1 as used in the BCM2837 
: {{comment|(read: "basically the same as RPi 3, rather than a first-gen", though still with 512MB RAM)}}
* most other differences are minor

====Pi Pico====

'''Raspberry Pi Pico''' (not to be confused with the Zero)
isn't a single-board computer, it's basically a microcontroller - see [[Electronics project notes/Microcontroller_and_computer_platforms#RP2040_and_Raspberry_Pi_Pico]]

===Notes on RPi GPIO===
<!--
Raspberry pi GPIO is 
* 3.3V (not 5V tolerant)
* limited current
* pullup values seem to vary between pins{{verify}}, and be quite high, so this can be more sensitive to EM than you want
* wired directly to the SoC so easy to fry
* HATs may take pins at will, so it's up to you to find a free one
* only accessible to root
: you could run everything as root (the botnet thanks you for making its life simpler if your code ever gets used widely enough to become a useful targer)
: there are workarounds, but they are ''slow''

This is one reason people tend to use I2C port expanders - or even just a separate arduino



I use this one from a small UK manufacturer, I'm sure there are similar ones more easily available in the US:
https://www.abelectronics.co.uk/p/54/IO-Pi-Plus

Or you can build one:
https://learn.adafruit.com/mcp230xx-gpio-expander-on-the-raspberry-pi/overview

-->

===Notes on RPi power===


For an idea of idle and loaded draw, see graphs like https://raspi.tv/2019/how-much-power-does-the-pi4b-use-power-measurements

The low end is mostly interesting for battery life. 

Both are interesting for requirements on your power - e.g. Pi4 is harder to power from power banks or smaller wallwarts.


Pi1 
: Model A specced for ~300mA max{{verify}}
: Model B for ~700mA max{{verify}}
: Zero   ~250mA max {{verify}}
: Zero W ~350mA max {{verify}}

Pi2
: ~700mA max {{verify}}

Pi3
: ~800mA max {{verify}}

Pi 4:
: people have reported ~2A supplies tend to be good even under high CPU use (and something between 1A~2A under simple use)
: on paper worst case may be up to 3A

<!--
Pi 5:
: might use 500mA idle, 800mA working{{verify}}
: might use 300mA when "off" because it might be configured to leave the SoC on but in shutdown state, because some HATs don't like what the rails do if you ''really'' power off[https://www.jeffgeerling.com/blog/2023/reducing-raspberry-pi-5s-power-consumption-140x]
: recommends 5A though it seems ~1A is just provisioning for USB
-->


'''...plus whatever you draw through USB''' - powered USB hubs help here.


The Pi 3+ and 4{{verify}} have a [[PMIC]], that detects and reports low voltage (under ~4.7V on its input), making it easier to diagnose insufficient power supplies.


See also:
* https://raspi.tv/2019/how-much-power-does-the-pi4b-use-power-measurements
* https://raspberrypi.stackexchange.com/questions/26526/current-draw-for-2-0-models/40393#40393
* https://github.com/raspberrypi/documentation/blob/develop/documentation/asciidoc/computers/raspberry-pi/power-supplies.adoc




====Saving power====
{{stub}}


tl;dr:

* Raspberries do not have anything like [https://en.wikipedia.org/wiki/Advanced_Configuration_and_Power_Interface ACPI], so there is no sleeping
: you can turn it off completely (and may still use on the order of ~70mA then{{verify}}), but restarting it later will need something external

* Most power use, idle or max, seems to come from the overall system speed
:: so has increased as generations have grown more powerful.
:: which over/underclocking can barely change

* still lower when fairly idle, so try to minimize workload


So for a low-computational-load purposes, an older Pi (and note that Zero / Zero W are basically scaled down earlier-gen) can easily be the more power-efficient choice, and 4 the fastest/hungriest, see e.g.
: https://raspi.tv/2019/how-much-power-does-the-pi4b-use-power-measurements
: https://magpi.raspberrypi.org/articles/raspberry-pi-4-specs-benchmarks



That said:

For example, you can save
* anywhere from nothing to practically maybe 100mA by minimizing CPU use
:: {{comment|(that 100mA is arbitrary, less than the max-min use. I'm assuming you can optimize only so much, and am being optimistic)}}

* a little by disabling some peripherals you don't use {{comment|(note: ability to do so varies a little per model)}}
** 20~30mA {{verify}} by disabling HDMI
** a few mA by changing/disabling a LED or two 
** 20-50mA {{verify}} disabling WiFi (Pi3, 4)
** USB is a more complex story (see below)


'''HDMI'''
<!--
sudo /opt/vc/bin/tvservice -o


Pi4:
 vcgencmd display_power 0 3 to turn off HDMI0
 vcgencmd display_power 0 7 to turn off HDMI1
(not sure the savings are the same)
-->


'''LEDs'''
<!--
Variations per pi

A LED takes a few mA.
[https://www.jeffgeerling.com/blogs/jeff-geerling/controlling-pwr-act-leds-raspberry-pi]
-->


'''WiFi, BT'''

<!--
Save ~40mA idle-ish {{verify}} by disabling wifi on RPi 3 and 4, when you're not using it.

Disabling bluetooth seems to have negligible effect - when it was unused. {{verify}}

(there are slight differences in hardware between 3B and 3B+/4, but they shouldn't matter here{{verify}})


In theory, you can only connect when you need to, but since the connection takes a few seconds,
this is probably only interesting for things like non-realtime logging.
-->


'''USB and ethernet''' 

<!--
Details vary with model, e.g. 
: e.g. 1 A doesn't allow it {{verify}}
: 2 and 3 had finer control (which used a combined USB2+Ethernet chips)
: Pi4 has less control again (uses a different chip for USB2+USB3, and separate one for Ethernet)

* the control per hub ''may'' extend to external hubs


People report that on the 2 and 3, disabling the USB+Ethernet IC, you save fairly little if they were unconnected anyway (others report saving up to 100~200mA but that much difference suggests much of that came from connected devices not being idle).

Note that since the USB powerlines aren't cut, some devices draw some power even with USB disabled{{verify}}.


Pi4, which has USB3, seems to only support overall disable, models before had finer control)
(it does have a completely separate Ethernet IC - can you disable that, though?)



The LAN9xxx (Pi2, 3)lets you control power per port{{verify}}, per hub{{verify}}

The VL805 (Pi4) only lets you 

Note that power lines to devices aren't cut, it just means that devices will not enumerate - which for ''most'' devices means they will do very little so draw little current (but apparently are not required to - I have some devices with idle behaviour).


Note also that Pi B+ and 2 could be told to handle more current (see max_usb_current, safe_mode_gpio=4)

-->




'''CPU'''

The CPU is one of the larger power users. 

The CPUs always did frequency scaling and, by default, fairly aggressively. 
So if you can do your work more efficiently, it'll put it near its lowest speed (baseline power user) more often {{comment|(which is why idling in that graph linked above differs less than peak use differs)}}. 
{{comment|(disabling a few pointless background processes can also help, except they tend to not use much)}}

It turns out the effects from underlocking are small, {{comment|(if you're using it fully you'ld just slow down the task, and if you're mostly idle you're not changing most of what that basic current draw comes from)}} and the undervolting need for that to make more of a dent may affect stability (of e.g. PCIe{{verify}}).

So the most effective thing you can do is lowering your workload.

<!--
https://learn.pi-supply.com/make/how-to-save-power-on-your-raspberry-pi/#throttle-cpu

There are some things you can still do. Consider that 
* aside from the ARM CPU, there are some other somewhat-dedicated cores that can be slowed

* if you're mostly idle, then lowering the idle frequency may still help - 
: ...but relatively little, and it can sometimes affects stability


You may prefer rpi-config for this. You can also find the variables yourself. 
-->



'''Regulation'''

It seems that before 3+/4, the 3.3V rail came from a linear regulator, so you ''could'' get a slight win from replacing that with a switch mode 3.3V[https://bitwizard.nl/wiki/Reducing_power_consumption_of_a_raspberry_Pi].


The 3+/4 switched to a switching {{search|MxL7704}} PMIC, which you're less likely to beat.

The Zeros (and pre-+ 3{{verify}}) also seem to have a switch-mode (PAM2306).



TODO: read:

http://www.earth.org.uk/note-on-Raspberry-Pi-setup.html

https://www.raspberrypi.org/documentation/configuration/config-txt/overclocking.md

https://mlagerberg.gitbooks.io/raspberry-pi/content/5.1-power-consumption.html

https://community.roonlabs.com/t/underclocked-pi-4-the-perfect-low-budget-77-usb-bridge/93743/8

https://www.raspberrypi.org/forums/viewtopic.php?t=257144

https://www.jeffgeerling.com/blogs/jeff-geerling/controlling-pwr-act-leds-raspberry-pi

https://www.researchgate.net/publication/309917878

<!--
https://www.jeffgeerling.com/blog/2019/best-way-keep-your-cool-running-raspberry-pi-4

https://magpi.raspberrypi.org/articles/how-to-overclock-raspberry-pi-4



-->

===Notes on video out===
{{stub}}

The first-gen B+ has a 4-pin plug (a.k.a. [[TRRS]], Tip-Ring-Ring-Sleeve) on which you can immediately use audio using a regular 3.5mm plug, while using composite video out (at all ''or'' alongside audio) will require a 4-pin (TRRS) plug.


Note that if you have a TRRS-to-four-RCA adapter cable, [[Common_plugs_and_connectors#TRS_pinout|it can have a variant wiring]].
: Often it just has two functions swapped (e.g. video and audio-right) so only requires a little trial and error. 
: Sometimes it requires rewiring.



The behaviour of forced / auto-detection between HDMI and composite depends on settings in <tt>/boot/config.txt</tt> (see pages like [http://www.raspberrypi.org/documentation/configuration/config-txt.md this] for reference if your config.txt doesn't have a lot of elaboration). 


Mainly: If you want to '''force use of HDMI''', even if it won't always be attached at boot:
 hdmi_force_hotplug=1
If you want to '''force use of composite''', even if HDMI is attached at boot:
 hdmi_ignore_hotplug=1 
Both these settings are 0 by (stock-)default.


To force a specific '''HDMI''' resolution or aspect, look at how {{inlinecode|hdmi_group}} and {{inlinecode|hdmi_mode}} ''combine''. You may also want to check what your monitor is capable of first:
 edidparser edid.dat > edid.txt
(For CEA modes from that list, use hdmi_group=1, for DMT modes use hdmi_group=2)

If you want a resolution that is ''not'' in that list, look at {{inlinecode|hdmi_cvt}}, see e.g. [http://www.raspberrypi.org/forums/viewtopic.php?f=29&t=24679] 

If you have a HDMI TV that wakes up when rebooting the Pi, that's because it sends an Active-Signal message. 
You can disable that:
 hdmi_ignore_cec_init=1

When tweaking for your specific monitor, you may want to:
* http://weblogs.asp.net/bleroy/getting-your-raspberry-pi-to-output-the-right-resolution


Some software won't send audio over HDMI unless you force it: 
 hdmi_drive=2
(1 is no sound, 'DVI mode')


'''Composite''' variants:
 sdtv_mode=2
Where:
 0    Normal NTSC
 1    Japanese version of NTSC – no pedestal
 2    Normal PAL
 3    Brazilian version of PAL – 525/60 rather than 625/50, different subcarrier
And its aspect ratio - 4:3 is default
 sdtv_aspect=1
Where:
 1    4:3  (default)
 2   14:9
 3   16:9

You may wish to play with overscan, e.g.
 disable_overscan=1
and e.g.
 # larger, TV that shows more black border than you want:
 overscan_left=-10
 overscan_right=-10
 overscan_top=-30
 overscan_bottom=-30
or:
 # smaller, e.g. for a TV that removes too much of the edge by default:
 overscan_left=10
 overscan_right=10
 overscan_top=30
 overscan_bottom=30


See also: 
* http://www.raspberrypi.org/forums/viewtopic.php?f=28&t=82063]
* http://www.raspberrypi-spy.co.uk/2014/07/raspberry-pi-model-b-3-5mm-audiovideo-jack/

* http://www.raspberrypi.org/forums/viewtopic.php?f=29&t=24679

====OMX====
<!--

OMX
http://www.raspberry-projects.com/pi/software_utilities/omxplayer

http://omxplayer.sconde.net/

http://www.raspberrypi-spy.co.uk/2013/06/playing-videos-on-the-raspberry-pi-command-line/



OMX / Clearing screen:
http://www.ducky-pond.com/posts/2013/Nov/how-to-clear-the-terminal-when-using-omxplayer-on-raspberry-pi/

https://github.com/huceke/omxplayer/issues/22

http://www.raspberrypi.org/forums/viewtopic.php?f=35&t=9789

http://raspberrypi.stackexchange.com/questions/3268/how-to-disable-local-terminal-showing-through-when-playing-video
-->

===Notes on the videocore===
{{stub}}

VideoCore has parts like:
* VPU
: media coprocessor (think JPEG and H264 accel) {{verify}}, so a a SIMD type thing (also 2 cores of it?)
: runs firmware (partly closed because licensing) that drives video acceleration, and 3D
: In typical use the VPU uses the QPU for OpenGL. the QPU is a 12-way{{verify}} SIMD, running a fairly fixed pipeline for fragment, vertex, and coordinate shading.


https://www.youtube.com/watch?v=eZd0IYJ7J40

https://github.com/hermanhermitage/videocoreiv/wiki/VideoCore-IV-Programmers-Manual

===On SD corruption===
{{stub}}

<!--
A few potential issues:

* there is always a chance that powering off can happen during a write
: on SD/flash, this is likely to be in an erase-write cycle (on SSD this is much less likely)
: possibly some journaling, copy-on-write filesystems deal better?
: consider writing only to SSD (probably USB connected) where possible, not to SD
: (also, always shutdown explicitly)

* crappy power supplies
: also, brownouts (as in, underpowered power supplies) are likely to have bad because it can reboot, but also make writes less predictable at all{{verify}}

* SD quality is unknown, and there's a lot of low quality cards out there

* SD doesn't do wear leveling 
: so running off on-board eMMC (e.g. using a [[beagleboard]] instead of a Pi), or external SSD, is arguably preferable

* environments with high amounts of EM noise can make it to IO lines, so a shielding case can matter
: again mostly relevant to writes
: applies to ''any'' storage medium, but something to keep in mind



Consider:
* find out what's writing
: tools like [[iotop]] helps 
:: (probably {{inlinecode|iotop -o -a}} for only things with activity, and accumulative)
:: In a lot of cases it's mainly logging (and things like dhcpcd saving its lease). Neither of which are necessary for function

:: {{inlinecode|lsof | grep REG | grep 'w  '}} may help figure out which files may be involved


* use [[strictatime]] or [[noatime]] everywhere
: ...but [[strictatime]] is the modern default anyway, so this should not make much difference

* (re)mounting all SD partitions (well, mainly the root filesystem) read-only
: That solves mostly problems caused by bad writes, because there are none. 
: however, this takes some extra care for things that ''do'' need to write
:: one case I ran into is /etc/resolv.conf

* put volatile things that you don't care about keeping in tmpfs. Consider:
:: /var/log/ (note you lose the ability to read them after crashes - but may well be worth it)
:: /tmp (if actively used)
:: /var/run (and may well be a symlink to /run, and may already be tmpfs)

: an easy way is to add fstab entries like (vary size according to use)
 none  /var/log    tmpfs  size=10M,noatime 0 0
: You may wish to configure your logging to go to some non-raspberry on your LAN instead of flash - you won't throw away as much debugging potential
* configure to fsck at every boot - could help
* disable swap {{comment|(may not matter if your use has very small memory footprint)}}
 sudo dphys-swapfile swapoff
 sudo dphys-swapfile uninstall
 sudo update-rc.d dphys-swapfile remove


Overclocking too much can probably also cause issues, though you'll probably notice crashes first...



btrfs as root fs
https://www.raspberrypi.org/forums/viewtopic.php?f=29&t=104108

-->

===HATs===

'''HAT''' (Hardware Attached on Top) are are 65x56mm boards with a 2x20-pin header, following a spec[https://github.com/raspberrypi/hats] designed to make it standard-n-easy to connect hardware.

It has an autoconfiguration system based on an EEPROM, connected on the ID_SD (GPIO0) and ID_SC (GPIO1) pins ([https://github.com/raspberrypi/hats/blob/master/designguide.md more details in the specs]).


There are also HATs that don't even do the EEPROM stuff. (are these compliant?)


HATs are made for 40-pin-GPIO Pi variants, as of this writing A+, B+, 2, 3, 4, Zero.

Compliant HATs can often be made to work on 26-pin Pi variants, 
but won't configure automatically, because the EEPROM pins that assist that are among the 14 added pins.



Physically, if you want to use a HAT ''and'' access to the pins for other reasons, you'll probably want a female header with long pins.


HATs can, in general, ''not'' be stacked.

It was considered in the definitions, and can work in some specific cases, but it cannot be guaranteed, because pins could clash.

If there's no clash, or the HAT was designed to stack (e.g. with more of itself[https://learn.adafruit.com/adafruit-16-channel-pwm-servo-hat-for-raspberry-pi/stacking-hats]) it'll work.{{verify}}




====pHAT====

A '''pHAT''' (partial HAT) is an informal variant,
basically anything that doesn't meet the HAT specs physically or electrically.

Adafruit call them bonnets.

Also often means a smaller variant, sized like a Zero. 
It seems they typically tend not to have the EEPROM either.


Manual configuration / use, and many pHATs, can often me made to work - ''if'' all the pins they use are in the set of 26.



See also:
* https://www.raspberrypi.org/blog/introducing-raspberry-pi-hats/
* https://github.com/raspberrypi/hats


=====pHAT DAC notes=====

Seems to just use the 5V, ground and I2S pins (no EEPROM/I2C)

i.e.:
: Pin 2 (5V)
: Pin 12 (GPIO 18, I2S)
: Pin 35 (GPIO 19, I2S)
: Pin 39 (Ground)
: Pin 40 (GPIO 21, I2S)

http://forums.pimoroni.com/t/phat-dac-which-gpio-are-in-use/1388/9

https://pinout.xyz/pinout/phat_dac



https://learn.pimoroni.com/tutorial/phat/raspberry-pi-phat-dac-install

====uHAT====

Follows HAT standard (unlike pHAT), but have a smaller board.

<!--
===Windows 10 IoT notes===
{{stub}}

tl;dr: "Windows 10" here is used as a brand, and means little.

It doesn't indicate kernel, or OS, or the ability to run things you would expect to run on windows 10 {{comment|(which summarizes the bulk of what layman or programmer would expect that to mean)}}.


Notes:
* no windows desktop
: It ''will'' show a screen on HDMI, but does nothing more than tell you the IP address and list USB devices.

* It can '''never''' run most of your desktop apps - they're not compiled for this ARM processor
: The only reason Linux can run on ARM moderately easily is because of its open source nature, meaning it can be compiled for other platforms (...with some minor tweaks - and usually someone else has already done the fighting involved in that). With most windows apps the x86 binary is all you will ever have.

* Microsoft's hardware support for the raspberry is relatively poor

* no serial port access

* no shell


That said,
* You ''can'' develop/run GUI-less apps - basically use it as a souped up microcontroller

* you ''can'' develop graphical apps [https://en.wikipedia.org/wiki/Universal_Windows_Platform UWP] style


If that's what you wanted, and what you're comfortable with, great.
Arguably this makes it quite useful at fulfilling a single purpose, which is a good approach to IoT.


But if you're a maker, and/or want to squeeze the most out of the platform, and/or wanted to run existing supporting software on it, and/or wanted to plug things into it, and/or wanted to a desktop, or an existing app, then linux is often the better choice.
-->

===Unsorted===

LEDs, meaning and config: https://www.jeffgeerling.com/blogs/jeff-geerling/controlling-pwr-act-leds-raspberry-pi#:~:text=All%20Raspberry%20Pi%20models%20have,ACT%20(a%20green%20LED).



'''On 5V tolerance''' 

Basically, No.   The GPIO is all 3.3V and none of it is [[5V tolerant]].

The only exception seems to be MISO (Master In Slave Out){{verify}}

To connect 5V to Pi GPIO, the simplest solutions are probably voltage dividers, 
sometimes a regulator, sometimes an optocouple, 
or one of a few diode tricks - see [[Electronics_notes/Changing_voltage#DC_level_shifting]] (but I need to write a better summary).

If you're going to go the current limiting resistor way (which, note is not ideal for fast communication, but plenty for slowish actuating signals), note that [http://www.mosaic-industries.com/embedded-systems/microcontroller-projects/raspberry-pi/gpio-pin-electrical-specifications this] suggests you should stay under 0.5mA, so the resistor should be over 10kOhm

[https://raspberrypi.stackexchange.com/questions/31648/gpio-protection-diodes-maximum-input-current]

==Odroid==
<!--
https://en.wikipedia.org/wiki/ODROID

-->

==Beagle==


<!--
While the beagle''board'' is a fairly specific PC-like thing (not unlike a raspberry pi),
the beagle''bones'' are more varied in terms of IO and other capabilities, 
making them suited for more varied 

--> 


===BeagleBone===

<!--

Costs: Most somewhere between EUR/USD40 and 130

Much more minimal than the beagleboard
-->

===Beagleboard===
{{stub}}

Wants 5V, consumes less than 2W.

Basic resources:
* 600MHz ARM processor
* 256MB Flash
* 256MB RAM
* GPU
* DSP chip


IO:
* USB socket for communication with host, and &lt;500mA of power from it
* SD reader (MMC+/SD/SDIO)
* Sound (3.5mm input and output)
* S-Video / Composite video
* DVI-D (0n HDMI connector)
* USB 2 host, two ports
* JTAG header
* RS232 header
* (The CPU can speak I2C, SPI) {{verify}}

Costs EUR/USD~150


See also:
* http://beagleboard.org/

==Plug computers==
{{old}}
===Sheevaplug, GuruPlug, Plug Computer 3.0===
(from [http://www.marvell.com Marvell])

====Sheevaplug (basic version)====
{{stub}}
From the outside, this looks mostly like a networked USB port.

Has:
* Low power ARM(-compatible) CPU, ~1GHz, draws only a few watts of power
* Gigabit Ethernet
* 512MB SDRAM
* 512MB Flash
* USB2 host
* USB socket with USB-to-serial connected to RS232 terminal, and the [[Electronics_notes/IO_and_wired_communication#JTAG|JTAG]] bus
* SD interface

Can run a few *nixes (ARM builds; there are some pre-made).

Commercial derivatives seem to include network file sharing, network backup, VoIP, and such.

USD/EUR ~100, depending on variant

====Sheevaplug+ (a.k.a. eSata Sheeva)====
{{stub}}

Like the basic Sheevaplug, but adds an eSATA port

====Guru Plug (a.k.a. Sheevaplug2)====

=====Guru Plug Standard=====
{{stub}}
* One Gigabit Ethernet port
* Two USB ports

* Wifi
* Bluetooth

* U-SNAP (Utility Smart Network Access Port) [http://www.usnap.org/]


=====Guru Plug Server Plus=====
{{stub}}

Much the same setup, but with:
* Two Gigabit Ethernet ports instead of one
* Two USB ports

* Micro SD
* eSATA plug

* Wifi
* Bluetooth
* U-SNAP [http://www.usnap.org/technical.aspx]

=====GuruPlug Display=====
{{stub}}

Like Server Plus, but 
* 3 USB2 ports
* either a HDMI Port OR a Touch Panel Display


====Plug Computer 3.0====
{{stub}}


====PogoPlug====
{{stub}}

PogoPlug is a Sheevaplug derivative.


Comes with OS / firmware and PC-side software to go along. This This setup is for cloud-style, remote access, social-site sharing, with files tied to people and accounts. It can take files from USB (automounting and understanding FAT32, NTFS, HFS+, ext2, ext3), and has a decent interface. 

That default setup does NOT do NAS in the sense of sharing files or media on a LAN with something like SMB/CIFS (a.k.a. windows file sharing), NFS, FTP, HTTP, DAAP, or such. The PC-side client makes files appear as if on a (new) local drive, which in itself is pretty handy - but only allows sharing with people with the same client ''and'' pogoplug accounts.


This all isn't a huge limitation. For one, you can enable ssh and install Samba on the existing setup within five minutes.

Tinkerers will like that it's an open-enough platform. You can install PlugApps (previously OpenPogo), which turns it into a generic linux server (but beware that not all hardware is necessarily supported, and driver stuff can be a pain).




Hardware:
* PogoPlug V1
** Seems to be very much like Sheevaplug hardware (slightly less memory, no SD card, no JTAG){{verify}}
** 1.2GHz ARM (most/all seem to be a licensed ARMv5 SoC)
** Discontinued{{verify}}

* PogoPlug V2 
** the fancier design, specifically the '''pink''' one {{verify}}
** 1.2GHz ARM
** 4 USB ports
** 256MB RAM
** 128MB Flash
** gigE networking

* PogoPlug Biz (mostly) seems to be the V2 hardware {{verify}}
** ...with some added services
** the fancier design, specifically the '''black and white''' one {{verify}}
** 1GHz ARM {{verify}}

* PogoPlug Pro (a.k.a. V3?)
** the fancier design, specifically the '''black''' one {{verify}}
** ''Not'' Sheeva-based
** armv6tel CPU (dual core CPU clocked to 700MHz) {{verify}}
** 128MB of RAM, 128MB of flash
** PCIE slot has 801.11 b/g/n WiFi  (Pogoplug Video has some video transcoder hardware instead?{{verify}}) (later versions don't have PCIE?{{verify}})
** http://plugapps.com/index.php5/Hardware:_Pogoplug_Pro

<!--
V2 and Pro have internal SATA slot, but no sata power, so arguably you could buy an SATA-to-eSATA connector to expose this.

){{verify}}
-->

See also:
* http://www.pogoplug.com/home-en-whats-pogoplug-product-comparison.html
* http://plugapps.com/index.php5/Portal:Hardware


=====PlugApps notes=====
{{stub}}

<!--
Some things you might like to do after installation
* http://plugapps.com/index.php5/FAQ:_Post-Install
* http://plugapps.com/index.php5/Template:First_reboot


The package manager is pacman. For reference: http://plugapps.com/index.php5/Guide:Package_Management

Manual service start/stop: look in /etc/rc.d/









On booting and kernel updates:

You may have multiple kernel images installed. To see what they are:
 file /boot/uImage*

How to use a kernel depends on how you have installed, and what path you want U-Boot to take.


For example, U-boot will look on disks, and it helps to have the first partition labeled 'rootfs'
 tune2fs -L "rootfs" /dev/sda1


======U-boot=====

UBIT is the '''U'''-'''B'''oot '''I'''nstall '''T'''oolkit

U-Boot seems to try quite a few things.

It will check for the presence of a kernel (/boot/uImage) and ramdisk (uInitrd) 
in NAND, USB and SATA (first partition if that is ext2 or FAT).



It also networks in the process. 
* (apparently) You can listen to it while booting. See [http://plugapps.com/index.php5/Monitoring_UBIT_boot_using_netcat]
* It has a boot delay in which you can interrupt remotely


Add some aliases to your ethernet cards (note: make it close enough so that routing won't fail)
 sudo ifconfig eth0:0 10.10.10.5
 sudo ifconfig eth0:1 10.10.10.4
 sudo ifconfig eth0:2 10.10.10.2
Listen to
 nc -lu 10.10.10.5 -p 6666
 nc -lu 10.10.10.4 -p 6666
 nc -lu 10.10.10.2 -p 6666

http://206.217.130.189/index.php5/UBIT

http://plugapps.com/index.php5/UBIT_U-Boot_parameters

======syslog-ng and/or udevd taking a lot of CPU======

udevd has a minimum requirement of the kernel it teams up with. 

There are some specific mismatches that will cause a fast-as-it-can stream of errors to the syslog. If the syslog is running, it's going to tie up its processing (even/especially if you filter it out ). If not, udevd is still going to use a few percent of CPU.

Right now (june 2011) there is a known problem with udev (not sure what) that causes this.


======changing kernels======


======front LED======

Green blinking: still in boot process
Orange:         error
Off:            

-->

==Chumby==

http://www.chumby.com/

==G20==
http://www.acmesystems.it/

=NSLU, NSLU2=
Popular for its price/ability balance, but has been discontinued. 

You probably want to look to the [[#Sheevaplug]] now.

See also:
* http://en.wikipedia.org/wiki/NSLU2
* http://www.nslu2-linux.org/

=Router hacking (mostly for Linksys WRT54 and similar)=
(See also [[Wireless notes]])


'''Alternative firmware, and interfaces for them'''

* Tomato
** for wireless routers (broadcom)
** Perhaps most user-friendly for common uses (though less wildly configurable than some others)
** http://www.polarcloud.com/tomato

* OpenWrt
** for wireless routers
** http://www.openwrt.org/

* X-Wrt 
** Extensions for OpenWrt
** http://www.x-wrt.org/

* Gargoyle
** Interface on OpenWRT (similar to X-Wrt in a number of ways)
** http://www.gargoyle-router.com/

* WIFI-BOX
** for wireless routers
** http://sourceforge.net/projects/wifi-box/

* DD-WRT
** for wireless routers
** [http://www.dd-wrt.com/wiki/index.php/Main_Page Wiki]
** [http://www.dd-wrt.com/ News]
** half commercial, some will be served well by the free version, some features only in paid version

* FreeWRT 
** (professional-market variant on OpenWRT)
** http://www.freewrt.org/

* HyperWRT
** http://en.wikipedia.org/wiki/HyperWRT


Router OS setups
* The Linux Router Project (LRP)
** Abandoned (see e.g. http://web.archive.org/web/20030624030005/http://www.linuxrouter.org/)
* LEAF Project (Linux Embedded Appliance Framework) (began as fork of LRP)
** http://leaf.sourceforge.net/

* Ipcop 
** http://ipcop.org/

* Zeroshell
** Meant to use most any computer (regular PC) as a router
** http://www.zeroshell.net/

* pfSense
** http://www.pfsense.com/

* m0n0wall
** http://m0n0.ch/wall/

* Floppy OSes (can be used for a HDD-less computer for firewall/NAT/other such purposes):
** floppyfw
*** http://www.zelow.no/floppyfw/index.html
** Fdgw (BSD)
*** http://www.fml.org/software/fdgw/


Unsorted:

* Vyatta
** http://www.vyatta.com/

* FREESCO
** http://www.freesco.org/

* CoovaAP 
** http://www.coova.org/

* SmoothWall
** http://www.smoothwall.net/
** http://www.smoothwall.org/


* LuCI
** http://luci.freifunk-halle.net/


==Some OpenWRT / X-WRT notes==
{{stub}}

===Notes on the ports, switch, VLAN, wireless, and such===
{{stub}}

Note that details also vary per product, so '''while much of the below may apply, chances are that not everything does''':


On many WRT54G and variants, you have
* five physical external ethernet ports (which are on the same internal switch)
* an internal link from the CPU to that switch
* an internal link from the CPU to the wireless device 

The five external ports are functionally split into one marked 'internet' (meant to go to your gateway/modem), and four internal/lan. The internet port may be physically spaced differently, but sits on the same internal switch, and seen that way by the CPU because it mainly sees the switch device, which it (usually) calls eth0. 

This is split by using [[VLAN]] ([[802.1q]]) tagging, which means that eth0 does not have an IP address, and routing rules involve the two vlan devices:
* '''eth0.0''' (VLAN 0, the four basic ports (and the internal one))
* '''eth0.1''' (VLAN 1, the internet port (and the internal one))

Note that since this is software-configured, this is just the default configuration you usually see. You can reconfigure this the way you want, e.g. merge all ports to use the thing as a plain switch, use multiple ports in a WAN-like way to use multiple broadband connections (probably each on their own VLAN) for redundancy, or whatnot.


The wireless device can also potentially get complicated, partially because of the way the hardware lets you emulate multiple wireless devices on a single physical device.
As such, you have a sort of dummy parent device, and one that you use in routing, often '''wlan0''', which is connected to what to the CPU is eth1 (or eth2, or sometimes ath0, depending on product).




Further interfaces you may see include:
* br-lan exists when you put a device in bridging mode.

* imq0, imq1: InterMediate Queueing devices, which assist traffic control [http://www.linuximq.net/]

* monitor interfaces




How you want to configure the device varies, and OpenWRT and X-WRT don't assume they know what you want, so don't assist you much either.

Networks can be defined in any way on the various interfaces -- but it seems fairly easy to cause OpenWRT/X-WRT to be confused in terms of the routing it should do (I've seen various confused routing tables, though that also had to do with what I was trying to make it do).


The default configuration seems to often be lan+wireless bridged as 192.168.1.1/24, wan as dhcp. {{verify}}

(wifi is often bridged to LAN)


<!--

Usually, you have a single network per interface:
* lan on eth0.0 (the lan ports) {{verify}}
* wan on eth0.1 (the internet port) {{verify}}



A basic one-AP system:
* wan port on DHCP (to the modem)
* LAN ports and wireless on bridge mode


Putting an interface in [[bridge]] mode will let it pass through traffic, and only makes sense when you run the same subnet on the respective ports.

It also makes a network you put on that device non-reachable. You may want to define another network to reach the device with. 

-->

===Notes on configuration notes===
{{stub}}
<!--
You can a reasonable amount of configuration from the web interface, but unsurprisingly it is a simplification of what is possible if you play with the underlying system.

Actually, some arguably not too unusual wishes are not so naturally configured via the web interface without having to dive into details.


The pretty default setups seems to be:
* The LAN ports + wireless bridged (that is, br0 being vlan0(eth0.0)+eth1{{verify}}), the interface configured as 192.168.1.1/24

* The WAN port (eth0.1) is often separate, by VLAN tagging, and confgured by DHCP. 

The WAN port is treated as a special case by some things. For example, QoS applies to traffic going out of the WAN port.


OpenWRT mostly assumes it's the only one around (or that WDS / client mode will serve other needs)

OpenWRT acts as a router, 
which can be troublesome when your modem already acts as a local router) 
It also means it provides DHCP (and, more importantly, won't let DHCP traffic through)


These and other facts can be unhandy in certain situations, such as 
* those where you want more than one AP (and don't want to use WDS), 
* have a modem that wants to do DHCP but you who wants OpenWRT to do, well, something interesting, 
* when you want to avoid extra subnets (e.g. a traffic limiting bridge).


The default mode for an AP is client, the other is Wireless Distribution System (WDS). WDS slaves an AP to another, which lets you do wireless range extension (at the cost of bandwidth{{verify}}) 
-->

===boot_wait and flashing===
{{stub}}

<tt>boot_wait</tt> makes it harder to brick your hardware, by always allowing you to flash it. 

Somewhat simplified, it refers to a setting that the bootloader listens to. When enabled, the bootloader will wait for three seconds before trying to load the kernel. Within those three seconds (or, if the kernel image doesn't pass CRC check, indefinitely), you can send a new firmware image in via <tt>tftp</tt> at <tt>192.168.1.1</tt> (what the bootloader listens to, regardless of later config{{verify}}).

The <tt>boot_wait</tt> period starts fairly quickly after the device powers up, so timing matters. I like atftp since you can give a single command, and it'll do a few attempts, meaning you can start it off, then plug in the router, and just wait and see whether this attempt worked or not.
Example command:
 atftp --trace --option "timeout 1" --option "mode octet" --put --local-file file.bin 192.168.1.1


<!--
You ''can'' disable boot_wait, but it's a nice idea that should you for some reason not be able to reach the device, that you can flash it and start anew. 

There are some situations that you can argue that cutting three seconds off boot time is a good thing, once you're set up and know you'll never change anything on the thing again (...since it's not too hard to mess with config to lock yourself out). 

-->

===Failsafe startup===
{{stub}}
In OpenWRT, if you misconfigure the device and can't reach it, you probably want to start it in failsafe mode. This will cause the device to use some default configuration, such as taking 192.168.1.1 to be easily reachable on the LAN ports.

(Note: If you have another device that uses 192.168.1.1, you should disconnect it or you may cause some OSes and switches to become very confused about where to switch, which can break your network temporarily)


To do a failsafe startup: Yank out the power cord, plug it back in, and wait for the DMZ light to come on (signals the start of boot {{verify}}) to press the reset button on the back a few times {{comment|(methods mention that the SES buttons should work too, but it didn't seem to for me. The amount of presses also seems to matter - not too often. My Random Superstition Procedure is three times in two seconds}}

Wait for the power/dmz to start blinking, and keep blinking (if it doesn't keep blinking, it's not in failsafe mode). 

If it does, you can now reach the device through passwordless telnet {{comment|(instead of the usual SSH)}} via one of the LAN ports, on 192.168.1.1.


What you want to do depends on what you did wrong. If you forgot your password, you want <tt>passwd</tt>. If you messed too much with all the settings, you can do a sort of factory-defaults thing using <tt>/bin/firstboot</tt>.



===See also / unsorted links===
http://sarwiki.informatik.hu-berlin.de/Programming_the_Linksys_WRT54GS_Wireless_Broadband_Router

http://x-wrt.org/
http://wiki.x-wrt.org/index.php/User_Manual
http://wiki.x-wrt.org/index.php/Main_Page
http://martybugs.net/wireless/openwrt/flash.cgi

https://dev.openwrt.org/
http://oldwiki.openwrt.org/

http://cyberforat.squat.net/openwrt/OpenWrt-HOWTO/x402.html

http://wiki.x-wrt.org/index.php/Multi-Route

https://forum.openwrt.org/viewtopic.php?id=13414


==Some Tomato notes==
{{stub}}

The WOL tool wants the MAC delimited using colons (as <tt>ether-wake</tt> does, and the value is fed straight to it)

=See also=
http://www.linuxdevices.com/


[[Category:Networking]]
[[Category:Hardware]]
[[Category:Electronics]]