Workshop on Embedded System and RTOS

Topics to be covered Duration: 25 Hrs

Embedded System Design: An Introduction
• Definition of Embedded Systems
• Real Time Embedded System
• Challenge and Trends in ES
• Designing issues in ES
• Tools
Microcontrollers & their Architecture
• I/O Ports.
• Interrupts.
• Timer/Counter.
• Communication Protocols (UART, SPI, I2C).
• ADC/DAC.
• CAN
• RTC
• Emerging Bus Standards(USB, Compact PCI)
• 8051 Microcontroller bock diagram, Instruction set and Assembly Programming
• Introduction to AVR and ARM Microcontroller
Introduction to Embedded C Programming
• Embedded C-Programming for Microcontroller.
• Introduction to C, Flow control statements, functions.
• Data Types, operators and expressions.
• Program structures.
• Program Burning and Execution.
Interfacing of peripherals to Microcontrollers
This session will be focusing on interfacing various devices to the micro controller.
• Actuators.
• Geared DC Motor.
• Stepper Motor.
This session includes detailed discussion of various types of Actuators followed by hand session on controlling the motion of Geared DC motor and techniques for precise position control using Stepper motor.
• Motor Driver.
• Relays.
• Solid State Drivers.
• Integrated Circuit drivers.
Discussion of various motor drivers available and their practical implementation.
• Displays.
• LED.
• LCD.
• 7-seg displays.
Interfacing of various Display devices with microcontroller.
• Input Devices.
• Switches.
• Matrix Keyboard.
Interfacing different human interface devices in various configurations with the microcontroller.
• Sensors.
• Temperature Sensors.
• Light Sensors.
Study and practical use of Sensors to enable microcontroller to acquire environmental data.
• Real Time Clock.
Introduction to concepts of RTOS
• Need for RTOS.
• Features of RTOS.
• Popular RTOSes.
Project Building (With Hardware Kit)
• Description
• Exploring.
• Designing.
• Programming and Implementation.

Testing a DB-9 RS-232 serial port in HyperTerminal

This procedure explains how to troubleshoot a COM card using Hyperterminal.
Before testing your serial ports, you must first hook up a loopback.

A loopback connects the output signal (TxD) to the input signal (RxD) in a single serial port connector to make it seem like there are two ports connected together.

Making a loopback
Step Procedure Description
Step 1-Turn off the computer
.
Step 2-Connect RxD (pin 2) and TxD (pin 3) of the serial port.
Use a loop-back connector if available, or any kind of conductive wire, even a paper clip
.
Step 3-Turn on the computer. You are now ready to test the port.
Figure 24 - RS-232 DB-9 connector
Running Hyperterminal
Step Procedure Description

Step 1-Launch HyperTerminal. In Windows,

select Programs/Accessories/ Communications/ HyperTerminal.

Step 2-Create a new session. When prompted, give the session any name you wish.

Step 3-Select the COM # associated with your You are now set up to test the port.
port from the drop down list.
Note: Leave all settings at default.

Figure 24 illustrates the jumper location for a loopback on a
RS-232 DB-9 connector.
Install a wire jumper to connect the following signals:
RxD (pin 2) to TxD (pin 3)
Step Procedure Description

Step 4-With the session open, type any text. If the text you type is echoed on the
screen, the port is functioning properly.

Step 5-Close the session.

Step 6-Repeat all above steps to test additional You will first need to connect the Loopback
ports. on the other ports using the steps above

IIT-K to launch India's lightest nano satellite 'Jugnu'

Kanpur: The Indian Institute of Technology (IIT), Kanpur has come in to agreement with the Indian Space Research Organization (ISRO) to launch a nano satellite. It will be the country's lightest and the institute's first satellite to be launched in the orbit from Sriharikota.

IIT Kanpur had presented the second design review to ISRO which nodded to launch the satellite.


"Though the memorandum of understanding between ISRO and IIT-K for the project was signed in February, regular review sessions are being carried out by ISRO to check the progress of the project," said Sanjay Govind Dhande, Director, IIT Kanpur.


"On Tuesday, our technical team working on the project apprised ISRO authorities of the release and antenna mechanism," he said.In April, the first review of Jugnu was carried out by ISRO.


Since last December, a team of 40 students and around 12 professors, led by Professor and Mechanical Engineering Department Head, Nalinaksh S Vyas have been working on the project.


"A similar project in any European country would have cost over Rs 10 crore but we expect the entire project to complete within a budget of Rs 2-3 crore, without compromising on quality. This is a welcome signal for indigenous remote sensing technologies," said Vyas.


A technical team led by D Madhav Murthy in the ISRO for Small Satellite, has said that the procedures for informing the ISRO officials for launch by a mother satellite has been provided, along with the details of the positioning of the satellite antenna set up in the institute premises.

Jugnu weighs around 3.5 kgs and would be 34 cm long and 10 cm wide. Equipped with the micro imaging and micro electronic system, it will transfer the images to the IIT Kanpur campus. The high resolution pictures obtained will be used for different applications like drought monitoring, wasteland management, urban planning and flood risk management.

"Although the stipulated life time of the satellite is six months, we are optimistic that it will complete at least 12 months in the orbit," said Dhandhe.

                                                             ABOUT COLLEGE

IIT-K to launch India's lightest nano satellite, Jugnu

IIT-K to launch India's lightest nano satellite, Jugnu

The Indian Institute of Technology, Kanpur (IITK) has received the Indian Space Research Organisation (ISRO) nod to launch its first and country's lightest nano satellite, Jugnu, by this December. The nod came after a second design review was presented by the IIT-K authorities. The satellite will be launched in the polar orbit from Sriharikota. IIT-K director Sanjay Govind Dhande said, "Though the memorandum of understanding between ISRO and IIT-K for the project was signed in February, regular review sessions are being carried out by ISRO to check the progress of the project." The first review session of the Jugnu was carried out by ISRO in April. "On Tuesday, our technical team working on the project apprised ISRO authorities of the release and antenna mechanism," said Dhande. A team of 12 professors and 40 IIT-K students led by professor and mechanical engineering department head, Nalinaksh S Vyas, have been working on the project since last December. A technical team of ISRO led by D Madhav Murthy, director (small satellite), said they had informed Isro authorities about the details related to the release of Jugnu by mother satellite in polar orbit, and also provided the details regarding the satellite antenna set up in the institute premises. "A similar project in any European country would have cost over Rs 10 crore but we expect the entire project to complete within a budget of Rs 2-3 crore, without compromising on quality. This is a welcome signal for indigenous remote sensing technologies," said Vyas. Weighing 3.5 kg, Jugnu would be 34 cm long and 10 cm wide. It would be equipped with micro imaging and micro electronic system, and transit images to base station at the IITK campus. "Although the stipulated life time of the satellite is six months, we are optimistic that it will complete at least 12 months in the orbit," said Dhande. The high-resolution pictures and data obtained will be used for various applications such as drought monitoring, wasteland management, urban planning and flood-risk management. Source : http://www.iitk.ac.in/news/ 

 

Device Driver

The Role of Device Driver


The Role of device Driver is to provide mechanism not the policy, Policy maintain by the operating systems( Kernel) administration part.


The distinction between mechanism and policy is one of the best ideas behind the Unix design. Most programming problems can indeed be split into two parts: "what capabilities are to be provided" (the mechanism) and "how those capabilities can be used" (the policy). If the two issues are addressed by different parts of the program, or even by different programs altogether, the software package is much easier to develop and to adapt to particular needs.


The Kernel of the Unix/Linux system is divided according to their task, conurrent task.



Process management
The kernel is in charge of creating and destroying processes and handling their connection to the outside world (input and output). Communication among different processes (through signals, pipes, or interprocess communication primitives) is basic to the overall system functionality and is also handled by the kernel. In addition, the scheduler, which controls how processes share the CPU, is part of process management. More generally, the kernel's process management activity implements the abstraction of several processes on top of a single CPU or a few of them.
Memory management
The computer's memory is a major resource, and the policy used to deal with it is a critical one for system performance. The kernel builds up a virtual addressing space for any and all processes on top of the limited available resources. The different parts of the kernel interact with the memory-management subsystem through a set of function calls, ranging from the simple malloc/free pair to much more complex functionalities.
Filesystems
Unix is heavily based on the filesystem concept; almost everything in Unix can be treated as a file. The kernel builds a structured filesystem on top of unstructured hardware, and the resulting file abstraction is heavily used throughout the whole system. In addition, Linux supports multiple filesystem types, that is, different ways of organizing data on the physical medium. For example, disks may be formatted with the Linux-standard ext3 filesystem, the commonly used FAT filesystem or several others.
Device control
Almost every system operation eventually maps to a physical device. With the exception of the processor, memory, and a very few other entities, any and all device control operations are performed by code that is specific to the device being addressed. That code is called a device driver. The kernel must have embedded in it a device driver for every peripheral present on a system, from the hard drive to the keyboard and the tape drive. This aspect of the kernel's functions is our primary interest in this book.
Networking
Networking must be managed by the operating system, because most network operations are not specific to a process: incoming packets are asynchronous events. The packets must be collected, identified, and dispatched before a process takes care of them. The system is in charge of delivering data packets across program and network interfaces, and it must control the execution of programs according to their network activity. Additionally, all the routing and address resolution issues are implemented within the kernel.

Loadable Modules
One of the good features of Linux is the ability to extend at runtime the set of features offered by the kernel. This means that you can add functionality to the kernel (and remove functionality as well) while the system is up and running.
Each piece of code that can be added to the kernel at runtime is called a module . The Linux kernel offers support for quite a few different types (or classes) of modules, including, but not limited to, device drivers. Each module is made up of object code (not linked into a complete executable) that can be dynamically linked to the running kernel by the insmod program and can be unlinked by the rmmod program.

The three classes of device Drivers are:
Character devices
A character (char) device is one that can be accessed as a stream of bytes (like a file); a char driver is in charge of implementing this behavior. Such a driver usually implements at least the open, close, read, and write system calls. The text console (/dev/console) and the serial ports (/dev/ttyS0 and friends) are examples of char devices, as they are well represented by the stream abstraction. Char devices are accessed by means of filesystem nodes, such as /dev/tty1 and /dev/lp0. The only relevant difference between a char device and a regular file is that you can always move back and forth in the regular file, whereas most char devices are just data channels, which you can only access sequentially. There exist, nonetheless, char devices that look like data areas, and you can move back and forth in them; for instance, this usually applies to frame grabbers, where the applications can access the whole acquired image using mmap or lseek.
Block devices
Like char devices, block devices are accessed by filesystem nodes in the /dev directory. A block device is a device (e.g., a disk) that can host a filesystem. In most Unix systems, a block device can only handle I/O operations that transfer one or more whole blocks, which are usually 512 bytes (or a larger power of two) bytes in length. Linux, instead, allows the application to read and write a block device like a char device—it permits the transfer of any number of bytes at a time. As a result, block and char devices differ only in the way data is managed internally by the kernel, and thus in the kernel/driver software interface. Like a char device, each block device is accessed through a filesystem node, and the difference between them is transparent to the user. Block drivers have a completely different interface to the kernel than char drivers.
Network interfaces
Any network transaction is made through an interface, that is, a device that is able to exchange data with other hosts. Usually, an interface is a hardware device, but it might also be a pure software device, like the loopback interface. A network interface is in charge of sending and receiving data packets, driven by the network subsystem of the kernel, without knowing how individual transactions map to the actual packets being transmitted. Many network connections (especially those using TCP) are stream-oriented, but network devices are, usually, designed around the transmission and receipt of packets. A network driver knows nothing about individual connections; it only handles packets.