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=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,17395bd9bffaca19 X-Google-Attributes: gid103376,public From: Amy Hartsough Subject: Re: Ada95/Mil-Std-1553 Problem (Long Post - Sorry About That) Date: 1997/01/13 Message-ID: <32DAF214.4070@worldnet.att.net>#1/1 X-Deja-AN: 209637937 references: <97011214115169@psavax.pwfl.com> to: "Marin David Condic, 561.796.8997, M/S 731-93" content-type: text/plain; charset=us-ascii organization: AT&T WorldNet Services mime-version: 1.0 newsgroups: comp.lang.ada x-mailer: Mozilla 2.02E (Win95; I) Date: 1997-01-13T00:00:00+00:00 List-Id: 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