Difference between revisions of "Electronics notes/IO and wired communication"

From Helpful
Jump to: navigation, search
m (Serial ports)
m (Serial ports)
Line 509: Line 509:
 
'' 'Serial port' '' usually refers to a more specific series of interfaces, such as RS-232 or RS-485, standards that settle things like voltage, grounding, whether it's common mode / differential style signalling.
 
'' 'Serial port' '' usually refers to a more specific series of interfaces, such as RS-232 or RS-485, standards that settle things like voltage, grounding, whether it's common mode / differential style signalling.
  
...or things that share a lot of its conventions -- not least of which the on-wire ''framing'' of a series of bits.
+
...or things that share a lot of its conventions -- in particular the on-wire ''framing'' of a series of bits.
  
 
<!--
 
<!--

Revision as of 18:43, 23 September 2021

This is for beginners and very much by a beginner.

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

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


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

Microcontroller and computer platforms Arduino and AVR notes · ESP series notes · STM32 series notes · · · ·


Less sorted: device voltage and impedance, audio and otherwise · electricity and humans · power supply considerations · Common terms, useful basics, soldering · PLL · pulse modulation · signal reflection · resource metering · SDR · Project boxes · Unsorted stuff

See also Category:Electronics.

Simple wire/circuit protocols

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)

On voltage differences

See Electronics project notes/Unsorted#Dealing_with_voltage_differences


I2C and TWI (fairly common)

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)

I2C (Inter-Integrated Circuit), often written as I2C.

Two-wire a.k.a. TWI (Two Wire Interface) is almost exactly the same, but under a different name (apparently for reasons of potential legal bother?(verify))


Wires:

  • clock (SCL)
  • data (SDA)
  • a shared ground.

Allows various slaves on a bus. Slaves only talk to masters, not to other slaves.

Multiple masters on a bus is possible, since bus arbitration is part of the protocol definition.


Speed

Often one of:

  • 10 kbit/s low-speed mode
  • 100 kbit/s standard mode
  • 400 kbit/s Fast mode
  • 1 Mbit/s Fast mode plus (Fm+)
  • 3.4 Mbit/s High Speed mode

100KHz is fairly standard, 400kHz (and 10kHz?) are also commonly seen.


Range:

Bus capacitance should be less than 400pF for standard mode (Fm+ devices should be able to deal with 550 pF), and you should assume it's one to few meters at best(verify), a bit more for low-speed mode.


There are basic extender ICs, and some other tricks, but if you need distance you're better off with things designed for it.


Wiring details

SDA and SCL are open-drain (open-collector in TTL terms), which means they usually ought to be pulled up to Vcc, for when all devices are tristated so no device is pulling it down. It may work without this (probably more likely to work on short, few-cm connections, at low speeds), but is more error-prone, easily leading to confused masters(verify).

Devices rarely have pull-up resistors integrated, because you ought to do this only once per bus.

The best resistance value depends on the bus capacitance, and also on the bus voltage.

  • You probably want ≥1kΩ, as less may mean current becomes a problem
  • You may well want want < 10kΩ, as more might make communication fail at higher speeds (and may not comply to rise times even when it does work). (verify)
    • it seems 400kHz probably needs <5kΩ


Addressing:

Device addresses may be

  • fixed for a device - meaning you can't put two of the same thing on one bus
you could power all but one down (but that's awkward)
you could use a I2C multiplexer, like the TCA9548A, a I2C device that switches the bus based on what you write to it.
  • jumpered
  • programmable and forgotten at resets
  • programmable and stored in eeprom


Typical addressing is 7 bits, in the first 8 bits of a transfer (alongside 1 bit for direction).

Using 7-bit addresses lets you use up to 112 7-bit-address devices on a bus (not 128, there are some reserved values, including a bit pattern that signals use of 10-bit addresses (which is rarely used). There are other reasons you may sometimes be able to use fewer on a bus).

...so that first bytes will be (address<<1)|1 for reading and (address<<1) for writing. It seems most libraries abstract that away and take just the address (though some datasheet give address as this already-shifted thing, which can be confusing).



Exchange - lowish level


Problems

Hanging communication

  • More likely when there are no pullups on the bus
  • Does your IC have internal pullups? (they may be too strong(verify))
  • your library may not have timeouts


See also:

SPI (fairly common)

Serial Peripheral Interface (Bus)[1]


Range: Assume you should stay under 10 meters at most, depending somewhat on the speed.

Speed: Masters often support 125kHz .. 4MHz (often clock-divided steps, factors of two). (There are masters that support speeds up to something like 10, 12MHz, even 40MHz or 50MHz.)

Simpler slaves (often those that will never need to move much data) may have a maximum speed of 500kHz or less.


Wires:

  • SCLK, clock (output from the master)
  • MOSI, master out slave in (output from the master))
  • MISO, master in slave out (input from slave to master))
  • SS, slave select (output from the master)) (also known as CSB)
  • a shared ground


