Learn vocabulary for embedded communication protocols: SPI, I2C, UART, CAN bus, peripheral addressing, and bus collision detection.
0 / 18 completed
1 / 18
In SPI communication, what are MOSI and MISO?
SPI uses four lines: SCLK (clock), MOSI (master-to-peripheral data), MISO (peripheral-to-master data), and CS/SS (chip select). The full-duplex nature means data flows in both directions simultaneously, making SPI faster than I2C but requiring more pins.
2 / 18
What is the role of the SDA and SCL lines in I2C?
I2C uses just two wires: SDA for data and SCL for clock. Both are open-drain (open-collector), meaning any device on the bus can pull the line low. Pull-up resistors hold the lines high when idle. Multiple devices share the same two wires, addressed by unique 7-bit or 10-bit addresses.
3 / 18
What is 'baud rate' in UART communication?
Baud rate defines the speed of the UART link — common values are 9600, 115200, and 921600 baud. Unlike SPI and I2C, UART is asynchronous (no shared clock), so both ends must independently configure the same baud rate, data bits, parity, and stop bits.
4 / 18
What does 'the peripheral is not responding on I2C' typically indicate?
In I2C, every transaction begins with the master sending the peripheral's address. If no device ACKs, a logic analyser will show the address byte followed by a NACK (non-acknowledge). Systematic diagnosis: verify address (check datasheet for address pins), test pull-ups, confirm VCC to the peripheral, and check wiring continuity.
5 / 18
What is a 'bus collision' in embedded communication protocols?
On shared-bus protocols like I2C and CAN, collision/arbitration is built into the protocol. In CAN, nodes monitor the bus while transmitting — if a node detects its dominant bit has been overridden, it loses arbitration and backs off. I2C multi-master configurations similarly detect lost arbitration and retry. Detection and handling vocabulary is important in multi-master embedded designs.
6 / 18
Reviewer: 'I'm seeing some inconsistent reporting on the sensor data. The API response for device 72 shows a 'protocol_error' code with a status of 500, but the logging system is indicating a timeout. Can you check if the UART baud rate is correctly configured and verify the I2C communication isn't experiencing any bus contention?'
Which of the following best describes what the reviewer is likely referring to?
The reviewer's comment points to a discrepancy between the API response and the logging system. This strongly suggests a problem with the underlying communication protocol configuration. Specifically, an incorrect baud rate on the UART interface (which transmits data serially) or I2C bus contention (where multiple devices try to access the same bus simultaneously) can lead to corrupted data and timeouts, explaining both the API error code and the logging timeout. Option A is too broad; option B misattributes the issue to a network problem; option D incorrectly assumes an API endpoint error.
7 / 18
PR Description:
"Fix: Resolved intermittent data loss from sensor device 15. Investigated API response and logging discrepancies. Found UART baud rate mismatch between the gateway and the sensor."
This scenario highlights the importance of understanding communication protocols beyond just the high-level error codes. While the PR mentions resolving data loss, the core issue identified by the reviewer is a mismatch in baud rates between the gateway and the sensor device. This mismatch would directly lead to incorrect or corrupted data being transmitted, explaining both the API response code (protocol_error) and the timeout observed in the logging system. The other options represent misunderstandings – network glitches don't explain mismatched baud rates, and the logging system is unlikely to be solely responsible for misinterpreting a valid 500 status code.
8 / 18
Reviewer: 'I'm seeing some inconsistent reporting on the sensor data. The API response for device 72 shows a 'protocol_error' code with a status of 500, but the logging system is indicating a timeout. Can you check if the UART baud rate is correctly configured and verify the I2C communication isn't experiencing any bus contention?'
Which of the following best describes what the reviewer is likely referring to?
The reviewer's comment points to a discrepancy between the API response and the logging system. This strongly suggests a problem with the underlying communication protocol configuration. Specifically, an incorrect baud rate on the UART interface (which transmits data serially) or I2C bus contention (where multiple devices try to access the same bus simultaneously) can lead to corrupted data and timeouts, explaining both the API error code and the logging timeout. Option A is too broad; option B misattributes the issue to a network problem; option D incorrectly assumes an API endpoint error.
9 / 18
PR Description:
"Fix: Resolved intermittent data loss from sensor device 15. Investigated API response and logging discrepancies. Found UART baud rate mismatch between the gateway and the sensor."
This scenario highlights the importance of understanding communication protocols beyond just the high-level error codes. While the PR mentions resolving data loss, the core issue identified by the reviewer is a mismatch in baud rates between the gateway and the sensor device. This mismatch would directly lead to incorrect or corrupted data being transmitted, explaining both the API response code (protocol_error) and the timeout observed in the logging system. The other options represent misunderstandings – network glitches don't explain mismatched baud rates, and the logging system is unlikely to be solely responsible for misinterpreting a valid 500 status code.
10 / 18
Reviewer: 'I'm seeing some inconsistent reporting on the sensor data. The API response for device 72 shows a 'protocol_error' code with a status of 500, but the logging system is indicating a timeout. Can you check if the UART baud rate is correctly configured and verify the I2C communication isn't experiencing any bus contention?'
Which of the following best describes what the reviewer is likely referring to?
The reviewer's comment points to a discrepancy between the API response and the logging system. This strongly suggests a problem with the underlying communication protocol configuration. Specifically, an incorrect baud rate on the UART interface (which transmits data serially) or I2C bus contention (where multiple devices try to access the same bus simultaneously) can lead to corrupted data and timeouts, explaining both the API error code and the logging timeout. Option A is too broad; option B misattributes the issue to a network problem; option D incorrectly assumes an API endpoint error.
11 / 18
PR Description:
"Fix: Resolved intermittent data loss from sensor device 15. Investigated API response and logging discrepancies. Found UART baud rate mismatch between the gateway and the sensor."
This scenario highlights the importance of understanding communication protocols beyond just the high-level error codes. While the PR mentions resolving data loss, the core issue identified by the reviewer is a mismatch in baud rates between the gateway and the sensor device. This mismatch would directly lead to incorrect or corrupted data being transmitted, explaining both the API response code (protocol_error) and the timeout observed in the logging system. The other options represent misunderstandings – network glitches don't explain mismatched baud rates, and the logging system is unlikely to be solely responsible for misinterpreting a valid 500 status code.
12 / 18
Reviewer: 'I'm seeing some inconsistent reporting on the sensor data. The API response for device 72 shows a 'protocol_error' code with a status of 500, but the logging system is indicating a timeout. Can you check if the UART baud rate is correctly configured and verify the I2C communication isn't experiencing any bus contention?'
Which of the following best describes what the reviewer is likely referring to?
The reviewer's comment points to a discrepancy between the API response and the logging system. This strongly suggests a problem with the underlying communication protocol configuration. Specifically, an incorrect baud rate on the UART interface (which transmits data serially) or I2C bus contention (where multiple devices try to access the same bus simultaneously) can lead to corrupted data and timeouts, explaining both the API error code and the logging timeout. Option A is too broad; option B misattributes the issue to a network problem; option D incorrectly assumes an API endpoint error.
13 / 18
PR Description:
"Fix: Resolved intermittent data loss from sensor device 15. Investigated API response and logging discrepancies. Found UART baud rate mismatch between the gateway and the sensor."
This scenario highlights the importance of understanding communication protocols beyond just the high-level error codes. While the PR mentions resolving data loss, the core issue identified by the reviewer is a mismatch in baud rates between the gateway and the sensor device. This mismatch would directly lead to incorrect or corrupted data being transmitted, explaining both the API response code (protocol_error) and the timeout observed in the logging system. The other options represent misunderstandings – network glitches don't explain mismatched baud rates, and the logging system is unlikely to be solely responsible for misinterpreting a valid 500 status code.
14 / 18
Reviewer: 'The sensor data stream is intermittently failing. The API response for device 31 indicates a 'CRC error' (status code 404), but the embedded logs show no network errors. What's likely causing this?'
CRC errors in embedded protocols often point to corrupted data transmitted over the bus. A CRC (Cyclic Redundancy Check) is an error-detection code; if it fails, the data itself has been altered. This suggests a problem with the sensor's output or potentially interference on the communication line.
15 / 18
During a standup meeting, Sarah says: 'I'm troubleshooting issues with device 87. The API is returning a 'protocol_version_mismatch' error (status 503), and the embedded system's diagnostics show it's running an older firmware version.' What does 'protocol_version_mismatch' typically mean in this context?
A 'protocol_version_mismatch' error signifies that the API client (the gateway) and the embedded device are not using compatible versions of the communication protocol. This can happen when firmware is updated on one side but not the other, leading to incompatible commands or data formats.
16 / 18
You are reviewing a PR description:
"Fix: Resolved intermittent issues with device 58. The logs indicated an 'I2C arbitration lost' error (status code 600) during periods of high data traffic. We increased the I2C priority level to mitigate this."
'I2C arbitration lost' errors occur when multiple devices on the same I2C bus try to transmit simultaneously. The I2C protocol uses an arbitration mechanism to determine which device gets priority; if this fails, data loss occurs. Increasing the priority level grants higher precedence.
17 / 18
In a Slack channel, Alex writes: 'I'm seeing a lot of 'timeout' errors from device 92. The API response shows the timeout, but the embedded system isn't reporting any network connectivity issues.' What is the most likely reason for this?
A timeout error in embedded communication protocols usually means that the gateway didn't receive a response from the target device within a specified time window. This could be due to network congestion, device unavailability, or simply the device taking longer than expected to process and respond.
18 / 18
You are debugging a UART communication issue. The API response shows 'parity error' (status code 701) when sending data to device 65. What does this error signify?
A parity error in UART communication indicates that the data being sent contains an incorrect number of ones and zeros (bits) relative to the defined parity setting. This usually points to a problem with the transmission or reception of the data itself – possibly due to noise or hardware issues.
What does the "Embedded Communication Protocols — Vocabulary" exercise cover?
Learn vocabulary for embedded communication protocols: SPI, I2C, UART, CAN bus, peripheral addressing, and bus collision detection.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free to use with no account, sign-up, or paywall.
How many questions are in "Embedded Communication Protocols — Vocabulary"?
This exercise has 18 questions. Each one gives instant feedback with an explanation, so you can see exactly why an answer is right or wrong.
Do I need to create an account to save my progress?
No account is required. The progress bar and score are tracked in your browser for the current session -- the exercise is designed to be a quick, repeatable drill rather than something you resume later.
What happens if I get an answer wrong?
You'll see the correct answer highlighted immediately, along with a short explanation of why it's correct. Wrong answers aren't penalized beyond your score, and you can keep going through every question.
How is this exercise different from reading an article?
Articles explain vocabulary and concepts through prose, while exercises like this one are interactive drills -- multiple-choice questions -- that test and reinforce your recall of specific terms and phrasing.
Can I retry this exercise?
Yes -- use the "Try again" button on the results screen to reset your score and go through all the questions again from the start.
Where can I find more Embedded & RTOS exercises?
Browse the full Embedded & RTOS hub for related drills, or check the site-wide exercises index for other IT English topics.
Is this exercise suitable for beginners?
This exercise assumes basic familiarity with IT terminology. If a term feels unfamiliar, check the site Glossary for a plain-English definition before attempting the questions.
How often is new content like this published?
New exercises are added regularly across all categories, alongside new vocabulary sets and articles. Check back on the exercises hub to see what's new.