Errata

r get a board with a higher SRAM (dynamic memory)
---------------------------
Doesn't SRAM mean STATIC memory?

Note from the Author or Editor:
Despite having the word "static" in its name, static RAM is a form of volatile memory. This is in contrast to dynamic RAM (DRAM), which needs to be occasionally refreshed to maintain an electrical charge. SRAM holds its state as long as power is maintained without needing additional circuitry to refresh it. See https://en.wikipedia.org/wiki/Static_random-access_memory for more details. I will add a clarifying note the first place this term is used.

The examples that follow assume you have sensors wired to digital pins 2 and 3 as discussed in Chapter 5.
-------------------------------------
Where exactly in chapter 5 is connecting sensors to pins 2 and 3 discussed?

Note from the Author or Editor:
Thank you; I apologize that this is unclear. Chapter 5's examples are not pin-specific, but the text suggests there is an example specific to these pins. I will change this to read:

"wired to digital pins 2 and 3. Several of the recipes in Chapter 5 discuss connecting sensors and other components to digital pins."

char c1 = 4;
char c2 = 210;

What are these supposed to be? I don't see them being used anywhere in the sketch.

Note from the Author or Editor:
Thank you for catching this error. That code appears to be a vestige of some earlier version and serves no purpose. It will be removed.

This sentence:
---------------------------------------------------------
This is because the pull-ups have been enabled on them using INPUT_PULLUP.
----------------------------------------------
In this sketch the pull-up resistors for the digital pins were enabled not by INPUT_PULLUP, but by this code:

for(int i=2; i <= 13; i++)
{
pinMode(i, INPUT); // set pins 2 through 13 to inputs
digitalWrite(i, HIGH); // turn on pull-ups
}
Actually, this seems to be a valid method of doing this, but only for Arduino versions prior to version 1.0.1, to wit:
-----------------------------------------------------------------------------------
Prior to Arduino 1.0.1, it was possible to configure the internal pull-ups in the following manner:
pinMode(pin, INPUT); // set pin to input
digitalWrite(pin, HIGH); // turn on pullup resistors
https://www.arduino.cc/en/Tutorial/DigitalPins
----------------------------------------------------------------------------------
The question is, is it still possible to use this method to enable pull-up resistors for digital pins in Arduino versions >= 1.0.1?
===========================================================

Anyway, the method said to had been used to enable pull-ups, was not actually used.

Note from the Author or Editor:
Thank you for this correction. I will incorporate it into a future reprint. In general, the method shown will work on 8-bit boards. However, it is not expected to work on 32-bit boards. See https://learn.adafruit.com/adafruit-feather-m0-adalogger/adapting-sketches-to-m0

Page 358. The text under Fig.8.13.

You can find circuit diagrams for this in the Arduino wiki
---------------------------------
What is this "Arduino wiki"? There is no wiki page on the Arduino web-site.

Note from the Author or Editor:
Thank you. This referred to the now-obsolete Arduino Playground, but much of what was there is outdated or refers to broken links. We will remove the reference for now, but will research whether it's valuable to elaborate on this in a future edition of the book.

Page 367, the line of code at the bottom of the page:
---------------------------------------------------
determine direction based on whether steps_to_mode is + or -
--------------------------------------------------------------------
What is this steps_to_mode? This is the only occurrence of this variable in the entire book.

Note from the Author or Editor:
Thank you for submitting this errata, and I'm sorry it made it through to the final version. The text "steps_to_mode" should be "steps", referring to the variable on the following line of code.

Page 461, the last sentence in the second from bottom paragraph:
-----------------------------------
The download for the Graphical LCD covered in Recipe 11.9 contains example sketches for displaying and setting time using an analog clock display drawn on the LCD.
---------------------------------
Exactly WHAT download for Graphical LCDs? There are quite a few links given in that section.

Note from the Author or Editor:
Thank you for reporting this. In a previous edition, recipe 11.9 used a single library that did have this example, but that is no longer the case. We well revise it to read:

All these examples print to the serial port, but you can print the output to LEDs or
LCDs. For example, the Adafruit LED Backpack library introduced in Recipe 7.13,
contains example sketches (clock_sevenseg_ds1307 and clock_sevenseg_gps) for displaying
time using an analog clock display drawn on an LED segment display.

Page 488, See Also section.
This sentence:

