Difference between revisions of "BitWacker PIC and Other Microcontroller to Java Communications"

From OpenCircuits
Jump to navigation Jump to search
Line 68: Line 68:
 
waits for a microcontroller response ( a sting of printable characters ), a standard termination character ( typically cr or lf ), or times out, or reaches a maximum length.  Records the reason for the end of the response.
 
waits for a microcontroller response ( a sting of printable characters ), a standard termination character ( typically cr or lf ), or times out, or reaches a maximum length.  Records the reason for the end of the response.
  
=== First Application: ===  
+
=== First Application: The RS232/USB Probe ===  
  
The RS232 Probe:  Sort of a terminal emulator but with some special features to test embedded devices.  Store multiple commands and issue with press of button.  Implement various handshaking/flow control.   
+
Much like a terminal emulator but with some special features to test embedded devices.  Store multiple commands and issue with press of button.  Implement various handshaking/flow control.  [[RS232/USB Probe]]
  
 
=== Second Application: BitWacker Command GUI ===  
 
=== Second Application: BitWacker Command GUI ===  

Revision as of 15:36, 13 March 2008

Introduction -- Testers Wanted

A new interesting device ( basically an advanced development board with firmware ) is the BitWacker:


USB Bit Whacker From the site: The UBW board is a small board that contains a Microchip PIC USB-capable microcontroller, headers to bring out all of the PICs signal lines (to a breadboard for example), only costs about $15-$20 to build and is powered from the USB connection. There seem to be a fair number of additional projects based on this device. Google "Bit Wacker".

The developer has supported the PC end of the communications with a program in Liberty Basic. The project based here is to provide communications using a JAVA application.

We expect to have some alpha level code in about two weeks ( from March 6 08 ) and are looking for testers. The tester should:

  • Have a BitWacker and cables to connect to a PC.
  • PC running XP or Win 98 ( other versions may work, but you would be more on your own )
  • Some experience with JAVA ( if you have a lot that is ok but please do not bash us on code quality for awhile ).


The contents of this page should change fairly frequently for the next few weeks, check back if you are just lurking.

For more information contact russ_hensel


Status

March 12 2008

  • RS232Probe Runs, not too bad, not robust against error and not all features running.
  • BitWacker Command API Got my BitWacker and tested. First bunch of API runs, now based on character processing, would like to allow decimal hex and binary input and input validation of fields, not there yet
  • Testers would like to see if someone can simply get it to run on their computer. Contact me russ_hensel.

More Information:

This project will be open source under one of the usual lisences, if there is a push for it I will move to Source Forge at some point.

Here is a feature ( and wish ) list ( add your input on the discussion page and note that once released you can make additions ) and some additional info:


  • Java ( which version? was jdk1.6.0_03 seems not to be compatible with windows 98, do we care? Have reverted to 1.4 something or other )

