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
