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=unavailable autolearn_force=no version=3.4.4
Path: 
 border2.nntp.dca1.giganews.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!usenet.blueworldhosting.com!feeder01.blueworldhosting.com!peer02.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!post02.iad.highwinds-media.com!news.flashnewsgroups.com-b7.4zTQh5tI3A!not-for-mail
From: Stephen Leake <stephen_leake@stephe-leake.org>
Newsgroups: comp.lang.ada
Subject: Re: STM32F4 Discovery, communication and libraries
References: <60a42dc6-d8d0-4432-ae5a-86de18b82840@googlegroups.com>
 <5kkrv9hejn2qhdckkeo8lidkbh3bkme1gn@4ax.com>
 <5b91313c-acf9-4a6e-b157-6ba7c8021567@googlegroups.com>
 <ru1tv9p9g8gtd7aijug3j2eojdpdgvhihk@4ax.com>
 <0513ad07-6fbe-463a-be6f-097cd5113f52@googlegroups.com>
 <e8yq8rtj1pcm$.glzqqjd7ulsi.dlg@40tude.net>
 <4f1ec65a-d66a-40bf-a0d6-278fde206e70@googlegroups.com>
 <uxgn4sadwori$.7fnns7uw9q79$.dlg@40tude.net>
 <c69kifFfr6sU1@mid.individual.net>
 <1cjwzr30b24xy.11kpydntxhfo5$.dlg@40tude.net>
 <c6bo5nF23tiU1@mid.individual.net>
 <929e9226-e4aa-474e-843c-68ed800eefad@googlegroups.com>
 <5b5583ca-c7b2-40be-9090-6253f0514db5@googlegroups.com>
 <7feccd2d-dcfd-405e-ae5d-e27d6662daa9@googlegroups.com>
 <af4a4b83-6cb3-40ff-bf09-1a27a60db4ec@googlegroups.com>
 <a54dcc42-d4e2-4d53-b381-2bb7a0eef1ee@googlegroups.com>
 <854mwfwonu.fsf@stephe-leake.org> <luq2q9$be4$1@dont-email.me>
Date: Thu, 11 Sep 2014 04:53:43 -0500
Message-ID: <857g1albyw.fsf@stephe-leake.org>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (windows-nt)
Cancel-Lock: sha1:CQ6KA194xDnL0tf+ola+hrbk2P4=
MIME-Version: 1.0
Content-Type: text/plain
X-Complaints-To: abuse@flashnewsgroups.com
Organization: FlashNewsgroups.com
X-Trace: c6dce54117135e3fb833021257
X-Received-Bytes: 3222
X-Received-Body-CRC: 1406817933
Xref: number.nntp.dca.giganews.com comp.lang.ada:188962
Date: 2014-09-11T04:53:43-05:00
List-Id: <comp.lang.ada>

Jeffrey Carter <spam.jrcarter.not@spam.not.acm.org> writes:

> On 09/10/2014 07:11 AM, Stephen Leake wrote:
>> 
>> Way overkill. Global variables is all you need.
>
> While a publish/subscribe mechanism is probably overkill, global variables
> should never be used. Global variables are a guaranteed way to make your S/W
> hard to understand and modify.

I disagree. One way is:

package Global_Variables is

   Sensor_1 : float;
   Sensor_2 : float;
   Actuator_1 : float;

end global_variables;

package Sensor_1 is 

    function Read return Float;

end Sensor_1;

package Controller is

    procedure Execute
        (Sensor_1 : in     Float;
         Sensor_2 : in     Float;
         Actuator :    out Float);    

end controller;

procedure Main is
begin
    loop
        wait_for_cycle;

        case cycle_type is
        when Sensor_1 => 
           Global_Variables.Sensor_1 := Sensor_1.read;

        when Sensor_2 => 
           Global_Variables.Sensor_2 := Sensor_2.read;

        when Control => 
            Controller.Execute 
                (Global_Variables.Sensor_1,
                 Global_Variables.Sensor_2,
                 Global_Variables.Actuator_1);

            -- output to actuator

        end case;

    end loop;
end Main;
         
That is well documented by the structure of the code.

I agree that having "Read" be a procedure that updates
Global_Variables.Sensor_1 in the body, and having Execute read it in the
body, is a bad design.

Global variables are not bad per se, if they are used carefully and
clearly.

What would you propose as an alternative to the above?

-- 
-- Stephe