Editing RS232/USB Probe

(by the author: ) This is a really old program.  I am not sure where the code is or much else about it.  I now work in Python and a much more useful program is [[Python SmartTerminal]]

=== Summary  ===

*Name: RS232/USB Probe 
*Status: still developing, but is working 
*Technology: Java -- should run on many platforms, Windows 98 through Vista 
*Author: russ_hensel ( where you can find an email address to reach me )
*License: not fully determined, but open source and object code.

Purpose:

The project is a specialized terminal emulator designed to talk to microcontrolles and similar devices either to control them or to try to deduce what there control protocol is.

Several areas are provided for input to the device.  This is typed as strings, but escape sequences also allow special characters including any ASCII character entered by its hex code.  Data is sent by pressing the send button.  Each send area has its own recieve area just to the right of it.  Also all data both sent and recieved is logged to the bottom window.  Other events in the software are also posted to the logging area.  The application has several send areas so that you can easily reissue earlier commands and easily keep frequently used commands ready to use.

A complete log of activity is provided both to the screen and to a log file.

=== Early Mock Up of Screen ===

[[Image:RS232ProbeMain.png | Screen Shot ]]

=== Download ===

Coming soon, for early adopters email me [[russ_hensel]]

== Installation Directions For all the Applications ( This is a first cut, more details will follow ) ==

