Re: How to get Ada to ?cross the chasm??

[Paul Rubin <no.email@nospam.invalid>]

Niklas Holsti <niklas.holsti@tidorum.invalid> 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.