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: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!news.swapon.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Niklas Holsti Newsgroups: comp.lang.ada Subject: Re: STM32F4 Discovery, communication and libraries Date: Fri, 29 Aug 2014 20:58:32 +0300 Organization: Tidorum Ltd Message-ID: References: <60a42dc6-d8d0-4432-ae5a-86de18b82840@googlegroups.com> <5kkrv9hejn2qhdckkeo8lidkbh3bkme1gn@4ax.com> <5b91313c-acf9-4a6e-b157-6ba7c8021567@googlegroups.com> <0513ad07-6fbe-463a-be6f-097cd5113f52@googlegroups.com> <4f1ec65a-d66a-40bf-a0d6-278fde206e70@googlegroups.com> <776fc1ce-f7cf-4e33-b439-0cfe658305af@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: individual.net a4FzQwAYQohggISNtOjsCAU87pBBc1dxkb26KrFaoPP/1dNQVl Cancel-Lock: sha1:4QHwYbVlVABJqcbljmelbhJHd1w= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 In-Reply-To: <776fc1ce-f7cf-4e33-b439-0cfe658305af@googlegroups.com> Xref: news.eternal-september.org comp.lang.ada:21996 Date: 2014-08-29T20:58:32+03:00 List-Id: On 14-08-29 03:07 , Roy Emmerich wrote: > To go a little deeper into my design: > > Each sub-module will run in its own task with its own timer. Hmm. I would probably not design it that way, but of course I don't know all your requirements or plans. To me, the modular aspect and the tasking/timing aspect should be orthogonal and (nearly) independent aspects of the design. I would describe a (functional) module as some coherent, inter-related set of state variables, and operations which use and update the state variables. The module does not necessarily have tasks of its own. A task, on the other hand, defines a time-line of activations of operations in (usually) several modules, which require similar or synchronised timing, sequencing, or periodic execution. In my experience, in a real-time system, most functional modules have operations with different timing constraints and execution periods, and which therefore should be executed by different tasks with different priorities (in a pre-emptive system) or different execution periods (in a statically scheduled, non-pre-emptive system). In my designs, tasks contained in sub-modules tend to be sporadically activated -- for example, the server task in the recent I/O-request-queue discussion -- rather than cyclic. > If, for example, I am monitoring a solar photovoltaic inverter via > MODBUS RTU, it is possible to retrieve a lot of different information. > Some information, like voltage and current, I may want to retrieve > every second whereas other information like battery temperature > I may only want to retrieve every 5 minutes. That agrees with my experience. > The module will know the sampling frequency for each variable to be > monitored and will trigger itself when it is time to do so. If these sampling frequencies are totally unrelated to other frequencies and sampling phases in other sub-modules, defining a dedicated task (or even two tasks, with different periods) within the sub-module can be the sensible thing to do. However, if many sub-modules have similar timing requirements, I would use a couple of global tasks -- say, a cyclic task with 1-second period, and another with a 1 minute period -- and have them call dedicated procedures in this sub-module, and in other sub-modules with similar sample-timing requirements. The benefit is avoiding the local timing calculations; the drawback is that one must consider interference between the tasks. Perhaps the simplest design is to have one global task with a 1-second period, which calls the 1-second operations from all sub-modules in every period, and the 1-minute operations in every 60th period. But this assumes that all the 1-minute operations can be finished in less than one second of execution time. Reducing the number of tasks in this way reduces the need for stack-space RAM and tends to make the system's behaviour more regular, predictable and understandable. But if your processor has plenty of speed and memory, these effects may not be important to you. If you want to make it very easy to add/remove sub-modules from the system, defining local tasks in each sub-module may be the better choice, because then you can easily avoid explicit calls from the main application to the sub-module. > Using protected objects and hard/firm/soft/non-critical tasks > it sounds like this could indeed be a viable approach. Sure. Many systems have been built that way in Ada. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ .