Training

A beginner’s guide to microcontrollers

December 2, 2015 By Aimee Kalnoskas 6 Comments

by Jon Wilder

Time after time I see beginners try to get started in embedded electronics, only to be overwhelmed and not know where to start. Some even make the mistake of trying to write their own code without first gaining a thorough understanding of the microcontroller/microprocessor they’re working with, the programming language they’re working with, or even basic programming concepts. Not to worry though…this article should pose a good primer to get your feet wet in the world of embedded electronics.

This article does not attempt to teach about any specific microcontroller/microprocessor, but is more of a primer to explain the general concepts which apply to all microcontrollers/microprocessors.

First, off…let’s ask ourselves a couple of questions. The first question –

What is a microcontroller?
A microcontroller is a tiny microcomputer on a chip. It has a CPU, RAM (Random Access Memory), special function registers, program ROM memory, data ROM memory, anywhere from one to several parallel I/O (Input/Output) ports, and can have a host of on chip peripherals including but not limited to Analog-to-Digital Converter (ADC), Digital-to-Analog Converter (DAC), Serial UART, one or several timers, comparators/on chip voltage reference, capture/compare/PWM (Pulse Width Modulation) module, Master Synchronous Serial Port for SPI (Serial Peripheral Interface)/I2C (Inter Integrated Circuit) communications, USB port, ethernet port, on chip oscillators, along with a host of other peripherals.

What is a microprocessor (wait, you mean there’s actually a difference)?
A microprocessor is everything a microcontroller is but without the program ROM on chip. The program code resides off-chip in a separate external EPROM chip.

Program ROM and Data ROM
The on-chip ROM memory (Read Only Memory) on a microcontroller is like a microcontroller’s hard drive. It has two partitions. One partition is reserved for the storage of the program code while the other partition is reserved for permanent storage of data that is used by the chip during normal program execution. On a given PIC microcontroller with say 8K of program space, the program space would occupy ROM addresses 0x0000 – 0x1FFF (or 0 – 8191 in decimal). The data space would start at program ROM address 0x2100. If the data ROM space were 256 bytes long, the data ROM space would occupy ROM addresses 0x2100 – 0x21FF (or 8448 – 8704 in decimal).

CPU
CPU stands for Central Processing Unit. It is basically the “brains” of the microcontroller. It is what fetches the instructions from the code memory and executes the instructions that it fetches.

Data RAM
The data RAM (Random Access Memory) is the data space that is used for temporarily storing constant and variable values that are used by the microcontroller during normal program execution. The amount of physical RAM space on a given microcontroller varies from one microcontroller to the next. The data RAM on a microcontroller is organized into several “registers”, each with its own unique “address”. A RAM register on an 8 bit microcontroller can hold a total of 8 bits, or one byte of data. A typical RAM space specification may specify that it is 256 x 8. This means that there are a total of 256 registers in the RAM, and those registers can hold 8 bits each.

A register is just a location in memory that you can write data to or read data from. Some of us refer to registers as “locations”.

Special Function Registers
The special function registers (or simply SFR’s) on a microcontroller are just like the registers in data RAM. You can write data to them as well as read data from them. Where they differ is that some SFR’s directly control the on-chip hardware on the microcontroller while others are controlled by the on-chip hardware on the microcontroller.

Each bit in an SFR is assigned to a function. In the SFR’s you have control bits and flag bits. Control bits are like “switches” that turn a function on or off depending on if you write a 1 or a 0 to that bit location in the SFR. Flag bits are like “indicator lights” that indicate whether or not a given condition exists depending on whether the flag bit is a 1 or a 0. Control bits directly control the hardware. Flag bits are controlled by the hardware. In any given program, we typically write to control bits while we read flag bits (some flag bits must be manually cleared by writing to them depending on the microcontroller…more on this later).

Each piece of hardware on the microcontroller will have at least 1 SFR assigned to it. Some hardware may have several SFR’s assigned to it. Consult your microcontroller’s data sheet to learn more about its specific SFR organization.

Configuration Bits
Most microcontrollers have special bits known as the “configuration bits”. These bits configure special options on the microcontroller including but not limited to –

* Oscillator Type
* Watchdog Timer On/Off
* Power Up Timer On/Off
* Brown Out Reset On/Off
* Low Voltage Programming On/Off
* Fail Safe Clock Monitor On/Off
* Internal/External Switchover On/Off

