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

[Amy Hartsough <Hartsough@worldnet.att.net>]

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