[C.CC USERS] Question about writing messages to serial port

James Brown james.brown4994 at gmail.com
Sun Dec 23 22:18:35 GMT 2012



Thanks for your kind comments.  Re the digital.input proc.  I copied the
text of the code in the Kroc wiki into an occam programme and it works fine
on both interrupt and non-interrupt pins.  The plumbing digital.input proc
may be different to the code therefore.


Haven't had time to improve things just yet.  Where is the best place to
post code and other stuff for other users to pick up?




From: jadudm at gmail.com [mailto:jadudm at gmail.com] On Behalf Of Matt Jadud
Sent: 22 December 2012 13:20
To: James Brown
Subject: Re: [C.CC USERS] Question about writing messages to serial port


Hi James,


I thought the docs for digital.input mentioned that only input 2 or 3 can be
used that way. The reason is that we actually use Arduino hardware
interrupts there. There is code that, someday, we want to integrate into the
runtime to handle all interrupts on all pins, but it grows the firmware, and
we haven't done it yet. 


So, yes, your solution of polling the pin is the alternative. In future revs
of the library, we'll either 1) try and support more pins for real
interrupts, or 2) improve the error handling. That might be tricky, though;
it is equivalent to, in C, trying to handle an interrupt that doesn't exist.



It is very, very awesome to see someone hacking things with the tools we
helped develop, even if the documentation needs work, etc. Very nice.


Trivial Tweaks:

At a glance, you don't have anything grossly un-occamish in there. The use
of the ALT makes sense; it is how you handle multiple channels in a
non-deterministic way. You could, for example, create another named PROC
perhaps, which would let you pull the code around line 50ish into its own
space. Pass that PROC the channels it needs, which might make it easier to
read what happens when things timeout in the outer ALT of flap.state.


(Or, if you prefer: the code in flap.state is the "least obvious" in the
program. That doesn't make it "bad," but it might make it more confusing as
you try and maintain/update the code later.)


Pulling out your pin states into a PROC setup() might make sense, which
would also shorten your main(). Making a named proc for the block under line
124 might also make sense; then, your entire "main()" (or "motion.pir")
would be a PAR block with a few named PROCs. 


These are all, though, details, and easy edits. Like I started out, this is
really cool. 





On Sat, Dec 22, 2012 at 4:53 AM, James Brown <james.brown4994 at gmail.com>

Again many thanks.  I will work through this library now.


Here is the (nearly) completed code.  Thanks to the assistance I have had I
have made rapid progress after a slow start.


In words this is what it does.


Monitors the cat flap:  if my cat goes out, disarms.  Comes back in, rearms.

If the back door is opened, terminates the programme and indicates a

When armed, if PIR is detected, fires the sprayer valve.


Next steps will be:

-          A more elegant "bistable" for the flap.state process (i.e. not
relying on the PRI ALT, although this works fine)

-          Another lockout condition based on a timed flow monitor (to avoid
flood in case of a malfunction) which will drive a close off valve

-          Rewrite programme using approved styles


p.s.  I have found that digital.input crashes my arduino uno if using any
pin other than 2 or 3.  Hence my own monitor.pin proc. I will have a look at
what is going on here.




From: jadudm at gmail.com [mailto:jadudm at gmail.com] On Behalf Of Matt Jadud
Sent: 22 December 2012 01:04
To: James Brown
Subject: Re: [C.CC USERS] Question about writing messages to serial port


Hi James,

serial.write.string(TX0, "Hello*n")




The occamdocs for the Plumbing modules should be reasonably up-to-date.







On Fri, Dec 21, 2012 at 6:28 PM, James Brown <james.brown4994 at gmail.com>


On arduino, how do I write a message out to the serial port so that it
appears in the occplug screen?  Would be useful for debugging.

James Brown

users mailing list
users at concurrency.cc



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.concurrency.cc/pipermail/users/attachments/20121223/9475d6c5/attachment.htm>

More information about the users mailing list