On a PIC microcontroller, there are even configuration bits for program code protection and data code protection. These bits prevent the program or data spaces from being read by external programming hardware to keep others from stealing your code. On an Atmel AT89S chip (8051 derivative), this is set by what is known as the “lock bits”.

Some refer to the configuration bits as the “fuse bits”. This comes from the old days of microprocessors that had actual “fuses” on chip that would get blown if certain fuse bit controlled functions were turned off. These fuses were “one time programmable”…once they were blown, there was no “unblowing” them. However, with the advent of flash memory available on modern microcontrollers, there are no more literal “fuses” on the chip. But the term itself carried over due to the configuration bits essentially providing the same control as the fuse bits did.

The ALU (Arithmetic and Logic Unit)
This piece of hardware is essentially responsible for all of the math and logic operations that are performed by the microcontroller. On most microcontrollers, the ALU will have 3 flag bits associated with it –

* The Zero Bit – This flag bit gets set to a 1 by the hardware whenever a math operation results in a zero result. It will be cleared to a 0 by the hardware whenever a math operation results in a non-zero result.

* The Carry/Borrow Bit – This flag bit works as a carry bit for addition operations while working as a borrow flag for subtraction operations. A “carry” occurs when the result of an addition operation results in a value larger than what the register is capable of holding. An 8 bit register can hold a maximum value of 255 (FF in hex or 11111111 in binary).

If an addition operation results in a result of greater than 255, the carry flag gets set to 1. If an addition operation results in a result of less than 255, no carry takes place so the carry flag gets cleared to 0.

For subtraction operations, the carry flag works as a borrow flag instead. The borrow flag works in reverse of the carry flag. If a subtraction operation results in a negative result, the borrow flag gets cleared to 0. If a subtraction operation results in a positive result, the borrow flag gets set to 1.

* The Digit Carry/Borrow Bit – This flag bit does the same thing as the carry/borrow flag, but it only works to indicate if a carry/borrow takes place between bits 3 and 4 only.

The ALU flag bits can be read at anytime to know whether the results of math operations were zero, positive/negative, or greater than/less than, etc etc.

The zero bit is a handy flag bit that allows us to compare two values to see if they are equal/not equal. If we take two numbers and subtract them, the result will be zero if equal while being non-zero if not equal. So to compare two values to see if they are equal/not equal, we subtract them, then read/check the zero bit to see if the bit is a 1 or a 0. If Zero Bit = 1, the result of the subtraction is zero, which means that the two values are equal. If Zero Bit = 0, the result of the subtraction is non-zero, which means that the two values are not equal.

The carry/borrow bit is a handy flag that allows us to compare two values to see if one value is greater than/less than the other value. Example…we have two values: VALUE1 and VALUE2. In code we perform this operation –

VALUE1 – VALUE2 = VALUE3

Once the subtract operation has been executed, we then read/check the high/low state of the carry/borrow bit.

If VALUE2 is greater than VALUE1, the result of the subtraction will be negative, which will clear the carry/borrow bit to 0. If VALUE2 is less than VALUE1, the result of the subtraction will be positive, which will set the carry/borrow bit to 1.

Consult the data sheet to learn which SFR contains these bits. On PIC microcontrollers, the ALU flag bits reside in the STATUS SFR. On MCS-51, they reside in the PSW SFR (Program Status Word).

The Program Counter
The Program Counter is an “address pointer” that tells the CPU where to find the next instruction to execute in program ROM. The CPU will fetch the instruction which resides at the program ROM address that is currently loaded in the program counter.

When the microcontroller resets, the program counter is initialized to 0x0000. The CPU will fetch the instruction which resides at program ROM address 0x0000. Once this instruction has been fetched, the program counter auto increments to the value of 0x0001. The program counter continuously auto-increments by the value of 1, which causes the CPU to access the contents of each register location in program ROM sequentially. It keeps doing so until the CPU has fetched and executed an instruction which modifies the value of the program counter. Such instructions that do this are jump instructions (ajmp and ljmp on MCS-51, goto on PIC), subroutine calls (acall and lcall on MCS-51, call on PIC), and any instructions which add or subtract a value to or from the program counter.

