CHAPTER-1

INTRODUCTION
Closed area without air circulation and directly exposed to sunlight heats up much faster
and reaches significantly higher temperatures than the open space where air circulates freely
so-called "greenhouse effect". That is exactly what happens in a vehicle parked in the hot
summer sun, which later represents a problem when entering such overheated vehicle. In real
conditions are presented and analyzed. The ventilation is very important to the humans in
anywhere. Especially for vehicle, in vehicles there is a lot of heat generate inside the vehicle, if it
is parked in the sun shine results more and more heat. So we cannot enter in to the vehicle
immediately, it takes more time to cool inside the vehicle results uncomfortable to the vehicle
owner.
The basic idea of this project is to prevent or at least mitigate overheating of the vehicle
interior in order to facilitate entering into the vehicle. So that a micro controller managed
automatic ventilation systems will help to make the vehicle comfortable to the owners while
it is parked in the sun shine of the vehicles. Micro controller managed automatic ventilation
system is implemented
The problem can be solved by leaving the vehicle windows partially opened so air can
circulate, which reduces the heating of the vehicle interior. However, as the ventilation
process takes place in a parked vehicle, without human presence, and the vehicle is
exposed to external influences, such as precipitation or potential burglary, it is unreliable
and unsafe. Consequently, it is necessary to

automate the ventilation process.

The complete automatic ventilation process

is

managed

by

microcontroller

default

algorithm, considering input signals read using various sensors. The temperature sensor
measures the temperature inside the vehicle. If it exceeds predefined level of "comfortable
temperature", microcontroller automatically lowers the power windows to enable air
circulation which alleviates aforementioned "greenhouse effect".

The automatic ventilation process must be reliable and not affect the safety of the vehicle. For
this reason, additional sensors are used, whose task is to annul dangers appeared with this
ventilation method. Before all, these are precipitation sensor that makes the ventilation process
reliable, and motion sensors that make it safe. There are also other sensors whose
implementation gives additional quality, but these are the most important of them. Together with
temperature sensor, they meet the minimum requirements to perform automatic function of
ventilation, without endangering the vehicle.
using a microcontroller as a central logical unit and a series of sensors which provide
sufficient data to ensure functional, but also efficient, reliable and safe ventilation. The
ventilation process is performed by opening vehicle windows slightly, which enables air to
circulate.
Following chapters show components and technologies used, operation modes, advantages
and disadvantages, capabilities and potential upgrades of the module, as well as ability of
integration with existing automatic systems within the vehicle.
module.

Results of testing the

CHAPTER-2
LITERATURE SURVEY
With embedded systems fast expanding its reach, subject matter related to this field is
available in abundance. While working on this project we have studied matter from various
sources such as books, online articles and reference manuals. The knowledge gained from this
activity has been of great help to us in understanding the basic concepts related to our project and
has ignited further interest in this topic.
We understood the preponderance of the ARM processors in the field of embedded systems and
the features of ARM processors from the document The ARM Architecture by Leonid Ryzhyk.
The ARM architecture is a confluence of many useful features that makes it better than other
peer processors. Being small in size and requiring less power, they prove useful in providing an
efficient performance in embedded applications.
C/OS III the Real Time Kernel, by Micrium press has been of great help in
providing an introduction to the Real Time Kernel. It has helped me to understand and write the
programming code for the project in the Real Time Operating System.
The Existing systems of automatic ventilation have a lot of demerits which are given below:
1. Pure analogy:
Previously existing systems are pure analogy systems. Which needs the manual operation, it does
not having quality sensors for detection of the high temperature. This system does not support
the predefined input data.
2. Time independent operation:
We cannot give the time to system for its operation set the time the existing systems are
programmed to search only in a predefined path. There is no chance to dynamically alter the
search path.
3. cannot able to establish the remote communication:
The following system cannot able to provide the information regarding temperature condition to
the user remotely.

4. Unintelligent:
Existing systems are unintelligent, it means it does not having micro controller. It simply
collects the data analogy mode; based on that collecting voltage from the sensors, it
performs the operation. It opens window when it receives the maximum voltage and close the
door when cools.
5. Environmental conditions:
It cannot accurately analyze the environmental conditions like temperature, detection of rains for
closing or opening the windows itself.
6. Low trough put:
It was built over the analog system, so that analogy systems performances are time taking
process, so these cannot provide the high speed operations.

CHAPTER-3
EXPERIMENTAL ANALYSIS
3.1 Block Diagram

Figure3.1 Block Diagram

Figure 3.1 Block diagram of the microcontroller managed automatic ventilation system for
vehicle interiors. The above Block diagram Consisting of the Arm Cortex M4 Micro
Controller and the Temperature Sensor to Monitor the Temperature inside the Vehicle.
Precipitation Sensor Is Used To Detect the Rain Fall Around the Vehicle and If Rain Occurred.
When window is in open position, the window will close automatically. To monitor the status of
the system LCD display is provided. Motor Driver Circuit is used to drive the Motors. Hence,
The Micro Controller cannot drive the motor directly. Two 60 rpm motors are used to close or to
open the window (Both left side window and right side window).

This device needs the power requirements as given as follows 5V, 750mA power supply. So
battery of the vehicle provides the voltage of 12V, 20A, so we are using 7805 three terminal
voltage regulator is used for voltage regulation.Arm7 microcontroller having the 64 pins
&low power consumption model, it is having the64 pins totally, It is having 48 I/O pins, on chip
ADC, UART, RTC 512kb of flash memory and utilizes low power ,it requires +3.3v volts for its
operation. A simpler design facilitates more efficient multi-core CPUs and higher core counts
at lower cost, providing higher processing power and improved energy efficiency for
servers and super computers LCD display.
First the system should be connected to the battery of the vehicle directly; the system should
remain in on condition even though vehicle in OFF position. When the temperature inside the
vehicle exceeds the predefined level, the microcontroller automatically switch on the motors
for opening the window simultaneously. When the temperature inside the vehicle reaches
the lower level, it will automatically close the window and status of the operation is
displaying on the LCD display. Same operation is performed during raining also. If the
windows are in open position if it rains the micro controller automatically activates the
Windows to close. Important notice is that the same operation can performed even the driver
presented inside the vehicle.

3.2 Module Architecture

the module's task is to control the ventilation process autonomously in order to
facilitate vehicle utilization, i.e. providing conditions to make the entering into the vehicle
parked in the sun more comfortable. In order to meet all the criteria of quality
ventilation, the module has to collect enough data from the vehicle's immediate
environment and, based on that data, it has to decide whether it is necessary to lower the
windows and thus start the ventilation process.
Accordingly, the module can be divided to three logical units: peripheral unit collects data, control unit manages module operations, and switching unit adjusts signals.
Figure 3.2 shows logic diagram of module.

Figure 3.2 Module Architecture

The switching unit exclusively receives commands, which makes it the output
unit.

The control unit, or microcontroller, receives, processes and sends signals which

makes it the central logical unit, while peripheral unit exclusively collects data and sends it
to control unit, which makes it the input unit.

3.2.1 Peripheral Unit

Since the peripheral unit is also the input unit, it is presented first, for better
insight into module operations and modes. By having to collect many different types of data,
the peripheral unit is complex enough as it is. The necessity of placing different sensors in
separate locations, in order to achieve data collection, makes it even more complex.

3.2.1.1 Temperature Sensor

The temperature sensor is the most important sensor of this module because
measuring of the vehicle interior temperature enables this method of automatic ventilation.
The sensor is located inside the vehicle, protected from direct sunlight in order to measure the

actual temperature of the vehicle interior, not the ostensible temperature (which is slightly
higher due to the direct expose to the sun rays).

The sensor consists of temperature

sensitive resistor - NTC (Negative Temperature Coefficient) as a main part of sensor's

electronic

circuit

with

other

necessary electronic

components.

In accordance with

temperature change, sensor gives different output value. The control unit processes it and thus
receives information about the actual temperature inside the vehicle.
The LM35-series devices are precision integrated-circuit temperature sensors, with an
output voltage linearly proportional to the Centigrade temperature. The LM35 device has an
advantage over linear temperature sensors calibrated in Kelvin, as the user is not required to
subtract a large constant voltage from the output to obtain convenient Centigrade scaling. The
LM35 device does not require any external calibration or trimming to provide typical accuracies
of C at room temperature and cover a full 55C to 150C temperature range.
Lower cost is assured by trimming and calibration at the water level. The low output
impedance, linear output, and precise inherent calibration of the LM35 device makes interfacing
to readout or control circuitry especially easy. The device is used with single power supplies, or
with plus and minus supplies. As the LM35 device draws only 60 A from the supply, it has very
low self-heating of less than 0.1C in still air. The LM35 device is rated to operate over a 55C
to 150C temperature range, while theLM35Cdevice is rated for a 40C to 110C range (10
with improved accuracy). The temperature-sensing element is comprised of a delta-V BE
architecture. The temperature-sensing element is then buffered by an amplifier and provided to
the VOUT pin. The amplifier has a simple class A output stage with typical 0.5- output
impedance .Therefore the LM35 can only source current and its sinking capability is limited to 1
A.

Figure 3.3 Temperature Sensor

Temperature is the most often-measured environmental quantity. This might be expected
since most physical, electronic, chemical, mechanical, and biological systems are affected by
temperature. Certain chemical reactions, biological processes, and even electronic circuits
perform best within limited temperature ranges. Temperature is one of the most commonly
measured variables and it is therefore not surprising that there are many ways of sensing it.
Temperature sensing can be done either through direct contact with the heating source, or
remotely, without direct contact with the source using radiated energy instead.
There are a wide variety of temperature sensors on the market today, including
Thermocouples, Resistance Temperature Detectors (RTDs), Thermistors, Infrared, and
Semiconductor Sensors.

3.2.1.2 Precipitation Sensor

Precipitation sensor is very important because it makes the automatic ventilation reliable.
If precipitation occurs during the ventilation process, sensor detects the new circumstances
and sends a signal to the control unit which orders to close the windows immediately.
The sensor is situated on the windshield inside the vehicle, above the rear-view mirror in
order to detect the falling drops of water on the glass. LED (Light Emitting Diode) or IR
(Infra-Red) diode is used as a transmitter that emits light at a certain

angle

onto

the

windshield. The light of the expected intensity reflects to the photodiode which is used
as a receiver. If droplets appear onto the windshield, the light reflects differently which causes
a change in the receiving electronic circuit connected to the microcontroller. That is recognized
as the presence of precipitation and windows close. Figure 3.4 shows precipitation sensor.

Figure 3.4 Precipitation Sensor

