嵌入式 DSP 开发实战：从需求到量产的全流程指南英文版 电子书-159页

嵌入式 DSP 开发实战：从需求到量产的全流程指南（HOW THE PROS DEVELOP EMBEDDED SOFTWARE）英文版

摘要：

本书是嵌入式 DSP 软件开发的实战指南，以语音替换装置项目为完整案例，覆盖从需求分析到量产验证的全流程。书中系统讲解需求建模、面向对象架构设计、成本估算、硬件适配、模块设计、编码规范、调试排错、集成验证与安全设计等核心环节，结合 TMS320VC5416 DSP 平台与 C 语言、汇编实现，详解 DMA、音频 Codec、串口、滤波、基音检测、波形合成等关键模块开发。同时提供开发环境搭建、团队协作、项目管理与问题解决方法，兼顾工程实践与规范流程，适合嵌入式与 DSP 开发人员快速掌握量产级开发方法。

HOW THE PROS DEVELOP EMBEDDED SOFTWARE

 A no-nonsense guide for developers

INTRODUCTION

Too many books on embedded software development deliver conceptually

elegant models of the development process, but lack the down-to-earth details of how to actually get the job done.

This no-nonsense guide fills in those details by showing an actual project from start to finish, and all of the methods and documents created along the way.  This information comes directly from the author's 20 years of experience. developing embedded software for electronic products made by top U.S. corporations

This guide walks the reader through the creation of a typical embedded application, a voice controlled synthesizer, from requirements an alysis through validation.

It is intended that a programmer with no previous embedded experience can read this book, and feel neither lost nor out of place in his first embedded project.  The new embedded developer may use the methods in this book as a starting point for his own collection of techniques.

The sample application is called a voice substitution device.  It measures the   fundamental frequency, if any, in an input signal; and substitutes a synthesized waveform of the same frequency in the output.  Hopefully, this example is challenging enough to illustrate most common embedded development practices.

SOME DEFINITIONS

An embedded system is an information appliance that is supplied with sensors  and effecters which permit it to interact with the external environment.  It uses a microprocessor to control the sensors and effecters, and software to guide its   interpretation of incoming signals, and its production of outgoing signals.

The memory chips, processor, input and output peripherals, sensors and effecters comprise the hardware of the embedded system.  The bit sequence in the memory chip is called the software of the embedded system.

Embedded systems are collections of interacting components.  The definitions below provide a framework for discussing those collections further.

Every component of an embedded system which interacts with other components is called an object. Each object is distinct from other objects, has an internal state, and exhibits a repertoire of behavior.  Objects exhibit their behavior by exchanging messages with other objects.  A message is an influence that passes between objects.

Objects may be hardware or virtual.  A hardware object is made out of material parts.  A virtual object is simulated in software.

Objects may be composed of other objects.  A compound object is an object which is  composed of other objects.  A mixed object is a compound object composed of some hardware and some virtual objects.

THE CONCEPTUAL MAP

Software developers create bit sequences that go into memory chips.

The typical developer cannot listen to a description of desired system behavior, and then just dash off a bit sequence that does the trick.  Instead, he must create a conceptual map of the problem to be solved, and all of the elements that make up a solution.  This conceptual map has both a material and a mental form.

MATERIAL CONCEPTUAL MAP

The material form of the conceptual map is a collection of data sheets, an alysis and design documents, interviews, and meeting minutes which bear on the

project. These documents are usually kept organized and readily accessible to each member of the team.

MENTAL CONCEPTUAL MAP

The mental form of the conceptual map is a representation in each team member's mind of the environment, goals, hardware, and software objects, and the ways in which they interact.

The dreaded "learning curve" of an embedded project is the time necessary for a new team member to create, from conversations and from the project's material conceptual map,  a mental conceptual map for the project.

LAYERS OF THE CONCEPTUAL MAP

It can be helpful to subdivide the conceptual map into different layers of

concepts, each of which deals with different portions of the mapping between the real external world, and the embedded software which interacts with it.

