> I'm looking for a set of ARM (LPC17xx series and
later the 43xx series) development tools and can't decide between Code Red
Red Suite 4 and Rowley CrossWorks.
Whats wrong with:
openocd and jtag interface tools
arm-linux-gnueabi-gcc-xxx
arm-linux-gnueabi-gdb-xxx
vim
Makefiles
Hobby and commercial work - thats gotten me through lpc* arm7 variants I have
had to use.
ARM Development Tools
Started by ●March 29, 2012
Reply by ●April 1, 20122012-04-01
Reply by ●April 1, 20122012-04-01
I don't think there's anything wrong if a toolchain does the job you
want
and you're happy using it, and have time to learn how to use it properly.
The issues are different for commercial use where time to market is
important, then it's worth paying a premium for a well supported toolchain
with a good user interface.
Regards
Phil.
From: l... [mailto:l...] On Behalf Of
asa386
Sent: 01 April 2012 18:00
To: l...
Subject: [lpc2000] Re: ARM Development Tools
> I'm looking for a set of ARM (LPC17xx series and later the 43xx series)
development tools and can't decide between Code Red Red Suite 4 and Rowley
CrossWorks.
Whats wrong with:
openocd and jtag interface tools
arm-linux-gnueabi-gcc-xxx
arm-linux-gnueabi-gdb-xxx
vim
Makefiles
Hobby and commercial work - thats gotten me through lpc* arm7 variants I
have had to use.
and you're happy using it, and have time to learn how to use it properly.
The issues are different for commercial use where time to market is
important, then it's worth paying a premium for a well supported toolchain
with a good user interface.
Regards
Phil.
From: l... [mailto:l...] On Behalf Of
asa386
Sent: 01 April 2012 18:00
To: l...
Subject: [lpc2000] Re: ARM Development Tools
> I'm looking for a set of ARM (LPC17xx series and later the 43xx series)
development tools and can't decide between Code Red Red Suite 4 and Rowley
CrossWorks.
Whats wrong with:
openocd and jtag interface tools
arm-linux-gnueabi-gcc-xxx
arm-linux-gnueabi-gdb-xxx
vim
Makefiles
Hobby and commercial work - thats gotten me through lpc* arm7 variants I
have had to use.
Reply by ●April 1, 20122012-04-01
--- In l..., "Phil Young" wrote:
>
> I don't think there's anything wrong if a toolchain does the job you want
> and you're happy using it, and have time to learn how to use it properly.
>
I don't really care about the IDE and even ISP/JTAG isn't a compelling argument. What I REALLY care about is the libraries and demo code. Lots and lots of demo code. I'm not much of an inventor, I am a copier. If I can find a demo that's close to what I want, I can copy and paste with the best of them! Oh, and that demo code needs to be unrestricted - just in case I sell something someday (not likely).
I am messing around with a PIC32 and Microchip's TCP/IP stack. What a nice bunch of code. The demo project uses (selectively) all of the features so there is something to copy. If you want a VERY complete stack, Microchip has it.
Just getting a C library isn't enough any more. I want the PHY and stack code for the specific device(s) I am using. Same with USB: I want CDC and HID code at a minimum and, perhaps, mass storage. And I want it for the specific toolchain I am using. As many vendors are now just wrapping the GCC toolchain, that is fine with me.
If the demo code meets my needs, I'll stand on my head with the IDE. As long as I can get my project done, I don't care about the user interface.
Richard
>
> I don't think there's anything wrong if a toolchain does the job you want
> and you're happy using it, and have time to learn how to use it properly.
>
I don't really care about the IDE and even ISP/JTAG isn't a compelling argument. What I REALLY care about is the libraries and demo code. Lots and lots of demo code. I'm not much of an inventor, I am a copier. If I can find a demo that's close to what I want, I can copy and paste with the best of them! Oh, and that demo code needs to be unrestricted - just in case I sell something someday (not likely).
I am messing around with a PIC32 and Microchip's TCP/IP stack. What a nice bunch of code. The demo project uses (selectively) all of the features so there is something to copy. If you want a VERY complete stack, Microchip has it.
Just getting a C library isn't enough any more. I want the PHY and stack code for the specific device(s) I am using. Same with USB: I want CDC and HID code at a minimum and, perhaps, mass storage. And I want it for the specific toolchain I am using. As many vendors are now just wrapping the GCC toolchain, that is fine with me.
If the demo code meets my needs, I'll stand on my head with the IDE. As long as I can get my project done, I don't care about the user interface.
Richard
Reply by ●April 1, 20122012-04-01
Yes, but you have to understand that it's very expensive to produce
development boards and demo software, consequently manufacturers tend to
provide this first on the more expensive commercial development systems
since these are what their customers demand.
Ports to more obscure and open source toolchains are more often a task for
the enthusiast, and far less likely to be supported / maintained.
I think your wording sums it up when you say 'messing around', this is fine
for you as a hobbyist but it's of no interest whatsoever to a manufacturer
to support somebody who might buy a few or even a few thousand parts.
To break even on development of a microcontroller they need to sell tens of
millions.
Regards
Phil.
From: l... [mailto:l...] On Behalf Of
rtstofer
Sent: 01 April 2012 21:43
To: l...
Subject: [lpc2000] Re: ARM Development Tools
--- In l... , "Phil
Young" wrote:
>
> I don't think there's anything wrong if a toolchain does the job you want
> and you're happy using it, and have time to learn how to use it properly.
>
I don't really care about the IDE and even ISP/JTAG isn't a compelling
argument. What I REALLY care about is the libraries and demo code. Lots and
lots of demo code. I'm not much of an inventor, I am a copier. If I can find
a demo that's close to what I want, I can copy and paste with the best of
them! Oh, and that demo code needs to be unrestricted - just in case I sell
something someday (not likely).
I am messing around with a PIC32 and Microchip's TCP/IP stack. What a nice
bunch of code. The demo project uses (selectively) all of the features so
there is something to copy. If you want a VERY complete stack, Microchip has
it.
Just getting a C library isn't enough any more. I want the PHY and stack
code for the specific device(s) I am using. Same with USB: I want CDC and
HID code at a minimum and, perhaps, mass storage. And I want it for the
specific toolchain I am using. As many vendors are now just wrapping the GCC
toolchain, that is fine with me.
If the demo code meets my needs, I'll stand on my head with the IDE. As long
as I can get my project done, I don't care about the user interface.
Richard
development boards and demo software, consequently manufacturers tend to
provide this first on the more expensive commercial development systems
since these are what their customers demand.
Ports to more obscure and open source toolchains are more often a task for
the enthusiast, and far less likely to be supported / maintained.
I think your wording sums it up when you say 'messing around', this is fine
for you as a hobbyist but it's of no interest whatsoever to a manufacturer
to support somebody who might buy a few or even a few thousand parts.
To break even on development of a microcontroller they need to sell tens of
millions.
Regards
Phil.
From: l... [mailto:l...] On Behalf Of
rtstofer
Sent: 01 April 2012 21:43
To: l...
Subject: [lpc2000] Re: ARM Development Tools
--- In l... , "Phil
Young" wrote:
>
> I don't think there's anything wrong if a toolchain does the job you want
> and you're happy using it, and have time to learn how to use it properly.
>
I don't really care about the IDE and even ISP/JTAG isn't a compelling
argument. What I REALLY care about is the libraries and demo code. Lots and
lots of demo code. I'm not much of an inventor, I am a copier. If I can find
a demo that's close to what I want, I can copy and paste with the best of
them! Oh, and that demo code needs to be unrestricted - just in case I sell
something someday (not likely).
I am messing around with a PIC32 and Microchip's TCP/IP stack. What a nice
bunch of code. The demo project uses (selectively) all of the features so
there is something to copy. If you want a VERY complete stack, Microchip has
it.
Just getting a C library isn't enough any more. I want the PHY and stack
code for the specific device(s) I am using. Same with USB: I want CDC and
HID code at a minimum and, perhaps, mass storage. And I want it for the
specific toolchain I am using. As many vendors are now just wrapping the GCC
toolchain, that is fine with me.
If the demo code meets my needs, I'll stand on my head with the IDE. As long
as I can get my project done, I don't care about the user interface.
Richard
Reply by ●April 1, 20122012-04-01
> I don't really care about the IDE and even
ISP/JTAG isn't a
>compelling argument. What I REALLY care about is the libraries and
>demo code. Lots and lots of demo code. I'm not much of an
>inventor, I am a copier.
First
all that support from the Board/Chip Manufacturer comes at a cost.
In both time and money investment on their end and money on your
end in the form of increased cost for the Board and peripherals.
Second
its not possible for a BSP to satisfy every possible use of the
board.
>If I can find a demo that's close to what I want, I can copy and
>paste with the best of them! Oh, and that demo code needs to be
>unrestricted - just in case I sell something someday (not likely).
I detest this approach. My experience tells me it ALWAYS leads to
problems down the line.
In one case you automatically inherit whatever problems/bugs were
in that piece of copied code. The more complex the code the worse
the potential bugs. After all the original manufacturers interest
is to sell chips/boards not software.
In another you inherit any limitations in the use of that chipset
as the original programmer may have targeted a specific feature of
the device and without a full understanding of said device you are
limited to "mimicking" what was done with very little opportunity
to enhance or improve.
Finally that mindset is limiting, especially when you are called
upon to "bootstrap" a board. To bring it up from the ground up -
firmware to bsp to user apps. In such a situation there is no demo
code, there is no os and you are completely on your own. This is
more common among companies that contract outside help to assist
in-house engineers to design a board for a particular product.
Sam Igwe
>compelling argument. What I REALLY care about is the libraries and
>demo code. Lots and lots of demo code. I'm not much of an
>inventor, I am a copier.
First
all that support from the Board/Chip Manufacturer comes at a cost.
In both time and money investment on their end and money on your
end in the form of increased cost for the Board and peripherals.
Second
its not possible for a BSP to satisfy every possible use of the
board.
>If I can find a demo that's close to what I want, I can copy and
>paste with the best of them! Oh, and that demo code needs to be
>unrestricted - just in case I sell something someday (not likely).
I detest this approach. My experience tells me it ALWAYS leads to
problems down the line.
In one case you automatically inherit whatever problems/bugs were
in that piece of copied code. The more complex the code the worse
the potential bugs. After all the original manufacturers interest
is to sell chips/boards not software.
In another you inherit any limitations in the use of that chipset
as the original programmer may have targeted a specific feature of
the device and without a full understanding of said device you are
limited to "mimicking" what was done with very little opportunity
to enhance or improve.
Finally that mindset is limiting, especially when you are called
upon to "bootstrap" a board. To bring it up from the ground up -
firmware to bsp to user apps. In such a situation there is no demo
code, there is no os and you are completely on your own. This is
more common among companies that contract outside help to assist
in-house engineers to design a board for a particular product.
Sam Igwe
Reply by ●April 2, 20122012-04-02
--- In l..., "asa386" wrote:
>
> > I don't really care about the IDE and even ISP/JTAG isn't a
> >compelling argument. What I REALLY care about is the libraries and
> >demo code. Lots and lots of demo code. I'm not much of an
> >inventor, I am a copier.
>
> First
> all that support from the Board/Chip Manufacturer comes at a cost.
> In both time and money investment on their end and money on your
> end in the form of increased cost for the Board and peripherals.
>
> Second
> its not possible for a BSP to satisfy every possible use of the
> board.
>
> >If I can find a demo that's close to what I want, I can copy and
> >paste with the best of them! Oh, and that demo code needs to be
> >unrestricted - just in case I sell something someday (not likely).
>
> I detest this approach. My experience tells me it ALWAYS leads to
> problems down the line.
>
> In one case you automatically inherit whatever problems/bugs were
> in that piece of copied code. The more complex the code the worse
> the potential bugs. After all the original manufacturers interest
> is to sell chips/boards not software.
>
> In another you inherit any limitations in the use of that chipset
> as the original programmer may have targeted a specific feature of
> the device and without a full understanding of said device you are
> limited to "mimicking" what was done with very little opportunity
> to enhance or improve.
>
> Finally that mindset is limiting, especially when you are called
> upon to "bootstrap" a board. To bring it up from the ground up -
> firmware to bsp to user apps. In such a situation there is no demo
> code, there is no os and you are completely on your own. This is
> more common among companies that contract outside help to assist
> in-house engineers to design a board for a particular product.
>
> Sam Igwe
>
All of this is true but the time it would take to replicate the Microchip TCP/IP stack, from scratch, would swamp an entire team of programmers. They're going to be copying code from somewhere...
I wouldn't be surprised if there's a 100k lines of code in the TCP/IP stack so, from the old IBM standard of 100 lines of debugged and documented code per day per programmer, it would take 3 people about a year to duplicate it from scratch. Without copying from somewhere...
Given their code and a few days to see how the pieces fit, I can have my project done in a week; not 3 manyears. That's important at my age.
I have at least a dozen ARM development boards and both YAGARTO and CrossWorks for use with any of them (plus GNUARM on my Linux machine). So why use a Microchip MIPs chip? Simple! All I care about is a fully developed TCP/IP stack. I won't use all of the features, of course, but it's nice to run the demo and see them work. And the stack is not limited to a single packet in flight like uIP and it's better documented (and more complete) than lwIP.
For a one-off project, I don't care what the hardware costs. I'm going to reduce the project to a simple custom PCB and I'll use their hardware design to do it.
Richard
>
> > I don't really care about the IDE and even ISP/JTAG isn't a
> >compelling argument. What I REALLY care about is the libraries and
> >demo code. Lots and lots of demo code. I'm not much of an
> >inventor, I am a copier.
>
> First
> all that support from the Board/Chip Manufacturer comes at a cost.
> In both time and money investment on their end and money on your
> end in the form of increased cost for the Board and peripherals.
>
> Second
> its not possible for a BSP to satisfy every possible use of the
> board.
>
> >If I can find a demo that's close to what I want, I can copy and
> >paste with the best of them! Oh, and that demo code needs to be
> >unrestricted - just in case I sell something someday (not likely).
>
> I detest this approach. My experience tells me it ALWAYS leads to
> problems down the line.
>
> In one case you automatically inherit whatever problems/bugs were
> in that piece of copied code. The more complex the code the worse
> the potential bugs. After all the original manufacturers interest
> is to sell chips/boards not software.
>
> In another you inherit any limitations in the use of that chipset
> as the original programmer may have targeted a specific feature of
> the device and without a full understanding of said device you are
> limited to "mimicking" what was done with very little opportunity
> to enhance or improve.
>
> Finally that mindset is limiting, especially when you are called
> upon to "bootstrap" a board. To bring it up from the ground up -
> firmware to bsp to user apps. In such a situation there is no demo
> code, there is no os and you are completely on your own. This is
> more common among companies that contract outside help to assist
> in-house engineers to design a board for a particular product.
>
> Sam Igwe
>
All of this is true but the time it would take to replicate the Microchip TCP/IP stack, from scratch, would swamp an entire team of programmers. They're going to be copying code from somewhere...
I wouldn't be surprised if there's a 100k lines of code in the TCP/IP stack so, from the old IBM standard of 100 lines of debugged and documented code per day per programmer, it would take 3 people about a year to duplicate it from scratch. Without copying from somewhere...
Given their code and a few days to see how the pieces fit, I can have my project done in a week; not 3 manyears. That's important at my age.
I have at least a dozen ARM development boards and both YAGARTO and CrossWorks for use with any of them (plus GNUARM on my Linux machine). So why use a Microchip MIPs chip? Simple! All I care about is a fully developed TCP/IP stack. I won't use all of the features, of course, but it's nice to run the demo and see them work. And the stack is not limited to a single packet in flight like uIP and it's better documented (and more complete) than lwIP.
For a one-off project, I don't care what the hardware costs. I'm going to reduce the project to a simple custom PCB and I'll use their hardware design to do it.
Richard
Reply by ●April 2, 20122012-04-02
Il 02/04/2012 06:32, rtstofer ha scritto:
>
>
> --- In l... ,
> "asa386" wrote:
> >
> > > I don't really care about the IDE and even ISP/JTAG isn't a
> > >compelling argument. What I REALLY care about is the libraries and
> > >demo code. Lots and lots of demo code. I'm not much of an
> > >inventor, I am a copier.
> >
> > First
> > all that support from the Board/Chip Manufacturer comes at a cost.
> > In both time and money investment on their end and money on your
> > end in the form of increased cost for the Board and peripherals.
> >
> > Second
> > its not possible for a BSP to satisfy every possible use of the
> > board.
> >
> > >If I can find a demo that's close to what I want, I can copy and
> > >paste with the best of them! Oh, and that demo code needs to be
> > >unrestricted - just in case I sell something someday (not likely).
> >
> > I detest this approach. My experience tells me it ALWAYS leads to
> > problems down the line.
> >
> > In one case you automatically inherit whatever problems/bugs were
> > in that piece of copied code. The more complex the code the worse
> > the potential bugs. After all the original manufacturers interest
> > is to sell chips/boards not software.
> >
> > In another you inherit any limitations in the use of that chipset
> > as the original programmer may have targeted a specific feature of
> > the device and without a full understanding of said device you are
> > limited to "mimicking" what was done with very little opportunity
> > to enhance or improve.
> >
> > Finally that mindset is limiting, especially when you are called
> > upon to "bootstrap" a board. To bring it up from the ground up -
> > firmware to bsp to user apps. In such a situation there is no demo
> > code, there is no os and you are completely on your own. This is
> > more common among companies that contract outside help to assist
> > in-house engineers to design a board for a particular product.
> >
> > Sam Igwe
> > All of this is true but the time it would take to replicate the
> Microchip TCP/IP stack, from scratch, would swamp an entire team of
> programmers. They're going to be copying code from somewhere...
>
> I wouldn't be surprised if there's a 100k lines of code in the TCP/IP
> stack so, from the old IBM standard of 100 lines of debugged and
> documented code per day per programmer, it would take 3 people about a
> year to duplicate it from scratch. Without copying from somewhere...
>
> Given their code and a few days to see how the pieces fit, I can have
> my project done in a week; not 3 manyears. That's important at my age.
>
> I have at least a dozen ARM development boards and both YAGARTO and
> CrossWorks for use with any of them (plus GNUARM on my Linux machine).
> So why use a Microchip MIPs chip? Simple! All I care about is a fully
> developed TCP/IP stack. I won't use all of the features, of course,
> but it's nice to run the demo and see them work. And the stack is not
> limited to a single packet in flight like uIP and it's better
> documented (and more complete) than lwIP.
>
> For a one-off project, I don't care what the hardware costs. I'm going
> to reduce the project to a simple custom PCB and I'll use their
> hardware design to do it.
>
> Richard
>
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?
>
>
>
> --- In l... ,
> "asa386" wrote:
> >
> > > I don't really care about the IDE and even ISP/JTAG isn't a
> > >compelling argument. What I REALLY care about is the libraries and
> > >demo code. Lots and lots of demo code. I'm not much of an
> > >inventor, I am a copier.
> >
> > First
> > all that support from the Board/Chip Manufacturer comes at a cost.
> > In both time and money investment on their end and money on your
> > end in the form of increased cost for the Board and peripherals.
> >
> > Second
> > its not possible for a BSP to satisfy every possible use of the
> > board.
> >
> > >If I can find a demo that's close to what I want, I can copy and
> > >paste with the best of them! Oh, and that demo code needs to be
> > >unrestricted - just in case I sell something someday (not likely).
> >
> > I detest this approach. My experience tells me it ALWAYS leads to
> > problems down the line.
> >
> > In one case you automatically inherit whatever problems/bugs were
> > in that piece of copied code. The more complex the code the worse
> > the potential bugs. After all the original manufacturers interest
> > is to sell chips/boards not software.
> >
> > In another you inherit any limitations in the use of that chipset
> > as the original programmer may have targeted a specific feature of
> > the device and without a full understanding of said device you are
> > limited to "mimicking" what was done with very little opportunity
> > to enhance or improve.
> >
> > Finally that mindset is limiting, especially when you are called
> > upon to "bootstrap" a board. To bring it up from the ground up -
> > firmware to bsp to user apps. In such a situation there is no demo
> > code, there is no os and you are completely on your own. This is
> > more common among companies that contract outside help to assist
> > in-house engineers to design a board for a particular product.
> >
> > Sam Igwe
> > All of this is true but the time it would take to replicate the
> Microchip TCP/IP stack, from scratch, would swamp an entire team of
> programmers. They're going to be copying code from somewhere...
>
> I wouldn't be surprised if there's a 100k lines of code in the TCP/IP
> stack so, from the old IBM standard of 100 lines of debugged and
> documented code per day per programmer, it would take 3 people about a
> year to duplicate it from scratch. Without copying from somewhere...
>
> Given their code and a few days to see how the pieces fit, I can have
> my project done in a week; not 3 manyears. That's important at my age.
>
> I have at least a dozen ARM development boards and both YAGARTO and
> CrossWorks for use with any of them (plus GNUARM on my Linux machine).
> So why use a Microchip MIPs chip? Simple! All I care about is a fully
> developed TCP/IP stack. I won't use all of the features, of course,
> but it's nice to run the demo and see them work. And the stack is not
> limited to a single packet in flight like uIP and it's better
> documented (and more complete) than lwIP.
>
> For a one-off project, I don't care what the hardware costs. I'm going
> to reduce the project to a simple custom PCB and I'll use their
> hardware design to do it.
>
> Richard
>
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?
>
Reply by ●April 2, 20122012-04-02
--- 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
> 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 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
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
----Original Message----
From: l...
[mailto:l...] On Behalf Of Phil Young
Sent: 02 April 2012 15:33 To: l...
Subject: RE: [lpc2000] Re: ARM Development Tools
> On the subject of how much support for $500, I would
> answer NONE.
>
> Companies that fail to realize this don't tend to last
> that long.
This is completely not my experience as the owner of a small company that develops embedded products. Our software suppliers (notably Rowley, and our Altium CAD reseller) give us amazing software support. What type of business are you in which makes you think this?
--
Tim Mitchell
From: l...
[mailto:l...] On Behalf Of Phil Young
Sent: 02 April 2012 15:33 To: l...
Subject: RE: [lpc2000] Re: ARM Development Tools
> On the subject of how much support for $500, I would
> answer NONE.
>
> Companies that fail to realize this don't tend to last
> that long.
This is completely not my experience as the owner of a small company that develops embedded products. Our software suppliers (notably Rowley, and our Altium CAD reseller) give us amazing software support. What type of business are you in which makes you think this?
--
Tim Mitchell
