[CCC DEV] Matt's project

peter feeney fighne at hotmail.co.uk
Sat Jul 7 16:46:04 BST 2012


this sounds as thou it has legs, very much along the ideas of the lego programming language which was visual blocks ( as it's lego what other concept would they use!)if you need some help with the node.js stuff gimme a shout, as it's my app server for my FT workRegards Pete

> From: developers-request at concurrency.cc
> Subject: developers Digest, Vol 26, Issue 3
> To: developers at concurrency.cc
> Date: Wed, 4 Jul 2012 12:00:02 +0100
> 
> Send developers mailing list submissions to
> 	developers at concurrency.cc
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> 	http://lists.concurrency.cc/mailman/listinfo/developers
> or, via email, send a message with subject or body 'help' to
> 	developers-request at concurrency.cc
> 
> You can reach the person managing the list at
> 	developers-owner at concurrency.cc
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of developers digest..."
> 
> 
> Today's Topics:
> 
>    1. Prototype drag-and-drop (Matt Jadud)
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Tue, 3 Jul 2012 10:53:18 -0400
> From: Matt Jadud <matt at jadud.com>
> Subject: [CCC DEV] Prototype drag-and-drop
> To: developers at concurrency.cc
> Message-ID:
> 	<CAAGM454YB1iQkgEgykGyZsmqe9QigRDrN3ZEWHq5TzuiZHjv0Q at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
> 
> Hi all,
> 
> [ TL;DR: It's a prototype visual environment. I have no idea if I've
> just reinvented something we already had around. Is it worth pursuing
> further, and who is interested? ]
> 
> I have a prototype drag-and-drop environment for the Arduino.
> 
> http://www.youtube.com/watch?v=ejzbrOroHTw
> 
> The source (*cough*) is in Github:
> 
> https://github.com/craftofelectronics/ardu-see
> 
> To save you digging through a pile:
> 
> 1. The web interface is thrown together with WireIt, which is built on
> the YUI library from Yahoo. Yahoo Pipes is built using this library.
> 
> 2. The blocks in the interface are specified in JSON. For example, the
> "Read Sensor" block specification looks like this:
> 
>   {
>     "name": "Read Sensor",
>     "container": {
>       "xtype": "WireIt.FormContainer",
>       "title": "read_sensor",
>       "icon": "res/icons/application_edit.png",
>       "collapsible": true,
>       "fields": [
>         {"type": "select", "inputParams": {"label": "Pin", "name":
> "1int", "selectValues": ["A0", "A1", "A2", "A3", "A4", "A5"] } },
>       ],
>       "terminals": [
>         {"name": "0out", "direction": [0,1], "offsetPosition":
> {"left": 100, "bottom": -15}}
>         ],
>       "legend": "Read my sensor and output its value."
> 	   	}
> 	   }
> 
> There are some fragile things in here. For example, the names are
> "0out" and "1int", which are how I'm encoding parameter order and
> type. (But, the prototype is assuming that everything is an INT,
> because it is 1) invisible to the user and 2) allows for a great deal
> of flexibility.)
> 
> 3. When you hit Load or Save, it pushes your data to http://parse.com/.
> 
> 4. When you hit Run, it pushes a JSON representation of the graph to a
> Node.JS server. (Why? Because it was the easiest thing I could find
> that would serve both static content and an RPC call.)
> 
> 5. The JSON server runs a small Scheme utility to 1) parse the JSON
> and 2) spit out a piece of occam-pi. Given a JSON structure like this:
> 
> {"name":"","project":"","working":{"modules":[{"name":"Read
> Sensor","value":{"1int":"A0"},"config":{"position":["18","24"]}},{"name":"Turn
> On In Range","value":{"1int":"2","2int":"0","3int":"100"},"config":{"position":["104","223"]}}],"wires":[{"src":{"moduleId":"0","terminal":"0out"},"tgt":{"moduleId":"1","terminal":"0in"}}],"properties":{"name":"","project":"","description":""}}}
> 
> it outputs
> 
> 
> #INCLUDE "ardu-see-ardu-do.module"
> PROC main1341326514 ()
>   CHAN INT wire01:
>   PAR
>     ReadSensor(A0, wire01!)
>     TurnOnInRange(2, 0, 100, wire01?)
> :
> 
> 6. For this to work, we have to implement each block in occam-pi.
> That's not hard.
> 
> #INCLUDE "plumbing.module"
> 
> VAL INT READ.DELAY IS 500:
> 
> PROC ReadSensor (VAL INT pin, CHAN INT out!)
>   INITIAL INT avr.pin IS board.analog.to.chip(pin):
>   WHILE TRUE
>     INT reading:
>     SEQ
>       delay(READ.DELAY)
>       adc.base(avr.pin, VCC, reading)
>       out ! (reading / 11)
> :
> 
> PROC TurnOnInRange (VAL INT pin, min, max, CHAN INT in?)
>   WHILE TRUE
>     INT value:
>     SEQ
>       in ? value
>       IF
>         (value >= min) AND (value <= max)
>           digital.write(pin, HIGH)
>         TRUE
>           digital.write(pin, LOW)
> :
> 
> 7. The Node.JS server then invokes the toolchain and uploads things.
> (My Mac environment for command-line building is poor, so really, I
> should just be able to call "occbuild" and be done. But, that's not
> how this script works at the moment.)
> 
> 8. Upload is handled by avrdude. My Arduino is hardcoded in.
> 
> That's about it, really. It's a prototype. I put it together because
> I'd like to teach an intro electronics course that has digital
> electronics, but I'd rather not have to teach programming (per se).
> Going to tools like Ardublocks or Modkit means a sequential world, and
> students still have to wrestle through lots of details that are, quite
> simply, unpleasant. (Or, if you prefer: if the course was primarily
> and only about digital electronics and an introduction to programming,
> I could probably fit a bit more programming instruction in... but, at
> the moment, I suspect not.)
> 
> My question is: can we bring this around before September-ish? Specifically:
> 
> 1. Can we put together something that runs on Mac and Windows?
> (Ideally, all three.)
> 2. The JavaScript side is, for all intents and purposes, "done." That
> is, adding new blocks is easy. Writing a bit of occam to represent the
> block is likewise easy.
> 3. We can write the server in anything we like: a stand-alone Python
> server that gets the job done works for me. I may explore whether it
> is possible to easily get a (compiled) stand-alone server to run in
> Scheme. If so, that would solve cross-platform packaging.
> 4. The user needs to find/specify the Arduino... somehow. I have some ideas.
> 5. Some error checking, somewhere, might be a good idea.
> 
> It would be nice to have something that leveraged our tools that
> anyone could use to quickly explore the Arduino. The environment is
> highly constrained, and allows me (as an educator) to limit what
> students are able to do in sensible ways. Or, if you prefer, the
> environment lets students focus on the circuit and the problem they're
> trying to solve, and not get lost in details of the programming...
> while allowing them to easily prototype systems with multiple sensors,
> on multiple inputs, with multiple outputs.
> 
> That's enough writing. I'll probably put a blog post up on
> http://craftofelectronics.org/ about this, which might be less
> verbose, more conceptual, and clearer.
> 
> Many thanks,
> Matt
> 
> 
> 
> ------------------------------
> 
> _______________________________________________
> developers mailing list
> developers at concurrency.cc
> http://lists.concurrency.cc/mailman/listinfo/developers
> 
> 
> End of developers Digest, Vol 26, Issue 3
> *****************************************
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.concurrency.cc/pipermail/developers/attachments/20120707/89295e23/attachment.htm>


More information about the developers mailing list