COTS board include file - System Testing Criteria

System Testing Criteria

Listiing 9.1: COTS board include file

#ifdef COTS_BOARD

#define NUMBER_OF_HARDWARE_PORTS 4

#else

#define NUMBER_OF_HARDWARE_PORTS 6

#endif

Teams need only a few COTS boards for development since these boards have limited use once the final target is ready. The boards can also serve as good validation platforms and, in some cases, as good demonstration platforms at trade shows or for early adopter customers wanting a proof-of-concept platform.

Designing Embedded Communications Software

by T. Sridhar ISBN:157820125x

With this foundation, you explore a development model that addresses the complete range of issues in the design of embedded communications software, including real-time operating systems, hardware and software partitioning, layering, and protocol stacks.

Table of Contents

Designing Embedded Communications Software Foreword

Preface

Chapter 1 - Introduction

Chapter 2 - Software Considerations in Communications Systems Chapter 3 - Software Partitioning

Chapter 4 - Protocol Software

Chapter 5 - Tables and Other Data Structures Chapter 6 - Buffer and Timer Management Chapter 7 - Management Software

Chapter 8 - Multi-Board Communications Software Design Chapter 9 - Going About the Development

Appendix A- Examples from Commercial Systems Glossary of- Common Terms and Acronyms References

Index List of Figures List of Tables List of Listings List of Sidebars

9.4 Development Environments and Tools

Depending upon the processor, developers will need to license compilers or cross compilers that run on their host workstations. For example, a developer working with a VxWorks™ development environment under Windows™ for a target using the PowerPC™ 750 processor will need a cross compiler, linker, and loader running under VxWorks for the PowerPC processor. RTOS vendors may offer these tools as part of the development environment, such as the Tornado Development Environment from Wind River. Alternately, the developer may need to license the tools from a third-party vendor such as Green Hills.

Some RTOS vendors offer the source code for their operating systems as part of the development licensing agreement. This is more the exception than the rule. Most vendors offer only the object code for the operating system for the processor needed by the customer. In our example, Wind River will provide VxWorks object files for the PowerPC processor, which need to be linked into the application comprising the protocol tasks, OSAL, and management tasks, as shown in Figure 9.3 (a). Some system files include a few source files and include files which can be modified for the specific target hardware initialization, application startup, and timer interrupt handling.

Figure 9.3: Typical development environment

The cross-development tools for the PowerPC 750 are used to compile the source code for the application into PowerPC object code and linked with the VxWorks OS object files to build a loadable image to download to the target. The download happens through an Ethernet port on the target, which is designated as the management port. The image can also be burned into flash for a faster boot. For multi-board systems, a separate image is burned into flash on each board.

On startup, initialization status is displayed with diagnostic messages on a serial port. The messages can be viewed by connecting a terminal or a PC with a terminal emulation program with parameters set to match with those for the serial port on the board. The messages include initialization status for DRAM, SRAM, hardware controllers, and the creation of data structures and buffer pools. Once initialization is complete, each of the tasks wait on events in their main loop.

To debug on the target, developers need to compile with the debug option. The code can be debugged through the serial port or through a host-based debugger which connects with the target over an Ethernet or serial connection. A target server exists on the target to act as the “local representative” of the host-based debugger (see Figure 9.3 (b)). The sequence of operations is as follows:

The developer uses host-based GUI commands for debugging.

The debugger communicates to the target server.

Designing Embedded Communications Software

by T. Sridhar ISBN:157820125x

Table of Contents

Designing Embedded Communications Software Foreword

Preface

Chapter 1 - Introduction

Chapter 2 - Software Considerations in Communications Systems Chapter 3 - Software Partitioning

Chapter 4 - Protocol Software

Chapter 5 - Tables and Other Data Structures Chapter 6 - Buffer and Timer Management Chapter 7 - Management Software

Chapter 8 - Multi-Board Communications Software Design Chapter 9 - Going About the Development

Appendix A- Examples from Commercial Systems Glossary of- Common Terms and Acronyms References

Index List of Figures List of Tables List of Listings List of Sidebars

The target server performs the debug operations as though it were locally attached.

The target server sends the results of the debug operation to the host-based debugger.

Several RTOSes offer file system capabilities either in local RAM or a remote development station. In this case, it may be possible to mount a directory on a user development station as a file system on the target; then diagnostic information can be written to a file on the target system. The information is transmitted using a UDP or TCP connection from the target to the host.

Designing Embedded Communications Software

by T. Sridhar ISBN:157820125x

Table of Contents

Designing Embedded Communications Software Foreword

Preface

Chapter 1 - Introduction

Chapter 2 - Software Considerations in Communications Systems Chapter 3 - Software Partitioning

Chapter 4 - Protocol Software

Chapter 5 - Tables and Other Data Structures Chapter 6 - Buffer and Timer Management Chapter 7 - Management Software

Chapter 8 - Multi-Board Communications Software Design Chapter 9 - Going About the Development

Appendix A- Examples from Commercial Systems Glossary of- Common Terms and Acronyms References

Index List of Figures List of Tables List of Listings List of Sidebars

9.5 Test Tools and Equipment

Testing the communications software on the target involves various types of test tools and equipment.

For example, protocol conformance testing for the IP suite can be done with a tool like Automated Network Validation Library (ANVL) from Ixia Corporation. The test generates packets for specific protocols on an interface connected to the router, while the other interface is used to observe behavior (see Figure 9.4). For example, to verify correct forwarding, the tool can generate a packet on Port 1, with a destination address equal to the IP address of Port 2 in Figure 9.4. The system under test (SUT) will forward the packet on its Port B to Port 2 of the test tool. The tool receives the packet, verifies it, and updates the test result information.

Figure 9.4: ANVL test tool.

While ANVL is a conformance tool offering some level of performance-based testing, there are specific types of test equipment such as those from Agilent, NetTest, and Spirent which incorporate conformance as part of a test suite portfolio. These types of test equipment perform two basic functions:

Analysis

the test equipment captures the frames and then decodes and analyzes the data for correctness.

Simulation

the test equipment generates packets for specific protocols and verifies the responses.

Simulation often involves a light-weight implementation of the protocol with its state machines, packet generation and reception, and a limited amount of configuration.

The test equipment can also be used to validate performance such as the forwarding rate, latency, jitter, and so on. This is usually done on the complete system with the hardware and software subsystems integrated.

In document 57359860 Designing Embedded Communications Software (Page 162-165)