comp.lang.ada
 help / color / mirror / Atom feed
* tasking design for keylock
@ 2006-03-03 12:36 Rolf
  2006-03-03 13:04 ` Jean-Pierre Rosen
                   ` (2 more replies)
  0 siblings, 3 replies; 5+ messages in thread
From: Rolf @ 2006-03-03 12:36 UTC (permalink / raw)


The following problem arose when I was thinking about the design for a
minimal tasking runtime system.

Many doors are locked by electronic keylocks where one has to type four
correct keys on a small keyboard (mostly 0 .. 9, *, #) before the lock
is opened. Now there are requirements

- that the time between the key presses must not exceed 0.5 seconds,
- and that after the 4th correct key you must not type any key at all
for at least 0.5 seconds.

How do you model the timing requirements using Ada tasking? (I can
attach the h/w interrupt from the key press to a protected procedure,
but I don't know how to proceed from there, i.e. how to cancel or serve
a timed entry call now)

    Rolf

P.S. I made a small state diagram expressing the requirements but don't
know where to upload it.




^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: tasking design for keylock
  2006-03-03 12:36 tasking design for keylock Rolf
@ 2006-03-03 13:04 ` Jean-Pierre Rosen
  2006-03-03 17:55 ` Dmitry A. Kazakov
  2006-03-03 20:48 ` Simon Wright
  2 siblings, 0 replies; 5+ messages in thread
From: Jean-Pierre Rosen @ 2006-03-03 13:04 UTC (permalink / raw)


Rolf a �crit :
> The following problem arose when I was thinking about the design for a
> minimal tasking runtime system.
> 
> Many doors are locked by electronic keylocks where one has to type four
> correct keys on a small keyboard (mostly 0 .. 9, *, #) before the lock
> is opened. Now there are requirements
> 
> - that the time between the key presses must not exceed 0.5 seconds,
> - and that after the 4th correct key you must not type any key at all
> for at least 0.5 seconds.
> 
> How do you model the timing requirements using Ada tasking? (I can
> attach the h/w interrupt from the key press to a protected procedure,
> but I don't know how to proceed from there, i.e. how to cancel or serve
> a timed entry call now)
> 
>
Why not call the Clock function every time a key is pressed?

-- 
---------------------------------------------------------
            J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr



^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: tasking design for keylock
  2006-03-03 12:36 tasking design for keylock Rolf
  2006-03-03 13:04 ` Jean-Pierre Rosen
@ 2006-03-03 17:55 ` Dmitry A. Kazakov
  2006-03-03 20:48 ` Simon Wright
  2 siblings, 0 replies; 5+ messages in thread
From: Dmitry A. Kazakov @ 2006-03-03 17:55 UTC (permalink / raw)


On 3 Mar 2006 04:36:08 -0800, Rolf wrote:

> The following problem arose when I was thinking about the design for a
> minimal tasking runtime system.
> 
> Many doors are locked by electronic keylocks where one has to type four
> correct keys on a small keyboard (mostly 0 .. 9, *, #) before the lock
> is opened. Now there are requirements
> 
> - that the time between the key presses must not exceed 0.5 seconds,
> - and that after the 4th correct key you must not type any key at all
> for at least 0.5 seconds.
> 
> How do you model the timing requirements using Ada tasking? (I can
> attach the h/w interrupt from the key press to a protected procedure,
> but I don't know how to proceed from there, i.e. how to cancel or serve
> a timed entry call now)

You can implement your FSM directly in the protected object. Timing
constraints will be checked in the protected procedure attached to the
keypad interrupt. This procedure will change the state (of the FSM)
according to your diagram. The state "Open" can be used as a barrier for
the entry Open. This entry can be then waited for from some (or several)
external task. You will also need protected procedure attached to the
door/lock interrupt (I presume that it closes automatically after some
delay.) It seems to me that you need no tasks to control the lock.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de



^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: tasking design for keylock
  2006-03-03 12:36 tasking design for keylock Rolf
  2006-03-03 13:04 ` Jean-Pierre Rosen
  2006-03-03 17:55 ` Dmitry A. Kazakov
@ 2006-03-03 20:48 ` Simon Wright
  2006-03-05 19:27   ` Nick Roberts
  2 siblings, 1 reply; 5+ messages in thread
From: Simon Wright @ 2006-03-03 20:48 UTC (permalink / raw)


"Rolf" <rolf.ebert_nospam_@gmx.net> writes:

> The following problem arose when I was thinking about the design for a
> minimal tasking runtime system.
>
> Many doors are locked by electronic keylocks where one has to type four
> correct keys on a small keyboard (mostly 0 .. 9, *, #) before the lock
> is opened. Now there are requirements
>
> - that the time between the key presses must not exceed 0.5 seconds,
> - and that after the 4th correct key you must not type any key at all
> for at least 0.5 seconds.
>
> How do you model the timing requirements using Ada tasking? (I can
> attach the h/w interrupt from the key press to a protected procedure,
> but I don't know how to proceed from there, i.e. how to cancel or serve
> a timed entry call now)

I may have misunderstood (and I may have got protected types wrong),
but .. assuming the interrupt handling PO is like

protected Interrupt_Handler is
   entry Read_Key (K : out Key);
   entry Handler;
   pragma Interrupt_Handler (Handler);
private
   ...
end Interrupt_Handler;

where Read_Key is released by the Handler entry, then you could

select
   Interrupt_Handler.Read_Key (K);
or
   delay 0.5;
   --  deal with missed input opportunity
end select;

--  repeat the above 3 times more

select
   Interrupt_Handler.Read_Key (K);
   --  deal with additional input
or
   delay 0.5;
   --  now we have the correct number of characters and no more
end select;


Thad doesn't handle multiple keypresses so close together that they
bunch up in the PO, of course.



^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: tasking design for keylock
  2006-03-03 20:48 ` Simon Wright
@ 2006-03-05 19:27   ` Nick Roberts
  0 siblings, 0 replies; 5+ messages in thread
From: Nick Roberts @ 2006-03-05 19:27 UTC (permalink / raw)


On Fri, 03 Mar 2006 20:48:52 -0000, Simon Wright <simon@pushface.org>  
wrote:

You probably already know this but:

(a) sound a raspberry (a single low long note) whenever the user makes a  
mistake;

(b) the sound (a short bleep) for each keypress must be the same;

(c) sound a rising two or three-note group to indicate success.

Points (a) and (c) are to give the user feedback. Point (b) is so that an  
interloper cannot tell what combination is being pressed just by  
listening. The raspberry, should always follow the 0.5 second timeout, and  
there should only be one kind of raspberry sound for any mistake, so that  
the combination cannot be progressively guessed.

-- 
Nick Roberts
http://www.nicholasjroberts.co.uk



^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2006-03-05 19:27 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2006-03-03 12:36 tasking design for keylock Rolf
2006-03-03 13:04 ` Jean-Pierre Rosen
2006-03-03 17:55 ` Dmitry A. Kazakov
2006-03-03 20:48 ` Simon Wright
2006-03-05 19:27   ` Nick Roberts

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox