--- In l..., "M. Manca" wrote:
> Richard,
> I asked you if you think to pay $500 for a networking library like the
> Microchip. So I mean with similar documentation and examples.
I think that $500 is pretty meaningless in terms of product development. I
wouldn't even get up and drive to a day's work for that kind of money.
After taxes, I wouldn't even see $300 of it so why bother?
But I also think a commercial, unlimited license, protocol stack with source and
documentation is probably going to be a bit more than $500 by the time royalties
are included.
But, true, $500 is pocket change in terms of development costs.
Richard
ARM Development Tools
Started by ●March 29, 2012
Reply by ●April 2, 20122012-04-02
Reply by ●April 2, 20122012-04-02
Hi
Interesting. The uTasker project is available as commerical license for less that $500 including full support for 3 months (or for 12 months for a few hundred more). These are royalty free and include TCP/IP (IPv4/IPv6 dual stack), USB, FAT and various other stacks for NXP, Freescale, ST, TI and ATMEL parts.
As developer on the project I support several hundred commerical uses (developing on various devices with a range of IDEs) and also several thousand registers 'non-commerical/hobby' users who get the SW, tools and support for free.
It can be hard work at times keeping up with the support requests but generally doesn't cause any real problems - support requests show weaknesses (in code or documentation) and result in improvements which further improve efficiency and can benefit everyone (and reduce future support load at the same time). On the whole users are very understanding that they haven't bought any one's soul with their $500 - they get many man-years investment in code and experience to start benefiting from on day one and are usually grateful enough to not pester with anything that is not serious. However they know that they can bank on fast help and solutions in case of any difficulties that are encountered (like preferential email support, telephone conferencing or project testing on most standard development boards).
As soon as the support scope extends to subjects that are clearly not part of the 'package' most are very willing to pay a donation to the project or a couple of hours 'consultancy' fee - at the end every one is happy; the project in question has usually made good progress and it is a win-win for both sides with a fast, informal solution.
If the software in question is not of poor quality and not overcomplicated for engineers to start with and solve their problems with I would suggest that the support side is very manageable (after several years of experince doing just this) and good support tends to result in more positive effects than negative loads on resources (of course this is not a blanket statement because it is probably not the same in all operating domains).
Regards
Mark
http://www.uTasker.com
--- In l..., "Phil Young" wrote:
>
> On the subject of how much support for $500, I would answer NONE.
>
> In the commercial world you would get object code for that, and support
> would normally be at least as expensive and limited in scope, duration, and
> responsiveness by the amount you pay and your importance as an ongoing
> customer.
>
>
>
> SW support is an expensive thing to provide so support contracts are
> generally very expensive, partly to cover the costs and partly to deter
> everybody from taking one out.
>
>
>
> SW support almost always places a heavy burden on the development team as
> well as the support team, so it's highly undesirable to sell lots of support
> licences, these should be limited to the customers which matter, i.e. those
> that buy many licenses and pay ongoing royalties.
>
>
>
> In this world I'd rather not have the business from small companies than
> have to provide support to them, it's important for the development team to
> be developing new features / products, not held up in thousands of support
> issues.
>
>
>
> Companies that fail to realize this don't tend to last that long.
>
>
>
> Regards
>
>
>
> Phil.
>
>
>
>
>
> From: l... [mailto:l...] On Behalf Of
> rtstofer
> Sent: 02 April 2012 14:39
> To: l...
> Subject: [lpc2000] Re: ARM Development Tools
>
>
>
>
>
> --- In l... , "M.
> Manca" wrote:
> > Yes, correct approach for a hobby project. Do you think you will use the
> > same approach for a professional project? I mean should you buy a
> > professional source code library assuming its cost is compatible with
> > your budget? For example: assuming a 100K source code library and 1 year
> > development as in your example, the development cost (I have a statistic
> > from Standish Group of 15$-40$ for SLOC in embedded development)
> > assuming a lower 10$/SLOC may be 1 million dollar and so a market price
> > may be $500. Should you buy the same library at $500? Just to be more
> > clear: should you buy a professional library equivalent to Microchip
> > networking stack for $500?
>
> That's difficult to say!
>
> How much support could I expect to get for a $500 library? On an individual
> basis, I am only worth $500 to the supplier (assuming they don't want a
> per-unit royalty) and they already have my money.
>
> Then there is the issue of source code. Sometimes all you get is a linkable
> library. If it works, great! If not, you can't even try to fix it. Perhaps,
> one day, the supplier will fix it. Or not...
>
> If the Microchip stack does all the functions required for a project, is
> professionally written (and it is), is 'free' on some basis with source code
> and abundant documentation, why not give it a try? Worst case, you have a
> fast mock-up of the project. The stack can always be replaced.
>
> Richard
>
>
>
Interesting. The uTasker project is available as commerical license for less that $500 including full support for 3 months (or for 12 months for a few hundred more). These are royalty free and include TCP/IP (IPv4/IPv6 dual stack), USB, FAT and various other stacks for NXP, Freescale, ST, TI and ATMEL parts.
As developer on the project I support several hundred commerical uses (developing on various devices with a range of IDEs) and also several thousand registers 'non-commerical/hobby' users who get the SW, tools and support for free.
It can be hard work at times keeping up with the support requests but generally doesn't cause any real problems - support requests show weaknesses (in code or documentation) and result in improvements which further improve efficiency and can benefit everyone (and reduce future support load at the same time). On the whole users are very understanding that they haven't bought any one's soul with their $500 - they get many man-years investment in code and experience to start benefiting from on day one and are usually grateful enough to not pester with anything that is not serious. However they know that they can bank on fast help and solutions in case of any difficulties that are encountered (like preferential email support, telephone conferencing or project testing on most standard development boards).
As soon as the support scope extends to subjects that are clearly not part of the 'package' most are very willing to pay a donation to the project or a couple of hours 'consultancy' fee - at the end every one is happy; the project in question has usually made good progress and it is a win-win for both sides with a fast, informal solution.
If the software in question is not of poor quality and not overcomplicated for engineers to start with and solve their problems with I would suggest that the support side is very manageable (after several years of experince doing just this) and good support tends to result in more positive effects than negative loads on resources (of course this is not a blanket statement because it is probably not the same in all operating domains).
Regards
Mark
http://www.uTasker.com
--- In l..., "Phil Young" wrote:
>
> On the subject of how much support for $500, I would answer NONE.
>
> In the commercial world you would get object code for that, and support
> would normally be at least as expensive and limited in scope, duration, and
> responsiveness by the amount you pay and your importance as an ongoing
> customer.
>
>
>
> SW support is an expensive thing to provide so support contracts are
> generally very expensive, partly to cover the costs and partly to deter
> everybody from taking one out.
>
>
>
> SW support almost always places a heavy burden on the development team as
> well as the support team, so it's highly undesirable to sell lots of support
> licences, these should be limited to the customers which matter, i.e. those
> that buy many licenses and pay ongoing royalties.
>
>
>
> In this world I'd rather not have the business from small companies than
> have to provide support to them, it's important for the development team to
> be developing new features / products, not held up in thousands of support
> issues.
>
>
>
> Companies that fail to realize this don't tend to last that long.
>
>
>
> Regards
>
>
>
> Phil.
>
>
>
>
>
> From: l... [mailto:l...] On Behalf Of
> rtstofer
> Sent: 02 April 2012 14:39
> To: l...
> Subject: [lpc2000] Re: ARM Development Tools
>
>
>
>
>
> --- In l... , "M.
> Manca" wrote:
> > Yes, correct approach for a hobby project. Do you think you will use the
> > same approach for a professional project? I mean should you buy a
> > professional source code library assuming its cost is compatible with
> > your budget? For example: assuming a 100K source code library and 1 year
> > development as in your example, the development cost (I have a statistic
> > from Standish Group of 15$-40$ for SLOC in embedded development)
> > assuming a lower 10$/SLOC may be 1 million dollar and so a market price
> > may be $500. Should you buy the same library at $500? Just to be more
> > clear: should you buy a professional library equivalent to Microchip
> > networking stack for $500?
>
> That's difficult to say!
>
> How much support could I expect to get for a $500 library? On an individual
> basis, I am only worth $500 to the supplier (assuming they don't want a
> per-unit royalty) and they already have my money.
>
> Then there is the issue of source code. Sometimes all you get is a linkable
> library. If it works, great! If not, you can't even try to fix it. Perhaps,
> one day, the supplier will fix it. Or not...
>
> If the Microchip stack does all the functions required for a project, is
> professionally written (and it is), is 'free' on some basis with source code
> and abundant documentation, why not give it a try? Worst case, you have a
> fast mock-up of the project. The stack can always be replaced.
>
> Richard
>
>
>
Reply by ●April 2, 20122012-04-02
The difference here is you are supporting a mature product, with different
variants, and not trying to fund development of new technology.
Supporting an RTOS and network protocol stack is quite different from
supporting new technologies in both SW and HW.
Employing apps engineers and training them takes a lot of time and money,
and a huge amount of time is taken up supporting new devices through the
complete development cycle from initial concept to volume production.
As a silicon vendor the apps engineers are involved in every stage of the
project from initial device selection through to supporting volume
manufacture, and most of the time on new products with new bugs to be
identified etc.
By the time the uTasker project is supporting these devices they have
generally moved well past that stage, and your support is inevitable
somewhat limited in scope compared to the support that a silicon vendor
needs to provide.
Employing an FAE, providing equipment and training etc costs a lot, if the
typical FAE salary is for example $100k then you need to double or treble
this for the actual cost of employing them.
For silicon vendors, which are all multinational companies it involves huge
costs in travel alone since FAE's generally need to travel frequently to the
customer and design centres, most of which involves international travel.
I know from experience that when I was doing this job I spent 20 weeks in 1
year overseas in Japan, US, and Europe, this is ridiculously expensive and
has to be accounted for in the sales of the product.
So it's not about poor quality SW, but the role of an AE / FAE is very
different to what you are doing, $500 would not cover a days work.
Regards
Phil.
From: l... [mailto:l...] On Behalf Of
Mark
Sent: 02 April 2012 21:05
To: l...
Subject: [lpc2000] Re: ARM Development Tools
Hi
Interesting. The uTasker project is available as commerical license for less
that $500 including full support for 3 months (or for 12 months for a few
hundred more). These are royalty free and include TCP/IP (IPv4/IPv6 dual
stack), USB, FAT and various other stacks for NXP, Freescale, ST, TI and
ATMEL parts.
As developer on the project I support several hundred commerical uses
(developing on various devices with a range of IDEs) and also several
thousand registers 'non-commerical/hobby' users who get the SW, tools and
support for free.
It can be hard work at times keeping up with the support requests but
generally doesn't cause any real problems - support requests show weaknesses
(in code or documentation) and result in improvements which further improve
efficiency and can benefit everyone (and reduce future support load at the
same time). On the whole users are very understanding that they haven't
bought any one's soul with their $500 - they get many man-years investment
in code and experience to start benefiting from on day one and are usually
grateful enough to not pester with anything that is not serious. However
they know that they can bank on fast help and solutions in case of any
difficulties that are encountered (like preferential email support,
telephone conferencing or project testing on most standard development
boards).
As soon as the support scope extends to subjects that are clearly not part
of the 'package' most are very willing to pay a donation to the project or a
couple of hours 'consultancy' fee - at the end every one is happy; the
project in question has usually made good progress and it is a win-win for
both sides with a fast, informal solution.
If the software in question is not of poor quality and not overcomplicated
for engineers to start with and solve their problems with I would suggest
that the support side is very manageable (after several years of experince
doing just this) and good support tends to result in more positive effects
than negative loads on resources (of course this is not a blanket statement
because it is probably not the same in all operating domains).
Regards
Mark
http://www.uTasker.com
--- In l... , "Phil
Young" wrote:
>
> On the subject of how much support for $500, I would answer NONE.
>
> In the commercial world you would get object code for that, and support
> would normally be at least as expensive and limited in scope, duration,
and
> responsiveness by the amount you pay and your importance as an ongoing
> customer.
>
> SW support is an expensive thing to provide so support contracts are
> generally very expensive, partly to cover the costs and partly to deter
> everybody from taking one out.
>
> SW support almost always places a heavy burden on the development team as
> well as the support team, so it's highly undesirable to sell lots of
support
> licences, these should be limited to the customers which matter, i.e.
those
> that buy many licenses and pay ongoing royalties.
>
> In this world I'd rather not have the business from small companies than
> have to provide support to them, it's important for the development team
to
> be developing new features / products, not held up in thousands of support
> issues.
>
> Companies that fail to realize this don't tend to last that long.
>
> Regards
>
> Phil.
>
> From: l...
[mailto:l... ] On
Behalf Of
> rtstofer
> Sent: 02 April 2012 14:39
> To: l...
> Subject: [lpc2000] Re: ARM Development Tools
>
> --- In l...
, "M.
> Manca" wrote:
> > Yes, correct approach for a hobby project. Do you think you will use the
> > same approach for a professional project? I mean should you buy a
> > professional source code library assuming its cost is compatible with
> > your budget? For example: assuming a 100K source code library and 1 year
> > development as in your example, the development cost (I have a statistic
> > from Standish Group of 15$-40$ for SLOC in embedded development)
> > assuming a lower 10$/SLOC may be 1 million dollar and so a market price
> > may be $500. Should you buy the same library at $500? Just to be more
> > clear: should you buy a professional library equivalent to Microchip
> > networking stack for $500?
>
> That's difficult to say!
>
> How much support could I expect to get for a $500 library? On an
individual
> basis, I am only worth $500 to the supplier (assuming they don't want a
> per-unit royalty) and they already have my money.
>
> Then there is the issue of source code. Sometimes all you get is a
linkable
> library. If it works, great! If not, you can't even try to fix it.
Perhaps,
> one day, the supplier will fix it. Or not...
>
> If the Microchip stack does all the functions required for a project, is
> professionally written (and it is), is 'free' on some basis with source
code
> and abundant documentation, why not give it a try? Worst case, you have a
> fast mock-up of the project. The stack can always be replaced.
>
> Richard
>
>
>
variants, and not trying to fund development of new technology.
Supporting an RTOS and network protocol stack is quite different from
supporting new technologies in both SW and HW.
Employing apps engineers and training them takes a lot of time and money,
and a huge amount of time is taken up supporting new devices through the
complete development cycle from initial concept to volume production.
As a silicon vendor the apps engineers are involved in every stage of the
project from initial device selection through to supporting volume
manufacture, and most of the time on new products with new bugs to be
identified etc.
By the time the uTasker project is supporting these devices they have
generally moved well past that stage, and your support is inevitable
somewhat limited in scope compared to the support that a silicon vendor
needs to provide.
Employing an FAE, providing equipment and training etc costs a lot, if the
typical FAE salary is for example $100k then you need to double or treble
this for the actual cost of employing them.
For silicon vendors, which are all multinational companies it involves huge
costs in travel alone since FAE's generally need to travel frequently to the
customer and design centres, most of which involves international travel.
I know from experience that when I was doing this job I spent 20 weeks in 1
year overseas in Japan, US, and Europe, this is ridiculously expensive and
has to be accounted for in the sales of the product.
So it's not about poor quality SW, but the role of an AE / FAE is very
different to what you are doing, $500 would not cover a days work.
Regards
Phil.
From: l... [mailto:l...] On Behalf Of
Mark
Sent: 02 April 2012 21:05
To: l...
Subject: [lpc2000] Re: ARM Development Tools
Hi
Interesting. The uTasker project is available as commerical license for less
that $500 including full support for 3 months (or for 12 months for a few
hundred more). These are royalty free and include TCP/IP (IPv4/IPv6 dual
stack), USB, FAT and various other stacks for NXP, Freescale, ST, TI and
ATMEL parts.
As developer on the project I support several hundred commerical uses
(developing on various devices with a range of IDEs) and also several
thousand registers 'non-commerical/hobby' users who get the SW, tools and
support for free.
It can be hard work at times keeping up with the support requests but
generally doesn't cause any real problems - support requests show weaknesses
(in code or documentation) and result in improvements which further improve
efficiency and can benefit everyone (and reduce future support load at the
same time). On the whole users are very understanding that they haven't
bought any one's soul with their $500 - they get many man-years investment
in code and experience to start benefiting from on day one and are usually
grateful enough to not pester with anything that is not serious. However
they know that they can bank on fast help and solutions in case of any
difficulties that are encountered (like preferential email support,
telephone conferencing or project testing on most standard development
boards).
As soon as the support scope extends to subjects that are clearly not part
of the 'package' most are very willing to pay a donation to the project or a
couple of hours 'consultancy' fee - at the end every one is happy; the
project in question has usually made good progress and it is a win-win for
both sides with a fast, informal solution.
If the software in question is not of poor quality and not overcomplicated
for engineers to start with and solve their problems with I would suggest
that the support side is very manageable (after several years of experince
doing just this) and good support tends to result in more positive effects
than negative loads on resources (of course this is not a blanket statement
because it is probably not the same in all operating domains).
Regards
Mark
http://www.uTasker.com
--- In l... , "Phil
Young" wrote:
>
> On the subject of how much support for $500, I would answer NONE.
>
> In the commercial world you would get object code for that, and support
> would normally be at least as expensive and limited in scope, duration,
and
> responsiveness by the amount you pay and your importance as an ongoing
> customer.
>
> SW support is an expensive thing to provide so support contracts are
> generally very expensive, partly to cover the costs and partly to deter
> everybody from taking one out.
>
> SW support almost always places a heavy burden on the development team as
> well as the support team, so it's highly undesirable to sell lots of
support
> licences, these should be limited to the customers which matter, i.e.
those
> that buy many licenses and pay ongoing royalties.
>
> In this world I'd rather not have the business from small companies than
> have to provide support to them, it's important for the development team
to
> be developing new features / products, not held up in thousands of support
> issues.
>
> Companies that fail to realize this don't tend to last that long.
>
> Regards
>
> Phil.
>
> From: l...
[mailto:l... ] On
Behalf Of
> rtstofer
> Sent: 02 April 2012 14:39
> To: l...
> Subject: [lpc2000] Re: ARM Development Tools
>
> --- In l...
, "M.
> Manca" wrote:
> > Yes, correct approach for a hobby project. Do you think you will use the
> > same approach for a professional project? I mean should you buy a
> > professional source code library assuming its cost is compatible with
> > your budget? For example: assuming a 100K source code library and 1 year
> > development as in your example, the development cost (I have a statistic
> > from Standish Group of 15$-40$ for SLOC in embedded development)
> > assuming a lower 10$/SLOC may be 1 million dollar and so a market price
> > may be $500. Should you buy the same library at $500? Just to be more
> > clear: should you buy a professional library equivalent to Microchip
> > networking stack for $500?
>
> That's difficult to say!
>
> How much support could I expect to get for a $500 library? On an
individual
> basis, I am only worth $500 to the supplier (assuming they don't want a
> per-unit royalty) and they already have my money.
>
> Then there is the issue of source code. Sometimes all you get is a
linkable
> library. If it works, great! If not, you can't even try to fix it.
Perhaps,
> one day, the supplier will fix it. Or not...
>
> If the Microchip stack does all the functions required for a project, is
> professionally written (and it is), is 'free' on some basis with source
code
> and abundant documentation, why not give it a try? Worst case, you have a
> fast mock-up of the project. The stack can always be replaced.
>
> Richard
>
>
>
Reply by ●April 2, 20122012-04-02
On 02/04/2012 20:28, Mark wrote:
> Interesting. Are these the number of licenses "ever" sold or yearly? Are
> they for their Tasking IDE or their PCB design SW?
>
> Most customers will be on a subscription (new PCB design licences will
> be about $5..7k and substription maybe 1k a year). Altium Designer is a
> wonderful product and they need a big team to maintain and further
> develop it (as they do all the time). Didn't expect that they would have
> financial difficulties (maybe the management is the big expense as in
> many companies now-a-days?)
Those were the number of current licenses for Altium Designer, mentioned
in a company report a year or so ago. Basically, their main source of
income. They slashed their prices a couple of years ago, so they won't
be getting anything like $5k per license.
Leon
--
Leon Heller
G1HSM
> Interesting. Are these the number of licenses "ever" sold or yearly? Are
> they for their Tasking IDE or their PCB design SW?
>
> Most customers will be on a subscription (new PCB design licences will
> be about $5..7k and substription maybe 1k a year). Altium Designer is a
> wonderful product and they need a big team to maintain and further
> develop it (as they do all the time). Didn't expect that they would have
> financial difficulties (maybe the management is the big expense as in
> many companies now-a-days?)
Those were the number of current licenses for Altium Designer, mentioned
in a company report a year or so ago. Basically, their main source of
income. They slashed their prices a couple of years ago, so they won't
be getting anything like $5k per license.
Leon
--
Leon Heller
G1HSM
Reply by ●April 2, 20122012-04-02
--- In l..., Leon Heller wrote:
> I don't know about the Altium resellers, but Altium themselves have had
> severe financial problems for many years:
> They claim to have sold about 18,000 licenses. With 285 staff to pay I
> can't see how they manage to keep trading.
Maybe that's why, about a year ago, Altium packed up and moved, lock, stock, and barrel, from Australia, to Shanghai, China.
> I don't know about the Altium resellers, but Altium themselves have had
> severe financial problems for many years:
> They claim to have sold about 18,000 licenses. With 285 staff to pay I
> can't see how they manage to keep trading.
Maybe that's why, about a year ago, Altium packed up and moved, lock, stock, and barrel, from Australia, to Shanghai, China.
Reply by ●April 3, 20122012-04-03
On 03/04/2012 01:37, Jerry wrote:
> --- In l... , Leon
> Heller wrote:
> > I don't know about the Altium resellers, but Altium themselves have had
> > severe financial problems for many years:
> > They claim to have sold about 18,000 licenses. With 285 staff to pay I
> > can't see how they manage to keep trading.
>
> Maybe that's why, about a year ago, Altium packed up and moved, lock,
> stock, and barrel, from Australia, to Shanghai, China.
Yes, it was obviously to reduce their costs. They even tried offering an
amnesty to the vast number of Chinese using pirated copies, which might
have had more effect coming from a Chinese company.
Leon
--
Leon Heller
G1HSM
> --- In l... , Leon
> Heller wrote:
> > I don't know about the Altium resellers, but Altium themselves have had
> > severe financial problems for many years:
> > They claim to have sold about 18,000 licenses. With 285 staff to pay I
> > can't see how they manage to keep trading.
>
> Maybe that's why, about a year ago, Altium packed up and moved, lock,
> stock, and barrel, from Australia, to Shanghai, China.
Yes, it was obviously to reduce their costs. They even tried offering an
amnesty to the vast number of Chinese using pirated copies, which might
have had more effect coming from a Chinese company.
Leon
--
Leon Heller
G1HSM
Reply by ●April 4, 20122012-04-04
What an interesting turn of conversation.
Will be interesting to see how the embedded tool world evolved in the next
few years. Our compiler products are generally under $500, and we do
provide support, but we certainly work hard up front to make the support
issues as light as possible. I'd say every other month we would have a
"Paul Curtis Category 3" support request, but even those, once you calm
them down, usually do work out well.
The number of "bugs" reported versus real compiler bugs is probably 100:5.
--
// richard m: richard @imagecraft.com
Will be interesting to see how the embedded tool world evolved in the next
few years. Our compiler products are generally under $500, and we do
provide support, but we certainly work hard up front to make the support
issues as light as possible. I'd say every other month we would have a
"Paul Curtis Category 3" support request, but even those, once you calm
them down, usually do work out well.
The number of "bugs" reported versus real compiler bugs is probably 100:5.
--
// richard m: richard @imagecraft.com
Reply by ●April 17, 20122012-04-17
> Regarding Rowley
I have used in last 7 years, at work, for ARM based product development, the following IDE's - Rowley Crossworks, IAR EWARM, TI CCS4, Freescale CodeWarrior 10, & Mentor Code Sourcery/Bench.
The only 2 I will gladly use again are Rowley & IAR.
---------
Rowley Crossworks also seemed the best tool for 'debug' of embedded devices as it wasn't as flaky as the eclipse based tools and IMO was a little better debug experience day to day than IAR. IAR seems to build a little better code in benchmarks I've seen but I have not needed to squeeze CPU cycles for a while so the debug experience is what I rate as most important. Also $1500 < $5000 so while both tools are good Rowley is less expensive.
One thing with Eclipse based tools we have used is the whole 'sharing' of projects via SCM tool (SVN in our case) seems very hard to do smoothly. The .metadata directory has too big a mix between project and personal settings to be a good candidate for raw archiving and there was not a good rule of thumb we found to use across all Eclipse tools on what parts to save away. If you have more than a few developers on a project you might have some issues (or a lot of extra work) to make something that is bit for bit reproducible after changing PC's or several additional projects have occurred and you have to go back to do maintenance. If you can stick with one IDE and one product maybe you only have to learn the rules once so just a one time waste of resources but I'm betting figuring out this will cost you in some fashion close to $500 x N developers unless your N is large (or you force everyone to use exactly the same development environment).
Have not used CodeRed but last time I did an IDE eval it seemed CodeRed didn't support the extended ARM family as well as Rowley and IAR did. If you go to an chip outside NXP/TI/ST products you would have to switch tools. You probably never HAVE to use a chip not available from one of those vendors for most embedded products but something to consider.
If you are sure you will only use NXP chips then maybe the trace feature is enough to tip you to CodeRed even with the Eclipse issues. If it is as powerful as the Keil trace feature seems to be in demos it would catch my interest if I didn't have to support a wider range of chip vendors (and it wasn't Eclipse based ).
I have used in last 7 years, at work, for ARM based product development, the following IDE's - Rowley Crossworks, IAR EWARM, TI CCS4, Freescale CodeWarrior 10, & Mentor Code Sourcery/Bench.
The only 2 I will gladly use again are Rowley & IAR.
---------
Rowley Crossworks also seemed the best tool for 'debug' of embedded devices as it wasn't as flaky as the eclipse based tools and IMO was a little better debug experience day to day than IAR. IAR seems to build a little better code in benchmarks I've seen but I have not needed to squeeze CPU cycles for a while so the debug experience is what I rate as most important. Also $1500 < $5000 so while both tools are good Rowley is less expensive.
One thing with Eclipse based tools we have used is the whole 'sharing' of projects via SCM tool (SVN in our case) seems very hard to do smoothly. The .metadata directory has too big a mix between project and personal settings to be a good candidate for raw archiving and there was not a good rule of thumb we found to use across all Eclipse tools on what parts to save away. If you have more than a few developers on a project you might have some issues (or a lot of extra work) to make something that is bit for bit reproducible after changing PC's or several additional projects have occurred and you have to go back to do maintenance. If you can stick with one IDE and one product maybe you only have to learn the rules once so just a one time waste of resources but I'm betting figuring out this will cost you in some fashion close to $500 x N developers unless your N is large (or you force everyone to use exactly the same development environment).
Have not used CodeRed but last time I did an IDE eval it seemed CodeRed didn't support the extended ARM family as well as Rowley and IAR did. If you go to an chip outside NXP/TI/ST products you would have to switch tools. You probably never HAVE to use a chip not available from one of those vendors for most embedded products but something to consider.
If you are sure you will only use NXP chips then maybe the trace feature is enough to tip you to CodeRed even with the Eclipse issues. If it is as powerful as the Keil trace feature seems to be in demos it would catch my interest if I didn't have to support a wider range of chip vendors (and it wasn't Eclipse based ).
Reply by ●April 17, 20122012-04-17
We use IAR EWARM and LPC1766 and LPC2366 parts with the J-Link...
I just saw mentioned in the Segger catalog, this LPC Lite JTAG box.
Anybody know if it is actually available ?? I cannot seem to find it anywhere except in their PDF catalog...
2.6.7 NXP: J-Link Lite LPC Edition
J-Link Lite LPC Edition is an OEM version of J-Link, sold by NXP.
Limitations
J-Link Lite LPC Edition only works with NXP devices. This limitation
can NOT be lifted; if you would like to use J-Link with a
device from an other manufacturer, you need to buy a separate
J-Link.
Licenses
No licenses are included.
--- In l..., richard neveau wrote:
> > Regarding Rowley
> I have used in last 7 years, at work, for ARM based product development, the following IDE's - Rowley Crossworks, IAR EWARM, TI CCS4, Freescale CodeWarrior 10, & Mentor Code Sourcery/Bench.
> The only 2 I will gladly use again are Rowley & IAR.
> ---------
> Rowley Crossworks also seemed the best tool for 'debug' of embedded devices as it wasn't as flaky as the eclipse based tools and IMO was a little better debug experience day to day than IAR. IAR seems to build a little better code in benchmarks I've seen but I have not needed to squeeze CPU cycles for a while so the debug experience is what I rate as most important. Also $1500 < $5000 so while both tools are good Rowley is less expensive.
> One thing with Eclipse based tools we have used is the whole 'sharing' of projects via SCM tool (SVN in our case) seems very hard to do smoothly. The .metadata directory has too big a mix between project and personal settings to be a good candidate for raw archiving and there was not a good rule of thumb we found to use across all Eclipse tools on what parts to save away. If you have more than a few developers on a project you might have some issues (or a lot of extra work) to make something that is bit for bit reproducible after changing PC's or several additional projects have occurred and you have to go back to do maintenance. If you can stick with one IDE and one product maybe you only have to learn the rules once so just a one time waste of resources but I'm betting figuring out this will cost you in some fashion close to $500 x N developers unless your N is large (or you force everyone to use exactly the same development environment).
> Have not used CodeRed but last time I did an IDE eval it seemed CodeRed didn't support the extended ARM family as well as Rowley and IAR did. If you go to an chip outside NXP/TI/ST products you would have to switch tools. You probably never HAVE to use a chip not available from one of those vendors for most embedded products but something to consider.
> If you are sure you will only use NXP chips then maybe the trace feature is enough to tip you to CodeRed even with the Eclipse issues. If it is as powerful as the Keil trace feature seems to be in demos it would catch my interest if I didn't have to support a wider range of chip vendors (and it wasn't Eclipse based ).
I just saw mentioned in the Segger catalog, this LPC Lite JTAG box.
Anybody know if it is actually available ?? I cannot seem to find it anywhere except in their PDF catalog...
2.6.7 NXP: J-Link Lite LPC Edition
J-Link Lite LPC Edition is an OEM version of J-Link, sold by NXP.
Limitations
J-Link Lite LPC Edition only works with NXP devices. This limitation
can NOT be lifted; if you would like to use J-Link with a
device from an other manufacturer, you need to buy a separate
J-Link.
Licenses
No licenses are included.
--- In l..., richard neveau wrote:
> > Regarding Rowley
> I have used in last 7 years, at work, for ARM based product development, the following IDE's - Rowley Crossworks, IAR EWARM, TI CCS4, Freescale CodeWarrior 10, & Mentor Code Sourcery/Bench.
> The only 2 I will gladly use again are Rowley & IAR.
> ---------
> Rowley Crossworks also seemed the best tool for 'debug' of embedded devices as it wasn't as flaky as the eclipse based tools and IMO was a little better debug experience day to day than IAR. IAR seems to build a little better code in benchmarks I've seen but I have not needed to squeeze CPU cycles for a while so the debug experience is what I rate as most important. Also $1500 < $5000 so while both tools are good Rowley is less expensive.
> One thing with Eclipse based tools we have used is the whole 'sharing' of projects via SCM tool (SVN in our case) seems very hard to do smoothly. The .metadata directory has too big a mix between project and personal settings to be a good candidate for raw archiving and there was not a good rule of thumb we found to use across all Eclipse tools on what parts to save away. If you have more than a few developers on a project you might have some issues (or a lot of extra work) to make something that is bit for bit reproducible after changing PC's or several additional projects have occurred and you have to go back to do maintenance. If you can stick with one IDE and one product maybe you only have to learn the rules once so just a one time waste of resources but I'm betting figuring out this will cost you in some fashion close to $500 x N developers unless your N is large (or you force everyone to use exactly the same development environment).
> Have not used CodeRed but last time I did an IDE eval it seemed CodeRed didn't support the extended ARM family as well as Rowley and IAR did. If you go to an chip outside NXP/TI/ST products you would have to switch tools. You probably never HAVE to use a chip not available from one of those vendors for most embedded products but something to consider.
> If you are sure you will only use NXP chips then maybe the trace feature is enough to tip you to CodeRed even with the Eclipse issues. If it is as powerful as the Keil trace feature seems to be in demos it would catch my interest if I didn't have to support a wider range of chip vendors (and it wasn't Eclipse based ).
Reply by ●April 17, 20122012-04-17
I am not sure that you can purchase this separately as it is an OEM product.
You can purchase it with the FDI kits:
http://www.teamfdi.com/support/touch-screen.php
-- Paul.
On 17 Apr 2012, at 19:15, boB G wrote:
> We use IAR EWARM and LPC1766 and LPC2366 parts with the J-Link...
>
> I just saw mentioned in the Segger catalog, this LPC Lite JTAG box.
> Anybody know if it is actually available ?? I cannot seem to find it anywhere except in their PDF catalog...
> 2.6.7 NXP: J-Link Lite LPC Edition
>
> J-Link Lite LPC Edition is an OEM version of J-Link, sold by NXP.
> Limitations
>
> J-Link Lite LPC Edition only works with NXP devices. This limitation
> can NOT be lifted; if you would like to use J-Link with a
> device from an other manufacturer, you need to buy a separate
> J-Link.
>
> Licenses
> No licenses are included.
>
> --- In l..., richard neveau wrote:
>>> Regarding Rowley
>> I have used in last 7 years, at work, for ARM based product development, the following IDE's - Rowley Crossworks, IAR EWARM, TI CCS4, Freescale CodeWarrior 10, & Mentor Code Sourcery/Bench.
>> The only 2 I will gladly use again are Rowley & IAR.
>> ---------
>> Rowley Crossworks also seemed the best tool for 'debug' of embedded devices as it wasn't as flaky as the eclipse based tools and IMO was a little better debug experience day to day than IAR. IAR seems to build a little better code in benchmarks I've seen but I have not needed to squeeze CPU cycles for a while so the debug experience is what I rate as most important. Also $1500 < $5000 so while both tools are good Rowley is less expensive.
>> One thing with Eclipse based tools we have used is the whole 'sharing' of projects via SCM tool (SVN in our case) seems very hard to do smoothly. The .metadata directory has too big a mix between project and personal settings to be a good candidate for raw archiving and there was not a good rule of thumb we found to use across all Eclipse tools on what parts to save away. If you have more than a few developers on a project you might have some issues (or a lot of extra work) to make something that is bit for bit reproducible after changing PC's or several additional projects have occurred and you have to go back to do maintenance. If you can stick with one IDE and one product maybe you only have to learn the rules once so just a one time waste of resources but I'm betting figuring out this will cost you in some fashion close to $500 x N developers unless your N is large (or you force everyone to use exactly the same development environment).
>> Have not used CodeRed but last time I did an IDE eval it seemed CodeRed didn't support the extended ARM family as well as Rowley and IAR did. If you go to an chip outside NXP/TI/ST products you would have to switch tools. You probably never HAVE to use a chip not available from one of those vendors for most embedded products but something to consider.
>> If you are sure you will only use NXP chips then maybe the trace feature is enough to tip you to CodeRed even with the Eclipse issues. If it is as powerful as the Keil trace feature seems to be in demos it would catch my interest if I didn't have to support a wider range of chip vendors (and it wasn't Eclipse based ).
>>
>>
You can purchase it with the FDI kits:
http://www.teamfdi.com/support/touch-screen.php
-- Paul.
On 17 Apr 2012, at 19:15, boB G wrote:
> We use IAR EWARM and LPC1766 and LPC2366 parts with the J-Link...
>
> I just saw mentioned in the Segger catalog, this LPC Lite JTAG box.
> Anybody know if it is actually available ?? I cannot seem to find it anywhere except in their PDF catalog...
> 2.6.7 NXP: J-Link Lite LPC Edition
>
> J-Link Lite LPC Edition is an OEM version of J-Link, sold by NXP.
> Limitations
>
> J-Link Lite LPC Edition only works with NXP devices. This limitation
> can NOT be lifted; if you would like to use J-Link with a
> device from an other manufacturer, you need to buy a separate
> J-Link.
>
> Licenses
> No licenses are included.
>
> --- In l..., richard neveau wrote:
>>> Regarding Rowley
>> I have used in last 7 years, at work, for ARM based product development, the following IDE's - Rowley Crossworks, IAR EWARM, TI CCS4, Freescale CodeWarrior 10, & Mentor Code Sourcery/Bench.
>> The only 2 I will gladly use again are Rowley & IAR.
>> ---------
>> Rowley Crossworks also seemed the best tool for 'debug' of embedded devices as it wasn't as flaky as the eclipse based tools and IMO was a little better debug experience day to day than IAR. IAR seems to build a little better code in benchmarks I've seen but I have not needed to squeeze CPU cycles for a while so the debug experience is what I rate as most important. Also $1500 < $5000 so while both tools are good Rowley is less expensive.
>> One thing with Eclipse based tools we have used is the whole 'sharing' of projects via SCM tool (SVN in our case) seems very hard to do smoothly. The .metadata directory has too big a mix between project and personal settings to be a good candidate for raw archiving and there was not a good rule of thumb we found to use across all Eclipse tools on what parts to save away. If you have more than a few developers on a project you might have some issues (or a lot of extra work) to make something that is bit for bit reproducible after changing PC's or several additional projects have occurred and you have to go back to do maintenance. If you can stick with one IDE and one product maybe you only have to learn the rules once so just a one time waste of resources but I'm betting figuring out this will cost you in some fashion close to $500 x N developers unless your N is large (or you force everyone to use exactly the same development environment).
>> Have not used CodeRed but last time I did an IDE eval it seemed CodeRed didn't support the extended ARM family as well as Rowley and IAR did. If you go to an chip outside NXP/TI/ST products you would have to switch tools. You probably never HAVE to use a chip not available from one of those vendors for most embedded products but something to consider.
>> If you are sure you will only use NXP chips then maybe the trace feature is enough to tip you to CodeRed even with the Eclipse issues. If it is as powerful as the Keil trace feature seems to be in demos it would catch my interest if I didn't have to support a wider range of chip vendors (and it wasn't Eclipse based ).
>>
>>
