* Re: Bidirectional UART design for Ravenscar
2017-08-25 22:24 Bidirectional UART design for Ravenscar Simon Wright
2017-08-25 22:40 ` Niklas Holsti
@ 2017-08-26 11:04 ` Jeffrey R. Carter
1 sibling, 0 replies; 3+ messages in thread
From: Jeffrey R. Carter @ 2017-08-26 11:04 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 3+ messages in thread