Electronics project notes/Microcontroller and computer platforms

From Helpful
Jump to navigation Jump to search
This is for beginners and very much by a beginner / hobbyist.

It's intended to get an intuitive overview for hobbyist needs. It may get you started, but to be able to do anything remotely clever, follow a proper course or read a good book.

Some basics and reference: Volts, amps, energy, power · batteries · resistors · transistors · fuses · diodes · capacitors · inductors and transformers · ground

Slightly less basic: amplifier notes · varistors · changing voltage · baluns · frequency generation · Transmission lines · skin effect

And some more applied stuff:

IO: Input and output pins · wired local IO · wired local-ish IO · ·  Various wireless · 802.11 (WiFi) · cell phone

Sensors: General sensor notes, voltage and current sensing · Knobs and dials · Pressure sensing · Temperature sensing · humidity sensing · Light sensing · Movement sensing · Capacitive sensing · Touch screen notes

Actuators: General actuator notes, circuit protection · Motors and servos · Solenoids

Noise stuff: Stray signals and noise · sound-related noise names · electronic non-coupled noise names · electronic coupled noise · ground loop · strategies to avoid coupled noise · Sampling, reproduction, and transmission distortions

Audio notes: See avnotes


Platform specific

Arduino and AVR notes · (Ethernet)
Microcontroller and computer platforms ··· ESP series notes · STM32 series notes


Less sorted: Ground · device voltage and impedance (+ audio-specific) · electricity and humans · power supply considerations · Common terms, useful basics, soldering · landline phones · pulse modulation · signal reflection · Project boxes · resource metering · SDR · PLL · vacuum tubes · Multimeter notes Unsorted stuff

Some stuff I've messed with: Avrusb500v2 · GPS · Hilo GPRS · JY-MCU · DMX · Thermal printer ·

See also Category:Electronics.


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.


On speed

Tends to depend on what you want, but of the buyable-as-a-DIY-board

Teensy 4 are faster than most of the below, but also pricier
due to low price, ESP32's are some of the best speed per price
though its FPU isn't as good as some (e.g. STM32F4)
STM32F4 (black pills) coming in second
and STM32F1's (blue pills) and ESP8266 coming in third


Arduino Due, and Teensy 3, are presumably comparable to blue pills (verify)


On RAM

AVR and Arduino

The Arduino was classically based on Atmel AVR[1], 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 (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 (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 and sheevaplug come to mind.


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

ARM Cortex

For context

ARM is a company[2].


ARM is probably best known for its ARM architecture, which are a specific RISC-style CPU architecture that lends itself to a wide range of embedded processing, SoCs, and can be scaled up to serious calculation.

At the lower end ARM may be comparable to microcontrollers, but at the higher end they are considerably faster.


That does not actually manufacture any silicon, but ARM has has various design series that 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 recognize

  • Qualcomm's Snapdragon, e.g. used in phones and tablets.
  • Microsoft SQ1 or SQ2 (also Qualcomm), used in Surface


And yes, ARM has now also become accepted as a regular CPU -- 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 (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[3] 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.


In the embedded/DIY realm we are usually specifically interested in the simpler ARM Cortex family (and then often ARM Cortex-M), which are somewhat simpler and more independent, so so easier to handle in terms of external components, required code.

Cortex is split into three series:

Cortex-M made for low cost and low power
which makes it the most interesting for 'like microcontrollers but rather faster' uses
Cortex-A
which is fast enough for a basic OS (e.g. used in Raspberry Pi)
there's also 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

While 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


Teensy 3 is ARM Cortex-M

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

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 EUR20
4.1 adds an Ethernet IC, SD card socket, 5-pin USB header. ~EUR26

RAM:

  • 64KB for 3.2
  • 256KB for 3.5 and 3.6
  • 1024KB for 4.0, 4.1
note: 4.1 also has pads for PSRAM and/or more flash


Voltage:

Teensy 3 and 4 are 3.3v devices and not 5V tolerant.

Current draw:

Teensy 3 up to ~40mA?(verify)
Teensy 4 ~100mA at 600MHz


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)


Teensy 4 memory

The 1024 KByte is split into two parts: (see also the memory map on the product page)

  • RAM1
512KB
more tightly coupled. Code, static variables, and stack will be put here
  • RAM2
512KB
runs slower
used for buffers, larger arrays, and dynamic allocations (the heap)
when using DMA, you would want to put it here so DMA can run in parallel with the CPU.

Look at the manual, "4.12 SRAM accesses".


These are accessed differently, and the teensy libraries will use some of this, so don't count on getting all of it, or storing one big array in there.



On USB


Atmel SAM (Arduino Zero, Due; Seeed XIAO)

ARM Cortex-M


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


Boards interesting to DIYers include:

STM32

For more DIYer notes, see STM32 notes


STM32 are a licensed[4] bunch of series of Cortex-M based devices.


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)


A bunch of pre-made boards may be interesting to DIYers, including

RP2040 and Raspberry Pi Pico

This article/section is a stub — probably a pile of half-sorted notes and is probably a first version, is not well-checked, so may have incorrect bits. (Feel free to ignore, or tell me)


RP2040 is a dual-core Cortex M0+ at 125MHz


...and we will quickly talk about the Pi Pico or the later Pico W (Wi-Fi, Bluetooth) board that uses it, though there are others.

Comparisons it elicits

  • 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)