The diagram below shows one such subdivision of an embedded project's conceptual map:

In this diagram, the subdivisions of the conceptual map relate to the flow of information in the embedded system.  Information flows in from the external process layer through the hardware layer, is transformed by the virtual machine layer, and processed by the application layer.  Response information is sent back out via the virtual machine layer, through the hardware layer, into the external process layer.

In the external process layer,  the embedded system is considered as a unit which exchanges influences with the external world.  The concepts in this layer describe in a general way each of those interactions.  They also describe in measurable detail every aspect of those interactions which motivated the building of the system.

The hardware layer of the conceptual map contains data sheets, schematics, and concepts related to the operation of the embedded system hardware.

Documentation is provided by hardware vendors and designers for the processor, peripherals, sensors, effecters, memory chips, comm chips, and power supplies.

The layer between the hardware and the application is called the virtual machine layer.  It describes the virtual (software-simulated) objects through which the application accesses the hardware, and organizes itself in time.  These virtual objects include the primitives of the programming language, the operating system (if any), and any I/O drivers supplied with the operating system or written separately.  Some of the concepts and documents for this layer are supplied by  language and operating system vendors, and some are created by the developers.

The application layer is a collection of virtual objects which interact to model the external process and/or exchange influences with it via the virtual machine and hardware layers.  This layer is mostly invented and documented by the developers.  It may also include virtual objects supplied in code libraries by the system sponsor, or by third party vendors.

The quality of the conceptual map, in both its physical and mental forms, figures prominently in the success orfailure of an embedded project.

If the team members have access to a well organized collection of system documents, and if they take the time to read and understand those documents; the project has a much higher prospect of success than if they do not.

 A final word about the conceptual map. A belief persists among some  developers, typically the more hardware oriented, that real engineers don't write  documentation. There is some justification for this position. In a s mall system,  not too complex, it is possible to write code for the system without documenting 

the conceptual map.

Troubles arise only when the number of callable functions exceeds a couple of  hundred, and/or there is frequent turnover in the engineering staff, or safety and regulatory issues require full disclosure of the development process.

Throughout this book, various methods will be used to document the conceptual map, be it in requirements, architecture, or design documents. If the reader is convinced that documenting is gilding the lily, then he will surely ignore these methods.

Nikola Tesla, arguably the Earth's greatest engineer, kept most of his plans and notes (except for patent applications) in his head. Mr. Tesla was the acknowledged master of the mental conceptual map. Perhaps that is why some of his greatest inventions weren't rediscovered until many years after his death.

 Just as some engineers favor sparse documentation, others prefer rich documentation. These are persons who require more rigor than that supplied in the methods used here. Those readers will no doubt feel free to use their own methods of documenting the conceptual map, or adopt methods that may be found in abundance in the literature.

DEVELOPMENT PROCESSES

 The software developer's task is to complete the conceptual map of the embedded system, and to implement and test it's virtual objects on the target hardware. This requires her to discover and document the system's required interactions with the outer world, learn how the hardware works, understand the virtual machine, invent the interacting virtual objects of the application, and debug and test their operation. To these ends, the developer participates in the processes described below.

•  AN ALYSIS

 Develop descriptions of the external process and the desired useful ways of interacting with it. Formulate a complete set of measurable goals for the embedded system to meet. Digest the vendor and hardware designer supplied documentation of the hardware and virtual machine. Understand any predecessor systems. If system safety is a concern, perform an initial study of the hazards created by the system, and possible ways of mitigating those hazards.

•  ARCHITECTURE

 Describe in overview how the hardware and virtual objects work together 

to interact with the external process. Put the description into an 

architectural document. Revise ana lysis concepts where necessary to 

accommodate real-world facts revealed by the architecture.

•  ESTIMATING

For planning purposes, break the remaining software development process into s mall chunks, and estimate how much effort of how many persons will be required to complete each chunk. Make some guesses 

about the number of lines of code, and function points required, and estimate total project resources from those estimates.

