0% found this document useful (0 votes)
5 views25 pages

BEC601 Module 2

Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
5 views25 pages

BEC601 Module 2

Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd

Module 2

[Link] the operation and non-operational quality attributes of an embedded system.(2


times)

Answer:
[Link] (i)DFG and CDFG models with an example. (ii)C v/s embedded C (iii)Compiler v/s
cross compiler.

Answer:

ii)
iii)

[Link] the assembly language based embedded firmware development with a diagram and
mention its advantages and disadvantages.

Answer:
Assembly language based embedded firmware development involves using a processor-
specific, low-level language that translates directly to machine code using an assembler. This
approach o ers direct hardware control and performance optimization at the cost of increased
development complexity and reduced portability.

The Assembly Language Development Process

The general process for assembly language based embedded firmware development follows
these steps:

1. Code Creation: The programmer writes the firmware using a text editor, saving it as a
source file with an .asm or .src extension. This code uses mnemonic instructions
specific to the target processor (e.g., MOV A, 30 for an 8051 chip).

2. Assembly: An assembler program converts the assembly source code into machine
code (object file, typically with an .obj extension). The assembler also generates a list
file (.lst), which lists opcodes, addresses, and any detected errors.

3. Linking: The object files are processed by a linker to produce an absolute object file
(.abs), which contains the final machine code.

4. Hex File Conversion: An object-to-hex converter (like "OH" for 8051) creates a
final .hex file, which is ready to be "burned" or loaded into the embedded system's
permanent memory (ROM/Flash).

A general diagram of the process looks like this:


[Source Code (.asm)] -> [Assembler] -> [Object File (.obj)] -> [Linker] -> [Absolute Object
File (.abs)] -> [Object to Hex Converter (OH)] -> [Executable Hex File (.hex)]

Advantages and Disadvantages

Advantages
Filo +1

 High Performance/Speed: Assembly programs are highly e icient and fast because
they are very close to machine code and allow direct control over the CPU's instructions
and execution timing.

 Direct Hardware Control: Programmers have complete access to hardware registers,


I/O ports, and specialized processor instructions, which is essential for writing device
drivers, handling interrupts, and low-level system operations.

 E icient Memory Usage/Small Code Size: Assembly code tends to be very compact,
using less memory than high-level language programs, which is crucial for memory-
constrained embedded systems.

 Precise Timing: It allows for exact control over program execution time, which is critical
for real-time applications and operations requiring highly accurate timing.

GeeksforGeeks +2

Disadvantages

Filo +1

 Complexity: Assembly language is di icult to learn, read, and write, requiring a deep
understanding of the specific target processor's architecture and instruction set.

 Time-Consuming Development: Writing, debugging, and maintaining assembly code


takes significantly more time compared to higher-level languages due to the lack of
abstraction and manual management of low-level details.

 Poor Portability: Assembly programs are machine-specific and are not portable across
di erent processor architectures. Code written for one system must be rewritten for a
di erent one.

 Error-Prone: The lack of safety nets and abstractions makes it easier to introduce errors
and bugs, which can be challenging to debug and a ect system reliability

[Link] coin operated telephone system with a FSM, function of states and state
transition diagram.

Answer:
A coin-operated telephone system can be modeled using a Finite State Machine (FSM),
where the system transitions between di erent states based on user inputs such as coin
insertion, dialing, and call completion.

States and Their Functions

1. S0 – Idle State

o Initial state of the system

o Waits for user to insert a coin

2. S1 – Coin Inserted State

o Detects and validates the coin


o If valid → proceed

o If invalid → return coin

3. S2 – Dial Tone State

o Provides dial tone to user

o Indicates system is ready to accept number

4. S3 – Dialing State

o User enters phone number

o Checks validity of number

5. S4 – Call Connected State

o Establishes communication

o Timer monitors call duration

6. S5 – Call End State

o Call is terminated after completion or timeout

o System prepares to reset

7. S6 – Return Coin State

o Returns coin if call is not completed

o System goes back to idle

State Transition Diagram

+--------+
| S0 |
| Idle |
+---+----+
|
| Coin Inserted
v
+--------+
| S1 |
| Coin |
+---+----+
/ \
Valid / \ Invalid
v v
+--------+ +--------+
| S2 | | S6 |
| Dial | | Return |
+---+----+ +--------+
|
| Dial Number
v
+--------+
| S3 |
| Dialing|
+---+----+
|
| Valid Number
v
+--------+
| S4 |
| Call |
+---+----+
|
| End/Timeout
v
+--------+
| S5 |
| End |
+---+----+
|
v
S0

State Transition Table

Present State Input Condition Next State

S0 Coin inserted S1

S1 Valid coin S2

S1 Invalid coin S6

S2 Dial input S3

S3 Valid number S4

S3 Invalid number S6

S4 Call समा / timeout S5

S5 Reset S0

S6 Coin returned S0

Conclusion
The FSM model ensures proper operation of the coin-operated telephone by:

 Handling user inputs systematically

 Validating coins and numbers

 Controlling call connection and termination

Thus, FSM provides a reliable and structured control mechanism for embedded systems
like coin-operated telephones.

[Link] the domain specific aspect of embedded systems with automotive domain as an
example.

Answer:

