This is a general comment not related to what Lamomiaciatica wrote.
Every engineer like more or less one IDE, I know engineers who like vim
that is not exactly an IDE.
I don't love an IDE more of another probably because I start programming
using PE and Edit an old IBM editor that I already had the source code
and I personalize a lot on my old HP Vectra. So I use what my customers
are using (when I have to do) or what I find/have for the cpu I have to
use. In the last 2 years I am using Eclipse or Eclipse based IDEs more
frequently then others and I am quite happy.
I don't use professionally CrossWorks, I evaluated it as I evaluated and
evaluate a lot of IDEs but it is one of the best I had used. I used also
Renesas HEW and I really think it was one of the worst.
In the embedded market there are more or less a dozen of
specialized/proprietary IDEs, in this group for me the winner is
CrossWorks; it is better then Keil uVision and also better then IAR IDE.
And there are as I know 3 standard IDEs used also for embedded: Visual
Studio, Eclipse and NetBeans. In this segment for me the winner is
Eclipse/Eclipse based IDEs. There are a lot of Eclipse based IDEs (DS-5,
LpcXpresso, Red Suite, Code Composer Studio, Code Warrior, e2studio), If
you only think about editing/building/debugging you can think Eclipse is
not so good but it has so many useful plugins (for cvs, svn, git,
mercurial and a dozen of svc, Mylyn, doxygen, the Atlassian plugins,
Maven, etc, etc.) that it is very productive and integrated in a
professional environment. There is also so much interest in Eclipse that
ARM DS-5 is based on Eclipse, ARM add some very good plugins and made a
very good IDE. You may evaluate it for free because the release tailored
to work with Android is free.
Also Keil has a plugin to use Eclipse instead uVision4, Renesas and
Silicon Labs have their Eclipse based IDE and other premier compiler
vendors are working on Eclipse.
Netbeans: it is as good as Eclipse, more better for Java (for me it has
the best GUI designer for Java) but also the C/C++ personality is quite
good. It hasn't so many plugins as Eclipse and until now it is used only
by Microchip as I know.
Visual Studio: Atmel choosed it for the new IDE, I really don't know
why.
So I think that on the long run the winner will be Eclipse, the
advantage to use one IDE for every need it is a good idea also if they
need to solve some problems (sometimes a plugin ti work with a
microcontroller don't accept the presence of some other plugins) and
they would study a little bit CrossWorks but it is a good product not
only tailored to hobbysts. I would like to have a GUI designer (not only
for Java) like that on Netbeans and the possibility to have sub projects
(Freescale added this possibility on their newest IDE always an Eclipse
based IDE)
Il 30/03/2012 21:07, Lamomiaciatica ha scritto:
>
>
> For me the Eclipse is for a hobbyist and not for educational too .Eclipse
> has more plugging and need a power pc CPU to run with good performance.
>
> At this moment I use IAR for ARM and AVR and prefer an IDE in-house
> again to
> open source...
>
> I evaluate the crossworks for the next plain.
>
> Thanks for yours opinion... Diego
>
> _____
>
> De: l...
> [mailto:l... ] En
> nombre de
> Phil Young
> Enviado el: viernes, 30 de marzo de 2012 15:56
> Para: l...
> Asunto: RE: [lpc2000] Re: ARM Development Tools
>
> Well said Chris.
>
> Eclipse based IDE has cost several CPU vendors design wins for ASIC
> with me,
> I will never risk a commercial development on an Eclipse based toolchain.
>
> Yes, it's cheap, but with the cost of developing an SOC into the tens
of
> millions of dollars having a good professionally maintained IDE that
isn't
> written in Java is a no brainer.
>
> And it's not just the code editor, but the debugger also.
>
> For a hobbyist it's a great environment, but IMHO it's not suitable
for a
> serious commercial product development.
>
> Regards
>
> Phil.
>
> From: l...
>
> [mailto:l...
> ] On
> Behalf Of
> Chris
> Sent: 30 March 2012 19:47
> To: l...
>
> Subject: Re: [lpc2000] Re: ARM Development Tools
>
> >> The CrossWorks IDE, CrossStudio, is completely written in-house.
> >> I see this as Rowley's biggest disadvantage.
> >> Their IDE just doesn't have all the nice features that Eclipse has
and
> never will.
> >> If there is something you want to do in Eclipse that's not
supported
> natively, it's very likely that there is a plugin that will do it.
>
> OMG. Nice features in Eclipse? Where!!! Eclipse is about the worst code
> editor I have ever used.
>
> Can you put your cursor on a word and just hit a key or two and search for
> all occurances of that word?
> Can you pull up a reference source for the word at your cursor?
> Perhaps I've not figured out how to use Eclipse right. So how do you
do
> that?
>
> It's funny that there are so many requests for an UltraEdit plugin for
> Eclipse.
> Why? Because Eclipse lacks so many basic programming editor features.
>
> I've used UltraEdit for years, and CrossWorks has many of the same
> features.
> I love that.
> That fact that CrossWorks is NOT based on Eclipse I see as as HUGE plus.
>
> CrossWorks has a zillion features that give a programmer truck loads of
> information.
> It is chuck full of data, information, and capabilities you will never
> find
> in any Eclipse clone.
> CrossWorks shows you the ROM and RAM used by every single module
> instantly.
> Zillons of other details.
>
> I've used a lot of IDE's and I have to say that CrossWorks is one of
the
> best.
> It was obviously designed by people who know exactly what embedded
> programmers need.
>
> Chris.
>
>
>
>
>
>
ARM Development Tools
Started by ●March 29, 2012
Reply by ●March 30, 20122012-03-30
Reply by ●March 30, 20122012-03-30
On 30 Mar 2012, at 18:17, fhriley wrote:
> --- In l..., Paul Curtis wrote:
>>
>>> The screen shots of Red Suite indicate that it's Eclipse-based. I can't
>>> tell what CrossWorks uses.
>>
>> The CrossWorks IDE, CrossStudio, is completely written in-house. We don't
>> hitch a ride on Eclipse or anything else that exists for the IDE. The IDE
>> reflects what we use each day, what we feel is appropriate for embedded
>> development, and not a huge melting pot of disparate ideas, from web
>> development to embedded development. Use sharp tools, not blunt instruments.
>
> I see this as Rowley's biggest disadvantage. Their IDE just doesn't have all the nice features that Eclipse has and never will.
That is simply opinion.
> If there is something you want to do in Eclipse that's not supported natively, it's very likely that there is a plugin that will do it.
Granted, there are a lot of plug-ins for everything under the sun. But you don't want everything under the sun. Do you use Eclipse when you want to write a fit polynomials as part of your numerical methods work? Well, I don't, I use Mathematica and sollya and I don't need a plug-in for it.
The problem is that is comes down to a kit of pieces collected from everywhere and all the IDE vendors using Eclipse are simply doing integration work. It's much like creating a Linux distribution, I suppose--take bit from here and there, remix, and serve. How many commercial Eclipse-based IDEs for ARM do we have now?
* Code Red's RedSuite
* CodeSourcery [aka Mentor now]
* Altium / Tasking
* TI's Code Composer Studio
* Attolic TrueSTUDIO
* Freescale's CodeWarrior
* ARM DS
These are all vendor supplied and all are different. Assume I want new support for LPC1700s and I have Code Compose Studio--where do I go to get the plug-in support for that? Oh, I can't? Right, I need another Eclipse toolset for that? Ok, now I need to develop for Atmel's ARM9--which Eclipse toolset do I need for that?
Given that these are all nicely written in portable Java, how come they don't run on all the standard operating systems across the board, like Windows, Linux, OS X, and Solaris and support for all the standard debug probes that you can acquire?
Eclipse don't have any cohesion, is clunky, and I hate using it. I use it frequently for XMOS development in XC. I hate every single moment of it, and I know I'm not alone.
In the end, it's just preference and IDE wars.
>
> On Fri, Mar 30, 2012 at 3:32 AM, wrote:
>> Code Red on the LPCXpresso is noticeably slower, probably due to it being
>> written in Java.
>
> Agreed that the LPCXpresso debugging is slow, but I wouldn't necessarily say it's because of Java. Java can be every bit as fast as C++. It may be the case that the Red Probe is much faster. I can't say either way though, of course, so it's a risk.
>
These are based on FTDI FT2232 devices, typically. One of the things that such devices do not do well is read target memory. Great in the other direction, writing is fast, but not reading.
> On Fri, Mar 30, 2012 at 3:32 AM, wrote:
>> CrossWorks libraries are lean and mean, and I have never encountered a bug
>> in them. Code Red supports their own libary (forget what it's called) and
>> Newlib. Newlib is a pig -- it pulls in so much code it's ridiculous.
>
> To be fair, there was very little difference between Code Red's library and Rowley's library in terms of performance and size when I tried it. You don't have to use newlib with Code Red, they just provide it.
>
You know, I think there is a difference.
-- Paul.
> --- In l..., Paul Curtis wrote:
>>
>>> The screen shots of Red Suite indicate that it's Eclipse-based. I can't
>>> tell what CrossWorks uses.
>>
>> The CrossWorks IDE, CrossStudio, is completely written in-house. We don't
>> hitch a ride on Eclipse or anything else that exists for the IDE. The IDE
>> reflects what we use each day, what we feel is appropriate for embedded
>> development, and not a huge melting pot of disparate ideas, from web
>> development to embedded development. Use sharp tools, not blunt instruments.
>
> I see this as Rowley's biggest disadvantage. Their IDE just doesn't have all the nice features that Eclipse has and never will.
That is simply opinion.
> If there is something you want to do in Eclipse that's not supported natively, it's very likely that there is a plugin that will do it.
Granted, there are a lot of plug-ins for everything under the sun. But you don't want everything under the sun. Do you use Eclipse when you want to write a fit polynomials as part of your numerical methods work? Well, I don't, I use Mathematica and sollya and I don't need a plug-in for it.
The problem is that is comes down to a kit of pieces collected from everywhere and all the IDE vendors using Eclipse are simply doing integration work. It's much like creating a Linux distribution, I suppose--take bit from here and there, remix, and serve. How many commercial Eclipse-based IDEs for ARM do we have now?
* Code Red's RedSuite
* CodeSourcery [aka Mentor now]
* Altium / Tasking
* TI's Code Composer Studio
* Attolic TrueSTUDIO
* Freescale's CodeWarrior
* ARM DS
These are all vendor supplied and all are different. Assume I want new support for LPC1700s and I have Code Compose Studio--where do I go to get the plug-in support for that? Oh, I can't? Right, I need another Eclipse toolset for that? Ok, now I need to develop for Atmel's ARM9--which Eclipse toolset do I need for that?
Given that these are all nicely written in portable Java, how come they don't run on all the standard operating systems across the board, like Windows, Linux, OS X, and Solaris and support for all the standard debug probes that you can acquire?
Eclipse don't have any cohesion, is clunky, and I hate using it. I use it frequently for XMOS development in XC. I hate every single moment of it, and I know I'm not alone.
In the end, it's just preference and IDE wars.
>
> On Fri, Mar 30, 2012 at 3:32 AM, wrote:
>> Code Red on the LPCXpresso is noticeably slower, probably due to it being
>> written in Java.
>
> Agreed that the LPCXpresso debugging is slow, but I wouldn't necessarily say it's because of Java. Java can be every bit as fast as C++. It may be the case that the Red Probe is much faster. I can't say either way though, of course, so it's a risk.
>
These are based on FTDI FT2232 devices, typically. One of the things that such devices do not do well is read target memory. Great in the other direction, writing is fast, but not reading.
> On Fri, Mar 30, 2012 at 3:32 AM, wrote:
>> CrossWorks libraries are lean and mean, and I have never encountered a bug
>> in them. Code Red supports their own libary (forget what it's called) and
>> Newlib. Newlib is a pig -- it pulls in so much code it's ridiculous.
>
> To be fair, there was very little difference between Code Red's library and Rowley's library in terms of performance and size when I tried it. You don't have to use newlib with Code Red, they just provide it.
>
You know, I think there is a difference.
-- Paul.
Reply by ●March 30, 20122012-03-30
I don't know that you absolutely need plug-ins for Eclipse. For quite a
long time I got along fine with ISP and didn't use JTAG at all.
That's changed for the better now that I use CrossWorks and CrossConnect
but I can still get the code written using Eclipse as a simple editor/project
manager.
All Eclipse really does is invoke some external 'make' process so it doesn't care if I'm doing PC, ARM, PIC, AVR, Blackfin or whatever. As long as I don't need the capabilities of JTAG, Eclipse works fine as just a naked IDE.
Here's another IDE: Microsoft Visual Studio Express 2010 will also allow you to run external makefiles. I was messing around with the Digilent Cerebot MX4CK for its USB capabilities and I just used MVSE to combine the PIC32 work with the Windows C work on the host end. Now all of the code is in one place. Very nice...
http://digilentinc.com/Products/Detail.cfm?NavPath=2,396,985&ProdEBOT-MX4CK
If you really want to get ARM work done in a hurry (and use JTAG, etc) then CrossWorks/CrossConnect is a great way to do it. Not only that, the IDE just looks good. The bigger the screen, the better. Multiple screens would be even better!
Richard
All Eclipse really does is invoke some external 'make' process so it doesn't care if I'm doing PC, ARM, PIC, AVR, Blackfin or whatever. As long as I don't need the capabilities of JTAG, Eclipse works fine as just a naked IDE.
Here's another IDE: Microsoft Visual Studio Express 2010 will also allow you to run external makefiles. I was messing around with the Digilent Cerebot MX4CK for its USB capabilities and I just used MVSE to combine the PIC32 work with the Windows C work on the host end. Now all of the code is in one place. Very nice...
http://digilentinc.com/Products/Detail.cfm?NavPath=2,396,985&ProdEBOT-MX4CK
If you really want to get ARM work done in a hurry (and use JTAG, etc) then CrossWorks/CrossConnect is a great way to do it. Not only that, the IDE just looks good. The bigger the screen, the better. Multiple screens would be even better!
Richard
Reply by ●March 31, 20122012-03-31
Hi All
I wonder how many IDE threads there have been? Usually started by someone who wants to pinch a few pennies by pointing out how fantastic Eclipe is and how it contains everything that anyone could ever want so that IDE manufacturer's - who are shameless enough to ask for some payment for their services - are presumably embaressed into admitting their fault and giving things away free too(?)
Eclipse does work, but I have to admit that my heart sinks each time I hear that it is chosen for the next project (the only good point is that no one complains when you are found taking a quick sleep between single-steps or a walk around the block while waiting for a download to compete - exagerated of course, but some of them are quite tedious).
For any hobbist who doesn't care about developing but loves to tinker with the IDE then Eclipse is perfect. However the hobby version of Crossworks is so cheap and so much more productive that any real aspiring professionals should have no second thoughts about spending a little pocket money for practicing with "professional tools".
I used ATMELS AVR32 studio for about 3 years on some professional projects. In each case it was dropped because it was more efficient to build and download with a bat file and debug with prinf() outputs than try to get the debugger to do anything sensible. Their new VisualStudio solution is however very useable - it actually works (quite well) and the editor is world-class; it does however show how these things polarize - other people I know are so angry with ATMEL for the change and just hate everything about the new environment (I still don't understand how they actually used the old one though because it can't even display CPU register contents as hex. values - you need to plug the decimal values that are displayed into a calculator to get them in hex (or use some other tricks) - and this after [presumably] millions of man-hours development...).
The other argumant is that an IDE should also run under Linux. This is strange since ATOLLIC don't make a package for Linux - they also state at their presentations that their research shows that everyone uses Windows for embedded development and that is why they decided on this. (In fact no one at any of the presentations/training courses did have a laptop that was running Linux rather than Windows - and no one complained at any training days that I attended - so maybe they do have a bit of a point... On top of that, when I have worked with developers using Linux boxes they tend to have their Windows based tools running on a virtual machine and the speed is comparable with Eclipse running in native mode (with Java of couse)).
I think that it is in fact very simple to finally put an end to all these discussions:
- Someone should just take Eclipse, make a package with all plug-ins and compiler chains for all processors (existing and future), sort out all existing bugs, improve any weaknesses, optimise the speed, write a good set of documentation, optimise all GCC libraries, make sure that all possible debuggers work well, put the result on a web site for (free) public download, publish their email address and mobile telephone number in case anyone has any problems and offer fast-response, round-the-clock service.
That would sort out all issues and show that the IDE companies were really a waste of space in the first place.
In the mean time I would just use Rowley; you can't go wrong with it ;-)
Regards
Mark
I wonder how many IDE threads there have been? Usually started by someone who wants to pinch a few pennies by pointing out how fantastic Eclipe is and how it contains everything that anyone could ever want so that IDE manufacturer's - who are shameless enough to ask for some payment for their services - are presumably embaressed into admitting their fault and giving things away free too(?)
Eclipse does work, but I have to admit that my heart sinks each time I hear that it is chosen for the next project (the only good point is that no one complains when you are found taking a quick sleep between single-steps or a walk around the block while waiting for a download to compete - exagerated of course, but some of them are quite tedious).
For any hobbist who doesn't care about developing but loves to tinker with the IDE then Eclipse is perfect. However the hobby version of Crossworks is so cheap and so much more productive that any real aspiring professionals should have no second thoughts about spending a little pocket money for practicing with "professional tools".
I used ATMELS AVR32 studio for about 3 years on some professional projects. In each case it was dropped because it was more efficient to build and download with a bat file and debug with prinf() outputs than try to get the debugger to do anything sensible. Their new VisualStudio solution is however very useable - it actually works (quite well) and the editor is world-class; it does however show how these things polarize - other people I know are so angry with ATMEL for the change and just hate everything about the new environment (I still don't understand how they actually used the old one though because it can't even display CPU register contents as hex. values - you need to plug the decimal values that are displayed into a calculator to get them in hex (or use some other tricks) - and this after [presumably] millions of man-hours development...).
The other argumant is that an IDE should also run under Linux. This is strange since ATOLLIC don't make a package for Linux - they also state at their presentations that their research shows that everyone uses Windows for embedded development and that is why they decided on this. (In fact no one at any of the presentations/training courses did have a laptop that was running Linux rather than Windows - and no one complained at any training days that I attended - so maybe they do have a bit of a point... On top of that, when I have worked with developers using Linux boxes they tend to have their Windows based tools running on a virtual machine and the speed is comparable with Eclipse running in native mode (with Java of couse)).
I think that it is in fact very simple to finally put an end to all these discussions:
- Someone should just take Eclipse, make a package with all plug-ins and compiler chains for all processors (existing and future), sort out all existing bugs, improve any weaknesses, optimise the speed, write a good set of documentation, optimise all GCC libraries, make sure that all possible debuggers work well, put the result on a web site for (free) public download, publish their email address and mobile telephone number in case anyone has any problems and offer fast-response, round-the-clock service.
That would sort out all issues and show that the IDE companies were really a waste of space in the first place.
In the mean time I would just use Rowley; you can't go wrong with it ;-)
Regards
Mark
Reply by ●March 31, 20122012-03-31
You forgot to mention it being written in Java, always time to make a cup of
tea when it decides to do garbage collection.
But I couldn't agree more, you get what you pay for.
Personally I use Keil, but all editing and syntax debugging is always done
in VS, and usually most of the actual debugging too using virtual models.
VS has some fantastic plug-ins available ( sadly not free, but value for
money ), in particular VisualSVN and VisualAssistX ( probably the best add
in ever ).
The one thing I do like about Keil is the compilers are generally very good
and the libraries provide load time decompression which keeps images small,
however the support from ARM for bug fixes in the debugger leaves a bit to
be desired.
Using the device models in simulation is a real benefit so I hope NXP bring
out the versions for the LPC4350 soon.
Regards
Phil.
From: l... [mailto:l...] On Behalf Of
Mark
Sent: 31 March 2012 14:44
To: l...
Subject: [lpc2000] Re: ARM Development Tools
Hi All
I wonder how many IDE threads there have been? Usually started by someone
who wants to pinch a few pennies by pointing out how fantastic Eclipe is and
how it contains everything that anyone could ever want so that IDE
manufacturer's - who are shameless enough to ask for some payment for their
services - are presumably embaressed into admitting their fault and giving
things away free too(?)
Eclipse does work, but I have to admit that my heart sinks each time I hear
that it is chosen for the next project (the only good point is that no one
complains when you are found taking a quick sleep between single-steps or a
walk around the block while waiting for a download to compete - exagerated
of course, but some of them are quite tedious).
For any hobbist who doesn't care about developing but loves to tinker with
the IDE then Eclipse is perfect. However the hobby version of Crossworks is
so cheap and so much more productive that any real aspiring professionals
should have no second thoughts about spending a little pocket money for
practicing with "professional tools".
I used ATMELS AVR32 studio for about 3 years on some professional projects.
In each case it was dropped because it was more efficient to build and
download with a bat file and debug with prinf() outputs than try to get the
debugger to do anything sensible. Their new VisualStudio solution is however
very useable - it actually works (quite well) and the editor is world-class;
it does however show how these things polarize - other people I know are so
angry with ATMEL for the change and just hate everything about the new
environment (I still don't understand how they actually used the old one
though because it can't even display CPU register contents as hex. values -
you need to plug the decimal values that are displayed into a calculator to
get them in hex (or use some other tricks) - and this after [presumably]
millions of man-hours development...).
The other argumant is that an IDE should also run under Linux. This is
strange since ATOLLIC don't make a package for Linux - they also state at
their presentations that their research shows that everyone uses Windows for
embedded development and that is why they decided on this. (In fact no one
at any of the presentations/training courses did have a laptop that was
running Linux rather than Windows - and no one complained at any training
days that I attended - so maybe they do have a bit of a point... On top of
that, when I have worked with developers using Linux boxes they tend to have
their Windows based tools running on a virtual machine and the speed is
comparable with Eclipse running in native mode (with Java of couse)).
I think that it is in fact very simple to finally put an end to all these
discussions:
- Someone should just take Eclipse, make a package with all plug-ins and
compiler chains for all processors (existing and future), sort out all
existing bugs, improve any weaknesses, optimise the speed, write a good set
of documentation, optimise all GCC libraries, make sure that all possible
debuggers work well, put the result on a web site for (free) public
download, publish their email address and mobile telephone number in case
anyone has any problems and offer fast-response, round-the-clock service.
That would sort out all issues and show that the IDE companies were really a
waste of space in the first place.
In the mean time I would just use Rowley; you can't go wrong with it ;-)
Regards
Mark
tea when it decides to do garbage collection.
But I couldn't agree more, you get what you pay for.
Personally I use Keil, but all editing and syntax debugging is always done
in VS, and usually most of the actual debugging too using virtual models.
VS has some fantastic plug-ins available ( sadly not free, but value for
money ), in particular VisualSVN and VisualAssistX ( probably the best add
in ever ).
The one thing I do like about Keil is the compilers are generally very good
and the libraries provide load time decompression which keeps images small,
however the support from ARM for bug fixes in the debugger leaves a bit to
be desired.
Using the device models in simulation is a real benefit so I hope NXP bring
out the versions for the LPC4350 soon.
Regards
Phil.
From: l... [mailto:l...] On Behalf Of
Mark
Sent: 31 March 2012 14:44
To: l...
Subject: [lpc2000] Re: ARM Development Tools
Hi All
I wonder how many IDE threads there have been? Usually started by someone
who wants to pinch a few pennies by pointing out how fantastic Eclipe is and
how it contains everything that anyone could ever want so that IDE
manufacturer's - who are shameless enough to ask for some payment for their
services - are presumably embaressed into admitting their fault and giving
things away free too(?)
Eclipse does work, but I have to admit that my heart sinks each time I hear
that it is chosen for the next project (the only good point is that no one
complains when you are found taking a quick sleep between single-steps or a
walk around the block while waiting for a download to compete - exagerated
of course, but some of them are quite tedious).
For any hobbist who doesn't care about developing but loves to tinker with
the IDE then Eclipse is perfect. However the hobby version of Crossworks is
so cheap and so much more productive that any real aspiring professionals
should have no second thoughts about spending a little pocket money for
practicing with "professional tools".
I used ATMELS AVR32 studio for about 3 years on some professional projects.
In each case it was dropped because it was more efficient to build and
download with a bat file and debug with prinf() outputs than try to get the
debugger to do anything sensible. Their new VisualStudio solution is however
very useable - it actually works (quite well) and the editor is world-class;
it does however show how these things polarize - other people I know are so
angry with ATMEL for the change and just hate everything about the new
environment (I still don't understand how they actually used the old one
though because it can't even display CPU register contents as hex. values -
you need to plug the decimal values that are displayed into a calculator to
get them in hex (or use some other tricks) - and this after [presumably]
millions of man-hours development...).
The other argumant is that an IDE should also run under Linux. This is
strange since ATOLLIC don't make a package for Linux - they also state at
their presentations that their research shows that everyone uses Windows for
embedded development and that is why they decided on this. (In fact no one
at any of the presentations/training courses did have a laptop that was
running Linux rather than Windows - and no one complained at any training
days that I attended - so maybe they do have a bit of a point... On top of
that, when I have worked with developers using Linux boxes they tend to have
their Windows based tools running on a virtual machine and the speed is
comparable with Eclipse running in native mode (with Java of couse)).
I think that it is in fact very simple to finally put an end to all these
discussions:
- Someone should just take Eclipse, make a package with all plug-ins and
compiler chains for all processors (existing and future), sort out all
existing bugs, improve any weaknesses, optimise the speed, write a good set
of documentation, optimise all GCC libraries, make sure that all possible
debuggers work well, put the result on a web site for (free) public
download, publish their email address and mobile telephone number in case
anyone has any problems and offer fast-response, round-the-clock service.
That would sort out all issues and show that the IDE companies were really a
waste of space in the first place.
In the mean time I would just use Rowley; you can't go wrong with it ;-)
Regards
Mark
Reply by ●March 31, 20122012-03-31
On 3/31/2012 9:09 AM, Phil Young wrote:
>
> You forgot to mention it being written in Java, always time to make a
> cup of
> tea when it decides to do garbage collection.
>
> But I couldn't agree more, you get what you pay for.
>
> Personally I use Keil, but all editing and syntax debugging is always done
> in VS, and usually most of the actual debugging too using virtual models.
>
> VS has some fantastic plug-ins available ( sadly not free, but value for
> money ), in particular VisualSVN and VisualAssistX ( probably the best add
> in ever ).
>
> The one thing I do like about Keil is the compilers are generally very
> good
> and the libraries provide load time decompression which keeps images
> small,
> however the support from ARM for bug fixes in the debugger leaves a bit to
> be desired.
>
> Using the device models in simulation is a real benefit so I hope NXP
> bring
> out the versions for the LPC4350 soon.
>
> Regards
>
> Phil.
>
For the one person in 100 who didn't know Visual studio would compile
code for ARM processors. See:
Howard
>
> You forgot to mention it being written in Java, always time to make a
> cup of
> tea when it decides to do garbage collection.
>
> But I couldn't agree more, you get what you pay for.
>
> Personally I use Keil, but all editing and syntax debugging is always done
> in VS, and usually most of the actual debugging too using virtual models.
>
> VS has some fantastic plug-ins available ( sadly not free, but value for
> money ), in particular VisualSVN and VisualAssistX ( probably the best add
> in ever ).
>
> The one thing I do like about Keil is the compilers are generally very
> good
> and the libraries provide load time decompression which keeps images
> small,
> however the support from ARM for bug fixes in the debugger leaves a bit to
> be desired.
>
> Using the device models in simulation is a real benefit so I hope NXP
> bring
> out the versions for the LPC4350 soon.
>
> Regards
>
> Phil.
>
For the one person in 100 who didn't know Visual studio would compile
code for ARM processors. See:
Howard
Reply by ●March 31, 20122012-03-31
Thanks Howard.
We did this in the past for the ARC processor also, unfortunately though
it's difficult to use for embedded systems and we always ended up building
the code for debugging in the manufacturers IDE. ( Actually Greenhills IDE,
but with Metaware compilers ).
The issue is with the particular instruction set options and startup code
which are specific to the core variant and co-processor options.
I'm currently building the same multi-core project to run in VS ( virtual
environment ), LPC4350, and dual LPC1758 processors, and any combination of
the above.
The beauty of the keil environment is that all the required startup code for
each processor is provided by the company who designed the core, and I
simply have to select the core variant for the compiler to know exactly what
options are available. ( have you tried configuring a compiler for the FPU
on 4350 yet?. )
But the real reason for selecting Keil ( after starting with Code Red ) was
the efficient library support and small code size, particularly for some of
my M0 projects where FLASH / RAM size are at a premium, and the load time
decompression is an excellent feature.
Regards
Phil.
From: l... [mailto:l...] On Behalf Of
Howard Hansen
Sent: 31 March 2012 17:22
To: l...
Subject: Re: [lpc2000] Re: ARM Development Tools
On 3/31/2012 9:09 AM, Phil Young wrote:
>
> You forgot to mention it being written in Java, always time to make a
> cup of
> tea when it decides to do garbage collection.
>
> But I couldn't agree more, you get what you pay for.
>
> Personally I use Keil, but all editing and syntax debugging is always done
> in VS, and usually most of the actual debugging too using virtual models.
>
> VS has some fantastic plug-ins available ( sadly not free, but value for
> money ), in particular VisualSVN and VisualAssistX ( probably the best add
> in ever ).
>
> The one thing I do like about Keil is the compilers are generally very
> good
> and the libraries provide load time decompression which keeps images
> small,
> however the support from ARM for bug fixes in the debugger leaves a bit to
> be desired.
>
> Using the device models in simulation is a real benefit so I hope NXP
> bring
> out the versions for the LPC4350 soon.
>
> Regards
>
> Phil.
>
For the one person in 100 who didn't know Visual studio would compile
code for ARM processors. See:
Howard
We did this in the past for the ARC processor also, unfortunately though
it's difficult to use for embedded systems and we always ended up building
the code for debugging in the manufacturers IDE. ( Actually Greenhills IDE,
but with Metaware compilers ).
The issue is with the particular instruction set options and startup code
which are specific to the core variant and co-processor options.
I'm currently building the same multi-core project to run in VS ( virtual
environment ), LPC4350, and dual LPC1758 processors, and any combination of
the above.
The beauty of the keil environment is that all the required startup code for
each processor is provided by the company who designed the core, and I
simply have to select the core variant for the compiler to know exactly what
options are available. ( have you tried configuring a compiler for the FPU
on 4350 yet?. )
But the real reason for selecting Keil ( after starting with Code Red ) was
the efficient library support and small code size, particularly for some of
my M0 projects where FLASH / RAM size are at a premium, and the load time
decompression is an excellent feature.
Regards
Phil.
From: l... [mailto:l...] On Behalf Of
Howard Hansen
Sent: 31 March 2012 17:22
To: l...
Subject: Re: [lpc2000] Re: ARM Development Tools
On 3/31/2012 9:09 AM, Phil Young wrote:
>
> You forgot to mention it being written in Java, always time to make a
> cup of
> tea when it decides to do garbage collection.
>
> But I couldn't agree more, you get what you pay for.
>
> Personally I use Keil, but all editing and syntax debugging is always done
> in VS, and usually most of the actual debugging too using virtual models.
>
> VS has some fantastic plug-ins available ( sadly not free, but value for
> money ), in particular VisualSVN and VisualAssistX ( probably the best add
> in ever ).
>
> The one thing I do like about Keil is the compilers are generally very
> good
> and the libraries provide load time decompression which keeps images
> small,
> however the support from ARM for bug fixes in the debugger leaves a bit to
> be desired.
>
> Using the device models in simulation is a real benefit so I hope NXP
> bring
> out the versions for the LPC4350 soon.
>
> Regards
>
> Phil.
>
For the one person in 100 who didn't know Visual studio would compile
code for ARM processors. See:
Howard
Reply by ●March 31, 20122012-03-31
--- In l..., Howard Hansen wrote:
> For the one person in 100 who didn't know Visual studio would compile
> code for ARM processors. See:
I've used VS to compile and debug AVR32 code, and it works quite well for this. Atmel switched to VS with AVR Studio 5, which elicited a sigh of relief from many using Eclipse-based AVR32 Studio, and hatred from others who think Microsoft, and hence, VS, are the devil incarnate.
Too bad the AVR32 is a niche MCU from a single vendor as it has a lot to like about it. It doesn't help that Atmel's support for it is half-hearted at best.
Atmel renamed AVR Studio to Atmel Studio when they went to version 6 as version 6 now supports Atmel's ARM processors in addition to the 8 and 16 bit AVRs.
> For the one person in 100 who didn't know Visual studio would compile
> code for ARM processors. See:
I've used VS to compile and debug AVR32 code, and it works quite well for this. Atmel switched to VS with AVR Studio 5, which elicited a sigh of relief from many using Eclipse-based AVR32 Studio, and hatred from others who think Microsoft, and hence, VS, are the devil incarnate.
Too bad the AVR32 is a niche MCU from a single vendor as it has a lot to like about it. It doesn't help that Atmel's support for it is half-hearted at best.
Atmel renamed AVR Studio to Atmel Studio when they went to version 6 as version 6 now supports Atmel's ARM processors in addition to the 8 and 16 bit AVRs.
Reply by ●April 1, 20122012-04-01
Reply by ●April 1, 20122012-04-01
hi,
I LIKE KEIL.
Thanks & Regards,
P. ALAGAPPAN
VASEE ELECTRONICS, SALIGRAMAM, CHENNAI -93. www.vaseee.com
--- On Sun, 1/4/12, Steve Childress wrote:
From: Steve Childress
Subject: [lpc2000] Re: ARM Development Tools
To: l...
Date: Sunday, 1 April, 2012, 1:04 PM
Did you consider IAR and Keil?
And if your target is an Atmel ARM, Atmel Studio 6 (free)
I LIKE KEIL.
Thanks & Regards,
P. ALAGAPPAN
VASEE ELECTRONICS, SALIGRAMAM, CHENNAI -93. www.vaseee.com
--- On Sun, 1/4/12, Steve Childress wrote:
From: Steve Childress
Subject: [lpc2000] Re: ARM Development Tools
To: l...
Date: Sunday, 1 April, 2012, 1:04 PM
Did you consider IAR and Keil?
And if your target is an Atmel ARM, Atmel Studio 6 (free)
