Created Mon, 26 May 2014 21:14:44 +0000 by majenko
Mon, 26 May 2014 21:14:44 +0000
I have spent the past two weeks slaving away over a hot keyboard giving UECIDE a complete makeover.
I have thrown away the old editor interface (quite literally - I deleted the old editor source code) and have crafted a proper interface. Quite frankly I got fed up with hacking and fudging the old Arduino code that I felt it would be easier in the long run to just delete it, so I did.
Here's what the interface now looks like (in Gnome with the Aluminium theme):
Gone is the old cheesy status bar in the middle of the screen wasting space. The status bar is now a real status bar at the foot of the screen - much more discrete. The editor window has now been split in two, with a proper project overview tree on the left. Gone is the old "every file in the project must be open in a tab all the time" rubbish from the old Arduino IDE. Now you only open the tabs YOU want to open! I can now craft individual editor plugins for different file types. Here's a demonstration of a small editor that dumps the structure of an ELF file into text and allows you to view it. Great for finding what's using all the space in your program:
You also get a full project file tree as well. Manage the files in your project from handy context menus. Drag and drop files within your project, make folders, delete files, even drag and drop files in from outside the project!
The plugin manager has been completely re-written as well. I know so much more about Java layout managers now, so I have done the layout properly at last. I have also implemented a task queue system, so only 3 operations will be active at once. Much more resource friendly...
I am releasing this new version as a beta test. It comes with a few caveats:
You can grab the beta software from [url]http://uecide.org/beta[/url] - it's packaged in the same formats as normal, so pick the same one you'd normally pick - the zip version ("full" if you're on windows) is probably best for testing with (except OS X of course, which is always just a DMG).
Thu, 29 May 2014 11:19:43 +0000
And here is the ultimate goal of this rewrite - what I have been striving for throughout:
matt@dell:~/git/UECIDE$ ./uecide.jar --upload --port=/dev/ttyUSB0 --board=chipkit_WF32 --headless /home/matt/libraries/Communications/DWIFIcK/examples/WiFiTCPEchoServer
Loading uecide...
Compiling...
Compiling Sketch...
Compiling Core...
...api
Compiling Libraries...
Linking sketch...
Compiling Done
Uploading firmware...
Resetting board...
Uploading...
Resetting board...
Upload Complete
Yes, command line compilation and uploading! UECIDE can now be placed in a script (be that a Makefile, or whatever) for compiling your sketch WITHOUT ANY EDITOR AT ALL!!!
How funky is that?
I'll make a new release later with this and a few more fixes in it.
Mon, 02 Jun 2014 21:18:11 +0000
How funky is that?
Get down with your bad self.
Jacob
Mon, 02 Jun 2014 23:30:08 +0000
Get down with your bad self. Jacob
Sorry, showing my age there... child of the 70's and all that ;)
Wed, 04 Jun 2014 07:13:14 +0000
I have downloaded in a separate folder c\Majenkotech\Uecide_0806. I started, very nice. Then I copied the enviromnet from my existing Uecide folder. Probably I copied what I shouldnt.
Atfer this step none of an Uecide version starts, even if I reinstall. It stucks at the starting logo. I have to clear the javaw32 in the process window.
Mpide and Arduino is running, as far as I see those using the same Java version.
Please advise what to do?
Csaba
Wed, 04 Jun 2014 09:55:35 +0000
Yes, you copied something you shouldn't have - namely your preferences.txt and the plugins from the old version.
The preferences.txt file has the location of where to store plugins. When the beta starts it installs some upgraded plugins - it's done that to your old version (because of the preferences.txt), so the old version won't like it. Also the old plugins in the new version would make it a bit iffy.
Delete the preferences.txt and .jar files from the new version's directory. Delete the PluginManager.jar and SerialTerminal.jar files from the old version's directory.
They should both start working then.
Tue, 10 Jun 2014 17:11:34 +0000
I have tried countless, but something does not work.
After starting the 6e version, the 5a doesn't start, I have to delete the 2 jar files from the 5a version.
More strange, the Plugin Manager item has been disappeared from the Tools menu in the 5a (old) version.
I get lost what to do.
Csaba
Wed, 11 Jun 2014 09:23:56 +0000
You must still have your wires crossed. Make sure the preferences.txt in your beta version's data directory doesn't point to the existing version's data directory at all. Edit it, and check for these settings:
location.boards=/home/matt/foo/boards
location.cache=/home/matt/foo/cache
location.compilers=/home/matt/foo/compilers
location.cores=/home/matt/foo/cores
location.plugins=/home/matt/foo/plugins
and make sure they don't point to the locations in your existing installation.
Wed, 11 Jun 2014 12:05:18 +0000
In the beta version no one instance in the folder of a preferences.txt. The old version has, in the main and the datadir folder but all earlier dates.
But both using the same preferences.txt in the Applications....\Local\UECIDE\ directory. This is the problem.
Both version is started from a command link having separate datadir location, so according to my logic they should look there. But they look in the Local default.
What should I do to detach them safely?
Thu, 12 Jun 2014 10:42:37 +0000
I have solved the missing functions loaded the copies of the two .jar files.
But still why they use the same Local preferences, when the datadir setup has been made?
Thanks.
Thu, 19 Jun 2014 09:55:34 +0000
I had the same issues when I started xuecide (6b) first time - my old uecide stopped working. Today I downloaded the 6e and opened it in a directory (windows zip-lite). I did not start the plugin manager but I looked at the preferences. Everything there is read from my old uecide's preferences.txt, including all the paths (that creates the mess then when you start to download via the plugin manager). So - would it be possible to create a fully autonomous environment, without reusing the old preferences stuff? It means no mixing of any setup/plugin stuff with any older installation? All related stuff in a separate dir? I rather spend 3 minutes setting the paths and configs in the new preferences.txt in the new installation as with the resolving the mess ;) PS:
Thu, 19 Jun 2014 10:32:54 +0000
That's the purpose of the --datadir=... command line option.
Thu, 19 Jun 2014 10:37:57 +0000
That's the purpose of the --datadir=... command line option.
I did it in past with the --datadir="path to my new xeucide" but it did not work, the old uecide got messed.. http://uecide.org/forum/viewtopic.php?f=9&t=200&start=10#p695
Now I have my production 8.5d working, and I am quite reluctant to try it with the --datadir= again (not to mess the 8.5d). Therefore I do not work with the new xuecide..
Thu, 19 Jun 2014 19:53:30 +0000
This is also my problem as I expressed.
Since I am working in the old version, I cant test the new one. If I start the new, I have to rebulid my working environment.
Fri, 20 Jun 2014 09:05:29 +0000
I've tried again (suicide 6e, XP SP3), set the --datadir="D:\ProgramFiles\arduino\xuecide" in the shortcut (working directory D:\ProgramFiles\arduino\xuecide), where xuecide is the new folder with the 6e. The shortcut is called xuecide.exe (to distinguish from the 85d uecide.exe).
Shortcut:
Target: D:\ProgramFiles\arduino\xuecide\uecide.exe --datadir="D:\ProgramFiles\arduino\xuecide"
Start in: D:\ProgramFiles\arduino\xuecide
I can see in the preferences the paths to xuecide. So I did download the boards/cores/compilers and it seems it creates the environment basically, without visible damage to my 85d.
It is my understanding the 6e is an early alfa version, so there are still other issues (see the uecide forum)..
Fri, 20 Jun 2014 10:52:22 +0000
I have never managed to replicate any of the problems with multiple installations that have been reported. I think most are related to copying preferences files that shouldn't be being copied ;)
Yes, there are issues still with 6e. In fact there is 6f available for download with a few fixes in it. The best upgrade route is to download the windows lite zip file and just copy the uecide.jar file from it to your installation. That's all there is to it these days, just that jar file.
There's some problems with saving in 6e, so I suggest you grab 6f asap ;)
I have already noticed some of the things on your other list, like the plugin manager problems. The icons not changing is just a screen refresh thing - gotta work out how to trigger it right. If you just highlight an entry it should change the icon. I haven't re-written the dependencies things yet for it - it's on my todo list.
Fri, 20 Jun 2014 15:02:15 +0000
6f - See the pictures - not an issue but cosmetics. :)
The issue I see is it does not compile my sketch even I see the libs in the list (in preferences Categorized libraries locations). What I need to do in order it recognizes the libraries?
PS: It does not change the editor font as set in preferences, still the default. The console font is changed after a while..
PS1: I would remove the big editor's icons, the functions are available in context or from main bar, rather spend more space for the edited text.. ( I can take the bar and move it away, but it does not allow to place it at the main bar on top, still in a separate window - wasting the resources imho).
PS2: comment/uncomment is something I would add, also autoformat was great function.
PS3: Serial Terminal - first time it opened the ST and I saw data coming. Then I closed it, and tried to open it again. No luck. Even after several restarts of xuecide, and several removes/inserts of the BT dongle. Getting "Unable to open serial port". The port is permanently blocked (I cannot open with TT either).
Fri, 20 Jun 2014 16:05:12 +0000
PS: I guess the triggering isn't happening - I'll check.
PS1: You mean the smaller editor toolbar? I may make it able to disable it.
PS2: comment/uncomment I need to rewrite. Autoformat is a plugin that needs rewriting.
PS3: Don't use bluetooth in windows XP :P
I don't know what is going on with your libraries. The old libraries system, which has a specific libraries folder, is gone. Instead it automatically adds a path to what was the standard libraries location to the libraries location list. Ensure that is right, and that it finds it. You can also check in the debug window to see what libraries it finds.
Fri, 20 Jun 2014 20:10:51 +0000
From debug - it loads the libraries:
Loading libraries from D:\MyCode\Arduino\libraries\BigNumber
Loading libraries from D:\MyCode\Arduino\libraries\BigNumberMath
..
Loading libraries from D:\MyCode\Arduino\libraries\MemoryFree
And when run compilation:
#include <MemoryFree.h>
#include <BigNumber.h>
#include <BigNumberMath.h>
BigNumberTest3X.ino:2:24: error: MemoryFree.h: No such file or directory
BigNumberTest3X.ino:3:23: error: BigNumber.h: No such file or directory
BigNumberTest3X.ino:4:27: error: BigNumberMath.h: No such file or directory
Fri, 20 Jun 2014 20:52:09 +0000
Ah, I think you may have set your libraries up wrong. There should be on entry in your libraries list in preferences - "D:\MyCode\Arduino\libraries"; it looks like you may have added that using the "Add Subdirectories" functionality, which is for adding multiple categories as subdirectories of a master directory.
Fri, 20 Jun 2014 21:04:03 +0000
:D I did nothing. It read the long list of libraries into the list automatically. So I added my library folder path to the list as the 43rd item - "libraries" (with Add new entry). So I have there 43 items, one of them is "libraries" where my libraries reside.. :? And it compiles now.
Fri, 20 Jun 2014 21:10:44 +0000
The only code capable of adding all the libraries like that is attached to the "Add Subfolders" button in preferences. The only way that code can run is if you click that button...
Maybe someone took control of your antiquated operating system and pressed it ;)
Fri, 20 Jun 2014 21:31:15 +0000
Yea, the Truecrypt took over. My XP will still be 30% of the market in 2020.. :P Unfortunately there is one single application which has issues with my BT.. Guess which one..
Fri, 20 Jun 2014 22:50:56 +0000
NTKERNEL.EXE?
Sat, 21 Jun 2014 07:31:42 +0000
I want to delete the list of libraries - I can highlight many, but it deletes only the first one in the list highlighted.
Is or will be the "clean build folder" and "purge cache folder" still available (or simply "clean")?
It would be great when it automatically put the xyz.h headers (#included) into the "Headers" folder in the "Project tree" so I can click on them and it opens them in the editor then.
What is the purpose of "Binaries" folder in the "Project tree"?
Serial Terminal - when I close the ST it locks the Com. Today the restart of xuecide helped however. Have a look at the stuff plz as it works in 85d better. Also, if possible, try to implement following simple scenario, plz: When the user clicks on the "Upload" button, the first internal operation shall be "close the Serial Terminal properly if it is opened and release the Com:X properly" That would be great to have in 85d as well. (PS: the reason for that is many of us may use the same Com:X for programming the chip as well as for the Console)
Sat, 21 Jun 2014 08:10:19 +0000
!. Yeah, I need to improve that list function - it's on my todo list.
Purge cache is in help->debug, clean build is right click on the output folder
No. Never gonna happen. Libraries are libraries - they're separate from the sketch and always will be. Imagine you get a book out from your local library and scribble all over it - would they be happy? No! But, if you photocopy the book (make a local copy) then you can scribble all over that copy to your heart's content. Localize the library (right click on it in the tree) then switch to the Files tab of the tree - you can edit the files for the local copy then.
Including binary objects (images, sounds, whatever) into your sketch. Only supported by the chipKIT core at the moment.
I'm going to have to set up some bluetoth system in windows aren't I? Unable to replicate this at all, and no one else has mentioned it ever. Oh, and the first thing it does when you upload is it closes any plugins that have the current com port open. That includes the serial terminal.
Sat, 21 Jun 2014 11:12:43 +0000
How can I debug the BT? Any advice?
Sat, 21 Jun 2014 11:41:19 +0000
Download the source code, set up a local compilation environment (JDK, Apache Ant, Git - under Linux is best) and examine the code, add Debug.message(...); commands in there to log information to the debug log, try different things out, compile it, and copy the .jar to your windows to see what helps. Serial.jar and Sketch.jar are the main users of serial, not including the serial based plugins.
Oh, and make sure you get the "complete_rewrite" branch.
Sat, 21 Jun 2014 12:24:08 +0000
My BT works at 115k. When I open the ST, the brate is set to 9600, and it works (I see the data coming). When I set the ST to 115k it stops. Setting the ST to 9k6 works again.. .. 9k6 works 14k stops with: Unable to reopen port (19k2 - missing) 28k works 38k stops with: Unable to reopen port 57k works 115k stops with: Unable to reopen port 230k works 460k stops with: Unable to reopen port .. It does not seem to be an XP issue, though..
PS: the same behavior with 85d.. The ST window cannot be closed after switching the brates.
PS1: 6f : when I set the ST br to 115k it stops. When I close the ST as well as the 6f, and I restart ST again, the ST opens with 115k and it works.. :shock: :?
Sat, 21 Jun 2014 13:07:56 +0000
Ok, good diagnostics there. It looks like it has nothing to do with the baud rate, but instead is an "every other" issue. So either it's not closing and reopening right when you change the baud rate, or it's doing the right thing but needing a delay in there to allow the BT to reconfigure itself.
Sat, 21 Jun 2014 13:49:35 +0000
PS: I have ~dozen progs I use with my 6 BTs for 4ys now (better to say I do not use Serial cables anymore). All work fine, the br and 8N1 settings must match. Otherwise it works as a dummy Serial COM. No special tricks needed behind the scene. So I would guess your application handles the BT as a standard Serial. Therefore my ongoing effort to persuade you there is a small "bug" somewhere in your Serial handling since ever.
Sat, 21 Jun 2014 13:54:26 +0000
I don't do anything particularly magical with the serial. I just open the port at a baud rate and send/receive data. If you adjust the baud rate dropdown it closes the port then opens it again with the new baud rate. There's no rocket science there, and nothing really that can go wrong. Feel free to inspect the source code and see if you can see anything wrong.
The actual serial handling itself is out of my hands - that uses the JSSC library, which is like RXTX but a lot better (in that it doesn't require special hacks just to get BT to work at all). Feel free to take a look at their source code as well and see if you can see anything in there that needs improvement for BT in windows.
Sat, 21 Jun 2014 20:09:29 +0000
Have a look at this https://code.google.com/p/java-simple-serial-connector/issues/detail?id=5&can=1&q=type%3DDefect there is a fix from 10/2013, maybe related.
Sat, 21 Jun 2014 21:03:44 +0000
Nice find. I'll make a wrapper function in the Serial class that does a purge and a close, and replace all the existing closes with calls to it - see if that helps at all.
Sat, 21 Jun 2014 21:18:42 +0000
I did torture the BT - a dozen openings/closings of the SMon in IDE 1.5.6r2 (it uses the 2.8.0 jssc lib), with switching between 9k6(bad) and 115k(good), with TeraTerm in between (open/close) and everything worked OK. NONE issues seen, port opened and closed properly.. ;)
I even opened the TT, then opened SMon in 156r2, it shot the error the port is not available (good), then I closed the TT, and quickly clicked on SMon again and it started immediately showing proper incoming data.. I did it also with reversed scenario: running SMon, then I opened TT, get error in TT (good), closed SMon and opened TT again, getting data - worked ok.
So the jssc behaves differently in 156r2 and in uecide (85d and 6f).
Here in https://github.com/arduino/Arduino/blob/1.5.6-r2/app/src/processing/app/SerialMonitor.java ie. they wait 100ms when closing the port - line ~50.. Maybe more to tackle for experts..
PS: if possible, timeouts when opening/closing com ports of at least 2-3secs would be good to have with BT.
PS1: I have to power off the BT module (at the mcu side) and restart the xuecide in order to release the COM port ..
Sun, 22 Jun 2014 12:26:33 +0000
I have added a 100ms delay to the opening of a com port (not the closing), so whenever it is opened it first waits 100ms - that should cover all situations without having to hunt down all the closes and replacing them.
I'm not sure what you mean by a 2-3 second timeout. Can you describe the idea in more detail?
Mon, 23 Jun 2014 07:18:02 +0000
6g:
java.lang.NullPointerException
at uecide.plugin.JTerminal.message(Unknown Source)
at uecide.plugin.SerialTerminal.serialEvent(Unknown Source)
at jssc.SerialPort$EventThread.run(SerialPort.java:1096)
Port name - COM5; Method name - openPort(); Exception type - Port busy.
Unable to open serial port
In the Debug Console:
Port name - COM5; Method name - openPort(); Exception type - Port busy.
******************** EXCEPTION ********************
An uncaught exception occurred:
The cause is: null
The message is: Port name - COM5; Method name - openPort(); Exception type - Port busy.
jssc.SerialPort.openPort(SerialPort.java:162)
uecide.app.Serial.requestPort(Serial.java:66)
uecide.app.Serial.requestPort(Serial.java:87)
uecide.plugin.SerialTerminal.run(Unknown Source)
uecide.plugin.SerialTerminal$7.actionPerformed(Unknown Source)
javax.swing.AbstractButton.fireActionPerformed(Unknown Source)
javax.swing.AbstractButton$Handler.actionPerformed(Unknown Source)
javax.swing.DefaultButtonModel.fireActionPerformed(Unknown Source)
javax.swing.DefaultButtonModel.setPressed(Unknown Source)
javax.swing.plaf.basic.BasicButtonListener.mouseReleased(Unknown Source)
java.awt.AWTEventMulticaster.mouseReleased(Unknown Source)
java.awt.Component.processMouseEvent(Unknown Source)
javax.swing.JComponent.processMouseEvent(Unknown Source)
java.awt.Component.processEvent(Unknown Source)
java.awt.Container.processEvent(Unknown Source)
java.awt.Component.dispatchEventImpl(Unknown Source)
java.awt.Container.dispatchEventImpl(Unknown Source)
java.awt.Component.dispatchEvent(Unknown Source)
java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source)
java.awt.LightweightDispatcher.processMouseEvent(Unknown Source)
java.awt.LightweightDispatcher.dispatchEvent(Unknown Source)
java.awt.Container.dispatchEventImpl(Unknown Source)
java.awt.Window.dispatchEventImpl(Unknown Source)
java.awt.Component.dispatchEvent(Unknown Source)
java.awt.EventQueue.dispatchEventImpl(Unknown Source)
java.awt.EventQueue.access$200(Unknown Source)
java.awt.EventQueue$3.run(Unknown Source)
java.awt.EventQueue$3.run(Unknown Source)
java.security.AccessController.doPrivileged(Native Method)
java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown Source)
java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown Source)
java.awt.EventQueue$4.run(Unknown Source)
java.awt.EventQueue$4.run(Unknown Source)
java.security.AccessController.doPrivileged(Native Method)
java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown Source)
java.awt.EventQueue.dispatchEvent(Unknown Source)
java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
java.awt.EventDispatchThread.pumpEvents(Unknown Source)
java.awt.EventDispatchThread.pumpEvents(Unknown Source)
java.awt.EventDispatchThread.run(Unknown Source)
******************** EXCEPTION ********************
Unable to open serial port
Mon, 23 Jun 2014 09:17:15 +0000
Excellent, the extra debugging I added seems to have given us some better detail.
It looks to me like it's trying to release the port, failing with an exception, then not actually releasing it so it remains locked.
Mon, 23 Jun 2014 09:23:20 +0000
I have added some extra exception wrapping around the release code - see if that helps.
I have uploaded a new uecide.jar file for you to try out: [url]http://uecide.org/beta/uecide.jar[/url]
Mon, 23 Jun 2014 09:32:51 +0000
The same..
Saved property file D:\ProgramFiles\arduino\xuecide\preferences.txt
Port name - COM5; Method name - openPort(); Exception type - Port busy.
******************** EXCEPTION ********************
An uncaught exception occurred:
The cause is: null
The message is: Port name - COM5; Method name - openPort(); Exception type - Port busy.
jssc.SerialPort.openPort(SerialPort.java:162)
uecide.app.Serial.requestPort(Serial.java:66)
uecide.app.Serial.requestPort(Serial.java:87)
uecide.plugin.SerialTerminal.run(Unknown Source)
uecide.plugin.SerialTerminal$7.actionPerformed(Unknown Source)
javax.swing.AbstractButton.fireActionPerformed(Unknown Source)
javax.swing.AbstractButton$Handler.actionPerformed(Unknown Source)
javax.swing.DefaultButtonModel.fireActionPerformed(Unknown Source)
javax.swing.DefaultButtonModel.setPressed(Unknown Source)
javax.swing.plaf.basic.BasicButtonListener.mouseReleased(Unknown Source)
java.awt.AWTEventMulticaster.mouseReleased(Unknown Source)
java.awt.Component.processMouseEvent(Unknown Source)
javax.swing.JComponent.processMouseEvent(Unknown Source)
java.awt.Component.processEvent(Unknown Source)
java.awt.Container.processEvent(Unknown Source)
java.awt.Component.dispatchEventImpl(Unknown Source)
java.awt.Container.dispatchEventImpl(Unknown Source)
java.awt.Component.dispatchEvent(Unknown Source)
java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source)
java.awt.LightweightDispatcher.processMouseEvent(Unknown Source)
java.awt.LightweightDispatcher.dispatchEvent(Unknown Source)
java.awt.Container.dispatchEventImpl(Unknown Source)
java.awt.Window.dispatchEventImpl(Unknown Source)
java.awt.Component.dispatchEvent(Unknown Source)
java.awt.EventQueue.dispatchEventImpl(Unknown Source)
java.awt.EventQueue.access$200(Unknown Source)
java.awt.EventQueue$3.run(Unknown Source)
java.awt.EventQueue$3.run(Unknown Source)
java.security.AccessController.doPrivileged(Native Method)
java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown Source)
java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown Source)
java.awt.EventQueue$4.run(Unknown Source)
java.awt.EventQueue$4.run(Unknown Source)
java.security.AccessController.doPrivileged(Native Method)
java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown Source)
java.awt.EventQueue.dispatchEvent(Unknown Source)
java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
java.awt.EventDispatchThread.pumpEvents(Unknown Source)
java.awt.EventDispatchThread.pumpEvents(Unknown Source)
java.awt.EventDispatchThread.run(Unknown Source)
******************** EXCEPTION ********************
Unable to open serial port
Mon, 23 Jun 2014 09:42:01 +0000
What worries me is that it says it's an uncaught exception. That means it's the default exception handler, so it's happening somewhere where there's no try/catch block.
BUT line 66 is slap bang in the middle of a try/catch block:
try {
SerialPort nsp = new SerialPort(name);
if (nsp != null) {
if (nsp.isOpened()) {
Base.error("For some reason the port " + name + " never got released properly.");
return null;
}
nsp.openPort(); // <<====== Line 66
return nsp;
}
} catch (SerialPortException se) {
if (se.getExceptionType().equals(SerialPortException.TYPE_PORT_NOT_FOUND)) {
JOptionPane.showMessageDialog(new Frame(), "The port could not be found.\nCheck you have the right port\nselected in the Hardware menu.", "Port not found", JOptionPane.ERROR_MESSAGE);
} else {
Base.error(se);
return null;
}
} catch (Exception e) {
Base.error(e);
return null;
}
A check is performed right before then to see if the port is open or not, and if it is then whinge about it (which isn't happening).
Maybe I'll repeatedly try and open it with some delays to see if that helps.
Mon, 23 Jun 2014 09:49:57 +0000
Just uploaded an experimental .jar file (same URL) - see what that does.
Mon, 23 Jun 2014 09:55:23 +0000
It waits few seconds after pressing the SM icon and then:
Error opening serial port
Port name - COM5; Method name - openPort(); Exception type - Port busy.
******************** EXCEPTION ********************
An uncaught exception occurred:
The cause is: null
The message is: Port name - COM5; Method name - openPort(); Exception type - Port busy.
jssc.SerialPort.openPort(SerialPort.java:162)
uecide.app.Serial.requestPort(Serial.java:73)
uecide.app.Serial.requestPort(Serial.java:115)
uecide.plugin.SerialTerminal.run(Unknown Source)
uecide.plugin.SerialTerminal$7.actionPerformed(Unknown Source)
javax.swing.AbstractButton.fireActionPerformed(Unknown Source)
javax.swing.AbstractButton$Handler.actionPerformed(Unknown Source)
javax.swing.DefaultButtonModel.fireActionPerformed(Unknown Source)
javax.swing.DefaultButtonModel.setPressed(Unknown Source)
javax.swing.plaf.basic.BasicButtonListener.mouseReleased(Unknown Source)
java.awt.AWTEventMulticaster.mouseReleased(Unknown Source)
java.awt.Component.processMouseEvent(Unknown Source)
javax.swing.JComponent.processMouseEvent(Unknown Source)
java.awt.Component.processEvent(Unknown Source)
java.awt.Container.processEvent(Unknown Source)
java.awt.Component.dispatchEventImpl(Unknown Source)
java.awt.Container.dispatchEventImpl(Unknown Source)
java.awt.Component.dispatchEvent(Unknown Source)
java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source)
java.awt.LightweightDispatcher.processMouseEvent(Unknown Source)
java.awt.LightweightDispatcher.dispatchEvent(Unknown Source)
java.awt.Container.dispatchEventImpl(Unknown Source)
java.awt.Window.dispatchEventImpl(Unknown Source)
java.awt.Component.dispatchEvent(Unknown Source)
java.awt.EventQueue.dispatchEventImpl(Unknown Source)
java.awt.EventQueue.access$200(Unknown Source)
java.awt.EventQueue$3.run(Unknown Source)
java.awt.EventQueue$3.run(Unknown Source)
java.security.AccessController.doPrivileged(Native Method)
java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown Source)
java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown Source)
java.awt.EventQueue$4.run(Unknown Source)
java.awt.EventQueue$4.run(Unknown Source)
java.security.AccessController.doPrivileged(Native Method)
java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown Source)
java.awt.EventQueue.dispatchEvent(Unknown Source)
java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
java.awt.EventDispatchThread.pumpEvents(Unknown Source)
java.awt.EventDispatchThread.pumpEvents(Unknown Source)
java.awt.EventDispatchThread.run(Unknown Source)
******************** EXCEPTION ********************
Unable to open serial port
Mon, 23 Jun 2014 09:57:07 +0000
Right, so no amount of delaying lets the port clear then. That tried to open the port 20 times with a 100ms delay between each (2 second delay).
I am at a loss now.
Mon, 23 Jun 2014 09:59:12 +0000
The stuff in 1.5.6r2 (jssc) works fine. Could the code be somehow reused in xeucide? PS: what about the purging the com before closing it - as in the jssc fix above?
I found the solution, performing a purge before closing Port:
if (serialPort! = null && serialPort.isOpened ()) {
serialPort.purgePort (1);
serialPort.purgePort (2);
serialPort.closePort ();
}
After the lines will connect successfully.
PS1: A remark: a single BT module connected gets always 2 ports opened - ie. COM5 and COM6. COM5 is the "active" one I use.
COM5 Outgoing Geoff 'DevB'
COM6 Incoming Geoff
COM7 Outgoing Jane 'DevB'
COM8 Incoming Jane
Mon, 23 Jun 2014 11:33:58 +0000
Ok, I have re-written that entire routine from scratch. I now maintain a static list of SerialPort objects and hand them out as needed, instead of creating a new port instance each time. Now it should be impossible for it to get a "busy" error from having a port opened twice.
New jar uploaded.
Mon, 23 Jun 2014 12:10:53 +0000
Am I downloading the newest one? Timestamped 13:34.. (Below an evidence it works first time after opening..) The same:
Port name - COM5; Method name - openPort(); Exception type - Port busy.
******************** EXCEPTION ********************
An uncaught exception occurred:
The cause is: null
The message is: Port name - COM5; Method name - openPort(); Exception type - Port busy.
jssc.SerialPort.openPort(SerialPort.java:162)
uecide.app.Serial.requestPort(Serial.java:82)
uecide.app.Serial.requestPort(Serial.java:97)
uecide.plugin.SerialTerminal.run(Unknown Source)
uecide.plugin.SerialTerminal$7.actionPerformed(Unknown Source)
javax.swing.AbstractButton.fireActionPerformed(Unknown Source)
javax.swing.AbstractButton$Handler.actionPerformed(Unknown Source)
javax.swing.DefaultButtonModel.fireActionPerformed(Unknown Source)
javax.swing.DefaultButtonModel.setPressed(Unknown Source)
javax.swing.plaf.basic.BasicButtonListener.mouseReleased(Unknown Source)
java.awt.AWTEventMulticaster.mouseReleased(Unknown Source)
java.awt.Component.processMouseEvent(Unknown Source)
javax.swing.JComponent.processMouseEvent(Unknown Source)
java.awt.Component.processEvent(Unknown Source)
java.awt.Container.processEvent(Unknown Source)
java.awt.Component.dispatchEventImpl(Unknown Source)
java.awt.Container.dispatchEventImpl(Unknown Source)
java.awt.Component.dispatchEvent(Unknown Source)
java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source)
java.awt.LightweightDispatcher.processMouseEvent(Unknown Source)
java.awt.LightweightDispatcher.dispatchEvent(Unknown Source)
java.awt.Container.dispatchEventImpl(Unknown Source)
java.awt.Window.dispatchEventImpl(Unknown Source)
java.awt.Component.dispatchEvent(Unknown Source)
java.awt.EventQueue.dispatchEventImpl(Unknown Source)
java.awt.EventQueue.access$200(Unknown Source)
java.awt.EventQueue$3.run(Unknown Source)
java.awt.EventQueue$3.run(Unknown Source)
java.security.AccessController.doPrivileged(Native Method)
java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown Source)
java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown Source)
java.awt.EventQueue$4.run(Unknown Source)
java.awt.EventQueue$4.run(Unknown Source)
java.security.AccessController.doPrivileged(Native Method)
java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown Source)
java.awt.EventQueue.dispatchEvent(Unknown Source)
java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
java.awt.EventDispatchThread.pumpEvents(Unknown Source)
java.awt.EventDispatchThread.pumpEvents(Unknown Source)
java.awt.EventDispatchThread.run(Unknown Source)
******************** EXCEPTION ********************
Unable to open serial port
Mon, 23 Jun 2014 12:53:41 +0000
Try my new jar file. I have re-ordered the closing things. It wasn't doing it right last time.
Mon, 23 Jun 2014 13:03:30 +0000
Interestingly, when I close the STerminal with File/Close, it closes the whole xueacide, and it does not lock the port. When I close the ST with the red/white cross on the ST window it locks the port. The port is really locked, as I cannot open it with TT either.
PS: 14:54 version (plz number the jars to be sure I work with the newest, ie. uecide34.jar)
Port name - COM5; Method name - openPort(); Exception type - Port busy.
******************** EXCEPTION ********************
An uncaught exception occurred:
The cause is: null
The message is: Port name - COM5; Method name - openPort(); Exception type - Port busy.
jssc.SerialPort.openPort(SerialPort.java:162)
uecide.app.Serial.requestPort(Serial.java:82)
uecide.app.Serial.requestPort(Serial.java:97)
uecide.plugin.SerialTerminal.run(Unknown Source)
uecide.plugin.SerialTerminal$7.actionPerformed(Unknown Source)
javax.swing.AbstractButton.fireActionPerformed(Unknown Source)
javax.swing.AbstractButton$Handler.actionPerformed(Unknown Source)
javax.swing.DefaultButtonModel.fireActionPerformed(Unknown Source)
javax.swing.DefaultButtonModel.setPressed(Unknown Source)
javax.swing.plaf.basic.BasicButtonListener.mouseReleased(Unknown Source)
java.awt.AWTEventMulticaster.mouseReleased(Unknown Source)
java.awt.Component.processMouseEvent(Unknown Source)
javax.swing.JComponent.processMouseEvent(Unknown Source)
java.awt.Component.processEvent(Unknown Source)
java.awt.Container.processEvent(Unknown Source)
java.awt.Component.dispatchEventImpl(Unknown Source)
java.awt.Container.dispatchEventImpl(Unknown Source)
java.awt.Component.dispatchEvent(Unknown Source)
java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source)
java.awt.LightweightDispatcher.processMouseEvent(Unknown Source)
java.awt.LightweightDispatcher.dispatchEvent(Unknown Source)
java.awt.Container.dispatchEventImpl(Unknown Source)
java.awt.Window.dispatchEventImpl(Unknown Source)
java.awt.Component.dispatchEvent(Unknown Source)
java.awt.EventQueue.dispatchEventImpl(Unknown Source)
java.awt.EventQueue.access$200(Unknown Source)
java.awt.EventQueue$3.run(Unknown Source)
java.awt.EventQueue$3.run(Unknown Source)
java.security.AccessController.doPrivileged(Native Method)
java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown Source)
java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown Source)
java.awt.EventQueue$4.run(Unknown Source)
java.awt.EventQueue$4.run(Unknown Source)
java.security.AccessController.doPrivileged(Native Method)
java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown Source)
java.awt.EventQueue.dispatchEvent(Unknown Source)
java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
java.awt.EventDispatchThread.pumpEvents(Unknown Source)
java.awt.EventDispatchThread.pumpEvents(Unknown Source)
java.awt.EventDispatchThread.run(Unknown Source)
******************** EXCEPTION ********************
Unable to open serial port
Mon, 23 Jun 2014 13:16:42 +0000
I did it 8x times in a row - closing the Sterminal with File/Close. It works fine, no lock up of the port.. So to recap:
Mon, 23 Jun 2014 13:29:22 +0000
That's because file->close exits the whole program. I really wish I could replicate this problem.
Mon, 23 Jun 2014 13:36:11 +0000
Sure, but that said it means the closing the ST alone, or internally (when making an upload) is not done "properly" - there must be a bug somewhere. The fact it works with 156r2 justifies that assumption..
Mon, 23 Jun 2014 13:46:32 +0000
But if that were the case it would be the same for all port types, not just bluetooth. There's only one way to close the port - port.close(). That is currently being done by the requestPort() function, after first purging the port.
Mon, 23 Jun 2014 13:55:06 +0000
I have added extra purging to the code in serial terminal.
New jar: [url]http://uecide.org/beta/uecide-342.jar[/url]
Mon, 23 Jun 2014 14:41:32 +0000
Saved property file D:\ProgramFiles\arduino\xuecide\preferences.txt
Request for port COM5
Released COM5 in all plugins
Re-opened port
Saved property file D:\ProgramFiles\arduino\xuecide\preferences.txt <<<< OPENED FIRST TIME
Request to close port
Purged port
Port closed OK
Saved property file D:\ProgramFiles\arduino\xuecide\preferences.txt <<<< CLOSED FIRST TIME
Request for port COM5 <<<<< STARTING TO TRY TO OPEN 2ND TIME
Released COM5 in all plugins
Re-opened port
Request for port COM5
Purged and closed COM5
Released COM5 in all plugins
Port name - COM5; Method name - openPort(); Exception type - Port busy.
******************** EXCEPTION ********************
An uncaught exception occurred:
The cause is: null
The message is: Port name - COM5; Method name - openPort(); Exception type - Port busy.
jssc.SerialPort.openPort(SerialPort.java:162)
uecide.app.Serial.requestPort(Serial.java:78)
uecide.app.Serial.requestPort(Serial.java:113)
uecide.plugin.SerialTerminal.run(Unknown Source)
uecide.plugin.SerialTerminal$7.actionPerformed(Unknown Source)
javax.swing.AbstractButton.fireActionPerformed(Unknown Source)
javax.swing.AbstractButton$Handler.actionPerformed(Unknown Source)
javax.swing.DefaultButtonModel.fireActionPerformed(Unknown Source)
javax.swing.DefaultButtonModel.setPressed(Unknown Source)
javax.swing.plaf.basic.BasicButtonListener.mouseReleased(Unknown Source)
java.awt.AWTEventMulticaster.mouseReleased(Unknown Source)
java.awt.Component.processMouseEvent(Unknown Source)
javax.swing.JComponent.processMouseEvent(Unknown Source)
java.awt.Component.processEvent(Unknown Source)
java.awt.Container.processEvent(Unknown Source)
java.awt.Component.dispatchEventImpl(Unknown Source)
java.awt.Container.dispatchEventImpl(Unknown Source)
java.awt.Component.dispatchEvent(Unknown Source)
java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source)
java.awt.LightweightDispatcher.processMouseEvent(Unknown Source)
java.awt.LightweightDispatcher.dispatchEvent(Unknown Source)
java.awt.Container.dispatchEventImpl(Unknown Source)
java.awt.Window.dispatchEventImpl(Unknown Source)
java.awt.Component.dispatchEvent(Unknown Source)
java.awt.EventQueue.dispatchEventImpl(Unknown Source)
java.awt.EventQueue.access$200(Unknown Source)
java.awt.EventQueue$3.run(Unknown Source)
java.awt.EventQueue$3.run(Unknown Source)
java.security.AccessController.doPrivileged(Native Method)
java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown Source)
java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown Source)
java.awt.EventQueue$4.run(Unknown Source)
java.awt.EventQueue$4.run(Unknown Source)
java.security.AccessController.doPrivileged(Native Method)
java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown Source)
java.awt.EventQueue.dispatchEvent(Unknown Source)
java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
java.awt.EventDispatchThread.pumpEvents(Unknown Source)
java.awt.EventDispatchThread.pumpEvents(Unknown Source)
java.awt.EventDispatchThread.run(Unknown Source)
******************** EXCEPTION ********************
Unable to open serial port
And after uecide's restart and trying to open the locked com port:
Saved property file D:\ProgramFiles\arduino\xuecide\preferences.txt
Request for port COM5
Released COM5 in all plugins
Port name - COM5; Method name - openPort(); Exception type - Port busy.
******************** EXCEPTION ********************
An uncaught exception occurred:
The cause is: null
The message is: Port name - COM5; Method name - openPort(); Exception type - Port busy.
jssc.SerialPort.openPort(SerialPort.java:162)
uecide.app.Serial.requestPort(Serial.java:78)
uecide.app.Serial.requestPort(Serial.java:113)
uecide.plugin.SerialTerminal.run(Unknown Source)
uecide.plugin.SerialTerminal$7.actionPerformed(Unknown Source)...
And after power off the BT and uecide's restart (the same when ST closed with File/Close previously):
Saved property file D:\ProgramFiles\arduino\xuecide\preferences.txt
Request for port COM5
Released COM5 in all plugins
Re-opened port
Mon, 23 Jun 2014 15:56:04 +0000
Re-opened port
Request for port COM5
THAT is a very suspicious bit...
On mine I see:
Request for port /dev/ttyUSB0
Released /dev/ttyUSB0 in all plugins
Re-opened port
Request for port /dev/ttyUSB0
Purged and closed /dev/ttyUSB0
Released /dev/ttyUSB0 in all plugins
Re-opened port
Seems to be opening the port twice - not sure why that would be.
Mon, 23 Jun 2014 15:58:49 +0000
Now I'm getting somewhere:
uecide.plugin.SerialTerminal$2@7e35ab86: Open port /dev/ttyUSB0
Request for port /dev/ttyUSB0
Released /dev/ttyUSB0 in all plugins
Re-opened port
uecide.plugin.SerialTerminal@1c9bfd77: Open port /dev/ttyUSB0
Request for port /dev/ttyUSB0
Purged and closed /dev/ttyUSB0
Released /dev/ttyUSB0 in all plugins
Re-opened port
There seems to be TWO serial terminals...!
This is not a serial problem at all - this is a plugin problem.
Mon, 23 Jun 2014 16:12:27 +0000
Ok, try this: [url]http://uecide.org/beta/uecide-343.jar[/url]
Mon, 23 Jun 2014 16:55:50 +0000
Saved property file D:\ProgramFiles\arduino\xuecide\preferences.txt
uecide.plugin.SerialTerminal@ee8f91: Opening serial terminal on port COM5
uecide.plugin.SerialTerminal@ee8f91: Open port COM5
Request for port COM5
Released COM5 in all plugins
Re-opened port
Request to close port
Purged port
Port closed OK
uecide.plugin.SerialTerminal@ee8f91: Closing serial terminal on port COM5
uecide.plugin.SerialTerminal@ee8f91: Closing serial terminal on port COM5
uecide.plugin.SerialTerminal@ee8f91: Opening serial terminal on port COM5
uecide.plugin.SerialTerminal@ee8f91: Open port COM5
Request for port COM5
Released COM5 in all plugins
Re-opened port
Request to close port
Purged port
Port closed OK
uecide.plugin.SerialTerminal@ee8f91: Closing serial terminal on port COM5
uecide.plugin.SerialTerminal@ee8f91: Closing serial terminal on port COM5
uecide.plugin.SerialTerminal@ee8f91: Opening serial terminal on port COM5
uecide.plugin.SerialTerminal@ee8f91: Open port COM5
Request for port COM5
Released COM5 in all plugins
Re-opened port
Request to close port
Purged port
Port closed OK
uecide.plugin.SerialTerminal@ee8f91: Closing serial terminal on port COM5
uecide.plugin.SerialTerminal@ee8f91: Closing serial terminal on port COM5
uecide.plugin.SerialTerminal@ee8f91: Opening serial terminal on port COM5
uecide.plugin.SerialTerminal@ee8f91: Open port COM5
Request for port COM5
Released COM5 in all plugins
Re-opened port
Request to close port
Purged port
Port closed OK
uecide.plugin.SerialTerminal@ee8f91: Closing serial terminal on port COM5
uecide.plugin.SerialTerminal@ee8f91: Closing serial terminal on port COM5
uecide.plugin.SerialTerminal@ee8f91: Opening serial terminal on port COM5
uecide.plugin.SerialTerminal@ee8f91: Open port COM5
Request for port COM5
Released COM5 in all plugins
Re-opened port
Request to close port
Purged port
Port closed OK
uecide.plugin.SerialTerminal@ee8f91: Closing serial terminal on port COM5
Saved property file D:\ProgramFiles\arduino\xuecide\preferences.txt
:) I am very happy that after a year of my tremendous effort I was able to push you into this fix finally :P Can you do it with 85x as well?
Mon, 23 Jun 2014 17:14:04 +0000
Now, the Serial Terminal works somehow, it closes when uploading, but I get this after the upload:
avrdude.exe: writing flash (23040 bytes):
Writing | ################################################## | 100% 7.56s
avrdude.exe: 23040 bytes of flash written
avrdude.exe done. Thank you.
Port name - COM4; Method name - openPort(); Exception type - Port busy.
Unable to lock serial port for board reset
The ST opens and works however (now I work with an another BT module on the COM4).
PS: sometimes it does
Uploading firmware...
Port name - COM4; Method name - openPort(); Exception type - Port busy.
Unable to lock serial port for board reset
after it closes the ST, but I can open ST, ST works, and after next attempt it downloads, with above message on port busy (but ST works, I can open, close it)..
Mon, 23 Jun 2014 17:20:02 +0000
I may need to tweak the upload system to work with the new close method.
I have back ported a fix to the old old version of serialterminal - it might work...
Mon, 23 Jun 2014 17:22:31 +0000
See may previous post I edited recently - describing the current upload issues. ST works however..
Mon, 23 Jun 2014 17:50:47 +0000
85d: I upgraded the SerialT via pluginM. Now when ST runs and I do upload, the ST does not close, but shows red Disconnected, the upload works fine. But the ST stays with Disconnected, and cannot be closed. When I open 2nd ST, 2nd ST works. When I do upload, it shows Disconnected in the 2nd ST (there is the 1st ST as well with Disconnected). The upload works ok, when upload finishes the 1st ST starts working and the second ST shows Disconnected and cannot be closed.. :)
Mon, 23 Jun 2014 18:27:15 +0000
The fix for that should be in the next release. It's too minor to bother with uploading specially. As for the old version - well, it's broken. Less broken that it was, but there you have it. That's why the beta is there - it's to fix all these things.
Fri, 27 Jun 2014 08:47:45 +0000
The editor font still not changing.. 6h
Fri, 27 Jun 2014 08:59:51 +0000
Yeah, I know. On the todo list. Can you open github issues for any problems you find so I don't lose track of them all?
Fri, 04 Jul 2014 20:50:19 +0000
I have just started working with the ChipKit MAX32 and MPIDE. Today I was trying to figure out how to "close" editor tabs in MPIDE. I did not like the way the tabs in MPIDE worked when there are more files in the sketch than will fit in tabs along the top. I found this thread and the mention of how the tabs work was of great interest.
I installed the beta and everything works with my simple test sketch involving several files and a 32 bit timer interrupt, so I am happy so far :D I have never used the Arduino IDE, preferring to use AVR Studio and WinAvr, but wanted to see if I can get used to the Arduino type environment.
I certainly like what I see in this "makeover" compared to MPIDE so far, thanks! (This is on OS-X)
Chuck
In fact, it's probably not even beta at this point. Use it at your own risk - it may not work at all for you, but please do give it a go. I need to know what works and what doesn't.
Sat, 05 Jul 2014 09:59:26 +0000
Great that you're enjoying it :)
Anything you find wrong, or anything you think could use a makeover, please open a github issue for it: [url]https://github.com/UECIDE/UECIDE/issues?milestone=1&state=open[/url]
Sat, 05 Jul 2014 20:35:03 +0000
Would it be possible to be able to set at least these flags from IDE? We may have other clocks freqs, and we may not want to use usb serial for example, or we may not want to use USB at all.. (prg via pickit then..) -DF_CPU=80000000L -D_USE_USB_FOR_SERIAL_
OR
maybe to have Board.txt in project list such we can edit/save it..
Sat, 05 Jul 2014 20:43:48 +0000
The USB serial one should be settable from the hardware (options) menu. As for the frequency, it's embedded in the board, so if you have a board that runs at a different frequency then you should really make a new board.
Sat, 05 Jul 2014 20:48:31 +0000
The USB serial one should be settable from the hardware (options) menu. As for the frequency, it's embedded in the board, so if you have a board that runs at a different frequency then you should really make a new board.
USB - No such option visible (only Warnings there..) I have FubSd with 80 and 120MHz.. why to create a new board then? I think the board freq is the only param (except USB usage) which may differ on the same board..
Or, ok, what needs to be done to create a new board?? Copy and rename the folder? Hehe, there is 6 descriptors with "fubarino" in board.txt - which one is relevant? I want in Fubarino folder have /fubarino_sd_120 and fubarino_sd_80 for example, and to see them in the menu then.. :)
Sat, 05 Jul 2014 21:15:48 +0000
Ah, the option is on a per-board basis (it's not applicable to all boards) and only the WF32 has it at the moment. I must replicate that to the other boards.
I've added it to the fubarino SD and the Max32 now. I've also knocked you up a 120MHz SD board in there as well.
Sat, 05 Jul 2014 21:34:31 +0000
Thanks, it works. When updating something in Plugin Manager - ie, an yellow triangel lits, what shall I do? Click "install" icon, or "remove" and then "instal"? I am missing an "update" icon there :)
Sat, 05 Jul 2014 22:12:11 +0000
You should just be able to "install" and it will upgrade. You can also do the "upgrade all" (arrow with a dot) and it will do all that need it.
Sun, 06 Jul 2014 08:35:57 +0000
How can I set a compilation flag (ie, Optimization level) from the sketch? I think we had had something like that but I cannot find that again..
Sun, 06 Jul 2014 09:52:50 +0000
#pragma parameter extra.flags=-O2
Sun, 06 Jul 2014 10:31:56 +0000
O like Ontario :) Thanks..
Sun, 06 Jul 2014 10:38:31 +0000
Did I do 0? I meant O. Oh. Not enough 0xC0FFEE.
Thu, 10 Jul 2014 20:54:52 +0000
Right, I want to push this beta version to completion ASAP now, so if you could all really hammer it and get those bugs in the issue tracker for me to fix that'd be great.
I've overhauled the UECIDE website today as well. The download page is now:
[url]http://uecide.org/download[/url]
Beta downloads are at the bottom of the page. We're up to 0.8.6m now...
Sat, 12 Jul 2014 10:00:02 +0000
It seems there is an issue with loading libs (86p).. I've tried to compile the TinyBasicPlus for mighty. It shows more libs in Libraries than required, and for example it tries to compile SdFat, when the SD is included only.. (only SD, SPI, EEPROM are included within the sketch).. https://github.com/BleuLlama/TinyBasicPlus
Sat, 12 Jul 2014 10:11:02 +0000
My guess is that there is a library naming conflict. SD has a file SdFat.h that it includes. You also have a library called "SdFat", which the IDE is finding when it sees that SD requires "SdFat.h".
I guess that it should be ruling out header files that match files inside the current library but isn't.
Sat, 12 Jul 2014 10:17:10 +0000
You may have X libs with Y identical file names inside of each.. That is not a sin..
Sat, 12 Jul 2014 10:19:46 +0000
I know it's not. It's just in some cases, when the header file is in the utility folder for example, it couldn't identify that it was local since "utility" wasn't included in the path name.
Try this: [url]http://uecide.org/beta/uecide-383.jar[/url]
Sat, 12 Jul 2014 11:57:16 +0000
That compiles..
Sat, 12 Jul 2014 12:31:16 +0000
An idea: would it be possible to create a small file inside the sketch folder, called ie. sketch.conf, where the settings for a) board, b) core, c) compiler, d) serial, e) options, and f) programmer selection will be stored? Thus switching between various sketches from "recent files" would not require switching that above settings too.. :ugeek:
Sat, 12 Jul 2014 12:33:20 +0000
I had thought of that, yes. It's something I'd probably like to do at some point.
Fancy signing up for an account on the main uecide.org site and creating it as an idea?
Sat, 12 Jul 2014 12:46:57 +0000
I'm trying not to implement anything new now until the beta is released. When it is, and I have a bunch of ideas logged, I'll start working through them starting with the most voted for ones.
Also, signing up to the main uecide.org site gives you access to an in-browser chat system like basefook has.
Sat, 12 Jul 2014 12:48:49 +0000
I did but none email received..
Sat, 12 Jul 2014 12:59:34 +0000
Looks like your dodgy mail host failed for a bit - should be there now though:
2014-07-12 13:36:37 1X5wXd-000Elu-Ra <= info@uecide.org H=(uecide.org) [213.229.101.171] P=esmtpa A=login:xxxx@xxxx.co.uk S=1071 id=4701ecb349131093a74f8546f3a7c48a@uecide.org
2014-07-12 13:36:38 1X5wXd-000Elu-Ra ax.virusfree.cz [2001:67c:15a1::b1] No route to host
2014-07-12 13:36:38 1X5wXd-000Elu-Ra ax.virusfree.cz [2001:67c:15a0::a1] No route to host
2014-07-12 13:36:39 1X5wXd-000Elu-Ra SMTP error from remote mail server after RCPT TO:<pito@xxxx.cz>: host ax.virusfree.cz [77.93.216.14]: 451 temporary failure G (#4.3.0)
2014-07-12 13:36:39 1X5wXd-000Elu-Ra SMTP error from remote mail server after RCPT TO:<pito@xxxx.cz>: host ax.virusfree.cz [88.208.65.55]: 451 temporary failure G (#4.3.0)
2014-07-12 13:36:39 1X5wXd-000Elu-Ra cx.spamfree.cz [2001:67c:15a2::c1] No route to host
2014-07-12 13:36:39 1X5wXd-000Elu-Ra dx.spamfree.cz [2001:67c:15a3::d1] No route to host
2014-07-12 13:36:39 1X5wXd-000Elu-Ra == pito@xxxx.cz R=dnslookup T=remote_smtp defer (65): No route to host
2014-07-12 13:54:50 1X5wXd-000Elu-Ra ax.virusfree.cz [2001:67c:15a1::b1] No route to host
2014-07-12 13:54:50 1X5wXd-000Elu-Ra ax.virusfree.cz [2001:67c:15a0::a1] No route to host
2014-07-12 13:54:56 1X5wXd-000Elu-Ra => pito@xxxx.cz R=dnslookup T=remote_smtp S=1107 H=ax.virusfree.cz [77.93.216.14] X=TLSv1:DHE-RSA-AES256-SHA:256
Wed, 23 Jul 2014 21:24:07 +0000
It last, I have taken the UECIDE beta and released it as a stable version.
0.8.7a is now available for download!
Mon, 11 Aug 2014 09:02:37 +0000
Stretching the makeover yet further, UECIDE now better supports themeing.
Not only that, but the console has been re-written and is now HTML-aware. Makes for much nicer informational outputs.
Here's the current beta sporting the HiFi window theme (Java Look & Feel), plus the Halflife SublimeText theme imported and slightly tweaked by hand: [attachment=0]ueicdesecksey.png[/attachment] Now you have to admit, that's starting to look rather sexy, isn't it?
Tue, 12 Aug 2014 20:08:36 +0000
Nice...
Jacob
Wed, 13 Aug 2014 23:13:02 +0000
This looks fantastic! Way to push ahead, majenko
G
Mon, 25 Aug 2014 15:40:30 +0000
Which SD Card library should I use? I got a ton of error messages!
Most of them regarding to: "#error ******** This sketch or library uses AVR-specific code that may not work with the chipKIT platform. See this forum for more information on porting code to chipKIT"
Uecide 8,5a compiles without a glitch.
Mon, 25 Aug 2014 17:09:52 +0000
I have installed the SD lib from https://github.com/chipKIT32/chipKIT32-MAX/tree/master/hardware/pic32/libraries/SD.
I get the same error message:
Compiling... Compiling Sketch... In file included from C:\Users\csaba.TMARKTDOMAIN\Documents_a_14_11_Projektek\Arduino_Pic\Uecide_Pde\libraries\SD_chipK/utility/SdFat.h:26:0, from C:\Users\csaba.TMARKTDOMAIN\Documents_a_14_11_Projektek\Arduino_Pic\Uecide_Pde\libraries\SD_chipK/SD_chipK.h:20, from C:\Users\csaba.TMARKTDOMAIN\Documents_a_14_11_Projektek\Arduino_Pic\Uecide_Pde\BICLOG_01_031\BICLOG_01_031.ino:15: C:\Program Files (x86)\Majenko Technologies\UECIDE\Uecide settings\compilers\pic32-tools\bin../lib/gcc/pic32mx/4.5.1/../../../../pic32mx/include/avr/pgmspace.h:4:2: error: #error ******** This sketch or library uses AVR-specific code that may not work with the chipKIT platform. See this forum for more information on porting code to chipKIT
I see what I might doing wrong. The two versions uecide 8.5a and the new one has been mixed, using the same settings directory I have to delete every versions and reinstall the new one.
Mon, 25 Aug 2014 17:25:50 +0000
I have reinstalled 0.8.7j.
Same result.
What is next?
Mon, 25 Aug 2014 18:27:39 +0000
You shouldn't be "installing" that library - it is already included in the core, and I have modified it to use proper hardware SPI and provide much higher speeds.
Delete the library from wherever you installed it to and just use the version included in the core.
Mon, 25 Aug 2014 19:03:16 +0000
After some massaging the library I have advanced, but not much:
In file included from C:\Users\csaba.TMARKTDOMAIN\Documents_a_14_11_Projektek\Arduino_Pic\Uecide_Pde\libraries\SD/SD.h:20:0, from C:\Users\csaba.TMARKTDOMAIN\Documents_a_14_11_Projektek\Arduino_Pic\Uecide_Pde\BICLOG_01_031\BICLOG_01_031.ino:15: C:\Users\csaba.TMARKTDOMAIN\Documents_a_14_11_Projektek\Arduino_Pic\Uecide_Pde\libraries\SD/utility/SdFat.h:285:10: error: conflicting return type specified for 'virtual size_t SdFile::write(uint8_t)' C:\Program Files (x86)\Majenko Technologies\UECIDE\Uecide settings\cores\chipKIT\api/Print.h:50:15: error: overriding 'virtual void Print::write(uint8_t)' C:\Users\csaba.TMARKTDOMAIN\Documents_a_14_11_Projektek\Arduino_Pic\Uecide_Pde\libraries\SD/utility/SdFat.h:287:10: error: conflicting return type specified for 'virtual size_t SdFile::write(const char*)' C:\Program Files (x86)\Majenko Technologies\UECIDE\Uecide settings\cores\chipKIT\api/Print.h:51:15: error: overriding 'virtual void Print::write(const char*)' In file included from C:\Users\csaba.TMARKTDOMAIN\Documents_a_14_11_Projektek\Arduino_Pic\Uecide_Pde\BICLOG_01_031\BICLOG_01_031.ino:15:0: C:\Users\csaba.TMARKTDOMAIN\Documents_a_14_11_Projektek\Arduino_Pic\Uecide_Pde\libraries\SD/SD.h:36:18: error: conflicting return type specified for 'virtual size_t File::write(uint8_t)' C:\Program Files (x86)\Majenko Technologies\UECIDE\Uecide settings\cores\chipKIT\api/Print.h:50:15: error: overriding 'virtual void Print::write(uint8_t)' C:\Users\csaba.TMARKTDOMAIN\Documents_a_14_11_Projektek\Arduino_Pic\Uecide_Pde\libraries\SD/SD.h:37:18: error: conflicting return type specified for 'virtual size_t File::write(const uint8_t*, size_t)' C:\Program Files (x86)\Majenko Technologies\UECIDE\Uecide settings\cores\chipKIT\api/Print.h:52:15: error: overriding 'virtual void Print::write(const uint8_t*, size_t)' Failed compiling sketch
Mon, 25 Aug 2014 19:08:27 +0000
DELETE THE LIBRARY
You are wasting your time!
Mon, 25 Aug 2014 19:09:23 +0000
You shouldn't be "installing" that library - it is already included in the core, and I have modified it to use proper hardware SPI and provide much higher speeds. Delete the library from wherever you installed it to and just use the version included in the core.
Ok.
Mon, 25 Aug 2014 19:14:19 +0000
DELETE THE LIBRARY You are wasting your time!
I missed your post.
Mon, 25 Aug 2014 19:20:57 +0000
I missed your post.
Thanks, it has compiled.
Just a little bit more understanding: The compiler first looking in the contributed lib. then in the chipkit lib?
Mon, 25 Aug 2014 19:21:28 +0000
I missed your post.
D'oh ;)
I'll post louder in future then :P
The library you have downloaded is part of the github version of MPIDE and uses the Arduino 1.x.x Print class which hasn't been released on the public yet. You can track that version with the chipKIT-Git core, but it doesn't work on MX chips at the moment (problem with the compiler / linker) so don't. It works fine with MZ chips (WiFire) though.
As I say, the library is already in the core, and I have optimized it for faster operation, so you don't need to do a thing, just #include <SD.h>.
Mon, 25 Aug 2014 19:24:24 +0000
Thanks, it has compiled. Just a little bit more understanding: The compiler first looking in the contributed lib. then in the chipkit lib?
Yes. It's all to do with the order the libraries are scanned. First it looks in the compiler, then the core, then the board, then it scans all the contributed ones. The last one found overrides an earlier one.
Mon, 25 Aug 2014 20:31:41 +0000
Thanks.
The new release is funky.....! A real milestone. I appreciate your effort.
To debug in MPLABX, I have some questions: the .elf file location is static? It shouldn't be in the sketch folder? how can I switch to external editor mode?
One other question: I am using Fubarino SD in my present project.
The USB (what is an on cip one) is behaving very annoying compared to standard chipkit boards, what is using FTDI interface.
Many times I blocked by "Unable to open Serial Port" message trying to use Monitor. Also many times unable to upload the program.
Sometimes board reset helps, sometimes (experienced still in the 8.5a version) I had to restart uecide. Do you have some suggestion to make it more comfortable?
Csaba
Mon, 25 Aug 2014 20:40:55 +0000
Thanks. The new release is funky.....! A real milestone. I appreciate your effort. To debug in MPLABX, I have some questions: the .elf file location is static? It shouldn't be in the sketch folder?
You can set the build folder to be located in the sketch folder, or it can be in the temporary file location. For debugging it is useful to have it in the sketch folder.
The option is in the preferences.
how can I switch to external editor mode?
You don't. You don't need to. It's all automatic. There is a service running which watches the files for external changes and reloads them if they have changed. You can have the file open in UECIDE and edit it outside. As soon as you save the file you will see it automatically update in UECIDE. If the file has been edited in UECIDE it will pop up and tell you it's been modified and ask you if you want to reload it.
One other question: I am using Fubarino SD in my present project. The USB (what is an on cip one) is behaving very annoying compared to standard chipkit boards, what is using FTDI interface. Many times I blocked by "Unable to open Serial Port" message trying to use Monitor. Also many times unable to upload the program. Sometimes board reset helps, sometimes (experienced still in the 8.5a version) I had to restart uecide. Do you have some suggestion to make it more comfortable? Csaba
Which operating system are you using? Some are better than others at handling the CDC/ACM class. The problem is that every time the board resets, for entering the bootloader, exiting the bootloader to run the sketch, etc, the serial port gets completely destroyed and recreated. It's like unplugging the board and plugging it back in again very rapidly. Some systems don't like it, and some take a moment or two to re-detect the board.
It's a pain, and one of the reasons I don't usually use the stk500 bootloader with them but use a HID bootloader instead.
Tue, 26 Aug 2014 06:33:28 +0000
The option is in the preferences.
Found.
You don't. You don't need to. It's all automatic. There is a service running which watches the files for external changes and reloads them if they have changed. You can have the file open in UECIDE and edit it outside. As soon as you save the file you will see it automatically update in UECIDE. If the file has been edited in UECIDE it will pop up and tell you it's been modified and ask you if you want to reload it.
This sounds great!!
Which operating system are you using? Some are better than others at handling the CDC/ACM class. The problem is that every time the board resets, for entering the bootloader, exiting the bootloader to run the sketch, etc, the serial port gets completely destroyed and recreated. It's like unplugging the board and plugging it back in again very rapidly. Some systems don't like it, and some take a moment or two to re-detect the board. It's a pain, and one of the reasons I don't usually use the stk500 bootloader with them but use a HID bootloader instead.
I am using Win7, Vista, XP on different notebooks depending the workphase. Right now I am working on Win7. Many times I can't connect even when the stk500 appears in the device manager.
Annoying to reload uecide and disconnect the USB at every 3rd upload/serial monitor attach. It was so comfortable in uecide using chipkit boards, when the Serial monitor was suspended and reconnected after upload. Is it possible with Fubarino SD?
Where can I find the HID bootloader?
Thanks.
Tue, 26 Aug 2014 08:46:44 +0000
Another bug we are trying to track down at the moment, which is also in recent versions of MPIDE, is that there are sometimes problems with the USB enumerating in Windows, which might be part of what you are seeing.
The bootloader I use is a somewhat modified version of the bootloader in RetroBSD. I have been meaning to clean it up and get it on github sometime, but it's not in a very friendly format at the moment.
It doesn't help the Windows CDC/ACM enumeration issues though.
Thu, 28 Aug 2014 04:37:33 +0000
Using the new uecide release I have found a way how to use Fubarino SD. After disconnected the serial monitor, press at least for 3-4 sec the reset button, then once more the reset and the prog together to enter bootloading mode. Usually works.
The long reset also works during Serial Debugging to restart. It is painful, but at least don't have to disconnect the USB time-to time.
I also tried MPLABX integration working flawless The long reset requirement also painful in this configuration too.
Fri, 29 Aug 2014 08:00:27 +0000
I am working in the new version in the last 3 days.
The Serial minitor is behaving a bit strange with Fubarion SD but this is dicussed. I havent used other boards with the new version.
During the Serial Monitor open, there is an error message, time to time:
java.lang.NullPointerException at uecide.plugin.JTerminal.message(Unknown Source) at uecide.plugin.SerialTerminal.serialEvent(Unknown Source) at jssc.SerialPort$EventThread.run(SerialPort.java:1096)
Is it possible to make more comfortable the "Find & Replace" function:
if there is a highlited text and invoking the Find&Replace function in menu or keyboard combination, it should open the Find context in the bottom of the window (as it does now) and copy the highlited text to Find window. Also a Find & Replace icon in the top icon-row of the window could be comfortable.