Written test experience

I have this question for a company some time ago, but I have no choice but to answer the first two points.

Interruption is an important part of embedded systems, which causes many compilation developers to provide an extension-to interrupt Standard C support. It indicates that a new keyword _ interrupt is generated. The following code uses the _ interrupt keyword to define an interrupt service subroutine (ISR). Please comment on this code.

_ Interrupt double compute_area (double radius)

{Double area = pI * radius;

Printf ("area = % F", area );

Return area;

}

There are too many errors in this function, so people don't know where to start:

1). ISR cannot return a value. If you do not understand this, you will not be hired.

2). ISR cannot pass parameters. If you do not see this, your chances of being hired are equivalent to the first.

3). In many processors/compilers, floating points are generally not reentrant. Some processors/compilers need to import the registers at the amount into the stack. Some processors/compilers do not allow floating-point operations in ISR. In addition, ISR should be short and efficient, and it is unwise to perform floating point operations in ISR.

4). With the 3.1 pulse, printf () often has re-import and performance problems. If you lose the third and fourth points, I won't be too embarrassed. Needless to say, if you can get the last two points, your prospects for employment will become brighter.

This company has another question. I have read the source code of others before.

Embedded systems often require programmers to access a specific memory location. In a project, the value of an integer variable whose absolute address is 0x67a9 must be set to 0xaa66. The compiler is a pure ANSI compiler. Write code to complete this task.

Test whether you know that it is legal to forcibly convert an integer number (typecast) into a pointer to access an absolute address. The implementation of this problem varies with the individual style. The typical code is as follows:

Int * PTR;

PTR = (int *) 0x67a9;

* PTR = 0xaa55;

A relatively obscure method is:

* (Int * const) (0x67a9) = 0xaa55;

Even if your taste is closer to the second option, I suggest you use the first option during the interview.

This is another question, but I am not very satisfied with it. I didn't define the bit3 Macro. Alas, I usually write it into a macro. Why that day .....

In an embedded system, you must perform bit operations on variables or registers. Given an integer variable A, write two pieces of code, set bit 3 of a first, and clear
Bit 3. In the preceding two operations, you must keep the other bits unchanged.

There are three basic responses to this problem.

1). I don't know how to start. The quilt has never worked on any embedded system.

2). Use bit fields. Bit fields is thrown into the dead corner of C language. It ensures that your Code cannot be transplanted between different compilers, and that your Code cannot be reused. Recently, unfortunately, I have seen infineon write drivers for its more complex communication chip. It uses bit fields and is completely useless to me, because my compiler uses other methods to implement bit fields. Morality: Never let a non-embedded guy stick the actual hardware edge.

3) Use # defines and bit masks. This is a highly portable method and should be used. The best solution is as follows:

# Define bit3 (0x1 <3)

Static int;

Void set_bit3 (void)

{A | = bit3;

} Void clear_bit3 (void)

{A & = ~ Bit3;

} Some people like to define a mask to set and clear values and define some descriptive constants at the same time, which is acceptable. I want to see several key points: constant, | = and & = ~ Operation.

Variables shared by several tasks in multiple tasks.Alas, what do you think. It is totally wrong. Amount... Volatile, which must be mastered in embedded systems.

People who cannot answer this question will not be hired. I think this is the most basic problem to distinguish between C programmers and embedded system programmers. Embedded System programmers often deal with hardware, interruptions, RTOS, and so on, all of which require volatile variables. If you do not know volatile content, it will lead to disasters.

If the subject correctly answers this question (well, I doubt this will happen), I will go a little deeper to see if this guy understands the full importance of volatile.

1) can a parameter be const or volatile? Explain why.

2) can a pointer be volatile? Explain why.

3) What are the following function errors:

Int square (volatile int * PTR)

{Return * PTR ** PTR;

} Below is the answer:

1). Yes. One example is read-only status registers. It is volatile because it may be unexpectedly changed. It is const because the program should not try to modify it.

2). Yes. Although this is not very common. One example is when a service subroutine repairs a pointer to a buffer.

3) This code has a prank. The purpose of this Code is to return the pointer * PTR points to the square of the value. However, since * PTR points to a volatile parameter, the compiler will generate code similar to the following:

Int square (volatile int * PTR)

{Int A, B;

A = * PTR;

B = * PTR;

Return a * B;

} Because the * PTR value may be unexpectedly changed, A and B may be different. As a result, this Code may not return the expected square value! The correct code is as follows:

Long square (volatile int * PTR)

{Int;

A = * PTR;

Return a *;

}

What is the meaning of the keyword volatile and three different examples are given. I answered the question, but I still did not really understand it.

A variable defined as volatile means that this variable may be unexpectedly changed, so that the compiler will not assume the value of this variable. Precisely, the optimizer must carefully re-read the value of this variable every time when using this variable, rather than using the backup stored in the register. The following are examples of volatile variables:

1). Hardware registers of parallel devices (for example, Status Registers)

2). Non-automatic variables that will be accessed in an interrupt service subroutine)

3) variables shared by several tasks in multi-threaded applications