Specs

264kB SRAM QSPI dedicated to optional flash (which on most boards is 2 MB or more)

3.3V

3x 12 bit ADCs (technically four but )

2x UART 2x SPI 2x I2C and it seems most pins can do PWM

Programmable IO [7]

USB 1.1 controller (host and device)



For hobbyists,

  • Can be programmed with
    • MicroPython
    • barer C++
    • Arduino IDE
  • those IO specs are not that much better
though the PWM can be faster
and the PIO opens up some options
  • the higher speed and more SRAM are only interesting to some projects
  • the arduino board has 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




The PIO

...are essentially eight tiny programmable microprocessors

actually two blocks of four, which matters in that each block shares
instruction memory,
four read ports (which allows some parallel access without blocking)


They are very basic - only nine instructions, which limits your options to what we will basically just view as a state machine,

It frequently does little more than push data through with some well controlled timing. The main upside being that it does not occupy the CPU doing that (and it can usually avoid a lot of interrupts).

As such, it's like an excellent version of bit banging.



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

This article/section is a stub — probably a pile of half-sorted notes and is probably a first version, is not well-checked, so may have incorrect bits. (Feel free to ignore, or tell me)

PIC

This article/section is a stub — probably a pile of half-sorted notes and is probably a first version, is not well-checked, so may have incorrect bits. (Feel free to ignore, or tell me)

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

A few series of IC from Nordic, of which nRF24L01 is probably best known.


SoC with ARM Cortex CPUs,

the RF part speaks Bluetooth BLE, and also ANT, Thread, and Nordic's own ESB(verify)


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

Max32

Wiring

There is a Wiring board, made for the Wiring software.

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


(sold e.g. 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

This article/section is a stub — probably a pile of half-sorted notes and is probably a first version, is not well-checked, so may have incorrect bits. (Feel free to ignore, or tell me)

http://www.rev-ed.co.uk/picaxe/


(NetMedia) BasicX (BX)

Forebrain

(Leaflabs) Maple

PLCs

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[8] (x64)
  • AMD's newer low-power chips (Competitors to Atom, CULV, and such), including Huron (Neo) and Geneva (Yukon and Nile refer to portable platforms that include the Huron and Geneva, respectively)
  • VIA Nano[9] (x64)
  • ARM7[13] (ARM architecture[14] is often used for specific-purpose embedded applications, and can be very good for their price)
  • ARM9[15]
  • ARM11[16]
  • (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 Nintendo DS

NVidia Jetson

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 basically means linux. 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.


This initially excluded windows completely, but there is now an a Windows 10 for ARM (related to products like the Surface Pro X), and there is a project that helps install it on raspberry. Initially this meant only ARM apps (so basically none of yours), but now there is x86 and x64 emulation letting you run them, and it's not even that slow.

Driver support seems to also not be too bad.



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


See also:


Board variants

First-gen (A or B)

  • BCM2835 package, contains
    • CPU: a 700 MHz ARM11 (ARMv6 arch)
    • GPU: a 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 for the Arduinory crowd (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 LAN9514 to serve USB2+FE (see e.g. this diagram for a Pi3) (also why this 100Mbit ethernet had share bandwidth with USB)
  • Two USB ports (via on-board hub device)
  • 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 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 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)
(side note: this allows using a bluetooth keyboard/mouse instead of USB-OTG fiddling)


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 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 @ 500MHz
  • 1/2/4GB RAM (DDR2)
  • bluetooth 5
  • wifi (11ac, 2.4+5ghz)
  • adds USB3 (though with initial hiccups)
VL805 for 2xUSB2, 2xUSB3
  • ethernet port is gBit capable (switched to a 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[17])}}