The Stack
The stack on a microcontroller is primarily used during subroutine calls and jumps to an interrupt handler. It is a “Last In First Out” buffer that is used to store return addresses. During a subroutine call, the current program counter address is “pushed” onto the stack with a +1 offset added to it, then the program counter is modified with the address value where the subroutine being called resides. This makes the program counter jump to the subroutine code to execute the subroutine.

At the end of the subroutine, there will be a “return” instruction (ret on MCS-51, return on PIC). Upon the execution of the return instruction, the stack is “popped”, and the last ROM address value that was pushed onto the stack is popped off of the stack and back into the program counter. This makes the program counter jump back to the instruction that resides after the instruction that called the subroutine (hence the need for the +1 offset at the time that the PC address is pushed onto the stack), and program execution continues where it left off prior to the subroutine call.

Some microcontrollers have a “software stack” (MCS-51). A software stack uses some of the microcontroller’s internal RAM space as the stack space. Other microcontrollers have a hardware stack (PIC). With a hardware stack, the stack is its own dedicated space that is separate from all other on chip memory spaces.

On some microcontrollers, the stack is writable. This allows us to use the stack for temporarily backing up critical registers during subroutine calls and interrupt handler execution. Prior to executing the subroutine or interrupt handler, the contents of the registers to back up are pushed onto the stack. Then, just prior to returning from the subroutine or interrupt handler, the contents we pushed onto the stack at the beginning of the subroutine are popped off of the stack one at a time, then restored to their original locations in reverse order from how they were pushed onto the stack (remember…Last In First Out).

A good example of this would be how we back up the accumulator and the PSW registers on MCS-51 during the execution of an interrupt handler routine –

Code (text):

push ACC ;back up accumulator onto stack
push PSW ;back up program status word onto stack

;execute interrupt handler code here

pop PSW ;restore program status word
pop ACC ;restore accumulator
reti ;return to main code from interrupt

As you can see, we first push the accumulator contents onto the stack, then we push the contents of the PSW onto the stack after it. The interrupt handler code is then executed.

After execution of the interrupt handler code, the PSW is popped off the stack first, then the accumulator is popped off of the stack after it…in reverse order from how they were pushed.

A typical SFR
A typical SFR is set up as shown below.

Code (text):

| PORT 1 SFR |
———————————————————
| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
| P1.7 | P1.6 | P1.5 | P1.4 | P1.3 | P1.2 | P1.1 | P1.0 |
| 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |

This is the port latch SFR on an MCS-51 microcontroller for parallel port 1. Each port on the MCS-51 is an 8 bit parallel port and each of the bits in the port SFR are assigned to each pin on the port. P1.0 would be pin 0 on port 1, P1.1 would be pin 1 on port 1, P1.2 would be pin 2 on port 1, etc etc.

As shown we have all zeros written to each of the bits in the port 1 latch SFR. This will place all of the pins on port 1 in the low state (0 volts). If we were to write 1’s to any of the port SFR bits, this will set the pin associated with the bit position that we write the “1” to in the high state (+5V).

Example, let’s write the value 01010101 to the port 1 SFR –

Code (text):

| PORT 1 SFR |
———————————————————
| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
| P1.7 | P1.6 | P1.5 | P1.4 | P1.3 | P1.2 | P1.1 | P1.0 |
| 0 | 1 | 0 | 1 | 0 | 1 | 0 | 1 |

As shown, this will place pins P1.0, P1.2, P1.4 and P1.6 in the high state while placing pins P1.1, P1.3, P1.5 and P1.7 in the low state.

A word on datasheets…and why they’re so important
Not all microcontrollers are created equal. Each and every one is designed with specific hardware on the chip. Microcontrollers from different manufacturers all have different architectures. You will find that PIC microcontrollers differ greatly from MCS-51 microcontrollers just as MCS-51 differs greatly from say the Motorola 65xx in regards to how the SFR’s are implemented, how the data RAM is organized, the instruction set, configuration word, how the parallel ports work, etc etc.

The ONLY way to know exactly how to work with your microcontroller and its hardware is to consult its datasheet. The datasheet explains every SFR, every piece of on chip hardware, the absolute maximum electrical ratings, the program/data memory organization, how the parallel ports are wired and how they work, the instruction set summary (for those of you who code in assembly language), etc etc. Pretty much everything that you as the programmer will need to know about your microcontroller is in the microcontroller’s datasheet.

