Bidirectional UART design for Ravenscar

Bidirectional UART design for Ravenscar

[Simon Wright]

I'm trying to implement a two-way interrupt-driven interface via a UART
with Ravenscar, and having trouble because there is one interrupt with
multiple causes; a writer must wait until transmission is possible
before putting the next character, while a reader must wait until
there's a character to be read.

This makes it hard to write a PO with a single entry (a Ravenscar
restriction) that serves both requirements.

It occurs to me that the interrupt handler could release one of two
suspension objects; if it's Tx_Transfer_Complete, release the SO that
the writer waits on, if it's Rx_Transfer_Complete release the reader's
SO.

Does that seem a reasonable approach?

Re: Bidirectional UART design for Ravenscar

[Niklas Holsti]

On 17-08-26 01:24 , Simon Wright wrote:
> I'm trying to implement a two-way interrupt-driven interface via a UART
> with Ravenscar, and having trouble because there is one interrupt with
> multiple causes; a writer must wait until transmission is possible
> before putting the next character, while a reader must wait until
> there's a character to be read.
>
> This makes it hard to write a PO with a single entry (a Ravenscar
> restriction) that serves both requirements.
>
> It occurs to me that the interrupt handler could release one of two
> suspension objects; if it's Tx_Transfer_Complete, release the SO that
> the writer waits on, if it's Rx_Transfer_Complete release the reader's
> SO.
>
> Does that seem a reasonable approach?

IMO yes.

I suppose that Tx and Rx completion can happen at the same time (in the 
same execution of the interrupt handler), in which case both suspension 
objects should be released.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

Re: Bidirectional UART design for Ravenscar

[Jeffrey R. Carter]

On 08/26/2017 12:24 AM, Simon Wright wrote:
> I'm trying to implement a two-way interrupt-driven interface via a UART
> with Ravenscar, and having trouble because there is one interrupt with
> multiple causes; a writer must wait until transmission is possible
> before putting the next character, while a reader must wait until
> there's a character to be read.
> 
> This makes it hard to write a PO with a single entry (a Ravenscar
> restriction) that serves both requirements.
> 
> It occurs to me that the interrupt handler could release one of two
> suspension objects; if it's Tx_Transfer_Complete, release the SO that
> the writer waits on, if it's Rx_Transfer_Complete release the reader's
> SO.
> 
> Does that seem a reasonable approach?

It should work. It seems unnecessarily low level, with the additional 
opportunities for error that that brings.

Under Ravenscar, something that conceptually would be a PO with multiple entries 
has to become multiple POs with 1 entry each. When the entry is just a 
wait/release, it can be replaced by an SO.

I'd probably do an initial Ravenscar design like (really, I do the design 
graphically, but the graphics then translate mechanically into Ada specifications):

protected type Waiter is
    procedure Signal;
    entry Wait;
private -- Waiter
    Occurred : Boolean := False;
end Waiter;

Rx_Waiter : Waiter;
Tx_Waiter : Waiter;

protected UART_Interrupt is
    procedure Handle;
    pragma Attach_Handler (Handle, ...);
end UART_Interrupt;

Handle calls Rx_Waiter.Signal or Tx_Waiter.Signal. (It's been a while since I 
looked at Ravenscar, but I think such calls are OK. If not, then you'd have to 
add an entry to UART_Interrupt and have a task between it and the Waiter POs.)

Then your Tx task might be

loop
    UART.Put (Byte => Output.Next);
    Tx_Waiter.Wait;
end loop;

and your Rx task,

loop
    Rx_Waiter.Wait;
    Input.Put (Byte => UART.Received);
end loop;

Whether the overhead of the extra POs is too much for your application depends 
on the timing requirements and measurement.

I worked with Bo Sandén once on what would be involved in a Ravenscar solution 
of his Flexible-Manufacturing-System problem (I don't think it was ever 
published). The full-Ada solution was full of protected queues of IDs for 
matching available resources with tasks that needed them. For example, a Q to 
match available autonomous guided vehicles (AGVs) with job tasks that needed 
them. When an AGV was available, its ID was put on the Q. When a job needed an 
AGV, it blocked on the Q's Get entry until the Q was not empty, then got an AGV 
ID. Multiple job tasks could be blocked on the Q, which is not allowed in 
Ravenscar*. That simple protected Q turned into 2 protected Qs, a PO per 
workstation, and a helper task to connect them all.

Personally, I found the single Q easier to understand and analyze, but I guess 
that's not true of automated tools.

*Neither are the dynamically created job tasks, so the design had to be inverted 
from job tasks that obtain the resources needed to process them to workstation 
tasks that find jobs that need their services. At least 1 other 
Ravenscar-compliant design is possible.

-- 
Jeff Carter
"This scene's supposed to be in a saloon, but
the censor cut it out. It'll play just as well
this way." [in a soda fountain]
Never Give a Sucker an Even Break
113