[C.CC USERS] Help needed with PRI ALT

[Matt Jadud]

Thank you, Carl. I missed that in a quick note last night. (James and I
were working on getting his list membership sorted out.)

James, another useful thing you might consider is drawing a dataflow
diagram of your application, and thinking about how the data will flow from
one parallel process to another. Some simple ones are in this paper:

http://www.jadud.com/dl/pdf/jadud-simpson-jacobsen-sigcse2008.pdf

and a slightly more complex one is in this paper:

http://www.jadud.com/dl/pdf/jacobsen-jadud-kilic-sampson-cpa2011.pdf

If someone on the list could point me at a more "legoland" resource, that
would be great. I know there must be some material that will help James in
thinking about how things flow from point A to point B in his app.

It feels a bit like you're wrestling with two things: the language, and the
paradigm. I'm thinking that we might be able to help you tease those apart
a little bit.

Keep asking questions!

Cheers,
Matt


On Thu, Dec 20, 2012 at 9:24 AM, Carl Ritson <C.G.Ritson at kent.ac.uk> wrote:

> Hi James,
>
> Because your PRI ALT is in a tight loop with a SKIP guard the system
> scheduler never gets a chance to run and no other processes can be run
> and read/drive the pins. At least that is what it looks like is
> happening to me.
>
> You have three option:
> 1. Add a delay after digital.write (SprayLED, HIGH).
> 2. Add a RESCHEDULE() after digital.write (SprayLED, HIGH).
> 3. Use a timer guard to activate digital.write (SprayLED, HIGH) if
> CatIn! and CatOut! do not signal within a set time period.
>
> All of these will allow the scheduler to run the other processes.
>
> Cheers,
>
> Carl
>
>
> 2012/12/20 James Brown <james.brown4994 at gmail.com>:
> > Can anyone help me with PRI ALT.
> >
> > I am a beginner and have been trying to figure out how to use occam to
> build
> > a simple cat deterrent.
> >
> > I have the following code.  It is not representative of what I want it
> to do
> > eventually but rather to experiment with PRI ALT.
> >
> > I am expecting that a signal from CatOut or CatIn should drive ArmedLED
> low
> > or high.  However it appears to ignore these signals.  I appears always
> to
> > default to final TRUE & SKIP condition.  I am stuck and I don't know how
> to
> > debug it.  Any ideas gratefully received.
> >
> > #INCLUDE "plumbing.module"
> >
> > VAL OutPin IS 2 :
> > VAL InPin IS 3 :
> > VAL ArmedLED IS 12 :
> > VAL SprayLED IS 13 :
> >
> > PROC blink.pin (CHAN SIGNAL out!)
> >   WHILE TRUE
> >     SEQ
> >       delay (500)
> >       out ! SIGNAL
> > :
> >
> > PROC monitor.pir ()
> >   SEQ
> >     digital.mode (InPin, INPUT)
> >     digital.mode (OutPin, INPUT)
> >     digital.mode (ArmedLED, OUTPUT)
> >     digital.mode (SprayLED, OUTPUT)
> >     digital.write (ArmedLED, LOW)
> >     digital.write (SprayLED, LOW)
> >     CHAN SIGNAL CatIn, CatOut:
> >     PAR
> >       blink.pin (CatOut!)
> >       delay (300)
> >       blink.pin (CatIn!)
> >       WHILE TRUE
> >         PRI ALT
> >           CatOut ? SIGNAL
> >             digital.write (ArmedLED, LOW)
> >           CatIn ? SIGNAL
> >             digital.write (ArmedLED, HIGH)
> >           TRUE & SKIP
> >             digital.write (SprayLED, HIGH)
> > :
> >
> >
> > _______________________________________________
> > users mailing list
> > users at concurrency.cc
> > http://lists.concurrency.cc/mailman/listinfo/users
> >
>
> _______________________________________________
> users mailing list
> users at concurrency.cc
> http://lists.concurrency.cc/mailman/listinfo/users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.concurrency.cc/pipermail/users/attachments/20121220/cf145e40/attachment.htm>