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

Wed Mar 2 07:33:01 GMT 2011

Matt,

Dont you have one of these already? Just when we last used it there were no drivers for OS X (and running in windows vm was suboptimal)?

 C

On 2 Mar 2011, at 00:37, Paul Verbeke <paverbeke at gmail.com> wrote:

> 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
> 
> 
> 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
> ************************************
> 
> _______________________________________________
> users mailing list
> users at concurrency.cc
> http://www.concurrency.cc/mailman/listinfo/users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.concurrency.cc/pipermail/users/attachments/20110302/7fa95363/attachment-0001.htm>