Re: Ada95/Mil-Std-1553 Problem (Long Post - Sorry About That)

Re: Ada95/Mil-Std-1553 Problem (Long Post - Sorry About That)

[Marin David Condic, 561.796.8997, M/S 731-93]

    Several of you have been very kind in sending me suggestions about
    how to handle my Mil-Std-1553 problems. I think the information is
    beginning to gel into a potential solution. I have one question
    which maybe some of the language lawyers can help me out with:

    Is there a way with tagged records to control the position/content
    of any and all tag data? (In a manner that is reasonably close to
    portable so that it's not dependent on, for example,
    implementation X uses a 16 bit integer for a tag vs implementation
    Y uses a 32 bit integer...) In other words, if I can guarantee that
    the tag data will occur at the end (or beginning?) of the record
    and/or that it will occupy exactly N bytes, I think I can figure out
    how to solve my send/receive problems. It would be better if I
    could control the *value* of the tag, but I'll settle for knowing
    where it is so I can strip it off.

    Any info on how that might be done? Thanks.

    MDC

Marin David Condic, Senior Computer Engineer    ATT:        561.796.8997
M/S 731-96                                      Technet:    796.8997
Pratt & Whitney, GESP                           Fax:        561.796.4669
P.O. Box 109600                                 Internet:   CONDICMA@PWFL.COM
West Palm Beach, FL 33410-9600                  Internet:   CONDIC@FLINET.COM
===============================================================================
    "Whatever is not nailed down is mine. Whatever I can pry up is not
    nailed down."

        --  Collis P. Huntington, railroad tycoon
===============================================================================

Re: Ada95/Mil-Std-1553 Problem (Long Post - Sorry About That)

[Larry Kilgallen]

In article <97011417264268@psavax.pwfl.com>, "Marin David Condic, 561.796.8997, M/S 731-93" <condicma@PWFL.COM> writes:

>     Is there a way with tagged records to control the position/content
>     of any and all tag data? (In a manner that is reasonably close to
>     portable so that it's not dependent on, for example,
>     implementation X uses a 16 bit integer for a tag vs implementation
>     Y uses a 32 bit integer...) In other words, if I can guarantee that
>     the tag data will occur at the end (or beginning?) of the record
>     and/or that it will occupy exactly N bytes, I think I can figure out
>     how to solve my send/receive problems. It would be better if I
>     could control the *value* of the tag, but I'll settle for knowing
>     where it is so I can strip it off.

I don't know how you could control the size.

I would think you could ensure it was at the end by using
representation clauses for all the other elements of the records,
essentially "filling up" the beginning so there is no space left
for the tag data except at the end.

Larry Kilgallen

Re: Ada95/Mil-Std-1553 Problem (Long Post - Sorry About That)

[Richard Kenner]

