From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.4 required=5.0 tests=AC_FROM_MANY_DOTS,BAYES_00 autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,6403691d6db186c8 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-02-27 05:23:18 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!beamish.news.atl.earthlink.net!guinness.news.atl.earthlink.net!news.atl.earthlink.net!stamper.news.atl.earthlink.net!harp.news.atl.earthlink.net!not-for-mail From: "Marin David Condic" Newsgroups: comp.lang.ada Subject: Re: Getting a symbol table from Gnat 3.15p on Windows Date: Thu, 27 Feb 2003 08:11:51 -0500 Organization: MindSpring Enterprises Message-ID: References: <9q77a.270939$HN5.1154712@rwcrnsc51.ops.asp.att.net> NNTP-Posting-Host: d1.56.bf.93 X-Server-Date: 27 Feb 2003 13:12:53 GMT X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Xref: archiver1.google.com comp.lang.ada:34668 Date: 2003-02-27T13:12:53+00:00 List-Id: Its pretty much as you describe. We've got various packages that contain global data. The embedded, on-board monitor can read and write any addresses in memory, so we have an external system that feeds it data & addresses to plug & chug. (It does this across a 1553, but could be modified to use Ethernet, etc.) The monitor and its external counterpart *can* be used for debugging, but its more important use is to plug test data into input memory locations, let the software crank and get the outputs from other memory locations. It does this at a high rate of speed so that it doesn't interfere with the realtime control and it is used to test the control's reaction to dynamic events. (Temperatures & pressures changing, actuator positions moving, etc.) Low level software in the embedded system is doing the A/D and D/A conversions & actual I/O. To drag this over to a workstation, you'd basically have to dummy-up the low level I/O and have something cycle the software. (Can't tie to an interrupt like we do on the embedded box - or maybe you could, but it starts getting complicated.) From there, if I can change the pipeline that feeds the monitor and get a symbol table that the external software can use, basically, I can run all the test scenarios that are already built for the embedded machine. In addition, I can rig up code to connect various other systems like engine models and actuator models to the control system, so long as I can feed it data fast enough. If I have a fast enough machine, I might even be able to run the control in realtime - which has distinct advantages. The thing is, if I start coming up with something that requires too much modification of the control software or starts linking together too many other pieces that might introduce time delays or allow the project to get too big in scope, it isn't going to fly. So I'm trying to see if I can get a usable symbol table that could be fed to my existing external monitor program that would result in addresses that the internal monitor program can use to access global data and thus have a relatively simple answer for how to run the embedded software on a workstation. Unfortunately, it is appearing that whatever addresses I might be able to come up with are not going to be usable by the internal monitor as it exists. From there, its a matter of determining how much additional work and complexity and time penalty would be involved in cobbling together some other answer. Contrary to the perception of many, we don't have billions to throw away on developing anything we like so I've got to do this in a fairly small number of $$$ or it won't be feasable. MDC -- ====================================================================== Marin David Condic I work for: http://www.belcan.com/ My project is: http://www.jsf.mil/ Send Replies To: m c o n d i c @ a c m . o r g "Going cold turkey isn't as delicious as it sounds." -- H. Simpson ====================================================================== wrote in message news:9q77a.270939$HN5.1154712@rwcrnsc51.ops.asp.att.net... > I gather these aren't for memory mapped IO ports? Does your program > under test just have a collection of things like > Voltage : Integer_8; -- etc > that you want to examine/modify from a second program/task? It sounds > like you essentially want to put those variables in a place in memory > where they can be accessed from either testee or tester. Are the > variables of interest sprinkled about, or are they in a few clumps? Can > you put them in a shared passive partition and have another parition be > the examiner/modifier? Or can you tell your linker to put those clumps, > or at least the packages containing them, at set locations in sharable > memory? Using a symbol table of course lets you leave the items of > interest wherever the linker put them, but perhaps you can instead move > the items to a more convenient spot - without significant change to the > program under test.