DS-5 opinions/reviews

Hi,

I'm debating purchasing a DS-5 license to do some bare metal
RTOS development work.  Anyone with first-hand experience with
the product, its quality/robustness and the quality/responsiveness
of the ARM Ltd folks in resolving "issues"?

[I'd much prefer using workarounds than having to debug frequent
patch releases!  "The bug you know is better than the one you
haven't yet *found*!"]

Also, any *experience* re: this approach vs. the GCC/GDB route?
I'm afraid that working with a commercial product and developing
a framework around it would burden future developers with leaner
development budgets.  So, the GCC/GDB/Eclipse route might be
less painful, overall (given that I'd end up building an environment
that fits with those "more available" tools)

Thx!
--don

Den l�rdag den 18. april 2015 kl. 01.01.31 UTC+2 skrev Don Y:
> Hi,
> 
> I'm debating purchasing a DS-5 license to do some bare metal
> RTOS development work.  Anyone with first-hand experience with
> the product, its quality/robustness and the quality/responsiveness
> of the ARM Ltd folks in resolving "issues"?
> 
> [I'd much prefer using workarounds than having to debug frequent
> patch releases!  "The bug you know is better than the one you
> haven't yet *found*!"]
> 
> Also, any *experience* re: this approach vs. the GCC/GDB route?
> I'm afraid that working with a commercial product and developing
> a framework around it would burden future developers with leaner
> development budgets.  So, the GCC/GDB/Eclipse route might be
> less painful, overall (given that I'd end up building an environment
> that fits with those "more available" tools)
> 
> Thx!
> --don

what would you gain from not using gcc like everyone else except a 
lighter wallet?


-Lasse

Hi Lasse,

On 4/18/2015 11:36 AM, lasselangwadtchristensen@gmail.com wrote:
> Den l�rdag den 18. april 2015 kl. 01.01.31 UTC+2 skrev Don Y:

>> I'm debating purchasing a DS-5 license to do some bare metal
>> RTOS development work.  Anyone with first-hand experience with
>> the product, its quality/robustness and the quality/responsiveness
>> of the ARM Ltd folks in resolving "issues"?

> what would you gain from not using gcc like everyone else except a
> lighter wallet?

I'll let you review the DS5 datasheet and note the differences
between it and GCC/GDB/Eclipse.

I've recommendations from two colleagues that speak very highly
of it (usage, support, code size, speed and quality).  When GCC
is brought up, both <frown> recalling how much more "work" is
required getting, installing, begging for assistance/bug fixes;
all to "save a DEVELOPMENT dollar".

[No idea how much your time is valued but it doesn't take long
at all for me to "lose" the price of a better tool while trying
to save a buck.  Unfortunately, neither of my colleagues had to
make the "make/buy" decision as their tools were "subsidized"]

My biggest concern is as to the "inertia" that a (paid) COTS solution
would impose on future developers.  I.e., I surely am not going to
build tools and practices that work in *two* different development
environments when I'm only *using* one of them!  (That would be
the worst of both worlds!)  Yet, I realize many folks probably
don't have pockets as deep as mine (or, perhaps, a different
*attitude* towards "spending development dollars").  OTOH, I
don't feel obliged to catering to their future "thrift" when it
comes at *my* current expense (*time*).

I was hoping other folks (besides my two colleagues) might have
*informed* opinions to offer as well...