There are easy workarounds, like running it via an adapter from a basic USB-A wallwart (given it's ~2A-capable)


Raspberry Pi Pico

  • basically a fast microcontroller
cheap
little fancy IO
sorta halfway between an arduino and raspberry - so not unlike a Teensy
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 has 2 MB of external flash

Notes on GPIO

Notes on 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


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




Saving power

This article/section is a stub — probably a pile of half-sorted notes and is probably a first version, is not well-checked, so may have incorrect bits. (Feel free to ignore, or tell me)


tl;dr:

  • Raspberries do not have anything like 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
(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 (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


LEDs


WiFi, BT


USB and ethernet



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 (which is why idling in that graph linked above differs less than peak use differs). (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, (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.



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[18].


The 3+/4 switched to a switching 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


Notes on video out

This article/section is a stub — probably a pile of half-sorted notes and is probably a first version, is not well-checked, so may have incorrect bits. (Feel free to ignore, or tell me)

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 /boot/config.txt (see pages like 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 hdmi_group and 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 hdmi_cvt, see e.g. [19]

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:


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:

OMX

Notes on the videocore

This article/section is a stub — probably a pile of half-sorted notes and is probably a first version, is not well-checked, so may have incorrect bits. (Feel free to ignore, or tell me)

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

This article/section is a stub — probably a pile of half-sorted notes and is probably a first version, is not well-checked, so may have incorrect bits. (Feel free to ignore, or tell me)


HATs

HAT (Hardware Attached on Top) are are 65x56mm boards with a 2x20-pin header, following a spec[20] 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 (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[21]) 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:


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.


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 this suggests you should stay under 0.5mA, so the resistor should be over 10kOhm

[22]

Beagle

BeagleBone

Beagleboard

This article/section is a stub — probably a pile of half-sorted notes and is probably a first version, is not well-checked, so may have incorrect bits. (Feel free to ignore, or tell me)

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


Plug computers

This hasn't been updated for a while, so could be outdated (particularly if it's about something that evolves constantly, such as software or research).

Sheevaplug, GuruPlug, Plug Computer 3.0

(from Marvell)

Sheevaplug (basic version)

This article/section is a stub — probably a pile of half-sorted notes and is probably a first version, is not well-checked, so may have incorrect bits. (Feel free to ignore, or tell me)

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

This article/section is a stub — probably a pile of half-sorted notes and is probably a first version, is not well-checked, so may have incorrect bits. (Feel free to ignore, or tell me)

Like the basic Sheevaplug, but adds an eSATA port

Guru Plug (a.k.a. Sheevaplug2)

Guru Plug Standard
This article/section is a stub — probably a pile of half-sorted notes and is probably a first version, is not well-checked, so may have incorrect bits. (Feel free to ignore, or tell me)
  • One Gigabit Ethernet port
  • Two USB ports
  • Wifi
  • Bluetooth
  • U-SNAP (Utility Smart Network Access Port) [23]


Guru Plug Server Plus
This article/section is a stub — probably a pile of half-sorted notes and is probably a first version, is not well-checked, so may have incorrect bits. (Feel free to ignore, or tell me)

Much the same setup, but with:

  • Two Gigabit Ethernet ports instead of one
  • Two USB ports
  • Micro SD
  • eSATA plug
  • Wifi
  • Bluetooth
  • U-SNAP [24]
GuruPlug Display
This article/section is a stub — probably a pile of half-sorted notes and is probably a first version, is not well-checked, so may have incorrect bits. (Feel free to ignore, or tell me)

Like Server Plus, but

  • 3 USB2 ports
  • either a HDMI Port OR a Touch Panel Display


Plug Computer 3.0

This article/section is a stub — probably a pile of half-sorted notes and is probably a first version, is not well-checked, so may have incorrect bits. (Feel free to ignore, or tell me)


PogoPlug

This article/section is a stub — probably a pile of half-sorted notes and is probably a first version, is not well-checked, so may have incorrect bits. (Feel free to ignore, or tell me)

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)


See also:


PlugApps notes
This article/section is a stub — probably a pile of half-sorted notes and is probably a first version, is not well-checked, so may have incorrect bits. (Feel free to ignore, or tell me)


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:

Router hacking (mostly for Linksys WRT54 and similar)

(See also Wireless notes)


Alternative firmware, and interfaces for them

  • Tomato
  • DD-WRT
    • for wireless routers
    • Wiki
    • News
    • half commercial, some will be served well by the free version, some features only in paid version


Router OS setups


Unsorted:



Some OpenWRT / X-WRT notes

This article/section is a stub — probably a pile of half-sorted notes and is probably a first version, is not well-checked, so may have incorrect bits. (Feel free to ignore, or tell me)

Notes on the ports, switch, VLAN, wireless, and such

This article/section is a stub — probably a pile of half-sorted notes and is probably a first version, is not well-checked, so may have incorrect bits. (Feel free to ignore, or tell me)

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 [25]
  • 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)


Notes on configuration notes

This article/section is a stub — probably a pile of half-sorted notes and is probably a first version, is not well-checked, so may have incorrect bits. (Feel free to ignore, or tell me)

boot_wait and flashing

This article/section is a stub — probably a pile of half-sorted notes and is probably a first version, is not well-checked, so may have incorrect bits. (Feel free to ignore, or tell me)

boot_wait 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 tftp at 192.168.1.1 (what the bootloader listens to, regardless of later config(verify)).

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


Failsafe startup

This article/section is a stub — probably a pile of half-sorted notes and is probably a first version, is not well-checked, so may have incorrect bits. (Feel free to ignore, or tell me)

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 (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 (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 passwd. If you messed too much with all the settings, you can do a sort of factory-defaults thing using /bin/firstboot.


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

This article/section is a stub — probably a pile of half-sorted notes and is probably a first version, is not well-checked, so may have incorrect bits. (Feel free to ignore, or tell me)

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

See also

http://www.linuxdevices.com/

Retrieved from "https://helpful.knobs-dials.com/index.php?title=Electronics_project_notes/Microcontroller_and_computer_platforms&oldid=92012"