Besides the instable working of the OLS I found an other issue while testing it.
Using an Arduino to generate waveforms the Arduino automatic reset was triggered every time I capture a waveform.
The Arduino uses this reset to activate the bootloader if you want to flash it.
The OLS sits on COM19. The Arduino on COM5. COM19 for the OLS due to using Blue Tooth which inserts a lot of additional comports.
Portmon from Sysinternals showed that requests to VCP0 (the Arduino device) were made by java.exe which triggered the Arduio reset.
The log shows:
0 0.01975857 javaw.exe IRP_MJ_CREATE VCP0 SUCCESS Options: Open
1 0.00000608 javaw.exe IRP_MJ_CLEANUP VCP0 SUCCESS
2 0.11812187 javaw.exe IRP_MJ_CLOSE VCP0 SUCCESS
Is this a from the SUMP client or a JAVA issue?
If this is from the SUMP client then please remove resetting additional comports. Its annoying.
Toshiba Qosmio/Windows 7 32bits.
ian wrote:... Hi ben51 - I'm not sure who is causing that, but I doubt it's the OLS hardware resetting the additional ports. Bug reports for SUMP should be directed to the SUMP project, we're don't maintain that project.
Your right, i'll do that. ...
@ben51: thanx for the info - from the info you gave it looks to me like this: ...
2. I attached an USB Arduino (actually a Freeduino) to my PC (Windows XP Pro) and performed a quick test running some "fast blinky LED" test on the Arduino (using COM 16) and then connected an OLS (using COM 19) and launched the SUMP Java Client .... BANG the blinking LED stopped and the Arduino performed a reset .... next I started a capture .... BOOM the blinking LED stopped and the Arduino performed a reset again. Whenever I started a capture from the SUMP Java client the Arduino would reset. However, after loading a new sketch to the Arduino - while keeping both the Arduino IDE and the SUMP Java Client open - starting a capture from the SUMP Java client would not reset the Ardino anymore. Next I tried to connect the SUMP client to the COM port the Arduino was using and ... BANG the Arduino was reset. When trying to connect the SUMP Java Client to the OLS I saw for the first time the "device not found" message :D
I don't think the OLS board has anything to do with the reset of your virtual Arduino COM port, at least not directly - However, I assume that you had absolutely no problem to run the SUMP Java client on your Mac and to connect to the OLS when you launched it the first time since librxtxSerial.jnilib and RXTXcomm.jar were already installed with your Arduino/Processing IDE prior to connecting the OLS for the first time. I would have to test it myself but I assume that your Arduino (actually the connection/virtual COM port) will be reset every time the SUMP Java client is started, at least whenever it opens the COM port to the OLS to initiate a capture ...
I have hardly any Java experience but checking the code for public boolean attach(String portName, int portRate) in FpgaDevice.java it seems that a general detach performed before attaching the COM port to the device may actually cause the input stream and the output stream of the "first" open port in the COM port list to be closed ... in your case it's the Arduino's COM port - anyway, I could be wrong here.
I agree with Ian that the SUMP Java client is not maintained by the OLS project ... and the issue does not qualify for an OLS fail.
On the other side there will be a considerable number of OLS users who will want to use the OLS in Arduino development. Since the problem is not restricted to Mac OSX (as shown above) and appears to origin from the SUMP Java client there should be a general interest to get it fixed. Actually the conflicts will not be restricted to the Arduino IDE but extend to all/most Java applications that will make use of librxtxSerial.jnilib and RXTXcomm.jar.
I will seperate this part of my post along with ben51s posts and merge them into a new "Conflicts between SUMP Java Client and Arduino IDE" thread later.
rhyde wrote:... The reason I have not seen the arduino interaction problem is I only have one usb port, and have failed on all attempts with powered hubs. So it is clear why I did not hit it.
ian wrote:Actually the conflicts will not be restricted to the Arduino IDE but extend to all/most Java applications that will make use of librxtxSerial.jnilib and RXTXcomm.jar.
I hadn't thought of this. Both SUMP and the Arduino IDE use the java rx/tx library. Both the FTDI chip and the OLS appear on the system as a serial port. COuld be an interaction there, but ti seems like no system should reset one serial port when another is added.
sdixon wrote:ian wrote:I hadn't thought of this. Both SUMP and the Arduino IDE use the java rx/tx library. Both the FTDI chip and the OLS appear on the system as a serial port. COuld be an interaction there, but ti seems like no system should reset one serial port when another is added.
The way most Arduino boards are set up, the processor is wired to reset to the boot loader whenever the DTR line is toggled, which generally happens when the port is opened. This is used by the Arduino IDE to automatically put the processor into the boot loader to load new code (it avoids requiring the user to manually reset the processor each time). So it perhaps isn't surprising that SUMP would cause an Arduino reset when it starts up since it seems to go through all of the available serial ports looking for the FPGA. But it doesn't really make sense that the reset happens each time a capture is started, as people are reporting. Once the correct serial port is selected in SUMP, it shouldn't be messing with any other port.