Most of them are freely available online with a simple Google search (I have yet to find one that isn’t). Stating that you couldn’t find the datasheet is not an acceptable excuse when it comes to this. The ONLY reason why anyone would refuse to look up the datasheet is either because they are too lazy OR they don’t understand them but don’t want others to know that they don’t. I will say right now though…most forum questions regarding microcontrollers could’ve been self answered had the person taken the time to look up the answer in the datasheet.

Datasheets are absolutely mandatory. You will not be able to write your own code without them.

About the Author
Jon Wilder is a freelance electronics engineer and electronics enthusiast for over 20 years. He spent four years in the US Navy as an aviation electronics technician. Jon has also been playing the guitar since age 13 and started integrating electronics and music from age 15. Jon built his first vacuum tube amp at age 17. “Musical electronics”, says Jon, is his love and passion.

Jon is also a frequent contributor and passionate member of Electro-Tech-Online engineering community. On Electro-Tech-Online, you can ask questions and get answers from your fellow engineers on everything from microcontrollers, renewable energy, and automotive electronics, to circuit simulation and design. Additionally, there are MCU-specific forums for 8051/8951, AVR, ARM,Arduino, Oshonsoft Project, as well as a Code Repository where members share snippets of code.

Follow Jon on Twitter at @PICmcuguy.

timer 0 and PIC16F628A

June 22, 2015 By Aimee Kalnoskas Leave a Comment

by Jon Wilder

The on-chip timer on PICs is confusing to some. But, not to worry…it’s probably one of the simplest on-chip peripherals to use on a PIC. In this article, we’ll use the PIC16F628A as our example of why that’s true.

Timer 0 (TMR0) is one of three timers available on the 16F628A that is running constantly — there’s no way to turn it off. It’s basically an 8-bit wide register in the SFRs and a clock source controls its value. The clock source for TMR0 can be either an external strobe signal fed in on pin RA4/T0CKI (T0CKI = Timer 0 Clock Input), or it can be the internal instruction cycle clock. When operating with an external strobe, it can be the counter that “counts” the strobe pulses of an external strobe source. When operating with the instruction cycle clock, it works as a timer. For this reason, you will sometimes hear engineers refer to TMR0 as the “timer/counter”.

The value residing in the TMR0 register starts at 0x00, and then rises by a factor of one upon every low-to-high transition of the clock source. You can also configure it to increment on the high-low or the low-high transition by using an external clock source. Basically, it’s just a register that counts pulses from one of two possible clock pulse sources as high as 0xFF (decimal 255). For this example, we will use the instruction clock operating as a timer.

The instruction clock runs at 1/4th the Fosc frequency. This means that if Fosc = 4MHz, our instruction clock runs at 1MHz, or one instruction per microsecond. In this scenario — assuming we don’t assign the prescaler TM — TMR0’s value is incremented on every pulse of the instruction clock. At a 1MHz instruction clock frequency, this increments the value in register TMR0 once every microsecond (1/μ).

Because the TMR0 register is only 8 bits wide, the maximum value that TMR0 can be incremented to is 0xFF, or decimal 255. At that point, it will roll over back to zero upon the next clock pulse. Once this rollover occurs, the Timer 0 interrupt flag is set (T0IF) in the INTCON register.This flag must be cleared in software.

Since TMR0 is currently running at one increment per μ, this means that the rollover occurs and the T0IF flag gets set once every 256μ (0x00 – 0xFF or 0-255 for 256 increments). If we wanted to know when a period of 256μ has passed, we can clear TMR0, clear the T0IF flag, then poll interrupt flag T0IF until T0IF goes high (rollover occurred), and continue on with our program.

Of course, a timer wouldn’t be useful without some way to slow it down to different increment rates. This is the job of the “prescaler”. The prescaler allows us to prescale the timer so that instead of it being incremented on every clock pulse, we can have it increment every two clock pulses, every four, every eight, etc…all the way up to every 256 clock pulses. If we were to set the prescaler to 1:256 with a 1MHz instruction clock, the timer would be incremented once every 256μ. Since our TMR0 register can count up to 256, it would count how many times a 256μ period passes up to 256 times. This means T0IF would get set every 65.5mS (milliseconds…256μ x 256 = 65.5mS).

The four registers of TMR0
There are four registers associated with TMR0: TMR0, OPTION_REG, INTCON, and TRISA. Let’s look at these in detail.

