Code words in text, database table names, folder names, filenames, file extensions, pathnames, dummy URLs and user input are shown as follows: "To get the preceding kernel messages, we can use both the dmesg and tail -f /var/log/kern.log commands."

A block of code is set as follows:

#include <stdio.h> 
 
int main(int argc, char *argv[]) 
{ 
    printf("Hello World!\n"); 
 
    return 0; 
} 

You should note that most code in this book has 4 spaces indentation while the example code you can find into the files provided with this book on Github or Packt site, has 8 spaces indentation. So the above code will look like as follow:

#include <stdio.h> 
 
int main(int argc, char *argv[]) 
{ 
        printf("Hello World!\n"); 
 
        return 0; 
}

Obviously they are perfectly equivalent!

Any command line input or output given on one of the embedded kits used in this book is written as follows:

root@bbb:~# make CFLAGS="-Wall -O2" helloworld


cc -Wall -O2 helloworld.c -o helloworld

Then by looking into the prompt string we can deduce which board we're currently using. I use the string bbb for the BeagleBone Black, a5d3 for the SAMA5D3 Xplained and wb for the WandBoard. However I use the generic string arm when I'm referring a generic embedded kit.

Note also that due space reasons into the book you may read very long commands lines as follows:

$ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- 
                sama5d3_xplained_nandflash_defconfig

Otherwise I have had to break the command line. However in some special cases you can find broken output lines (specially on kernel messages) as follow:

cdc_ether 2-1.1:1.0 usb0: register 'cdc_ether' at usb-0000:00:1d.0-1.1
, CDC Ethernet Device, 62:1e:f6:88:9b:42

Unluckily these lines cannot be easily reported into a printed book so you should consider them as a single line.

Any command line input or output given on my host computer as a non- privileged user is written as follows:

$ tail -f /var/log/kern.log

When I need to give a command as a privileged user (root) on my host computer the command line input or output is then written as follows:

# /etc/init.d/apache2 restart

You should notice that all privileged commands can be executed by a normal user too by using the sudo command with the form:

$ sudo <command>

So the preceding command can be executed by a normal user as:

$ sudo /etc/init.d/apache2 restart

On several GNU/Linux distribution a kernel message has the usual form:

Oct 27 10:41:56 hulk kernel: [46692.664196] usb 2-1.1: new high-speed USB device number 12 using ehci-pci

Which is a quite long line for this book, that's why the characters from the start of the lines till the point where the real information begin are dropped. So, in the preceding example, the lines output will be reported as follow:

usb 2-1.1: new high-speed USB device number 12 using ehci-pci

However, as just said above, if the line is still too long it will be broken anyway.

Long outputs, repeated or less important lines in a terminal are dropped by replacing them with three dots ... shown as follows:

output begin
output line 1
output line 2
...
output line 10
output end

When the three dots are at the end they mean that the output continues but I decided cut it for space reasons.

When you should modify a text file, I'm going to use the unified context diff format since this is a very efficient and compact way to represent a text modification. This format can be obtained by using the diff command with the -u option argument.

As a simple example, let's consider the following text into file1.old:

This is first line 
This is the second line 
This is the third line 
... 
... 
This is the last line 

Suppose we have to modify the third line as highlighted in the following snippet:

This is first line 
This is the second line 
This is the new third line modified by me 
... 
... 
This is the last line 

You can easily understand that reporting each time the whole file for a simple modification it's quite obscure and space consuming, however by using the unified context diff format the preceding modification can be written as follow:

$ diff -u file1.old file1.new 
--- file1.old 2015-03-23 14:49:04.354377460 +0100 
+++ file1.new 2015-03-23 14:51:57.450373836 +0100 
@@ -1,6 +1,6 @@ 
 This is first line 
 This is the second line 
-This is the third line 
+This is the new third line modified by me 
 ... 
 ... 
 This is the last line 

Now the modification is very clear and written in a compact form! It starts with a two-line header where the original file is preceded by --- and the new file is preceded by +++, then follows one or more change hunks that contain the line differences in the file. The preceding example has just one hunk where the unchanged lines are preceded by a space character, while the lines to be added are preceded by a + character and the lines to be removed are preceded by a - character.

Still for space reasons, most patches reported into this book has reduced indentation in order to fit printed pages width, however they are still perfectly readable in a correct form. For the real patch you should refer to the provided files on Github or Packt site.

In this book I'm going to mainly use two different kind of connections to interact with the the embedded boards: the serial console, an SSH terminal and an Ethernet connection.

The serial console, that is implemented over the same USB connection used to power up the board, is mainly used to manage the system from the command line. It's largely used to monitoring the system especially to take under control the kernel messages.

An SSH terminal is quite similar to the serial console even if is not exactly the same (for example kernel messages do not automatically appear on a terminal) but it can be used in the same manner as a serial console to give commands and to edit files from the command line.

In the next chapters I'm going to use a terminal on the serial console or over an SSH connection indifferently to give the most of the commands and configuration settings needed to implement all the prototypes explained in this book.

To get access to the serial console from your host PC you can use the minicon command as follow:

$ minicom -o -D /dev/ttyACM0

Or the next one according to the board and/or the USB-to-Serial adapter used:

$ minicom -o -D /dev/ttyUSB0

However in Chapter 1 , Installing the Developing System, this aspects are explained and you should not worry about them. Note also that on some system you may needs the root privileges to get access to the /dev/ttyACM0 device. In this case you can fix this issue or by using the sudo command or, better, by properly add you system's user to the right group by using the command below:

$ sudo adduser $LOGNAME dialout

Then log out and log in again and you should access the serial devices without any problem.

To get access to the SSH terminal you can use the emulated Ethernet connection over the same USB cable used for the serial console. In fact, if your host PC is well configured, when you plug in the USB cable, after a while, you should see a new cable connection with a proper IP address (in case of the BeagleBone Black you should get the address 192.168.7.1, for the SAMA5D3 Xplained the address 192.168.8.1, while address 192.168.9.1 for the WandBoard. See Chapter 1 , Installing the Developing System ). Then, for example, I can use this new connection to get access to the BeagleBone Black by using the following command:

$ ssh [email protected]

The last available communication channel is the Ethernet connection. It is used mainly to download files from the host PC or the Internet and it can be established by connecting an Ethernet cable to the each embedded kit's Ethernet port and then configuring the port accordingly to the reader's LAN settings.

But it's quite important to point out the you can get connected with the Internet by using also the emulated Ethernet connection over USB presented above. In fact, by using the commands below on the host PC (obviously GNU/Linux based), you'll be able to use it as a router allowing your embedded boards to surf the net as it was connected with its real Ethernet port:

# iptables --table nat --append POSTROUTING --out-interface eth1
                       -j MASQUERADE
# iptables --append FORWARD --in-interface eth4 -j ACCEPT
# echo 1 >> /proc/sys/net/ipv4/ip_forward

Then, for instance, on the BeagleBone Black I should set the gateway through the USB cable using the following command:

root@bbb:~# route add default gw 192.168.7.1

Note that the eth1 device is the preferred Internet connection on my host system, while the eth4 device is the BeagleBone Black's device as viewed on my system.

New terms and important words are shown in bold. Words that you see on the screen, for example, in menus or dialog boxes, appear in the text like this: "Clicking the Next button moves you to the next screen."