Electronics project notes/Microcontroller and computer platforms

From Helpful
Jump to: navigation, search
This is for beginners and very much by a beginner. It's meant to try to cover hobbyist needs, and as a starting point to find out which may be the relevant details for you, not for definitive information.

Some basics and reference: Volts, amps, energy, power · Ground · batteries · resistors · changing voltage · transistors · fuses · diodes · varistors · capacitors · inductors · transformers · baluns · amplifier notes · frequency generation · skin effect


And some more applied stuff:

IO: IO and wired communication · localish communication · wireless (ISM RF, GSM, RFID, more) · 802.11 (WiFi) · 802.15 (including zigbee)


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

Some stuff I've messed with: Avrusb500v2 · GPS · Hilo GPRS · Bluetooth serial · JY-MCU · DMX · ESC/POS notes

Audio notes: basic audio hacks · microphones · amps and speakers · device voltage and impedance, audio and otherwise ·

Less sorted: Common terms, useful basics, soldering · Microcontroller and computer platforms · Arduino and AVR notes · ESP series notes · Electronics notes/Phase Locked Loop notes · mounts, chip carriers, packages, connectors · signal reflection · pulse modulation · electricity and humans · Unsorted stuff


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.



ESP series

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

Wireless boards with a programmable microcontroller. Sometimes used standalone, sometimes slaved to AVR-or-similar.


See ESP notes for more detailed practical use notes


ESP2866

ESP2866

  • Wifi 11b/g/n (no bluetooth)
  • ~160KB SRAM
  • often at 80 MHz (can be run faster)
  • 17 GPIO, 2 SPI, 2 I2S, 2 UART, 1 I2C, and a 10-bit ADC (pin overlap)
  • no hardware PWM