Current testing on XP only.

  • Communication using java comm: RS232 emulation over USB. Not ideal, hard to install, some platform differences, like the naming of comm ports. In the Java world there does not seem to be a better alternative.
  • Support both RS232 and USB RS232 emulation so framework will work with older RS232 devices.
  • Software structured in layers, one layer for RS232, higher layer models the BitWacker.
  • Use Model View Controller pattern.
  • Make GUI based, but provide Java Programmers with an API for custom applications, document for reuse.
  • Control parameters of application through a property ( text ) file. Perhaps later add parameter control to GUI.
  • Include program debugging through log4j framework ( it has be suggested that a newer framework might be used, this may happen but

not for the first pass ).

  • In the lower level API get away from text for arguments ( Port “A” “B”... ) and move to numerical arguments, this makes abstraction of the hardware easier and allows for easier looping through ports and bits. Also provide a fairly easy way to think about the hardware in the more traditional text model.
  • Include provisions for scaling of analog input data to floating point.
  • Include a text file for logging ( some ) operations.
  • All code specific to BitWacker will be in a small set of classes ( or 1 class ) so that applications can be switched to other devices ( or versions of BitWacker without much application change.
  • Some sort of macro record and play back facility, these can be saved to a file and replayed from there.
  • Command protocol:

is parameter controlled, so can be varied typically command is printable characters followed by a standard termination character ( typically cr or lf ) waits for a microcontroller response ( a sting of printable characters ), a standard termination character ( typically cr or lf ), or times out, or reaches a maximum length. Records the reason for the end of the response.

First Application: The RS232/USB Probe

Much like a terminal emulator but with some special features to test embedded devices. Store multiple commands and issue with press of button. Implement various handshaking/flow control. RS232/USB Probe

Second Application: BitWacker Command GUI

Fairly direct implementation of the BitWacker Command API with one parameter controlled button for each ( most? ) command. Ex: button for PO" ( "Pin Output" ) will have GUI edit controls for entry of Port, Pin, and State. GUI will also support display of BitWacker response as appropriate.

Third Application: Graphical Data Logger

For low speed logging, up to say 1 measurement per second. Nice graphical output ( using PtPlot )

Fourth Application: Smart Battery Charger with Graphical Data Logger

Basically a peak detecting charger for NiCad and Nickle metal hydride batteries. After fast charge drops back to trickle charging. Charging logic is all on the PC, so can be very smart with a nice GUI. Will require an add-on board. I have an old version of this based on different hardware which may be used as a starting place for the project.

Installation Directions ( This is a first guess, more details will follow )

Configure Java JDK ( later will have directions for the runtime environment ) as it suits you. Download and install the java comm API for your platform. This can be a problem because a bad installation often fails without any messages. Download BitWackerJava.zip. Unzip to an installation directory ( c:\BitWacker for example but in any case avoid directory names with embedded blanks ) Do not un-jar the jar file ( unless you just want to mess around ) Source code will be provided in BitWackerJavaSource.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. Edit BitWacker.properties for your configuration. ( see section below on BitWacker.properties and directions in the file ) Edit the BitWacker.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.


Coding Standards

This is more of a goal than a standard. It may help in adapting the code to your use, or if you contribute consider them, you may have better ones, but lets discuss russ_hensel prior to any big changes especially on existing code.

Most development has been done in Netbeans, consider it.

If you make a change make sure everything still compiles, not just the stuff you are interested in.

Code for ease of reading and maintainability, do not abstract much more than necessary, especially as code becomes unreadable, or has many more methods than are actually used.

Lots of white space, preferably with meaning.

Use my as prefix for most instance variables.

Lots of comments, tell intent, do no repeat what can be read from the code.

Limit scope but you need not be a fanitic.

Meaningfull variable, method, and class names, no hungarian notation, but prefix for scope may be useful.

Example Property File

BitWacker.properties
comments indicated by leading ; but on the wiki it makes the lines bold
---------------
debugLevel 10 = lots of debug messages, 0 = none or almost -- this is being phased out in favor of log4j which has its own property file

debugLevel=9

---------------
commPort set the comm port that the unit will be on
for USB installations use the device manager ( perhaps under Control Panel -> System -> Hardware )
to see where your USB connection is installed.
like COM1, COM2 ...

commPort=COM2

---------------
Parity even odd everything else is none
None is the only tested value, and is the standard value for BitWacker

Parity=none

---------------
Baud string one of valid baud rates 9600 19200 ...
xxxx is the standard value for BitWacker

Baud=19200

---------------
DataBits 5 6 7 8
8 is the only tested value, and is the standard value for BitWacker

DataBits=8

---------------
FlowControl none rtcs_in ... see parms
None is the only tested value, and is the standard value for BitWacker

FlowControl=none

---------------
StopBits 1 "1.5" 2
1 is the only tested value, and is the standard value for BitWacker

StopBits=1

---------------
outputFile location, name of output file
can be full path or relative to where the app is running

logFile=BitWackerLog.txt

---------------
time in ms seconds between reading used by logger
deltaT=4000
deltaT=50000

deltaT=1000

---------------
scale the values for analog reading
Scale is set by having a high and low value that corresponds to the raw data values of the Bitwacker ( normally 10 bit? )
by having low actually be high we can invert the scales!
each data channel also get a name
---------------
data Channel 0

dataChan0Lo=15 dataChan0Hi=-1 dataChan0Name=Voltage

---------------
data Channel 1

dataChan1Lo=15 dataChan1Hi=-1 dataChan1Name=Current

---------------
averageOver
to improve the analog readings we average ( moving average ) the values.
measuremenst are running averages over this number of measurements, affects all channels

averageOver=3

---------------
PlotStyle
defines how data is plotted ( note, to gain flexibility this property will probably be revised in the future )
TIME_0
time on the X axis, channel 0 on the Y axis
HORZ_0 HORZ_1 VERT_0 VERT_1 XY_01 XY_10 XY_TARG_01 TIME_0 TIME_01


PlotStyle=TIME_01

---------------

// PICUnit1 PICUnitSim //picUnitClassName=PICUnit1 // BitWacker for the BitWacker // BitWackerSim to simulate the BitWacker

picUnitClassName=BitWacker

---------------


===================== end ======================

End Example Property File