Page 1 of 9 - Cover Page Submission ID trn:oid:::3618:73458039
6658_Es_AAt2.pdf
Institute of Aeronautical Engineering (IARE)
Document Details
Submission ID
trn:oid:::3618:73458039 6 Pages
Submission Date 1,566 Words
Dec 9, 2024, 10:10 AM GMT+5:30
9,184 Characters
Download Date
Dec 9, 2024, 10:48 AM GMT+5:30
File Name
6658_Es_AAt2.pdf
File Size
176.6 KB
Page 1 of 9 - Cover Page Submission ID trn:oid:::3618:73458039
Page 2 of 9 - Integrity Overview Submission ID trn:oid:::3618:73458039
6% Overall Similarity
The combined total of all matches, including overlapping sources, for each database.
Filtered from the Report
Bibliography
Match Groups Top Sources
10 Not Cited or Quoted 6% 3% Internet sources
Matches with neither in-text citation nor quotation marks
5% Publications
0 Missing Quotations 0% 0% Submitted works (Student Papers)
Matches that are still very similar to source material
0 Missing Citation 0%
Matches that have quotation marks, but no in-text citation
0 Cited and Quoted 0%
Matches with in-text citation present, but no quotation marks
Integrity Flags
0 Integrity Flags for Review
Our system's algorithms look deeply at a document for any inconsistencies that
No suspicious text manipulations found. would set it apart from a normal submission. If we notice something strange, we flag
it for you to review.
A Flag is not necessarily an indicator of a problem. However, we'd recommend you
focus your attention there for further review.
Page 2 of 9 - Integrity Overview Submission ID trn:oid:::3618:73458039
Page 3 of 9 - Integrity Overview Submission ID trn:oid:::3618:73458039
Match Groups Top Sources
10 Not Cited or Quoted 6% 3% Internet sources
Matches with neither in-text citation nor quotation marks
5% Publications
0 Missing Quotations 0% 0% Submitted works (Student Papers)
Matches that are still very similar to source material
0 Missing Citation 0%
Matches that have quotation marks, but no in-text citation
0 Cited and Quoted 0%
Matches with in-text citation present, but no quotation marks
Top Sources
The sources with the highest number of matches within the submission. Overlapping sources will not be displayed.
1 Internet
[Link] 2%
2 Publication
Jae-Ho Lee, Heung-Nam Kim. "Implementing priority inheritance semaphore on … 1%
3 Publication
Synchronization in Real-Time Systems, 1991. 1%
4 Publication
A.J. Wellings. "Scheduling time constrained messages on miniMAP", Proceedings … 1%
5 Internet
[Link] 1%
6 Publication
Pranabananda Chakraborty. "Operating Systems - Evolutionary Concepts and Mo… 0%
Page 3 of 9 - Integrity Overview Submission ID trn:oid:::3618:73458039
Page 4 of 9 - Integrity Submission Submission ID trn:oid:::3618:73458039
AAT -2 ASSIGNMENT
EMBEDDED SYSTEMS – AECC40
[Link] -21951A6658
1. llustrate the working of microwave oven with neat diagram..
• Requirements: These are typically higher-level, conceptual goals that the
system needs to fulfill. They often focus on what the system should do
(functional requirements) and constraints (non-functional requirements).
Requirements are the foundational building blocks of a project. For
instance, "The system should process data in real-time," or "The embedded
system should operate under harsh environmental conditions like extreme
temperatures" are examples of requirements.
• Specifications: These are technical and detailed descriptions that break
down the requirements into concrete terms. They define how the system
will fulfill the requirements in measurable terms. For example, the
specification for the "real-time" requirement might specify that "The
system should process a batch of 1000 data points every 10 milliseconds."
Specifications give the design and development teams a clear, actionable
framework to implement.
In essence, requirements are the "what" the system needs to do, while
specifications define the "how" it will be achieved.
2. Discuss the non- operational quality attributes of embedded computing
applications.
In embedded systems, particularly those used in critical applications like
automotive, medical devices, or aerospace, non-operational quality attributes are
crucial for system longevity and reliability. Here are some additional details about
the non-operational quality attributes:
• Fault Tolerance: In embedded systems, fault tolerance is essential,
particularly when operating in environments where failure is costly or
dangerous (e.g., automotive safety systems or medical devices). The
system should gracefully recover from errors, ensuring minimal disruption.
• Real-time Constraints: Many embedded systems must perform actions
4 within a specific time frame. These constraints can be hard real-time
4 (where failure to meet the deadline can lead to catastrophic results) or soft
Page 4 of 9 - Integrity Submission Submission ID trn:oid:::3618:73458039
Page 5 of 9 - Integrity Submission Submission ID trn:oid:::3618:73458039
real-time (where missing a deadline degrades performance but doesn't
necessarily cause failure).
• Usability: Embedded systems often interface with humans, so usability, or
6 how easy it is for the user to interact with the system, is an important non-
functional attribute. This could involve providing intuitive interfaces, clear
visual indicators, or appropriate feedback mechanisms.
3. Explain the purpose of TxD and RxDinserial communication of 8051
microcontroller.
• TxD (Transmit Data): The TxD pin is used by the 8051 microcontroller
to send out data in serial form (one bit at a time) to peripheral devices like
sensors, other microcontrollers, or a serial terminal. It is essential for
communication in UART (Universal Asynchronous
Receiver/Transmitter) mode, allowing the microcontroller to
communicate asynchronously with other devices.
• RxD (Receive Data): The RxD pin is used by the 8051 microcontroller to
receive serial data from external devices. When the microcontroller is set
to receive data, it listens for signals on this pin, where it captures the
incoming data stream and processes it accordingly. This allows two-way
communication between the 8051 and peripherals.
Together, TxD and RxD facilitate bidirectional serial communication, which is
widely used in embedded systems for efficient, long-distance data transfer with
minimal wiring.
4. Define switch bounce.
Switch bounce can lead to multiple transitions in the signal sent to a
microcontroller, even though the user intended only a single press or release. This
can cause the system to misinterpret the action.
• Software Debouncing: This is the simplest way to address switch bounce.
It involves adding a small delay after each signal change to ensure that
multiple bounces are ignored, typically by checking the signal again after
a short period (e.g., 5–50 milliseconds).
• Hardware Debouncing: This method uses components like capacitors or
Schmitt triggers to filter out the noise caused by bounce before it reaches
Page 5 of 9 - Integrity Submission Submission ID trn:oid:::3618:73458039
Page 6 of 9 - Integrity Submission Submission ID trn:oid:::3618:73458039
the microcontroller. Capacitors can smooth the transitions, while Schmitt
triggers provide clean digital edges.
Switch bounce can be a significant issue in embedded systems, particularly when
using mechanical switches, so it must be handled effectively to ensure reliable
user input.
5. Make use of different methods to handle deadlocks in operating systems
Here are further insights into dealing with deadlocks in real-time and embedded
operating systems:
• Deadlock Prevention: One classic approach to deadlock prevention is
ensuring that the system does not allow circular wait conditions by
enforcing a strict order in which resources can be requested, or by
eliminating hold and wait by requiring processes to request all needed
resources upfront.
• Deadlock Detection: In embedded systems where resources are limited
and real-time responses are crucial, deadlock detection might be tricky. The
operating system needs to periodically check if a deadlock has occurred by
tracking resource allocation and process states. If a deadlock is detected,
the system may need to abort one or more processes to resolve the issue.
• Deadlock Recovery: A common recovery technique involves using
process termination (killing processes that are involved in deadlock) or
resource preemption (taking resources from lower-priority processes and
reallocating them to higher-priority ones). For real-time embedded
systems, deadlock recovery mechanisms must be efficient to avoid
disrupting critical operations.
1 6. Define priority inversion. What are the different techniques adopted for
handling priority inversion?
In embedded systems, priority inversion can significantly affect real-time
performance. To add more details:
2 • Priority Inheritance: In this approach, when a low-priority task holds a
resource that a high-priority task needs, the low-priority task temporarily
1 inherits the priority of the high-priority task. This prevents the high-priority
task from being blocked by intermediate-priority tasks.
• Priority Ceiling: This method involves assigning each resource a priority
3 ceiling. A task can only use resources if its priority is higher than the ceiling
Page 6 of 9 - Integrity Submission Submission ID trn:oid:::3618:73458039
Page 7 of 9 - Integrity Submission Submission ID trn:oid:::3618:73458039
3 of the resource. This ensures that no task with a lower priority can block a
higher-priority one.
Handling priority inversion is crucial in real-time embedded systems where the
time-critical tasks must not be delayed due to priority conflicts.
7. List out the laboratory instruments for testing the embedded system.
In addition to the basic instruments mentioned earlier, more advanced instruments
used in embedded system testing include:
• In-circuit Emulator (ICE): Allows debugging and real-time execution of
code on the embedded system, providing detailed insights into the
operation of the microcontroller during development.
• Spectrum Analyzer: Used to measure the frequency spectrum of signals,
which is helpful when diagnosing issues in communication and signal
processing in embedded systems.
• Environmental Chambers: Used to simulate extreme environmental
conditions (e.g., temperature, humidity) that the embedded system might
encounter in real-world deployment, such as in automotive or aerospace
applications.
• Signal Generator: A more advanced tool used for testing embedded
systems' response to varying input conditions, such as simulating
communication signals or input from sensors.
8. Discuss in detail about embedded software development process and tools.
Here are some of the tools used at various stages of embedded software
development:
• Code Editing and Compilation: Tools like Keil µVision, IAR
Embedded Workbench, and GCC (GNU Compiler Collection) are
commonly used to write and compile embedded C or assembly code.
• Version Control: Systems like Git or Subversion (SVN) help manage
code changes, especially in large teams.
• Simulation and Emulation Tools: Tools like Proteus and QEMU allow
developers to simulate embedded systems in software before deployment,
enabling debugging without hardware.
Page 7 of 9 - Integrity Submission Submission ID trn:oid:::3618:73458039
Page 8 of 9 - Integrity Submission Submission ID trn:oid:::3618:73458039
• Static Analysis: Tools such as PC-lint or Coverity help identify potential
bugs in the code before execution.
• Continuous Integration (CI) Tools: Systems like Jenkins or Travis CI
are increasingly used in embedded software development to automate
testing and ensure code quality.
9. Give examples of ARM assembly language instructions and their
corresponding operations.
Here are more ARM assembly instructions:
1 • AND R0, R1, R2: Performs a bitwise AND operation between registers R1
and R2, storing the result in R0.
• CMP R3, R4: Compares the contents of R3 and R4 without storing the
result, affecting the condition flags based on the comparison (useful for
conditional branching).
• BNE label: Branches to the specified label if the previous comparison
(CMP) did not result in equality (i.e., not equal).
• BL function: Branches to a function and links the return address, so the
program can return to the instruction following the function call.
10. Compare and contrast ARM architecture with other popular processor
architectures.
Expanding on the comparison:
• ARM:
o Low Power: ARM processors are designed with low power
consumption in mind, making them ideal for mobile devices,
wearables, and IoT.
o Scalability: ARM cores range from small, simple cores like the
ARM Cortex-M (for microcontrollers) to powerful cores like the
Cortex-A series (for smartphones, tablets, and even servers).
• x86:
o High Performance: x86 CPUs (by Intel and AMD) tend to be more
powerful and are widely used in PCs and servers. However, they
consume more power, which makes them less suitable for embedded
or mobile applications.
Page 8 of 9 - Integrity Submission Submission ID trn:oid:::3618:73458039
Page 9 of 9 - Integrity Submission Submission ID trn:oid:::3618:73458039
o Complex Instruction Set: Unlike ARM, x86 has a complex
instruction set with more powerful instructions for handling multi-
step operations in a single command, though this can lead to less
efficiency in terms of power consumption.
• MIPS:
o Embedded Focus: Like ARM, MIPS is often used in embedded
systems, networking devices, and set-top boxes. However, its market
share has been largely overtaken by ARM in recent years.
o Performance: MIPS processors have a simpler design similar to
ARM and offer efficient execution of basic tasks.
• RISC-V:
5 o Open Source: RISC-V is an open-source instruction set architecture
(ISA), which is gaining traction in embedded systems and research.
It offers more customization and freedom in design compared to
ARM and x86.
o Flexible: With RISC-V, companies can build processors with
specific needs, offering advantages in specialized embedded
applications.
In summary, ARM is highly preferred in the embedded space due to its balance
of power efficiency, performance, and scalability, while x86 is more dominant in
high-performance computing scenarios.
Page 9 of 9 - Integrity Submission Submission ID trn:oid:::3618:73458039