Embedded systems are often domain-specific, meaning they are designed for a particular
application area with unique requirements.
Each domain (like automotive, medical, or consumer electronics) has its own constraints,
standards, and functionalities.

The automotive domain is a major example where embedded systems are widely used for
control, safety, and automation.

Automotive Embedded Systems

Modern vehicles contain multiple embedded systems called Electronic Control Units (ECUs)
that manage di erent functions.

Examples:

 Engine Control Unit (ECU)

 Anti-lock Braking System (ABS)

 Airbag Control System

 Infotainment system

 Cruise control

Domain-Specific Characteristics (Automotive)

1. Real-Time Constraints

 Systems must respond within strict time limits

 Example: Airbag must deploy within milliseconds

2. Safety-Critical Operation
 Failure can cause accidents

 Must follow safety standards like ISO 26262

3. Reliability & Robustness

 Must work under harsh conditions:

o Temperature variations

o Vibrations

o Electrical noise

4. Low Power Consumption

 Important for battery e iciency

5. Communication Protocols

 Multiple ECUs communicate using:

o CAN (Controller Area Network)

o LIN, FlexRay

6. Cost and Size Constraints

 Must be compact and cost-e ective for mass production

Block Diagram of Automotive Embedded System

+----------------------+
| Sensors |
| (Speed, Temp, etc.) |
+----------+-----------+
|
v
+----------------------+
| Microcontroller |
| (Embedded System) |
+----------+-----------+
|
v
+----------------------+
| Actuators |
| (Brakes, Engine) |
+----------------------+
|
v
+----------------------+
| Communication Bus |
| (CAN/LIN/FlexRay) |
+----------------------+

Advantages in Automotive Domain

 Improved safety (ABS, airbags)

 Better performance (engine optimization)

 Enhanced comfort (climate control, infotainment)

 Fuel e iciency

Challenges

 High design complexity

 Strict safety certification

 Debugging di iculty

 Cost constraints

Conclusion

The automotive domain highlights how embedded systems are tailored to meet specific
requirements like real-time response, safety, and reliability.
Thus, domain-specific design ensures e icient and safe operation of modern vehicles

[Link] drives/passenger ‘seat belt warning’ in an automotive using the FSM model. The
system requirements are captured as or( with the help of FSM model, explain the system design
and operation of automatic seat belt warning)-2times

i)When the vehicle ignition is turned ON and the seat belt is not fastened within 10 seconds of
ignition ON the system generates an alarm signal for 5 seconds.

ii)The alarm is turned OFF when the alarm time (5 seconds) expires or if the driver/passenger
fastens the belt or if the ignition switch is turned o . Whichever happens first

Answer:
[Link] the application specific aspect of embedded systems with washing machine as an
example or (Explain the working of washing machine with a neat functional diagram.) 2 times

Answer:
8. Design an automatic tea/co ee vending machine based on FSM model for the following
requirements. Or(.Design and automatic tea/co ee vending machine based on FSM model.) -2
times

i)The tea/co ee vending is initiated by user inserting a 5-rupee coin

ii)After inserting the coin, the user can either select ‘co ee’ or ‘tea’ or press ‘cancel’ to cancel
the order and take back the coin

Answer:
[Link] the characteristic and quality attributes of embedded system.

Answer:
[Link] the hardware and software co-design in embedded systems.

Answer:

Hardware and Software Co-design is a design methodology in embedded systems where


hardware and software are developed simultaneously to achieve optimal system
performance, cost, and power e iciency.

Instead of designing hardware first and software later, both are designed together
(concurrently).

Need for Co-Design

 Increasing system complexity

 Requirement of high performance

 Need for low power and cost optimization

 Faster time-to-market

Co-Design Process

1. System Specification

o Define overall functionality and requirements


2. Partitioning

o Divide system into:

 Hardware components

 Software components

3. Hardware Design

o Design processors, memory, ASIC/FPGA

4. Software Design

o Develop firmware, drivers, OS

5. Co-Simulation

o Simultaneous testing of hardware & software

6. Integration & Implementation

o Combine both and deploy in embedded system

Block Diagram

+----------------------+
| System Specification|
+----------+-----------+
|
v
+----------------------+
| Partitioning |
| (HW / SW Division) |
+-----+---------+------+
| |
v v
+-------------+ +-------------+
| Hardware | | Software |
| Design | | Design |
+------+------+ +------+------+
| |
+--------+-------+
v
+----------------------+
| Co-Simulation |
+----------+-----------+
|
v
+----------------------+
| Implementation |
+----------------------+
Key Features

 Parallel development of HW and SW

 Early verification through co-simulation

 E icient resource utilization

 Performance optimization

Advantages

1. Improved Performance

o Critical tasks implemented in hardware

2. Reduced Development Time

o Parallel design approach

3. Cost Optimization

o Balanced hardware-software usage

4. Flexibility

o Software can be updated easily

Disadvantages

1. Design Complexity

o Requires coordination between teams

2. High Initial Cost

o Tools and expertise required

3. Di icult Partitioning

o Deciding HW vs SW is challenging

Applications

 Automotive systems

 Consumer electronics

 IoT devices

 Communication systems
Conclusion

Hardware and software co-design is an e icient approach for developing modern


embedded systems, ensuring optimized performance, reduced time, and better system
reliability.

You might also like