[taste-users] Re: [MSDL] TASTE - drivers and code reuse

["Maxime Perrotin" <Maxime.Perrotin@xxxxxxx>]

Hi Jorge,

In general, the construct of choice when dealing with drivers is the Blackbox devices (set the function language to Blackbox_Device in the interface view). They have the particularity that the messages they receive (through provided interfaces) are not decoded by the runtime - they are sent "raw" to your functional code. If you specify an ACN encoding for these messages, you can let the tools encode the data in any format you want. Then, in your functional code, you can implement your driver code, and send directly this data to HW without having to reformat it.

The limitation is that blackbox devices are only in C, not in Ada.

I just created a small demo that covers your case of interfacing with Interface.Unsigned_32

If you update your TASTE VM you can find it in ~/tool-src/testSuites/WorkInProgress/Demo_Matlab2013_BlackBox_Ada_ACN

At the root you will find these two files:

DataView.asn   -> contains  MyInteger ::= INTEGER (0..255)

DataView.acn   -> Defines  MyInteger[encoding pos-int, size 32, endianness little]

This way I instruct ACN to encode this type with a memory structure that complies with Unsigned_32

In the Interface view, I created a function called Driver, implemented in "Blackbox device":

The Send_Something interface has a parameter for which I selected ACN as encoding, and of type MyInteger:

The signature of the skeleton function is then:

void driver_Send_Something(void *IN_something, size_t size_IN_something);

Note that there is no type because this is an ACN-encoded buffer.

I filled in the code with something simple - and ending with a call to the Ada function:

Separately, I created an Ada function (my_ada_driver) and exported the symbol to C:

And I wrote a simple implementation to display the value (but this is where you put your own code)

:

At the moment you have to compile the file yourself:

gnatgcc -c adadriver.adb

to get a file called adadriver.o

Next I added this extra file to the build command in build-script.sh:

 --with-extra-Ada-code demo_simulink2013:./driver/ada_driver/ 

And that's it - no need to manually convert the parameters.

I built the project and ran it:

[SDL] Starting: 0
[C Driver] Received ACN-encoded data: 0
[Ada] Received value : 0
[SDL] Starting: 1
[C Driver] Received ACN-encoded data: 1
[Ada] Received value : 1
[SDL] Starting: 2
[C Driver] Received ACN-encoded data: 2
[Ada] Received value : 2
[SDL] Starting: 3
[C Driver] Received ACN-encoded data: 3
[Ada] Received value : 3

Phew - data is consistent across SDL, C and Ada !

It is quite simple - but obviously there is one step that we could avoid, if there were direct support for blackbox devices. Let me know if this is what you would need or if this can be sufficient for you.

For other situations, it is a case by case basis - in some situations it may be easier to simply convert the types manually (especially when you are in the same language), I think there is no general rule.

Hope that answers to your question..

Maxime

On Mon, 27 May 2013 13:37:12 +0200, Jorge Garrido Balaguer <jgarrido@xxxxxxxxxxxxxxx> wrote:

Dear Maxime,

Once I've done the TASTE example, I was wondering how code reuse is possible in TASTE. 

This came to my mind when I was thinking in a more complex or real example. My idea is to use one of our Leon engineering boards to test a new real time clock using TASTE, more or less simulating a real on board operation: the housekeeping manager checks the system, generates the TM and sends it through the radio. The RT clock is connected through an I2C bus and the radio by a serial line.

So the question (or question) is, which is TASTE approach to drivers and code reusing? I mean, since in TASTE the design begins with a data definition, which has to be used in the interface view it is not straight forward to use code with interfaces designed for other data types. For example, our RT clock driver (written in ADA) takes an Interfaces.Unsigned_32 as a parameter. For this case, three approaches come to my mind:

• Forget about the driver in the interface view, and just declare a Housekeeping function in ADA so I can call the driver inside the ADA code, using Interfaces and so on.
• Declare two functions, one called Housekeeping (any language) and a Housekeeping_middleware in ADA in which I just "translate" data types
• In general, declare a Middleware function used by the rest of the system to interact with all the reused code (drivers, etc).

Each one has benefits and drawbacks, and probably none of them is what it is proposed in Taste. What is your opinion?

Thank you very much,

Jorge

--

ESA - European Space Agency

Maxime Perrotin

TASTE Project manager

PROBA V - PROBA 3 Software engineer

System, Software and Technology Department

ESTEC

Keplerlaan 1, PO Box 299

NL-2200 AG Noordiwjk, The Netherlands

maxime.perrotin@xxxxxxx | www.esa.int

+31 (0)71 565 4923 | Fax +31 (0)71 565 5420

This message and any attachments are intended for the use of the addressee or addressees only. The unauthorised disclosure, use, dissemination or copying (either in whole or in part) of its content is not permitted. If you received this message in error, please notify the sender and delete it from your system. Emails can be altered and their integrity cannot be guaranteed by the sender.

Please consider the environment before printing this email.