•  HARDWARE SUPPORT

Support the persons developing the embedded system hardware by writing test code. Use the information gained from writing the test code to improve the architecture and assist with the design of the system. In some cases incorporate the test code directly into the final system code.

•  DESIGN

Create an orderly description of a collection of virtual objects, which implement the system architecture. Document the collection in a design document. Review the design document with team members and third parties. Make sure the design will result in a system that meets its goals and operates safely. Revise an alysis and architectural concepts as necessary to accommodate changes motivated by the design process.

• CODE

Implement in the chosen languages, all invented virtual objects, including those in the virtual machine. Revise ana lysis, architecture, and design as needed.

•  DEBUG

Make all of the hardware and virtual objects work as intended. Revise an alysis, architecture, design and code as needed.

•  INTEGRATION

Make all of the hardware and virtual objects interact in the way envisioned in the architecture and design. Revise ana lysis, architecture, design and code as needed.

•  VERIFICATION

 Formally demonstrate that the virtual objects work properly. Revise all above as needed.

•  VALIDATION

Formally demonstrate that the overall embedded system meets the goals it was intended to meet. Revise all above as needed.

 The processes described above will be considered in more detail in the next few sections of this book

ANA LYSIS

 A better heading for this chapter might be "Learning".

 Whether you come in at the beginning or some time during the middle of a project, your first task is to learn everything there is to know about the project. In no particular order, you need to know:

 1) Why is this project happening?

 2) What persons support the project?

 3) What persons oppose the project?

 4) Is this a new product, or a new version of an older product?

 5) What are the technical goals of the project?

 6) What is the technical environment of the project?

 7) Are project resources adequate to support your efforts?

 8) What is the expected schedule for the project? Is it realistic?

 9) What are the skills, strengths, and weaknesses of other team members?

 10) Which team members do you like? Which ones can you trust? What are their skill sets?

 11) Is product safety an issue? If so, does the resource provider support an emphasis on product safety?

 You won't answer all these questions immediately. In fact, you may never answer all of these questions; but these are things you should find out as soon as possible after coming into a new project.

Now you may say: "Look man, I'm just a programmer on this project. I do my work, they write my check. What do I care about all that political stuff?"That may be so, but you are also responsible for your own life, and a medium sized embedded project is going to account for a big chunk of the next couple of years of your life. It's going to affect your relationships, and your happiness for as long as you are involved. Better to know what you are walking into, than to stumble blindly into a disaster in the making.

 Project Motivation and Support

 Why is this project happening? Ask around. Normally, you will find someone who champions the project. Get to know that person. What is their motivation?  If they get a spark in their eye when they talk about the project, that is a good sign. If they are just occupying an organizational position and carrying out policy, that may still be OK. If they are looking to make a lot of money, that is probably a bad sign. There are much easier ways to make money.

It's can be tough at first to find out, but you need to know the primate power relationships within the organization, as they relate to the project champion. He may be on the way out, in which case you'll have to find another situation. Make sure the project champion has the support of the main monkeys within the 

organization.

Next feel out the network of technical personnel. Have they been with the organization a long time, or did they just arrive. If the latter, are they replacing people who just left? Why? How is the morale of the technical staff? If they spend more time talking about the organization than about the work, get out of  there fast.

Does your entry into the project ignite professional jealousy in anyone on the staff? If so, acquaint yourself with that person. Once you get to know each other, the problem will likely go away. You will have a new friend. If that doesn't happen, keep your eye on that person.

Once you are comfortable with the project motivation and personnel, you are ready to enjoy the first technical challenge: discovering the requirements.

详细内容请见附件

免责声明：

本页面/内容部分素材来源于互联网公 开 信 息，旨在传递更多信息，不代表本平台立场。

版权归原作者或机构所有，如涉及侵权，请通过平台联系我们，我们将在核实后第一时间处理。

本平台对转载内容的真实性、准确性不作任何保证，用户需自行判断并承担使用风险。