javacomm ioctl help
I am trying to add hardware handshaking to the RXTX package and am having lots of troubles with the java environment. I have a routine in C that handles hardware handshaking without any problems. However, incorporating this routine into java with JNI causes all sorts of strange problem. i.e a call to tcgetattr works immediately after turning h/w handshaking off, however when this routine is called again I get an IO error on the tcgetattr call, just trying to read the damn status! Somehow jumping fro the C code back into java and back again stuffs up the port somehow. Anyone have any ideas What the hell does the java do to the machine since I can't even open a port non_blocking under java!! Also, does any one know where I can get a good desciption of the ioctls? this would be VERY useful. Cheers Dave Atkinson
RXTXPre4 update
To those who have played with my previous update to RXTX and anyone else I have now updated what I have done to javacomm2 specs. It is now bundled as an update to pre4 of rxtx. basically there are about 8 files you need to update to rxtxpre4 before running ./configure. This version is much cleaner than my last attempt, thanks to the availability of the minicom source code (don't you just love linux!) and implements most events, hardware flow control (tested with a fussy modem). Anyone interested can email me. I am also trying to contact the keepers of the rxtx page. Cheers Dave Atkinson
Re: Well done
To the blackdown gang and all supporters of Linux, thanks for making the world a better place. Without you many of us would be condemned to NT. Dave Atkinson
To read from a port
The easiest way I know, if you just want simple parameters such as IRQ, mac address, IO ports is to boot up using a slackware boot disk with net.i. Unlike redhat, slackware has extensive support for ethernet cards and probes just about all of them when booting up with net.i, displaying any results on the console. > Hi. There is somebody who can tell me how to get information from a > Ethernet card on my PC system? Of course, I know the protocol of the outward > system. > > Thanks. >
To read from a port
My mistake !! I obviously subscribe to too many mailing lists. I assume you are after more detailed information via Java. The only way I can think of is to look after the tcpdump code and write your own interface in C using JNI. Dave Atkinson > The easiest way I know, if you just want simple parameters such as IRQ, > mac address, IO ports is to boot up using a slackware boot disk with > net.i. Unlike redhat, slackware has extensive support for ethernet > cards and probes just about all of them when booting up with net.i, > displaying any results on the console. > > > Hi. There is somebody who can tell me how to get information from > a > > Ethernet card on my PC system? Of course, I know the protocol of the > outward > > system. > > > > Thanks. > > >
Re: RXTX, SerialImp.c
Guys, I haven't had a chance to look at what everyone has done but here are my thoughts. The major thing I have done with ioctls() is to do a nonblocking read FIONREAD which also returns the number of bytes available for reading. I could not find a similar function using termios. I can't think of a way to avoid this. (I would actually like to go even lower and use interrupts for notification as the polling is wasteful of resources.) Also, I agree with the comment about removing the separate input and output streams. It is just asking for problems. I was planning to look at merging them but have not had the time. Dave Atkinson > > > On Sun, 20 Sep 1998, Sheldon Young wrote: > > > At 11:13 AM 9/20/98 -0600, Trent Jarvi wrote: > > > > >sheldon: I just sat down this morning (6 hours) and commented most the > > >SerialImp.c code to rxtx. its a 32k patch. does not mess with code much > > >at all. Should help people thinking about contributing/fixing things. Is > > >it ok to send it into the cvs? > > > > Thanks for asking. Go for it > > done. > > > >I notice there is still a fair amount of ioctl stuff in SerialImp.c... > > >like david says, its hard to find good sources of documentation on ioctl > > >and termios. I've marked them as FIXME till we can figure out how to do > > >it right with termios. > > > > Sounds good. > > I removed all the ioctls that are possible. I talked to some kernel > hackers and it appears much of what david did has to be done with low > level ioctls. I removed what we could. > > > >Strange... SerialImp.c which started as a 4k file is now 100k. > > > > Perhaps we should think about splitting it > > > > I think what may be best is to take a serious look at the duplication of > input and output streams. The kernel keeps that as one structure not two. > (I'm not sure what other unix's do though.) ie.. input and output > streams are actually working on one termios at the kernel level. > > declaring > > struct termios in > struct termios out > > and treating them seperate may actually be more confusing than need be. > change in and tcsetattr then change out and tcsetattr you end up with > in==out at the kernel level. I think it was a design flaw on my part. > > david: Great work. Took a long time to read through and verify > SerialImp.c changes. you can double check the changes I made but they are > minimal. > > I've found another hacker thats going to take a look at commapi (I > personally dont use it so I have to trust you guys there). I'll let you > know if he bites. I think david's work got his attention. >
Re: RXTX, SerialImp.c
Dan, I did try to write a version using select() but it stopped everything while waiting on the select. I agree that java lacks select(). It would be great if you could get a version of select under java. Alternatively if I could stop select blocking all threads .. Dave > [EMAIL PROTECTED] wrote: > > The major thing I have done with ioctls() is to do a nonblocking read > > FIONREAD which also returns the number of bytes available for reading. I > > could not find a similar function using termios. I can't think of a way > > to avoid this. (I would actually like to go even lower and use > > interrupts for notification as the polling is wasteful of resources.) > > Would select() be applicable? > > (This is the greatest functions for doing I/O > efficiently; you can sleep the current thread > until any of a number of file descriptors has > i/o ready for you. Java suffers greatly from > its absence. It's the key to implementing > truly monsterously high performance web > servers and the like, where the number of > clients far exceeds the number of available > threads.) > - Dan >
some problems with rxtx-1.2pre5
Michael, I have not had time to download the pre5 release yet so cannot check the line number (my changes were merged with others). However, a printout of the compiler error would be useful. Also, I suspect the BlackBox you are using is for an old version of commapi as openPort() was replaced with open() in commapi2.0. Dave > Mr. Atkinson > > I downloaded and built the rxtx-1.2pre5 package. I followed your readme > file and used the comm.jar file > from."javacomm20-beta-solaris-sparc_tar.z". > > When I initially tried to build the package I got an error relative to > "tt" in file SerialImp.c at line 2180. I commented out the offending > lines to get the package to build. > > When Testing with the comm.jar file from > "javacomm20-beta-solaris-sparc_tar.z" I get the following error. > > java BlackBox -p /dev/cua3 > > CommAPI pre-release version. Do not distribute. > Opening port /dev/cua3 > java.lang.NoSuchMethodError: javax.comm.CommPortIdentifier: method > openPort(Ljava/lang/String;I)Ljavax/comm/CommPort; not found > at SerialPortDisplay.openPort(SerialPortDisplay.java:133) > at SerialPortDisplay.(SerialPortDisplay.java:114) > at BlackBox.addPort(BlackBox.java:277) > at BlackBox.main(BlackBox.java:170) > > > When I replace the comm.jar file one I previously used the BlackBox demo > runs, but with no receive functionality as with the previous version of > rxtx I built (rxtx-1.2pre3). I have also run the SerialDemo with the > same results as above. When running both demos under release 1.2pre3 > the transmit functionality works but not the receive. I understand this > is due to the eventlistners not beign enabled in the early release. > > Questions: > > what could be causing the errors mentioned above. > Are the eventlistenres enabled in release 1.2pre5, so the receive > functionlity should work in the demos? > What should I do to properly build the system? > > Any help will be greatly appreciated. > > Thank You > > Michael Cianciosi > >
Low level disk access
While this is not directly a Java question does anybody know of any library functions etc which will provide low level disk access to harddisks. i.e sector access etc. I am looking at writing a Java class for providing direct access to a dedicated harddisk so that I can avoid some of the overhead of Java and normal filesystem based disk access. Dave Atkinson
Re: Low level disk access
I won't charge for the entertainment value, and I wont give up my daytime job. (Although I have considered joining a circus as a juggler!) I was actually implying that I would use JNI and write the interface in C. Hence the "While this is not directly a Java question...". Does anybody know of any suitable library functions, code, for lowlevel HD access ? Thankyou and Good Night!! (Insert fanfare here) Dave Atkinson > On Wed, 11 Nov 1998 10:40:52 +, [EMAIL PROTECTED] wrote: > > >While this is not directly a Java question does anybody know of any > >library functions etc which will provide low level disk access to > >harddisks. i.e sector access etc. > > > >I am looking at writing a Java class for providing direct access to a > >dedicated harddisk so that I can avoid some of the overhead of Java and > >normal filesystem based disk access. > > Sorry, but when I read this I laughed a bit... > > In any reasonable filesystem (ext2 on Linux, HPFS on OS/2, etc) you > get very good performance - and if you are controlling this from Java, > going directly to the hard drive just seems a bit, well, funny. > > I do not know of any libraries for Java that provide low-level disk > access. Using JNI (Native Methods) you could write those routes in > another language (C is the easiest) and then use them from Java. > > Michael Sinz -- Director of Research & Development, NextBus Inc. > mailto:[EMAIL PROTECTED] - http://www.nextbus.com > My place on the web ---> http://www.users.fast.net/~michael_sinz > >
java and proxies
Does anyone know if it possible to use multiple proxies for URL connections within a single java program? I have an application that needs to access to different proxies to get to different networks (long story). I can access either proxy by setting the System properties proxySet etc. However if I try to change the proxy during the programs execution it just ignores the change and uses the initial setting. I can't even turn the proxying off for URL connections once I have established a connection using the proxy. BTW I make sure I close all connections before trying to change the proxy information. Is there a way around this ? Cheers Dave Atkinson
Idiot Trap!!!
Just an idea. It appears that an automated mailing list has become the ideal tool to trap idiots. Any idiot can somehow manage to subscribe themselves, but, even though they are given unsubscribe information during the registration, they cannot unsubscribe. Therefore it would be nice to have a list of such people so mailing lists can filter them out before subscribing them. Due to the nature of the beast the obvious thing to do is to setup a bogus mailing list, with a suitable subject, eg "Are you an idiot!" which periodically, say every minute, sends them a message detailing how to unsubscribe. Users, such as the one on this list a few hours ago ([EMAIL PROTECTED]), are bound to get struck on the mailing list. This mailing list publishes its list of its current subscribers to the other mailing lists enabling the idiots to be filitered out. Cheers Justa Thought p.s. 'This guy (see above) is depriving some village of an idiot!'
Devices and blocking
I have just downloaded the Java Comm stuff including RXTX and noticed that many of the functions aren't available. i.e addEventListener. Since the Solaris examples use event listeners I have been trying to add this functionality. I have started doing this in an unsophisticated way by using a separate thread based on the rx.java example to monitor the port. This thread checks the port and generates a SerialPortEvent if any data appears. Unfortunately there is no easy way to check the port for data without reading it. Therefore I have added a single character buffer to SerialImp.c so that I can implement the available() function. The main problem I have is that even though I open the port as NONBLOCK in SerialImp.c the port actual blocks on a read. I have tested the code using a simple c program and the nonblocking stuff works fine. However running under java it blocks, even though the flags are correct, checked just before the read. Does anybody know why the read function would block under java ?? (I'm not sure if "under java" is exactly the right expression). I can get the functionality working as long as the main line doesn't call available() and just relies on an event as the monitor thread can afford to block on the read. This is not satisfactory though and at non blocking read is preferable or a way of finding out when the serial port has data. Any ideas ? Dave Atkinson
Someone to play with Linux javacomm
I have been playing around with the javacomm rxtx stuff implementing the event notification stuff as well as non blocking reads. Unfortunately I have a problem with the serial ports always blocking on reading despite the open options. Therefore I have implemented non blocking by using a separate thread the block on reading and update appropriate flags. I have also implemented many of the modem control line indication functions but not everything. However, you can run the BlackBox demonstration and the other examples that I have tested. I am currently looking for someone to play with what I have done, point out/fix any problems etc etc. The code is a bit messy at the moment and the java is probably not perfect as I am still learning. Any volunteers ? Cheers Dave Atkinson
