Electronics notes/IO and wired communication

From Helpful
(Redirected from CH340)
Jump to navigation Jump to search

⚠ This is for beginners and very much by a beginner / hobbyist

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

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

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

And some more applied stuff:

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

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

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

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

Audio and video notes: See avnotes

Platform specific

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

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

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

See also Category:Electronics.

Simple wire/circuit protocols

This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

On voltage differences

See Electronics project notes/Unsorted#Dealing_with_voltage_differences

I2C and TWI (fairly common)

This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

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


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


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.


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Ω


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


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.


  • 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


  • 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 — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

Microwire (uWire)

A predecessor (and subset) of SPI
Half duplex
tend to have a slower maximum speed than SPI often does.

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

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

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.


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.

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



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


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

Wire speed: up to 400 kHz

See also:


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:


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

This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

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)



See #CAN notes below



Vehicle buses

This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

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:

CAN notes
This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

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.


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


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



Local Interconnect Network



Unsorted (vehicle buses)



One wire (aside from power)



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

This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

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


  • 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


  • 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


  • 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
This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

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 — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

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 — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

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.


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


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


  • You don't need extra wires


  • 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 — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

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

This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.
The pink plug is the DB-25F parallel port
Male 36-pin Centronics connector (a micro ribbon connector), seen e.g. on parallel printer cables

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.

The Centronics interface was later standardized by IEEE (see IEEE 1284) in the 1990s, 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 can be considered an improved version of EPP, using DMA (up to ~2.5MB/s, the limit of DMA 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


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


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.


ICSP (In Circuit Serial Programming)

This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

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:


This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

See also:




This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

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

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

  • 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 is a single wire protocol that seems to be for the STM8 only.


ST-LINKv2 notes

This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

ST-LINKs seem to speak

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.

digital isolation between PC and the target
presents USB storage and programs it int the target [6]
ST-LINK-v3 (a.k.a. STLINK-V3SET)
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)

This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

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 — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

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


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.


Bit banging