Greetings, I've been using TinyOS on my Gentoo installations for some time using sun-jdk as the Java compiler. I noticed recently that there are a set of ebuilds for installing TinyOS and the related tools via portage and I got excited; however, many of them have hard dependences on ibm-jdk. Below is a somewhat "official" source indicating that the sun-jdk works for for a TinyOS installation: http://www.moteiv.com/community/Tmote_Linux_install It would be great if the ebuilds could be revised to depend on something like virtual/jdk-1.4* instead of specifically on ibm-jdk. Thanks!
hi, afaik the dependency is due to the support of serial port communication with (javax) in ibm jdk and the recommendation in the install guide (http://www.tinyos.net/tinyos-1.x/doc/install.html) it seems that moteiv propose to use TOSComm do you use it ? it works well? If so someone should write an ebuild for it, but the code semms to be only available on cvs ... Aurelien
Ah, I wasn't aware that ibm-jdk-bin included the javax.comm stuff. I use rxtx; however, I build it manually and use their script to change the gnu package to javax.comm. I noticed that rxtx is in portage, but I imagine they use the gnu package hierarchy. I don't know if it would be worth trying to get the TinyOS stuff to talk to the gnu.* comm packages.
I don't know how rxtx works. Java people? I can try to trigger the dependency, but any other jdk is unsupported upstream, and may need some work on the sources. Any hints or suggestion?
How bout sun's javacomm? http://java.sun.com/products/javacomm/ Would that work?
One note on the ibm javacomm implementation. It wants to map all the serial devices to a COM<n> name, instead of just using the name of the device (e.g. /dev/ttyUSB0). This just blows my software out of the water since I'm using udev to give devices a reasonable name. I'm about to try out Sun's implementation of javacomm. Maybe if that works we could get a javacomm USE flag for sun-jdk similar to whats available for ibm-jdk-bin.
Okay, I tried Sun's implementation of Javacomm, and it's pretty much broken (has many race conditions). See http://forum.java.sun.com/thread.jspa?threadID=673793 for more information. I've also tried the latest version of rxtx (not currently in portage) and it seems to behave pretty well. For me, rxtx seems to be the way to go (this being selfish, as the IBM javacomm does that silly business of calling /dev/ttyS0 COM1). Now, as far as the issue of rxtx being in the gun.io.* by default, instead of the javax.comm.* package. I see two potential options. I could open a bug against rxtx requesting they add a local USE flag that would conditionally run their changePackage script. On the other hand, I could look into developing some wrapper classes in the javax.comm package that wraps the classes in gnu.io. All that being said, if the current ebuilds are working well for other people, maybe I should just drop this request and continue to manually manage this stuff. I'll leave that up to you guys. Thanks, Andy
(In reply to comment #6) > All that being said, if the current ebuilds are working well for other people, > maybe I should just drop this request and continue to manually manage this > stuff. I'll leave that up to you guys. http://bugs.gentoo.org/show_bug.cgi?id=120962 Just proposed yesterday. :-)
I'll try to have tinyos working with rxtx, but this will be the bug with the lowest priority on my todo list. So don't expect to have rxtx support so soon...
Sanchan has been retired.
