The major differences between threads and processes are:

Threads share the address space of the process that created it; processes have their own address space.
Threads have direct access to the data segment of its process; processes have their own copy of the data segment of the parent process.
Threads can directly communicate with other threads of its process; processes must use interprocess communication to communicate with sibling processes.
Threads have almost no overhead; processes have considerable overhead.
New threads are easily created; new processes require duplication of the parent process.
Threads can exercise considerable control over threads of the same process; processes can only exercise control over child processes.
Changes to the main thread (cancellation, priority change, etc.) may affect the behavior of the other threads of the process; changes to the parent process do not affect child processes.

The proper use of C’s volatile keyword is poorly understood by many programmers. This is not surprising, as most C texts dismiss it in a sentence or two. This article will teach you the proper way to do it.

Have you experienced any of the following in your C or C++ embedded code?

Code that works fine–until you enable compiler optimizations
Code that works fine–until interrupts are enabled
Flaky hardware drivers
RTOS tasks that work fine in isolation–until some other task is spawned
If you answered yes to any of the above, it’s likely that you didn’t use the C keyword volatile. You aren’t alone. The use of volatile is poorly understood by many programmers. Unfortunately, most books about the C programming language dismiss volatile in a sentence or two.

C’s volatile keyword is a qualifier that is applied to a variable when it is declared. It tells the compiler that the value of the variable may change at any time–without any action being taken by the code the compiler finds nearby. The implications of this are quite serious. However, before we examine them, let’s take a look at the syntax.

Syntax of C’s volatile Keyword

To declare a variable volatile, include the keyword volatile before or after the data type in the variable definition. For instance both of these declarations will declare foo to be a volatile integer:

volatile int foo;
int volatile foo;
Now, it turns out that pointers to volatile variables are very common, especially with memory-mapped I/O registers. Both of these declarations declare pReg to be a pointer to a volatile unsigned 8-bit integer:

volatile uint8_t * pReg;
uint8_t volatile * pReg;
Volatile pointers to non-volatile data are very rare (I think I’ve used them once), but I’d better go ahead and give you the syntax:

int * volatile p;
And just for completeness, if you really must have a volatile pointer to a volatile variable, you’d write:

int volatile * volatile p;
Incidentally, for a great explanation of why you have a choice of where to place volatile and why you should place it after the data type (for example, int volatile * foo), read Dan Sak’s column “Top-Level cv-Qualifiers in Function Parameters” (Embedded Systems Programming, February 2000, p. 63).

Finally, if you apply volatile to a struct or union, the entire contents of the struct/union are volatile. If you don’t want this behavior, you can apply the volatile qualifier to the individual members of the struct/union.

Proper Use of C’s volatile Keyword

A variable should be declared volatile whenever its value could change unexpectedly. In practice, only three types of variables could change:

1. Memory-mapped peripheral registers

2. Global variables modified by an interrupt service routine

3. Global variables accessed by multiple tasks within a multi-threaded application

We’ll talk about each of these cases in the sections that follow.

Peripheral Registers

Embedded systems contain real hardware, usually with sophisticated peripherals. These peripherals contain registers whose values may change asynchronously to the program flow. As a very simple example, consider an 8-bit status register that is memory mapped at address 0×1234. It is required that you poll the status register until it becomes non-zero. The naive and incorrect implementation is as follows:

uint8_t * pReg = (uint8_t *) 0×1234;

// Wait for register to become non-zero
while (*pReg == 0) { } // Do something else
This will almost certainly fail as soon as you turn compiler optimization on, since the compiler will generate assembly language that looks something like this:

mov ptr, #0×1234 mov a, @ptr

loop:
bz loop
The rationale of the optimizer is quite simple: having already read the variable’s value into the accumulator (on the second line of assembly), there is no need to reread it, since the value will always be the same. Thus, in the third line, we end up with an infinite loop. To force the compiler to do what we want, we modify the declaration to:

uint8_t volatile * pReg = (uint8_t volatile *) 0×1234;
The assembly language now looks like this:

mov ptr, #0×1234

loop:
mov a, @ptr
bz loop
The desired behavior is achieved.

Subtler problems tend to arise with registers that have special properties. For instance, a lot of peripherals contain registers that are cleared simply by reading them. Extra (or fewer) reads than you are intending can cause quite unexpected results in these cases.

Interrupt Service Routines

Interrupt service routines often set variables that are tested in mainline code. For example, a serial port interrupt may test each received character to see if it is an ETX character (presumably signifying the end of a message). If the character is an ETX, the ISR might set a global flag. An incorrect implementation of this might be:

int etx_rcvd = FALSE;

void main()
{
…
while (!ext_rcvd)
{
// Wait
}
…
}

interrupt void rx_isr(void)
{
…
if (ETX == rx_char)
{
etx_rcvd = TRUE;
}
…
}
With compiler optimization turned off, this code might work. However, any half decent optimizer will “break” the code. The problem is that the compiler has no idea that etx_rcvd can be changed within an ISR. As far as the compiler is concerned, the expression !ext_rcvd is always true, and, therefore, you can never exit the while loop. Consequently, all the code after the while loop may simply be removed by the optimizer. If you are lucky, your compiler will warn you about this. If you are unlucky (or you haven’t yet learned to take compiler warnings seriously), your code will fail miserably. Naturally, the blame will be placed on a “lousy optimizer.”

The solution is to declare the variable etx_rcvd to be volatile. Then all of your problems (well, some of them anyway) will disappear.

Multithreaded Applications

Despite the presence of queues, pipes, and other scheduler-aware communications mechanisms in real-time operating systems, it is still fairly common for two tasks to exchange information via a shared memory location (that is, a global). Even as you add a preemptive scheduler to your code, your compiler has no idea what a context switch is or when one might occur. Thus, another task modifying a shared global is conceptually identical to the problem of interrupt service routines discussed previously. So all shared global variables should be declared volatile. For example, this is asking for trouble:

int cntr;

void task1(void)
{
cntr = 0;

while (cntr == 0)
{
sleep(1);
}
…
}

void task2(void)
{
…
cntr++;
sleep(10);
…
}
This code will likely fail once the compiler’s optimizer is enabled. Declaring cntr to be volatile is the proper way to solve the problem

GDB is an essential tool for programmers to debug their code.
Breakpoints are the way to tell GDB to stop or pause the program execution at certain line, or function, or address. Once the program is stopped you can examine and change the variable values, continue the program execution from that breakpoint, etc.
Similar to breakpoints, backtrace is also helpful during debugging process to view and navigate the stack frame as explained in this tutorial

This tutorial requires some basic understanding of stack frame that we discussed in our memory layout of a process article.
C Code Example for GDB Backtrace
The following C program code example will be used in this tutorial to explain GDB backtrace.

#include
void func1();
void func2();
int main() {
int i=10;
func1();
printf(“In Main(): %d\n”,i);
}
void func1() {
int n=20;
printf(“In func1(): %d\n”,n);
func2();
}
void func2() {
int n = 30;
printf(“In func2() : %d\n”,n);
}
# cc -g stack.c

In a above code, main() will call func1() which inturn calls func2(). We will show how to examine the stack at each stage.
Getting a Backtrace in GDB
In this example, we had set a breakpoint at line number 20. So, the code stopped at func2() line 20 when we use gdb.
You can get the backtrace using ‘bt’ command as shown below.

# gdb
(gdb) file ./a.out
Reading symbols from /home/lakshmanan/a.out…done.
(gdb) b 20
Breakpoint 1 at 0×400579: file stack.c, line 20.
(gdb) run
Starting program: /home/lakshmanan/./a.out
In func1(): 20
Breakpoint 1, func2 () at stack.c:20
20 printf(“In func2() : %d\n”,n);
We already discussed how we can use GDB breakpoints to pause and continue a program execution from a particular point for debugging purpose.
From the output below, we know that currently we are in func2(), which is called by func1(), which was inturn called by main().

(gdb) bt
#0 func2 () at stack.c:20
#1 0×0000000000400568 in func1 () at stack.c:15
#2 0×0000000000400525 in main () at stack.c:9

Moving from one Frame to Another
You can move between the stack frames using ‘frame [number]’ as shown below.
In the below snippet, still the func2() is not returned, but we are able to move to frame 1 (which is func1) and examine the variable n’s value which is present inside func1().

(gdb) bt
#0 func2 () at stack.c:20
#1 0×0000000000400568 in func1 () at stack.c:15
#2 0×0000000000400525 in main () at stack.c:9
(gdb) p n
$1 = 30
(gdb) frame 1
#1 0×0000000000400568 in func1 () at stack.c:15
15 func2();
(gdb) p n
$2 = 20
In the snippet below, we have executed the next 2 instructions using ‘n 2’, and func2 is returned.
Now ‘bt’ tells you that you are currently in func1() which is called from main(), and the stack frame for func2 is gone.

(gdb) n 2
In func2() : 30
func1 () at stack.c:16
16 }
(gdb) bt
#0 func1 () at stack.c:16
#1 0×0000000000400525 in main () at stack.c:9
Get Information about a Stack Frame
You can get the information about a particular frame using ‘info frame [number]’ as shown below.

(gdb) info frame 0
Stack frame at 0x7fffffffe150:
rip = 0×400568 in func1 (stack.c:16); saved rip 0×400525
called by frame at 0x7fffffffe170
source language c.
Arglist at 0x7fffffffe140, args:
Locals at 0x7fffffffe140, Previous frame’s sp is 0x7fffffffe150
Saved registers:
rbp at 0x7fffffffe140, rip at 0x7fffffffe148

IPC allows to coordinate among the different processes that are running in an operating system simultaneously. There are various IPC techniques viz. PIPE, FIFO, Shared memory, Message Queue,Threads etc.

Difference between two IPC techniques i.e, Pipe and FIFO

1) Pipe uses the internal data structure for communication between processes(it does not exists physically). But FIFO is physically present in our directory.
2) Pipe can be accessed through file descriptor which it returns while using pipe system call,But FIFO having name so, we can access and load it in to memory using its file name.
3) Pipe can be accessed to the related process only(parent -child process). But FIFO can access unrelated processes too.
4) While reading the pipe, its writing end should be closed and reverse also bears the same but in case of FIFO as many process can access the same file at a time.
5) Pipe is transient in nature i.e, it exists till the process is running but FIFO exists until one deletes it from the file system.
6) As FIFO is a file so any time we can change the file properties but it is not same as in case of pipe.

The msgget() system call returns the System message queue identifier associated with the value of the key argument. A new message queue is created if key has the value  IPC_PRIVATE or key isn’t IPC_PRIVATE, no message queue with the given key exists, and  IPC_CREAT is specified in msgflg. If msgflg specifies both IPC_CREAT and IPC_EXCL and a message queue already exists for key, then msgget() fails with errno set to EEXIST. This is analogous to the effect of the combination O_CREAT | O_EXCL for open.

These header files are used:

• #include <sys/types.h>
• #include <sys/ipc.h>
• #include <sys/msg.h>

Syntax: int msgget(key_t key, int msgflg);

RETURN VALUE: If successful, the return value will be the message queue identifier (a nonnegative integer), otherwise -1 with errno indicating the error.

ERRORS: On failure, errno is set to one of the following values which are given below:

• EACCES: A message queue exists for key, but the calling process does not have  permission  to  access  the  queue,  and does not have the CAP_IPC_OWNER capability.
• EEXIST: A message  queue  exists  for  key  and  msgflg  specified  both IPC_CREAT and IPC_EXCL.
• ENOENT: No  message  queue  exists  for  key  and msgflg did not specify IPC_CREAT.
• ENOMEM: A message queue has to be created but the system does  not  have enough memory for the new data structure.
• ENOSPC: A  message  queue has to be created but the system limit for the maximum number of message queues (MSGMNI) would be exceeded.

DESCRIPTION

These functions return information about a file. No permissions are required on the file itself, but — in the case of stat() and lstat() — execute (search) permission is required on all of the directories in path that lead to the file.

stat() stats the file pointed to by path and fills in buf.

lstat() is identical to stat(), except that if path is a symbolic link, then the link itself is stat-ed, not the file that it refers to.

fstat() is identical to stat(), except that the file to be stat-ed is specified by the file descriptor filedes.

All of these system calls return a stat structure, which contains the following fields:

struct stat {
    dev_t     st_dev;     /* ID of device containing file */
    ino_t     st_ino;     /* inode number */
    mode_t    st_mode;    /* protection */
    nlink_t   st_nlink;   /* number of hard links */
    uid_t     st_uid;     /* user ID of owner */
    gid_t     st_gid;     /* group ID of owner */
    dev_t     st_rdev;    /* device ID (if special file) */
    off_t     st_size;    /* total size, in bytes */
    blksize_t st_blksize; /* blocksize for filesystem I/O */
    blkcnt_t  st_blocks;  /* number of blocks allocated */
    time_t    st_atime;   /* time of last access */
    time_t    st_mtime;   /* time of last modification */
    time_t    st_ctime;   /* time of last status change */
};