Notes:

  • MISO is optional for devices you only command and don't read out,
(MOSI is basically only optional for snoopers and logic analysers)
  • There is also a three-wire mode, which lets you puts MOSI and MISO on a single wire.


Features, in comparison to others:

  • Potentially faster than I2C, SMBus (depending on master, slave capabilities)
  • only one master on a bus
  • as many slaves as you can connect, but needs an extra wire for each (though you can daisy chain, use address lines, or such)
  • don't need pre-set address (can matter for usability)
  • Full duplex communication (most others aren't, though you often do not need or use this)
  • more wires than most others
  • lower power than various others


See also:


Variations - Dual, quad, queues, etc.
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)

Microwire (uWire)

A predecessor (and subset) of SPI
Half duplex
tend to have a slower maximum speed than SPI often does.
http://en.wikipedia.org/wiki/Microwire


Dual SPI (a.k.a. DIO(verify))

  • uses the same wiring as SPI (basic SPI wires can still speak plain SPI)
  • but MOSI and MISO can be used bidirectionally, and specific commands will do so,
allowing responses (and sometimes requests) to use both lines
https://en.wikipedia.org/wiki/Serial_Peripheral_Interface#Dual_SPI

Quad SPI (a.k.a. QIO(verify)) uses four data lintes

DIO idea of abusing MOSI and MISO (and this can still speak plain SPI)
but adding two further (transfer-only) data lines
https://en.wikipedia.org/wiki/Serial_Peripheral_Interface#Quad_SPI

In other words, backwards compatible SPI controllers, but when you know you're talking to a device that supports this, you can can transfer 2 or 4 bits per clock rather than 1.

These are seen around ROMs, Flash, SPI SRAM, and microprocessors designed to use them.

There even seems to be an octal SPI


QPI, a.k.a. SQI, seems(verify) a different expansion with 4 bidirectional data lines.

https://en.wikipedia.org/wiki/Serial_Peripheral_Interface#QPI/SQI


SPIFI (SPI Flash Interface) seems almost but not quite the same thing as quad SPI(verify)

possibly just a standard around quad?(verify)



There are some devices that do double data rate SPI.


FlexSPI seems to often imply a SPI host that

supports multiple configured devides
single/dual/quad/octal transfers
microcontroller support that can involve DMA transfers, possibly memory mapped accesses cached in the CPU
Used for SPI flash.


QSPI can refer to queued SPI or to quad SPI.(verify)

Queued SPI controllers that have a small data buffer, and frequently DMA, so that you don't have to spend much CPU time communication with your own SPI peripheral.

[2]


MibSPI (a TI term?), Multi-Buffer SPI, seems to be a similar idea but more of a shift register setup?

http://www.ti.com/lit/ug/spnu217b/spnu217b.pdf

https://electronics.stackexchange.com/questions/206328/what-is-the-difference-between-mibspi-and-spi



SMBus

'System Management Bus'

A two-wire bus derived from I2C (but not necessarily compatible unless made to be(verify)).

Wire speed: 10 kHz to 100 kHz

See also:


PMBus

Variant of SMBus targeted at power supplies, adding a bunch of domain-specific commands.

Wire speed: up to 400 kHz


1-wire

A master/slave bus, shared so can have multiple devices on it.

The one-wire refers to the data wire being bidirectional and not needing clock - but you'll still also need ground.


And sometimes also power, but low-current-devices (like iButtons and some sensors) can charge enough energy from the data line that they don't need that.


Seen in various sensors, and and e.g. iButtons.


Each 1-wire device has a unique ID, as parts of 64-bit ROM:

  • an 8-bit family code
  • a 48-bit serial number
  • an 8-bit CRC

The simplest iButtons have nothing more than this (e.g. used for simple key systems). Other devices have more to say.



See also:

ModBus

Others

ZacWire

One wire (aside from power)
https://www.microchip.com/forums/m489186.aspx


UNI/O

http://en.wikipedia.org/wiki/UNI/O

Vehicle buses

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)

These are often serial interfaces, with more robustness provisions, e.g. having specs or protocol deal with more noise, data collisons, a few meters of wiring, and sometimes things like priorities.

