Re: [Openocd-development] About the eclipse
Alain Mouette a écrit : > Michel Catudal escreveu: > >> Freddie Chopin a écrit : >> >>> Alain Mouette pisze: >>> >>> I just have to discover if dgb+OpenOCD works fine, but I was not able to make it work with CM3 en Eclipse either (it worked fine in ARM 7/9). Probably I just have to try it again with 0.2.0 >>> OpenOCD works and was always working fine with Eclipse. I use it with >>> ARM7 and Cortex-M3 without many problems. >>> >>> Use the tutorial at Michael Ficher's site - www.yagarto.de - or try the >>> auto-translated version of my tutorial: >>> http://translate.google.com/translate?prev=hp&hl=pl&js=y&u=http%3A%2F%2Fwww.freddiechopin.info%2Findex.php%2Fpl%2Fartykuy%2F35-arm%2F59-arm-toolchain-tutorial%3Fshowall%3D1&sl=pl&tl=en&history_state0= >>> >>> >> I also have a tutorial but it is for Linux users. Yagarto's tutorial is >> strictly for windows users. >> > > Please, I would like it very much (I use Linux). Do you have it posted > somewhere? > > Thanks, > Alain > > _ On my website. I have one that assumes that you use an IAR STM32 board with CAN and one that assumes that you use an a Stellaris board from Texas Instruments. The file is not up to date as I have changes some of my compilers. My latest ARM compiler is 4.4.0 from the released version and not the SVN. I will update the documents within the next few weeks. I have been very busy at work recently with long hours otherwise I would have updated them. I will provide 64 bits binaries in a few weeks as soon as I get myself another hard disk. I have little space left on my 2TB of hard disk space. Michel -- Tired of Microsoft's rebootive multitasking? then it's time to upgrade to Linux. http://home.comcast.net/~mcatudal ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] About the eclipse
Michel Catudal escreveu: > Freddie Chopin a écrit : >> Alain Mouette pisze: >> >>> I just have to discover if dgb+OpenOCD works fine, but I was not able to >>> make it work with CM3 en Eclipse either (it worked fine in ARM 7/9). >>> Probably I just have to try it again with 0.2.0 >>> >> >> OpenOCD works and was always working fine with Eclipse. I use it with >> ARM7 and Cortex-M3 without many problems. >> >> Use the tutorial at Michael Ficher's site - www.yagarto.de - or try the >> auto-translated version of my tutorial: >> http://translate.google.com/translate?prev=hp&hl=pl&js=y&u=http%3A%2F%2Fwww.freddiechopin.info%2Findex.php%2Fpl%2Fartykuy%2F35-arm%2F59-arm-toolchain-tutorial%3Fshowall%3D1&sl=pl&tl=en&history_state0= >> > I also have a tutorial but it is for Linux users. Yagarto's tutorial is > strictly for windows users. Please, I would like it very much (I use Linux). Do you have it posted somewhere? Thanks, Alain ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] About the eclipse
Michel Catudal wrote: > You misunderstood my comment. I've had to explain to many people why > they had such a ridiculous message. > If you forget to change a name that doesn't exist you are likely to > find a problem much quicker than if you get an error message > that on the surface appeared to be legitimate. I too have several > different version, actually a few more than you. > Most people using free software do not as they stick usually to one. I > was pointing out a way to make it easier to find such silly error. Well - in most cases, you will *not* get a "not found" message. If I am working on a Powerpc or SH project, using the ARM debugger as default will produce just the same "ridiculous" messages, so using arm-elf as default is in no way better than using the native gdb. cu Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] About the eclipse
Hi, On Sun, Jul 26, 2009 at 10:20 AM, Øyvind Harboe wrote: > We use the Zylin Embedded CDT on linux daily inhouse and I've received > lots of feedback indicating that there are Linux users out there. > I am using it on Windows with CygWin, Linux (Ubuntu) and MacOS X. Regards, Edgar ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] About the eclipse
Michael Schwingen a écrit : > Michel Catudal wrote: > >> ECDT_Debugger_Name = gdb >> >>> This is a silly default, but there isn't really a good default here. >>> I chose arm-elf-gdb. >>> >>> >>> >>> >> It is easy to change, I was just mentionning that it looks bad because >> gdb is the local debugger and not an embedded one. >> A common free debugger is arm-elf-gdb while the most familiar commercial >> versions have eabi in it. It would be better to have arm-elf-gdb >> or arm-linux-gdb since if you forget to change the default you will not >> get weird messages that will confuse the hell out of a newbie. >> A missing filename message is better than a criptic message which unless >> you realize that it is trying to debug x86 stuff makes no sense. >> >> > This is just silly. > > You have to change it anyway - *any* default will be wrong for a > majority of users. > > On my work machine, I have these versions: > /opt/cgdb/bin/powerpc-eabi-gdb > /opt/cgdb/bin/sh-elf-gdb > /opt/gdb-6.3/bin/powerpc-eabi-gdb > /opt/gdb-6.5/bin/powerpc-eabi-gdb > /opt/gdb-6.7.1/bin/arm-elf-gdb > /opt/gdb-6.7.1/bin/powerpc-eabi-gdb > /opt/gdb-6.7.1/bin/sh-elf-gdb > /opt/gdb-6.8/bin/arm-elf-gdb > /opt/gdb-6.8/bin/powerpc-eabi-gdb > > which are used for different projects. Whichever is the default is wrong > for most work, and if the default is any one of these instead of the > native gdb, it won't help a bit for any debugging work that requires a > different one. > > cu > Michael > You misunderstood my comment. I've had to explain to many people why they had such a ridiculous message. If you forget to change a name that doesn't exist you are likely to find a problem much quicker than if you get an error message that on the surface appeared to be legitimate. I too have several different version, actually a few more than you. Most people using free software do not as they stick usually to one. I was pointing out a way to make it easier to find such silly error. I've had people searching for a long time as to why they could not get their debugger to work, perhaps they thought that the plugin was able to sniff the debugger as codeblocks do. The solution would be to either make sure that the default debugger is not the system debugger or do as codeblocks does and make it possible to identify the debugger correctly. Michel -- Tired of Microsoft's rebootive multitasking? then it's time to upgrade to Linux. http://home.comcast.net/~mcatudal ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] About the eclipse
Michel Catudal wrote: > ECDT_Debugger_Name = gdb >>> >>> >> This is a silly default, but there isn't really a good default here. >> I chose arm-elf-gdb. >> >> >> > It is easy to change, I was just mentionning that it looks bad because > gdb is the local debugger and not an embedded one. > A common free debugger is arm-elf-gdb while the most familiar commercial > versions have eabi in it. It would be better to have arm-elf-gdb > or arm-linux-gdb since if you forget to change the default you will not > get weird messages that will confuse the hell out of a newbie. > A missing filename message is better than a criptic message which unless > you realize that it is trying to debug x86 stuff makes no sense. > This is just silly. You have to change it anyway - *any* default will be wrong for a majority of users. On my work machine, I have these versions: /opt/cgdb/bin/powerpc-eabi-gdb /opt/cgdb/bin/sh-elf-gdb /opt/gdb-6.3/bin/powerpc-eabi-gdb /opt/gdb-6.5/bin/powerpc-eabi-gdb /opt/gdb-6.7.1/bin/arm-elf-gdb /opt/gdb-6.7.1/bin/powerpc-eabi-gdb /opt/gdb-6.7.1/bin/sh-elf-gdb /opt/gdb-6.8/bin/arm-elf-gdb /opt/gdb-6.8/bin/powerpc-eabi-gdb which are used for different projects. Whichever is the default is wrong for most work, and if the default is any one of these instead of the native gdb, it won't help a bit for any debugging work that requires a different one. cu Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] About the eclipse
Øyvind Harboe a écrit : > I've committed a few fixes. > > Patches gladly accepted for any other warnings you can sort out... > > > I will let you know, right now I am trying to figure out why the openocd ftdi driver will not work at all on Mandriva 2009.1 The proprietary stuff works like a champ. > >> The guilty file is build.properties >> > > Fix committed (removed obsolete references). > > good > >>> The update site works fine on e.g. Eclipse 3.5 w/Ubuntu 9.04. >>> >>> >>> >> Doesn't work on Ubuntu 8.10 >> > > Could you elaborate? Eclipse 3.5 does not work or the plugin? > > What happens? > > Tons of errors. I downloaded version 3.5 and installed locally and problem was fixed. I actually preferred version 3.5 of Eclipse so I never went back to the 3.2 version that was installed. It would have been nice to have the standard ubuntu Eclipse install work with it. > I can't see any reason for problems with Ubuntu as such. This even > works on Mac & Ubuntu 9.04. > > > >> Last I tried with Ubuntu 8.10 and fedora 9 it would barf, so I relied to the >> old fashion way which is to copy the compiled java >> to their proper directory. >> > > What barfed? > > We had some domain name problems with our server that we sorted > out. Could it that you hit that problem window? > > > Don't remember the details except that I got lotsa messages of errors, not just warnings. >> I am referring to the .jar files. It is important which version of Eclipse >> is used. >> If you have 3.3, 3.4 or 3.5 you need different ones. >> > > There is no way I could hope to support anything than the latest > version of Eclipse with the resources available. > > > I understood that, it is why I opted to recompile my own plugin. That way I can have a working system without any concern with what Linux version I have. Perhaps your way around for people who have issues would be to give a short description on how to generate ones own plugin from source. The upgrade is dependant on what a distribution has done to "beautify" their version of Eclipse. I have little confidence on the eclipse upgrade approach for this kind of stuff as you have no control on what Mandriva, Redhat or SuSE do with their Eclipse. Redhat for instance compiles everything for the opensource of java which has nowhere near the quality of the Sun Java. I've had lotsa crashes with Redhat's Eclipse and it is often due to the non Sun Plugins. This will change eventually. Maybe the best approach for eveyone would be to install Eclipse locally with the official stuff but to convince anyone to do that would be quite a challenge. >> ECDT_Debugger_Name = gdb >> > > This is a silly default, but there isn't really a good default here. > I chose arm-elf-gdb. > > It is easy to change, I was just mentionning that it looks bad because gdb is the local debugger and not an embedded one. A common free debugger is arm-elf-gdb while the most familiar commercial versions have eabi in it. It would be better to have arm-elf-gdb or arm-linux-gdb since if you forget to change the default you will not get weird messages that will confuse the hell out of a newbie. A missing filename message is better than a criptic message which unless you realize that it is trying to debug x86 stuff makes no sense. Michel -- Tired of Microsoft's rebootive multitasking? then it's time to upgrade to Linux. http://home.comcast.net/~mcatudal ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] About the eclipse
I've committed a few fixes.
Patches gladly accepted for any other warnings you can sort out...
> The guilty file is build.properties
Fix committed (removed obsolete references).
>> The update site works fine on e.g. Eclipse 3.5 w/Ubuntu 9.04.
>>
>>
>
> Doesn't work on Ubuntu 8.10
Could you elaborate? Eclipse 3.5 does not work or the plugin?
What happens?
I can't see any reason for problems with Ubuntu as such. This even
works on Mac & Ubuntu 9.04.
> Last I tried with Ubuntu 8.10 and fedora 9 it would barf, so I relied to the
> old fashion way which is to copy the compiled java
> to their proper directory.
What barfed?
We had some domain name problems with our server that we sorted
out. Could it that you hit that problem window?
> I am referring to the .jar files. It is important which version of Eclipse
> is used.
> If you have 3.3, 3.4 or 3.5 you need different ones.
There is no way I could hope to support anything than the latest
version of Eclipse with the resources available.
> ECDT_Debugger_Name = gdb
This is a silly default, but there isn't really a good default here.
I chose arm-elf-gdb.
--
Øyvind Harboe
Embedded software and hardware consulting services
http://www.zylin.com
### Eclipse Workspace Patch 1.0
#P embeddedcdt4_0
Index: build.properties
===
RCS file: /cvsroot/cdt-contrib/embeddedcdt4_0/build.properties,v
retrieving revision 1.5
diff -u -r1.5 build.properties
--- build.properties7 May 2008 21:01:55 - 1.5
+++ build.properties26 Jul 2009 17:53:16 -
@@ -12,7 +12,6 @@
.classpath,\
.project,\
plugin.properties,\
- 3rdparty/commons-httpclient-3.1.jar,\
META-INF/,\
helpwanted.txt,\
bugs.txt,\
@@ -27,7 +26,6 @@
plugin.properties,\
plugin.xml,\
src/,\
- 3rdparty/,\
lib/,\
META-INF/,\
helpwanted.txt,\
Index: ChangeLog
===
RCS file: /cvsroot/cdt-contrib/embeddedcdt4_0/ChangeLog,v
retrieving revision 1.47
diff -u -r1.47 ChangeLog
--- ChangeLog 13 Jul 2009 18:23:29 - 1.47
+++ ChangeLog 26 Jul 2009 17:53:16 -
@@ -1,3 +1,7 @@
+2009-07-26 Øyvind Harboe
+ * Fixed a few warnings reported by Michel Catudal
+ * arm-elf-gdb is now default
+ * Fixed CygWin to Cygwin spelling in a few places
2009-07-13 Øyvind Harboe
* bumped to 4.9.1
2009-07-08 Øyvind Harboe
Index: plugin.properties
===
RCS file: /cvsroot/cdt-contrib/embeddedcdt4_0/plugin.properties,v
retrieving revision 1.1
diff -u -r1.1 plugin.properties
--- plugin.properties 26 Feb 2007 20:03:18 - 1.1
+++ plugin.properties 26 Jul 2009 17:53:16 -
@@ -1,7 +1,7 @@
-containerName.cygwin=CygWin path translator
-containerDescription.cygwin=Translates from CygWin to Windows paths
+containerName.cygwin=Cygwin path translator
+containerDescription.cygwin=Translates from Cygwin to Windows paths
StandardCommandFactory.name=Standard
-ECDT_Debugger_Name = gdb
+ECDT_Debugger_Name = arm-elf-gdb
ECDT_Debugger_Init =
ECDT_Main_PrefPage_Label = Embedded CDT
ECDT_Main_PrefPage_Desc = Set preferences for the Embedded CDT Plugin
Index:
src/com/zylin/embeddedcdt/sourcelookup/cygwin/CygWinSourceContainerBrowser.java
===
RCS file:
/cvsroot/cdt-contrib/embeddedcdt4_0/src/com/zylin/embeddedcdt/sourcelookup/cygwin/CygWinSourceContainerBrowser.java,v
retrieving revision 1.1
diff -u -r1.1 CygWinSourceContainerBrowser.java
---
src/com/zylin/embeddedcdt/sourcelookup/cygwin/CygWinSourceContainerBrowser.java
26 Feb 2007 20:03:17 - 1.1
+++
src/com/zylin/embeddedcdt/sourcelookup/cygwin/CygWinSourceContainerBrowser.java
26 Jul 2009 17:53:16 -
@@ -10,6 +10,6 @@
SourceContainerBrowser
{
public ISourceContainer[] addSourceContainers( Shell shell,
ISourceLookupDirector director ) {
- return new ISourceContainer[] { new
CygWinSourceContainer("CygWin source container" ) };
+ return new ISourceContainer[] { new
CygWinSourceContainer("Cygwin source container" ) };
}
}
Index:
src/com/zylin/embeddedcdt/sourcelookup/cygwin/CygWinSourceLookupDirector.java
===
RCS file:
/cvsroot/cdt-contrib/embeddedcdt4_0/src/com/zylin/embeddedcdt/sourcelookup/cygwin/CygWinSourceLookupDirector.java,v
retrieving revision 1.1
diff -u -r1.1 CygWinSourceLookupDirector.java
---
src/com/zylin/embeddedcdt/sourcelookup/cygwin/CygWinSourceLookupDirector.java
26 Feb 2007 20:03:18 - 1.1
+++
src/com/zylin/embeddedcdt/sourcelookup/cygwin/CygWinSourceLookupDire
Re: [Openocd-development] About the eclipse
Øyvind Harboe a écrit : > I'll answer a few more questions here, but really these belong > in the zylin-discuss mailing list. > > [stuff deleted w.r.t. warnings, I'll have a peek at the current warnings > at some point] > > Not a problem >> This one is better than the 4.5 version even though it still has the >> requirement for two phantom directories >> It can be fixed by removing those items. >> > > What directories? > > The guilty file is build.properties source.zylinembeddedcdt.jar = src/ output.zylinembeddedcdt.jar = bin/ bin.includes = plugin.xml,\ zylinembeddedcdt.jar,\ icons/,\ cdtpatches.txt,\ plugin.xml,\ icons/,\ build.properties,\ bin/,\ ChangeLog,\ .classpath,\ .project,\ plugin.properties,\ ==> 3rdparty/commons-httpclient-3.1.jar,\ META-INF/,\ helpwanted.txt,\ bugs.txt,\ lib/ src.includes = .classpath,\ .project,\ ChangeLog,\ bin/,\ cdtpatches.txt,\ build.properties,\ icons/,\ plugin.properties,\ plugin.xml,\ src/,\ ==> 3rdparty/,\ lib/,\ META-INF/,\ helpwanted.txt,\ bugs.txt jars.compile.order = zylinembeddedcdt.jar > Hmm... java doesn't "compile directories" or require empty ones... I don't > know what you are referring to here. > > whether it is java, C or assembler it always gets upset when you state directories that don't exist > What binary are you referring to? > > .jar files > The update site works fine on e.g. Eclipse 3.5 w/Ubuntu 9.04. > > Doesn't work on Ubuntu 8.10 > There update site works on all operating systems, no special > linux binary required. > > Last I tried with Ubuntu 8.10 and fedora 9 it would barf, so I relied to the old fashion way which is to copy the compiled java to their proper directory. > The Zylin Embedded CDT is identical for all distributions of linux > or operating systems for that matter. > > What is it that you are referring to that requires binaries for > a particular distribution? > > I am referring to the .jar files. It is important which version of Eclipse is used. If you have 3.3, 3.4 or 3.5 you need different ones. I will check them again when I get some time. a last gripe on my part : In the file plugin.properties containerName.cygwin=CygWin path translator containerDescription.cygwin=Translates from CygWin to Windows paths StandardCommandFactory.name=Standard ECDT_Debugger_Name = gdb ECDT_Debugger_Init = ECDT_Main_PrefPage_Label = Embedded CDT ECDT_Main_PrefPage_Desc = Set preferences for the Embedded CDT Plugin It might be a good idea to not default to gdb as it looks stupid because gdb is the local debugger and not the embedded debugger. It can have several name like arm-linux-gdb or arm-elf-gdb but gdb is definitely not one of them. You are probably right, we should stick to the proper newsletter even though there is some apparent overlap of the two here. Michel -- Tired of Microsoft's rebootive multitasking? then it's time to upgrade to Linux. http://home.comcast.net/~mcatudal ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] About the eclipse
I'll answer a few more questions here, but really these belong in the zylin-discuss mailing list. [stuff deleted w.r.t. warnings, I'll have a peek at the current warnings at some point] > This one is better than the 4.5 version even though it still has the > requirement for two phantom directories > It can be fixed by removing those items. What directories? > The name of the directories in > question seem to give the impression that the plugin > will be cripple in some instances unless those are put it there. > What are those ThirdParty parts? What are they called? > One thing I don't understand about that eclipse compiling is that I would > consider a missing directory an error and not a warning. Hmm... java doesn't "compile directories" or require empty ones... I don't know what you are referring to here. > >>> When you get to the zylin website it is obvious that only windows is >>> supported. >>> >> >> For my information: where does it say that only windows is supported? >> >> It certainly was not my intention to give that impression. >> >> > > You haven't provided a working Linux binary since version 3.2 What binary are you referring to? The update site works fine on e.g. Eclipse 3.5 w/Ubuntu 9.04. There update site works on all operating systems, no special linux binary required. > I prefer to compile my own but many people do not. > I think that the best approach on your site would be to ask people to > provide packages for different distributions if you are not willing or don't > have > the time to do it. On the setedit and turbo vision projects we have done > that and it has been very well received. > Not too many people are interested in blindly copying plugins in the eclipse > plugin directory and prefer to rely on people who know what they're doing. The Zylin Embedded CDT is identical for all distributions of linux or operating systems for that matter. What is it that you are referring to that requires binaries for a particular distribution? -- Øyvind Harboe Embedded software and hardware consulting services http://www.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] About the eclipse
Øyvind Harboe a écrit : > We use the Zylin Embedded CDT on linux daily inhouse and I've received > lots of feedback indicating that there are Linux users out there. > > It does work on Cygwin too. > > On cdt-contrib.sourceforge.net you need to check out embeddedcdt4. The > older embeddedcdt versions are still there only for reference. Perhaps it > would be better to delete them. > > Here is the latest version: > > http://opensource.zylin.com/embeddedcdt.html > > > On Mandriva 2009.1 the latest version still has 11 warnings and no errors, a good improvement. Some warnings seem to be irrelevant and some give some doubt on whether it will run correctly or not. example - Accès déconseillé : The method getInstance() from the type WorkbenchHelpSystem is not accessible due to restriction on required library /usr/lib/eclipse/plugins/ org.eclipse.ui.workbench_3.4.2.M20090127-1700.jar There were some issues on Fedora 9. The previous version I tried would barf on Ubuntu 8.10 until I installed the newer eclipse. This one is better than the 4.5 version even though it still has the requirement for two phantom directories It can be fixed by removing those items. The name of the directories in question seem to give the impression that the plugin will be cripple in some instances unless those are put it there. What are those ThirdParty parts? One thing I don't understand about that eclipse compiling is that I would consider a missing directory an error and not a warning. >> When you get to the zylin website it is obvious that only windows is >> supported. >> > > For my information: where does it say that only windows is supported? > > It certainly was not my intention to give that impression. > > You haven't provided a working Linux binary since version 3.2 I prefer to compile my own but many people do not. I think that the best approach on your site would be to ask people to provide packages for different distributions if you are not willing or don't have the time to do it. On the setedit and turbo vision projects we have done that and it has been very well received. Not too many people are interested in blindly copying plugins in the eclipse plugin directory and prefer to rely on people who know what they're doing. If you are interested I could provide some packages for 1-Fedora 9 32 bits 2-Ubuntu 8.10 32 bits 3-Ubuntu 9.04 32 bits 4-SuSE 11.1 64 bits 5-SuSE 11.0 32 bits 6-Mandriva 2009.1 32 bits Michel -- Tired of Microsoft's rebootive multitasking? then it's time to upgrade to Linux. http://home.comcast.net/~mcatudal ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] About the eclipse
We use the Zylin Embedded CDT on linux daily inhouse and I've received lots of feedback indicating that there are Linux users out there. It does work on Cygwin too. On cdt-contrib.sourceforge.net you need to check out embeddedcdt4. The older embeddedcdt versions are still there only for reference. Perhaps it would be better to delete them. Here is the latest version: http://opensource.zylin.com/embeddedcdt.html > When you get to the zylin website it is obvious that only windows is > supported. For my information: where does it say that only windows is supported? It certainly was not my intention to give that impression. -- Øyvind Harboe Embedded software and hardware consulting services http://www.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] About the eclipse
hello michel 2009/7/26 Michel Catudal : >> When I can modify it I will patch it to you. Thank you very much. > > All you need is to have Eclipse installed with the plugin support and > possibly many other packages if you see errors flagged by the plugin. > you download the plugin from cvs and make an import of the project. > You then export the plugin if you don't have any errors. > > After you export the plugin you copy the .jar file on eclipse/plugin > ok, I wil try. best regards wangqiang ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] About the eclipse
Qiang Wang a écrit : >> Could you explain what issues you found? >> > I use the zylin in windows to debug some ARM assembly code and c code. > I use the register table,too. But I found that the register table can > only show 64-bit register value but not 32-bit. > If you have the experience of debugging an embedded system, you will > know what it means. > > I will look that up. Right now I am in the process of changing from the proprietary binaries and the open source ftdi, that last one doesn't work on mandriva. Once I fix it I will see if I can help you on that. I usually don't debug my code in assembler so I haven't played any attention to this. > Another issue It is too slow when I download some big code.I do not > know the reason. > > I think that it may be more an issue with the JTAG software. To see if the problem is really at Eclipse you could try gdb by itself. One option you could try is setedit. Set does have a dos version which should work on windows. He uses his own library to interface with gdb. It is quite fast compared to Eclipse. > >If you have found bugs for which you have patches I'm sure others would > appreciate if you posted your fixes. > > I do not know how to develop the Eclipse Plug-ins , but I am going to > study it now. > When I can modify it I will patch it to you. > > All you need is to have Eclipse installed with the plugin support and possibly many other packages if you see errors flagged by the plugin. you download the plugin from cvs and make an import of the project. You then export the plugin if you don't have any errors. After you export the plugin you copy the .jar file on eclipse/plugin Michel -- Tired of Microsoft's rebootive multitasking? then it's time to upgrade to Linux. http://home.comcast.net/~mcatudal ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] About the eclipse
>Could you explain what issues you found? I use the zylin in windows to debug some ARM assembly code and c code. I use the register table,too. But I found that the register table can only show 64-bit register value but not 32-bit. If you have the experience of debugging an embedded system, you will know what it means. Another issue It is too slow when I download some big code.I do not know the reason. >If you have found bugs for which you have patches I'm sure others would appreciate if you posted your fixes. I do not know how to develop the Eclipse Plug-ins , but I am going to study it now. When I can modify it I will patch it to you. best regards wangqiang ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] About the eclipse
Øyvind Harboe a écrit : >> I adapted the zylin plugin to Linux and it works fine. As is it had serious >> issues. >> > > Could you explain what issues you found? > > The binaries published years ago don't work unless you use some old 3.2 Eclipse and there are no new binaries published. The source doesn't not compile at all. It requires some simulator stuff which seems to be some proprietary crap not provided with the source. I clean that crap out and in the process makes it more lean by removing the useless windows and mac stuff. My goal is to have something that works well on Linux. I have never seen anyone making any effort to support different Linux distributions correctly so I chose to make my own plugins. My plugins are a customized Linux only version of zylin plugin and a modified version of gnuarm plugin which seems to be a windows only plugin despite the false claims that it was also meant for Linux. I have not added anything to the zylin plugin, just removed useless crap and changed the default name for the debugger to arm-elf-gdb, the default of gdb is rather ridiculous to say the least. I haven't made a real fork since I have not really had any need for added functionality to it yet. I am always willing to provide the source for my plugin when someone asks for it. For the gnuarm plugin it is a different story. I found it rather useless as is since it lacked some important flags for the cortex devices that I use. I also didn't like names used for the different packages since it took too long to create new projects. I will eventually add more functionality to it. My plugins are customized versions for Linux for me and those people like me who have no use whasoever for windows or mac. It is not meant to be a replacement for zylin or anything similar, just a custom version that is tested on Linux and is sure to work on Linux. I have tested on several version of Linux RPM based systems as well as a couple of Ubuntu distributions.. I provide a document that explains you in details how to get a development system working. So far most people who have read and and told me about it seemed quite satisfied. Someone has some issues on Ubuntu 8.04, I think he has some missing libraries. I just hadn't had time to deal with this one yet. Everytime I think I got some time to deal with it something else more important comes up. Someone has a neat document that only supports windows. He says clearly that the zylin plugin that he uses is not able to use gdb, he uses insight. Many people who write to me on the subject have never been able to get it to work with arm-elf-gdb on Linux until they found my plugin. > If you have found bugs for which you have patches I'm sure others would > appreciate if you posted your fixes. > > When you get to the zylin website it is obvious that only windows is supported. If I find actual bugs I will see if I can find a way to fix them without breaking anything and will make sure to let someone know. I don't know if missing parts can be considered as bugs and I don't think that the maintainers of the zylin plugin would be willing to remove the part that I consider useless crap. Michel -- Tired of Microsoft's rebootive multitasking? then it's time to upgrade to Linux. http://home.comcast.net/~mcatudal ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] About the eclipse
> I adapted the zylin plugin to Linux and it works fine. As is it had serious > issues. Could you explain what issues you found? > It needed some special hardware to work. ?? > I only provide a binary so you need to make your own modification on the > zylin but I can help if you write to me personally. If you have found bugs for which you have patches I'm sure others would appreciate if you posted your fixes. -- Øyvind Harboe Embedded software and hardware consulting services http://www.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] About the eclipse
The reason why I still maintain the Zylin Embedded CDT plugin is mainly that it provides projectless debugging + a few tricks for Cygwin. -- Øyvind Harboe Embedded software and hardware consulting services http://www.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] About the eclipse
Freddie Chopin a écrit : Alain Mouette pisze: I just have to discover if dgb+OpenOCD works fine, but I was not able to make it work with CM3 en Eclipse either (it worked fine in ARM 7/9). Probably I just have to try it again with 0.2.0 OpenOCD works and was always working fine with Eclipse. I use it with ARM7 and Cortex-M3 without many problems. Use the tutorial at Michael Ficher's site - www.yagarto.de - or try the auto-translated version of my tutorial: http://translate.google.com/translate?prev=hp&hl=pl&js=y&u=http%3A%2F%2Fwww.freddiechopin.info%2Findex.php%2Fpl%2Fartykuy%2F35-arm%2F59-arm-toolchain-tutorial%3Fshowall%3D1&sl=pl&tl=en&history_state0= I also have a tutorial but it is for Linux users. Yagarto's tutorial is strictly for windows users. Michel -- Tired of Microsoft's rebootive multitasking? then it's time to upgrade to Linux. http://home.comcast.net/~mcatudal ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] About the eclipse
Qiang Wang a écrit : > Hello, Oyvind Harboe > Yes, Eclipse is. > But Zylin plug-ins needs more jobs to do. > > My work is about the hardware and software, too. > I try to use Zylin to debug my code, with openocd too. > It is good but not enough for job, we have to purchase special ARM Debug ICE. > > Best regards > > > 2009/7/25 Øyvind Harboe : > >> The great advantage of Eclipse for us is that it can be >> used by a heterogeneous team. >> >> We're a team of hardware FPGA & software engineers. >> >> The software engineers use techniques which include >> C++, but also Java, web, etc. >> >> Eclipse offers a great Subversion plugin for those that >> do not want to rely exclusively on command line tools, >> which is especially true for hardware engineers we >> find. Mostly hardware engineers use it as a subversion >> GUI and editor. The ability to launch e.g. ModelSim using >> project settings that can be committed to projects is >> a great advantage. >> >> -- >> Øyvind Harboe >> Embedded software and hardware consulting services >> http://www.zylin.com >> >> I adapted the zylin plugin to Linux and it works fine. As is it had serious issues. It needed some special hardware to work. I only provide a binary so you need to make your own modification on the zylin but I can help if you write to me personally. Michel -- Tired of Microsoft's rebootive multitasking? then it's time to upgrade to Linux. http://home.comcast.net/~mcatudal ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] About the eclipse
Qiang Wang pisze: > Really? > Can it debug the ARM assembly code , ARM c code and MISP code also? > How can I got it or something like that? You can do the first two things with Zylin alone or with GDB H.D. + Zylin (I suppose that Zylin does the disassembly, it's not possible to see the assembler code without that plubin installed - only installed, nothing more is required). I don't know about MIPS Debugging assembly code is not as comfortable as C code. Try the tutorials that I've linked - they do explain a lot of things that you ask for. 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] About the eclipse
Really? Can it debug the ARM assembly code , ARM c code and MISP code also? How can I got it or something like that? 2009/7/25 Freddie Chopin : > Qiang Wang pisze: >> Hello, Oyvind Harboe >> Yes, Eclipse is. >> But Zylin plug-ins needs more jobs to do. >> >> My work is about the hardware and software, too. >> I try to use Zylin to debug my code, with openocd too. >> It is good but not enough for job, we have to purchase special ARM Debug ICE. > > Try GDB Hardware Debugging plugin which is available as an official CDT > addon from Eclipse. > > 4\/3!! > ___ > Openocd-development mailing list > Openocd-development@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/openocd-development > ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] About the eclipse
Qiang Wang pisze: > Hello, Oyvind Harboe > Yes, Eclipse is. > But Zylin plug-ins needs more jobs to do. > > My work is about the hardware and software, too. > I try to use Zylin to debug my code, with openocd too. > It is good but not enough for job, we have to purchase special ARM Debug ICE. Try GDB Hardware Debugging plugin which is available as an official CDT addon from Eclipse. 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] About the eclipse
Hello, Oyvind Harboe Yes, Eclipse is. But Zylin plug-ins needs more jobs to do. My work is about the hardware and software, too. I try to use Zylin to debug my code, with openocd too. It is good but not enough for job, we have to purchase special ARM Debug ICE. Best regards 2009/7/25 Øyvind Harboe : > The great advantage of Eclipse for us is that it can be > used by a heterogeneous team. > > We're a team of hardware FPGA & software engineers. > > The software engineers use techniques which include > C++, but also Java, web, etc. > > Eclipse offers a great Subversion plugin for those that > do not want to rely exclusively on command line tools, > which is especially true for hardware engineers we > find. Mostly hardware engineers use it as a subversion > GUI and editor. The ability to launch e.g. ModelSim using > project settings that can be committed to projects is > a great advantage. > > -- > Øyvind Harboe > Embedded software and hardware consulting services > http://www.zylin.com > ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] About the eclipse
hello, Luca I use Eclipse with zylin. You can try the zylin with the plug-in below. http://opensource.zylin.com/embeddedcdt.html It can be used but not so convince. best regards wang qiang 2009/7/25 Luca Ottaviano : > Il giorno sab, 25/07/2009 alle 10.44 +0900, Qiang Wang ha scritto: >> hello, >> I just have another question. >> Do you use the Eclipse to debug your code? > > I've been using CodeLite lately on both Linux and Windows with great > satisfaction. It's consistent between platforms and auto-completion > works fine (something that other IDEs I tried didn't got quite > right...but maybe it's just me that can't setup correctly :) > > Best regards, > -- > Luca Ottaviano > > ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] About the eclipse
The great advantage of Eclipse for us is that it can be used by a heterogeneous team. We're a team of hardware FPGA & software engineers. The software engineers use techniques which include C++, but also Java, web, etc. Eclipse offers a great Subversion plugin for those that do not want to rely exclusively on command line tools, which is especially true for hardware engineers we find. Mostly hardware engineers use it as a subversion GUI and editor. The ability to launch e.g. ModelSim using project settings that can be committed to projects is a great advantage. -- Øyvind Harboe Embedded software and hardware consulting services http://www.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] About the eclipse
Alain Mouette pisze: > I just have to discover if dgb+OpenOCD works fine, but I was not able to > make it work with CM3 en Eclipse either (it worked fine in ARM 7/9). > Probably I just have to try it again with 0.2.0 OpenOCD works and was always working fine with Eclipse. I use it with ARM7 and Cortex-M3 without many problems. Use the tutorial at Michael Ficher's site - www.yagarto.de - or try the auto-translated version of my tutorial: http://translate.google.com/translate?prev=hp&hl=pl&js=y&u=http%3A%2F%2Fwww.freddiechopin.info%2Findex.php%2Fpl%2Fartykuy%2F35-arm%2F59-arm-toolchain-tutorial%3Fshowall%3D1&sl=pl&tl=en&history_state0= 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] About the eclipse
I am not sure if this question is for me... but I can answer: I use Eclipse Ganimede, but I am not happy with it. I am planning to move to Code::Blocks as soon as possible. Just a few weeks when I deliver the current project in beta version. I have tested Code::Blocks in some smaller tests. It feels very nice, fast, project is only one small file, easy to backup, etc... I just have to discover if dgb+OpenOCD works fine, but I was not able to make it work with CM3 en Eclipse either (it worked fine in ARM 7/9). Probably I just have to try it again with 0.2.0 Alain Qiang Wang escreveu: > hello, > I just have another question. > Do you use the Eclipse to debug your code? > > best regards > wang qiang > ___ > Openocd-development mailing list > Openocd-development@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/openocd-development > > ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
