Help! (Ada/Integrity/PEG)

Help! (Ada/Integrity/PEG)

[TAMS Team]

We're just about to start our project using Integrity/AdaMulti to code the
main part of the application, with PEG as our GUI designer.  The target
hardware will be a Radstone PPC4 board.  The (Ada) application will decode
serial data coming from a remote processor to generate the screen layouts
and softkeys (and changes to their properties, e.g. text contents), and
encode serial data to send back to the remote processor which will
essentially only contain information about softkey presses and status flags
from the screen hardware.  All the PEG task is required to do is to display
the appropriate windows or softkeys.

Our first hurdle to overcome is how to get the main application task talking
to the GUI task.  We're not quite sure how to get started, but I think we've
convinced ourselves we may have to use some form of messaging.  However,
we're not certain of the form of messaging - i.e. typically how do you send
a message to the RTOS message queue, what form is it, and how does PEG pull
it from the queue?

Any advice (or even sample code!) greatly received!

(Please assume we're complete novices with absolutely no experience using
this combination of products, and you'll be pretty close to the truth!)

Re: Help! (Ada/Integrity/PEG)

[Mr. Caffiene]

On Fri, 21 Dec 2001 15:31:10 -0000
"TAMS Team" <tamsteam@rolls-royce-rps.demon.co.uk> wrote:

> We're just about to start our project using Integrity/AdaMulti to code the
> main part of the application, with PEG as our GUI designer.  The target
> hardware will be a Radstone PPC4 board.  The (Ada) application will decode
> serial data coming from a remote processor to generate the screen layouts
> and softkeys (and changes to their properties, e.g. text contents), and
> encode serial data to send back to the remote processor which will
> essentially only contain information about softkey presses and status flags
> from the screen hardware.  All the PEG task is required to do is to display
> the appropriate windows or softkeys.
> 
> Our first hurdle to overcome is how to get the main application task talking
> to the GUI task.  We're not quite sure how to get started, but I think we've
> convinced ourselves we may have to use some form of messaging.  However,
> we're not certain of the form of messaging - i.e. typically how do you send
> a message to the RTOS message queue, what form is it, and how does PEG pull
> it from the queue?
> 
> Any advice (or even sample code!) greatly received!
> 
> (Please assume we're complete novices with absolutely no experience using
> this combination of products, and you'll be pretty close to the truth!)
> 
> 

Is the main application task coded in Ada or another language. If written in another language, you would want to use the the standard Ada "Interfaces" libraries to communicate with the task.(Assuming I understand what your saying.)
Also, rather than using messaging, you could use a storage pool controlled by a "semaphore" of sorts, which might be much more efficient. A stack of some sort would probably be the fastest method, but also the most troublesome to work with.(Unless you happen to be using Forth. Heh.)

A little more detail(if at all possible) on what your doing would enable us(or at least me) to provide a little more pertinent advice.(I use to do C coding on RTEMS, another RTOS. Thank G-d I discovered Ada. Heh.)

Re: Help! (Ada/Integrity/PEG)

[TAMS Team]

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!


"Mr. Caffiene" <nospam@attbi.com> wrote in message
news:20011221103954.4cd90f91.nospam@attbi.com...
> On Fri, 21 Dec 2001 15:31:10 -0000
> "TAMS Team" <tamsteam@rolls-royce-rps.demon.co.uk> wrote:
>
> > We're just about to start our project using Integrity/AdaMulti to code
the
> > main part of the application, with PEG as our GUI designer.  The target
> > hardware will be a Radstone PPC4 board.  The (Ada) application will
decode
> > serial data coming from a remote processor to generate the screen
layouts
> > and softkeys (and changes to their properties, e.g. text contents), and
> > encode serial data to send back to the remote processor which will
> > essentially only contain information about softkey presses and status
flags
> > from the screen hardware.  All the PEG task is required to do is to
display
> > the appropriate windows or softkeys.
> >
> > Our first hurdle to overcome is how to get the main application task
talking
> > to the GUI task.  We're not quite sure how to get started, but I think
we've
> > convinced ourselves we may have to use some form of messaging.  However,
> > we're not certain of the form of messaging - i.e. typically how do you
send
> > a message to the RTOS message queue, what form is it, and how does PEG
pull
> > it from the queue?
> >
> > Any advice (or even sample code!) greatly received!
> >
> > (Please assume we're complete novices with absolutely no experience
using
> > this combination of products, and you'll be pretty close to the truth!)
> >
> >
>
> Is the main application task coded in Ada or another language. If written
in another language, you would want to use the the standard Ada "Interfaces"
libraries to communicate with the task.(Assuming I understand what your
saying.)
> Also, rather than using messaging, you could use a storage pool controlled
by a "semaphore" of sorts, which might be much more efficient. A stack of
some sort would probably be the fastest method, but also the most
troublesome to work with.(Unless you happen to be using Forth. Heh.)
>
> A little more detail(if at all possible) on what your doing would enable
us(or at least me) to provide a little more pertinent advice.(I use to do C
coding on RTEMS, another RTOS. Thank G-d I discovered Ada. Heh.)

Re: Help! (Ada/Integrity/PEG)

[Mr. Caffiene]

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

Re: Help! (Ada/Integrity/PEG)

[tmoran]

> 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 ...
  If I understand what you're doing, an Ada "protected record" would be
just the ticket here.  The queue data is hidden inside and the routines
to insert/remove items are visible, but only one routine is allowed to
execute at a time, so two tasks can't step on each other's feet.
Essentially you let the compiler handle the semaphore for you, making
your life simpler and less subject to mistakes, and the compiler
run-time probably does the job more efficiently.

Re: Help! (Ada/Integrity/PEG)

[Mr. Caffiene]

On Tue, 25 Dec 2001 03:20:25 GMT
tmoran@acm.org wrote:

> > 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 ...
>   If I understand what you're doing, an Ada "protected record" would be
> just the ticket here.  The queue data is hidden inside and the routines
> to insert/remove items are visible, but only one routine is allowed to
> execute at a time, so two tasks can't step on each other's feet.
> Essentially you let the compiler handle the semaphore for you, making
> your life simpler and less subject to mistakes, and the compiler
> run-time probably does the job more efficiently.

Hmmmm...I dont doubt that it's simpler. 

I'll test that method out. I'm curious how much of a performance penalty 
the compiler runtime would cause. I'm used to explicitly declaring and 
controlling the memory from scratch(likely due to my C and Assembler roots)
however an implicit run-time just might prove to be more effective in this
particular task.

I'll let you know what I discover.

Mr. Caffiene

Merry X-mas

chris@dont.spam.me