There are many of these (and occasional use of more generic things like I2C and SPI), and many are an extra layer on top of something relatively simple.


A few names pop up more often, say,

  • In boats you have RS422 as per NMEA0183, which became a sort standard in that many devices adhered to it


  • In cars you now regularly see CAN[3].
...though CAN was targeted for automotive use, but it turned out to be a robust and flexible shared (multi-master) bus and found somewhat wider adoption.
  • LIN is an alternative to CAN, often seen as a supplement
it's lower speed, but also lower cost to implement
so can make more sense for (clusters of) small devices


See also:


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

Serial interface, designed as a vehicle bus, with a bunch of robustness features.

Most variants can take ~30 or ~100 nodes.


Note that maximum speed is limited by cable length.

Within most cars and trucks this should not be an issue at least up to 1MBit, even FD's 12Mbit is quoted to work up to 10m.


Protocol

standard CAN (2.0A)
extended CAN (2.0B)

The main difference is that standard/A has 11-bits identifiers, extended/B lets you use 29-bits identifiers (11+18).

The extension was defined so that both can coexist on the same network.


Physical

HS-CAN (CAN's typical physical layer?)

2-wire, ~3.5V differential
terminated bus (120 ohm resistors on at each end of the network)
priorities, collison arbitration
40 Kbit/s to 1 Mbit/s
ISO 11898-2

CAN-FD - a higher speed variant, (FD being Flexible Data-rate) (verify)

up to around 12MBps
https://en.wikipedia.org/wiki/CAN_FD
ISO 11898-2:2015

FT-CAN (Fault Tolerant CAN), a.k.a. LS-CAN (Low Speed CAN)

40 Kbit/s to 125 Kbits/s
each device has its own termination; different connectors
ISO 11898-3


More specific: J1939 came from agriculture, marine, truck & bus

largely an extension of CAN, largely compatible (but has a bunch of parts, and a bunch of footnotes to go along)
A mild variation in wiring for robustness (SAE J1939-11 and 15) (verify)
also relates to the 2.0B variant (verify)

SWC - Single Wire Channel CAN.

~40 Kbit/s
SAE J2411
though people may opt for LIN instead, as it's cheaper to implement


Also related:

  • "ISOBUS", ISO 11783, mainly in agriculture, think tractors
based from J1939 (verify)
https://en.wikipedia.org/wiki/ISO_11783
  • ISO 11992 - similar to J1939. Not sure it's actually used (verify)


  • TI adds the terms MCAN and DCAN, where D seems to mean double-clocked [5]





UNSORTED

https://en.wikipedia.org/wiki/CAN_bus
https://www.computer-solutions.co.uk/info/Embedded_tutorials/can_tutorial.htm
LIN
Unsorted

Serial ports

Serial communication in the wider sense of 'one thing after another' is very common, because, well, that's the simplest thing to do with just one or two wires.

In that wide sense, it includes all of the things mentioned above, and much more.

(Arguably including things like QAM as well, which sends one symbol at a time, which just happens to present multiple bits)


'Serial port' usually refers to a more specific series of interfaces, such as RS-232 or RS-485, standards that settle things like voltage, grounding, whether it's common mode / differential style signalling.

...or things that share a lot of its conventions -- in particular the on-wire framing of a series of bits.


Terminology and pins

UART versus USART

UART = Universal Asynchronous Receiver/Transmitter

USART = Universal Synchronous/Asynchronous Receiver/Transmitter


USART adds the ability to run in synchronous mode. This means we send a clock alongside the data, so that the receiver does not need to know the baud rate ahead of time. This is also better behaved at higher speeds, but only really for short connections, often on the same board.





Common variants

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)


Most common serial ports seem to be:

RS-232, (a.k.a. EIA RS-232, EIA 232, and TIA 232)

  • (probably the most common variant because of desktop PCs)
  • defines voltage levels, signaling rate, timing, slew-rate, short-circuit behavior, pluggable connectors and pin identification, and some more
  • single-ended communication
  • speed and range: usually at most a few hundred kbps at short range (in theory up to a few MBps), aa few dozen kbps at a dozen meters or so(verify)
  • one-to-one (1 driver, 1 receiver)
  • full duplex (separate line for send and receive)
  • ITU-T V.24 is most related, others (like ITU-T V.28) can also be relevant.
  • http://en.wikipedia.org/wiki/RS-232


