View source for Electronics project notes/Microcontroller and computer platforms

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


-->




==AVR and Arduino==


The Arduino is mostly based on (8-bit) Atmel AVR[http://www.atmel.com/products/avr/] 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 even a decade ago there 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. (PIC too, actually, it was just a different community)


You get
* programmability without a costly programmer
: {{comment|(for most boards you only need a USB cable, and in some minimal boards you need a USB-to-serial device)}}
* 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 around the heart of the board that is the AVR (which by itself costs only ~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.

==PIC==
{{stub}}

Comparable with AVR in many ways, sometimes the better option for any given project.

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

The main thing that it doesn't have is ready-made boards.

==ARM Cortex(-M)==

'''For context'''

ARM, the company[https://en.wikipedia.org/wiki/Arm_Holdings] mainly designs a specific RISC-style architecture[[https://en.wikipedia.org/wiki/ARM_architecture]], for various markets, and includes various distinct microarchitectures[https://en.wikipedia.org/wiki/List_of_ARM_microarchitectures].

It's a popular enough design series that various companies create licensed[[https://en.wikipedia.org/wiki/Arm_Holdings#Licensees]] derivations. One result you may recognize is Quallcom's Snapdragon e.g. used in phones.


In the embedded/DIY realm we are mostly interested in ARM Cortex family, itself split into three series: 
: [https://en.wikipedia.org/wiki/ARM_Cortex-M Cortex-M] made for low cost and low power, 
: [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]])



Us hobbyists are mainly interested in '''Cortex-M''', being a step up in power from AVR/PIC style microcontrollers, but still pretty cheap.


===Atmel SAM===


For example:
* [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://en.wikipedia.org/wiki/Atmel_ARM-based_processors


===STM32===

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

Many individual models over various series, but ''broadly'' with speeds somewhere between 20 and 200MHz, and with SRAM and flash up to a few hundred KB.

Regularly run at 3.3V (down to 2V)
: A subset of pins are 5V tolerant (when you disable pullup/pulldown), others are not.


Specific IO features vary (with specific chip in a series, and then whether the board exposes them).

Many have (12-bit{{verify}}) ADCs (some multiple)

Some have (12-bit) DACs (max speed in the megasample range, varying with series)

Have a bunch of timers, some usable as PWM{{verify}}.
Others have more dedicated PWM (e.g. with dead time / phase control generator){{verify}}.

http://www.emcu.eu/stm32-basic-timer/


e.g.:
* {{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]




The features depend in part on the series (of which there are a dozen) and family, but also on the choice of '''package''' (of which there are often several).

For example, the STM32F103C8T6 (48-pin) and STM32F103RCT6 (64-pin) are both STM32F103, but the latter exposes a bunch more things. {{comment|{For example, the former exposes one SPI port, the latter three (two of which can be switched to I2S) {{verify}} }}

The datasheets have tables that basically match this to the amount of pins of specific packages.

<!--
F1 series (launched 2007), Cortex-M3

F2 series (launched 2010), Cortex-M3

L1 series (launched 2010), Cortex-M3

F4 series (launched 2011), Cortex-M4F

F3 series (launched 2012), Cortex-M4F

F0 series (launched 2012), Cortex-M0

F7 series (launched 2014), Cortex-M7F (pin compatible with F4, faster)

L0 series (launched 2014), Cortex-M0+

L4 series (launched 2015), Cortex-M4F

H7 series (launched 2017), Cortex-M7F

L5 series (launched 2018), Cortex-M33F

G0 series (launched 2018), lower-power variants of L0 (Cortex-M0+)
-->



====Blue pill notes====
{{stub}}

Blue Pill boards are typically based on the STM32F103C8T6 (a Cortex-M3, STM32F1 series)


If USB doesn't work:
* R10 problem: R10 on the board is the USB's D+ line pullup, which should be 1.5k -- but is higher on many older 
: there's a hack in putting something in parallel on external pins (e.g. if the resistor is 10k, adding ~1.8k should work)

* Most STM32F103 boards do not come with a USB-capable firmware/bootloader{{verify}}
: you will need to flash one over serial
: Note that USB code takes ~20KB, so if you don't need it, you may want to skip that
:: (that said, most people don't need a huge amount of code, so USB is just nice to have)

  BOOT0 BOOT1  
    0     x    on-board flash (user-written firmware)
    1     0    system ROM (essentially programming mode)
    1     1    SRAM 

System ROM has some specific functions, see [https://www.st.com/content/ccc/resource/technical/document/application_note/b9/9b/16/3a/12/1e/40/0c/CD00167594.pdf/files/CD00167594.pdf/jcr:content/translations/en.CD00167594.pdf ST AN2606]. In fact, this is what we use when updating the user flash.

SRAM is mostly used for debugging without rewriting your flash - or in larger setups, sometimes by having one device control the boot of another. You'll probably never use this

...so to most of us, the upper jumper (BOOT0) means left=firmware and right=programming).


You can use SWD programmer/debugger if you have the hardware (see the pins on the edge), which is pretty simple/cheap hardware in itself (see e.g. ST-LINK/V2), is faster and requires no jumpering, and potentially allows embedded debugging.
But if you don't have one then a generic serial port takes just a few seconds more, so those are the typical instructions.

So to flash:
* connect:
** your serial Gnd to Gnd
** your serial TX to (STM32's RX1, board-labeled) A10
** your serial RX to (STM32's TX1, board-labeled) A9
** give the STM32 3.3V
::: the often-simpler option is to also plug in the board's USB (yes, the one that currently does not do anything)
::: if your usb-serial board outputs 3.3V on its Vcc (or can be jumpered to) connect it to 3.3V
::: if your usb-serial board outputs 5V on its Vcc, connect it to 5V
* Set BOOT0 to 1, BOOT1 to 0 (system ROM)
* press reset
* run the flasher
* Set BOOT0 to 0, BOOT1 to 0 (user flash)
* unplug (also for the implied reset)




'''Black pill (Blue Pill 2) notes'''

Black Pill boards are typically based on the STM32F401CCU6 or STM32F411CEU6 (a Cortex-M4F, STM32F4 series)

Compared to blue pill, these will have 
: higher clock speed
: 256 or 512KB flash
: 64 or 128KB SRAM
: USB-C port
: FPU
: a few more IO options (but how much is exposed)

They cost maybe twice as much, which is still not much

===Others===

e.g. 
* [https://www.pjrc.com/teensy/ Teensy 3] series boards (Cortex-M4F)  (NXP)

==ESP series==
{{stub}}

For details, look at [[Electronics project notes/ESP notes]]


For comparison with others here:

ESP8266
* Based on Xtensa LX106 microprocessor
: often at 80 MHz {{comment|(can be run faster at 160MHz though people report this breaks code that didn't expect that)}}
* Wifi 11b/g/n (no bluetooth), apparently people have got it to send on the order of ~10mbit/s
* ~160KB SRAM
* 17 GPIO, 2 SPI, 2 I2S, 2 UART, 1 I2C, and a 10-bit ADC (pin overlap)
* no hardware PWM



ESP8285 is compatible with ESP8266 but has the flash integrated rather than beside it



ESP32
* wifi + bluetooth
* often at 160MHz (can be run faster), ~20% used for wireless
* https://www.espressif.com/en/products/hardware/esp32/overview
* https://www.espressif.com/sites/default/files/documentation/esp32_technical_reference_manual_en.pdf
* ~500K SRAM
* more IO than a ESP8266: 36 GPIO, 4 SPI, 2 I2S, 2 UART, 2 I2C, and a 12-bit ADC, 2 8-bit DACs (note: pin overlap)
* Four timers

==Teensy==

Teensy 2 series are AVRs at 16MHz and are comparable to Arduino Mini/Nano, with different features;

Teensy 3 series are [[STM32]]:
: Teensy LC is an ARM Cortex-M0+ at 48MHz,    ~EUR13
: Teensy 3.0 is an ARM Cortex M4 48MHz,       ~EUR20
: Teensy 3.1 is an ARM  Cortex M4 72MHz,       ~EUR20
: Teensy 3.2 is an ARM Cortex-M4 at 72MHz,    ~EUR20
: Teensy 3.5 is an ARM Cortex-M4F at 120MHz,  ~EUR30
: Teensy 3.6 is an ARM Cortex-M4F at 180MHz,  ~EUR35

See 
: https://www.pjrc.com/teensy/
: https://www.pjrc.com/teensy/techspecs.html

Note that the 3+ are 3.3V devices (only some 5V tolerant)

==Wiring==
{{stub}}

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==
{{stub}}

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

...and cricket?

http://www.handyboard.com/
-->

==Parallax==
{{stub}}
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/

<!--
==(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?)
-->

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


<!--
==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
-->

==See also==
* http://fritzing.org/

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

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

Often not so hip on the sort of IO you want in projects, but if you want an interface, particularly if a palmtop has a touchscreen, 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))}}.
-->

==Raspberry Pi==

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


In an ARM rather than x86, though. Could run anything you can compile for ARM. 

Which means it easily runs linux, and 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. 

(ARM and drivers are also why they'll never run windows as you know it)


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.


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


Hardware ('''mostly for first-gen model B''', see below for the others):
* [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
* HDMI out
* audio out (3.5mm jack, also via HDMI)
* the 26-pin is for the Arduinory 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)
* 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 Zero'''
* BCM2835 (same as Pi 1, though clocked 40% faster)
* 512MB RAM
* smaller board, and GPIO pins come unpopulated to stay slim.
* USB host port is micro style so you need a {{imagesearch|USB OTG cable}}
* 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's still there
:: USB sound can be cheap, but not all are supported, and quality 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)
: (note this allows using a bluetooth keyboard/mouse)


'''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'''
* 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 4'''
* BCM2711, Cortex-A72 (ARMv8 arch) 1500MHz 4-core
: VideoCore 6 @ 500MHz
* 1/2/4GB RAM (DDR2)
* bluetooth 5
* wifi (11ac, 2.4+5ghz)
* ethernet port is gBit capable
* adds USB3 (though with initial hiccups)
* dual video output / 4K res now at 60p 
* reported issues:
:: cooling: at maximum cpu it runs hot enough to throttle
:: Powering from a proper USB-C power source wo (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/]), which can lead to a proper USB-C charger (sensibly) refusing to charge i.e. power it). There are easy workarounds, like running it via an adapter from a basic USB-A wallwart (given it's ~2A-capable)



===Notes on power===


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
: ...plus whatever you draw through USB (consider powered USB hubs)
: See the note above on (not) using a proper USB-C charger.


Note that Pi 3 and 4{{verify}} have a switch mode supply, that detects and reports low voltage (under ~4.7V),
making it easier to diagnose insufficient power supplies.


See also:
* https://raspberrypi.stackexchange.com/questions/26526/current-draw-for-2-0-models/40393#40393

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

The 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, 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

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

<!--
Three main problems:
* yanking power during a write (worse on SD/USB flash, where it's probably an erase-write cycle)
: possibly some journaling, copy-on-write filesystems deal better?
: run OS on hard drive, when at all reasonable

* crappy power supplies
: it has been argument that those with high amounts of noise can make it to IO lines - again mostly relevant to writes
: also, brownouts (as in, underpowered power supplies) are likely to have bad effects. The Pi would probably just reboot

* wearing out the SD card due to many writes


To improve both, consider:
* sometimes you can get away with (re)mounting readonly {{comment|(may need some more [[tmpfs]] to not break some things)}}.
: That solves any problems caused by bad writes, because there are none. 
* use noatime everywhere {{comment|(tends to be default for / filesystem, which is where it matters)}}

* put volatile things 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)
: check what programs write elsewhere (e.g. use iotop?)
: 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


People argue that overclocking too much can do it too, but probably you'll notice kernel 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 65x56 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]).



HATs are made for 40-pin-GPIO Pi variants, currently A+, B+, 2, Zero.


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


HATs can, in general, ''not'' be stacked. It was considered, and can work in specific cases,
but there are various cases where it couldn't be made to work. In particular HATS using the same pins.
This is fine for e.g. I2C (with some address tweaking), but not for most other pins. 

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


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

Usually it means a smaller variant for the Zero. 
It seems they typically tend not to have the EEPROM either.


Compliant HATs won't work on 26-pin Pis as automtically configured things, in that the EEPROM pins aren't in that set (they're among the 14 added ones).
Manual configuration / use, and many pHATs, can work fine on 26-pin ''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


===Windows 10 IoT notes===
{{stub}}

Notes:
* no serial port access

* It will never run your desktop apps - they're not compiled for ARM.
: The only reason Linux can do this moderately easily is because source to most apps is open, meaning it can be compiled for other platforms (...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.

* no shell

* Microsoft's hardware support here is pretty poor

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

* You can develop/run GUI-less apps

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


So Microsoft understands it as a souped-up-arduino at best.
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 more out of the platform, and/or wanted to use an existing graphical interface (X windows), linux is often objectively the better choice.

==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 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:            

-->

====See also====
* http://en.wikipedia.org/wiki/SheevaPlug
** http://en.wikipedia.org/wiki/SheevaPlug#Commercial_products for various variants


* http://en.wikipedia.org/wiki/GuruPlug
* http://www.plugcomputer.org/plugwiki/index.php/GuruPlug
* http://www.marvell.com/platforms/plug_computer/

==Chumby==

http://www.chumby.com/

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

==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/

=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 VLAN stuff is software controlled, 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]]