TMRo
Register TMR0 holds the value that is being incremented by the clock source. Any writes to this register (i.e. clrf TMR0, movwf TMR0, bsf TMR0, X) will also clear the prescaler back to a 1:2 prescale. This means you will have to reset the prescaler back to where you had it every time you write to register TMR0 if you had it set anywhere other than 1:2.

OPTION_REG
____
| RBPU |INTEDG| T0CS | T0SE | PSA | PS2 | PS1 | PS0 |

The OPTION register holds the control bits for the following:

Timer 0 Clock Source (T0CS)
Timer 0 Source Edge Select Bit (TOSE)
Prescaler Assign Bit (PSA)
Prescaler Rate Select Bits (PS2-PS0)

T0CS – Selects the clock source for TMR0. Default is 1/T0CKI. Clearing this bit will select the instruction clock as the TMR0 clock source.

T0SE – Selects whether TMR0 is incremented on the rising or falling edge of T0CKI. Default is 1/Increment on falling edge. Only applies when T0CKI is the clock source.

PSA – This sets whether the prescaler is assigned to TMR0 or the Watchdog Timer. Default is 1/Prescaler assigned to WDT. When assigned to the WDT, TMR0 runs on a 1:1 prescale (increments on every pulse of the clock source).

PS2-PS0 – Sets the prescaler rate between 1:2 – 1:256 in bit-divisible values. Default is 111/1:256 (1:128 if assigned to the WDT).

TMR0 setup with the instruction clock as the clock source and a 1:4 prescaler

INTCON
The interrupt control register INTCON contains both the TMR0 interrupt control bit (T0IE) as well as the TMR0 interrupt flag bit (T0IF). If TMR0 interrupt is enabled (T0IE = 1…disabled by default), the program counter will jump to the interrupt handler code upon TMR0 overflow when T0IF gets set (T0IF must be cleared in software prior to exiting the interrupt). However, since T0IF continues to run normally whether the TMR0 interrupt is enabled or disabled, it’s always available for polling if you do not want TMR0 to trigger an interrupt.

TMR0 interrupt setup

If you use multiple interrupts, you will have to poll all of your interrupt flags to determine which interrupt triggered the interrupt condition, then jump it to the applicable code.

TRISA
The TRISA register contains the port direction bit for RA4/T0CKI. To configure RA4 as the TMR0 clock source input, TRISA bit 4 must be set to configure it as input.

A complete TMR0 setup with interrupt, instruction clock as the clock source and 1:4 prescaler

If we omit the bottom two lines of code so that we’re not working with a TMR0 interrupt, we can still poll the TMR0 interrupt flag to know when the overflow happens:

Using TMR0 as a counter
You can also configure a TMR0 as a pulse counter. To do this, you configure T0CKI as the clock source by setting bit T0CS in OPTION_REG. Bit T0SE in OPTION_REG will control whether the TMR0 register gets incremented on the falling edge of the pulse source (1) or on the rising edge of the pulse source (0).

You can implement one of the other two hardware timers to set up a sample interval, or you could do it in software with delay loops. Set up the code where it calls the delay loop after which the TMR0 is sampled to see how many pulses were counted during the set delay interval.

And that’s all there is to know about TMR0. Simple right?

Jon is also a frequent contributor and passionate member of Electro-Tech-Online, an electrical engineering membership community. On Electro-Tech-Online, you can ask questions and get answers from your fellow engineers on everything from microcontrollers, renewable energy, and automotive electronics, to circuit simulation and design. Additionally, there are MCU-specific forums for 8051/8951, AVR, ARM, Arduino, Oshonsoft Project, as well as a Code Repository where members share snippets of code.

Follow Jon on Twitter at @PICmcuguy.

How To Monitor I2C Communications Through RS232

October 10, 2014 By Aimee Kalnoskas 1 Comment

by Electro-Tech-Online member languer

In the past when requiring to monitor I2C communications between two devices I would use a logic analyzer. Such monitoring was useful to determine if the I2C communications between devices was properly configured. Even though this is quite useful and efficient, it does require a logic analyzer, with an I2C protocol debugger. Such devices are actually pretty common and not too expensive (e.g. Saleae Logic analyzer), but sometimes these may be overkill and a small specialized device may suffice. In comes the I2C monitor. Something which:

can monitor simple I2C communications between two or more devices (at up to 100kHz bus speeds)
does not respond, acknowledge, or in any way modify the communication being monitored
outputs the transactions through RS232