A cross-reference of similar I2C EEPROMs (https://oreil.ly/3aLyo) with a wide range of capacities

----------------------------
The link is dead.

Note from the Author or Editor:
Apologies, but it appears that the 'f' was truncated from the complete URL when the URL was shortened. The correct link should be http://ww1.microchip.com/downloads/en/DeviceDoc/21621d.pdf

Page 500, text after the code after Fig. 13.13.
---------------------------------------
A3 is analog pin 3 (digital pin 17), and A2 is analog pin 2 (digital pin 16); these pins provide power to the nunchuck:

enum nunchuckItems { joyX, joyY, accelX, accelY, accelZ, btnZ, btnC };

enum is the construct to create an enumerated list of constants, in this case a list of the sensor values returned from the nunchuck.

--------------------------------------
I am having problems with seeing the relation of the given code line to the preceding statement of the pins used to provide power to the Wii Nunchuk. The code line just has no logical relation to the text preceding it as the colon at the end of the text seems to suggest. At least I don't see it.

The code line does form a logical unit with the following text, but it seems rather awkward to open a new logical unit with just a line of code.

Note from the Author or Editor:
Thank you for catching this. The paragraph in question should end with a period instead of a colon and the paragraph that begins with "enum is the construct" should be moved to precede the line of code that begins with "enum nunchuckItems".

Pages 505-507. Code.

Is there any reason why there are two statements in some lines in these code listings?

Would it affect the functionality of the program is such lines were to be split in two, with each statement in its own line?

As far as I know, it shouldn't, but who knows.

Note from the Author or Editor:
This is a purely stylistic decision and you could break the code after the semicolons without altering the functionality of the program. Because the two adjacent lines (digitalWrite and delay) are companions and are short lines, it can sometimes be a useful stylistic choice to group them in this way.

Page 521, the paragraph immediately above fig. 14.5.

In your code, you must replace 0013A200 (DH) and 403B9E1E (DL) with the high and low addresses of the destination radio. You can look up the high (ATDH) and low
(ATDL) portions of the serial number using X-CTU, as shown in Figure 14-5.
---------------------------------------------------
The second sentence is really confusing. I don't see how the high and low parts of the serial number fits with the preceding sentence in which the high and low addresses are discussed. Do we use the high and low parts of the destination device's serial number as the high and low parts of its address, or do we use this information to look up the corresponding DH and DL parts of its address?

Ditto about the figure caption.

Note from the Author or Editor:
Thank you, and I apologize for the lack of clarity. I will change the paragraph to read:

In your code, you must replace 0013A200 (DH) and 403B9E1E (DL) with the high and low addresses of the destination radio. You can look up the high (ATDH) and low (ATDL) portions of the serial number by connecting to the destination radio using X-CTU, as shown in Figure 14-5: in the code, use the destination radio's SH (Serial Number High) for DH and the destination radio's SL (Serial Number Low) for DL. The numbers are also printed on the label underneath the XBee. (For a Series 1 XBee use 0 for the DH, and for the DL use the MY address of the XBee you want to talk to.)

Page 550, the very first sentence.
-------------------------------

This sketch uses the Arduino UDP (User Datagram Protocol) library to send and receive strings.
-------------------------------
What is exactly the name of this library as it appears in the Library Manager? I cannot find either the Arduino UDP or UDP or EthernetUdp library in there.

Note from the Author or Editor:
Hi, this is built in to the Ethernet library. Please see https://www.arduino.cc/en/reference/ethernet. I will change this to read:

This sketch uses the EthernetUDP (UDP=User Datagram Protocol) library, which is bundled with the built-in Ethernet library, to send and receive strings. Similar libraries are bundled with the WiFiNINA (WiFiUDP) and ESP8266WiFi (WiFiUdp; note the case difference).

Page 552, Section Discussion, this sentence:
----------------------------------------------------------
String length is limited by a constant set in the EthernetUdp.h library file; the default value is 24 bytes, but you can increase this by editing the following line in Udp.h if you want to send longer strings:
--------------------------------------------------------------
Do we indeed edit the Udp.h file, or, pethaps, the EthernetUdp.h file?

Note from the Author or Editor:
As it turns out, these instructions are completely incorrect. Sorry about that; the example will be updated to use a local variable instead. See https://github.com/arduino-libraries/Ethernet/issues/109 for an explanation of the issue. As it turns out, the #define appears in Ethernet.h, not EthernetUdp.h. But it is not used anywhere in the library, only in the example that comes with the Ethernet library.

Page 553, code, function setup(), second line:
--------------------------------

void setup() {
Ethernet.begin(mac,ip); ------------------ this one
Udp.begin(localPort);
----------------------------------
Does not compile. The compiler says:

'ip' was not declared in this scope

Note from the Author or Editor:
Apologies for this error and thank you. The ip argument was included in error. It should just be Ethernet.begin(mac) so that it can retrieve an IP address from the DHCP server. This will be corrected.

Page 554, the code, these two lines:
--------------------------------------------

packetBuffer[index++] = lowByte(value); // the low byte);
packetBuffer[index++] = highByte(value); // the high byte); }

----------------------------------------
I don't believe those closing brackets and semicolons are needed there. Most definitely, not the closing curly bracket.
Although they will not affect the compilation, they do insert confusion.

Note from the Author or Editor:
Thank you for catching this error. This was indeed a mistake. There were a number of fundamental issues with this example that I noticed thanks to your error report (0-values in the array would cause Processing to assume it reached the end of the message, among others). I have simplified this to map the 10-bit values to 8-bit bytes and send those to Processing. Since the Processing sketch was coded to handle them as 8-bit values anyhow, there was no loss of data. See https://github.com/bjepson/Arduino-Cookbook-3ed-INO/tree/master/ch15/ch15_udp_analog and https://github.com/bjepson/Arduino-Cookbook-3ed-PDE/tree/master/ch15/ch15_udp_analog

Page 556, code, function Boolean over(),
---------------------------------------

Boolean over()
{
if (mouseX > xpos && mouseX < xpos+swidth &&
mouseY > ypos && mouseY < ypos+sheight)
mouseY > ypos && mouseY < ypos+sheight) --- this one
mouseY > ypos && mouseY < ypos+sheight)
-------------------------------------------------
Compiler says there is an error in it, suggesting it's in the second ypos+sheight) line:

expecting SEMI, found ')'
Syntax error, maybe a missing semicolon?

Note from the Author or Editor:
Thank you for reporting this error, and sorry about that. There should only be two lines here; the second one is duplicated twice, which leads to the error. It will be corrected in a future printing.

Page 612, code, this sentence:
--------------------------------------

Demonstrates use of UDP sendPacket and ReceivePacket
----------------------------------------------
What functions are these? I can find no such functions in this code

Note from the Author or Editor:
Thank you for your correction. The description was incorrect and will be changed to "Demonstrates use of UDP to communicate with an NTP server"

Page 624, the first paragraph, this sentence (and other similar occurrences):
-----------------------------------
This folder needs to be put inside a folder called libraries inside your Arduino document folder.
--------------------------
The "document folder" part. In this case, it can be figured out from the context that the "document folder" is actually the sketch folder (yes, yes, a sketch IS a document, but so are many other types of, er, documents), which is by default called "Arduino". However, in other circumstances it can be confusing, especially when "documents" is used as the name of the folder, as in this sentence on page 627:
---------------------------------
You can increase this by modifying the library. Go to the libraries folder in your Arduino Documents folder.
---------------------------------------
Although it can be figured out from the following sentence that it's also actually the sketch folder, it might take longer, as one might be wondering if there is actually an Arduino folder named "Documents," whereas there is no such folder. At least as far as I know.

Note from the Author or Editor:
Thank you. This is a good point. We will update it to read Sketch folder.

Page 672, the paragraph before the "See Also" section, this sentence:
--------------------------------------------
The code stays in the while loop at the end of the inner block, so you need to reset the board when you want to do another run.
--------------------------------------
What while loop? There are no while loops in the code being discussed.

Note from the Author or Editor:
Thank you. That text was relevant in an earlier edition but is no longer correct. It will be removed.

Page 680, the paragraph above the code, this sentence:
-------------------------------------------------
Enter a digit from 1 to 7 using the value in the lefthand column of Table 18-2
-------------------------------------------------------
This is really confusing. First of all, there are no single digits in the table for Timer0. Second, in the tables for Timer1 and Timer 2, there are only digits from 1 to 5.

Also, I guess, the digit entered is chosen based on the desired frequency in the rightmost column.

Note from the Author or Editor:
Thank you. Yes, the table has a lot of errors. The leftmost column should contain 1-5 for TCCR0B and TCCR1B, but 1-7 for TCCR2B. Additionally, for TCCR0B, the frequencies should read 62500, 7812.5, 976.56, 244.14, 61.04. For TCCR1B they should read 31372.55, 3921.16, 490.2, 122.55, and 30.64. For TCCR2B, they should read 31372.55, 3921.16, 980.39 (with a divisor of 32), 490.2, 245.10 (divisor=128), 122.55, and 30.64. These will be corrected

Page 683, the paragraph above the raven. This sentence:
--------------------------------------------
The pulse generator also uses Timer1 (the only 16-bit timer on the Uno and other boards based on the ATmega328), so you can combine the functionality using a single board.
----------------------------------------------
The part "combine the functionality." What functionality can be combined and what can it be combined with?

Note from the Author or Editor:
Thanks for catching this. That sentence is problematic in a few ways. While it suggests that you could generate and interpret signals from the same board, that is really only of theoretic interest and doesn't have a practical value that I can discern. We'll remove the problematic part in the next printing.