Java Serial Comm Help!!

dgvawter

For the past week I have been playing around with communication between a java program and the basic stamp 2,·and it has not been working.·When·the java program sends data of any size·to the stamp, the program running on the stamp restarts. This is very frustrating, and·if anyone can lend their help, it would be much appreciated.

Oh, and if·anyone wants to see the syntax, here it is:

COMPUTER SIDE
Import java.comm classes
Check to see if COM4 is available
Open the port
Open the input and output buffer
Send data ("1")
Recieve data
Display recieved data
Close port

BASIC STAMP 2 SIDE
Main:
· Debugin
· If input == 1
··· Debug "G"
··· GOSUB End
· Else
··· GOSUB Main
End:
· EXIT

Unsoundcode

Two things , if you are using the default serial port for communications the serial baud rate should be for an inverted signal

·SERIN 16, 16468, 30000, Timeout, [noparse][[/noparse]DEC x]

secondly the DEBUG instruction is most likely tieing up the serial port, use SEROUT instead

·SEROUT 16, 16468, [noparse][[/noparse]"G"]·

Jeff T.

Franklin

On most PCs when you open the com ports the computer toggles the DTR line and that is what is resetting the stamp. I hope I got that right but if not I'm close.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- Stephen

dgvawter

I forgot to mention, the basic stamp will reset no matter what command it is executing, be it PAUSE, SERIN, PULSOUT, or anything else.

Chris Savage

When you use GOSUB without return you can cause erratic resets of the program.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Tech Support

dgvawter

I have found·out a·new bit of info today, when the basic stamp SEROUT's "G", the java program running on the computer recieves the message, but then the·basic stamp immediatly resets. Another wierd thing is that the stamp is able to communicate with the Debug Terminal. At this moment, it is looking like a problem with how the port is set up.

Franklin

Did you correct your program?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- Stephen

dgvawter

I have been looking through the java comm api and have been changing different settings, but nothing has worked so far.

Unsoundcode

Are you sure it's resetting and not just stuck in the serin/timeout loop of the BS2 program. You can insert a couple of debug instructions to be sure. One would be the very first line of Stamp code something like DEBUG "Reset" the second would be just below the label Timeout: something like DEBUG "Timeout".

You say· "the·basic stamp immediatly resets. Another wierd thing is that the stamp is able to communicate with the Debug Terminal". I'm not sure whats happening but you can't use DEBUG and communicate on the default programming port at the same time, it's one or the other.

When using·the programming port·to communicate you have to bear in mind that the Stamp echoes back all that you send it and if you don't clear the PC serial buffer before you transmit your next data string then data from the previous statement will get mixed with the new data.

Jeff T.

EDIT: the following link is to a thread that discusses resets due to hooking up a serial cable or opening an app on the PC.

http://forums.parallax.com/showthread.php?p=700216

Post Edited (Unsoundcode) : 1/21/2008 2:43:58 AM GMT

AnthonyM

Well... as this is my first post, it may or may not be helpful as I'm still learning as well.

With regard to your Java program, I actually am using the RXTX Serial Port drivers so I can't relate to how you're sending/receiving the data; it seems to simple to me, as you'll see why in a second. With RXTX you have to implement your own Class to read/write data and I've tried both reading in "lines" of data and reading in single bytes at a time.

What I've found that reading in bytes at a time is more straight forward and you're less suseptable to your Java program being too slow to read in the information being sent from the STAMP. What I found with reading in lines at a time is that my Java program couldn't keep up and you'd get junk data being read in. For instance I'd use the BS2 command DEBUG "readme" and sometimes I'd see the Java program read in the entire "string" of characters, but I'd mostly see junk being read in for the first half of the "string". So that's when I started looking into how to slow things down.

The Java program became more consistent reading in data when I read in a byte at a time; however I'd still see junk data from time to time.

So that's what led me to using the SEROUT command rather than DEBUG. From an article I read, I understood that there was a basic overhead with reading data and I built that into the SEROUT pace time; from what I've seen around 20ms gives me the most consistent "read". My ultimate objective was to be able to read in a terminating command from the STAMP to stop the Java program; which I've accomplished.

I actually came onto the forums to see why I couldn't get SEROUT to work; I had the wrong tpin argument and I didn't know what the right one should be until I read the post above. It works now, but I'm still not quite sure why... as for the the baudmode argument for SEROUT I used 84 as that was the RS232's baudmode for a rate of 9600.. which is what I'm using.

Anyway, hopefully this has helped.. if even a little. What I would recommend is the same as above; throw some debugging statement at key points and start understanding what's happening...

dgvawter

I GOT IT!!!!!!!!! It works. I unplugged the ATN connection from the DB9 header to the basic stamp, and it worked. The only downside to doing this is that when you unplug ATN is that you can not program the STAMP. Refrencing past posts, the DTR connection is what is causing the reset. So to Franklin, you were spot on. When seting up the serial port in java, i wasnt able to turn off the DTR. So now, after i have the connection working, i will try to turn off this DTR. There is a command port.setDTR(boolean), but that did not seem to work.