3.2.1.3 Motion Sensor

Motion sensors are very important for the vehicles safety while the ventilation process
takes place.

If there are movements detected within the vehicle's surroundings, it is

classified as a potential danger and the system closes the windows. Commercial motion
sensors on the principle of infrared technology - "Velleman PIR416" are used for purpose
of this module. The infrared motion sensor works on a similar principle as the precipitation
sensor; by detecting the infrared radiation reflected from a moving object within the
sensors range. Infrared sensors have the disadvantage of not receiving signal effectively
through the glass, so they should be mounted outside the vehicle, which is aesthetically
undesirable.

For this reason, microwave motion sensor(s) can be used, such is, which will

surely detect all motions within the vehicle's surroundings, from inside the vehicle. The basic
function of automatic ventilation inside the vehicle is achieved using temperature sensor.
Ventilation inside the vehicle is achieved by method of slightly lowering windows for a
few centimeters, which makes it functional, discreet enough, but relatively reliable and
safe. By adding the precipitation and motion sensors, the ventilation process becomes reliable
and safe, but it opens up the possibility of even better ventilation. That is, now when there is a
control system and protection from external impact, the windows can be further lowered

10

to increase air circulation, and more air circulation means more quality ventilation. These
critical input units are the most important for stable ventilation process. Other input units which
contribute to efficiency and vehicle safety are:

3.2.1.4 Light Sensor

The light sensor; used for economic reasons. Given that the interior can be heated
more than the environment only when the vehicle is exposed to direct sunlight, which
does not exist at night, whole ventilation process at night does not make sense, and it is
automatically suspended until morning. It results in a more efficient and economical usage of
the module. Sensor is placed inside the vehicle, protected from direct sunlight in order to
reduce sudden changes in light intensity readings caused by disruptive factors such as
clouds. The sensor itself is actually a photo resistor that has a characteristic of resistance
change depending on the intensity of light in the area where it is located. Photo resistor
used here has an extremely fast response to changes in light intensity. Resistance changes are
large even for the least change of the brightness. Therefore, it is necessary to use additional
electronic components that slow down and reduce these rapid and large changes to obtain
stable and reliable signal which can then be sent to the control unit for processing.

Figure 3.5 Light Sensor

11

3.2.1.5 Position Sensors

Position sensors contribute to the quality work of module. These are the lower and upper
end as well as mid position sensors. They are located in the vehicle doors, that is, the end
positions of windows movement range.
position of the window.

They signal an entirely opened or entirely closed

The mid position sensor signals when window reaches position

where should be placed in the automatic ventilation mode. Position sensors provide a reliable
windows setting in the desired position. This benefits to all aspects of the module quality;
provides the reliability and security because the windows will always reach an end
position whenever it is necessary, improves efficiency because windows will stop
immediately when they reach a target position, preventing unnecessary overload of the
electric motors and needles consumption of limited electrical energy, as well as potential
danger of blowing electric motors or module is prevented and the vehicle is protected
from potential conflagration. Moreover, a very important input information is obtained direct feedback that informs the microcontroller on the execution of the given commands.
All this greatly improves the quality of the ventilation process. Position sensor functionality is
achieved using conventional buttons and switches. When reaching the mid or end position,
the window carrier press the button/switch that closes the electronic circuit which confirms
successfully executed operation to microcontroller. According to, various components and
methods were considered for this purpose, such are photo and infra-red diodes or instead of
using additional components this function is
Programmable via microcontroller in the form of time circuit. However, classic buttons
and switches are the simplest, most reliable and most resistant components that are to be
applied for this purpose.

3.2.2 Control Unit

Control, or central logical unit, is the brain of the module. By default algorithm and
collected input signals, module independently controls power windows in automatic mode the automatic ventilation inside the vehicle. In manual mode, when a person is present in the
vehicle, module just relays human commands onto the windows.
For this purpose is used AVR ATmega32 microcontroller. Since the microcontroller is
available as one component, this is seemingly a very simple logical unit.

12

However, it is a

highly complex integrated circuit that contains thousands of electronic components inside.
All in all, this microcontroller is too powerful for this module.

However, as it has an

affordable price, and considering the additional module upgrades and extensions, it would
be imprudent to limit its potential immediately at start by implementing a microcontroller
with fewer features.
The control unit could be implemented even without microcontroller by using
some other logic electronic components, however, the module would not be programmable,
nor upgradeable or be adaptable to individual vehicles and customer requirements.

3.2.3 Switching Unit

Switching unit is also used as the output unit and is responsible for the stable
transmission of the output control signals from the microcontroller and to adjust them for
window's electric motors. It consists of several components that are responsible for the
conversion of weak control signals from the microcontroller to the strong electric signals
that directly drive the electric motors. These are various transistor amplifiers and relays
which, in addition to amplifying the weak control signals from the microcontroller, also
galvanically isolate logic module's electronic circuit from a strong motor's electric circuit.
There are various options of transfer and adjustment of control signals from the
microcontroller to the electric motors. In this case, a driver L293NE is used.
It turns logic signal from the microcontroller into much stronger electric signal that can
directly power the electric motor. Considering that in real circumstances current reaches 1
A, it turns out that this driver component overheats and does not deliver enough power for
electric motor to move windows quality enough.

Therefore, besides the aforementioned

galvanic circuit separation, relays are used to prevent overheating of the driver component,
achieving a sufficient power for quality work of electric motors and prevent the flow of
large currents within the module, which is not advisable because of the strong magnetic fields
that are generated by large currents and their negative effects on sensitive electronic
components.

13

3.2.4 Other Units

Peripheral unit, control unit and switching unit compose a logical unit that is
oriented to the specific modules role - automatic ventilation inside the vehicle. In addition
to them, the module includes other components that perform a particular role; voltage
converter and stabilizer, integrated connector and a set of components

that

allow

the

microcontroller to be programmed directly within the module.

3.3 Hardware Components

3.3.1 ARM CORTEX M4
ARM originally Acorn RISC Machine it is a family of reduced instruction set
computing architectures for computer

processors,

configured

for

various

environments,

developed by British company ARM Holdings. A RISC based computer design approach means
ARM processors require significantly fewer transistors than typical complex instruction set
computing x86 processors in most personal computers. This approach reduces costs, heat and
power use. Such reductions are desirable traits for light, portable, battery powered devices
including smart phones, laptops, tablet and notepad computers, and other embedded systems. A
simpler design facilitates more efficient multi-core CPUs and higher core counts at lower cost,
providing improved energy efficiency for servers.
The main system consists of 32 bit multilayer AHB bus matrix that interconnects the
eight masters and seven slaves.
Eight masters:

Cortex-M4F core I-bus, D-bus and S-bus

DMA1 memory bus

DMA2 memory bus

DMA2 peripheral bus

Ethernet DMA bus

USB OTG HS DMA bus

14

Seven slaves:

Internal Flash memory ICode bus

Internal Flash memory DCode bus

Main internal SRAM1 (112 KB)

Auxiliary internal SRAM2 (16 KB)

Auxiliary internal SRAM3 (64 KB) available only on STM32F42xxx and

STM32F43xxx devices

AHB1 peripherals including AHB to APB bridges and APB peripherals

AHB2 peripherals

FSMC

The memory organization of the system with Program memory, data memory, registers
and I/O ports are organized within the same linear 4 Gbyte address space. The bytes are coded in
memory in little Endean format. The lowest numbered byte in a word is considered the words
least significant byte and the highest numbered byte, the words most significant. The
addressable memory space is divided into 8 main blocks, each of 512 MB
GPIO:
The general purpose input output (GPIO) peripherals of system cortex we are using
consistes of the has four 32-bit configuration registers (GPIOx_MODER, GPIOx_OTYPER,
GPIOx_OSPEEDR and GPIOx_PUPDR), two 32-bit data registers (GPIOx_IDR and
GPIOx_ODR), a 32-bit set/reset register (GPIOx_BSRR), a 32-bit locking register
(GPIOx_LCKR) and two 32-bit alternate function selection register (GPIOx_AFRH and
GPIOx_AFRL).
The following are the main features of the GPIO:

Up to 16 I/Os under control

Output states: push-pull or open drain + pull-up/down

Output data from output data register (GPIOx_ODR) or peripheral

Speed selection for each I/O

Input states: floating, pull-up/down, analog

Input data to input data register (GPIOx_IDR) or peripheral (alternate function input)

Bit set and reset register (GPIOx_BSRR) for bitwise write access to GPIOx_ODR

15

Locking mechanism (GPIOx_LCKR) provided to freeze the I/O configuration

Analog function

Alternate function input/output selection registers (at most 16 AFs per I/O)

Fast toggle capable of changing every two clock cycles

Highly flexible pin multiplexing allows the use of I/O pins as GPIOs or as one of several

GPIO functional description:

Subject to the specific hardware characteristics of each I/O port listed in the datasheet, each port
bit of the general-purpose I/O (GPIO) ports can be individually configured by software in several
modes:

Input floating

Input pull-up

Input-pull-down

Analog

Output open-drain with pull-up or pull-down capability

Output push-pull with pull-up or pull-down capability

Alternate function push-pull with pull-up or pull-down capability

Alternate function open-drain with pull-up or pull-down capability

RCC:
The Reset and clock control (RCC) of the system consists of three types of reset, defined
as system Reset, power Reset and backup domain Reset.
A system reset sets all registers to their reset values except the reset flags in the clock
controller CSR register and the registers in the Backup domain.
A system reset is generated when one of the following events occurs:

A low level on the NRST pin (external reset)

Window watchdog end of count condition (WWDG reset)

Independent watchdog end of count condition (IWDG reset)

A software reset (SW reset)

Low-power management reset

16

A power reset is generated when one of the following events occurs:

Power-on/power-down reset (POR/PDR reset) or brownout (BOR) reset

When exiting the Standby mode

The backup domain reset sets all RTC registers and the RCC_BDCR register to their reset

values. The BKPSRAM is not affected by this reset. The only way of resetting the BKPSRAM is
through the Flash interface by requesting a protection level change from 1 to 0.
A backup domain reset is generated when one of the following events occurs:

Software reset, triggered by setting the BDRST bit in the RCC

VDD or VBAT power on, if both supplies have previously been powered off
The system clock of the arm cortex plays an important role. Three different clock sources

can be used to drive the system clock (SYSCLK)

HSI oscillator clock

HSE oscillator clock

Main PLL (PLL) clock

The devices have the two following secondary clock sources:

32 kHz low-speed internal RC (LSI RC) which drives the independent watchdog and,
optionally, the RTC used for Auto-wakeup from the Stop/Standby mode.

