![](https://csdnimg.cn/release/download_crawler_static/10658592/bg10.jpg)
Elsevier US Prelims-H8583 3-8-2007 8:31p.m. Page:xv Trimsize:7.5×9.25in
Fonts:Times & Legacy Sans Margins:Top:48pt Gutter:60pt Font Size:11/14 Text Width:34.6pc Depth:37 Lines
xv Introduction
3. Implement the software (UI).
4. Try the device with the UI and refine and/or reimplement as necessary.
However, we do not live in an ideal world.
In the real world, the complexity of the software and the time-to-market constraints demand
that software is largely completed long before hardware is available. Indeed, much of the
work typically needs to be done even before the hardware design is finished. An approach to
this dilemma is to use prototyping technology. With modern simulation technology, you can
run your code, together with any real-time operating system (for example, RTOS) on your
development computer (Windows, Linux, or UNIX), and link it to a graphical representation
of the UI. This enables developers to interact with the software as if they were holding the
device in their hand. This capability makes checking out all the subtle UI interactions a
breeze.
I.2 Reusable Software
Ask long-serving embedded software engineers what initially attracted them to this field of
work and you will get various answers. Commonly though, the idea of being able to create
something was the appeal. Compared with programming a conventional computer,
constrained by the operating system and lots of other software, programming an embedded
system seemed like working in an environment where the developer could be in total
control. (The author, for one, admits to a megalomaniac streak.)
However, things have changed. Applications are now sufficiently large and complex that it
is usual for a team of software engineers to be involved. The size of the application means
that an individual could never complete the work in time; the complexity means that few
engineers would have the broad skill set. With increasingly short times to market, there is a
great incentive to reuse existing code, whether from within the company or licensed from
outside.
The reuse of designs—of intellectual property in general—is common and well accepted in
the hardware design world. For desktop software, it is now the common implementation
strategy. Embedded software engineers tend to be conservative and are not early adopters of
new ideas, but this tendency needs to change.
I.2.1 Software Components
It is increasingly understood that code reuse is essential. The arguments for licensing
software components are compelling, but a review of the possibilities is worthwhile.
www.newnespress.com