[C.CC USERS] users Digest, Vol 14, Issue 1

Tue Mar 1 23:37:08 GMT 2011

Hi,

Just a side note this company below makes a nice 8 bit 24 MHZ USB Logic
Analyzer that is reasonably inexpensive...~ $150.00 USD. Has protocol
analyzers for I2C SPI etc.

http://www.saleae.com/logic/

Paul
<http://www.saleae.com/logic/>

On Tue, Mar 1, 2011 at 8:00 AM, <users-request at concurrency.cc> wrote:

> Send users mailing list submissions to
>        users at concurrency.cc
>
> To subscribe or unsubscribe via the World Wide Web, visit
>        http://www.concurrency.cc/mailman/listinfo/users
> or, via email, send a message with subject or body 'help' to
>        users-request at concurrency.cc
>
> You can reach the person managing the list at
>        users-owner at concurrency.cc
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of users digest..."
>
>
> Today's Topics:
>
>   1. Re: 3 Blinkin lights - other solutions (Steve Pretty)
>   2. Re: 3 Blinkin lights - other solutions (Matt Jadud)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 28 Feb 2011 21:38:47 +0000
> From: Steve Pretty <steve.g.pretty at btinternet.com>
> Subject: Re: [C.CC USERS] 3 Blinkin lights - other solutions
> To: users at concurrency.cc
> Message-ID: <4D6C15E7.9080006 at btinternet.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> I tried the three (and 4 and 5!) Blinkin lights myself.  It is
> fascinating to see the kind of complex issues that can arise in
> concurrent code coming up in just three lines of code.  Using "Blink" on
> three LEDs is causing 18 (at least) occam processes to compete for
> processing cycles ( each Blink starts a tick (which starts a delay) and
> a pin.toggle (which starts a toggle and a digital.output).
>
> Of course, if you just want three LEDs to flash in syncronism, you might
> be best just to use a single timer and distribute the output to three
> output functions - e.g.:
>
> #INCLUDE "plumbing.module"
>
> PROC delta3 (CHAN SIGNAL x?, x1!, x2!, x3!)
>   WHILE TRUE
>     SEQ
>       x  ? SIGNAL
>       x1 ! SIGNAL
>       x2 ! SIGNAL
>       x3 ! SIGNAL
> :
>
> PROC main ()
>   CHAN SIGNAL s, s1, s2, s3:
>   PAR
>     tick (100, s!)
>
>     delta3 (s?, s1!, s2!, s3!)
>
>     pin.toggle (11, LOW, s1?)
>     pin.toggle (10, LOW, s2?)
>     pin.toggle (9, LOW, s3?)
> :
>
> All the lights run in synch using this approach. Well - actually, I put
> a logic analyser on it - becasue of the concurrency, the LEDs come on
> one after another, with the third coming on typically 5ms after the first.
>
> The engineering side of me says that the simplest way to get three LEDS
> to blick in sync is to wire them in parallel!
>
> Steve
>
>
>
> ------------------------------
>
> Message: 2
> Date: Mon, 28 Feb 2011 17:08:07 -0500
> From: Matt Jadud <matt at jadud.com>
> Subject: Re: [C.CC USERS] 3 Blinkin lights - other solutions
> To: Steve Pretty <steve.g.pretty at btinternet.com>
> Cc: users at concurrency.cc
> Message-ID:
>        <AANLkTinGSApoOBTzvv=gbKV3tswmkq06rfbEtVyGeKpB at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Hi all,
>
> On Mon, Feb 28, 2011 at 16:38, Steve Pretty
> <steve.g.pretty at btinternet.com> wrote:
> > to see the kind of complex issues that can arise in concurrent code
> coming
> > up in just three lines of code. ?Using "Blink" on three LEDs is causing
> 18
> > (at least) occam processes to compete for processing cycles ( each Blink
> > starts a tick (which starts a delay) and a pin.toggle (which starts a
> toggle
> > and a digital.output).
>
> Steve is exactly right. blink(...,...) was written in a completely
> compositional style, which leads to lots of processes. Further, we run
> smack into Lar's timing issues.
>
> > Of course, if you just want three LEDs to flash in syncronism, you might
> be
> > best just to use a single timer and distribute the output to three output
> > functions - e.g.:
>
> > All the lights run in synch using this approach. Well - actually, I put a
> > logic analyser on it - becasue of the concurrency, the LEDs come on one
> > after another, with the third coming on typically 5ms after the first.
> >
> > The engineering side of me says that the simplest way to get three LEDS
> to
> > blick in sync is to wire them in parallel!
>
> Yep. And, a variation on this approach (compiles, but untested):
>
> --- BEGIN CODE ---
> #INCLUDE "plumbing.module"
>
> VAL []INT LEDS IS [9, 10, 11]:
> VAL INT NUM.LEDS IS (SIZE LEDS):
>
> PROC pinger (CHAN SIGNAL in?, []CHAN SIGNAL out!)
>  WHILE TRUE
>    SEQ
>      in ? SIGNAL
>      PAR i = 0 FOR NUM.LEDS
>        out[i] ! SIGNAL
> :
>
>
> PROC main ()
>  CHAN SIGNAL trigger:
>  [NUM.LEDS]CHAN SIGNAL s:
>  PAR
>    tick (100, trigger!)
>    pinger(trigger?, s!)
>    PAR i = 0 FOR NUM.LEDS
>      pin.toggle(LEDS[i], LOW, s[i]?)
> :
> --- END CODE ---
>
> This demonstrates replication in a PAR. This way, we can have an array
> of channels, and an array of LED pins, and compress some of this down
> in terms of lines-of-code. It also makes it easier to add another
> LED... simply grow the LED array, and the number of pins you're
> toggling changes as well. Like Steve said, though, we still only have
> one processor, but the timing will be much closer.
>
> I think I'd like a logic analyzer... that would be a very useful tool to
> have.
>
> Cheers,
> Matt
>
>
>
> ------------------------------
>
> _______________________________________________
> users mailing list
> users at concurrency.cc
> http://www.concurrency.cc/mailman/listinfo/users
>
>
> End of users Digest, Vol 14, Issue 1
> ************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.concurrency.cc/pipermail/users/attachments/20110301/70824008/attachment.htm>