RS-485

  • probably the most common variant after RS-232
  • differential communication
  • one pair of wires can do half duplex (seems more common), two pairs can do full duplex
  • speed and range: <10MBps at a few meters, <100kb/s at ~1km
  • up to 32 drivers/receivers on a single bus
    • though not arbitrarily, and with limitations on range (verify)
    • only one driver active at a time. Protocols are often written to avoid collisions, and some setups detect them by checking what's on the bus while you're sending.(verify)
  • http://en.wikipedia.org/wiki/RS-485


RS-422

  • differential communication
  • speed and range: <10MBps at a few meters, <100kb/s at ~1km
  • full duplex - RX pair, TX pair.
sometimes also a CTS pair and RTS pair(verify)


Yes, RS422 and RS485 are similar in most ways.

There are cases where you can substitute line drivers from one and the other, but this comes with a few footnotes.

(See e.g. renesas AN1989 for a more differences at electrical level)


There's a bunch of other RS-othernumbers


Notes:

  • The names are seen as RS-something, EIA-something, TIA-something, and sometimes ANSI-something,
  • ...and some with a similar-enough (or equivalent) ITU-T standard. Note that this and related ground is covered by ITU-T V series (ports, lots of acoustic modem stuff, and such).


  • There are further related standards in the series, but most of them are not so interesting now.






On voltage levels

The RS-232 standard mentions

use +15V and -15V to represent boolean levels
be robust to +25V..-25V
still work with signals weakened to +3V..-3V.


Computers regularly used +12V and -12V, because computer power supplies usually provide +12 anyway (and would just need a tiny -12V added) those and this is well within spec.

So you should suspect particularly DB-25 or DE-9 motherboard serial ports to have these voltage levels.


This matters because more recent serial ports may be using different voltage levels.

Usually TTL levels: 0V and 5V.

Devices with such as microcontrollers, PCBs with serial headers, hand-held devices, phones, and such may have 0 and 5V, or 0 and 3.3V. (3.3V may (or may not!) be robust to 0..5V communication depending on design)

USB-to-serial adapters frequently choose to just use the 5V that USB itself provides.

Relatively few are designed to provide real RS-232 voltages (the DC-DC voltage conversion is about a buck worth of components, so price isn't necessarily a good indicator).


As such, your working assumption should be that none of this is compatible with RS-232 until you've checked that it is.

If you connect the two together, it may work, but will likely fry the lower-voltage device within days at most.

In some cases it will communicate, or manage only in one direction which with many protocols amounts to not at all. This in part because according to spec, RS-232 should consider -3V..3V as a transition range where the values is undefined.


You can make the two talk to each other with some level shifting.

Level shifting can be done in various ways, is probably easiest via specific-purpose ICs, such as the MAX232, MAX211, and others in the MAX220..MAX249 series, MAX3232, and similar products from other companies. There are quite a few options, many of which are cheap (and a few fancier ones that are not).


MAX232 and similar
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)

A converter between oldschool RS-232 voltage levels (-15V and +15V) to recently typical unipolar levels (5V TTL), so that you can interface oldschool serial ports to microcontrollers and such.


Powered from 5V, translated IO at 5V. Has a charge pump to generate the larger voltages (only as much current as is necessary, order of magnitude 10mA(verify), so rarely useful for other purposes)


Has two lines in one direction, two lines in the other. Usually one pair is used for TX/RX, the other pair often unused, or used for flow control, e.g. CTS/RTS-style.

Further components you'll need:

  • Two external capacitors to support the the voltage pump.
    • specced for at least 16V. Capacitance depends on variant, e.g. 1µF for MAX232, 0.1µF for some others
  • capacitors(verify) on VS+ (to Vcc) and VS- (to Gnd) (for stability? required or not?)
  • bypass capacitor on Vcc can't hurt (1uF?)


Pin-compatible: MAX232, ICL232, ST232, ADM232, HIN232, and probably others.

There are variants, e.g.

  • Some are 3.3V instead of 5V (e.g. MAX-3232, RS-2323)
  • some have the capacitors built in (but can be more expensive than adding separate capacitors)
  • Some have more transmit and receive ports (e.g. MAX3241, MAX3237)
  • some are power-saving variants


See also:

Some more comparison between RS-232, RS-422, RS-485

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)

Converters between most of these serial variants exist, and also to USB and other buses.

Conversion between the RS variants usually just deals with the electronics (like voltage differences) and is otherwise transparent, in that it adds no data buffering and should not noticeably affect timing.


