Errata

When using Atmel Studio 4 getting build errors from the usart.h and usart.c header files:-
i.e. dep/USART.c:5: *** missing separator. Stop.

In the ZIP file from github/hexagon5un/AVR-Programming the makefile in the folder Chapter02_Programming-AVRs/blinkLED/ does not contain the word MAIN. I suppose in the file is written TARGET.
It also doe not contain the words LOCAL_SOURCE, EXTRA_SOURCE, and EXTRA_SOURCE_FILES.
I think for a beginner this is very irritating, especially in this early stage of her or his progress.

It would be worth drawing a schematic of the Alice/Bob serial communication situation. Granted, I usually have to look up pull-up resistors and pull-down resistors to make sure I get it right, however, this situation is still a little ambiguous.

There is no mention of a microcontroller so I cannot assume that there is a path to ground through an mcu IO pin. The way I interpret the situation so that it follows and works with the text is as follows:

There is a VCC of 5 Vdc. Connected to this is the pull-up resistor in series with an LED for which the cathode is connected to ground. Connected to the anode is one side of a normally open pushbutton switch. The other end of the normally open pushbutton switch is connected to ground. This way, when the NOPB is pressed, it provides a path to ground, thus turning off the LED.

One more point, I know this book is for a little bit of more advanced that many books for something like the Arduino. I expect to work a little more to figure out how things are working that are not immediately apparent.

While the example is nice to explain reacting on events in real-time using interrupts, I think it should be pointed out to beginners like me that a button should normally not be connected to an interrupt as Jack Ganssle writes in his "Guide to Debouncing".
Readers could even be tempted to debounce their button using the delayed button state rechecking in the ISR as I did, which is not a good idea and didn't work well.
Checking the state of the button connected to an input pin in a timer interrupt ISR every n ms seems to be a solution recommended by many, and it works very well for me.

So maybe beginners like me could be made aware of that?

Hello,

This is a suggestion for an aside that could be included in the book. In Example 8-2 (capSense.c listing), chargeCycleCount is a 16 bits (2 bytes) unsigned integer. However, the AVR used in the book is an 8 bit processor, which means that updating or reading a 2 bytes variable requires 2 memory operations (one for each 8 bit word).

The book is correct that the variable must be marked volatile. In this particular case, the example is correct since the event loop cannot read chargeCycleCount and be interrupted by the ISR which increments it. The global interrupt flag is in fact disabled at the time the event loop reads chargeCycleCount (cli() has been called before).

However, I believe it would be great to warn in an aside about the potential race condition inherent to modifying and reading a variable longer than 8 bits concurrently in an interrupt handler and in the event loop even if it is volatile. Suppose the interrupts were not disabled at the time chargeCycleCount is read, the least significant byte of chargeCycleCount could be read, and then the event loop could be interrupted by the ISR which modifies both bytes of chargeCycleCount. Now, when execution returns to the event loop, it reads the most significant byte of chargeCycleCount.

Here is the problem, the value of chargeCycleCount as seen by the event loop is made of half the previous value and half the new value, which may cause undesired behaviours. This is called a torn read.

It would be great to explain why in Example 8-2 the sei() and cli() calls are very important.

Thank you

I'd feel better if:

if (ticks == OVERFLOWS_PER_SECOND)

were:

if (ticks >= OVERFLOWS_PER_SECOND)

I understand that if you missed just the right ticks update, you'd only be off by about a second until the value overflowed and cycled to top again. I'd still be concerned that the while loop itself or pollSerial() (even if there was no waiting data) might cause an occasional ticks overshoot.

This is just a quibble. What the author wrote is clearer and doesn't require extra explanation. And as the author also notes, you are not going to get atomic clock accuracy out of this.

A mention of the write protection modes on the 25LC256 may be warranted. The chips I used came with BP0 and BP1 set by default, hence all write operations fail silently and the example did not work on the new chips without first doing a Write Status Register Instruction transfer and pushing both bits low. As these bits are non-volatile this need only be done once, however it may save hours of troubleshooting for new users not familiar with the chip.

The i2CThermometer.c program displayed garbled output in the serial screen. Changing the serial port speeds made no difference. Although I was able to read the lm75 data in a Logic Analyser, while running the program.

When I commented out the clock_prescale_set(clock_div_1) statement or modified the parameter to clock_div_8, the serial output was Ok.

The same problem & solution applied for p373, the loggingThermometer.c program.

I used an ATMega328, is that the reason why? I did try another but still the same result. Is it because of the AtMega328 & not ATMega128? And if so any idea why??

Regards

The garbled output is fixed by using avrdude to set the full-speed clock. ie lfuse=E2
or by using the supplied makefile, run
make set_fast_fuse
(or see p191).

set bit rate calculation 8Mhz / (16+2*TWBR*1) doesn't give 100kHz but 13.9Hz

reference to p 242 doesn't help further