Re: Help! (Ada/Integrity/PEG)

[Mr. Caffiene <nospam@attbi.com>]

On Mon, 24 Dec 2001 09:58:46 -0000
"TAMS Team" <tamsteam@rolls-royce-rps.demon.co.uk> wrote:

> Thanks for your reply.
> 
> We currently have a system which contains a processor card that sends serial
> data (RS100 protocol) to a remote display panel, which draws all relevant
> screen layouts and softkeys.  The display panel handles softkey inputs, and
> transmits the key touches back to the processor card via the serial port
> (again, formatted to RS100 protocol).
> 
> What we're starting at the moment is work to replace the display panel
> (mainly due to obsolescence problems).  However, as the processor card will
> not change in the system, all inputs/outputs to the panel must also be
> unchanged, and the processor must see the new panel as the same black box.
> To achieve this, we're going to be writing the software that actually runs
> in the new panel - this will handle interpreting incoming RS100 data from
> the system's processor, drawing the screen displays, handling softkey input,
> returning key touch data to RS100 protocol, and additional functionality
> such as operator aids and a help system.
> 
> The main application for the display panel software will be written using
> Ada 95 (easiest to justify, due to the nature of the application!).  We have
> already got AdaMULTI/Integrity for the main development, but have also
> chosen PEG to handle all the GUI bits and bobs.  So basically everything we
> can do in Ada, we will do, with the exception of the GUI, which will be
> achieved using PEG/C++.  What we're not sure about is how to get the main
> Ada task to talk to the PEG task!  At the moment phrases like "semaphore",
> "storage pool" and even "messaging" just about make sense, but as you can
> probably tell, we're just at the bottom of our learning curve!
> 
> We look forward to your guidance (and appreciate your tolerance!)...!!!
> 
> Cheers & Merry Xmas!

Alright, I'm going to speak abstractly here, and not use sample code as I would most likely cause more confusion if I went into implementation details.

I'm currently writing a Point of Sale application which can run on top of either an RTOS or a Virtual Machine. This sounds somewhat related to what your describing.
I'm using embedded QT (from Trolltech) for the display, so I'm becoming much more familiar with interfacing with C++. I hope to post up the code under the LGPL once it's in a sane state.

As far as interfacing to the PEG/C++ libs, that should be a piece of cake. I'm using the Ada.Interfaces.C libraries(should be built right into your compiler) to handle "importing" and "exporting" of data and parameters.
The method (abstractly speaking) that I'm using to keep it running within my declared time contraints are as such...

1. I instantiate a fixed size qeue at startup. This qeue is used for passing data and parameters. Normally the qeue will behave as any qeue. Except if for some unforseen reason the application should require information from the qeue out of order, it can grab the information and the queue automatically re-orders itself. This seems to be working well so far.

2. As either task can insert information into the qeue, I use a semaphore to control when either task can access. A semaphore is a concept from the Unix world which has two values ( True/False, 1/0, Open/Closed, Left/Right, foo/bar) . Basically if the semaphore is set to Closed, the qeue can only be accessed by the Ada Task, if it is set to Open it can then be accessed by the QT task. As the Ada task is the controlling procedure, it decides when the qeue is open or closed.(A qeue is a type of stack where the values in the stack are inserted at the "rear" and removed at the "front".)

This method is very fast, and has not resulted in any data corruption that I've detected. Likewise I can configure it for different sized stacks depending on the platform being used.

Somethings I have yet to do...

Implement a thorough error detection system to check data being passed in from the QT task. This is going to be a challenge, but I never trust data being passed in from outside tasks.

Also, for most situations where the Ada task is sending information to the QT task is not even necessary to use the qeue, as I can just drop the data directly into the QT memory heap using the Interfaces library. It's a snap, so I've discovered.

Make sure I dont accidentally mix in QT code with my soon to be LGPLed code. Licensing issues can be a pain in the ass. I'll be contacting Trolltech shortly to clarify the matter. This is an experimental prototype, so I dont see much of a problem.

For more information on qeues, I'll refer you to Donald E. Knuth's "The Art of Computer Programming" volume 1. Look it over, lots of good stuff there.

As far as specific implementation details, I would recommend talking to one of the more experienced developers here in the newsgroup, as they would be better suited to communicating all the nuances that such a project would involve. My yammering would end up sounding like so much jibberish. Heh.

I hope this abstract description helps somewhat. Good Luck with your project.

Mr. Caffiene
chris@dont.spam.me