Den s�ndag den 19. april 2015 kl. 02.50.15 UTC+2 skrev Don Y:
> Hi Lasse,
> 
> On 4/18/2015 11:36 AM, lasselangwadtchristensen@gmail.com wrote:
> > Den l�rdag den 18. april 2015 kl. 01.01.31 UTC+2 skrev Don Y:
> 
> >> I'm debating purchasing a DS-5 license to do some bare metal
> >> RTOS development work.  Anyone with first-hand experience with
> >> the product, its quality/robustness and the quality/responsiveness
> >> of the ARM Ltd folks in resolving "issues"?
> 
> > what would you gain from not using gcc like everyone else except a
> > lighter wallet?
> 
> I'll let you review the DS5 datasheet and note the differences
> between it and GCC/GDB/Eclipse.
> 
> I've recommendations from two colleagues that speak very highly
> of it (usage, support, code size, speed and quality).  When GCC
> is brought up, both <frown> recalling how much more "work" is
> required getting, installing, begging for assistance/bug fixes;
> all to "save a DEVELOPMENT dollar".
> 
> [No idea how much your time is valued but it doesn't take long
> at all for me to "lose" the price of a better tool while trying
> to save a buck.  Unfortunately, neither of my colleagues had to
> make the "make/buy" decision as their tools were "subsidized"]
> 
> My biggest concern is as to the "inertia" that a (paid) COTS solution
> would impose on future developers.  I.e., I surely am not going to
> build tools and practices that work in *two* different development
> environments when I'm only *using* one of them!  (That would be
> the worst of both worlds!)  Yet, I realize many folks probably
> don't have pockets as deep as mine (or, perhaps, a different
> *attitude* towards "spending development dollars").  OTOH, I
> don't feel obliged to catering to their future "thrift" when it
> comes at *my* current expense (*time*).
> 
> I was hoping other folks (besides my two colleagues) might have
> *informed* opinions to offer as well...

my point is that ds-5 might be better in some ways but it will limit who 
will consider using what ever it is you are making. If you are the only 
one who is going to use it that doesn't matter.  

imagine if Linux had required a $1000 compiler license

-Lasse

On 4/19/2015 4:27 AM, lasselangwadtchristensen@gmail.com wrote:
> Den s�ndag den 19. april 2015 kl. 02.50.15 UTC+2 skrev Don Y:
>> Hi Lasse,
>>
>> On 4/18/2015 11:36 AM, lasselangwadtchristensen@gmail.com wrote:
>>> Den l�rdag den 18. april 2015 kl. 01.01.31 UTC+2 skrev Don Y:
>>
>>>> I'm debating purchasing a DS-5 license to do some bare metal
>>>> RTOS development work.  Anyone with first-hand experience with
>>>> the product, its quality/robustness and the quality/responsiveness
>>>> of the ARM Ltd folks in resolving "issues"?
>>
>>> what would you gain from not using gcc like everyone else except a
>>> lighter wallet?
>>
>> I'll let you review the DS5 datasheet and note the differences
>> between it and GCC/GDB/Eclipse.
>>
>> I've recommendations from two colleagues that speak very highly
>> of it (usage, support, code size, speed and quality).  When GCC
>> is brought up, both <frown> recalling how much more "work" is
>> required getting, installing, begging for assistance/bug fixes;
>> all to "save a DEVELOPMENT dollar".
>>
>> [No idea how much your time is valued but it doesn't take long
>> at all for me to "lose" the price of a better tool while trying
>> to save a buck.  Unfortunately, neither of my colleagues had to
>> make the "make/buy" decision as their tools were "subsidized"]
>>
>> My biggest concern is as to the "inertia" that a (paid) COTS solution
>> would impose on future developers.  I.e., I surely am not going to
>> build tools and practices that work in *two* different development
>> environments when I'm only *using* one of them!  (That would be
>> the worst of both worlds!)  Yet, I realize many folks probably
>> don't have pockets as deep as mine (or, perhaps, a different
>> *attitude* towards "spending development dollars").  OTOH, I
>> don't feel obliged to catering to their future "thrift" when it
>> comes at *my* current expense (*time*).
>>
>> I was hoping other folks (besides my two colleagues) might have
>> *informed* opinions to offer as well...
>
> my point is that ds-5 might be better in some ways but it will limit who
> will consider using what ever it is you are making.

That was exactly the point I made in my OP:
     "I'm afraid that working with a commercial product and developing
     a framework around it would burden future developers with leaner
     development budgets."

> If you are the only
> one who is going to use it that doesn't matter.
>
> imagine if Linux had required a $1000 compiler license

Then only folks willing to shell out the $1K would be capable of
kernel hacking "out-of-the-box"!  It doesn't seem uncommon for FOSS
projects to "arbitrarily" pick their own tools, build systems, etc.
How is burdening a prospective developer with having to acquire and
install (even if they are "free") a different version of make(1),
a different VC system, testing framework, etc. any different than
saying "shell out $X instead of your *time* if you want to play"?
Haven't they, in effect, said their time and effort is worth
enough that they should pick the tools and approach that *they*
consider the most effective approach to the problem?

Note that my approach doesn't impact folks working in userland.
How often do you hack the RTOS of a product you are developing?
Are you capable of understanding the bare metal interfaces to do
so?  Do you even know where to *begin*?  Or, do you spend your
effort on the *application* side??  (which can use entirely
different tools)

Den s�ndag den 19. april 2015 kl. 19.38.44 UTC+2 skrev Don Y:
> On 4/19/2015 4:27 AM, lasselangwadtchristensen@gmail.com wrote:
> > Den s�ndag den 19. april 2015 kl. 02.50.15 UTC+2 skrev Don Y:
> >> Hi Lasse,
> >>
> >> On 4/18/2015 11:36 AM, lasselangwadtchristensen@gmail.com wrote:
> >>> Den l�rdag den 18. april 2015 kl. 01.01.31 UTC+2 skrev Don Y:
> >>
> >>>> I'm debating purchasing a DS-5 license to do some bare metal
> >>>> RTOS development work.  Anyone with first-hand experience with
> >>>> the product, its quality/robustness and the quality/responsiveness
> >>>> of the ARM Ltd folks in resolving "issues"?
> >>
> >>> what would you gain from not using gcc like everyone else except a
> >>> lighter wallet?
> >>
> >> I'll let you review the DS5 datasheet and note the differences
> >> between it and GCC/GDB/Eclipse.
> >>
> >> I've recommendations from two colleagues that speak very highly
> >> of it (usage, support, code size, speed and quality).  When GCC
> >> is brought up, both <frown> recalling how much more "work" is
> >> required getting, installing, begging for assistance/bug fixes;
> >> all to "save a DEVELOPMENT dollar".
> >>
> >> [No idea how much your time is valued but it doesn't take long
> >> at all for me to "lose" the price of a better tool while trying
> >> to save a buck.  Unfortunately, neither of my colleagues had to
> >> make the "make/buy" decision as their tools were "subsidized"]
> >>
> >> My biggest concern is as to the "inertia" that a (paid) COTS solution
> >> would impose on future developers.  I.e., I surely am not going to
> >> build tools and practices that work in *two* different development
> >> environments when I'm only *using* one of them!  (That would be
> >> the worst of both worlds!)  Yet, I realize many folks probably
> >> don't have pockets as deep as mine (or, perhaps, a different
> >> *attitude* towards "spending development dollars").  OTOH, I
> >> don't feel obliged to catering to their future "thrift" when it
> >> comes at *my* current expense (*time*).
> >>
> >> I was hoping other folks (besides my two colleagues) might have
> >> *informed* opinions to offer as well...
> >
> > my point is that ds-5 might be better in some ways but it will limit who
> > will consider using what ever it is you are making.
> 
> That was exactly the point I made in my OP:
>      "I'm afraid that working with a commercial product and developing
>      a framework around it would burden future developers with leaner
>      development budgets."
> 
> > If you are the only
> > one who is going to use it that doesn't matter.
> >
> > imagine if Linux had required a $1000 compiler license
> 
> Then only folks willing to shell out the $1K would be capable of
> kernel hacking "out-of-the-box"!  It doesn't seem uncommon for FOSS
> projects to "arbitrarily" pick their own tools, build systems, etc.
> How is burdening a prospective developer with having to acquire and
> install (even if they are "free") a different version of make(1),
> a different VC system, testing framework, etc. any different than
> saying "shell out $X instead of your *time* if you want to play"?
> Haven't they, in effect, said their time and effort is worth
> enough that they should pick the tools and approach that *they*
> consider the most effective approach to the problem?
> 
> Note that my approach doesn't impact folks working in userland.
> How often do you hack the RTOS of a product you are developing?
> Are you capable of understanding the bare metal interfaces to do
> so?  Do you even know where to *begin*?  Or, do you spend your
> effort on the *application* side??  (which can use entirely
> different tools)

if Linus had used a $1000 compiler you would most likely never 
have heard of Linux

-Lasse

On 4/19/2015 11:48 AM, lasselangwadtchristensen@gmail.com wrote:

> if Linus had used a $1000 compiler you would most likely never
> have heard of Linux

I don't use Linux -- so how would that have affected me?

Should I ensure all my hardware designs use thru-hole technology so
Joe Hobbyist can build boards with his Weller soldering iron/pencil?
And, nice *fat* traces so he can get the boards built for pennies?

Should I only use components that are available in Qty 1?  And,
keep total product cost under $100 for folks with shallow pockets?
Limit the complexity to things that can be accomplished with a PIC and
$30 demo board?

Should I only use languages that someone has "blessed" as "mainstream"?
Should I shun any technology that requires folks to spend money??

FOSS adherents seem to be more and more "tightwads" -- yet insisting
their *employers* pay them with hard currency (instead of free software).

On 19/04/15 02:49, Don Y wrote:
> Hi Lasse,
>
> On 4/18/2015 11:36 AM, lasselangwadtchristensen@gmail.com wrote:
>> Den l�rdag den 18. april 2015 kl. 01.01.31 UTC+2 skrev Don Y:
>
>>> I'm debating purchasing a DS-5 license to do some bare metal
>>> RTOS development work.  Anyone with first-hand experience with
>>> the product, its quality/robustness and the quality/responsiveness
>>> of the ARM Ltd folks in resolving "issues"?
>
>> what would you gain from not using gcc like everyone else except a
>> lighter wallet?
>
> I'll let you review the DS5 datasheet and note the differences
> between it and GCC/GDB/Eclipse.

Disclaimer - I haven't used ARM's own development tools at all.

The IDE for DS5 is Eclipse, the same as for most free and commercial 
gcc-based ARM toolchains.

The compiler for DS5 is, I think, still Keil's tools.  They are a good 
deal poorer than gcc in C and C++ feature support.  ARM is dropping the 
Keil toolchain entirely for future versions of their development tools, 
and moving to clang/llvm because they are more flexible, give better 
code, and have better support for modern standards.  (ARM choose 
clang/llvm rather than gcc because of the licensing.)

I can't tell you what ARM's support would be like.  I do know that price 
is no indication of quality for support, nor is it any indication that 
you will be up and running any faster or slower than with a free or 
low-price toolkit.  I have seen people spend weeks getting top-price 
commercial toolchains working, and seen them fighting with support 
people.  I have also seen people getting completely free systems up and 
running in under and hour.  Usually it comes down to the experience of 
the user with the processor in question, and with that type of toolchain 
- the price (or lack thereof) is mostly irrelevant.

For debugger hardware (and to a lesser extent, debugger software), on 
the other hand, there can be very big differences in quality, features 
and speed.  If you actually need the speed and features, that can be 
worth paying for.

>
> I've recommendations from two colleagues that speak very highly
> of it (usage, support, code size, speed and quality).  When GCC
> is brought up, both <frown> recalling how much more "work" is
> required getting, installing, begging for assistance/bug fixes;
> all to "save a DEVELOPMENT dollar".
>
> [No idea how much your time is valued but it doesn't take long
> at all for me to "lose" the price of a better tool while trying
> to save a buck.  Unfortunately, neither of my colleagues had to
> make the "make/buy" decision as their tools were "subsidized"]
>
> My biggest concern is as to the "inertia" that a (paid) COTS solution
> would impose on future developers.  I.e., I surely am not going to
> build tools and practices that work in *two* different development
> environments when I'm only *using* one of them!  (That would be
> the worst of both worlds!)  Yet, I realize many folks probably
> don't have pockets as deep as mine (or, perhaps, a different
> *attitude* towards "spending development dollars").  OTOH, I
> don't feel obliged to catering to their future "thrift" when it
> comes at *my* current expense (*time*).
>
> I was hoping other folks (besides my two colleagues) might have
> *informed* opinions to offer as well...

Hi David,