This is nothing new. In fact the ideas behind this project were born from the following projects:
I2C Bus Sniffer on AVR
Robust I2C Slave Without a Sampling Clock

Design
To monitor simple I2C communications between two or more devices and output these transactions through RS232 to a PC, in some of the reference designs listed before most of the work is done by the MCU. The MCU samples the SCL and SDA lines and has to determine the START and STOP conditions, as well as the normal data. The flow diagram sort of goes as follows:

To help the MCU keep up with the data, external hardware is added to handle the Start and Stop conditions. This was done on both the “I2C Bus Sniffer on AVR” and “Robust I2C Slave Without a Sampling Clock” articles. Such implementation requires four dedicated pins: three interrupt pins (one for Start condition, one for Stop condition, one for SCL), and one standard input for SDA. In addition the MCU requires built-in USART hardware.

The next figure provide illustration of how create the two additional hardware blocks for the Start and Stop conditions needed. During normal transactions the SDA (data) line is only allowed to change when the SCL (clock) line is at a logic low. A Start and Stop condition is then defined by a change of the SDA line when the SCL line is at a logic high; the Start condition indicated when the SDA transfers from at a logic high to a at a logic low with the SCL at a logic high, and the Stop condition indicated when the SDA transfers from at a logic low to a at a logic high with the SCL at a logic high.

Flip-Flops can be used to create a simple method to identify these conditions, and create simple pulses to indicate either condition. The next figure shows a dual D-type flip-flop configuration used to determine a Start condition.

The following figure, on the other hand, shows a dual D-type flip-flop configuration used to determine the Stop condition.

These Flip-Flop hardware blocks together with the MCU can now provide the building blocks for the I2C monitor. The I2C Start command, as decoded by the flip-flop, can trigger an I/O interrupt on the MCU indicating the start of the message. The I2C Stop command, as decoded by the flip-flop, can trigger a separate I/O interrupt on the MCU indicating the end of the message.

For proper operation, the following requirements exist for the MCU:

MCU must be clocked at the highest MHz rate possible (this is to be able to keep up with high data rates during the interrupt routines)
MCU requires dedicated USART hardware/pins
MCU requires three interrupt pins

For the implementation Microchip’s 18F1320 PIC was chosen. This MCU has the following specifications:

40MHz clock (10MHz internal – using x4 PLL)
Two dedicated USART pins
Four dedicated interrupt pins (one is shared with USART, so CCP pin is used as third)

Implementation
The following figure shows the implementation of the proposed design. For a quick prototype, the FTDI interface was replaced with an FTDI TTL cable. Oshonsoft Basic was used to code and simulate the PIC MCU operation before actual implementation and testing of the hardware. The prototype worked as expected with two caveats: (1) the maximum bus supported speed is 100kHz, and (2) if the internal buffer on the MCU overflows there is currently no indication for this. Ideally such a device would work for I2C communications up to 400kHz, but this is limited by the PIC MCU clock and the RS232 output routines. The higher I2C communications are better suited for an FPGA implementation.

Click ASM Code for pdf of full Code

16 Best Questions to ask Embedded Systems Programmers

September 29, 2014 By Aimee Kalnoskas 2 Comments

Trying to decide if your potential new embedded programmer hire has what it takes? Need a little help with embedded-specific interview questions? Or do you simply want to take a break and have fun with a test?

Electro-Tech-Online member known as amol. guilhane07 has compiled 16 questions to ask when recruiting embedded systems programmers. We list the questions here — but we aren’t giving you the answers right away. Try the test yourself and then follow the link at the end to Amol’s pdf with questions and answers. Let us know how you did and if you found the questions useful.

Tip: Click the code for a clearer image in a new window.

An obligatory and significant part of the recruitment process for embedded systems programmers seems to be the ‘C Test’. Over the years, I have had to both take and prepare such tests and in doing so have realized that these test can be very informative for both the interviewer and interviewee. Furthermore, when given outside the pressure of an interview situation, they can also be quite entertaining (hence, this article).

From the interviewer’s perspective, you can learn a lot about the person that has written or administered the test. Is the test designed to show off the writer’s knowledge of the minutiae of the ANSI standard rather than to test practical know-how? Does it test ludicrous knowledge, such as the ASCII values of certain characters? Are the questions heavily slanted towards your knowledge of system calls and memory allocation strategies indicating the writer may spend his time programming computers instead of embedded systems? If any of these are true, then I know I would seriously doubt whether I want the job in question.