* Configure Java JDK or Java Runtime Environment as it suits you.  I am using version 1_4 to stay compatible with older machines.  You can find it round about [http://java.sun.com/j2se/1.4.2/download.html Download Java 2 Platform, Standard Edition, v 1.4.2 (J2SE)]

* Download and install the JavaComm API for your platform. Sun no longer support this for windows; ( I will change to some other support soon ) I found it at [ http://wind.lcs.mit.edu/download/ Software Download and Install] Install can be a problem because a bad installation often fails without any messages.  Here are installation directions: [http://www.xpl4java.org/xPL4Java/javacomm.html Javacomm -- Serial and Parallel port access for Java and xPL]

* Download RS232Etc.zip. I will provide a location soon, for testers email me [[russ_hensel]] Unzip to an installation directory ( c:\RS232Etc for example but in any case avoid directory names with embedded blanks and if you stick to c:\RS232Etc fewere modifications will be required to the bat file. )  Do not un-jar the jar file(s) ( unless you just want to mess around )  Source code will be provided in RS232Etc.jar when it it a bit more stable.  Note that renaming the .jar file to .zip will allow you to extract the files with most zip utilities that do not directly support jar files.

*Edit RS32Probe.properties for your configuration, directions are in the file.

*Edit the  RunRS32Probe.bat file for your configuration ( see directions in bat file ).  You may want to do this in a copy of the file so that you always have the original bat file ( or maybe we will give you two copies).

*Double click the bat file to run the program, begin debugging the installation.  If you have problems I will help you, email me with some details of the problem, include screen shots or detailed discription of error messages.

=== Use Details ===

Some Use Details

Before running the program make sure the property file ( RS232Probe.properties ) has the values you want to use.  This file is documented internally.  Make sure you save a backup somewhere of the original file ( there is a backup in the installed files ).  Double click the batch file to launch the program.  Startup information will appear in the Java console ( the dos window associated with the program, and in the program log area, and in the log file. )

Fill in one of the blanks under Data ( the column by defaults contains SendMe ) and press the <Send> button.  The device response ( if any ) will appear in the corresponding Received Data field.  You can edit the data and send it again or just send it again.  The panel on the bottom shows the activity of the application >> precedes sent data, and << received data.  The rows are repeated so that you can easily switch between string sent. 

One somewhat complicated, but important area to understand is how the program knows that the microcontroller has finished responding.  We have three ways:

* Wait for some special character ( which I call the termination character ) to be recieved.  Very often the carriage return serves this purpose.  In this program you can specify a character for the program to look for. 
* Wait some maximum anount of time and assume by then that the microcontroller is finished.  This method is not fast, and is not particurllarly reliable.  Nice to have as a backup method or if waiting for a termination character when the microcontroller has crashed could wait forever.
* Stop after some maximum length of response.  Alsmost always an error condition. 

These are specified by entering data in some of the gui fields and can be different for different data that you send.

The initial values in the GUI give you some idea ( I hope ) on how to use them.  Here are some details on all the Graphical User Elements.


{| class="wikitable"
|-valign="top"	
! GUI Element
! Use

<!---------------------------->
|-valign="top"		
|''Button:''  Send 
|Press it to send your data. ( the data in the field to its right )
<!---------------------------->
|-valign="top"		
|''Field:'' Data 
|Input: The data you want to send. This field uses special character translation so you can send any ASCII character(s).  See Special Character Translation below.

<!---------------------------->
|-valign="top"		
|''Field:'' Waits 
|Input:  A time in some arbitrary units that the probe will wait for a return from the BitWacker.  Data usually comes back pretty fast.  Try starting with 50.  If the termination reason is maximum wait exceeded, the time has run out and you may have an error condition or need to increase the time.
<!---------------------------->
|-valign="top"		
|''Field:'' Term C: Termination Character 
|Input: A string for the character you want to be used by the microcontroller to indicate that its transmission is over.  This field uses special character translation.  The most common termination is the carriage return “~r”

<!---------------------------->
|-valign="top"		
|''Field:'' Maximum Length 
|Input: The maximum length in character of the response that will be accepted from the BitWacker.  If it is exceeded the response is cut off and the termination reason is listed as maximum length exceeded.

<!---------------------------->
|-valign="top"		
|''Field:'' Response 
|Output:  Whatever the microcontrolller returns for data.  Cut off at the first occurrence of the termination character if any.

<!---------------------------->
|-valign="top"		
|''Field:'' Termination Reason  
|Output:  The reason why the received data was terminated.  Normally it is an error if the reason is anything other than Termination Character received.
<!---------------------------->
|-valign="top"		
|''Field:'' Log Area
|
Output: Lots of information about events in the probe are logged here ( and to the log file )  This is normally set up information and then when data is sent it is preceded by >> and when it is received it is preceded by <<.  You cannot type in here, but can highlight text and copy it.
<!---------------------------->
|-valign="top"		
|''Field:'' Comment  
|
If you enter a comment here you can log it to the log area by pressing the <Log Comment> button.  This data is just for the log and is not sent to the microcontrolller.
<!---------------------------->
|-valign="top"		
|''Button:'' Comment 
|Send the data in the comment field to the log area, none of this is sent to the microcontroller.
<!---------------------------->
|-valign="top"		
|''Field:'' Term Char for All Sends
|This data is appended to the end of all data sent, leave it blank if you do not want to use it.
<!---------------------------->
|-valign="top"		
|''Menu:'' File -> Clear Log
|Clears the log area ( no effect on the log file ).
<!---------------------------->
|-valign="top"		
|''Menu:'' File -> Clear Pending Data
|Checks the recieve buffer for data from the bitwacker that came in after the end of the last recieve.  Log it, but otherwise throw it away.
Sets up for clean communication on the next send, but lets you see that there was some unprocessed data.
<!---------------------------->
|-valign="top"		
|''Menu:'' File -> Open Property File
|New -- think it works Opens a dialog for you to choose a new property file ( or the same one, but with edited values { or not if you just want to reinitilize ] ) and reinitilize the application with different ( or the same ) parameters.  If you want you can open the property file in an editor, edit values, save ther file ( and possibly keep it open, or not ) and then reload the same file with the new parameters. 
<!---------------------------->
|-valign="top"		
|''Menu:'' File -> Open Comm Parms
|Stubb -- does not work, may not ever work.  Lets you choose communications parameters on the fly without messing with the property file.
<!----------------------------
|-valign="top"		
|
|
<!----------------------------
|-valign="top"		
|
|
<!----------------------------
|-valign="top"		
|
|
<!----------------------------
|-valign="top"		
|
|
<!---------------------------->

|}

Each time the application initializes it either starts with an empty log file or appends to the old one, I need to find out which, what would you like it to do?  Append seems the right choice to me.

Logging on start up:

Typically something like ( this is using the opening using a "probe":


Reading property file C:\Russ\Java\RS232Etc\MrMoose.properties
Stream File = C:\Russ\Java\RS232Etc\MrMoose.properties
COM3 Opened Now Probing Response UBW FW D Version
<<v
COM6 Opened Now Probing Response UBW FW D Version
<<
COM7 Opened Now Probing Response UBW FW D Version
<<
COM10 Opened Now Probing Response UBW FW D Version
<<
COM12 Opened Now Probing Response UBW FW D Version
<<
COM13 Opened Now Probing Response UBW FW D Version
<<
Parms.initPort() failed
RS232 Probe initilization complete.


There is also a bunch of logging to the java console, some of it is the same as to the log area and file, other logging may be different, particurlarlly for execptions that the application does not do a good job of managing.  Take a look at this if the application seems to behaving oddly.  There is more information on the scanning of com ports, something like:


Reading property file C:\Russ\Java\RS232Etc\MrMoose.properties
openOutputStream for rs232probe2.txt
Looking for port: COM15
Found port: COM3
Found port: COM6
Found port: COM7
Found port: COM10
Found port: COM12
Found port: COM13
Found port: LPT1
Found port: LPT2
Port not found: COM15
Parms.initPort() failed

In this case it is scanning for port 15, but it is not active so initialization fails.

=== Special Character Translation ===


{| class="wikitable"
|-valign="top"	
! Special Char. As typed in GUI
! Char Sent
! Comment

<!---------------------------->
|-valign="top"		
|~r or ~R
|Cr = 0x0D
|Carriage return, the normal end to a transmit to the microcontroller
<!---------------------------->
|-valign="top"		
|~t or ~T
|tab = 0x09 
| Also know as horizontal tab.
<!---------------------------->
|-valign="top"		
|~n or ~N
|new line = 0x0a
| Also know as line feed
<!---------------------------->
|-valign="top"		
|~xx  
|The character corresponding to xx in hex.
|xx must be exactly 2 valid hex digits ( 0 to F )
<!----------------------------
|-valign="top"		
|
|
|
<!----------------------------
|-valign="top"		
|
|
|
<!----------------------------
|-valign="top"		
|
|
|
<!---------------------------->


<!---------------------------->

|}


=== Enhancements ===

The following are under consideration but may or may not ever happen, your comments will be some of the input for the decision.


{| class="wikitable"
|-valign="top"	
! Enhancement
! Comment

<!---------------------------->
|-valign="top"		
|Save property file under old or new name.  Preserve comments from the original file ( may require editing to be consisten with the new values )
|This lets you start with a property file, run with it, tweak the values ( assuming we have an interface to do it, which we are planning ) and then save the the resulting values in the old or a new property file.
<!---------------------------->
|-valign="top"		
|Add property file support for intial values in all the send fields.
|A pre-set up the fields for common values used by a microprocessor.
<!---------------------------->
|-valign="top"		
|Log file playback.
|Play back the same commands as used in a previous session.  The log file could be manually edited prior to playback.
<!---------------------------->
|-valign="top"		
|Continuous recieve option.
|Add a thread in the background to recieve and log data continuously ( presumabley this would be turned off for each transmit and then turned back on after the response was recieved ).
<!---------------------------->
|-valign="top"		
|Implement always clear pending.
|This would check for, clear and log any pending data prior to any transmit.
<!---------------------------->
|-valign="top"		
|
|
<!---------------------------->
|-valign="top"		
|
|
<!---------------------------->

|}