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 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> <0513ad07-6fbe-463a-be6f-097cd5113f52@googlegroups.com> <4f1ec65a-d66a-40bf-a0d6-278fde206e70@googlegroups.com> <1cjwzr30b24xy.11kpydntxhfo5$.dlg@40tude.net> <929e9226-e4aa-474e-843c-68ed800eefad@googlegroups.com> <5b5583ca-c7b2-40be-9090-6253f0514db5@googlegroups.com> <7feccd2d-dcfd-405e-ae5d-e27d6662daa9@googlegroups.com> Date: Wed, 10 Sep 2014 09:11:49 -0500 Message-ID: <854mwfwonu.fsf@stephe-leake.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (windows-nt) Cancel-Lock: sha1:Yjw8nce243V1wIgPwLkvwrGrSXU= MIME-Version: 1.0 Content-Type: text/plain X-Complaints-To: abuse@flashnewsgroups.com Organization: FlashNewsgroups.com X-Trace: 31ab054105c33e3fb833002462 X-Received-Bytes: 5932 X-Received-Body-CRC: 2103992655 Xref: number.nntp.dca.giganews.com comp.lang.ada:188944 Date: 2014-09-10T09:11:49-05:00 List-Id: Roy Emmerich writes: > Let me give a little bit of background to my thinking. Let's say at > the top of every minute you want to measure ambient temperature (via > analogue input), solar irradiance (via analogue input) and inverter > current (via MODBUS RTU to the inverter) with my data logger. Going > with a sequential mindset to start with, you will always know that > with a single core (or multi-core) processor the samples will be > sequential. The one sample follows the other and you have to programme > things this way (e.g. iterating through an array of variables to > sample). Threading (or tasking in Ada) on a single processor > essentially does the same thing but the programming is done in a way > that it looks like the three samples are taken at the same time (i.e. > simultaneously sample ambient temperature, solar irradiance and > inverter current at the top of every minute). The approach, however, > is very different. The samples will each take a few milliseconds at most; that's negligible compared to the once per minute period. Sequential is fine. Also, the analog hardware determines the inter-sample rate. To sample three channels truly simultaneously, you need three A/D's, with a trigger pulse to start the sample. Way overkill for this application. Most likely, you'll have one A/D, so all your samples will be sequential. Then you have a choice of triggering each one individually, or just continuously looping thru all of them. > Also, in my mind, it seems to be the right way to tackle the problem > from the outset. It may be an overly complicated approach just to > solve the logging aspect but I am also hoping to extend it to include > control aspects too. Yes, control may have tighter timing requirements. But if they can all be expressed as fixed periods, and it all fits within your CPU budget, then a timer-driven single thread is the way to go. Anything more complicated just makes the system harder to understand, and eats power. If it doesn't fit within your CPU budget, and you are trying to do the "best" in some degraded mode, then tasking might be useful, if you can design an approprite scheduling algorithm. > Once the complexity increases I have the feeling a multi-threaded > approach will be much more modular, "module" /= "thread" "module" = "package" threads are required when different functions truly overlap in time, in ways that are too complex to handle with a timer-driven design. You may have several threads, each running several modules. If the application really needs multiple CPUs/cores in order to get everything done in time, then you need threads. > * thread one, here's your configuration, you take care of inverter > current sampling every 5 seconds. > * thread two, here's your configuration, you take care of solar > irradiance sampling every 1 second. > * thread 3, here's your configuration, you take care of diesel generator control. > * etc. Timer interrupt config: period 5 seconds: inverter current sampling period 1 second: solar irradiance sampling period ?: diesel generator control At those slow periods, you'll have plenty of CPU time. In Ada, timer interrupts are most easily handled as protected entries. These can simply call the appropriate module subprograms, or they can release a thread, by changing a guard variable on another entry. > To solve inter-thread communication I am looking at some sort of > variable publish/subscribe design. Way overkill. Global variables is all you need. If it gets very complex, you might want a symbol table, with name lookup at elaboration time (which may be what you mean by publish/subscribe). That way, you can have more than one instance of a module, with variable names that include the module name: analog_sampler_1.value, analog_sampler_2.value. What do the three modules mentioned above have to say to each other? The diesel generator needs the sensor values; just read the global variables. > Does this make it clearer? I'm trying to plan for the long term and > currently feel like I'm in a state of analysis paralysis :) It takes three tries to get it right; just relax and do the first implementation, for an actual application that you might get paid for soon. It will be wrong, but you'll learn a lot, and maybe you'll make some money if it's good enough. -- -- Stephe