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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,9b75d36fda92b3ba X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news2.google.com!proxad.net!proxad.net!news.clara.net!wagner.news.clara.net!fi.sn.net!newsfeed2.fi.sn.net!news.song.fi!not-for-mail Date: Thu, 19 Jan 2006 12:16:27 +0200 From: Niklas Holsti Organization: Tidorum Ltd User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050513 Debian/1.7.8-1 X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Using Ada (or SPARK) in Ada-unaware environment References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <43cf66fc$0$7484$39db0f71@news.song.fi> NNTP-Posting-Host: laku61.adsl.netsonic.fi X-Trace: 1137665788 news.song.fi 7484 81.17.205.61:32852 X-Complaints-To: abuse@song.fi Xref: g2news1.google.com comp.lang.ada:2529 Date: 2006-01-19T12:16:27+02:00 List-Id: Maciej Sobczak wrote: > Hi, > > Imagine a control system (to be developed) which needs to interact with > some devices. Those devices are supplied with C drivers and libraries. Been there a couple of times. > What is the recommended practice for developing this control system in > Ada (or SPARK)? I basically see two options for this: > > 1. Enjoy Ada's ability to interface with C libraries (pragma Import) and > write everything in Ada. I have always used this option. It works well *unless* the C libraries try to interact with the OS/kernel using signals or timers (sleeps), or create their own threads. Sometimes the C library interface (C header files) relies heavily on #define macros, which can make writing the Ada specs rather boring. It helps to put one layer of application-specific C routines between the C libraries and the Ada code, presenting a simpler, application-specific C-Ada interface. > 2. Write separate programs in C (or C++) that will be responsible only > for talking to the devices via their C access libraries. Write the main > controller in Ada, as another separate program, and use some form of > interprocess communication to have all those components talk. I would do that only if the C libraries use the OS features I mentioned above, in which case it would be easier to isolate the C code in its own process (= program). Still, you would need an Ada run-time (tasking) that connects well to the interprocess communication primitives, eg. lets an Ada task wait on an OS mutex or signal. > The advantage of the second option is that the controller part can be > easily tested in isolation or in a fake environment. Hmmm... I have usually done that in option 1 by implementing a test/fake version of the C libraries themselves. The only reason why this could be simpler in option 2 is if the test/fake code must be written in C and needs to use the OS features mentioned above. In option 1, the test/fake code can be written in Ada and use Ada tasking and I/O if necessary, which seems a lot simpler to me. My 2 cents... -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ .