Common interview questions for embedded software developer

Let’s see some of the common interview questions asked during an embedded C developer interview.

EMBEDDED SYSTEM

1. What changes are to be done on software if the embedded software is ported from a 32 bit architecture to a 64 bit architecture.

2. Can you call a static function which belongs to a different file, if possible How?

3. Volatile qualifier and its use in embedded software.

4. How interrupts are working in embedded software.

5. Explain how you will implement an Ethernet receiver driver using interrupt.

6. Explain about ADCs

7. Explain interrupt latency.

8. Difference between ARM and PowerPC architecture.

9. Explain how stack is working.

10. Memory layout of an executable.

11. Explain the protocols I2C, SPI and CAN.

12. What is the mechanism which determines the baud rate of a CAN network.

RTOS

1. Priority inversion, priority inheritance, priority ceiling.

2. What is deadlock and livelock.

3. Difference between Semaphore and Mutex.

4. Explain a situation where you have used Semaphore and Mutex in you past projects.

5. Process synchronization methods in RTOS.

GENERAL

1. Why are you looking for a change?

2. What is your expectation from the new job, if offered?

PROJECT

1. Explain your recent project.

2. Draw the software architecture of your recent project.

3. Challenges you faced during your project.

C CODING

1. How to find the Nth node from the end in a singly linked list.

2. Code to modify the even indexed members in an array.

3. Implement XOR without using the operator.

4. Reverse a string.

5. Convert little endian to big endian.

6. Write a C code to print a string without using a semicolon in the program.

7. Write a program to find a merge in a singly linked list.

A Quick refresher on the CAN protocol

This article is intended to give you a quick refresher on the protocol. The following paragraphs are organized in such a way that the reader is expected to have a basic understanding of the CAN protocol.

The Controller Area Network (CAN) is a serial communications protocol which efficiently supports distributed realtime control with a very high level of security. Upto 1Mbps of communication speeds can be achieved in a CAN network.

CAN protocol with refernce to the OSI model:

1. The object layer:
The scope of the object layer includes finding which messages are to be transmitted, deciding which messages received by the transfer layer are actually to be used and providing an interface to the application layer related hardware.
2. The transfer layer:
The scope of the transfer layer mainly is the transfer protocol, i.e. controlling the framing, performing arbitration, error checking, error signalling and fault confinement. Also some general features of the bit timing are regarded as part of the transfer layer. It is in the nature of the transfer layer that there is no freedom for modifications.
3. The physical layer:
The scope of the physical layer is the actual transfer of the bits between the different nodes with respect to all electrical properties. Within one network the physical layer, of course, has to be the same for all nodes.

The CAN bus is a broadcast type of bus. There is no way to send a message to just a specific node; all nodes will invariably pick up all traffic.

Layered Structure of a CAN Node:

Basic Configuration:

The physical layer of CAN is a differential transmission on a twisted pair bus. The bus uses non-return-to-zero (NRZ) with bit stuffing. The nodes are connected to the network in a Wired-AND fashion.

A maximum of 8 Bytes can be transfered per message in CAN. The messages are protected by CRC type checksum. CAN bus access is handled via serial communication scheme of Carrier Sense Multiple Access/Collition Detection with Non-Destructive Arbitration.

There are no explicit address used in the CAN messages, instead each message carries a numeric value which contains its priority and also serve as an identification of the message.

CAN uses an elaborate error handling scheme that results in re-transmitted messages if they are not properly received. Also there are effective means for isolating faults and removing faulty nodes from the bus.

About the higher layer protocols using CAN:
Higher layer protocols such as Devicenet, CANKingdom, CANopen etc. are used to standardize network startup process, to distribute ‘addresses’ among participating nodes, to determine the layout of the messages, to provide routines for error handling at the system level. But the use of the higher layer protocols are entirely optional.

Message transfer is manifested and controlled by four different frame types:
1. DATA FRAME – Carries data from a transmitter to the receivers.
2. REMOTE FRAME – To request the transmission of the DATA FRAME with the same IDENTIFIER.
3. ERROR FRAME – Transmitted by any unit on detecting a bus error.
4. OVERLOAD FRAME – To provide for an extra delay between the preceding and the succeeding DATA or REMOTE FRAMEs.

When the bus is free any unit may start to transmit a message. The unit with the message of higher priority to be transmitted gains bus access. If 2 or more units start transmitting messages at the same time, the bus access conflict is resolved by bitwise arbitration using the IDENTIFIER. The mechanism of arbitration guarantees that neither information nor time is lost.

There are two different formats which differ in the length of the IDENTIFIER field: Frames with the number of 11 bit IDENTIFIER are denoted Standard Frames. In contrast, frames containing 29 bit IDENTIFIER are denoted Extended Frames.

CAN Standard Data Frame:

CAN Extended Data Frame:

PIC16F886 Assembly example code for UART echo test using interrupt

PIC16F886 Assembly example code for UART echo test using interrupt

This example assembly code for PIC16F886 can be used to learn the working of the UART module within the PIC MCU. The assembly code project is comprised of two *.asm files and can be compiled using MPLAB IDE.

Working:
The program will echo back the characters which were entered from a PC (Personal Computer).
.
.
.
.
.
.
.
Source files:

1. main.asm

2. uart.asm

PS: The above assembly program is having a special behavior while executing the same. Readers are encouraged to find out the program behavior and are welcome to comment on this. 🙂

LED Blink Assembly code for PIC16F886 using Timer0 interrupt

LED Blink Assembly code for PIC16F886 using Timer0 interrupt

The below is a working example of LED blink program using PIC assembly code which can be compiled on MPLAB IDE.

Abstract:

The LED is connected to RC4 of PIC16F886 and the circuit is setup as active LOW. Here the LED will glow when the RC4 output is made to ‘0’.
.
.
.
.
.
.
.
The PIC configurations used are,

There are 3 global variables also used for the project which are shown as below.

There are 2 labels also used as shown below,

Complete Assembly program: