ISO 9001:2015 Certified

Embedded Systems Courses in bangalore, best embedded systems training course in bangalore, embedded training institutes in bangalore, Best Embedded Systems Training Institutes in Bangalore, embedded systems training in bangalore, embedded systems course fees in bangalore, embedded coaching centera.

What is an Embedded System?

An Embedded system is a combination of computer software and hardware which is either fixed in capability or programmable.An embedded system can be either an independent system, or it can be a part of a large system. It is mostly designed for a specific function or functions within a larger system. For example, a fire alarm is a common example of an embedded system which can sense only smoke.

History of Embedded system

Here, are important milestones from the history of Embedded system

In 1960, Embedded system was first used for developing Apollo Guidance System by Charles Stark Draper at MIT.
In 1965, Autonetics, developed the D-17B, the computer used in the Minuteman missile guidance system.
In 1968, the first Embedded system for a vehicle was released.
Texas Instruments developed the first microcontroller in 1971.
In 1987, the first Embedded OS, VxWorks, was released by Wind River.
Microsoft's Windows Embedded CE in 1996. By the late 1990s, the first Embedded Linux system appeared.
The Embedded market reach $140 billion in 2013.
Analysts are projecting an Embedded market larger than $40 billion by 2030.


Career Opportunities In Embedded Systems

No doubt starting packages are not much high but once you gain experience of 3-4 years, you will get handsome packages.
And experienced embedded system developers has very high demand in India.


Why Linux??

Microprocessor industry advances, forms the foundation for using Linux as an embedded OS.
Developers always wants the latest and greatest hardware and software for their new embedded designs while also requiring high reliability.
Desktop OS provides the latest in software but lack of reliability and require more memory and CPU resources.
Real-time OS (RTOS) vendors offer reliability but struggle with software development in the ever-changing world technology
Open source: entire kernel source available free.
Portable from mainframe to hand-helds Devices.


Linux Kernel Versioning??

Find it by Using Command uname -r or uname -a.
For Example-:Using w.x.y-zz and looking at the fourth file listed /boot/vmlinuz-4.4.0-45 we can say:
w = Kernel Version = 4
x= Major Revision = 4
y = Minor Revision = 0
zz=Patch number = 45


Definition of Kernel

A monolithic kernel:- all services (file system, VFS, device drivers, etc) as well as core functionality (scheduling, memory allocation, etc.) are a tight knit group sharing the same space. This directly opposes a microkernel.
Suitable for Desktop (UNIX, MS-Windows).
Less run time overhead.
Less extensibility.


monolithic kernel:-Some of the essential services like address space management, Timer and IPCs reside in the kernel space.
Suitable for Embedded (RTOS).
Run time overhead.
Highly extensible.


What are Device Drivers..??

A specific piece of hardware could be controlled by a piece of software (a device driver), or could be controlled by another hardware device, which in turn could be managed by a software device driver. In the latter case, such a controlling device is commonly called a device controller.
In short, a device driver has two parts: i) Device-specific
and ii) OS-specific.


The device-specific portion of a device driver remains same across all operating systems, and is more of understanding and decoding of the device data sheets, than of software programming.


In Linux, a device driver provides a system call interface to the user. And, this is the boundary line between the so-called kernel space and user space of Linux. Based on the OS-specific interface of a driver, in Linux a driver is broadly classified into 3 verticals:
1.Packet-oriented or Network vertical.
2.Block-oriented or Storage vertical.
3.Byte-oriented or Character vertical.


Linux Kernel Makefile??

1.Overview and Definition
The Makefiles have five parts:
Makefile ----------------the top Makefile.
.config -----------------the kernel configuration file.
arch/$(ARCH)/Makefile ---the arch Makefile.
scripts/Makefile.* ----common rules etc. for all kbuild Makefiles.
kbuild Makefiles -----there are about 500 of these.


The top Makefile reads the .config file, which comes from the kernel configuration process.
The top Makefile is responsible for building two major products: vmlinux(the resident kernel image) and modules (any module files).
It builds these goals by recursively descending into the subdirectories of the kernel source tree.
The list of subdirectories which are visited depends upon the kernel configuration.
The top Makefile textually includes an arch Makefile with the name arch/$(ARCH)/Makefile. The arch Makefile supplies architecture-specific information to the top Makefile.
Each subdirectory has a kbuild Makefile which carries out the commands passed down from above.
The kbuild Makefile uses information from the .config file to construct various file lists used by kbuild to build any built-in or modular targets.
scripts/Makefile.* contains all the definitions/rules etc. that are used to build the kernel based on the kbuild makefiles.


2. The kbuild files
The most simple kbuild makefile contains one line:
obj-y += foo.o
This tells kbuild that there is one object in that directory, named foo.o. foo.o will be built from foo.c or foo.S.
If foo.o shall be built as a module, the variable obj-m is used.
Therefore the following pattern is often used:
obj-$(CONFIG_FOO) += foo.o
$(CONFIG_FOO) evaluates to either y (for built-in) or m (for module).If CONFIG_FOO is neither y nor m, then the file will not be compiled nor linked.


What Linux kernel porting

Linux kernel porting involves two things at a higher level: architecture porting and board porting.Architecture, in Linux terminology, refers to CPU. So, architecture porting means adapting the Linux kernel to the target CPU, which may be ARM, Power PC, MIPS, and so on. In addition to this, SOC porting can also be considered as part of architecture porting. As far as the Linux kernel is concerned, most of the times, you don’t need to port it for architecture as this would already be supported in Linux. However, you still need to port Linux for the board and this is where the major focus lies. Architecture porting entails porting of initial start-up code, interrupt service routines, dispatcher routine, timer routine, memory management, and so on. Whereas board porting involves writing custom drivers and initialisation code for devices specific to the board.


1. Downloading and Building the Kernel
Below are the steps for the same:
Download the kernel source code linux-xx.yy.zz.tar.bz2.
untar it with 'tar -jxvf linux-linux-xx.yy.zz.tar.bz2.
Configure the kernel with below steps:
+ Copy the new config as .config in kernel top level directory.
+ make ARCH=arm menuconfig
Compile the kernel with make ARCH=arm CROSS_COMPILE= zImage
This will give you the zImage at linux-xx.yy.zz/arch/arm/boot/
Transfer this is to the board and reboot to boot with new kernel image.


2. Building the device driver as a part of Kernel (in tree building)
a)) In linux, drivers can be compiled in two ways - either as part of the kernel or as modules so that they can be plugged dynamically into the kernel. Here, we will build the driver as the part of the kernel, so that it is loaded during boot up.
b))We will add a small driver to the kernel. Below are the steps:
- Copy the file char_driver.c to linux-linux-xx.yy.zz/drivers/char/.
- Edit the Kconfig file in drivers/char/ and add the following:
Given below is the segment of code
added in drivers/char/Kconfig:
+tristate "Demo for HELLO Driver"
+default m
+Adding this driver to kernel for demonstrating the kbuild


- This will show up as Hello Driver in menuconfig which you can either build as part of kernel, or as a module.
- Edit the makefile to add the following entry:
obj-$(CONFIG_HELLO_DRIVER) += char_driver.o
This will boil down to either obj-y, obj-m or obj-n, depending on the option selected in menuconfig. - In char_driver.c, put some message in init() function and that message will be displayed during kernel booting.
- Once, the modifications are done, configure the kernel with make ARCH=arm menuconfig. Under the device drivers-> Character devices, there will be a option hello driver, just select it. Exit & save the config. - This will add the CONFIG_HELLO_DRIVER=y in the .config file which will be used in Makefile.
- Now, compile the kernel with make ARCH=arm CROSS_COMPILE=- zImage
- Boot the board with above Image and you should see the message which you added in init() function.
+ To test the Device Driver with Application Program and run it on the board.


3. Compiling the Device Driver Code outside of kernel(out tree building)
Now, intention is to build the kernel module using the kernel source code.
Below are the steps:
+ Open the Makefile & update the 'KERNEL_SOURCE' variable with the path of kernel directory.
+ Update the 'CROSS_COMPILE' with your toolchain prefix say 'arm-linux-'.
+ Execute 'make' and this should generate the .ko file. Transfer this to the board using tftp or scp.
+ Once transferred, insert the module with 'insmod '.