32.768 kHz low-speed external crystal (LSE crystal) which optionally drives the RTC
clock (RTCCLK)

DMA:
The DMA controller performs direct memory transfer: as an AHB master, it can take the control
of the AHB bus matrix to initiate AHB transactions.
It can carry out the following transactions:
peripheral-to-memory
memory-to-peripheral
memory-to-memory
The DMA controller provides two AHB master ports: the AHB memory port, intended to be
connected to memories and the AHB peripheral port, intended to be connected to peripherals.

17

However, to allow memory-to-memory transfers, the AHB peripheral port must also have access
to the memories. The AHB slave port is used to program the DMA controller (it supports only
32-bit accesses).
Direct memory access (DMA) is used in order to provide high-speed data transfer between
peripherals and memory and between memory and memory. Data can be quickly moved by
DMA without any CPU action. This keeps CPU resources free for other operations. The DMA
controller combines a powerful dual AHB master bus architecture with independent FIFO to
optimize the bandwidth of the system, based on complex bus matrix architecture. The two DMA
controllers have 16 streams in total (8 for each controller), each dedicated to managing memory
access requests from one or more peripherals. Each stream can have up to 8 channels in total.
And each has an arbiter for handling the priority between DMA requests.
The main DMA features are:

Dual AHB master bus architecture, one dedicated to memory accesses and one dedicated
to peripheral accesses

AHB slave programming interface supporting only 32-bit accesses

8 streams for each DMA controller, up to 8 channels (requests) per stream

Four separate 32 first-in, first-out memory buffers (FIFOs) per stream, that can be used
In FIFO mode or direct mode.

ADC:
The ADC of the ARM cortex The 12-bit ADC is a successive approximation analog-todigital converter. It has up to 19 multiplexed channels allowing it to measure signals from 16
external sources, two internal sources, and the VBAT channel. The A/D conversion of the
channels can be performed in single, continuous, scan or discontinuous mode. The result of the
ADC is stored into a left or right aligned 16-bit data register. The analog watchdog feature allows
the application to detect if the input voltage goes beyond the user-defined, higher or lower
thresholds.
The 12-bit ADC is a successive approximation analog-to-digital converter. It has up to 19
multiplexed channels allowing it to measure signals from 16 external sources, two internal
sources, and the VBAT channel. The A/D conversion of the channels can be performed in

18

single, continuous, scan or discontinuous mode. The result of the ADC is stored into a left- or
right-aligned 16-bit data register.
The analog watchdog feature allows the application to detect if the input voltage goes beyond
the user-defined, higher or lower thresholds.
ADC main features:
12-bit, 10-bit, 8-bit or 6-bit configurable resolution
Interrupt generation at the end of conversion, end of injected conversion, and in case of
analog watchdog or overrun events
Single and continuous conversion modes
Scan mode for automatic conversion of channel 0 to channel n
Data alignment with in-built data coherency
Channel-wise programmable sampling time
External trigger option with configurable polarity for both regular and injected conversions
Discontinuous mode
Dual/Triple mode (on devices with 2 ADCs or more)
Configurable DMA data storage in Dual/Triple ADC mode
Configurable delay between conversions in Dual/Triple interleaved mode
ADC conversion type (refer to the datasheets)
ADC supply requirements: 2.4 V to 3.6 V at full speed and down to 1.8 V at slower speed
ADC input range: VREF <= VIN <= VREF+
DMA request generation during regular channel conversion

NESTED VECTORED INTERRUPT CONTROLLER (NVIC):

The nested vector interrupt controller NVIC includes the following features:

82 maskable interrupt channels for STM32F405xx/07xx and STM32F415xx/17xx, and

up to 86 maskable interrupt channels for STM32F42xxx and STM32F43xxx (not
including the 16 interrupt lines of Cortex-M4F)

16 programmable priority levels (4 bits of interrupt priority are used)

low-latency exception and interrupt handling

19

power management control implementation of system control registers

The NVIC and the processor core interface are closely coupled, which enables low
latency interrupt processing and efficient processing of late arriving interrupts.

All interrupts including the core exceptions are managed by the NVIC.

EXTERNAL INTERRUPT/EVENT CONTROLLER (EXTI):

The external interrupt/event controller consists of up to 23 edge detectors for generating
event/interrupt requests. Each input line can be independently configured to select the type
(interrupt or event) and the corresponding trigger event (rising or falling or both). Each line can
also masked independently. A pending register maintains the status line of the interrupt requests.
EXTI main features:
The main features of the EXTI controller are the following:
Independent trigger and mask on each interrupt/event line
dedicated status bit for each interrupt line
Generation of up to 23 software event/interrupt requests
Detection of external signals with a pulse width lower than the APB2 clock period. Refer to
the electrical characteristics section of the STM32F4xx datasheets for details on this parameter.
TIMER:
The basic timers TIM6 and TIM7 consist of a 16-bit auto-reload counter driven by a
programmable prescaler. They may be used as generic timers for time-base generation but they
are also specifically used to drive the digital-to-analog converter (DAC). In fact, the timers are
internally connected to the DAC and are able to drive it through their trigger outputs.
The timers are completely independent, and do not share any resources.
Basic timer (TIM6&TIM7) features include:
16-bit auto-reload up counter
16-bit programmable prescaler used to divide (also on the fly) the counter clock
frequency by any factor between 1 and 65536
Synchronization circuit to trigger the DAC
Interrupt/DMA generation on the update event: counter overflow

20

Time-base unit
The main block of the programmable timer is a 16-bit upcounter with its related auto-reload
register. The counter clock can be divided by a prescaler.
The counter, the auto-reload register and the prescaler register can be written or read by
software. This is true even when the counter is running.
The time-base unit includes:
Counter Register (TIMx_CNT)
Prescaler Register (TIMx_PSC)
Auto-Reload Register (TIMx_ARR)
The auto-reload register is preloaded. The preload register is accessed each time an attempt is
made to write or read the auto-reload register. The contents of the preload register are
transferred into the shadow register permanently or at each update event UEV, depending on the
auto-reload preload enable bit (ARPE) in the TIMx_CR1 register. The update event is sent
when the counter reaches the overflow value and if the UDIS bit equals 0 in the TIMx_CR1
register. It can also be generated by software. The generation of the update event is described in
detail for each configuration.
The counter is clocked by the prescaler output CK_CNT, which is enabled only when the
counter enable bit (CEN) in the TIMx_CR1 register is set.
Prescaler description
The prescaler can divide the counter clock frequency by any factor between 1 and 65536. It is
based on a 16-bit counter controlled through a 16-bit register (in the TIMx_PSC register). It can
be changed on the fly as the TIMx_PSC control register is buffered. The new prescaler ratio is
taken into account at the next update event.
Counting mode
The counter counts from 0 to the auto-reload value (contents of the TIMx_ARR register), then
restarts from 0 and generates a counter overflow event.
An update event can be generate at each counter overflow or by setting the UG bit in the
TIMx_EGR register (by software or by using the slave mode controller).

21

The UEV event can be disabled by software by setting the UDIS bit in the TIMx_CR1 register.
This avoids updating the shadow registers while writing new values into the preload registers.
In this way, no update event occurs until the UDIS bit has been written to 0, however, the
counter and the prescaler counter both restart from 0 (but the prescale rate does not change). In
addition, if the URS (update request selection) bit in the TIMx_CR1 register is set, setting the
UG bit generates an update event UEV, but the UIF flag is not set (so no interrupt or DMA
request is sent).
When an update event occurs, all the registers are updated and the update flag (UIF bit in the
TIMx_SR register) is set (depending on the URS bit):
the buffer of the prescaler is reloaded with the preload value (contents of the
TIMx_PSC register)
the auto-reload shadow register is updated with the preload value (TIMx_ARR)
The following figures show some examples of the counter behavior for different clock
frequencies when TIMx_ARR = 0x36.
I2C:
I2C (inter-integrated circuit) bus Interface serves as an interface between the microcontroller
and the serial I2C bus. It provides multimaster capability, and controls all I2C bus-specific
sequencing, protocol, arbitration and timing. It supports standard and fast speed modes. It is
also SMBus 2.0 compatible.
It may be used for a variety of purposes, including CRC generation and verification, SMBus
(system management bus) and PMBus (power management bus).
Depending on specific device implementation DMA capability can be available for reduced
CPU overload.
I2C main features
Parallel-bus/I2C protocol converter
Multimaster capability: the same interface can act as Master or Slave
I2C Master Features:
Clock generation
Start and Stop generation

22

 I2C Slave features:

Programmable I2C Address detection
Dual Addressing Capability to acknowledge 2 slave addresses
Stop bit detection
Generation and detection of 7-bit/10-bit addressing and General Call
supports different communication speeds:
Standard Speed (up to 100 kHz)
Fast Speed (up to 400 kHz)
Programmable digital noise filter for STM32F42xxx and STM32F43xxx
Status flags:
Transmitter/Receiver mode flag
End-of-Byte transmission flag
I2C busy flag
Error flags:
Arbitration lost condition for master mode
Acknowledgement failure after address/ data transmission
Detection of misplaced start or stop condition
Overrun/Underrun if clock stretching is disabled
2 Interrupt vectors:
1 Interrupt for successful address/ data communication
1 Interrupt for error condition
Optional clock stretching
1-byte buffer with DMA capability
Configurable PEC (packet error checking) generation or verification:
PEC value can be transmitted as last byte in Tx mode
PEC error checking for last received byte
SMBus 2.0 Compatibility:
25 ms clock low timeout delay
10 ms master cumulative clock low extend time
25 ms slave cumulative clock low extend time

23

 Hardware PEC generation/verification with ACK control

Address Resolution Protocol (ARP) supported
PMBus Compatibility
I2C functional description:
In addition to receiving and transmitting data, this interface converts it from serial to parallel
format and vice versa. The interrupts are enabled or disabled by software. The interface is
connected to the I2C bus by a data pin (SDA) and by a clock pin (SCL). It can be connected
with a standard (up to 100 kHz) or fast (up to 400 kHz) I2C bus.
Mode selection
The interface can operate in one of the four following modes:
Slave transmitter
Slave receiver
Master transmitter
Master receiver
By default, it operates in slave mode. The interface automatically switches from slave to master,
after it generates a START condition and from master to slave, if an arbitration loss or a Stop
generation occurs, allowing multimaster capability.
Communication flow
In Master mode, the I2C interface initiates a data transfer and generates the clock signal. A
serial data transfer always begins with a start condition and ends with a stop condition. Both
start and stop conditions are generated in master mode by software.
In Slave mode, the interface is capable of recognizing its own addresses (7 or 10-bit), and the
General Call address. The General Call address detection may be enabled or disabled by
software.
Data and addresses are transferred as 8-bit bytes, MSB first. The first byte(s) following the start
condition contain the address (one in 7-bit mode, two in 10-bit mode). The address is always
transmitted in Master mode.