ESP8266 is a single SMD IC which you probably don't want to deal with yourself. You'ld typically buy on a small board, (see e.g. http://esp8266.net/ for details)

Initially form espressif, who had board variants called ESP-WROOM-something.

more common are the Ai-Thinker ones, often one of:

  • ESP-01 - exposes little useful IO, used mostly as a wifi slave board
  • ESP-05 - also exposes little IO. Allows better antenna than 01. Discontinued?(verify)
  • ESP-12 - exposes more things, making it more useful as a standalone uC, though physically it's not so easy to use
  • ESP-201 - easier to use on a breadboard
...and yeah, a bunch more of these exist.

...or one that is made for easier prototyping, such as the NodeMCU or WeMOS (which build on the ESP-12, and e.g. add USB-to-serial) or HUZZAH (seems to refer to at least two vairants, mostly be a breakout plus regulator).


You must yield time to the wifi code at least every few hundred ms(verify)

ESP8285

Compatible with ESP8266, has flash integrated, making it even smaller.

There seem to be some variant boards here too, at least:(verify)

ESP-M1 - antenna connector
ESP-M2 - onboard antenna
ESP-M3 - onboard antenna
ESP-01M

ESP32

See also:

see also

AVR and Arduino

The Arduino is mostly based on (8-bit) Atmel AVR[1] 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
(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 (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 (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.

Teensy

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


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

(MIT) HandyBoard

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

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

...and cricket?

http://www.handyboard.com/

(Parallax)

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

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

Basic Stamp

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

http://www.parallax.com/tabid/214/Default.aspx

Propeller

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

http://www.parallax.com/tabid/407/Default.aspx

Javelin Stamp

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

http://www.parallax.com/tabid/255/Default.aspx

BUG

http://www.buglabs.net/

(NetMedia) BasicX (BX)

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


[2]

(variation on Basic Stamp?)

PICAXE

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

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



See also

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[3] (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[4] (x64)
  • VIA C7[5] (x86)
  • VIA C3[6] (x86)
  • VIA Eden[7] (x86)
  • ARM7[8] (ARM architecture[9] is often used for specific-purpose embedded applications, and can be very good for their price)
  • ARM9[10]
  • ARM11[11]
  • (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

Raspberry Pi

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

Nice for hobby purposes, and plenty of people are happy with it as a XMBC-style media player.

The video playing ability is pretty impressive (to the point where anything done on the CPU feels relatively sluggish).


Could run anything you can compile for ARM. A few linux variants (e.g. Arch, Debian) are easy to adapt.

Initial boot is from SD card.


Hardware (mostly for model B, see below for the others):

  • BCM2835 package contains
    • CPU: a 700 MHz ARM11 (ARMv6 arch)
    • GPU: a Videocore 4
      • capable of H.264 at 40MBits/s (can do H.264 high profile, and can play 1080p -- but for some video may need the 256MB or 512MB RAM models of the board)
      • OpenGL ES (and openVG)
    • USB controller
    • 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 (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.
  • runs from 5V (taken from a micro-USB slot)
Model A specced for ~300mA (1.5W), Model B for ~700A (3.5W)
see e.g. [12] for power requirements for various specific boards


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

  • ARM Cortex-A7 (ARMv7 arch), 900MHz 4-core
~2x as fast as Pi1 B+ when using all CPU
  • 1GB RAM

Raspberry Pi 3

  • ARM Cortex-A53 (ARMv8 arch), 1200MHz 4-core
~60% faster than Pi 2 in best case(verify)
  • 1GB RAM
  • WiFi and Bluetooth

Raspberry Pi Zero

  • BCM2835 (like Pi 1, though 40% faster at 1000MHz)
  • 512MB RAM

Raspberry Pi Zero W

  • Zero, but with Wifi (11n) and bluetooth (4.1)


Various hardware can be added easily enough with USB dongles - WiFi, sound in, and such. ...assuming the driver is, or can be, compiled on ARM (and on the specific OS you're running).

See also:


Notes on video out

This article/section is a stub — probably a pile of half-sorted notes, is not well-checked so may have incorrect bits. (Feel free to ignore, fix, 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). 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. [13]

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:

On SD corruption

Pi zero

GPIO pins come unpopulated to stay slim.

USB host port is micro style so you need a USB OTG cable

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)

TV out is on two (unpopulated) pins

Pi zero W

Adds Wifi and bluetooth.

Note that you may wish to configure your image for your local wifi and to enable SSH, so that you can log in without a keyboard and monitor.

Note: Allows bluetooth mouse+keyboard.


Hats

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


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:


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

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

tl;dr:

  • Microsoft understands IoT as a souped-up-arduino, a target for Visual Studio developers to use
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
  • if you're a maker, and/or want to squeeze more out of the platform, linux is often objectively the better choice (e.g. Microsoft's hardware support here is pretty poor).


Notes:

  • no desktop
It will show a screen on HDMI, but does nothing more than tell you the IP address and list USB devices.
  • no ability to run most windows apps
You can develop/run UI-less apps, or UWP apps
  • no shell
  • no serial port access
  • It can run UWP apps.
It will never run your desktop apps. Which makes sense, they're not compiled for ARM.
The only reason Linux can do this moderately easily with 99% of things that run on it, is because source to most apps is open, meaning you can compile it for other platforms. With most windows apps that just won't happen.

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

Sheevaplug, GuruPlug, Plug Computer 3.0

(from Marvell)

Sheevaplug (basic version)

This article/section is a stub — probably a pile of half-sorted notes, is not well-checked so may have incorrect bits. (Feel free to ignore, fix, 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, is not well-checked so may have incorrect bits. (Feel free to ignore, fix, 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, is not well-checked so may have incorrect bits. (Feel free to ignore, fix, or tell me)
  • One Gigabit Ethernet port
  • Two USB ports
  • Wifi
  • Bluetooth
  • U-SNAP (Utility Smart Network Access Port) [15]


Guru Plug Server Plus
This article/section is a stub — probably a pile of half-sorted notes, is not well-checked so may have incorrect bits. (Feel free to ignore, fix, 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 [16]
GuruPlug Display
This article/section is a stub — probably a pile of half-sorted notes, is not well-checked so may have incorrect bits. (Feel free to ignore, fix, 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, is not well-checked so may have incorrect bits. (Feel free to ignore, fix, or tell me)


PogoPlug

This article/section is a stub — probably a pile of half-sorted notes, is not well-checked so may have incorrect bits. (Feel free to ignore, fix, 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
    • 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, is not well-checked so may have incorrect bits. (Feel free to ignore, fix, or tell me)


See also


Chumby

http://www.chumby.com/

G20

http://www.acmesystems.it/

Beagleboard

This article/section is a stub — probably a pile of half-sorted notes, is not well-checked so may have incorrect bits. (Feel free to ignore, fix, 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:

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
    • for wireless routers (broadcom)
    • Perhaps most user-friendly for common uses (though less wildly configurable than some others)
    • http://www.polarcloud.com/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, is not well-checked so may have incorrect bits. (Feel free to ignore, fix, 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, is not well-checked so may have incorrect bits. (Feel free to ignore, fix, 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 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 [17]
  • 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, is not well-checked so may have incorrect bits. (Feel free to ignore, fix, or tell me)

boot_wait and flashing

This article/section is a stub — probably a pile of half-sorted notes, is not well-checked so may have incorrect bits. (Feel free to ignore, fix, 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, is not well-checked so may have incorrect bits. (Feel free to ignore, fix, 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, is not well-checked so may have incorrect bits. (Feel free to ignore, fix, 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/