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!.POSTED!not-for-mail From: Paul Rubin Newsgroups: comp.lang.ada Subject: Re: How to get Ada to ?cross the chasm?? Date: Sun, 13 May 2018 10:03:18 -0700 Organization: A noiseless patient Spider Message-ID: <8736yvzdwp.fsf@nightsong.com> References: <87k1sg2qux.fsf@nightsong.com> <87h8njmk4r.fsf@nightsong.com> <87po27fbv9.fsf@nightsong.com> <87in7x62vw.fsf@nightsong.com> <878t8szdtk.fsf@nightsong.com> <87tvrdhl5v.fsf@nightsong.com> <874ljc1w76.fsf@nightsong.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: reader02.eternal-september.org; posting-host="c82ca7f9f25fd066772aef1e7a55ff31"; logging-data="15097"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX190z0YGz2aY2DGTmULNlROy" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux) Cancel-Lock: sha1:mJgyK9PrhKLHJa60SYvBTC6AbHk= sha1:BpdMRlttPpbDdYrHcdhJSeg81VY= Xref: reader02.eternal-september.org comp.lang.ada:52339 Date: 2018-05-13T10:03:18-07:00 List-Id: Niklas Holsti writes: > For the UART input-line buffer, the number of non-CR characters > received before a CR character depends on external causes; 1) In a critical system, the sending end would be part of the system and it wouldn't be allowed to send that many characters 2) the receiving end could have to process one character at a time (or one token at a time, any token > N chars considered invalid and so the chars can be thrown away one by one). Port speed would be set low enough to satisfy WCET requirements on the receiving end. In a case where flooding is even possible, the sending end must be non-critical. > I think most such applications also have logging functions, at least > in order to report errors as anomaly events. Well I've never worked on such an application in real life (I arrived at this subject through being interested in logic and proofs as topics in math) so you know way more than I do about how they actually work. But I imagine the app being something like an engine controller in a car. So there might be some variables counting how many anomalies of a given type had occurred, or maybe even a log of the past N such events for some small fixed N, and there'd be no persistent memory so you'd have to connect the ECU up to an analyzer before powering it off, or maybe even run your diagnostics with the analyzer connected. Maybe in todays cars the ECU could send log data to some centralized logging computer constantly but the other receiving end would be non-critical. > if the receiver says "stop sending" to the sender, it can cause > overflow of the sender's transmission queue. Queue-length bounds > become a global system problem. Sure, just like WCET. If both ends are critical then analysis must ensure that overflow doesn't happen. > But today, when time-and-space-isolated partitions are not yet common, > they are still part of the same program, thus usually under the same > coding and design rules. Yeah I'm familiar with big apps that aren't realtime-critical, and have a reasonable picture of how very small critical Atom-like apps work. But I'm aware there is a middle area that's still critical, but more complicated than the Atom-like stuff, where my picture is hazy.