24

3.2.2 LCD DISPLAY

LCD (Liquid Crystal Display) screen is an electronic display module and find a wide
range of applications. A 16x2 LCD display is very basic module and is very commonly used in
various devices and circuits. These modules are preferred over seven segments and other multi
segment LEDs. The reasons being: LCDs are economical; easily programmable; have no
limitation of displaying special & even custom characters (unlike in seven segments), animations
and so on.
A 16x2 LCD means it can display 16 characters per line and there are 2 such lines. In
this LCD each character is displayed in 5x7 pixel matrix. This LCD has two registers, namely,
Command and Data. The command register stores the command instructions given to the LCD. A
command is an instruction given to LCD to do a predefined task like initializing it, clearing its
screen, setting the cursor position, controlling display etc. The data register stores the data to be
displayed on the LCD. The data is the ASCII value of the character to be displayed on the LCD.
Click to learn more about internal structure of a LCD.

Features:

Can display 224 different symbols.

61x15.8mm viewing area.

5x8 dot matrix format for 2.92x5.56mm characters plus cursor line.

TTL and CMOS compatible.

25

Figure 3.6 LCD DISPLAY

Pin No.

Symbol

Function

VSS

Ground

VDD

Power supply

VLCD

Power Supply for LCD

RS

Select Display Data("H")or Instructions("L")

R/W

Read or Write Select Signal

Read/Write Enable Signal

DB0

Display Data Signal

DB1

Display Data Signal

DB2

Display Data Signal

10

DB3

Display Data Signal

11

DB4

Display Data Signal

12

DB5

Display Data Signal

26

13

DB6

Display Data Signal

14

DB7

Display Data Signal

15

Cathode of Backlight

16

Anode of Backlight
Table 3.1 LCD PIN CONFIGURATION

3.3.3 STEPPER MOTOR

The L298 is a popular motor driver IC that is usable from 6 to 50V, at up to 4A total
output current. It is a high voltage, high current dual full-bridge driver designed to accept
standard TTL logic levels and drive inductive loads such as relays, solenoids, DC and stepping
motors. Two enable inputs are provided to enable or disable the device independently of the
input signals. The emitters of the lower transistors of each bridge are connected together and
the corresponding external terminal can be used for the connection of an external sensing
resistor. An additional supply input is provided so that the logic works at a lower voltage.
FEATURES:

Four motor direction indicator LEDs.

An on-board user-access able 5V low-dropout regulator.

Schottky EMF-protection diodes.

Screw-terminals for power and motor connections.

Socket pin connectors for easy logic interfacing.

