3
\$\begingroup\$

I am trying to enabling an embedded system built around Intel D1000 MCU. I am mainly from a software background and just starting to catch up with some hardware knowledge.

I am trying to build connection between an EEPROM and the MCU. My target is to enable this path:

  1. User burns the firmware into the EEPROM,
  2. Then MCU boots and runs some code to load the firmware into the SPI FLASH. .

And I see words like USB, UART, SPI. They all have Serial as part of their names. What's the difference? How to use/connect them?

(Excuse me if this is a naive question.)

\$\endgroup\$

closed as too broad by Matt Young, PeterJ, uint128_t, placeholder, Dmitry Grigoryev Jun 21 '16 at 6:35

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • \$\begingroup\$ The reason that all those different interface options are provided is because it depends on what you are connecting TO. You may find for your system design that some peripherals or sensors or interfaces want one or more of those interfaces. So you use whichever one will speak properly between the microcontroller and the peripheral. \$\endgroup\$ – Richard Crowley Jun 21 '16 at 1:50
  • 2
    \$\begingroup\$ Looks like your question is getting close votes. At first glance this question looks like one of those "what is a USB?" questions. There's an expectation that you know how to use an internet search to find your IC datasheet, as well as find standards documents for common interfaces like USB. The way I read it, you're asking for a brief compare/contrast overview, but will be responsible for drilling down to the implementation details. Suggest you edit to add your datasheet link. \$\endgroup\$ – MarkU Jun 21 '16 at 2:14
  • \$\begingroup\$ "My target is to enable this path: firmware -> EEPROM -> SPI FLASH -> MCU." That doesn't make sense: firmware is a concept, not a physical thing. EEPROM and FLASH don't communicate, at last one side must be intelligent. \$\endgroup\$ – Wouter van Ooijen Jun 21 '16 at 6:34
  • \$\begingroup\$ @WoutervanOoijen Sorry for missing some details. I want to burn the firmware into the EEPROM, and then MCU runs some code to load the firmware into the SPI FLASH. \$\endgroup\$ – smwikipedia Jun 21 '16 at 9:16
4
\$\begingroup\$

Those are three different types of serial interfaces.

SPI has a master clock and synchronous master-in-slave-out and master-out-slave-in data: a total of 3 wires plus ground/power and optional chip-select. Data is transferred simultaneously in and out, typically 8 bits at a time. Data can be MSB-first or LSB-first, depending on the connected SPI slave device. SPI is a somewhat loosely defined standard, originally came from the Motorola 68HC11 microcontroller I think. Effectively it's like a shift register.

UART is the peripheral that sends and received asynchronous serial. This protocol is often also called "RS-232(C)" or "EIA-232" or "TIA-232" or "COM port", or several other aliases. This is one of the oldest commonly used serial interface protocols, which is why it has so many names. Unlike SPI, RS232 UART uses a single wire to transmit both the clock and data. As such it depends on prearranged agreement between transmitter and receiver, as to the baud rate timing, the number of data bits, whether or not there will be a parity bit, and the minimum number of stop bits. Transmittting RS232 is straightforward, but receiving RS232 is tricky because of the need to recover the clock signal timing. This is best done in hardware.

USB is a more modern interface standard that is described in detail by the USB Implementors Forum documentation; I won't rehash the standard here. USB uses differential NRZ signalling and is thus much more complicated to describe at the wire level. Typically you use USB by adding handler code to a hardware USB Serial Interface Engine embedded within the microcontroller, or else use a PHY (physical interface) chip. You can't really bit-bang USB in software, as you could with RS232 or SPI.

You didn't ask about Ethernet, that's yet another serial interface and yet another complicated but well-documented protocol.

The important thing is that "serial" by itself is just a word, not a complete standard.

If you haven't already, you should grab the datasheets for your Intel D1000 MCU and start skimming the table of contents. There you will find sections that describe in great detail, exactly how each of the MCU's peripherals work.

\$\endgroup\$
2
\$\begingroup\$

I'm sure you already have some experience with USB already, they are all 'serial' as the data is sent one bit at a time down one lane (conga line, one lane highway etc.), as opposed to being split up across several lanes at once (parallel data).

SPI is good for embedded stuff as it is just a shift register and not much else, this allows for really fast comms (10Mbps is not uncommon even in tiny 8bit micros with and 50+ in a lot of 32bit chips). Data gets loaded into a shift register and sent out bit by bit on each clock cycle. At the other end the reverse action is performed. There are 4 pins: MISO (Master-In Slave-Out), MOSI (Master-Out Slave-In), CLK and CS (Chip Select), sometimes its the more ambiguous SDI (serial in), SDO (serial out), SCK (clock) and CE (chip enable) or some variation thereof. SPI is an internal interface, pretty much just used between chips on the same PCB. (I2C is another internal serial chip to chip interface that's closer to a low speed UART in terms of complexity and pin count)

UART is the technical name for the kind of serial port you might find on an old 90's PC (serial mouse, keyboard and modem), UART uses half the number of wires as SPI (TX and RX as opposed to data in, data out, clock and chip select). UART reduces the pin count but limits the maximum data rate as the receiver has to try and reverse engineer the data clock from the bitstream. UART requires more work to decode, but as pretty much every processor in existence has a dedicated UART transceiver, this is a non issue. UART is a good quick way to get an embedded micro to talk to a PC as UART to USB adapters are a dollar a dozen (assuming you haven't got any good ol' com ports on your computer). The only pins of any real interest are just the TX and RX along with a connection to the electrical ground. UART is more of an external interface, i.e. between whole systems or devices as opposed to individual chips.

Now USB is by a wide margin the fastest of the three (by an order of magnitude) but it is also far more complex, with handshaking, device detection, auto speed negotiation etc. it's not something that's particularly easy to do in an embedded system unless you can get some preconfigured USB software libraries for your chip. USB is a differential, bi-directional interface. There is two pins: D+ and D-, each is the mirror opposite of the other, this is done as it improves the signal integrity (among other things) allowing for up to 480Mbps down some pretty rubbish cabling provided that the D+ and D- wires are always right next to each other or in a twisted pair.

\$\endgroup\$

Not the answer you're looking for? Browse other questions tagged or ask your own question.