Errata

Non-integral type cannot have in-class initializer and the statement "static Singleton* mInstance = 0;" inside the class definition was incorrect:

class Singleton {
public:
static Singleton* Instance() {
if (mInstance == 0) {
mInstance = new Singleton;
}
return mInstance;
}

protected:
Singleton(); // no one can create this except itself
private:
static Singleton* mInstance = 0;
}

The non-integral type static class variable should be defined as follows:
private:
static Singleton* mInstance;

If you want to initialize it to 0 and you should initialize it outside the class definition as follows:

Singleton * Singleton::mInstance = 0;

On the main Model View-Controller pattern diagram:
The arrows between the Controller and View should be in opposite directions if they are pointing from the source to destination for the message/information.

A code example reads: filter = &fir;.
Here filter is declared as a pointer to a function and fir as a function. As the name of a function, without the brackets, evaluates to the address of the function, this should be:
filter = fir;.
If the code works with the address operator it is possibly because the compiler throws the ampersand away. See K&R 1 page 209 and ANSI C.

In the first diagram, it seems like the write and read pointers are switched. write should be ahead of read for the data to be between them and (write - read) to be a positive value.

In the second diagram, the pointers are again backwards and the code seems to have them backwards as well.

Perhaps I'm misunderstanding something, but these drawings conflict with the ones on page 178.

After the loop unrolling (as reflected by the code), the while loop now only decrements bufLength once for each two bytes that are written from the byteBuffer. Since bufLength was doubled (bufLength*2) before the loop, it should decrement in tandem with the increments in byteBuffer: otherwise the buffer will run out of bytes half way through the while loop.

An somewhat more elegant solution would involve removing the multiplication (bufLength = bufLength*2) above the loop. However, in this case, the 2nd paragraph of the next page (241) should also be removed. (It starts with "Why don't I care about removing the bufLength multiplication at the top of the function?")

In fact, after reading that line, I was hopeful that my confusion would be cleared up imminently. Instead, it was increased instead :)

Kind regards, and the book was a fun and interesting read!
- Niek van Suchtelen

The code in the Interview Question box is introduced as a "relatively dumb solution", however, I'm not sure that the writer intended to omit a return statement for its 'output' variable.

Adding "return output;" after the loop would fix this issue.

Kind regards,
- Niek van Suchtelen

There are a few things in this interview question I believe could be very confusing or misleading to new embedded programmers.

In Paragraph 2, did you mean to say the bit-shift operator has lower precedence than the bit-wise and operator? (&) This would make sense for there to be an error with missing parentheses, but the missing parenthesis for the subtraction would not cause an error.

In your code examples, you have the for loop setting bits and the 3 line swap operation. The latter is a fairly compact but complicated set of operations per line. It may be worth giving a short explanation of how 1 register is saved by example 3. It also worth noting that even though 1 register is saved, assuming the compiler has optimized out the 3rd, the 1st code example is smaller in flash, saving ~3x the code space without loop unrolling. (Though the loop runs ~42 assembly operations while the 3rd runs only ~15.) I'm not sure if any of this matters, but clarification could mean the difference of understanding the tradeoffs of size and speed and just taking the latter example as the superior.

The stated equivalence of the equations for calculation of standard deviation does not hold for the "corrected" STD, i.e. when the denominator is (N-1). A simple test for the values, say, [3,5,7] verifies this: The first form returns 2, and the second form returns 4.062. The equivalence as stated holds only for the "uncorrected" STD, when the denominator is N, as shown in http://dsearls.org/courses/M120Concepts/ClassNotes/Statistics/510B2_derivation.htm.
Alternatively, the second equivalence can be fixed by encompassing the last term, (x_bar)^2, within the summation parenthesis.

In table 9-1, titled "Approximating 1/6 with a power-of-two divisor", one of the divisors listed is 23 (for equivalent shift 5). This is not a power of 2, and should be 32 instead.

Kind regards,
- Niek van Suchtelen

The sine function [...] outputs a value from -1 to 1, NOT from 0 to 1

Table 9-1 Row 3: Divisor = 23 but should be 32
Table 9-1 Row 10: Error = 0,04 but should be 0.04

In the following section of code:

struct sFakeFloat four = {1, -2};
floatingPointValue = four.num >> shift ==> 1/(2^(-2)) ==> 1 * 2^2 ==> 4

The variable 'shift' should be 'four.shift'.

Starting with table 9-4, a maximum result for the A*ADC^2 + B*ADC + C equation is given as 1249.641. However, I can get a higher maximum value by plugging in certain values from Table 9-3:

ADC: 1023
A: 0.001
B: 0.2
C: 3

Now, the equation is: 0.001 * 1023^2 + 0.2 * 1023 + 3 = 1254.129, not 1249.641.

The value for the minimum result is given as -1046.483. This is correct, as it can be obtained using ADC: 1023, A: -0.001, B: 0.002, C: -2.

However, the explanation in the paragraph starting with "We can determine" seems wrong for this case. The first line of that paragraph refers to the max. value, which is a correct explanation, although the actual value obtained doesn't seem to be a result from this explanation (as explained earlier). The part about the minimum value states that: "the minimum result can be obtained only with the maximum ADC, minimum A parameter, and zero B and C parameters". This is not true, and as shown in my previous paragraph, it's not what was used to obtain -1046.483. When using the explanation, the result would be -1046.529, which is indeed lower, but B now falls outside its 0.002 - 0.2 range, and a lower result is still possible by using -2 for C (although B would still be wrong) and it's not the result that is given in 9-4.

Kind regards,
- Niek van Suchtelen

The granularity given in the table (4.2950E+09) is wrong, for both Minimum and Maximum.

It should be 2.3283E-10.

Kind regards,
- Niek van Suchtelen

P.S. It would be great if I could get a copy of the book that incorporates the fixes!