In article <1997Jan14.203917.1@eisner> kilgallen@eisner.decus.org (Larry Kilgallen) writes:
>In article <97011417264268@psavax.pwfl.com>, "Marin David Condic, 561.796.8997, M/S 731-93" <condicma@PWFL.COM> writes:
>
>>     Is there a way with tagged records to control the position/content
>>     of any and all tag data? (In a manner that is reasonably close to
>>     portable so that it's not dependent on, for example,

>I would think you could ensure it was at the end by using
>representation clauses for all the other elements of the records,
>essentially "filling up" the beginning so there is no space left
>for the tag data except at the end.

This isn't portable.  There's explicit implementation permission to
reserve a particular space in a record for the tag (but not for any
other internal field).  So a compiler is permitted to reject such a
rep clause (GNAT will, for example).

Re: Ada95/Mil-Std-1553 Problem (Long Post - Sorry About That)

[Marin David Condic, 561.796.8997, M/S 731-93]

Richard Kenner <kenner@LAB.ULTRA.NYU.EDU> writes:
>This isn't portable.  There's explicit implementation permission to
>reserve a particular space in a record for the tag (but not for any
>other internal field).  So a compiler is permitted to reject such a
>rep clause (GNAT will, for example).
>
    There's an additional problem - what you want to be able to do is
    figure out how many words are in the message, then do an
    UNCHECKED_CONVERSION of the message into your raw-word output
    buffer. If the tag info is in there at all, it a) gets counted in
    the word count and b) gets transferred to the buffer. (If you can
    guarantee it falls at the end, you could at least chop it off!)

    It would seem to me that the tag ought to be treated like array
    bounds - if an implementation keeps the bounds of an array with
    the array itself, all the usual clauses (like 'ADDRESS) are
    supposed to ignore that data.

    Using Streams seems to provide some mechanism for stripping out
    the tag info, but I haven't got the OO thing down far enough just
    yet to see how I could use it to get the contents of a message
    into a raw-word array where I can manipulate it. (Working on it in
    my "spare time". If I get an answer, I'll publish an example to
    whoever would like one.) I'm not sure this isn't going to involve
    moving the data twice or that it won't lead to grossly inefficient
    operation - but it seems like an area to start.

    MDC

Marin David Condic, Senior Computer Engineer    ATT:        561.796.8997
M/S 731-96                                      Technet:    796.8997
Pratt & Whitney, GESP                           Fax:        561.796.4669
P.O. Box 109600                                 Internet:   CONDICMA@PWFL.COM
West Palm Beach, FL 33410-9600                  Internet:   CONDIC@FLINET.COM
===============================================================================
    "Languages don't kill people. *Programmers* do!"

        --  Rich Stewart - Language Lawyer & Language Control Opponent.
===============================================================================

Ada95/Mil-Std-1553 Problem (Long Post - Sorry About That)

[Marin David Condic, 561.796.8997, M/S 731-93]

I have a problem I am trying to solve that involves building a
good  general purpose interface to a Mil-Std-1553 data bus using
Ada95. The 1553  moves data in blocks of 16 bit words, 32 words
at a shot. How exactly is not the problem. Accept for the moment
that we need some array of 32 words as the local buffer to hold
the data being sent or received. Here's what you'd like to have:

-- You would like to create any record type of some arbitrary
number of words (Possibly limited to some maximum, like 1024
words) and you want the first two words to always be the same:
Number of words in the message followed by message ID. Ex:

Type Msg is
    record
        Num_Wds  : Integer := 2;
        Msg_ID   : Integer := 0;
        --  Conforming records would have other stuff here.
    end record;

--  You want to write a package which will send or receive any
arbitrary object of a conforming record type to/from the bus.

--  The message length should not be arbitrarily restricted. (That
is to say, you don't want to insist that each message be exactly
N words in size - although for practical concerns, I'd accept
some maximum upper bound. Dynamically allocating buffers could
be a major problem.) An illegal package spec which would do the
job would look something like this:

package Mil_Std_1553 is
    function Msg_Waiting return BOOLEAN ;
    function Msg_ID return INTEGER ;
    procedure Get (
        Msg : out <any arbitrary conforming record type>);
    procedure Put (
        Msg : in <any arbitrary conforming record type>);
end Mil_Std_1553;

The requirements look something like this:

--  The program wants to work with structured data (record types)

--  The bus wants to work with 32 word chunks of raw words. It
will want machine addresses of where to get/put the data, so you
can probably make a big ring buffer and keep moving pointers
around.

--  The guy at the other end of the wire wants to send or receive
predictable formatted data as spelled out in an interface
control document (some well defined set of messages)

--  The guy at the other end may have been programmed in almost
any other language, so you can't count on the idiosyncrasies of
a particular compiler/hardware combination.

--  Output (from our side) is a little simpler because you can
dynamically determine the size of the record structure that the
data is parked in and use that to convert/block/xmit the data.

--  Input is harder because you have to determine from the
message ID where the data is ultimately to be parked. (You get a
big case statement or lots of little guys being dispatched to
check if the data is for them.)

--  Buffering/Blocking/Deblocking/Hardware is all to be hidden
invisibly in the package body - the client just wants to define
a message and send/receive it while seeing as little as possible
from the Mil_Std_1553 package. (avoid overlaying onto visible
raw-word buffers, etc.)

A traditional solution in languages like Ada83, C, Jovial, etc.
has been to do some version of the following:

--  Declare a fixed size raw-word array.

--  Declare N record types & objects (or maybe 1 discriminated
record type - although this contains its own form of
punishment.)

--  Use address clauses or other mechanisms to overlay the record
objects on the raw word array.

--  For sends, you move the data from some local record to the
overlaid record object and call "Put"

--  For receives, you check the Msg_ID (if data is waiting) and
go into a big case statement to move the data to some local
record.

Discriminated records can be a help, but it generally means
maintaining some mondo-big record declaration that is a pain to
extend. You'd like to declare new messages on the fly and
minimize impact. It seems like Ada95 ought to have a better
answer, but I'm not smart enough to see it.

--  Tagged records suggest a possible solution, but I've been
having problems playing around with that. Output can be coerced
by force (I have a relatively small example if anyone wants to
see it) but you've got to get rid of the record tag. It's
unpredictable and it can make problems for the other end - not
to mention wasting a word of storage in the message) Input is a
lot harder because you won't get the record tag in the message
or it would be unpredictable. That, and you need to write lots of
dispatched "Get" routines.