On 4/19/2015 1:03 PM, David Brown wrote:
> On 19/04/15 02:49, Don Y wrote:
>> On 4/18/2015 11:36 AM, lasselangwadtchristensen@gmail.com wrote:
>>> Den l�rdag den 18. april 2015 kl. 01.01.31 UTC+2 skrev Don Y:
>>
>>>> I'm debating purchasing a DS-5 license to do some bare metal
>>>> RTOS development work.  Anyone with first-hand experience with
>>>> the product, its quality/robustness and the quality/responsiveness
>>>> of the ARM Ltd folks in resolving "issues"?
>>
>>> what would you gain from not using gcc like everyone else except a
>>> lighter wallet?
>>
>> I'll let you review the DS5 datasheet and note the differences
>> between it and GCC/GDB/Eclipse.
>
> Disclaimer - I haven't used ARM's own development tools at all.

That's the problem.  Canvassing colleagues only turns up a few working
under DS5.  But, those that do seem to have good things to say about it...

> The IDE for DS5 is Eclipse, the same as for most free and commercial gcc-based
> ARM toolchains.
>
> The compiler for DS5 is, I think, still Keil's tools.  They are a good deal
> poorer than gcc in C and C++ feature support.  ARM is dropping the Keil
> toolchain entirely for future versions of their development tools, and moving
> to clang/llvm because they are more flexible, give better code, and have better
> support for modern standards.  (ARM choose clang/llvm rather than gcc because
> of the licensing.)

The switch is already present in DS5 -- AFAICT you have a choice of the linaro
gcc compiler or the newer llvm implementation.

> I can't tell you what ARM's support would be like.  I do know that price is no

Nor can you predict what the type of support I might receive in the
FOSS/embedded community would likely be.  How many folks are hacking
(existing, "running") kernels vs. tinkering with userland apps (vs.
never even LOOKING at the sources!)?  I didn't notice a lot of
folks chiming in with their first-hand experience with A5 cores when
I asked, recently!  How many *fewer* are developing custom RTOS's on
those?  And deploying in a distributed environment?

[Of course, no guarantee that any of the ARMLtd folks have the requisite
experience/knowledge, either.  But, they probably have a bigger incentive
to get me to a solution -- no per unit royalties until product moves out
the door!]

> indication of quality for support, nor is it any indication that you will be up
> and running any faster or slower than with a free or low-price toolkit.  I have
> seen people spend weeks getting top-price commercial toolchains working, and
> seen them fighting with support people.  I have also seen people getting
> completely free systems up and running in under and hour.  Usually it comes
> down to the experience of the user with the processor in question, and with
> that type of toolchain - the price (or lack thereof) is mostly irrelevant.

So far, I can only comment on what the few colleagues who've used their
toolchain have had to say.  I've done a fair bit of work with gcc/gdb
and know there is always a significant effort to getting the remote stubs
working properly, adapting to your particular RTOS interfaces, etc.

The risk of the DS5 approach is that it might be too closed to allow me to
make those sorts of tweaks (hard to imagine since they aren't also pushing
an integrated OS/toolchain solution -- unlike folks like IAR, etc.).

> For debugger hardware (and to a lesser extent, debugger software), on the other
> hand, there can be very big differences in quality, features and speed.  If you
> actually need the speed and features, that can be worth paying for.

There's a huge difference debugging userland applications with a running
OS -- or, even modifying an existing OS to add features -- vs. working from
bare metal, up.  I.e., starting with *just* silicon.

I suspect ARM's models aren't supported (sold) in FOSS gcc/gdb/eclipse
implementations so, you're stuck with debug *hardware* entirely.  How many
hours of poking at stubs are required before you've paid off the cost of
a commercial tool (*cost* seems to be the only issue keeping folks from
the ARM tools).  How many protoboard revisions do I have to run through
with the gdb approach due to its reliance on "real" hardware?

Time to bake the cookies...

David Brown <david.brown@hesbynett.no> wrote:

> The compiler for DS5 is, I think, still Keil's tools.

AFAIK Keil's own ARM compiler was dropped in favour of ARM's some time 
around the Keil 5 timeframe. For some time the only real difference 
between the two was that MDK only supported microcontroller cores.

-a