Brainscape's Knowledge GenomeTM

Browse over 1 million classes created by top students, professors, publishers, and experts.


See full index

ECE 510 > EXAM 1 > Flashcards

EXAM 1 Flashcards

You may prefer our related Brainscape-certified flashcards:
Early Childhood Education flashcards
1
Q

Hard RTS

A
  • Must meet its deadline with zero flexibility ( or near-zero degree of flexibility)
  • Result is useless if computed after the dealine
  • If the deadline is missed, it can be catastrophic, costly, may involve human life or entire system damage
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

Soft RTS

A
  • There is a level of flexibility in meeting the deadline
  • Applied when
  • > Does not involve catastrophic failures
  • > It is still acceptable ( within a frame of tolerance)
  • > Can be somehow corrected by approximation, etc.
  • Occasional soft or permanent soft RTS
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

RTS Requirement

A

Computation must be finished before reaching a given deadline

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

Differentiation of Hard vs. Soft

A
  • Hard RTS – at deadline you have a deterministic value/action
  • Soft RTS – the value can be an estimation
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

Corrections for Hard and Soft

A
  • Hard systems make every effort in predicting if a pending deadline might be missed
  • > Anticipation of a missed deadline
  • > Envelope of deadline ‘safety zone’
  • > Able to apply corrective actions before a catastrophe
  • > Compensate by computing estimations forward instead relying on precise values
  • Soft systems may have recovery actions after the deadline is missed – think about resynchronization
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

Deterministic Character

A
  • In RTS, timing correctness complements functional correctness – they coexist
  • You work with functional and timing issues, and moreover, you synchronize functions by means of accepting/issuing timing events
  • RTS have substantial knowledge of the controlled environment as well as the controlled system itself
  • RTS have deterministic character
  • > Because the response time to a dedicated event is bonded
  • -> Fixed bonding
  • -> Flexible bonding
  • > Actions are taken in response to an event as known a-priori
  • > They are less adaptable to the changing environment
  • -> Dedication to a mission
  • -> Because of lack of adaptation they can be less robust
  • > Levels of determinism and robustness can be balanced (some form of adaptation may be permitted)
  • > This balancing is application specific
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

Round Robin Scheduling

A

Tasks all get an equal amount of time, sharing the processing unit equally. Typically, there is a variation of scheduling algorithms used, such as preemptive attributes allow a round robin scheduler to have higher priority task interrupt a task execution.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

Preemptive Priority Scheduling

A

Tasks are executed based of priority. This is often used in conjunction with another algorithm, such as round robin.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q

Objects

A
  • Special constructs that are the building blocks for application development for RTOS
  • > Tasks - concurrent and independent threads of execution that can compete for CPU execution time
  • > Semaphores - are token-like objects that can be incremented/decremented by tasks for synchronization or mutual exclusion
  • > Message queues - are buffer-like data structures that can be used for synchronization, mutual exclusion, and data exchange by passing messages between tasks.
  • Developers can combine these objects (and others) to solve common real-time problems such as concurrency, activity synchronization, and data communication
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

Services

A
  • Help developers to create applications
  • They comprise sets of API calls to kernel objects, or in general to facilitate timer management, interrupt handling, device I/O, and memory management
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

The five key characteristics of an RTOS

A
  • Reliability
  • Predictability
  • Performance
  • Compactness
  • Scalability
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

Reliability

A
  • One of the most important characteristics
  • Must need to operate for long periods of time without human intervention
  • Some may allow reset, others will not allow due to consequences
  • Reliability is influenced by all components (hardware and software)
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q

Predictability

A
  • Meeting time requirements
  • Deterministic - must have predictable behavior
  • Measuring:
  • > Testing time responses in different situations
  • > Computing the variance of the response times for each type of system call
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

Performance

A
  • How fast deadlines are met
  • Measuring:
  • > MCU MIPS
  • > Throughput - measure overall system performance
  • -> The rate at which a system can generate outputs based on inputs coming in
  • -> The amount of data transferred divided by the time taken (bps)
  • > Call-by-call
  • -> Use of timestamps to indicate when a system call started and when finished
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q

Compactness (plus weight and software size)

A
  • Physical size (final product)