Differential signaling uses two wires in a way that makes them much less susceptible to noise (noise that is consistent on both lines is electrically subtracted, not perfectly, but it works well), which means you can transmit further, with fewer errors, and/or faster (speed capabilities mostly matter on lines more than a few meters long. On short-enough wires everything can be fast).


When you interconnect more than two devices, it is often handy to do so with a single bus, regardless of whether it's a one-to-many, or an (often half-duplex) anyone-can-speak setup.

Details related to termination can vary.



When you convert, you do often inherit some conventions.

RS-232 stuff is typically a single-device query-response where parties can send at any time whatsoever. The fact that RS-485 can have many devices on the same bus means there is often some mechanism to deal cleanly, e.g. have identifiers they can be queried by, both to tell devices apart, and having only one speak via some easy convention (e.g. an initial "are you here, x?" scan of all addresses, then querying all known devices).

You may need a RTS-to-speak setup, or the converter may detect when you're talking. Depending on details, the RS232 device may effectively listen to itself, so you may need to ignore that, and/or write your RS-232 code in a half-duplex sort of way. (verify)


On Ground

Even for differential signalling you may want a ground line as well. You don't need it for the signal - that's fine because the voltage difference between the two data wires is what matters, and well controlled.

However, you also need to consider whether the voltage difference between the devices is different. The spec basically says their difference should stay within -7V and +12V.

If it's more, communication will stop working, and and it may damage the electronics. (though frankly, if it's large enough for the latter, you probably need to look at why in more detail)


Adding a ground line effectively limits the amount of (common mode) voltage that the input terminals will see.

You're fine without ground if both ends will never vary much. In some cases, you can design it that way. In some cases it's implicit, e.g. when all parts are powered from the same thing. (You may even avoid some ground loop problems if you don't connect ground.(verify))


See also:

Flow control

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)

When the receiving side cannot guarantee it consumes the received data fast enough, flow control is preferable, arguably necessary.

The problem comes when the receiving end cannot guarantee (or just practically doesn't) that incoming data is moved out of the receiver's small buffer fast enough. Once that hardware buffer is full, there is no choice but to throw away data.


Strictly speaking a guarantee to do this is hard, particularly between devices of different speeds and designs, and for high speed transfers.

Still, a number of applications don't continuously stream data, so may rarely or just not see trouble.


(RS232) Hardware flow control refers to using the CTS/RTS lines to signal readiness to receive.

Advantages:

  • efficient mechanism
  • out of band; no implications to the data stream itself

Disadvantages:

  • You need extra wires. Only practical in short-length connections
  • impossible or just very impractical for transmission in other media (e.g. POTS modems, wireless tranmission of serial signals)


Software flow control refers to using some codes within the data stream to stop and restart flow. These are usually named XON and XOFF:

  • XOFF, 19 decimal, 0x13 hex, and also known as DC3 (also Ctrl-S in some terminals; see Shells_and_terminals#Shell_flow_control)
  • XON, 17 decimal 0x11 hex, and also known as DC1 (also Ctrl-Q in some terminals)

These ask the other end to stop sending, and start sending again.

Advantages:

  • You don't need extra wires

Disadvantages:

  • You can't send data that contains these vales. You need to encode/escape around that, using some extra logic on both ends, using some protocol that both ends agree on.
  • noisy lines may mean the characters are missed


See also:


Notes on baud rate, bandwidth, and latency

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)

USB to serial notes

Common ICs, particularly around the DIY scene (Arduino, ESP8266, STM32) and chinese shave-off-some-cents clones of various things


  • FT232 (from FTDI)
e.g. on earlier arduinos


  • CP2101
exposes a few more pins(verify)


  • PL2303
has a history of knockoffs, and Prolific's Windows drivers changed over time to effectively block these fakes
you can tell if Device Manager shows something like "this is not prolific pl2303 please contact your supplier"
meaning that if you're a DIYer and still want to do something with them, older drivers will work.


  • CH340G / CH340
Driver may or nay not be installed automatically on all OSes (particularly apples seem to have issues), so if not detected you need to find the driver and possibly some instructions.
Datasheet: https://cdn.sparkfun.com/datasheets/Dev/Arduino/Other/CH340DS1.PDF

Parallel ports

Microcontroller programming and testing

ISP (In-System Programming)

Refers (somewhat generally) to the ability to program a chip while it is in its circuit, (rather than having to be programmed beforehand, or taken out to program).

At a lower level, ISP usually means some serial protocol, and that the chip can itself generate the programming voltage it needs (from its typical supply voltage).


So it often means

  • can update firmware
  • you don't need an expensive hardware programmer (nice for the DIY crowd)
  • less time consuming testing/development cycle

See also JTAG, which can regularly also do firmware updates, lus a few debug-like things.

http://en.wikipedia.org/wiki/In-System_Programming

ICSP (In Circuit Serial Programming)

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)

