Cross-Paltform Development
Cross-Paltform Development
Cross-Paltform Development
development
Chifundo Polska Mlangeni
Cross-Platform Development Process
• Compared with nonembedded software, the development of embedded
software renders many unique challenges to software engineers:
• For embedded systems, especially for real-time embedded systems,
timing correctness is equally important as functional correctness.
Sometimes, a timing constraint is so important that it becomes an
integral part of the functional requirements.
• For example, although a GPS navigation system can always identify
waypoints correctly (functional correctness), it is useless if it is not able
to report the waypoints before it is too late for the user to take actions.
• Most embedded systems are “dumb” devices that cannot run a
debugger; this makes it hard to detect and clear program defects.
• For example, inside a refrigerator can handle inputs from its touchpad and door
sensor, provide output to a digital display, and control the cooling and icemaker
machinery. It, however, may not have “luxurious” resources reserved for
debugging.
• Most embedded systems are required to offer high reliability. For example, if a
system has a reliability requirement of four nines (i.e., 99.99% availability), it is
not tolerable if the downtime is greater than 9 s per day.
• High reliability is not a trivial objective especially for an embedded system that
may be operating in a hostile or an unexpected environment.
• Unpredictable event patterns from the environment may significantly change
an embedded system’s sequence of execution.
• Efficient utilization of the memory space is another challenge. More memory
means more monetary cost.
• Making software is a creative activity; making software that can fit into the
available memory space demands even more creativity.
• Power management is critical to prolong the operating time of an embedded
system. Being able to switch to a low-power state when inactive is a must-have
feature for many embedded systems.
• Owing to the uniqueness of embedded software, we need to distinguish two
terms: host platform and target platform.
• The term “host platform” refers to the computing environment (i.e., the
processor architecture and, if applicable, the operating system) upon which
software is developed and its executable artifact is built.
• In contrast, the term “target platform” refers to the computing environment
upon which software (actually its executable artifact) is intended to run.
• For most software systems running on general-purpose computers, the host
platform is the same as the target platform, and it is not necessary to
distinguish the two. However, for embedded software, its target platform is
typically different from its host platform.
Hardware Architecture
• As far as embedded systems are concerned, a hardware architecture is an abstract
representation of an electronic or an electromechanical device that contains
microprocessors, memory chips, and some peripherals (e.g., clocks, controllers, I/O
devices, sensors, and actuators) as needed to fulfill its expected functionality.
• Some common design factors related to hardware architecture design are as follows:
• Processing power. How fast a microprocessor will be required? A closely related
factor is the processor’s power consumption, typically expressed in terms of millions
of instructions per second per milliwatt. A more powerful processor generally means
higher power consumption, and a higher price too.
• Memory requirements. What types of random-access memory (RAM) and
nonvolatile memory (NVM) will be needed? For each type, how much memory will
be appropriate on the evaluation board
• how much will be appropriate on the target system? A design with more memory on the
evaluation board than what might be needed can often save a project that could have failed
otherwise. However, more than necessary will certainly increase the production cost.
• Peripherals. What peripherals are required? Some advanced processor designs, also called
microcontrollers or system-on-chip processors, have many built-in peripherals. Such a
processor, if chosen, may be able to meet the needs for peripherals already. In general, it is
advised to design a debugging interface (such as a serial port) on the evaluation board or the
target system. When choices need to be made, performance always has higher priority than
cost.
• A proven statement says that never use a $1.00 chip and expect the performance of a
$10.00 chip.
• Reliability. Should the system be fail-proof? May it fail occasionally? What is the tolerable
downtime?
• Future upgrade. How will field upgrades be performed?
Software Design
• Software design includes software architecture design, task design, and
schedulability analysis:
• Software architecture design. How are different functional modules interrelated
and synchronized?.
• Task design. How many tasks should be considered? How should one assign
priorities to those tasks? How should one document the task design and the
timing constraints associated with the tasks?
• Schedulability analysis. As far as the identified timing constraints are concerned,
is the set of tasks schedulable?.
THANK YOU