itm / wsn-device-drivers Goto Github PK

The MacAddress class should be able to be constructed from Strings (Hex, Dec, Binary), Longs and Byte-Arrays. In the same manner it should have methods to return the MacAddress as one of these types.

The code is just horrible...

Cause this class is grown with the project and was only designed for testing. This should be refactored in something like a DeviceExampleBuilder. That allows more control over the device example creation.

The factory receives two parameters type and port of either an enum type or a String which can be mapped to the enum type and creates the appropriate instance.

Currently, each device driver instance uses 3 threads to do its work. There should be only the (necessary) RXTX thread and one (ideally shared) instance of some scheduler thread of a ScheduledExecutorService instance that is passed to the various classes which can be used to execute logic and handle user or device events.

Cf. itm/wsn-device-utils#11

This has several advantages:

1. You can set the Executor for the TimeLimiter that would allow to set maximum thread amout for the whole application which is optimal for embedded devices. See issue #11
2. There is no more PausableThreadExecutor necessary, cause the operation can be canceled inside the Operation instead outside of it. This will make several classes unnecessary.
3. The TimeLimiter can be injected, which allows to set the ExecutorService.

<3 Google Guava ;)

Devide the components in such a way that you can define a device as a GuiceModule. This should allow to remove the Device Interface, cause the factories are provided by guice, allow a much better loosely coppling and hopefully a better testability ;)

Currently cause of the ProgressManager the output of these two devices is a little bit wired. This has to be fixed.

When you call the read() method without available check the read will block until something happens. When no a device call any method from the source InputStream it will also lock. This can only be solved by decoppling the whole inputstreams.

I tried to flash an isense node using the flash utitlity from http://github.com/itm/wsn-device-utils/. It failed with the following errors:

java -jar wsn-device-utils-0.3-SNAPSHOT-flash.jar isense /dev/ttyUSB2 vlinks.bin 
myJarPath=file:/home/testbeduzl/wsn-device-utils-0.3-SNAPSHOT-flash.jar
oneJarPath=file:/home/testbeduzl/wsn-device-utils-0.3-SNAPSHOT-flash.jar
Experimental:  JNI_OnLoad called.
RXTX Warning:  Removing stale lock file. /var/lock/LCK..ttyUSB2
2011-05-12 09:37:49,271 | pool-1-thread-1           | DeviceFlasherCLI$1        | INFO  | Starting flash operation...
2011-05-12 09:37:49,294 | pool-1-thread-1           | DeviceFlasherCLI$1        | INFO  | Progress: 0%
2011-05-12 09:37:49,496 | pool-1-thread-1           | DeviceFlasherCLI$1        | INFO  | Progress: 1%
2011-05-12 09:37:49,698 | pool-1-thread-1           | DeviceFlasherCLI$1        | INFO  | Progress: 2%
2011-05-12 09:37:49,900 | pool-1-thread-1           | DeviceFlasherCLI$1        | INFO  | Progress: 3%
2011-05-12 09:37:49,910 | pool-1-thread-1           | DeviceFlasherCLI$1        | INFO  | Progress: 4%
2011-05-12 09:37:49,913 | pool-1-thread-1           | DeviceFlasherCLI$1        | INFO  | Progress: 6%
2011-05-12 09:37:49,917 | pool-1-thread-1           | AbstractOperation         | ERROR | Exception during operation execution
de.uniluebeck.itm.wsn.drivers.core.exception.InvalidChecksumException
    at de.uniluebeck.itm.wsn.drivers.jennic.JennicDevice.receiveBootLoaderReply(JennicDevice.java:281)
    at de.uniluebeck.itm.wsn.drivers.jennic.JennicGetChipTypeOperation.getChipType(JennicGetChipTypeOperation.java:54)
    at de.uniluebeck.itm.wsn.drivers.jennic.JennicGetChipTypeOperation.execute(JennicGetChipTypeOperation.java:106)
    at de.uniluebeck.itm.wsn.drivers.jennic.JennicGetChipTypeOperation.execute(JennicGetChipTypeOperation.java:14)
    at de.uniluebeck.itm.wsn.drivers.core.operation.AbstractOperation.executeSubOperation(AbstractOperation.java:178)
    at de.uniluebeck.itm.wsn.drivers.jennic.JennicProgramOperation.execute(JennicProgramOperation.java:78)
    at de.uniluebeck.itm.wsn.drivers.jennic.JennicProgramOperation.execute(JennicProgramOperation.java:12)
    at de.uniluebeck.itm.wsn.drivers.core.operation.AbstractOperation.call(AbstractOperation.java:116)
    at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
    at java.util.concurrent.FutureTask.run(FutureTask.java:138)
    at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
    at java.lang.Thread.run(Thread.java:619)
    2011-05-12 09:37:49,921 | pool-1-thread-1           | DeviceFlasherCLI$1        | ERROR | Flashing node failed with  Exception:     de.uniluebeck.itm.wsn.drivers.core.exception.InvalidChecksumException