The st_dev field describes the device on which this file resides.

The st_rdev field describes the device that this file (inode) represents.

The st_size field gives the size of the file (if it is a regular file or a symbolic link) in bytes. The size of a symlink is the length of the pathname it contains, without a trailing null byte.

The st_blocks field indicates the number of blocks allocated to the file, 512-byte units. (This may be smaller than st_size/512, for example, when the file has holes.)

The st_blksize field gives the “preferred” blocksize for efficient file system I/O. (Writing to a file in smaller chunks may cause an inefficient read-modify-rewrite.)

Not all of the Linux files systems implement all of the time fields. Some file system types allow mounting in such a way that file accesses do not cause an update of the st_atime field.

The field st_atime is changed by file accesses, e.g. by execve(2), mknod(2), pipe(2), utime(2) and read(2) (of more than zero bytes). Other routines, like mmap(2), may or may not update st_atime.

The field st_mtime is changed by file modifications, e.g. by mknod(2), truncate(2), utime(2) and write(2) (of more than zero bytes). Moreover, st_mtime of a directory is changed by the creation or deletion of files in that directory. The st_mtime field is not changed for changes in owner, group, hard link count, or mode.

The field st_ctime is changed by writing or by setting inode information (i.e., owner, group, link count, mode, etc.).

NOTE : Use stdio.h header file

solution 1:

#include
void main()
{
if(printf(“Hello World”))
{
}
}

solution 2:

#include
void main()
{
while(!printf(“Hello World”))
{
}
}

solution 3:

#include
void main()
{
switch(printf(“Hello World”))
{
}
}

 Embedded Systems and IOT

With billions of devices expected to join the IoT over the next several years, analysts expect organizations to continue this migration away from the legacy static languages that have been traditionally used. This steady integration into the IoT will have significant impact on device design (Figure 1).

why the floating point number initialising with f in postfix……….

e.g.

if we take two floating point number

f1 = 0.5f;

f2 = 0.3f;

and if we print, then two different result

if( f1 == 0.5f )

{

printf(“f1 = %f\n”,f1);

printf(“True”);

}

else

printf(“False”);

//case 2

if( f2 == 0.3f )

{

printf(“f2 = %f\n”,f2);

printf(“True”);

}

else

printf(“False”);

the above two if case give two different result…….

understand if no just wait for next  ……

Partitioning in hard disk is  of two types:

a) MBR

b) GPT

MBR refers to master boot record and is knowledge of the first sector of any hard disk that identifies how and where an operating system is located so that it can be boot (loaded) into the computer’s main storage or random access memory.

GPT refers to GUID Partition Table  is a standard for the layout of the partition table on a physical storage device used in a desktop or server PC, such as a hard disk drive or solid-state drive, using globally unique identifiers (GUID).

GPTs use logical blocking address (LBA) in place of the historical cylinder-head-sector (CHS) addressing. In a GPT, the first sector of the disk is reserved for a “protective MBR” such that booting a BIOS-based computer from a GPT disk is supported, but the bootloader and operating system must both be GPT-aware. Regardless of the sector size, the GPT header begins on the second logical block of the device

Head mounted display is one of the new gadget that has taken the electronic market with a surprise .A head-mounted display (or helmet-mounted display, for aviation applications), both abbreviated HMD, is a display device, worn on the head or as part of a helmet, that has a small display optic in front of one (monocular HMD) or each eye (binocular HMD).

for eg : samsung VR headset ,oculus VR , google cardbox.

To install GCC on Windows, you need to install MinGW. To install MinGW, go to the MinGW
homepage, www.mingw.org, and follow the link to the MinGW download page. Download
the latest version of the MinGW installation program, which should be named MinGW-
<version>.exe.
While installing MinWG, at a minimum, you must install gcc-core, gcc-g++, binutils, and
the MinGW runtime, but you may wish to install more.
Add the bin subdirectory of your MinGW installation to your PATH environment variable,
so that you can specify these tools on the command line by their simple names.
When the installation is complete, you will be able to run gcc, g++.

We can create threads using this function:

int pthread_create(pthread_t *thread, pthread_attr_t *attr,
void*(*start_routine)(void *),
void *arg);

*thread is a pointer to new thread, it points to a location where id of new thread will be written when the thread will be created. From now on, this thread id will be used for referring to new thread.