--  Someone suggested streams, but I can't figure out how this
would work. I'd need to see some small subset example because I
just don't see it from my limited experience.

--  Pointers to a record class may provide some help, but you're
still stuck with the tag and the associated problems on the
input side.

--  If you could control the value and placement of the tag, you
might have an answer because it could substitute for the message
ID. But I'm not sure that's possible.

-- You *really* need to limit data motion and buffering. You
can't get around at least one buffer for the 1553 to read/write
to/from. But you probably don't want to compute out of that
buffer unless you're astronomically fast and you have predictable
message intervals. The goal ought to be 2 moves: from/to local
storage and up/down the wire (1553 hardware move) We'd also
expect to have to implement buffer protection to eliminate risks
of multiple task accesses (and hardware accesses!) to the
buffer, but I think some version of protected types ought to
handle this. You also want to avoid any dynamic allocation or
unpredictable stack sizes and such so declaring lots of buffers
on the fly is probably not a good answer.


Anybody out there ever seen something like this done in Ada95?
Can you suggest an approach? I'll e-mail my feeble attempts to
program an output solution (compiles & runs using Gnat/WinNT) to
anyone who asks. Thanks.

MDC

Marin David Condic, Senior Computer Engineer    ATT:        561.796.8997
M/S 731-96                                      Technet:    796.8997
Pratt & Whitney, GESP                           Fax:        561.796.4669
P.O. Box 109600                                 Internet:   CONDICMA@PWFL.COM
West Palm Beach, FL 33410-9600                  Internet:   CONDIC@FLINET.COM
===============================================================================
    "When the going gets weird, the weird turn pro."

        --  Dr. Hunter S. Thompson
===============================================================================

Re: Ada95/Mil-Std-1553 Problem (Long Post - Sorry About That)

[Amy Hartsough]

Marin David Condic, 561.796.8997, M/S 731-93 wrote:
> 
> I have a problem I am trying to solve that involves building a
> good  general purpose interface to a Mil-Std-1553 data bus using
> Ada95. The 1553  moves data in blocks of 16 bit words, 32 words

Several months ago I wrote a MIL-1553B Bus Controller in Ada-83.

In my design there are basically 3 layers. There's the hardware-interface
layer that drives the bus controller chip we're using. Then there's the
actual bus controller layer which talks to the device driver, and
provides services which provide for sending and receiving data, and
overall coordination of message traffic. The top-most layer is basically
the client layer, where "knowledge" of the R/T interface is kept.

So when the client decides it needs to communicate with an R/T, it formats
a message according to the ICD of the R/T. Prior to calling the Bus Controller,
the client invokes an instantiation of Unchecked_Conversion which converts
its "ICD Record" into an array of 64 bytes (stream). When the client does invoke
the BC, it passes the stream, the direction (Transmit/Receive), an Identifier for the 
R/T (not an address, the BC "knows" addresses), and the "size" (length) of the data 
being sent. The client specifies the TRUE length of the data, 1 - 32 words. The
BC performs the conversion to the 1553 protocol where 0 in the length field means
32 words.

The BC takes all of this information, determines the R/T address, formats the data
into a 1553 Command Word, calls the device driver, and waits for the "transmission
complete" interrupt.

The device driver places the Command Word into a "control block" inside the
1553 chip's dedicated RAM, then signals the chip to "go". When the transmission is 
complete (success or failure), the 1553 chip signals an interrupt at the PIC, which
is handled by the BC (it was originally handled by the device driver layer, but a
"quirk" of our compiler forced us to move it out to the BC when we moved from
a single 1553 bus to 3 buses). The BC services the interrupt by requesting the
Status Word from the device driver. The 1553 chip has created the status word in
a reserved region of the "control block".

The BC extracts any data from the Status word (or is that the data word? sorry, it's
been a while). The status word is evaluated for error reports, and the data and
status is returned to the client.

Well, I guess that's enough waste of bandwidth for the day.

Hope this has been helpful.

	Michael

Re: Ada95/Mil-Std-1553 Problem (Long Post - Sorry About That)

[Michael F Brenner]

My experience with 1553 indicates the following:
    (a) The bit structures are easier to deal with in Ada-95 because
    of the modular types.
    (b) To be compatible with C or FORTRAN or JOVIAL at the other
    end, let the high-order bit be always zero
    (c) The hard part is the conversion from 1553A to 1553B which
    requires a method of using the extra wire when no response
    is received on the first wire, for extra reliability. It is 
    easier to design this in First, rather than add this in later.
    (d) While everyone frowns on overlaying data using address
    clauses, I have seen them used on 1553A or 1553B drivers on
    MIPS, 80x86, and 680x0 CPUs in Ada, with no efficiency hit or
    reliability problems. In all three compilers, there WAS an
    efficiency hit for using an unchecked_conversion: it did a
    copy operation for most or all accesses.
    (e) Getting rid of the tag is a bigger problem than you indicate
    because the machine-independent specification of how to represent
    the tags is not in the Ada Standards, but in the CORBA standard.
    Since not everyone on the other side will have access to CORBA,
    you should not use tags, discriminants, or unconstrained elements
    in the message data structures themselves. Instead, ACCESS EACH
    ELEMENT through an object oriented interface (a get function and
    a set procedure). This use of object oriented design forgives
    many coding sins and deals with the foibles of many languages,
    operating systems, message formats, and hardware protocols like
    the 1553.
    (f) You are absolutely right about avoiding dynamic allocations
    because of unpredicatability of time, even in the fastest systems.
    You are also right that a good approximation to the amount
    of time your system will take is proportional to the number of
    copies of the data you make. Therefore, at this first approximate
    level, reducing the number of copies is indeed critical. 
    (g) But in these days of plummeting memory chip prices, and continued
    blossoming of CPU speeds, we should not restrict ourselves to
    slow, small-RAM hardware solutions. A MIPS R10000 chip today with
    dual ported memory for the buffers is no more expensive than
    the LSI-11, 680x0, or Spark chip solutions were last year. The
    new desktop Pentium PRO 200MHz chips with PCI bus and memory
    mapped I/O to dual ported memory can copy the buffer in zero time
    or less (because of overlapping, pre-reading, hardware memory
    protection, write-back cache larger than the size of the buffer,
    and mapping registers). The translation lookaside buffers for
    virtualizing the Spark, MIPS, TI, and Alpha chips, when combined
    with 2 levels of cache can give statistical determinate memory
    access of a single cycle, with the worst case only 8 cycles.
    All of these brands of chips permit the addition of DMA
    channels which can read and write memory in parallel. These are
    just some of the more common brands of chips and there are
    many more brands and many custom chips, ASICs, PALs, etc. Do not
    limit yourself to fore-ordained hardware. Be flexible enough to 
    recognize that any Ada procedure or task can be replaced by a
    chip. For example, they have RISK chip CPU boards that plug into
    a PC, that you talk to through memory mapped RAM locations. 
    Sometimes the best software solution is improved hardware.

Re: Ada95/Mil-Std-1553 Problem (Long Post - Sorry About That)

[Brad Balfour]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2213 bytes --]


In article <97011214115169@psavax.pwfl.com>, "Marin David Condic,
561.796.8997, M/S 731-93" <condicma@PWFL.COM> wrote:

>I have a problem I am trying to solve that involves building a
>good  general purpose interface to a Mil-Std-1553 data bus using
>Ada95.

[snip]

Rather than get into a discussion about the technical details of building
such a binding, I thought I'd just post information I found on the AdaIC's
website at http://sw-eng.falls-church.va.us/AdaIC/docs/flyers/1553b.htm
about a commercial product that provides this service:

--begin excerpt--
Noetic Software, Inc. offers thick and thin Ada 95 bindings for MIL-STD-
1553B (multiplex serial data bus) applications.

Features

      Noetic�s MIL-STD-1553B thick bindings were developed to provide a
      class library of data structures, operators, and objects to implement
      hardware/bus initialization, bus control, remote terminal and bus monitor
      operations. Also available are thin bindings that provide a low-level
      interface to a particular manufacturer�s MIL-STD-1553B hardware. 

Benefits

      These MIL-STD-1553B bindings for Ada 95 allow for an easy transition of
      existing applications to Ada 95 and a greater potential for software reuse
      among all MIL-STD-1553B applications. The use of a standard interface
      reduces costs and time investments associated with training developers in
      the creation and use of 1553B applications. 

Availability

      MIL-STD-1553B bindings for Ada 95 will be available in October 1996. 

For More Information

      For more information, contact: 

            Noetic Software, Inc.
            Michael J. Kiernan
            2300 Computer Avenue, Suite A-6
            Willow Grove, PA 19090
            Phone: 215/784-9580
            Fax: 215/784-9582
            E-mail: mkiernan@noetic.com

-- 
Brad Balfour                            SIGAda WWW Server
CACI, Inc.                                http://www.acm.org/sigada/
(703) 277-6767                          and also try:
bbalfour@std.caci.com                     http://www.adahome.com/
3930 Pender Drive     Fairfax, VA 22030
   "...they even have rules for exceptions" -- Dewar and Schonberg