Electronics notes/IO and wired communication
Simple wire/circuit protocols
On voltage differences
See Electronics project notes/Unsorted#Dealing_with_voltage_differences
I2C and TWI (fairly common)
I2C (Inter-Integrated Circuit), often written as I2C, or sometimes IIC.
Two-wire/TwoWire 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 typical, 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(verify)), 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 (which seem to mostly be buffers), and some other tricks, but if you need distance you're better off with an alternative designed for distance.
Wiring details
SDA and SCL are open-drain (open-collector in TTL terms), which means they ought to be pulled up to Vcc, for the times that 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, and with single devices), 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, so the first byte 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).
There are fewer than 128 addresses, because there are resereved addresses (0..7 and 0.x78..0x7f).
Some values are used to signal 10-bit addresses, but those are rarely used.
Also, some ranges seem to have specific uses.
There is apparently an officially registered list devices, but the official one doesn't seem to be released.
- 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:
- http://en.wikipedia.org/wiki/I2C
- http://en.wikipedia.org/wiki/Two-wire_Serial_Interface#Derivative_technologies
- http://www.best-microcontroller-projects.com/i2c-tutorial.html
I3C
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:
- http://en.wikipedia.org/wiki/Serial_Peripheral_Interface_Bus
- http://www.freescale.com/files/microcontrollers/doc/ref_manual/S12SPIV3.pdf
Variations - Dual, quad, queues, etc.
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
SPI (from context of the next few: classical / regular / single)
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 lines
- DIO idea of abusing MOSI and MISO (and this can still speak plain SPI)
- and adding two further data-transfer-only lines
- https://en.wikipedia.org/wiki/Serial_Peripheral_Interface#Quad_SPI
There even seems to be an octal SPI(verify) but it seems rare at best.
DIO and QSPI controllers will also speak basic SPI,
- 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.
- are e.g. seen around ROMs, Flash, SPI SRAM, some USB-SPI bridges, and microprocessors designed to use them.
UNSORTED
There are some devices that do double data rate SPI.
SPIFI (SPI Flash Interface) seems almost but not quite the same thing as quad SPI(verify)
QPI, a.k.a. SQI, seems(verify) a different expansion with 4 bidirectional data lines.
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.
- Both quad SPI and Queued SPI use QSPI as abbreviation. Not confusing at all. Check which one you're looking at.
FlexSPI (an NXP term?) seems to often imply a SPI host that
- supports multiple configured devices
- single/dual/quad/octal transfers
- microcontroller support that can involve DMA transfers, possibly memory mapped accesses cached in the CPU
- Used for SPI flash.
- https://mcuxpresso.nxp.com/api_doc/dev/1315/group__flexspi.html
MibSPI (a TI term?), Multi-Buffer SPI, seems to be a similar idea but more of a shift register setup?
- https://electronics.stackexchange.com/questions/206328/what-is-the-difference-between-mibspi-and-spi
- http://www.ti.com/lit/ug/spnu217b/spnu217b.pdf
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
See also:
1-wire
A shared bus, so can have multiple devices on it, but there is only one master/initiator.
The one-wire refers to the data wire being bidirectional (half duplex) and not needing clock - but you'll still also need ground.
And sometimes also power, but many low-current-devices (like iButtons and some sensors) can charge enough energy from the data line.
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:
Fieldbuses
Fieldbus refers to basic network used for real-time and distributed control, particularly in industry.
As a specific name it (today) probably refers to IEC 61784 / 61158. (It had some precursors).
As a general name it gets used for used varied protocols, varied topologies,
so in some cases it means "Anything that is practical enough to place between a bunch of devices."
In most cases it implies a protocol that lets devices talk in whole messages (logical/transport sort of layer),
and doesn't have to think about bits.
As such, in that wider sense it can refers more to protocols than to hardware.
Consider e.g. Modbus over RS-485 can be considered a fieldbus, RS485 in itself not so much.
For more history and examples, see https://en.wikipedia.org/wiki/Fieldbus
ModBus
ModBus originated as a way to program PLCs, but has become a de facto standard for sensors, industrial devices.
It uses some interesting terms in its definitions, in part because of these origins, and in part just because it originated fifty years ago.
Variants include
- MODBUS RTU 'remote terminal unit'
- i.e. modbus over serial (in sensors often something like RS485 because that's smart in industrial settings)
- Modbus ASCII
- a more text-like variant, in part to allow use over older serial, including
- Modbus over TCP
- in fact two variants, that seem to vary mostly in a checksum(verify)
- Modbus over UDP
- seems to be relatively rare?(verify)
https://en.wikipedia.org/wiki/Modbus
CAN
See #CAN notes below
EtherCAT
https://en.wikipedia.org/wiki/EtherCAT
Vehicle buses
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.
They pretty much qualify to be named a fieldbus. But more specific.
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 was a de facto standard for a long time, that various kinds of devices adhered to
- In cars you now regularly see CAN[2].
- ...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:
- http://en.wikipedia.org/wiki/Vehicle_bus
- http://en.wikipedia.org/wiki/Vehicle_bus#Protocols.2C_Physical_Media_and_Connectors
CAN notes
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 also lets you use 29-bits identifiers (11+18). (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
- 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)
- MilCAN [3]
- TI adds the terms MCAN and DCAN, where D seems to mean double-clocked [4]
- Bosch adds the terms M_CAN, C_CAN, and apparently A_CAN and D_CAN (verify) (are these just specific controllers?)
- TWAI (Two-Wire Automotive Interface) seems to be Espressif's name for "speaks CAN".
- Whether that is because they don't pay Bosch for the name, or because they speak a subset so couldn't call it CAN, I don't know.[5](verify)
UNSORTED
LIN
Local Interconnect Network
https://en.wikipedia.org/wiki/Local_Interconnect_Network
https://www.csselectronics.com/screen/page/lin-bus-protocol-intro-basics/language/en
Unsorted (vehicle buses)
Others
ZacWire
- One wire (aside from power)
- https://www.microchip.com/forums/m489186.aspx
UNI/O
Current-loop serial ports
Voltage-level serial ports
(a.k.a. every serial port since roughly the eighties)
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 serial port variants
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
- 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)
- multi-drop: 1 driver, up to 10 receivers
- Compatible: ITU-T V.11 (verify)
- http://en.wikipedia.org/wiki/RS-422
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 framing
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
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
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
Flow control lets the receiving side say "that's too fast, give me a second."
When the receiving side cannot guarantee it consumes the received data fast enough,
flow control is preferable, arguably necessary.
At higher level this is about the speed of consuming that data,
at low level it's about a usually-tiny hardware buffer that the receiver directly writes into, and our higher-level software only occasionally reads out.
Once that hardware buffer is full, and things are still coming in, there is no choice but to throw away data - because at low level, what alternative do you see?
Strictly speaking, a guarantee is hard anyway,
particularly between devices of different speeds and designs, and for high speed transfers.
There are various designs that happen to be fine, often because they don't continuously stream data.
For example, sending occasional status updates means that hardware buffer may (almost) always get
serviced before we send the next one.
when we do care about throughput without failure, we need flow control
(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:
- http://en.wikipedia.org/wiki/Software_flow_control
- http://en.wikipedia.org/wiki/Flow_control#Hardware_flow_control
Notes on baud rate, bandwidth, and latency
USB to serial notes
There are many, but between the DIY scene (Arduino, ESP8266, STM32) and chinese shave-off-some-cents clones of various things, you mostly see:
- FT232 (from FTDI)
- e.g. on earlier arduinos
- CP2101 (or CP210x indicating that it's a series also including CP2102, CP2103, CP2104, CP2105, and CP2108)
- 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.
- CH340 / CH340G
- Driver may or may 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.
- high bit rates not always stable?
- Datasheet: https://cdn.sparkfun.com/datasheets/Dev/Arduino/Other/CH340DS1.PDF
Implementation-wise, USB-to-serial can be a little interesting.
If you've seen acronyms like CDC and ACM scroll by, those originate from telephony standards, and are models fit for modems of the classical wired-phone sense. (e.g. ACM (Abstract Control Model) roughly means exposing a serial line that controls the modem (using specific commands), contrasted with DCM (Direct Line Control Model) where the USB host directly controls the modem)
In theory, ACM-style CDC is a good enough fit for serial ports. But it might be a little awkward for some hardware, and it's apparently also relevant that Windows XP implemented CDC somewhat poorly, which seems part of why it became regular for USB-serial devices to do their own thing instead(verify))
Both may be reasons that the FTDI/PL2303/SiLabs above tend to use the proprietary (0xef?) class, so are not driverless on the PC side.
That said, microcontrollers that implement serial over USB directly are more likely to much more likely choose CDC, because it would make them driverless(verify) and probably means less code(verify)
You might see this around Arduinos with AVR of the U2 / U4 variants (e.g. Leonardo, Pro Micro, Yun), ARM Cortex variants like the Arduino Zero and Due; STM32s, and more.
Parallel ports
Over time
There are various PC ports that use parallel communication, but the one most consistently referred to that way was the DB-25 connection on the PC side, that historically often adapted to a 36-pin Centronics plug on the other side, used for printers.
Developed by Centronics around since the late 1970s, this became a de facto standard probably via its adoption by e.g. IBM (who called it the 'IBM Printer Adapter') and IBM compatibles, in the early 1980s.
This interface was later standardized by IEEE in the 1990s (see IEEE 1284), which also included the faster EPP and ECP modes (~2MByte/s), which saw moderate use until USB replaced it in speed and convenience in the 2000s.
In this time, 'parallel port' (which in theory is a much wider concept) came to refer specifically to the PC side's DB-25 connectors with IEEE 1284 compliant controller behind it, because of its more generic use than Centronics and its device side originally imagined, particularly once the faster modes were standardized.
Such parallel ports were once widespread, a standard port on motherboards for years, as ubiquitous as the 9-pin serial port often next to it, and not immediately displaced by USB because parallel's fastest modes were faster than the first generation of USB; up to roughly 2005 devices were still produced with parallel interfaces (e.g. scanners, printers).
Speed: The Centronics/SPP ports was a basic interface with limited speed (and varied, due to typical protocols being acknowledged synchronous signaling(verify), not necessarily faster than 150kbit/s (frequently ≤50kbyte/s), though maybe 400kbyte/s in some implementations/combinations(verify).
EPP is quoted at 2MByte/s, ECP at 2.5MByte/s
IEEE 1284 ports have a number of modes:
- Compatibility mode / Centronics mode / Standard Parallel Port (SPP)
- almost purely the original Centronics design
- Unidirectional: data lines are host-to-device only (though bidirectional communication was possible at all by abusing the status lines - see the next item)
- speed could in theory be above 150kbytes/s, but as there are no buffers it will easily be less than that in practice.
- Nibble Mode / Bi-tronics mode
- Used the status lines to receive 4 bits of data at a time.
- This idea works on many pre-IEEE-1284 Centronics interfaces too.
- Byte Mode / "Bi-Directional"
- Half duplex
- bi-directional (can use all the data pins in both directions, easier than abusing the status lines)
- not supported by pre-IEEE-1284 intefaces
- Enhanced Parallel Port (EPP)
- Half duplex
- bi-directional (can use the data pins in both directions)
- Basically a hardware-supported variant of byte mode - considerably more bandwidth, with less CPU use
- Extended Capability Port (ECP)
- Half duplex
- bi-directional (can use the data pins in both directions)
- its own thing, but offloaded PC-side work to DMA, so often faster than EPP (up to ~2.5MB/s, roughly the limit of DMA transfers on the ISA bus(verify))
The SPP implementation distributes the 17 pins onto three adjacent IO addresses:
- Base - Data port
- The eight data pins
- Base+1 - Status port, a.k.a. control input
- five incoming pins: ACK, busy, paper end/out, select, error
- Base+2 - Control port, a.k.a. control output
- four outgoing pins: strobe, autofeed, init, select in
Note:
- Some lines use inverted logic
- In centronics mode, the base port is write-only, in byte mode it is read-write
- both the status and control port filled some more bits with byte mode
See also:
Some lower level details:
- https://web.archive.org/web/20120506095613/http://www.lvr.com/parport.htm
- https://web.archive.org/web/20071002143009/http://www.beyondlogic.org/spp/parallel.htm#1
- https://web.archive.org/web/20180129102307/http://www.citr.auckland.ac.nz/~james/parport.html
- https://web.archive.org/web/20091206043339/http://www.cse.shirazu.ac.ir/~zjahromi/parallel-port-interfacing.htm
USB
See USB notes
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)
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:
- http://en.wikipedia.org/wiki/In_Circuit_Serial_Programming_%28ICSP%29
- http://www.tango-lasergame.be/cf/milestag/mmt/4.html
JTAG
See also:
HIL
https://en.wikipedia.org/wiki/Hardware-in-the-loop_simulation
SWD
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 Vcc when the ARM is not otherwise powered.
Being defined by and for only ARM, it has a specific feature set (cf. JTAG where most of the actually interesting features were 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
ST-LINKs seem to speak
- SWIM for STM8
- and JTAG and SWD for STM32
ST-LINK devices expose the logic lines for all three, plus:
- 3.3V to power the IC
- 5V in case you need it
- RESET to make the process easier
Some ST-LINK devices also provide digital isolation.
- ST-LINK
- obsolete
- ST-LINK/V2
- ST-LINK/V2 ISOL
- digital isolation between PC and the target
- ST-LINK/V2-1
- presents USB storage and programs it int the target [6]
- ST-LINK-v3 (a.k.a. STLINK-V3SET)
- STLINK-v3MINI
- STM32 only (not STM8 like most of this list)
The smaller USB dongles seem to all be clones, and there seem to be variant clones with differen pinouts.
These also seem to omit JTAG(verify) but see https://github.com/jeanthom/DirtyJTAG
LVP (Low Voltage Programming)
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)
(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.