de.uniluebeck.itm.wsn.drivers.core.exception.InvalidChecksumException
    at de.uniluebeck.itm.wsn.drivers.jennic.JennicDevice.receiveBootLoaderReply(JennicDevice.java:281)
    at de.uniluebeck.itm.wsn.drivers.jennic.JennicGetChipTypeOperation.getChipType(JennicGetChipTypeOperation.java:54)
    at de.uniluebeck.itm.wsn.drivers.jennic.JennicGetChipTypeOperation.execute(JennicGetChipTypeOperation.java:106)
    at de.uniluebeck.itm.wsn.drivers.jennic.JennicGetChipTypeOperation.execute(JennicGetChipTypeOperation.java:14)
    at de.uniluebeck.itm.wsn.drivers.core.operation.AbstractOperation.executeSubOperation(AbstractOperation.java:178)
    at de.uniluebeck.itm.wsn.drivers.jennic.JennicProgramOperation.execute(JennicProgramOperation.java:78)
    at de.uniluebeck.itm.wsn.drivers.jennic.JennicProgramOperation.execute(JennicProgramOperation.java:12)
    at de.uniluebeck.itm.wsn.drivers.core.operation.AbstractOperation.call(AbstractOperation.java:116)
    at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
    at java.util.concurrent.FutureTask.run(FutureTask.java:138)
    at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
    at java.lang.Thread.run(Thread.java:619)

Currently the device drivers parse iSense messages. Cause this has to be handled by an more upper layer this has to be removed from the drivers.

The factory receives two parameters type and port of either an enum type or a String which can be mapped to the enum type and creates the appropriate instance.

Cause a OperationHandle should have the whole functianlity of a Future it should extend it. ListenableFuture allows to add addional listeners besides the callback and execute them in separated threads.

The TimeLimiter can be shared between all operations. A singlethreadExecutor is enough. The shutdown of this executor can be done manual externally.

ExecutorService you want to shutdown manually should be given as constructor arguments. Default ExecutorService initialisation can be kept. See for example the SimpleTimeLimiter, which initializes an internal CachedThreadExecutor but has no method for a shutdown.

This is necessary for both dependency injection and the usage of the Mockito library for unit testing.

Currently cause this is a fork of the rsc project the packages has ro be renamed correctly.

Device interface should include a shutdown() method that should be used instead of connection.shutdown() or Closeables.closeQuietly(Connection) when deleting the device.

• A non-multiplexed device should clean itself and then call connection.shutdown() to close the real serial port.
• A multiplexed device should remove ifself from the demultiplexer routing table, clean itself, and then check if there is any other device in the routing table listening to the real serial port and, if empty, call connection.shutdown() to close it.

https://github.com/itm/itm-build-tools

Currently the locking of the input stream is bounded to the serial port devices.
For the internal developed Wasemote Devices this is needed.

Flush automatically the buffer when

1. Buffer size was reached
2. Timeout occured

Each instance of this wrapper needs his own ScheduledExecutorService.

Allows to remove the monitor method.

Currently the native libraries are extracted in the current working dir. This should be changed to somethink like ~/.wsn-device-drivers. For this the java classpath has to be changed at runtime.

Cause async can only be realized with threads this package makes not sense. Reduces the amount of packages.

The Apache Commons Lang library provides the class SystemUtils that helps to check if the system is currently running on whatever OS.

This method is equals for the jennic and pacemate devices and TelosB returns null. So when this data is needed it should be provided at a higher level?

An Operation currently contains the operation itselfs and the whole lifecycle. The lifecycle of an operation should separated. This reduces the code and can make the AbstractOperation not anymore necessary. So you can create a operation by only implementing an interface instead of extending a class.

This will introduce a OperationContainer, OperationContainerFactory, OperationContext (for accessing the container from the operation, e.g. for canceling an operation).