TM4C123GH6PM: Hi Bob Crosby,I don't know why I canot reply to your answer In problem that uart(1-7) cannot work, when I clicked your reply ,it always show blanks. ,so I can only ask a new question about that,really thanks.

There is a lot of information about communication peripherals and I doubt I can point you to a single good source of starting material. I suggest you do as you are doing. Pick a project, read about that peripheral, ask questions and play with code. UART and CAN are often used for communication between devices that can be separated by several meters. SPI and I2C are more traditionally used for communication between components on the same board or in the same system. There are many types of transceivers used with UARTs. RS232, RS422 and RS485 are some examples. Then there are protocol layers that are used on top of the hardware communications. Examples are ModBus or NEMA0183 to name just two. CAN is more complex, but has some distinct advantages. Here is a good paper on CAN. Here is a paper on basic I2C. There are lots of variations on the use of SPI. There are variations in phase, clock polarity and nomenclature. Here is a non-TI paper that gives some basic information. If those communications peripherals are not enough, we now have USB and Ethernet interfaces as well.

Greetings,

Is it not clear that Bob's post here - with such 'broad, linked & deep/detailed  content' - should be promoted to, 'Sticky Status?'    (i.e. live 'forever' atop the forum's heap (page 1) - rather than rotating off into forum 'oblivion!')   (i.e. to be found - only rarely - by true forum 'searchers.')

Beyond Bob's sage guidance - perhaps the practice at my small (growing) Tech Firm - proves useful.    (maybe)

Follows - advice from our intern & young engineering & programming staff:   (in answer to your request for 'learning')

• Just as Bob suggested - focus upon one or two 'communication peripherals (methods)' indeed proves best.    Doing too much - too soon - over-challenges most here - and is to be avoided.
• 'UART' is the overwhelming 'First Choice' of our staff.   This vendor's APIs well describe it - both short (MCU to MCU) and long range (via the addition of 'Line Drivers' (for RS232, RS422 or RS485) - are accommodated.   Further - the UART 'avoids' the addition of a 'Clock Channel' - as the UART's data clock is 'Re-Created at each end' automatically.   (And this most always 'works' so long as the UART Baud Rates are set equal - and the other protocol elements - are matched.  (i.e. # of bits, # of stop bits, and hardware (i.e. CTS/RTS) or software (i.e. X_On/X_Off) enforced 'data pauses.')   It must be stated that RS232 levels - if employed at 'one end' - must be employed at both (or all) ends.   RS232 signal levels far exceed the max. ratings of the MCU's UART port - and (likely) yield 'instant destruction.'   (when in doubt - use one of the proper line drivers - again at each end.)
• 'Second choice is 'SPI' - which is clocked (rather than Asynchronous) as used by the UART.    This is a short range bus - sometimes useful in 'board to board' applications - but (usually) only when the boards are in near proximity.    The 'gotcha' w/SPI is the 'Simultaneous Data Transmission & Reception'  - which occurs upon every SPI clock pulse.   (although usually upon different clock edges)   Our group recommends that one start w/an SPI-based EEProm - which serves as a superior means to 'Store Non-Volatile Data.'   (and minus the complexity & predictable 'wear' - resident w/in the MCU's (simulated) EEProm.)

Those two communication methods meet (both) your short & long range - as well as added (& non-voiatile) memory needs!   (i.e. 3 needs - satisfied via (just 2) communication types.)

Most always an O-Scope is 'necessary' to 'properly diagnose failure and/or error conditions.'   The transmitter, receiver or both may 'Fail to perform' - minus a scope - diagnosis is greatly delayed & complicated.