[BAE Logo]
[ About ][ Home ][ News ][ Resources ][ Services ][ Sitemap ][ Literature ][ Our Markets ][ Interesting Projects ][ Community Service ][ Contact Us ]

Microprocessor User's Guides

Evaluation Kit User's Guides

Skills Chart
Teaming Specifications, Communication, Coordination, Commitment, Schedules, Deadlines, and sensitivity to Corporate Goals, Conventions, and Requirements
Technical Microprocessor Architecture, Digital Electronics, Digital Logic, Circuit Design, Logic Design, Programming, Programming Conventions, Programmer's Models, Languages, Assembler, C, Assembler Mnemonics, C Conventions, Clocks, Interrupts, Interrupt Latencies, Development Tools, ICE, JTAG, Breakpoints, Information Theory, Schematics, Flow Charts, Block Diagrams, Graphics, Illustrations, Publishing, Electronic Publishing, Documentation, Document Conventions, Document Organization, Page Layout, Tables of Contents, Intellectual Property Considerations, Trademarks, Copyrights
Software Embedded Systems, Programming, Programming Conventions, Programmer's Models, Programming Languages, Assembler, Assembler Mnemonics, C, Interrupts, Interrupt Latency, Development Tools, ICE, JTAG, Microsoft Word(TM), Adobe Acrobat(TM), Adobe FrameMaker(TM), Mainstay WinFlow(TM)
Hardware Electronics Design, Circuit Design, Logic Design, Digital Electronics, Evaluation Boards, Evaluation Systems, ICE, Components, Component Packaging, Circuit Boards, Circuit Board Layout and Design

The goal for this project was to create effective User's Guides for a new line of ARM-based, 32-bit System-On-Chip (SOC) devices being developed by our Client. The User's Guides had to be technically correct, consistently formatted, well-organized, and useful to programmers and hardware designers alike.

The Guides also had to be available on specific dates, to ensure a successful product launch.

Our Client knew from previous experience that the scope and breadth of this project required the skills of an experienced engineer, programmer, and author. With this in mind, they approached our Principal Engineer, Patrick H. Barrett, who agreed to serve as engineer-writer for the project.

Silicon development projects are fast-paced, so we located our engineer on-site, to absorb the corporate culture, develop team relationships, and ensure timely information. Achieving a good impedance-match with the team was critical.

[SOC User's Guide, cover]


New product launches are a Marketing department's lifeblood, so our engineer established and maintained an early rapport with our Client's Marketing Team.

The Marketing Team provided valuable insight about the "vision" for the product, the target market, the desired look-and-feel of the documents, the table of contents (in general terms), and corporate requirements.

Our engineer also worked closely with the SOC chip designers, to develop an understanding of the Intellectual Property (IP) in the SOC, and how it would be interconnected in this particular design. The dialogue began with existing materials, and progressed into various graphic elements the guides would require, such as flow charts, state diagrams, and block diagrams.

The initial step was to comprehend the design by crafting accurate block diagrams, at various levels of complexity. These block diagrams were useful to the design and test engineers, and became the basis for much of the graphic art published in the User's Guides. Development of the block diagrams led to the early discovery and correction of a bug in the IP.


Any chip's personality is determined by its Intellectual Property (IP), and how the IP is interconnected.

Accurate textual and graphic descriptions of the functionality provided by the IP, and achieved (or ignored) by the interconnections among the various IP modules, are vastly important.

Although much of the IP was previously documented by its vendors, such as ARM, Ltd., the vendor documentation was of diverse style, unclear, and often contradictory. Some of the IP was newly created by our Client, and formal documentation did not yet exist. Sorting this out was a major challenge.

[Example Block Diagram]

Organizationally, our engineer was placed in our Client's Software Systems Engineering (SSE) group, rather than their Technical Publications department. This gave him direct access to the personnel who were evaluating the silicon and developing the circuit boards and software for the evaluation kits.

Mr. Barrett also gained access to a development system, the latest development software, and an evaluation board, which he used to explore the SOC, and to ensure that the code being created for publication in the guides was adequately commented, and matched the explanations and screen-captures presented in the guides.

This location and environment were critical, because no other department could have provided the same blend of tools and timely information.

[EVB User's Guide, cover]


When a product is launched, technical inquiries will funnel to an organization's Field Applications Engineers.

These folks are positioned "where the rubber meets the road", so their input on all aspects of the product is extremely important.

In this particular project, members of the Applications Engineering Group were also evaluating the early silicon, and preparing software for the Evaluation Kits.

Our engineer worked as closely as possible with the FAEs for the duration of the project.

Although not located in the Technical Publications Department, our engineer also worked closely with their personnel.

Technical Publications Departments play an important role because their output must be technically correct, and must reflect a consistent corporate identity. The materials produced by the Tech Pubs folks are often a new Customer's first contact with a company and its products. But new products foster new ideas and new techniques, which can conflict with the inertia inherent in large organizations.

Situations can arise in which everyone is correct, but they disagree. Publications targeted to the web, for example, should be differently organized than materials intended for print publication. The software tools used for Technical Writing, such as Adobe Acrobat, Illustrator(TM), and FrameMaker(TM), are quite different, in subtle ways, from the ordinary word-processing software used in the corporate world.

Our engineer was called upon to function as a catalyst between competing interests, promoting (or retarding) change, with little or no authority, and without appearing too strongly attached to any one group, department, or faction.

This ability to accomplish change in a stressful environment is a key occupational requirement (and hazard) of Technical Writing. Mr. Barrett, with experience in design engineering, embedded systems development, and also Technical Writing, was uniquely suited for this project.

The project was completed on schedule and within budget.

Our Client, The Sharp Corporation, announced its Blue Streak(TM) line of microcontrollers and ARM-based System-On-Chip (SOC) devices in March 2002, at the Embedded Systems Conference, in San Francisco.

Our Client has requested that we not publish the actual documents on our website, to ensure that its Customers have access to only the most recent versions of the documents. For more information about Sharp Blue Streak(TM) products, and a closer look at the current versions of the LH79520 User's Guides, click here to surf to our Client's website.

Top Literature
Contact Us
©Copyright 1999-2002 Barrett & Assoc. Engineering, revised 02/09/21