There is another option I use since a couple of years to pilot
scientific devices, to program my chemostats, etc. and that is
platform-independent: Tcl.
Tcl i/o design is excellent and very robust, and Tcl/Tk is integrated in
R with the tcltk package.
It is really just a mather of a few lines of code in R to communicate
through a serial port from R using Tcl. Something like:
require(tcltk)
.Tcl('set R_com1 [open "com1" r+]') # Works on Windows too!
# There are many config parameters available here... just an example
.Tcl('fconfigure $R_com1 -mode "9600,n,8,1" -buffering none -blocking 0')
# Send a command to your device through the serial port
.Tcl('puts -nonewline $R_com1 {my_cmd}')
# Read a line of text from the serial port
line <- tclvalue(.Tcl('gets $R_com1'))
With a little bit more code, one can program Tcl to call R code
automatically everytime new data is pushed by the connected device
through the serial port. This is done using something like:
.Tcl('fileevent $R_com1 readable [list Handler_com1 $R_com1]')
Here, "Handler_com1" is a Tcl function. So, some care must be taken
using tcltk's .Tcl.callback() to trigger the event on the R side. One
way to deal with this easily is by using tclFun() from the tcltk2 package.
In tcltk2, there is also ?tclTaskSchedule that can be of interest in the
context of serial port communication to trigger a R function in the
background regularly and collect data actively from the serial port.
All these tools give me a lot a flexibility to communicate through the
serial port from R,... and most importantly, to write my code in a
portable way (tested on Windows XP and Linux Ubuntu).
If there is some interest in this approach, I could initiate a 'tclcom'
R package on R-Forge and place there the code I have.
Best,
Philippe
..............................................<°}))><........
) ) ) ) )
( ( ( ( ( Prof. Philippe Grosjean
) ) ) ) )
( ( ( ( ( Numerical Ecology of Aquatic Systems
) ) ) ) ) Mons University, Belgium
( ( ( ( (
..............................................................
On 21/04/10 03:17, shotwelm wrote:
Simon is right of course, there are plenty of sensors that would work
just fine at 9600 baud (like a thermistor rigged to an ADC). There's a
theorem along these lines (Nyquist sampling theorem?). I think piping
the output to R is a clever solution. I added a few lines to the ttys.c
program so that the baud rate is a command line option (i.e. -B9600)
<http://biostatmatt.com/temp/ttys.c> and confirmed it will compile in
Linux (2.6.30). Maybe it will save a step. Microcontrollers really are
addictive!
For an ioctl package, I was originally thinking of using file
descriptors directly. However, I agree this feels like subverting what
could be an extension of the connections API. Given that "everything is
a file" in POSIX systems, there may be an argument for an ioctl package
that is independent of the connections implementation, say to do things
that connections were not designed to do. For example, interfacing with
V4L2 devices usually involves many ioctl calls, an mmap call, but rarely
read or write calls. But maybe it would just be better to pipe this type
of output to R also...
-Matt
On Tue, 2010-04-20 at 16:42 -0400, Simon Urbanek wrote:
On Apr 20, 2010, at 11:51 AM, shotwelm wrote:
I've done some microcontroller work over serial also. Unfortunately,
interfacing with a serial port is system dependent, and the mechanisms can be
quite different, as you probably know. It appears that Simon has a solution
below that will work if you are willing to accept the default baud rate (9600
is way too slow for good sensor data
[OT: define "good" ;) - good doesn't mean fast - besides it won't be any good
if it is too fast to be meaningfully processed -- that's a different story, though :P -
and it is trivial to change so the solution works in general]
), parity, etc.. or use external tools. On POSIX systems, you would need access
to the termios.h header and the system ioctl function in order to change these
settings. Although I'm not 100% sure, I don't think R has this capability ...
yet.
I'm new to the list, but I'd be surprised if the R developers that have been
around awhile haven't already considered adding support for ioctls and the
POSIX terminal interface. This makes me wonder why it's not there. If there is
no good reason, I'm starting to see a series of R packages (or core extensions)
developing.
Good luck ;). The issue is that connections are inherently backend-independent
which implies that packages have no access to connection internals as they can
change at any time. This means that you can't enhance them without putting the
enhancements into R itself. This implies that you have to make a strong case
since you need a volunteer in R-core to maintain that code etc.
With a package for ioctls, we could use all sorts of cool stuff, like
Video4Linux2 (webcams, HAM radio, tuners)...
Ioctls are highly system-specific which is orthogonal to the design of
connections. You could probably hack together a FD-based access system but it
would not be compatible with connections (unless you exploit undocumented
things if possible at all ...). Also ioctls can change the stream semantics
entirely thus breaking anything that deals with the FD assuming some defined
state ...
When I collect sensor data over serial, I do it in python or write a small C
program to dump a single-column csv. Of course, R is excellent for digital
signal processing after that. Check out the DSP (
http://biostatmatt.com/archives/78 ) I did in R with some ECG data I collected
with an Atmel uC.
Well, we're back to calling tools to do the interfacing like the ttys (I do
prefer pipe to intermediate files)... It's not that complicated and has several
benefits (implicit parallelization, process separation in case things go wrong
etc.) so it is not obvious that it's a bad thing ...
I suspect that we're simply suck until the connection API is either exposed or re-written so
packages can provide new connections types or extend existing one. Again, this is not trivial
especially when you start messing with ioctl since it's easy to depart from defined behavior in
that case ... That said, I agree that expanding connections is useful so some progress there would
be desirable - but the "how" and "who" is not clear to me ...
That's just my $0.02, though ...
Cheers,
Simon
On Tue, 2010-04-20 at 11:05 -0400, Simon Urbanek wrote:
On Apr 20, 2010, at 10:33 AM, Blair Christian wrote:
Does anybody know if there is any support to read from serial ports? I just got
an arduino, and wanted to write some scripts for working with real time
streaming sensor data...
Yes (I have Arduinos reporting measurements from all sensors in the house to R
on my iMac which produces plots that are synchronized with my webserver). In
principle you can simply use /dev/tty.usb... and read from it. In most cases
the default setting is already fine (9600,n,8,1 on Mac) or you can use tools
the set it up in advance (setserial on Linux etc.) so you don't have to worry
about setting up the serial from R.
Depending on your OS you may be able to read from the serial device directly
with a regular file connection or you can use a pipe connection to a tool which
pipes out from the tty to stdout (written for a Mac but may work on other
unices):
https://svn.rforge.net/C/trunk/tools/ttys.c
and then use something like
f=pipe("ttys /dev/tty.usbserial-X1234")
A rather handy option -d prepends current time to each line so you can track
output over time. I have some more tools for this (even allowing you to share
form Arduino output with several computers or even send remote commands to your
Arduino including encryption etc ...).
Cheers,
Simon
PS: From experience I can say that Arduinos are highly addictive so beware ;).
In base::connections documentation, it's not clear if there's an easy
way to do this? Any ideas on hacking it? I'm open to win/linux/mac
solutions. I'm not sure how sockets work, but possibly there is a way
to pipe things to a buffer and read from a buffer in bash (in my linux
mind I have the thought of trying to redirect /dev/something to a
file, or symlinking a file to point to the hardware, but know that
there has to be some secret sauce to go from streaming in to a
readable file, but don't know what the missing components are).
Thoughts?
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