From the interviewer’s perspective, a test can reveal several things about the candidate. Primarily, one can determine the level of the candidate’s knowledge of C. However, it is also very interesting to see how the personal reasons to choices, backed up with some good intuition, or do they just guess? Are they defensive when they are stumped or do they exhibit a real curiosity about the problem, and see it as an opportunity to learn something? I find this information as useful as their raw performance on the test.

With these ideas in mind, I have attempted to construct a test that is heavily slanted towards the requirements of embedded systems. This is a lousy test to give to someone seeking a job writing compilers! The questions are almost all drawn from situations I have encountered over the years. Some of them are very tough, however, they should all be informed.

This test may be given to a wide range of candidates. Most entry-level applicants will do poorly on this test, while seasoned veterans should do very well. Points are not assigned to each question, as this tends to arbitrarily weight certain questions. However, if you choose to adopt this test for your own use, feel free to assign test scores.

Preprocessor

Q1: Using the #define statement, how would you declare a manifest contact that returns the number of seconds in a year? Disregard leap years in your answer.

Q2: Write the “standard” MIN macro. That is, a macro that takes two arguments and returns the smaller of the two arguments

Q3: What is the purpose of the preprocessor directive #error?

Infinite Loops

Q4: Infinite loops often arise in embedded systems. How does one code an infinite loop in C?

Data Declarations:

Q5: Using the variable a, write down definitions of the following:

An integer
A pointer to an integer
A pointer to a pointer to an integer
An array of ten integers
An array of ten pointers to integers
A pointer to an array of ten integers
A pointer to a function that takes an integer as an argument and returns an integer
An array of ten pointers to functions that take an integer argument and return an integer

Static

Q6: What are the uses of the keyword static?

Q7: What does the keyword “const” mean?

Q7.1: What do the following incomplete declarations mean?

const int a ;

int const a ;

const int *a ;

int * const a ;

int const * a const ;

Volatile

Q8: What does the keyword volatile mean? Give three examples of its use.

Q8.1:

(a) Can a parameter be both const and volatile? Explain your answer.
(b) Can a pointer be volatile? Explain your answer.
(c) What is wrong with the following function?:

Bit Manipulation

Q9: Embedded systems always require the user to manipulate bit sin registers or variables. Given an integer variable a, write two code fragments. The first should set bit 3 of a. The second should clear bit 3 of a. In both cases, the remaining bits should be unmodified.

Accessing Fixed Memory Locations

Q10: Embedded systems are often characterized by requiring the programmer to access a specific memory location. On a certain project, it is required to set an integer variable at the absolute address 0x67x9 to the value 0xaa55. The compiler is a purse ANSI compiler. Write code to accomplish this task.

Interrupts

Q11: Interrupts are an important part of embedded systems. Consequently, many compiler vendors offer an extension to standard C to support interrupts. Typically, this new keyword is interrupt. The following code uses interrupt to define an interrupt service routine. Comment on the code:

Code Examples

Q12: What does the following code output and why?

Q13: Comment on the following code fragment:

Dynamic Memory Allocation

Q14: Although not as common as in a non-embedded computer, embedded systems still do dynamically allocate memory from the heap. What are the problems with dynamic memory allocation in embedded systems?

Q15: Typedef is frequently used in C to declare synonyms for pre-existing data types. It is also possible to use the preprocessor to do something similar. For instance, consider the following code fragment

The intent in both cases is to define dPS and tPS to be pointers to structure s. Which method (if any) is preferred and why?

Obfuscated syntax

A16: C allows some appalling constructs. Is this construct legal, and if so what does this code do?

You’re done! Download the original pdf here with the questions and answers.

Do you have questions of your own that you either you used in recruiting — or that were used on you? Share in the comments below and we’ll put them together in another future post.

References

In Praise of the #error directive. ESP September 1999.
Efficient C Code for Eight-Bit MCUs, ESP November 1988.

Training

A beginner’s guide to microcontrollers

timer 0 and PIC16F628A

How To Monitor I2C Communications Through RS232

16 Best Questions to ask Embedded Systems Programmers

EE World Online Network

Microcontroller Tips

Training

Footer

EE World Online Network

Microcontroller Tips