A small 40mm (1.53") square footprint.

27

FIGURE 3.7 L298 STEPPER MOTOR DRIVER

A Stepper motor is an electromechanical device which converts electrical pulses into

discrete mechanical movements. Stepper motors consist of a permanent magnetic rotating shaft,
called the rotor, and electromagnets on the stationary portion that surrounds the motor, called the
stator. The shaft or spindle of a Stepper motor rotates in discrete step increments when electrical
command pulses are applied to it in the proper sequence. The motors rotation has several direct
relationships to these applied input pulses. The sequence of the applied pulses is directly related
to the direction of motor shafts rotation. The speed of the motor shafts rotation is directly related
to the frequency of the input pulses and the length of rotation is directly related to the number of
input pulses applied.
BIPOLAR STEPPER MOTOR:
Bipolar motors have a single winding per phase. The current in a winding needs to be
reversed in order to reverse a magnetic pole, so the driving circuit must be more complicated,
typically with an H-bridge arrangement. There are two leads per phase, none are common.
Because windings are better utilized, they are more powerful than a unipolar motor of the same
weight. This is due to the physical space occupied by the windings. A unipolar motor has twice
the amount of wire in the same space, but only half used at any point in time, hence is 50%
efficient (or approximately 70% of the torque output available). Though bipolar
is more complicated to drive, the abundance of driver chip means this is much less difficult to

28

achieve. An 8-lead stepper is wound like a unipolar stepper, but the leads are not joined to
common internally to the motor. This kind of motor can be wired in several configurations.

FIGURE 3.8: STEPPER MOTOR

Operation of Stepper Motor:The rotor: The rotor itself is made from two discs, a little like gears, one of which is a magnetic
north pole (red) and the other is a south pole (blue). When we put the two discs back to back, we
get north and South Pole teeth alternating around the edge
The stator: Around the edge of the rotor, we have the stator: in the example, four electromagnets
that can be switched on and off individually. Generally the electromagnets in a stepper motor
work in pairs, with each opposing pair of magnets switching on together to make a north pole at
the same time, followed by the magnets at right angles, which also work together. Exactly what
switches on when depends on how many rotor teeth (steps) there are and how many
electromagnet coils surround them: the geometry and alignment of a stepper motor has to be just
right to make the rotor turn.

29

FIGURE 3.9: STEPPER MOTOR MECHANISM

How it rotates:

The right electromagnet is energized and becomes a north pole (red) and the left
electromagnet becomes a south pole (blue). This pulls the rotor around by one step so a
blue tooth on the rotor snaps toward the right electromagnet and a red tooth snaps toward
the left electromagnet.

Now the bottom electromagnet becomes a north pole, the top magnet becomes a south
pole, and the two horizontal magnets are switched off. Again, the teeth of the rotor are
pulled around by one step.

The vertical magnets are now switched off and the horizontal magnets are switched on
again, but with the opposite polarity (pattern of magnetism) that they had before. The
teeth of the rotor advance by one more step.

Finally, the vertical magnets are switched on again, in the opposite polarity to before, and
the horizontal magnets are switched off. The rotor mores around one more step. The
whole cycle then repeats.

30

3.3.4 SENSORS
In this projects, different types of sensors are used. Those are mainly Temperature sensor,
precipitation sensor, light sensor, motion sensor and position sensors. The full description of
these sensors in the section 3.2.1.

31

CHAPTER-4
MICROCONTROLLER PROGRAMMING
4.1 RTOS (Real Time Operating System)
A Real Time Operating System generally contains a real-time kernel and other higher-level
services such as file management, protocol stacks, a Graphical User Interface (GUI), and other
components. Most additional services revolve around I/O devices.
MICRIUM C/OS -III REAL TIME KERNEL:
C/OS-III is a scalable, ROMable, preemptive real-time kernel that manages an unlimited
number of tasks. C/OS-III is a third-generation kernel, offering all of the services expected
from a modern real-time kernel including resource management, synchronization, inter-task
communication, and more. However, C/OS-III also offers many unique features not found in
other real-time kernels, such as the ability to perform performance measurements at run time,
directly signal or send messages to tasks, and pending (i.e., waiting) on such kernel objects as
semaphores and message queues.
The services offered by the real time kernel c/OS:

Task management

Ready list

Scheduling

Context switching

Interrupt management

Pending list

Time management

Timer management

Resource management

Synchronization

Message passing

Multiple objects

Memory management

Runtime statistics.

32

Here is a list of features provided by C/OS-III:

Source Code: C/OS-III is provided in ANSI-C source form. The source code for C/OS-III is
arguably the cleanest and most consistent kernel code available. Clean source is part of the
corporate culture at Micrim. Although many commercial kernel vendors provide source code
for their products, unless the code follows strict coding standards and is accompanied by
complete documentation with examples to show how the code works, these products may be
cumbersome and difficult to harness. With this book, you will gain a deep understanding of the
inner workings of C/OS-III, which will protect your investment.
Intuitive Application Programming Interface (API): C/OS-III is highly intuitive. Once
familiar with the consistent coding conventions used, it is simple to predict the functions to call
for the services required, and even predict which arguments are needed. For example, a pointer
to an object is always the first argument, and a pointer to an error code is always the last one.
Preemptive multitasking: C/OS-III is a preemptive multi-tasking kernel and therefore,
C/OS-III always runs the most important ready-to-run task.
Round robin scheduling of tasks at equal priority: C/OS-III allows multiple tasks to run at
the same priority level. When multiple tasks at the same priority are ready-to-run, and that
priority level is the most important level, C/OS-III runs each task for a user-specified time
called a time quanta. Each task can define its own time quanta, and a task can also give up the
CPU to another task at the same priority if it does not require the full time quanta.
Low interrupt disable time: C/OS-III has a number of internal data structures and variables
that it needs to access atomically. To ensure this, C/OS-III is able to protect these critical
regions by locking the scheduler instead of disabling interrupts. Interrupts are therefore disabled
for very little time. This ensures that C/OS-III is able to respond to some of the fastest interrupt
sources.
Deterministic: Interrupt response with C/OS-III is deterministic. Also, execution times of most
services provided by C/OS-III are deterministic.
Scalable: The footprint (both code and data) can be adjusted based on the requirements of the
application. Adding and removing features (i.e., services) is performed at compile time through
approximately 60 #defines (see os_cfg.h). C/OS-III also performs a number of run-time checks
on arguments passed to C/OS-III services. Specifically, C/OS-III verifies that the user is not

33

passing NULL pointers, not calling task level services from ISRs, that arguments are within
allowable range, and options specified are valid, etc.. These checks can be disabled (at compile
time) to further reduce the code footprint and improve performance. The fact that C/OS-III is
scalable allows it to be used in a wide range of applications and projects.
Portable: C/OS-III can be ported to a large number of CPU architectures. Most C/OS-II ports
are easily converted to work on C/OS-III with minimal changes in just a matter of minutes and
therefore benefit from more than 45 CPU architectures already supported by C/OS-II.
ROMable: C/OS-III was designed especially for embedded systems and can be ROMed along
with the application code.
Run-time configurable: C/OS-III allows the user to configure the kernel at run time.
Specifically, all kernel objects such as tasks, stacks, semaphores, event-flag groups, message
queues, number of messages, mutual exclusion semaphores, memory partitions and timers, are
allocated by the user at run time. This prevents over-allocating resources at compile time.
Unlimited number of tasks: C/OS-III supports an unlimited number of tasks. From a practical
standpoint, however, the number of tasks is actually limited by the amount of memory (both code
and data space) that the processor has access to. Each task requires its own stack space and,
C/OS-III provides features to allow stack growth of the tasks to be monitored at run-time.
C/OS-III does not impose any limitations on the size of each task stack, except that there be a
minimum size based on the CPU used.
Unlimited number of priorities: C/OS-III supports an unlimited number of priority levels.
However, configuring C/OS-III for between 32 and 256 different priority levels is more than
adequate for most applications.
Unlimited number of kernel objects: C/OS-III allows for any number of tasks, semaphores,
mutual exclusion semaphores, event flags, message queues, timers, and memory partitions. The
user allocates all kernel objects at run-time.
Services: C/OS-III provides all the services expected from a high-end real-time kernel, such as
task management, time management, semaphores, event flags, mutexes, message queues,
software timers, fixed-size memory pools, etc.
Mutual Exclusion Semaphores (Mutexes): Mutexes are provided for resource management.
Mutexes are special types of semaphores that have built-in priority inheritance, which eliminate

34

unbounded priority inversions. Accesses to a mutex can be nested and therefore, a task can
acquire the same mutex up to 250 times. Of course, the mutex owner needs to release the mutex
an equal number of times.
Nested task suspension: C/OS-III allows a task to suspend itself or another task. Suspending a
task means that the task will not be allowed to execute until the task is resumed by another task.
Suspension can be nested up to 250 levels deep. In other words, a task can suspend another task
up to 250 times. Of course, the task must be resumed an equal number of times for it to become
eligible to run on the CPU.
Software timers: You can define any number of one-shot and/or periodic timers. Timers are
countdown counters that perform a user-definable action upon counting down to 0. Each timer
can have its own action and, if a timer is periodic, the timer is automatically reloaded and the
action is executed every time the countdown reaches zero.
Task Signals: C/OS-III allows an ISR or task to directly signal a task. This avoids having to
create an intermediate kernel object such as a semaphore or event flag just to signal a task, and
results in better performance.
Task Messages: C/OS-III allows an ISR or a task to send messages directly to a task. This
avoids having to create and use a message queue, and also results in better performance.
Task registers: Each task can have a user-definable number of task registers. Task registers
are different than CPU registers. Task registers can be used to hold errno type variable, IDs,
interrupt disable time measurement on a per-task basis, and more.
Error checking: C/OS-III verifies that NULL pointers are not passed, that the user is not
calling task-level services from ISRs, that arguments are within allowable range, that options
specified are valid, that a pointer to the proper object is passed as part of the arguments to
services that manipulate the desired object, and more. Each C/OS-III API function returns an
error code concerning the outcome of the function call.
Built-in performance measurements: C/OS-III has built-in features to measure the execution
time of each task, stack usage of each task, number of times a task executes, CPU usage, ISR-totask and task-to-task response time, peak number of entries in certain lists, interrupt disable and
scheduler lock time on a per-task basis, and more.

35

Built-in trace points: C/OS-III has built-in trace points throughout the code to record all the
kernel events and interrupts in real-time using some of the most popular tracing analysis tools
(e.g. Percepio's TraceAlyzer and SEGGER SystemView).
Can easily be optimized: C/OS-III was designed so that it could easily be optimized based on
the CPU architecture. Most data types used in C/OS-III can be changed to make better use of
the CPUs natural word size. Also, the priority resolution algorithm can easily be written in
assembly language to benefit from special instructions such as bit set and clear, as well as countleading-zeros (CLZ), or find-first-one (FF1) instructions.
Deadlock prevention: All of the C/OS-III pend services include timeouts, which help avoid
deadlocks.
Tick handling at task level: The clock tick manager in C/OS-III is accomplished by a task that
receives a trigger from an ISR. Handling delays and timeouts by a task greatly reduces interrupt
latency. Also, C/OS-III uses a hashed delta list mechanism, which further reduces the amount of
overhead in processing delays and timeouts of tasks.
User definable hooks: C/OS-III allows the port and application programmer to define hook
functions, which are called by C/OS-III. A hook is simply a defined function that allows the
user to extend the functionality of C/OS-III. One such hook is called during a context switch,
another when a task is created, yet another when a task is deleted, etc.
Timestamps: For time measurements, C/OS-III requires that a 16-bit or 32-bit free running
counter be made available. This counter can be read at run time to make time measurements of
certain events. For example, when an ISR posts a message to a task, the timestamp counter is
automatically read and saved as part of the message posted. When the recipient receives the
message, the timestamp is provided to the recipient, and by reading the current timestamp, the
time it took for the message to be received can be determined.
Built-in support for Kernel Awareness debuggers: This feature allows kernel awareness
debuggers to examine and display C/OS-III variables and data structures in a user-friendly way.
The kernel awareness support in C/OS-III can be used by C/Probe to display this information
at run-time.
Object names: Each C/OS-III kernel object can have a name associated with it. This makes it
easy to recognize what the object is assigned to. You can thus assign an ASCII name to a task, a

36

semaphore, a mutex, an event flag group, a message queue, a memory partition, and a timer. The
object name can have any length, but must be NUL terminated.

4.2 Task Management

The design process of a real-time application generally involves splitting the work to be
completed into tasks, each responsible for a portion of the problem. C/OS-III makes it easy for
an application programmer to adopt this paradigm. A task (also called a thread) is a simple
program that thinks it has the Central Processing Unit (CPU) all to itself. On a single CPU, only
one task can execute at any given time.
C/OS-III supports multitasking and allows the application to have any number of tasks. The
maximum number of task is actually only limited by the amount of memory (both code and data
space) available to the processor. Multitasking is the process of scheduling and switching the
CPU between several tasks (this will be expanded upon later). The CPU switches its attention
between several sequential tasks. Multitasking provides the illusion of having multiple CPUs
and, actually maximizes the use of the CPU. Multitasking also helps in the creation of modular
applications. One of the most important aspects of multitasking is that it allows the application
programmer to manage the complexity inherent in real-time applications. Application programs
are typically easier to design and maintain when multitasking is used.
Tasks are used for such chores as monitoring inputs, updating outputs, performing computations,
control loops, update one or more displays, reading buttons and keyboards, communicating with
other systems, and more. One application may contain a handful of tasks while another
application may require hundreds. The number of tasks does not establish how good or effective
a design may be, it really depends on what the application (or product) needs to do. The amount
of work a task performs also depends on the application. One task may have a few microseconds
worth of work to perform while another task may require tens of milliseconds.
Tasks look like just any other C function, with a few small differences. There are two types of
tasks: run-to-completion (the first listing below) and infinite loop (the second listing below). In
most embedded systems, tasks typically take the form of an infinite loop. Also, no task is
allowed to return as other C functions can. Given that a task is a regular C function, it can
declare local variables.

37

When a C/OS-III task begins executing, it is passed an argument, p_arg. This argument is a
pointer to a void. The pointer is a universal vehicle used to pass your task the address of a
variable, a structure, or even the address of a function, if necessary. With this pointer, it is
possible to create many identical tasks, that all use the same code (or task body), but, with
different run-time characteristics. For example, you may have four asynchronous serial ports that
are each managed by their own task. However, the task code is actually identical. Instead of
copying the code four times, you can create the code for a generic task that receives a pointer
to a data structure, which contains the serial ports parameters (baud rate, I/O port addresses,
interrupt vector number, etc.) as an argument. In other words, you can instantiate the same task
code four times and pass it different data for each serial port that each instance will manage.
A run-to-completion task must delete itself by calling OSTaskDel(). The task starts, performs its
function, and terminates. There would typically not be too many such tasks in the embedded
system because of the overhead associated with creating and deleting tasks at run-time. In
the task body, you can call most of C/OS-IIIs functions to help perform the desired operation
of the task.
void MyTask (void *p_arg)
{
OS_ERR err;
/* Local variables

*/

/* Do something with p_arg

/* Task initialization
/* Task body ... do work!

*/
*/
*/

OSTaskDel((OS_TCB *)0, &err);

}

With C/OS-III, you either can call a C or assembly language functions from a task. In fact, it is
possible to call the same C function from different tasks as long as the functions are reentrant. A
reentrant function is a function that does not use static or otherwise global variables unless they
are protected (C/OS-III provides mechanisms for this) from multiple access. If shared C

38

functions only use local variables, they are generally reentrant (assuming that the compiler
generates reentrant code). An example of a non-reentrant function is the famous strtok() provided
by most C compilers as part of the standard library. This function is used to parse an ASCII string
for tokens. The first time you call this function, you specify the ASCII string to parse and a list
of token delimiters. As soon as the function finds the first token, it returns. The function
remembers where it was last so when called again, it can extract additional tokens, which is
clearly non-reentrant.
The use of an infinite loop is more common in embedded systems because of the repetitive work
needed in such systems (reading inputs, updating displays, performing control operations, etc.).
This is one aspect that makes a task different than a regular C function. Note that one could use a
while (1) or for (;;) to implement the infinite loop, since both behave the same. The one used
is simply a matter of personal preference. At Micrium, we like to use while (DEF_ON). The
infinite loop must call a C/OS-III service (i.e., function) that will cause the task to wait for an
event to occur. It is important that each task wait for an event to occur, otherwise the task would
be a true infinite loop and there would be no easy way for other lower priority tasks to execute.
This concept will become clear as more is understood regarding C/OS-III.
void MyTask (void *p_arg)
{
/* Local variables

*/

/* Do something with p_arg

*/

/* Task initialization
while (DEF_ON) {

*/
/* Task body, as an infinite loop.

*/

:
/* Task body ... do work!

*/

:
/* Must call one of the following services:

*/

/* OSFlagPend()
/*

*/

OSMutexPend()

*/

39

/*

OSQPend()

*/

/*

OSSemPend()

*/

/*

OSTimeDly()

*/

/*

OSTimeDlyHMSM()

/*

OSTaskQPend()

/*

OSTaskSemPend()

/*

OSTaskSuspend()

/*

OSTaskDel()

*/
*/
*/

(Suspend self)

*/

(Delete self)

*/

:
/* Task body ... do work!

*/

:
}
}

The event the task is waiting for may simply be the passage of time (when OSTimeDly() or
OSTimeDlyHMSM() is called). For example, a design may need to scan a keyboard every 100
milliseconds. In this case, you would simply delay the task for 100 milliseconds then see if a key
was pressed on the keyboard and, possibly perform some action based on which key was
pressed. Typically, however, a keyboard scanning task should just buffer an identifier unique to
the key pressed and use another task to decide what to do with the key(s) pressed.
Similarly, the event the task is waiting for could be the arrival of a packet from an Ethernet
controller. In this case, the task would call one of the OS Pend() calls (pend is synonymous with
wait). The task will have nothing to do until the packet is received. Once the packet is received,
the task processes the contents of the packet, and possibly moves the packet along a network
stack.
Its important to note that when a task waits for an event, it does not consume CPU time.

40

Tasks must be created in order for C/OS-III to know about tasks. You create a task by simply
calling OSTaskCreate() as weve seen in the Getting Started section. The function prototype for
OSTaskCreate() is shown below:
void OSTaskCreate (OS_TCB
OS_CHAR

*p_name,

OS_TASK_PTR
void

*p_tcb,

p_task,

*p_arg,

OS_PRIO

prio,

CPU_STK

*p_stk_base,

CPU_STK_SIZE

stk_limit,

CPU_STK_SIZE

stk_size,

OS_MSG_QTY

q_size,

OS_TICK
void

time_slice,
*p_ext,

OS_OPT

opt,

OS_ERR

*p_err)

A complete description of OSTaskCreate() and its arguments is provided in C/OS-III API

Reference. However, it is important to understand that a task needs to be assigned a Task Control
Block (i.e., TCB), a stack, a priority and a few other parameters which are initialized by
OSTaskCreate(), as shown in the figure below.

41

Figure 4.1 - OSTaskCreate() initializes the tasks TCB and stack

When calling OSTaskCreate(), you pass the base address of the stack (p_stk_base) that will be
used by the task, the watermark limit for stack growth (stk_limit) which is expressed in number
of CPU_STK entries before the stack is empty, and the size of that stack (stk_size), also in
number of CPU_STK elements.
When specifying OS_OPT_TASK_STK_CHK + OS_OPT_TASK_STK_CLR in the opt
argument of OSTaskCreate(), C/OS-III initializes the tasks stack with all zeros.
C/OS-III then initializes the top of the tasks stack with a copy of the CPU registers in the same
stacking order as if they were all saved at the beginning of an ISR. This makes it easy to perform
context switches as we will see when discussing the context switching process. For illustration
purposes, the assumption is that the stack grows from high memory to low memory, but the same
concept applies for CPUs that use the stack in the reverse order.

42

The new value of the stack pointer (SP) is saved in the TCB. Note that this is also called the topof-stack.
The remaining fields of the TCB are initialized: task priority, task name, task state, internal
message queue, internal semaphore, and many others.
Next, a call is made to a function that is defined in the CPU port, OSTaskCreateHook() (see
os_cpu_c.c). OSTaskCreateHook() is passed the pointer to the new TCB and this function allows
you (or the port designer) to extend the functionality of OSTaskCreate(). For example, one could
printout the contents of the fields of the newly created TCB onto a terminal for debugging
purposes.
The task is then placed in the ready-list (see The Ready List) and finally, if multitasking has
started, C/OS-III will invoke the scheduler to see if the created task is now the highest priority
task and, if so, will context switch to this new task.
The body of the task can invoke other services provided by C/OS-III. Specifically, a task can
create another task (i.e., call OSTaskCreate()), suspend and resume other tasks (i.e., call
OSTaskSuspend() and OSTaskResume() respectively), post signals or messages to other tasks
(i.e., call OS??Post()), share resources with other tasks, and more. In other words, tasks are not
limited to only make wait for an event function calls.
The figure below shows the resources with which a task typically interacts.

Figure 4.2 - Tasks interact with resources

43

An important aspect of a task is its code. As previously mentioned, the code looks like any other
C function, except that it is typically implemented as an infinite loop and, a task is not allowed to
return.
Each task is assigned a priority based on its importance in the application. C/OS-IIIs job is to
decide which task will run on the CPU. The general rule is that C/OS-III will run the most
important ready-to-run task (highest priority).
With C/OS-III, a low priority number indicates a high priority. In other words, a task at priority
1 is more important than a task at priority 10.
C/OS-III supports a compile-time user configurable number of different priorities (see
OS_PRIO_MAX in os_cfg.h). Thus, C/OS-III allows the user to determine the number of
different priority levels the application is allowed to use. Also, C/OS-III supports an unlimited
number of tasks at the same priority. For example, C/OS-III can be configured to have 64
different priority levels and one can assign dozens of tasks at each priority level.
See Assigning Task Priorities.
1. A task has its own set of CPU registers. As far as a task is concerned, the task thinks it
actually has the CPU all to itself.
2. Because C/OS-III is a preemptive kernel, each task must have its own stack area. The
stack always resides in RAM and is used to keep track of local variables, function calls,
and possibly ISR (Interrupt Service Routine) nesting.
3. Stack space can be allocated either statically (at compile-time) or dynamically (at runtime). A static stack declaration is shown below. This declaration is made outside of a
function.
static CPU_STK MyTaskStk[???];

or,

CPU_STK MyTaskStk[???];

44

Note that ??? indicates that the size of the stack (and thus the array) depends on the task stack
requirements. Stack space may be allocated dynamically by using the C compilers heap
management function (i.e., malloc()) as shown below. However, care must be taken with
fragmentation. If creating and deleting tasks, the process of allocating memory might not be able
to provide a stack for the task(s) because the heap will eventually become fragmented. For this
reason, allocating stack space dynamically in an embedded system is typically allowed but, once
allocated, stacks should not be deallocated. Said another way, its fine to create a tasks stack
from the heap as long as you dont free the stack space back to the heap.
void SomeCode (void)
{
CPU_STK *p_stk;
:
:
p_stk = (CPU_STK *)malloc(stk_size); if (p_stk != (CPU_STK *)0) {
Create the task and pass it p_stk as the base address of the stack ;}
:
:
}
See Determining the Size of a Stack.
1. A task can also have access to global variables. However, because C/OS-III is a
preemptive kernel care must be taken with code when accessing such variables as they
may be shared between multiple tasks. Fortunately, C/OS-III provides mechanisms to
help with the management of such shared resources (semaphores, mutexes and more).
2. A task may also have access to one or more Input/Output (I/O) devices (also known as
peripherals). In fact, it is common practice to assign tasks to manage I/O devices.

45

4.3 Interrupt Management

An interrupt is a hardware mechanism used to inform the CPU that an asynchronous event
occurred. When an interrupt is recognized, the CPU saves part (or all) of its context (i.e.,
registers) and jumps to a special subroutine called an Interrupt Service Routine (ISR). The ISR
processes the event, and upon completion of the ISR the program either returns to the
interrupted task, or the highest priority task, if the ISR made a higher priority task ready-to-run.
Interrupts allow a microprocessor to process events when they occur (i.e., asynchronously),
which prevents the microprocessor from continuously polling (looking at) an event to see if it
occurred. Task level response to events is typically better using interrupt mode as opposed to
polling mode. Microprocessors allow interrupts to be ignored or recognized through the use of
two special instructions: disable interrupts and enable interrupts, respectively.
1. In a real-time environment, interrupts should be disabled as little as possible. Disabling
interrupts affects interrupt latency possibly causing interrupts to be missed.
2. Processors generally allow interrupts to be nested, which means that while servicing an
interrupt, the processor recognizes and services other (more important) interrupts.
3. One of the most important specifications of a real-time kernel is the maximum amount of
time that interrupts are disabled. This is called interrupt disable time. All real-time
systems disable interrupts to manipulate critical sections of code and re-enable interrupts
when critical sections are completed. The longer interrupts are disabled, the higher the
interrupt latency.
4. Interrupt response is defined as the time between the reception of the interrupt and the
start of the user code that handles the interrupt. Interrupt response time accounts for the
entire overhead involved in handling an interrupt. Typically, the processors context
(CPU registers) is saved on the stack before the user code is executed.
5. Interrupt recovery is defined as the time required for the processor to return to the
interrupted code or to a higher priority task if the ISR made such a task ready-to-run.
6. Task latency is defined as the time it takes from the time the interrupt occurs to the time
task level code resumes.

46

4.4 Timer Management

C/OS-III provides timer services to the application programmer and code to handle timers is
found in os_tmr.c. Timer services are enabled when setting OS_CFG_TMR_EN to
DEF_ENABLED in os_cfg.h.
Timers are down counters that perform an action when the counter reaches zero. The user
provides the action through a callback function (or simply callback). A callback is a userdeclared function that will be called when the timer expires. The callback can be used to turn a
light on or off, start a motor, or perform other actions. However, it is important to never make
blocking calls within a callback function (i.e., call OSTimeDly(), OSTimeDlyHMSM(),
OSPend(), or anything that causes the timer task to block or be deleted).
Timers are useful in protocol stacks (retransmission timers, for example), and can also be used to
poll I/O devices at predefined intervals.
An application can have any number of timers (limited only by the amount of RAM available).
Timer services (i.e. functions) in C/OS-III start with the OSTmr???() prefix, and the services
available to the application programmer are described in C-OS-III API Reference.
The resolution of all the timers managed by C/OS-III is determined by the configuration
constant: OS_CFG_TMR_TASK_RATE_HZ, which is expressed in Hertz (Hz). So, if the timer
task (described later) rate is set to 10, all timers have a resolution of 1/10th of a second (ticks in
the diagrams to follow). In fact, this is the typical recommended value for the timer task. Timers
are to be used with coarse granularity.
C/OS-III provides a number of services to manage timers as summarized in the table below.
Function Name

Operation

OSTmrCreate()

Create and specify the operating mode of the

timer.

OSTmrDel()

Delete a timer.

OSTmrRemainGet()

Obtain the remaining time left before the timer

expires.

OSTmrStart()

Start (or restart) a timer.

47

OSTmrStateGet()

Obtain the current state of a timer.

OSTmrStop()

Stop the countdown process of a timer.

Table 4.1 Timer API summary

A timer needs to be created before it can be used. You create a timer by calling OSTmrCreate()
and specify a number of arguments to this function based on how the timer is to operate. Once
the timer operation is specified, its operating mode cannot be changed unless the timer is deleted
and recreated. The function prototype for OSTmrCreate() is shown below as a quick reference:
void OSTmrCreate (OS_TMR

*p_tmr,

/* Pointer to timer

CPU_CHAR

*p_name,

/* Name of timer, ASCII */

OS_TICK

dly,

OS_TICK

period,

OS_OPT

opt,

OS_TMR_CALLBACK_PTR

p_callback,

void

*p_callback_arg, /* Arg. to callback */

OS_ERR

*p_err)

/* Initial delay

*/

/* Repeat period
/* Options

*/

*/
*/

/* Fnct to call at 0

*/

Once created, a timer can be started (or restarted) and stopped as often as is necessary. Timers
can be created to operate in one of three modes: One-shot, Periodic (no initial delay), and
Periodic (with initial delay).

48

CHAPTER-5
EXPERIMENTAL TOOLS
5.1 Software Requirements
IAR EMBEDDED WORKBENCH:

Figure 5.1 IAR Embedded Workbench Welcome Screen

IAR Embedded Workbench is available for many microprocessors and microcontrollers

in the 8-, 16-, and 32-bit segments, allowing stay within a well-known development environment
also for projects. It provides an easy to learn and highly efficient development environment with
maximum code inheritance capabilities, comprehensive and specific target support. IAR
Embedded Workbench promotes a useful working methodology, and you can reduce your
development time significantly by using the IAR Systems tools.

The highly optimizing IAR C/C++ Compiler.

The IAR Assembler.

The versatile IAR ILINK Linker, including accompanying tools.

49

A project manager.

A powerful editor.

IAR Systems is a Swedish computer software company that offers development

tools for embedded system. IAR Systems was founded in 1983, and is listed on NASDAQ
OMX in Stockholm. IAR is an abbreviation of Ingenjorsfirman Anders Rundgren, which means
Anders Rundgren Engineering Company.
IAR Systems develops C and C++ compilers, debuggers, and other tools for developing
and debugging firmware for 8-, 16-, and 32-bit processors. The company started out in the 8-bit
market, but moved into the expanding 32-bit market, especially the market for 32
bit microcontroller.

Figure 5.2 IAR Embedded workbench window

50

Creating the Application Project and demonstrate the development cycle for setting up your
application project in the IDE. Typically, the cycle consists of these steps.

Creating a workspace

Creating a new project

Setting project options

Adding source files to the project

Setting tool-specific options

Compiling

Linking

For most product packages, there are two high-level programming languages. You can use with
the IAR C/C++ Compiler. C is the most widely used high-level programming language in the
embedded Systems industry. You can build freestanding applications that follow these Standards:

Standard C also known as C99. Hereafter, this standard is referred to as Standard C in this
guide.

C89 also known as C94, C90, C89, and ANSI C. This standard is required when MISRA
C is enabled.

C++ depends on your product package, any of these standards can be used:

Standard C++ can be used with different levels of support for exceptions and runtime
type information.

Embedded C++ (EC++), a subset of the C++ programming standard. It is defined by an

industry consortium, the Embedded C++ Technical committee.

IAR Extended Embedded C++, with additional features such as full template support,
multiple inheritances, namespace support, the new cast operators, as well as the Standard
Template Library (STL).

JTAG DEBUGGING:
The Joint Test Action Group (JTAG) name is associated with the IEEE 1149.1 standard
entitled Standard Test Access Port and Boundary-Scan Architecture. Started in 1990 as a
digital test mechanism. In 1994, a supplement containing a description of the boundary scan
description language (BSDL) was added. JTAG is now primarily used for accessing subblocks of integrated circuits, but is also useful as a mechanism for debugging embedded
systems.

51

Figure 5.3 IAR JTAG Debugger working window.

DEVELOPING EMBEDDED APPLICATIONS:Before we start developing our embedded application software, we should read about these
Concepts:
the development cycle.
commonly used software models.
the build process.
Programming for performance.
considering hardware and software factors.
Application execution.

52

THE DEVELOPMENT CYCLE:Before the actual development starts you must gather requirements and design and
specify your application architecture (manually or using automated code generation tools, such
as visual state). Then, you are ready to start the IAR Embedded Workbench IDE.
Below is a typical development cycle:-

A
Requirement
gathering

Link object files for debug

Debug with

Design and
specification

C-spy

Set up
project

Build for release

Edit c source file

Load image to
flash/PROM
Compile files

A
A
A
A

Figure 5.4: DEVELOPMENT CYCLE

53

Set up a project, which includes general and tool-specific options.

Create your source code files in C, C++, or assembler.

Buildcompile and linkyour project for debugging.

Correct any errors in your source code.

Test and debug your application.

Build for release.

Load the image to flash or PROM memory.

5.2 Hardware Requirements

THE STM32F4 High-Performance Discovery Board:
The STM32F4 DISCOVERY helps to discover the STM32F4 high-performance features
and to develop an application easily. It includes everything required for beginners and
experienced users to get started quickly. Based on the STM32F407VGT6, it includes an STLINK/V2 embedded debug tool, two ST MEMS, digital accelerometer and digital microphone,
one audio DAC with integrated class D speaker driver, LEDs and push buttons and an USB OTG
micro-AB connector. A large number of free ready-to-run application firmware examples are
available on www.st.com/stm32f4-discovery to support quick evaluation and development.

54

Figure 5.5: STM32F4 high-performance discovery board.

Features of STM32F4 Board:

STM32F407VGT6 microcontroller featuring 32-bit ARM Cortex-M4F core, 1 MB Flash,

192 KB RAM in an LQFP100 package.

On-board ST-LINK/V2 with selection mode switch to use the kit as a standalone
STLINK/ V2 (with SWD connector for programming and debugging)

Board power supply: through USB bus or from an external 5 V supply voltage.

External application power supply: 3 V and 5 V.

LIS302DL, ST MEMS motion sensor, 3-axis digital output accelerometer.

MP45DT02, ST MEMS audio sensor, Omni-directional digital microphone.

CS43L22, audio DAC with integrated class D speaker driver.

Eight LEDs are as follows

LD1 (red/green) for USB communication.

LD2 (red) for 3.3 V power on.

Four user LEDs, LD3 (orange), LD4 (green), LD5 (red) and LD6 (blue)

USB OTG LEDs LD7 (green) VBUS and LD8 (red) over-current.

Two push buttons (user and reset)

55

USB OTG FS with micro-AB connector.

Extension header for all LQFP100 I/Os for quick connection to prototyping board and
easy probing.

Complete, fully functional motion detection.

Wide 5 m x 5 m, 60 degree detection pattern.

Sensitivity control via simple hardware configuration.

SLEEP mode for low power applications.

No temperature compensation required.

Operates from 2.7 V to 3.6 V power supply.

Simple 8-pin interface.

Standard operating temperature: 0 C to 70 C.

System Requirements:

Windows PC (2000, XP, Vista, 7)

USB type A to Mini-B cable.

Development Tool Chains:

Altium TASKING VX-Toolset.

Atollic TrueSTUDIO

IAR, Embedded Workbench for ARM

Keil, MDK-ARMTM.

Demonstration Software:
The demonstration software is preloaded in the boards Flash memory. It uses the MEMS
motion sensor to blink the four LEDs according to the motion direction and speed. Connecting
the board to a PC with a second USB 'type A to micro-B' cable converts it into a standard mouse,
and board motion controls the PC cursor. The latest versions of the demonstration source code
and associated documentation can be downloaded from www.st.com/stm32f4-discovery.

56

Thermocouple:
It is a type of temperature sensor, which is made by joining two dissimilar metals at one
end. The joined end is referred to as the HOT JUNCTION. The other end of these dissimilar
metals is referred to as the COLD END or COLD JUNCTION. The cold junction is actually
formed at the last point of thermocouple material. If there is a difference in temperature between
the hot junction and cold junction, a small voltage is created. This voltage is referred to as an
EMF (electro-motive force) and can be measured and in turn used to indicate temperature.

The RTD:
Is a temperature sensing device whose resistance changes with temperature. Typically
built from platinum, though devices made from nickel or copper are not uncommon, RTDs can
take many different shapes like wire wound, thin film. To measure the resistance across an RTD,
apply a constant current, measure the resulting voltage, and determine the RTD resistance. RTDs
exhibit fairly linear resistance to temperature curves over their operating regions, and any
nonlinearity are highly predictable and repeatable. The PT100 RTD evaluation board uses
surface mount RTD to measure temperature. An external 2, 3 or 4-wire PT100 can also be
associated with measure temperature in remote areas. The RTDs are biased using a constant
current source. So as to reduce self-heat due to power dissipation, the current magnitude is
moderately low. The circuit shown in figure is the constant current source uses a reference
voltage, one amplifier, and a PNP transistor.

Thermistors:
Similar to the RTD, the thermistor is a temperature sensing device whose resistance
changes with temperature. Thermistors, however, are made from semiconductor materials.
Resistance is determined in the same manner as the RTD, but thermistors exhibit a highly
nonlinear resistance vs. temperature curve.

Thus, in the thermistors operating range we can see a large resistance change for a very
small temperature change. This makes for a highly sensitive device, ideal for set-point
applications.

57

CHAPTER-6
FLOWCHART
It is mentioned that a microcontroller decides what to do and operates independently.
The microcontroller basically just follows the algorithm behavior, predefined program of
what to do in a certain situation. Simplified flowchart shows the microcontrollers algorithm
of behavior (Figure 6.1). Method of operation can easily be noticed by the flowchart.

At the

beginning, initialization of microcontroller and auxiliary variables is performed. After

completion of the initialization, program starts checking parameters and thus sets the state of the
output. First, it determines whether the vehicle is parked or in use. This is determined by
checking whether the key is in the ignition lock, which is not a one hundred percent
confirmation, but it is considered satisfactory. Depending on the result, manual or automatic
mode is switched on. In manual mode, while a person uses the vehicle, microcontroller
only transmits input state to output and thereby has only a minor role in the protection of
electric motors from overload.
When the automatic mode is on, other preconditions are checked in order of
priority; whether it is night, is there precipitation and are there suspicious objects near the
vehicle. If the answer to any of these queries is confirmative, it means the ventilation
process is not necessary or it could endanger the vehicle and will not even start until the
appropriate conditions. If all conditions are satisfied, only then microcontroller checks if
the vehicle interior is overheated and, if it is, opens the windows for ventilation. If, at any
time during the ventilation process, disturbing factors appear, the windows close, thus
suspending the ventilation process until the required conditions are met again. Left and right
window can be opened and closed separately in automatic mode.

This also provides the

efficiency. For example, if in the middle of the ventilation suspicious movements are detected
on the right side of the vehicle, only the right window will close which still allows
partial ventilation through left window only, which is better than none.

58

Figure 6.1 Flow Chart

59

CHAPTER-8
TEST RESULTS
The module is designed and developed for the installation into a one older car
without automatic air conditioner and with already existing basic electric mechanism for
lowering and raising the windows. The car has two power windows which can be managed.
That is why this module prototype manages only two sets of input and output signals for
connecting two independent windows. Figure 4.1 shows the electric scheme of a module
prototype.

Control unit, switching unit, other units and some of the peripheral units

(temperature and light sensors) can be perceived. Since the rest of the sensors cannot be
integrated into the modules main electronic circuit, connectors for their signals are
located inside the module. However, what is not mentioned so far are a lot of buttons, switches
and LEDs that can be seen alongside input and output connectors. With buttons, switches and
LEDs, this prototype module becomes the simulator as well inside the module are
simulators of all input and output signals that make this prototype even more convenient
for the further development and testing.
Although this is just a module prototype, it satisfies all requirements for working
in

real

conditions

and

can

be implemented in any vehicle. Considering

different

characteristics of individual microcontroller pins and the various possible upgrades,

important criterion was to place and connect components in a logical and calculated order,
with respect to all present and possible hardware or software upgrades so it is important to
be careful while designing and connecting all
electronic components in general.

electronic

circuits,

inputs,

outputs

and

Integration of certain electronic components protects

module against different sort of nuisances that exist or could appear in real circumstances.
Electronic circuit was developed parallel with the program code to achieve even better
congruence between individual components and operations. Besides all the attention that was
given in the hardware development, a lot of attention was committed to the software
segments that improve quality work of module and protect system against contingent
situations. Aesthetic appearance of the assembly was also taken into consideration. Result is a
complete product that is ready for real use. Of course, the software can still significantly
improve in order to obtain a more intelligent and efficient module, but it is efficient enough,
functional, reliable and safe to use.

60

The module is assembled using DIP (Dual In-line Package) electronic components,
primarily due to the ease of making, testing and changing the hardware, which is quite
important since it is a prototype that will spend most of the time in simulation instead of
operating into the real world. Figure 5 shows the final implementation of printed circuit board.
Necessity of placing sensors around vehicle interior is already presented, but it is
good to emphasize it again because it directly disables implementation of this module as one
physical unit, which triggers other aggravating effects for easy installation and minimum
costs.
PRAPOSED SYSTEM
The proposed system has the following specifications.
1. Fully digital system:
This system is implemented by using advanced controller, which enables all the
sensors to interface them digitally to the micro controller. So that the results given by the
system are very accurate.
2. Status monitoring:
Whatever the works performed by the controller system, which enables the LCD
display to monitor the status of the system. So that the user use this or operate this system
more and more comfortably.
3. Time dependent operation:
This system allows the time dependent operations. Which means that how much of time
is required fully open the window the window or fully close. Time taking to open a window
or to close the window is fixed by the programmer.
4. Intelligent:
This system behavior is very intelligent, why because it is designed over the micro
controller platform, it works depending on the situation occurred.

61

5. Temperature & rain monitoring in digital:

This monitors the temperature and rain occurrence in digital way; it means it will
compare the received data from sensors with the predefined data, if input data is matched
with the predefined data it will perform the desired operation as it is necessary.
6. Accurate and high speed operation:
Data provide by the system is very accurate in terms of data collecting and process
execution. Operation Speed of the system is very high, due presence of the high performance
controller and reliable sensors operation.
7. Support remote communication:
The following system has ability to communicate with vehicle user; it will send
the information regarding temperature condition inside the vehicle to the user by SMS.
WORKING
First the system should be connected to the battery of the vehicle directly; the system
should remain in on condition even though vehicle in OFF position. When the temperature
inside the vehicle exceeds the predefined level, the microcontroller automatically switch on
the motors for opening the window simultaneously it will send a message to the user by using
the GSM modem.
When

the

temperature inside

the

vehicle reaches

the lower

level,

it

will

automatically close the window and status of the operation is displaying on the LCD display.
Same operation is performed during raining also. If the windows are in open position if it
rains the micro controller automatically activates the windows to close, again status is send to
user through SMS. Important notice is that the same operation can performed even the driver
presented inside the vehicle.

62

Module has been tested under real operating conditions in few vehicles on
outside temperatures in range of 21 C to 27 C. Mid position sensors were set on few different
levels. Also,

temperatures

inside

vehicles while

fully opened/closed

windows

were

measured for better comparison. Measured temperatures are presented by Figure 6. The
samples were collected during longer period of time. Comparing measured inside temperatures
it is concluded that slightly opened windows (up to 5 cm) do not get satisfying results. To
achieve quality ventilation it was necessary to lower windows at least 10 to 15 centimeters.
Of course, more opened windows, and finally completely opened windows gives the best results,
but 15 to 25 centimeters is optimal regarding inside temperature drop, energy consummation and
safety concerns.
Presented results should be taken into consideration as informative since measurements
were not taken in exactly the same weather conditions for each individual vehicle so there are
visible disrupting effects. It can be remarked that many different factors, besides obvious
direct sunlight, outside temperature and windows position directly affect ventilation
process; weather conditions have significant influence on the ventilation process e. g.,
wind noticeably accelerates and enhances ventilation. Further, size of the vehicle, even
vehicle body color and vehicle orientation relative to the sun makes noticeable difference.
Except module proved to be safe, reliable and efficient, satisfactory results of the
ventilation function were achieved.

Without the module and with closed windows (or

slightly lowered windows), temperature inside of the vehicle parked in the sun on light
spring temperatures of 25 C can reach over 50 C. In summer, inside temperature rises even
more drastically.

While lowering windows for at least 10 to 15 centimeters to enable

quality ventilation process, inside temperature becomes much bearable.

Considering the

fact that this ventilation process is a passive method of cooling overheated interior, it
accomplishes very good results.

63

Figure 8.1 Simulator Showing Results

Figure 8.2 Project Hardware

64

Fig.8.3 LCD Showing Results based on the temperature

ADVANTAGES
1. It provides the advantage of safety.
The major advancement in this system, it provides the safety to the vehicle users. And
keeps the vehicle interior clean and reduces the health problems to the user of that particular
vehicle
2. Saving of time.
The users of the vehicle are no need to waiting until vehicle becoming cool. So this
system keeps ready vehicle any time to travel.
3. Increases the life span of the vehicle interiors:
This system helps the vehicle interior to continue the long time. So it prevents damage of
vehicle interiors from the excess heat and rain water in rainy season.
4. Saving the fuel.
If vehicle kept in sun shine it may get overheat, to diminish that overheating the
user may switch on the AC of the vehicle. By utilizing the this system the user may not
require

to switch on the AC, so it automatically reduces usage of AC ,it reflects the fuel

saving.

65

5. Saving money.
Microcontroller managed automatic ventilation system, it reduces the fuel usage,
increases the life span of the system, provides the safety for the vehicle interiors so that
ultimately reflects that money saving.
6. Easy maintenance.
By using the, high end technological device for vehicle safety, this device works
without human involvement because it is intelligent one and that too it does not require any
maintenance.

APPLICATIONS
1. cabs This systems is very useful in cabs, because the customers of the cab may
except the luxury of resources, this system meet their requirements.
2. Transport business.
The stated in the above, this system is not only used in cabs, but also in every
transportation bodies, why because that the Passengers may expect the comfortable journey.
3. Home and own vehicles
We can comfortably arrange this type of microcontroller based automatic ventilation for
houses, own vehicles for comfortable living, comfortable journeys respectively.

66

CHAPTER-9
CONCLUSION AND FUTURE SCOPE
Conclusion:
It can be summarized that this module, although only a prototype, is completely
functional device that performs its function safely, reliably and efficiently.

Possibility of

application is not limited only to the vehicle ventilation. The module is extremely expandable
in both ways: it is upgradeable for new tasks as well as compatible for integration into
some existing systems. Nearly every component can be used for several other functions, which
can be achieved only by software upgrade.

Upgrading hardware

opens

even

greater

possibility to upgrade the software and there are countless capabilities. Despite all the
positive sides of this module, the question remains whether it can find its application in the
market. Since the module is impracticable as a physical unit (because of peripheral unit),
it is necessary to adapt it to any individual vehicle. Thus its individual installation is not
cost-effective. It could find its purpose and economic efficiency if it would be serially mounted
in same type of vehicle.

Future Scope:
Microcontroller managed automatic ventilation system a main advantage is extendibility.
As per our requirement we can extend the Microcontroller managed automatic ventilation system
features .By adding additional sensors, communicating equipment in order to increase coverage
area. In next five years, utility for Microcontroller managed automatic ventilation system in cabs
,houses and all other transporting business my grow more and more.

67

CHAPTER-10
REFERENCES
1.

Slobodan Ribaric, Advanced microprocessor architectures, Element, 1999, IEEE

Trans. Computers, vol. 52, no. 5, pp. 545-557, May 2003.

2.

T. M. Ladwa, S. M. Ladwa, R. S. Kaarthik, A. R. Dhara and N.Dalei, Automatic

ventilation of vehicle interior,International Conference on Instrumentation,
Communications,Information

Technology,

and

Biomedical Engineering

(ICICIBME), Bandung, Indonesia, 2009.

3.

International Workshop on Intelligent Data Acquisition and Advanced Computing

Systems:

Technologyand Applications, Rende (Cosenza), Italy 21-23

September 2009.
4.

Boric Raic, Module for automatic raising and lowering car windows, unpublished
EEE TRANSACTIONS

ON

Information

and Communication Technology,

(MIPRO) 26-30,May 2014

5.

Leo Budin, Microcomputers and microcontrollers, Element, 2004.

6.

Slobodan Ribari, Advanced microprocessor architectures, Element, 1999.

7.

Antun arevi, Electronic components and analog circuits, Technical school

of Ruer Bokovi, 1996.

8.

Aleksandar Szabo, Impulse and digital electronics part 1, Technical school

of Ruer Bokovi, 2000.

9.

Aleksandar Szabo, Industrial electronics, Technical school of Ruer Bokovi,

1996.

10.

Stanko Paunovi, Digital electronics part 1, kolska knjiga, 2005.

11.

Hans Brklin, The whole electronics Main catalog 92, datasheet, 1991.

12.

Atmel Corp., AVR ATmega32 (L), datasheet, 2011.

68

13.

www.atmel.com/images/doc2503.pdf

14.

http://www.besyoautoparts.com/Products_hb.asp?id=1704

15.

Velleman nv, PIR416, user manual, 2011.

16.

http://www.velleman.eu/downloads/3/pir416a705.pdf

17.

SOAN Electronic Technology Co., Ltd., KG001-12, user manual

18.

http://www.savebase.com/infobase/downloads/Kris_products/KG001-12V.pdf

19.

Boris Rai, Module for automatic raising and lowering car windows, unpublished.

20.

Leo Budin, Microcomputers and microcontrollers, Element, 2004.

21.

Antun Sarcevic, Electronic componentsand analog circuits, Technical school of

Ruder Boskovic, 1996.

22.

Aleksandar Szabo, Impulse and digital electronics part 1, Technical school of

Ruder Boskovic, 2000.

23.

D. Heb, C. Rohrig. Remote ventilation control, IEEE

24.

M. Callahan Jr, Vehicle ventilation, IEEE Transaction

25.

Son communications, vol. 27, pp. 343-348, February, 1979.

26.

Guangzhou Besyo auto parts Co, Ltd., BY-R606N, brochure

69