Report from the Fall 1999 Embedded Systems Conference

November 17, 1999

Compilations of notes by attendees from the Jet Propulsion Laboratory, California Institute of Technology. Specifically, By the members of the: Realtime Interferometer Software Group, Section 383 Graham Hardy Brad Hines Phil Irwin Beth McKenney Martin Regehr Guidance and Control Analysis Group, Section 345 Matt Wette Test Systems Engineering Group, Section 341 Dennis McCrealy

Edited byBrad Hines

This report was prepared by participants from the Jet Propulsion Laboratory, California Institute of Technology, under a contract with the National Aeronautics and Space Administration. Reference herein to any specific Commercial product, process, or service by trade name, trademark, manufacturer, or otherwise, does not constitute or imply its endorsement by the United States Government or the JetPropulsion Laboratory, California Institute of Technology.

Revision Log Version Revision Note Published Date Date Reviewed

1.1 1.o

Incorporated comments from Document Review Released

11/17/1999 10/27/1999

11/16/1999 10/26/1999

Introduction
The authors of this report have recently returned from the 10* annual EmbeddedSystems Conference in San Jose,California. A broad array of topics were covered in the tutorials and classes at the conference, and vendors displayed a wide variety of products. The conference was attended by over 16,000 people, and is the single biggest event in the embeddedindustry each year. We learned a lot of noteworthythings at the show, and it worthwhile to make report of the felt this highlights of what we saw and learned. The first section of this report is a high-level summary of what we all saw, with more details on each of the topics in the later sections. Each attendee received theproceedings of the conference on CD-ROM, whichmeans that we have available papers covering most of the topics summarized in this report for anyone that would like to read them. Contact any of the authors of this report if you'd like more info on a particular topic. Also, Dennis McCreary has arranged for the CD to be available online on huey for the next few months; just type "esc99" at the Unix prompt to view the CD [Link], you canborrow a CD from one of the authors.

***Note to Managers***

(M)

This report contains a lot of technical content, but italso contains substantial amounts of information of interest to managers. If you're a manager andjust want to browse theparts of the report having to do with management, look for the @f) indicator in the right margin of the section heading, such as is in the heading for this section. Items marked witha small m (m) may be of interest to those directly managing software projects. That is, if you're manager of a project which has software or embedded systemsas a component, I think a you'll want to be awareof at least the (M) items. If you directly manage a software or embedded development task, I think you'll also want to be aware of the (m) items. The last of the @f)l(m)items appears on page8 of this report.

Summary
Java (M) Believe it ornot, Java for embedded applications is making a huge splash in the industry. A number of vendors are now supplying small-footprint JavaVirtual Machines for embedded processors, and there are even a number of hardware Java machines silicon that you can buy. in
JPL in the news (M) Several attendees were regaled on several occasions with examples of software failures brought to you by JPL, with Mars Pathfiider playing thestarring role (2 separate failures that were popular), and Mars Climate Orbiter mentioned as a possible software failure. The Ariane 5 failure was also mentioned, but less popular. Software people like to illustrate their points with really spectacular failures.