Used by PIC microcontrollers, AVRs, and Parallax Propellers.


Has a line for programming voltage (voltage varies; may be between 5V and 13.5V), so not quite the same as #ISP_.28In-System_Programming.29, though similar enough in a "you connect it and it programs" way.


Typically (actively) uses five pins.

Associated with various different plugs, typically 0.1" pitch pin headers, though smaller (and larger) variants exist.

Note that you can't go by plug size alone - some have multiple possible pinouts. To avoid damage and confusion, always check the pinout.


See also:


JTAG

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:


HIL

https://en.wikipedia.org/wiki/Hardware-in-the-loop_simulation

SWD

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)

SWD (Serial Wire Debug) is an ARM-specific thing.

Its basic function is comparable to JTAG, but over a somewhat simpler physical interface:

  • SWCLK
  • SWDIO
  • Gnd

...and in practice optionally Vcc when the ARM is not otherwise powered.

Being defined by and for just ARM, it has a specific feature set (cf. JTAG where most interesting features are added later and not necessarily portable), e.g. CPU level debugging (e.g. fetch register, break, run), sometimes integrated into your PC-side development environment.


Note that ARM devices often provide SWJ-DP, which speaks both SWD and JTAG(verify)



See also:

SWIM

SWIM is a single wire protocol that seems to be for the STM8 only.


ST-LINKv2 notes

LVP (Low Voltage Programming)

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)

LVP seems primarily mentioned in the context of PIC18* microcontrollers, as a variant to the apparently more standard Vpp-of-up-to-13.5V way of programming (in this context meaning ICSP?(verify)).


See also

Network over power (Homeplug, other names)

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)

(not to be confused with Power over Ethernet (PoE))


Often marketed as a cable reducer, a way to connect rooms or floors without having to pull wires and drill holes. The systems should probably only be used when wiring is prohibitively hard, as cables are simpler, can be faster / upgraded more easily, and there are potentially fewer problems.

You could also use it to run a longish extension cord (say, to a shed) and avoid running (and protecting) a long network cord beside it.


The devices usually come in pairs.

The medium is shared (most underlying technologies do frequency multiplexing) so more devices mean less speed, and there's a maximum to the amount of distinct channels/devices.

Speed will also degrade with medium noise.

Once it works it can work well, but it may be a little unpredictable to set up, and don't count on always getting the advertised speed.


Requirements

You need to be on the same local (phase of your) transformer for operation at all. Most houses are on a single transformer (in most of the world; in the US houses may be wired in two different phases in different legs of their house).

It's likely that you'll see some connectivity, but in multiple-leg buildings (including larger buildings such as apartment complexes, stores, and such) you should probably not do any larger investments without doing some tests first. In some cases you're better off spending a few more hours adding and beautifying/hiding a wired connection.

You may run into other problems, such as getting little or no communication through power conditioning devices (may be central in a large building), even a power strip that does radio-frequency or general electromagnetic interference filtering (often extra features on those fancy semi-nonsense surge protection strips), or interference from certain devices (like, apparently, some light dimmers).


On speed

Long and/or noisy connections are likely to fall back to lower speeds. Speeds vary with design; there is no single standard, although there seem to be relatively few underlying chips.

Theoretically there seems little reason you can't the quoted maximum speed, but you can get lower speeds because of on aspects of your electrical wiring that you can often neither predict or change.

Your house and the locations you plug these devices into may work out as better or worse than average, but in general you probably shouldn't expect more than 80 megabits, and in some bad cases you may get little over ~5-10mbit/s.

The devices are marketed at speeds like 14MBps, 85MBps, 200Mbps, even gigabit, but note that these are often maximum/ideal figures (as with wireless networking), not fixed figures (as with most wired networking). (Also, a few figures are marketing lies. There have apparently been lawsuits over this)


Quotes on range are a little harder to find. Quotes on what speed you get at different distances are even rarer (how does speed degrade?(verify)).

Apparently relatively ideal conditions allows for on the order of 200 meters, sometimes more, sometimes less. Note that this is meters of wire, which is more than distance between rooms. Still, this is enough to cover many houses, make floor-to-floor connections, and (and technically more than the length of a single twisted-pair (Cat5e/Cat6) wire.



Unsorted