Forums

DS-5 opinions/reviews

Started by Don Y April 17, 2015
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&#2013266168;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&#2013266168;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&#2013266168;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&#2013266168;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&#2013266168;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&#2013266168;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&#2013266168;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&#2013266168;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&#2013266168;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