Code Reviews (MI Every class I am awareof that covered managementof embedded projects ended upquickly focusing on management of software. Each of these classes homed in on the importance of code reviews in delivering s o h a r e on time and controlling maintenance costs. Documentation and Bugs (M) Classes stressed that bugs should be fixed when found, that lists of known bugs should not be allowed to continue to grow, and all system failures should be recorded. Documentation should be written, at that least the first cut, before significant coding takes place.

Performance A number ofattendees learned about coding for performance, including optimization of virtualfunctions, avoiding temporary anddynamic objects, references, overloading new, and manipulating registers from c/c++.

C++ (m) Much embedded development still done in Cybut there is continuous migration into C++ and greater is levels of object orientation. The Embedded C++ standard (EC++)is a sort of compromise that provides many usefulfeatures of C++ while losing some of the bulk of the full language.
Hardware Design People learned about anumber of logic design issues and tools. Tools GDB is now supporting tracepoints, which are a wayof allowing you to step through realtime code without actually stopping it. Execution data is recorded whilethe code executes, allowing you replay to it later. Hardware 500 MHz PowerPC750 boards are now available. System-on-a-chip is becoming a bigdeal for folks designing small, smart,all-in-one devices. You can buy somereally small stuff, 486 computers and hard drives that fit in your shirt pocket, etc. There is hardware to translate between just about anybus you want now, it seems,VME, PCI, CPCI, 1394,. . . Debugging withhardware emulators is becoming tougher as chips get faster, so debugging facilities are moving on-chip. Open Source (m) The open source model, where source code is free, with the option to pay for support, is increasing in the popularity. In addition to the Gnu packages, thereare now open-source real-time operatingsystems (uC/OS-XI, an 8-bit OS, VRTX from Mentor Graphics, andECOS from Cygnus Support), and Linux is coming on strong as an embedded and development platformand garnering lots of support fromhardware vendors, Realtime OS Technology The Priority CeilingProtocol is an exciting twist, one that getting more attention recently, that is completely eliminates the possibility of priority inversion problems (such as were experiencedby Pathfinder) a d the dreaded deadlock (!) and allows predictable design of realtime systems. Vendors are starting to support OSEK, a new microkernelstandard small RTOSs. There was also a talk on for scheduling technology from the 1970s to today. Microsoft Windows CE is really targeted towards handheld devices with displays and that sort of thing, butit does have relatively impressive realtime performance andis a viable platform for many applications,including the sorts of things we do. Busses Protocols (m) CAN (Controller Area Network) TTP (Time-Triggered Protocol) are being used in medium-speed and (1 Mbitlsec) applications such as automobiles. TTP seems toshow special promise as far as being able to build deterministicand predictable realtime systems withfewer surprises during integration. I20 is a Wind-River-backed I/O idea for putting smart processors in I/O devices, which has benefits for hardware vendors who must supply drivers to their customers on multiple OSS. Several folks attended a 1394 (Firewire) class and now have apretty deep understanding of it. USB is sort of lower-speed incarnation of Firewire. Both USB and Firewire are about to undergo aspec update, which has the potential to cause backward compatibilityproblems. Its importantto be aware of the software environment usedwith the bus in a particular system as well, since many standardsoftware layers (e.g. SBP-2 over Firewire) add nontrivial overhead.

Standards (m) X M L seems to be on a roll, and is positioned to become the common data interchange format of the future. Many tools, including your desktop office suite, are adopting XML or at least supporting it. Miscellaneous -Linux is the best documentation know of for device driver writers, asserted one I speaker. So if there is already support for a board youhave in Linux, run, dont walk, to the Linux sources and steal away.
Of Note - The line for the mens room was consistently longer than the line for the womens room.

Detailed reports
Java -Hines, Irwin
Industry interest in Java seems to be coming fromseveral directions. There are a lot of realtime Java products available, from compilers, to Java-to-C++ converters (so that you can then compile),to virtual machines for embedded use, to Java processors that execute Java byte-codes directly. One sourceof interest is the commonly held opinion Java is an easier language to learn than C++. that Also, since Javadoes not havepointers and eliminates a whole class ofprogramming errors related to memory management(seasoned programmers learn how to avoid these pitfalls, but novices are often victims of them), people are enthusedabout the ability to eliminate these errors. Memory leaks can be particularly problematic in embedded systems, which sometimes are required to run for weeks or months at a time. Another bonus is portability, obviously. You test your code on a workstation and it can run on your embedded system without recompiling. can also imagine things like our Apparent Place calculations, I which arecurrently written in C++, being writtenin Java. Then, when a bug is found andcorrected, our various field installations can just grab the new code and insert it into their system. No need to recompile, rebuild, etc. The new stuff just starts working.
As far as performance, there has been significant technical progress that makes performance much of less an issue. The common gut reaction is that a language that does garbage collection is unfit for realtime. However, there are now garbage collectors available that are compatible with realtime use, using techniques such as incremental garbage collection. One advantage to garbage collection is that heap fragmentation, whichcan be a particular concern again for systems that have to run for very long uptimes, is not an issue.
A second performance concern has to dowith the fact that Java is interpreted instead of compiled. There are a couple of solutions to this available now. There are now compilers that compile Javadirectly into native machine codefor performance-sensitiveapplications. These applications then tendto beonly about 50% slower than the equivalent C++ program. The performance difference is largely due to Javas runtime error-checking(e.g. array bounds, etc.), and most compilers offer the option to turn this error-checking off for performance-sensitive applications.

(m)

For people that are developing embedded codefor small devices, where designers typically develop their own hardware as well as software, hardware Java machinesare an excellent solution to the performance problem.

C++ in Embedded Systems - Wette

Matt attended a talk and another shop talk on using C++ for embedded systems. The speaker was Don Saks, who has a company providing support for C++. In his talk the speaker overviewed somefeatures of

C++ and discussed trend in embedded systems and some waysto migrate to C++. Two features that are the of current concern in embeddedsystems are (1) exception handling (2) runtime type information. and There is also a EmbeddedC++ standard (EC++) that is supported by many vendors. The official C++ standards committee nowhas a working group on performance issues. However, recommendation was no given for EC++ as (1) manyfeatures which dont have performance issues were removed (e.g., templates, namespaces) and(2) the standard is incomplete (e.g.,there is no specification to cover failure of operator new). Anotherbit of useful advice was that EC++ Standard Library can provide a useful replacement the for the morebulky Standard C++ Library. In summary, it seems people are not making the choice of that whether to convert to C++ but when (though Java is making a splash). For more info on EC++, see ~httv://[Link]/ec2vlus/>.

Also, after the conference Matt talked Kenny Meyers of MDS about C++/Java issues. He showed Matt a to cool book by Stan Lippman called Inside C++ the Object Model which talks about internals of C++ code layout. Matt went out bought it at Barnes and Noble -- looks good. Also, Kenny said that Stan is and coming out with abook on performance.

Realtime Operating Systems and OS Technology - Wette, Hines, McCreury

One talk, A Survey of Task Schedulers provided an overview of schedulers from the 1970s to today. The talk A Modem Standard for Super-small Kernels ...provided details on the new OSEK standard for small RTOSs, which many vendors (including WRS) are starting to support. A entitled Inside Real-Time talk Kernels covered the authors popular, open-source 8-bit RTOS calleduC/OS-11. The best talk of this lot was Predictable Real-Time System Design given by a speaker from TimeSys. He gave an overview of realtime systems issues (priority inversion, RMA etc) touched alittle on CORBA and and its implications. Matt has contacted these folks to come give a talk,possibly the morning of Nov 3. The current feeling seems to be that the Priority Inversion Protocol for schedulers is not as reliable as Priority Ceiling Protocol.
Priority Ceiling Protocol Most OSs dont quite support this hlly yet, but it willlikely be coming soon, since it solves some nasty problems (priority inversion and deadlock) so beautifully. The idea is this.

Priority inversion occurs when alow-priority task owns a resource thats needed by a high-priority task. The high-priority task hasdo wait on the low-priority task to finish using the resource before it can proceed. OSs (VxWorks, for example) provide a wayto get around this with priority inheritance. In this scheme, as soon as the OS detects that the high-priority task is waiting on a resource owned by the low-priority task, it temporarily boosts the priority of the low-priority task (the task inherits priority of the higher-priority the task temporarily). Now the low-priority task will run and releasethe resource and the high-priority task can then proceed. However, this doesnt solveall problems of this type. Deadlock, where two tasks each require two resources, butare each blocked waitingon one of them, which is already owned by the other task, is a serious problem in some systems. The Priority Ceiling Protocol slightly changes the idea ofpriority inheritance to eliminate both priority inversion and deadlock. Basically,the OS (or you, manually) keeps track of all the potential users of a resource ([Link] a semaphore),and marks that resource with the priority of the highest-prioritypotential user. That is, the resourceis assigned the priority ceiling ofall the possible users priorities. Then, when a task acquires the resource, its priority is instantly boosted to the priority ceiling for the resource and remains there until it releases the resource. Since there is no other contender for the resource with higher priority, there willnever be any contention for the resource. Amoments thought reveals that this solves the problem of deadlock, too.

It's a verycute and clever solution with few drawbacks. The main drawback is the repeated boosting of low-priority tasks to high priority even when there is no contention for the resource. However, an advantage of PCP is that it makes the system' realtime performanceanalytically predictable. There are more details on this in the paper on PCP in the conference proceedings.

Time-Triggered Protocol - Wette

TTP/C (Time-TriggeredProtocol) is a standardfor bus-based communication distributed TTTech in by Germany. It seems to be big in the auto industry and is a complement/ alternative to CAN (Controller Area Network). The main difference between CAN and TTP is that TTP is "state based" rather than "event based. Nodes (repeatedly) transmit their current state on a periodic basis rather than sending single messages. For example, if a switch is turned on in the network the associated bus message wouldnot be "switch turned on" but "switch off [wait] switch is on [wait] switch is on ...'I. is All bus traffic is completely deterministic, allocated apriori and configured in each node as a dispatch table. The advantage hereis that TTP is robust to lost messages. There is more. Matt has a copy of the spec if anyone wants to look. Also, more on TTP is available from <[Link] One of the coolest things that came up in the talk is that BMW has a prototype S U V with steer-by-wire,and it works!

Code reviews Hines

(M)

There appears to be no debate remaining in the industry. Code reviews appear to uncontested as the way be to improve productivity and reduce cost. The claim is that studies show that code reviewis 20 times more efficient atfinding bugs than debugging is. A full day of code review with 4 people can be a bit tedious and seemunproductive, but many times a particularly insidious bug can take a skilled programmer two weeks totrack down. If the full-day code review finds only three or four bugs, itquickly earns its keep. Typically, the reviews are significantly more effective than that. Reviews are also credited with beingespecially helpful during the maintenance phase,after the original programmers have moved Code prepared for review is often in better condition, withbetter on. documentation, thancode that has simply been developed and tested by a single developer until it works. It seems clear that, within a couple of years, anyorganization that does not implement code reviews as part of its standard developmentpractice is going to look like a dinosaur relative to the restof the industry.

Iterative development - Hines

(MI

Iterative development wasalso a universal theme. Nobody believes in waterfall anymore. The idea is to get askeleton of the whole application running as quickly as possible, and then begin slowly filling it in with functionality. The idea of testing daily (or at least weekly) wasalso strongly endorsed.

Squash bugs now - Hines

The purposeof code reviews and daily regression testing is to catch bugs as soon as possible. There was a universal thread through all the management talks that bugs should be fvred as soon as they are detected. Pushing to make delivery date and makingthe delivery with a list of known bugs outstanding as liens was a universally declared to be a poor practice. Stop, fix the bugs now. The bugs shouldbe fixed whilethe code is fresh in the programmers' minds, and while bugs are repeatable. Latent bugs can interact with the other bugsto create extremely difficult-to-diagnose problems.

A related pointis that all failures of a system should be recorded. Often, when developersencounter anomalous behavior,they just try it again. Recurring bugs can slip through the cracks this way, as developers repeatedlyignore a serious problem becauseits simply an annoyance to their problem at hand. Its important to record every failure of the system in order to makesure this kind of thing doesnt slip through the cracks.

Pay attentionto the error cases -Hines

(M)

The loss of thefirst Ariane 5 is the classic example of an error case that was trapped by the program and handled exactly as the programmers intended, yet led to system failure anyway. In the Ariane 5, the Inertial Measurement Unit experienced a numericoverflow of a 16-bit value due to larger forces, [Link] the the Ariane5 than hadexisted in the previous-generation rocket, in which the IMU had beensuccessfully used. The software trapped the error, and dutifblly shut down the IMU and switched to the backup unit. Of course, the backup immediately experienced the same problem and was shut down by unit software as well. After that, the rocket didnt fly so well. Example after example was presented systems thatfailed because of incorrect behavior in the offof nominal case. These cases are often not specified well,or left up to the programmers to handle, the and specific behavior in these cases is not documentedas part of the documentation of a software [Link] the examples show, can have catastrophic results, especially when it comes time to reuse software. this the Complete specification and documentation of a modules behavior is important in order to avoid these kinds of problems.

I20 -Hines, Wette

Intelligent I/O (120) is a protocol/design scheme that calls for I/O devices to have an embedded processor that responds to particular message-passing protocol. The idea is that this achieves some level of device a independence for software drivers. I 2 0 specifies standard interfaces to about 20 different types of devices, including printers, modems, etc. The idea, then,is that the OS vendor just supports I20 fadmodem, rather than havingto support devices from hundredsof different vendors. The vendor thenplaces his value-added softwareon the embedded processor in the I 2 0 device. When a driver update is needed, the vendor only has to update one driver, instead of one for every OS platform that the device works with. There are currently some legal harangues surrounding 120, having to do with the fact that its a Wind River initiative and theyve their fingers into it in some slightly inextricable ways. got Its not clear how applicable I 2 0 is to us directly at the moment, but it is reasonably possiblethat as time goes on, more and more the deviceshoards we buy willinclude I 2 0 support, and VxWorks will of provide I 2 0 drivers, andthis will be a convenient way access certain common hardware types,such as D/A to converters, makingit much easier for us to develop drivers.

XML -McCreary
X M L is the wave of the future. It is ideally suited for exchanging information between vastly different applications withdifferent needs (HTML is not). Xh4L is expected to be the common data interchange format ofthe hture. XML has a simple universalsyntax, flexible data model, multiple namespaces is and being adoptedby many tools across many industries(Excel, Word, Office, Internet Explorer, and Oracle among others). Transformationprograms exist which will translate XML to XML, HTML, SVGh4L and MathML.

Debugging Technology - McCreary, McKenney, Wette

Several companies are coming out with debuggers which allow visibility into realtime code without changing execution timing, at least to some extent. These tools, including a new versionof GDB, work by making a record of whatactually happened during the realtime execution and thenallowing you to step through thecode, examine variables, and so on, using saved information from thetrace buffer. Xray Debuggerfrom Mentor Graphics allows "synchronousbreakpoints," which allow the execution of several tasks to besimultaneously suspended whena breakpoint is reached in a single task.

Coding and Debugging Techniques - Regehr

There are a few techniques that can usually be used improve the performanceof C++ code. Passing to objects by reference-to-const avoids a copy constructor call, and the creation of temporary objects can sometimes beavoided by using multiple unaryoperators instead of binary operators. Performance gains can sometimes be achieved in programs whichdo a lot of memory allocatioddeallocationby overloading 'new' with a 'placement new' function which allocates memory from a pre-allocated pool in fixed-size blocks in order to mitigate the variable overhead and memory fragmentation which can be caused by the standard new'function. For debugging interrupt service routines and other hard realtime events, you can use techniques similar to what we have usedin the past, such as reserving some parallel output bits for debugging, andusing an oscilloscope and an external counter to monitor the frequency of interrupts, the fraction of CPU time spent in ISRs, and to detect missed interrupts. Also, monitoring the size of the stack using a stack monitor is considered a good idea.

Flash Memory McCreary, Regehr

Flash memoryis available in gigabyte sizes, and oneof the companies that makesit claims it is rad hard and thus might be suitable as a substitute for a disk drive on a spacecraft. Drivers exist for many operating systems to make a bank of flash memory looklike a disk drive. We have to do little more research to a determine howthese capabilities relate to VxWorks flash file system that flew on Mars Pathfinder.

Meta-Information
This section doesn't contain as many details on things we learned, but it isa report from various folks on a list of topics that they learned about. We include it here so folks can see what else we learned that we didn't necessarily write up in this report. If you are interested in any of the things mentioned here, contact the person who made the report for more information, and or she can point you to the appropriate papers he from theconference.
Beth McKenney I learned somecreative ways to reduce runtime overheadin C++, such as (a) forcing virtual function calls to be non-virtualin time-critical parts of the code, (b) convincing the compiler not to create superfluous temporary objects using a variety of techniques, and(c) avoiding dynamic creatioddeletion of objects where possible.

Also learned a few tricks for representing andmanipulating hardware registers using C/C++ (with the caveat that some of the techniques may be compiler- system-dependent). or
I learned about the differences between EPLDs and FPGAs, well as some of the features to look for as when selecting a chip for a given application. Heard some good treatment of various FPGA design issues, such as hold time violations, bus contention, glitches, one-hot encoding, and the rare cases where asynchronous logic might possibly be advisable.

Also learned abit about FPGA design tools, including key differences between the Altera andXilinx compiler strategies. I learnedthat it is possible to insert a "stub" of the GDB debuggerinto an embedded system, and it up to set record tracevariables at desired locations ("tracepoints") during runtime, minimizing the impact the on realtime system behavior. The variables can then be read back at later time using the GDB interface with a a few simple extensions.[This has been done by some peopleat Cygnus, butwe could probablydo it ourselves in the time it will takeCygnus to figure out how it wants to market their stuff.] [Matt] If this stuff is part of the GDB sources, then the developer versions of that stuff is available. In fact, Cygnus provides access to most of the CVS development trees (i.e., youcan do things like "cvs checkout" the gdb development tree).
Matt Wette I visitedseveral vendor displays and got some insight on the state of the art in compilers, debuggers, and other such tools. Ialso visited the SBS display which providedsome up-to-date information on I/O capability we'll be needing for the SIM testbeds. Processing for the simulation in the SIM Flight System Testbed shouldnot be an issues. Vendors (e.g., Motorola) are now coming out with 500MHz 750 processors for VME and CPCI.

There was atalk on MSWindows CE focused on changes to the upcoming version 3.0 that developers needed tobe aware of.
Phil Irwin Here's some stuff that caught my attention: FirewireNSB: - These two busses are very similar, USB is a lower speed version with a higher max nodecount - Both are about toundergo a spec update, which couid causeincompatibilitiesin devices. Firewire especially so because there are some new rules that could make it very difficult to interpret the spec. - USB is better for input devices...Firewire for storage, video ... C++: - Dan Saks gave agreat talk on reducing runtime overhead inC++ - Many of the things he mentioned, we already do. He even went far as to fake out the virtualtable and as call a function directly if it were to be called in a long repetitive loop. - He also talked abouttemporary objects, overloading new, placement new,and using references to your advantage. Svstem-on-a-chip: - No speaker really gave me a good handle on this but it sounds like it's much better for super-high quantity production (definitely not our bag), but it's a really cool concept. Hardware - You can buy a486 computer on a 2"x3" board, complete withISA bus - You can also get amulti-hundred MB hard drive that fits on a L2 PC card. - SBS has some neatstuff for bus conversion (VME-PCI, VME-IEEE1394,etc...). Software: - There are a few hardware companies getting excited about Linux; software companies don't like it, especially ones that sell operating systems. - There are bazillions of software development tool companies. I didn't too excited about any of them. If get we want to increase debugging capabilities, maybe we should think about hardware debugging. our

Graham Hardy Since RTOS'sare relatively new to me I gravitated to the talks about the nature of Real-Time Kernels and Multitasking [Link] things I learned were:

10

1. The natureof the following: Linear Code(foregroundhackground) vs. Multitasking, Multitasking vs. Multithreading, Prioritization, Determinism, Preemptive vs. non-Preemptive Scheduling 2. The structure of a RTOS (e.g.: Task States, TCB's, Ready Lists, System Ticks, Interrupt-Kernel interaction, Wait Lists, Kernel Services, Stack Checking, etc) 3. The considerations and tradeoffs of choosing Build vs. Buy with respect to RTOS's. 4. Getting aDigital ASIC designed and built pretty straightforward though expensive(also the tradeoffs is of Gate Arrays vs. Standard Cells). 5. Modem State Machine theory is bloody complicated! !!

Dennis McCrealy I took the following classes. Here are my comments on each. 100 TCPAP Networking
202 The Integration of EmbeddedWeb Technology with XML Already discussed in "Detailed Reports" above. 242 Debugging ISRs "If debuggingis the process of removing bugs,then programming must be the process of putting them in." "Trust nothing,assume nothing, presume failure." This talk presented a philosophy on the design, implementation and testing of ISRs. This is a good paper worth reading if you are interested in ISRs. 260 Flash MemoryTechnology and Techniques Flash memoryretains information that is written to it even after the power is turned [Link] will retain the information for 10 years plus. Whileit can be programmed at the byte level, an erase operation erases an entire [Link] behavior must be taken into account when designing applications that use it. With repeated use, the memory can degrade. It is still usable, but takes longer to program or erase. Several software vendors have written packages that emulate disk drives in flash memory. If a sector previously written tothe device needs to be modified, the old sector is marked dirty and the new changed sector is written to a different location. Whenall the sectors in a block have been marked dirty, can be erased and it reclaimed. Devices about the size of a height disk drive exist which hold several half gigabytes of flash memory. 301 Architecture ofDevice UO Drivers, Parts 1 & 2 Some specific strategies for particular types of device drivers. 341 Device Drivers Good overview of issues involved in writing device drivers. "Linux is the bestdocumentation I know of for driver writers." 368 Memory Management Discusses memory managementissues on the stack and the heap. Shows how malloc works discusses and alternate schemes for pools or partitioning memory to reduce fragmentationproblems. Talks about third party software memory management issues and automatic garbage collection. Presents a smart pointer class for C++ whichhandles memory allocation. 403 Reducing Runtime Overhead C++ in Excellent talk. Discusses optimization issues with virtual functions, parameter passing, ++i vs. i++, replacing the new and delete operators and usingplacement new among others. 423 Representing and Manipulating Hardwarein Standard C and C++ Excellent talk. Standard C and C++ excellent choices for devices that use memory mapped are 110. With the use of minor deviations, they are also a goodchoice for devices which do port YO. For architectures that providespecial I/O instructions dedicated toparticular devices, they are a poor choice. Discusses the use of "const", "volatile", and "sigatomic-t". Talks about various ways to describe the memory mapped

11

hardware includingpointers to hardware registers, casting, masking,registers as objects, tagsvs types, register pairs, and writeonly registers. Also discusses problems with optimization. 444 Fundamentals of Firewire, Parts 1 & 2 Good overview of what Firewire is, where it isheaded and how works. it 509 The Heisenberg Debugging Technology The people at Cygnus have added trace points to the GDBdebugger. The advantage of trace points is that data is collected and buffered internally while the program running and is processed offline after the run is is over. This allows the programto run much closerto real time while it is collecting the debugging information. The modifications to the GDB debugger required dothis are publicly available. Onthe to target side, a GDB stub is required. This stub has been written by Cygnus, but they haven'tdecided what they are going to do withyet. Usingthis debugging technique, it is possible to have unattendedcollection it of debug data over extendedperiods of time on the order of days or weeks, depending,of course, on the size of the internal buffer allocated and the amount debug data being collected. When processing the of collected data, youcan replay it multiple times and do calculations based on any of thevalues collected. This would be very useful if we could get holdof the stub or write our own.
567 How Scripting Adds Valueto Embedded Systems With therise in processing speed, memory size, and complexity of embedded systems, onboard scripting is going to becomeincreasingly more important.

John Ousterhout, who gave this talk, believes that TCL is the best choice for a scripting language. (I second that opinion.) TCLis easily extensible, can be embedded and to produce an application command used language, is easy to hookto anything, has great GUS, is cross platform, and is open source. It is ideally suited to integration applications where severalseparate applications must betied together. An informal study indicated that it was3 to 10 times faster to develop an integration application using TCL [Link] Java, C or C++. Inparticular, John feels that Java is not a good match for embedded programming and presents a list of reasons why hefeels this way. I also picked up hardcopies of the presenter's slides for the following classes that I did not attend: 243 How to Size Message Queues 401 Inside Real-Time Kernels, Parts 1 & 2 529 Debugging Tools, Trends and Tradeoffs in an Embedded Design Project 566 Moving froma Standard ProgrammableInterrupt Controller to an Open ProgrammableInterrupt Controller I also spent some time talking to vendors of hardware andsoftware debuggers and flash memory. Flash memory is available in gigabyte sizes and one of the companies that makes it claims it is rad hard and thus might besuitable as a substitute for a disk drive on a spacecraft. I asked them to supply me the with names of people who usetheir product for disk drives on cards which can be installed ina VME cage. I saw demonstrationsof several hardware and software debuggers. Mentor Graphicsmakes Xray Debugger, a software product which allows synchronous breakpoints. You can requestthat when a particular breakpoint occurs in a particular task, that several other tasks running on the sameor different targets be breakpointed at the same time. sounds like something that would be This useful to us. Green Hills makes a software debugger called Metro2000 which it turns out that the FST has a license for. I plan to takea look at it. Embedded SupportTools Corp makes several hardware debuggers which were impressive. They support several hardware interfaces including JTAG,and in one setup, you can do things like breakpoint the hardware whena piece of software outside a particular rangeof addresses attempts to store into an address

12

inside aparticular range of [Link] would allow you to trap a programthat was walkingall over memory whilenot stopping for legitimate uses of that memory. Another advantage of the hardware debugger is that you can examine memory even the machine has locked up. With software debuggers, if if this happens, you have tostart over and try again. Tektronix demoed a nice logic analyzer with lots of memory so it could buffer up lots of data. We have an earlier model herein the STB3 lab and Iplan to findout more about how it works and what it can do. Cygnus has upgraded the GNU debugger to include tracepoints which allow debugging closer to realtime. The code for this in the debugger is publicly available but they haven't yet decided what to do with the stub which is required on the target side. For a fee, we might be able to get them to install it here.
Martin Regehr Cristopher Leidigh of American Power Conversion gave a fairly useful tutorial on TCPAP which included details of ARP, IP, and TCP. He performed livedemonstrations of various concepts using communication between his laptop computer and other networked devices, and a software package calledObserver which displayed transmissions at the byte level and interpreted them at level of different layers in the TCPAP the stack. My Tran of Motorola discussed the OpenPIC (Programmable interrupt controller) as an alternative to the older 8259A interrupt controller. The OpenPIC supports multiple processors and inter-processor interrupts, and allows interrupt priorities to be set using registers on the chip. Apparently HDL specifying the chipis available for free and manufacturers who sell chip or incorporate itinto other chips need not this pay license fees.
As discussed earlier, Dan Saks of Saks and Associates gave several talks on C++ and C, including a good review talk on templates and a talk on improving the speed of C++code, and Jack Ganssle of The Ganssle Group discussed various techniques for debugging ISRs

Bill Grundmann ofIntel discussed their flash memory technology. Apparentlythe main advantage of flash memory is that it is non-volatile; disadvantages are slow speed and the fact that erasing can only be done a large block at a time. He discussed page mode access for speeding up reads, andallocation algorithms for mitigating the inconvenience of erasing. Windows CE drivers are available which will make a bank of flash memory look disk space to the operating system. like

13