- Resources taken (understanding memory requirements is very important

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q

Scalability

A
  • RTOS should scale-up (or scale-down) to meet a wide variety of applications
  • Depends on a number of functionalities used
  • Ability to add extra modules/services
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
17
Q

Tasks

A

An independent thread of execution, which it can compete with other tasks for execution.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
18
Q

Idle task

A
  • This is a system task of lowest priority executing an endless loop
  • Executed when no other task can run
  • It can be a user supplied routine
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
19
Q

Task execution states

A
  • Ready state
  • Blocked state
  • Running state
    Task states must be maintained by a kernel.
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
20
Q

Task in Running state

A
  • Task switching will need to swap register content
    • involved in task control execution
    • holding local variables/pointers
    • No need to swap global variables/pointers
  • A running task can move to the blocked state
    • By making a call that requests an unavailable resource
    • By making a call that requires to wait for an event to occur
    • By making a call to delay the task for some duration
  • In non-RTOS systems, you will need to have a register/memory model
21
Q

Task in Blocked state

A
  • Without being blocked by resources - it means, a lower priority task could not run (CPU starvation)
  • Blocking conditions include:
    • A semaphore token for which a task is waiting
    • A message, on which a task is waiting
    • A time delay imposed on the task
22
Q

Task creation and deletion

A
  • In non-RTOS systems, you want tasks to be in memory as static objects
    • Static memory allocation for data is preferred
    • Dynamic memory allocation will add a lot of complications
  • Creating a task is simply initializing it and moving to the Ready state
23
Q

Task Scheduling

A
  • In non-RTOS systems, there is a lot of freedom in designing a task scheduling algorithm
    • rule of thumb: simple approach first, then complicate later
    • include objects involved in blocking (semaphores/tokens, message queues)
  • preemption lock - used when a task is in a critical section of code, which cannot be preemted by other tasks ( also known as an atomic operation)
    • a mechanism is needed to support this feature
  • task completion
    • run-to-completion tasks vs. endless-loop tasks
  • An oversight is needed to detect and escape scheduler misbehavior
  • Use FSM approach to model the scheduler
24
Q

Semaphores and the types

A

A kernel object that one or more threads of execution can acquire or release for the purpose of synchronizaiton or mutual exclusion (token)
- Allows a task to carry out some operations or access a reasource
types:
- Binary semaphore
- Counting semaphore
-Mutual exclusion semaphore (Mutex)

25
Q

Binary semaphore

A
  • Can have a value {0-unavailable, 1-available}

- Treated as global resources (shared among all tasks that need them)

26
Q

Counting semaphore

A
  • Allows for issuing multiple tokens
  • uses a count to allow it to be acquired or released multiple times.
  • Limited use
27
Q

Mutual Exclusion (Mutex) semaphores

A
  • Special binary semaphore that supports ownership, resource access, etc. for avoiding problems inherent to mutual exclusion (use with resources)
  • holds task-ID
  • It can be released only by a task which acquired it.
28
Q

Semaphore use

A
  • Wait-and-signal semaphore
    • communication between two tasks for the purpose of synchronization without exchanging data (execution flow control)
    • tWaitTask can have higher priority
  • Multiple-task wait-and-signal semaphore
    • Sensor -> multiple_action
    • can be used with a counting semaphore
  • credit-tracking synchronization
  • single shared-resource-access synchronization
29
Q

Message Queue

A

A buffer-like object through which tasks and ISRs send and receive messages to communicate and synchronize with data.

  • Temporarily holds messages from a send until the intended receiver is ready to read them
  • Temporary decoupling of sending and receiving task (it frees the tasks from having to send and receive messages simultaneously)
30
Q

Message Queue states

A
  • Empty
  • Not empty
  • Full
31
Q

Message queue content

A
  • a temperature value
  • a bitmap to draw on a display
  • a text message to print on LCD
  • a keyboard event
  • a data packet to send over the network
32
Q

Why message queue vs. pointers to data

A
  • Keep copying to a minimum - copying data is expensive in embedded systems
  • allocate separate memory locations for a queue
  • use a concept of private buffers to communicate between task in a simple way
33
Q

Message queue design considerations

A 
Size
Organization
Access controls
Handling exceptions
Message order
- FIFO
- LIFO
34
Q

Message queue use

A
  • Non-interlocked, one-way data communication
    • simplest scenario: loosely-coupled
    • typically tSinkTask has higher priority
    • ISR use for tSourceTask
  • Interlocked, one-way data communication
    • communication requiring a handshake protocol
    • Use of a binary semaphore
    • Sender waits for confirmation
    • Blocking and non-blocking approach
    • A need for a FSM model of the protocol
  • Interlocked, two-way data communication
    • Bidirectional data flow; e.g., like a procedure call, or client/server
  • Broadcast communication
    • Sending to multiple tasks
    • Issue of message removal (detect of all tasks blocked situation)
35
Q

Event registers

A

Approach

  • processing is triggered by occurrence of events
  • event register associated with each task; and consists of a group of binary event flags to track the occurrence of specific events
  • There can be a global event register
  • Events are combined into a condition (logical function)
36
Q

Exception

A

An exception is any event that disrupts the normal execution of the processor and forces the processor into execution of special instructions in a privilege state

  • Synchronous:
    • For example: Division by zero; alignment problem w/ memory addressing
37
Q

Interrupt

A

An interrupt is an external asynchronous exception triggered by an event that an external hardware device generates

  • Asynchronous
    • external to current computing
    • For example: System reset; Data received by a subsystem
38
Q

Programmable Interrupt Controllers (PIC)

A
  • Low-pin MCU have one INT input; high-pin MCUs have more INT inputs, but this is frequently not enough
  • Interrupt control processing is handled externally by PIC
  • Implementations differ but provide two main functionalities:
    • Prioritization of multiple interrupt sources and flagging one of the highest priority
    • Offloading the core MCU from determining an interrupt source
  • They are programmable
    • Each interrupt request line has a priority assigned to it (mostly through software, but can be through hardware)
    • Support nested interrupts
    • Can be cascaded to allow for a large number of interrupt sources
39
Q

general exceptions

A
  • classification of exceptions
    • Asynchronous - non - maskable
    • Asynchronous - maskable
    • Synchronous - precise (instruction causing a problem is determined through program counter register)
    • Synchronous - imprecise (multiple causes exist due to pipelining, etc.)
  • Many MCUs have additional non-maskable interrupt input line (NMI)
  • Knowing the reason/source of exception helps to determine how the system is to recover from exception, if it is possible anyway
  • Priorities Highest to lowest
    • Asynchronous - non - maskable (system reset)
    • Synchronous - precise
    • Synchronous - imprecise
    • Asynchronous - maskable
  • External interrupts (except NMI) are the only exceptions that can be disabled by software
40
Q

Stack overflow

A

When data is copied onto the stack past the statically defined limits. This causes corruption.

41
Q

Exception timing

A

Interrupt response time
- Interrupt latency
– Time between interrupt signal and the ISR begins to execute
– includes interrupt acknowledgment and initial organization for processing
– influenced by a higher priority interrupt being executed at the time
– Influenced by time over the interrupt system is disabled and then later re-enabled by software
Split processing time
- interrupt processing can be split into two parts: necessary one (under masked interrupt system) and a dedicated daemon task that can be interrupted
- in such a case, an interrupt serves as a ‘semaphore’ for a daemon task
- Disadvantages
– total response time expands
– Daemon task may not run if there are other higher priority tasks waiting

42
Q

Hard timer

A
  • implemented by hardware
  • high-precision events
  • invokes an interrupt service
  • one of them can be used by a scheduler
  • Often limited number of hardware timers
43
Q

Soft timer

A
  • Scheduled through software activity
  • Non-high-precision mechanism
  • Should be used for timeout implementation
44
Q

Types of of multitasking schedulers

A
  • Cooperative Multitasking
  • Preemptive Multitasking
  • Time-Sharing Multitasking
  • Event driven
45
Q

Cooperative Multitasking

A

An inexpensive alternative to time-sharing multitasking
In a simple form - implements passing execution from one task to the scheduler when:
- certain number of instructions was executed ( similar to tick estimation for time-sharing multitasking
- Nothing important is to be done next by this task
- has to wait and there is hurry
- Scheduler decides to execute another task or get back to the original one
- non-preemptive; although preemptive concept can be added as well
Example: Each task has multiple leave-points to the scheduler i.e. call, goto, return, or return-from-int

46
Q

Preemptive Multitasking

A

Software decomposed into :
- one background task
- Multiple ISRs
Interrupts
- Hardware - external
- Hardware - internal (timers)
- Software (through INT instructions)
- Software-Hardware interrupt (non-conventional tricks depend on architecture)
– using output_pin to input_pin connection to create interrupt
– using logical high input and interrupt masking bit
- External interrupts require a hardware-based PIC
– an excellent approach to handle external interrupts
- resolves priority conflicts
- requires an ID passing protocol; INT-INTACK protocol

47
Q

Time-Sharing Multitasking

A
  • Full-scale multitasking
  • Scheduler is a super task - meaning it activates other application tasks
  • Scheduler is always activated by its own timer
  • Requires full task swapping and elimination of recursions (by design)
  • ISRs can be added as additional higher-priority routines
  • Task priorities are
    • Mostly fixed
    • Variable for a truly advanced scheduler
  • Scheduler jobs: update tasks states - decide which one to run - Pass execution
  • Task sequencing
    • all task have the same priority
    • based on different priority
    • task priority adjustment
48
Q

Event-Driven scheduler

A

Interrupt-drive systems
- system waits for interrupts ( similar to preemptive multitasking)
Energy sensitive applications
- System goes to sleep as frequently as possible to save energy
- MCUs with nano-Watt technology have many sleep levels
- system clock frequency change can also be used to decrease power consumption
– Higher-frequency clock operations are for time sensitive (main) threads/tasks
– low-frequency clock operations are reserved for background threads/tasks
- System awaits a tick or event to wake up and process
- in summary, MCU executes only when the application has something to do.

ECE 510 (1 decks)

Brainscape helps you reach your goals faster, through stronger study habits.
© 2024 Bold Learning Solutions. Terms and Conditions