FreeRTOS and newlib - comments requested

On Wednesday, June 28, 2017 at 10:39:57 AM UTC-4, Don Y wrote:
> These types of "support activities" are often handled by "junior engineers".
> I think their thinking is that its a relatively "safe" way to use their
> skills without too much risk (I think they expect developers to rework
> the examples and not blindly incorporate them into product).  I know that
> the quality of support folks with which I interact varies based on the
> dollar volume of the business I'm doing.
> 
> The same is true of "application notes" -- both hardware and software.
> Taking ANY of that stuff literally is almost certainly a bad idea.  I
> don't think anyone actually proofreads the code/schematics...

Two different topics:
(1) 'support' desk
The unfortunate side-effect of cheap development kits (which we all love):
Every student and wannabee buys one, and then contacts support because they
need help opening the box. Hence a colleague at Garmin (who buys *lots*
of these parts gets to talk to an actual real engineer... And the rest of us
get to email to Freescale's lowest-possible-cost help desk in China staffed
with script-readers who tell us to reinstall the software and try again,
and cannot manage anything vaguely complex. If you have a real problem,
they by definition cannot help - if they were smart enough to
help they wouldn't be working there.

(2) Marketing-required SDKs and application notes:
Provided  by usually not the top-tier engineers, but at least engineers.
I've seen plenty of app notes that would cause a fire if copied,
and I've seen field failures when a witless engineer copied one
verbatim and shipped it without proper testing...
But the SDKs are relied on by real customers (who expect at least
working examples) so there is *some* pressure to make this stuff work.
But not enough to use top-tier engineers and implement real testing
(for at least many vendors). So you get stuff like Freescale's SDK,
which provides init functions for all the control structures, but
they don't actually initialize the entire structure - so the sample
code memsets the structure to 0 and then calls the init...
You couldn't make this stuff up!

> It's worthwhile to develop your own standard libraries, drivers/handlers,
> crt0.s, etc. that you are more intimately familiar with so you can more
> readily port them to other projects...

Absolutely. But don't stop there, implement the USB-stack, network-stack,
all drivers, compiler, runtime library, and operating system yourself.
That way you'll know what your getting for sure.
And don't forget to design your own improved peripherals using FPGAs.

Except for the USB and network stacks, I've done all the above *too*
many times (and I've had to *debug* some USB and network stacks).
But when I **actually have to build a product for a customer**, using
the latest MCUs and electronics, this is wildly impractical!

So we end up depending on variable-quality stuff,
and slogging through fixing the worst of it,
and economics say it ain't going to get better - not possible.

Enough, Hopefully I've helped a bit with the newlib stuff!

On 7/1/2017 11:16 AM, Dave Nadler wrote:
> On Wednesday, June 28, 2017 at 10:39:57 AM UTC-4, Don Y wrote:
>> These types of "support activities" are often handled by "junior engineers".
>> I think their thinking is that its a relatively "safe" way to use their
>> skills without too much risk (I think they expect developers to rework
>> the examples and not blindly incorporate them into product).  I know that
>> the quality of support folks with which I interact varies based on the
>> dollar volume of the business I'm doing.
>>
>> The same is true of "application notes" -- both hardware and software.
>> Taking ANY of that stuff literally is almost certainly a bad idea.  I
>> don't think anyone actually proofreads the code/schematics...
> 
> Two different topics:
> (1) 'support' desk
> The unfortunate side-effect of cheap development kits (which we all love):

(Well, the price of the kit isn't directly coupled to the quality of the
support; they *could* offer the kits "at cost" and force folks to pay
for support *or* rely on forum-based support as a consequence of the
low cost prototype)

> Every student and wannabee buys one, and then contacts support because they
> need help opening the box. Hence a colleague at Garmin (who buys *lots*
> of these parts gets to talk to an actual real engineer... And the rest of us
> get to email to Freescale's lowest-possible-cost help desk in China staffed
> with script-readers who tell us to reinstall the software and try again,
> and cannot manage anything vaguely complex. If you have a real problem,
> they by definition cannot help - if they were smart enough to
> help they wouldn't be working there.

The manufacturer can't afford a "relationship" with each *potential*
customer.  Instead, they hope to seed development efforts and possible
relationships.

I've found that the quality of the questions I issue and the critiques
of their "product" (documentation, hardware, toolchain, etc.) gets me
the attention of the right people.  I.e., they know I'm digging deep
under the hood and not just poking at something casually or for a
"one-off".

Then, it becomes an issue of keeping in touch with these inside contacts
often enough that as they move through (and between) organizations, they
remain accessible to you -- so you don't have to start all over at the
bottom.

[This allows my work with bigger customers to benefit the little garage
shops -- who'd simply not have access to those sorts of resources with
their small volume purchases]

> (2) Marketing-required SDKs and application notes:
> Provided  by usually not the top-tier engineers, but at least engineers.
> I've seen plenty of app notes that would cause a fire if copied,
> and I've seen field failures when a witless engineer copied one
> verbatim and shipped it without proper testing...

Developing relationships with key customers lets you rely on them for
*thoughtful* feedback.  I've had relationships with tool vendors
where I would report a problem in the morning and have an updated
set of binaries TO TEST by evening.  Me benefitting from not having to
leave work-arounds in production code; they benefitting by not having
to do extensive testing before getting a pre-release out.  They
could defer releasing THIS version to their customer base until the
next "scheduled release" -- when it would have undergone more formal
documentation and testing.

> But the SDKs are relied on by real customers (who expect at least
> working examples) so there is *some* pressure to make this stuff work.
> But not enough to use top-tier engineers and implement real testing
> (for at least many vendors). So you get stuff like Freescale's SDK,
> which provides init functions for all the control structures, but
> they don't actually initialize the entire structure - so the sample
> code memsets the structure to 0 and then calls the init...
> You couldn't make this stuff up!

Again, find customers who are conscientious, go the extra mile for
them KNOWING they'll be willing/eager to share their efforts with
you.  They're obviously not going to share proprietary ideas or
algorithms; but can catch and repair errors as more than an academic
exercise -- they're *using* the code/schematic-sections that they're
feeding back to you.

Forums try to exploit this but the "relationship" is tenuous and,
by definition, "public".  I'd not want to discuss or reveal specific
details of a project in a public forum beyond what I need to get
a problem fixed.

By contrast, in private communications, I can pass far more detailed
information, larger code fragments, bigger portions of schematics, etc.
without wondering who *else* (competitors) is seeing what I'm doing.

>> It's worthwhile to develop your own standard libraries, drivers/handlers,
>> crt0.s, etc. that you are more intimately familiar with so you can more
>> readily port them to other projects...
> 
> Absolutely. But don't stop there, implement the USB-stack, network-stack,
> all drivers, compiler, runtime library, and operating system yourself.
> That way you'll know what your getting for sure.

That's often a requirement.  I'm writing my fourth network stack as each
has had different design and operating constraints.  "One size fits all"
DOESN'T!  But, this really isn't hard if you've already created other
versions and just want to tweek them to fit a new set of requirements
or constraints.

It also shows you the value of writing "portable" code; you can inherit
a lot of quality without having to rewrite it all.

> And don't forget to design your own improved peripherals using FPGAs.

Only if needed.  Buy what you can; write/design what you must.
Silly to waste time designing a DRAM controller when you can buy one
that's already integrated with the processor.  OTOH, if you want to
*share* physical memory with another device, you're likely not going
to find a COTS solution (for processor of your choosing).

> Except for the USB and network stacks, I've done all the above *too*
> many times (and I've had to *debug* some USB and network stacks).
> But when I **actually have to build a product for a customer**, using
> the latest MCUs and electronics, this is wildly impractical!

I think importing code/hardware is the more impractical.  You have
little idea of how it was *intended* to work, the skill level of
the developer, the ruthlessness of the folks testing it, etc.

And, you start over with each new platform with the same uncertainties.

By contrast, I can tweek the same libraries I've been using for years
to work with a new compiler/toolchain, new hardware platform, etc.
Ditto other major subsystems, device drivers, etc.  Most of the
"meat" lies in the choice of algorithms, not the vagaries of the
particular hardware.

> So we end up depending on variable-quality stuff,
> and slogging through fixing the worst of it,
> and economics say it ain't going to get better - not possible.
> 
> Enough, Hopefully I've helped a bit with the newlib stuff!

Good.

On 01.7.2017 г. 21:16, Dave Nadler wrote:
> On Wednesday, June 28, 2017 at 10:39:57 AM UTC-4, Don Y wrote:
>> These types of "support activities" are often handled by "junior engineers".
>> I think their thinking is that its a relatively "safe" way to use their
>> skills without too much risk (I think they expect developers to rework
>> the examples and not blindly incorporate them into product).  I know that
>> the quality of support folks with which I interact varies based on the
>> dollar volume of the business I'm doing.
>>
>> The same is true of "application notes" -- both hardware and software.
>> Taking ANY of that stuff literally is almost certainly a bad idea.  I
>> don't think anyone actually proofreads the code/schematics...
>
> Two different topics:
> (1) 'support' desk
> The unfortunate side-effect of cheap development kits (which we all love):

Not everyone. I am the proof :-). In fact I have never wasted any time
with one of these. If I will design something I will have to design it
anyway, why would I waste time toying around with some other board
than the one I want to design.

> Every student and wannabee buys one, and then contacts support because they
> need help opening the box. Hence a colleague at Garmin (who buys *lots*
> of these parts gets to talk to an actual real engineer... And the rest of us
> get to email to Freescale's lowest-possible-cost help desk in China staffed
> with script-readers who tell us to reinstall the software and try again,
> and cannot manage anything vaguely complex. If you have a real problem,
> they by definition cannot help - if they were smart enough to
> help they wouldn't be working there.

This is why I hate the trend. Because of the above programmers
are almost extinct. And because they are kids who know how to open
the box call themselves "programmers" and the public accepts that.
Worse, the customers of our kind do.

Dimiter

-=====================================================-
Dimiter Popoff, TGI             http://www.tgi-sci.com
-=====================================================-
http://www.flickr.com/photos/didi_tgi/

On Saturday, July 1, 2017 at 3:41:28 PM UTC-4, dp wrote:
> On 01.7.2017 г. 21:16, Dave Nadler wrote:
> > The unfortunate side-effect of cheap development kits (which we all love):
> 
> Not everyone. I am the proof :-). In fact I have never wasted any time
> with one of these. If I will design something I will have to design it
> anyway, why would I waste time toying around with some other board
> than the one I want to design.

These boards are invaluable! On my desk I have one I used to bring up
most of a customer application, with stubs for the real hardware.
We sent a few to the end customer to debug their software against our
API before the real (hugely expensive) hardware was ready, and they
continue to use them for software development.

> This is why I hate the trend. Because of the above programmers
> are almost extinct. And because they are kids who know how to open
> the box call themselves "programmers" and the public accepts that.
> Worse, the customers of our kind do.

Me too. But the depth of current stacks precludes doing everything
oneself like the old days. Witness your struggle moving to a new
processor ;-) Customers pretty quickly find out when they can't
get something that works reliably, promptly, who is a real engineer.
Or they go bust (plenty of stories of crating I've witnessed).
Anyway I'm not going to write another RTOS.

At least I can have fun teaching "How NOT To Do Embedded Design"!
Perhaps I'll do it again at fall west coast ESC...

See ya, Dave

On Saturday, July 1, 2017 at 3:13:26 PM UTC-4, Don Y wrote:
> (Well, the price of the kit isn't directly coupled to the quality of the
> support; they *could* offer the kits "at cost" and force folks to pay
> for support *or* rely on forum-based support as a consequence of the
> low cost prototype)

No they cannot - The competitive market and corporate budgeting dictates
these are sold at or below cost.

> I've found that the quality of the questions I issue and the critiques
> of their "product" (documentation, hardware, toolchain, etc.) gets me
> the attention of the right people.  I.e., they know I'm digging deep
> under the hood and not just poking at something casually or for a
> "one-off".

Way back, my firm got several big customers after support contacts about
problems with their products.  But you will never, ever, reach serious folks
through today's support channels (like Freescale) because of the economics.
Unless you are my colleague at Garmin or similar you're screwed.
Perhaps I'm overly pessimistic given the recent support mishaps;
still have senior contacts at some vendors so its not impossible.
No idea how to reach anybody competent and attentive regarding the
Kinetis line, though NXP a few years back was great (fixed documentation
errors I pointed out, fixed bugs and helped me work around others).

I should stop teeth gnashing and go enjoy the summer with my wife now!
See ya, Dave

Hi Dimiter,

On 7/1/2017 12:41 PM, Dimiter_Popoff wrote:
> On 01.7.2017 г. 21:16, Dave Nadler wrote:
>> On Wednesday, June 28, 2017 at 10:39:57 AM UTC-4, Don Y wrote:
>>> These types of "support activities" are often handled by "junior engineers".
>>> I think their thinking is that its a relatively "safe" way to use their
>>> skills without too much risk (I think they expect developers to rework
>>> the examples and not blindly incorporate them into product).  I know that
>>> the quality of support folks with which I interact varies based on the
>>> dollar volume of the business I'm doing.
>>>
>>> The same is true of "application notes" -- both hardware and software.
>>> Taking ANY of that stuff literally is almost certainly a bad idea.  I
>>> don't think anyone actually proofreads the code/schematics...
>>
>> Two different topics:
>> (1) 'support' desk
>> The unfortunate side-effect of cheap development kits (which we all love):
> 
> Not everyone. I am the proof :-). In fact I have never wasted any time
> with one of these. If I will design something I will have to design it
> anyway, why would I waste time toying around with some other board
> than the one I want to design.

I think you're ignoring the fact that most folks don't design hardware,
anymore.  The thinking seems to be that you can "save lots of time"
by buying a board that you can glom some I/O's onto.

Of course, now you have to design the I/O board and hope its a clean
interface to the purchased board -- and, that the purchased board
meets *your* specific needs (gee, will it operate *reliably* over the
full temperature and power supply range?  will it be repairable?
will the vendor keep supplying THAT "component"?  etc.)

So, folks are even more willing to buy their prototyping hardware...
"so they can be writing code (that they've not fully DESIGNED!) sooner"!

[A guy in SED was looking to use an arduino to light an indicator when
it sensed a device (cell phone) was NOT plugged into the USB outlet.

There's this misplaced sense of "if I do THIS, I can cut all these
corners and be done quicker, cheaper, etc." -- but all you do is
swap in NEW "corners" that you'll need to work through.

[E.g., the guy who used a COTS PC as the UI for his process control
system -- then had to figure out how to package it in a way that
would protect the keyboard, disk drives, monitor, etc. from the harsh
environment to which they'd be subjected, etc.  And, of course, the
PC didn't have the necessary I/O's to interface to the field sensors
and actuators so he *still* had to design some boards for that.
Then, had to scurry when the PC vendor stopped offering that particular
model and new buses came into being, etc.  How much did he *really*
save?]

OTOH, there are markets where you need to be able to respond quickly
and choose not to invest in the staff that would otherwise enable you
to do so -- effectively outsourcing the skillsets that you would otherwise
need to ensure your *continued* viability.

And, finally, the folks who delude themselves into thinking they're
just going to use this to get a toe-hold in the market and THEN they'll
RE-design the product the "correct way"... only to discover that either:
- their product sucks and they've effectively NO market (share)
- their product has high demand, despite its shortcomings, and they
   are now caught up trying to address modifications/enhancements requested
   from their customer base -- while their competitors are free to work
   on the NEXT generation products that will supplant them in the market
   that they THINK they've got such a hold over!

[A manager at a multimillion dollar manufacturing company once lamented
to me that they LOST their market when they were busiest meeting its
needs -- as a virtual monopoly!  They were so busy being "wagged" by
their new/existing customers that they didn't have time to put resources
into "what comes next".  So, when the competition announced a better
mousetrap, sales dried up overnight and there was no "next" product
ready in the pipeline to compete!]

>> Every student and wannabee buys one, and then contacts support because they
>> need help opening the box. Hence a colleague at Garmin (who buys *lots*
>> of these parts gets to talk to an actual real engineer... And the rest of us
>> get to email to Freescale's lowest-possible-cost help desk in China staffed
>> with script-readers who tell us to reinstall the software and try again,
>> and cannot manage anything vaguely complex. If you have a real problem,
>> they by definition cannot help - if they were smart enough to
>> help they wouldn't be working there.
> 
> This is why I hate the trend. Because of the above programmers
> are almost extinct. And because they are kids who know how to open
> the box call themselves "programmers" and the public accepts that.
> Worse, the customers of our kind do.

Until they find a product that eats their lunch/reputation.

On 01.7.2017 г. 22:52, Dave Nadler wrote:
> On Saturday, July 1, 2017 at 3:41:28 PM UTC-4, dp wrote:
>> On 01.7.2017 г. 21:16, Dave Nadler wrote:
>>> The unfortunate side-effect of cheap development kits (which we all love):
>>
>> Not everyone. I am the proof :-). In fact I have never wasted any time
>> with one of these. If I will design something I will have to design it
>> anyway, why would I waste time toying around with some other board
>> than the one I want to design.
>
> These boards are invaluable! On my desk I have one I used to bring up
> most of a customer application, with stubs for the real hardware.
> We sent a few to the end customer to debug their software against our
> API before the real (hugely expensive) hardware was ready, and they
> continue to use them for software development.

I understand they can be useful in your case where your goal is to
sell just software, not a complete product. I have almost never been
there hence my point of view.

>
>> This is why I hate the trend. Because of the above programmers
>> are almost extinct. And because they are kids who know how to open
>> the box call themselves "programmers" and the public accepts that.
>> Worse, the customers of our kind do.
>
> Me too. But the depth of current stacks precludes doing everything
> oneself like the old days. Witness your struggle moving to a new
> processor ;-)

Not such a huge struggle really - unless you envisage my moving
from the 68k architecture to power, this took me a year and was
anything but a walk in the park.
I'd like to see someone doing it in a shorter time - porting the
entire OS and all apps, was 6 or 8 M source back then (> 15 years
ago, how is THAT possible...). Say ARM to x86 or vice versa.

Moving within closer family has taken negligible time, say when I
needed a small MCU a few years ago for a one-off it took me
3 months to adapt my entire toolchain to it (mostly writing
the BDM thing and the debugger) and another month for the end
application code. I have yet to see someone matching the 4 months
for a product like that (hardware design, simulations, PCB
etc. included in the 4 months of course):
http://tgi-sci.com/dsv/dsvpex.htm , second product top
to bottom (the +/-100V saw generator),
http://tgi-sci.com/misc/cfb.gif .
Matching that using any board and any toolchain will still
have me impressed.

> Customers pretty quickly find out when they can't
> get something that works reliably, promptly, who is a real engineer.
> Or they go bust (plenty of stories of crating I've witnessed).

Of course, they are not stupid. Or go bust :-).
But I have never managed - never tried really - to sell just
software, hence our differing points of view I guess.

> Anyway I'm not going to write another RTOS.

Hah, never say never :-).
I feel the same about dps of course.

> At least I can have fun teaching "How NOT To Do Embedded Design"!
> Perhaps I'll do it again at fall west coast ESC...
>
> See ya, Dave

Best,

Dimiter

-=====================================================-
Dimiter Popoff, TGI             http://www.tgi-sci.com
-=====================================================-
http://www.flickr.com/photos/didi_tgi/

On 7/1/2017 1:02 PM, Dave Nadler wrote:
> On Saturday, July 1, 2017 at 3:13:26 PM UTC-4, Don Y wrote:
>> (Well, the price of the kit isn't directly coupled to the quality of the
>> support; they *could* offer the kits "at cost" and force folks to pay
>> for support *or* rely on forum-based support as a consequence of the
>> low cost prototype)
> 
> No they cannot - The competitive market and corporate budgeting dictates
> these are sold at or below cost.
> 
>> I've found that the quality of the questions I issue and the critiques
>> of their "product" (documentation, hardware, toolchain, etc.) gets me
>> the attention of the right people.  I.e., they know I'm digging deep
>> under the hood and not just poking at something casually or for a
>> "one-off".
> 
> Way back, my firm got several big customers after support contacts about
> problems with their products.  But you will never, ever, reach serious folks
> through today's support channels (like Freescale) because of the economics.
> Unless you are my colleague at Garmin or similar you're screwed.

That's the point; work on large volume kit and you'd be surprised who
they'll put on a *plane* to COME talk to you.  Of course, you
don't have to FORGET that contact when you move on to the next
"garage shop" project.  If *all* you effectively are is a "purchasing
agent" (i.e., you only appear to the vendor as a source of sales),
then you have little continued sway with that vendor or his staff.

OTOH, if you can engage them in technical issues that affect *their*
design decision of future products (because they want to develop
things that YOU will want to buy), you're more likely to *keep* their
(individual) attention, even after you've moved on to smaller ponds
or different domains.

[I.e., you want a *personal* relationship with the folks involved,
not a "business" relationship.  The former is tied to YOU, the
latter is tied to the firm you're representing along with the
firm at which your contact is CURRENTLY employed.]

> Perhaps I'm overly pessimistic given the recent support mishaps;
> still have senior contacts at some vendors so its not impossible.
> No idea how to reach anybody competent and attentive regarding the
> Kinetis line, though NXP a few years back was great (fixed documentation
> errors I pointed out, fixed bugs and helped me work around others).

With most forums (fora?), there is little value to reporting problems
and solutions.  If it's not a "trivial" or *obvious* problem (one
that WILL affect everyone), chances are you'll have to fix it yourself.
How much time you want to spend beyond that is a personal issue as
you're unlikely to "get" much for that investment (beyond a sense
of having helped some other who *might* head down that same path).

Early in my career, clients made the decisions regarding which tools,
components, etc, they wanted used in THEIR products;   when they'd
invested tens of kilobucks in a "development system" -- not just
a compiler on a PC -- they were eager to leverage that prior investment
AND the past development/troubleshooting/manufacturing experiences
of their existing staff.  "Can't you do this with a 6809?  68K?  1802?
Those are the tools and components that we've experience with, now..."
(sure, but are any of those really the right way to approach the problem?)

Later, I learned to take more control of projects -- be a bigger fish
in a smaller pond, often.  So, I could tailor the hardware (that *I*
was going to be charged with designing) to the software (that I would
write) to the toolchain (that I would purchase/develop) to satisfy the
specification (that I'd write and the client would approve).  By
leveraging past designs, I could continue to take on larger projects
without having to "increase (my) resources" -- I knew where the
costs would be in my approach instead of having to open a new can
of worms, each time.

> I should stop teeth gnashing and go enjoy the summer with my wife now!

Work should be *fun*.  If its not, then its a *job*.  :<

> See ya, Dave
> 

On 01.7.2017 г. 23:15, Don Y wrote:
> Hi Dimiter,
>
> On 7/1/2017 12:41 PM, Dimiter_Popoff wrote:
>> On 01.7.2017 г. 21:16, Dave Nadler wrote:
>>> On Wednesday, June 28, 2017 at 10:39:57 AM UTC-4, Don Y wrote:
>>>> These types of "support activities" are often handled by "junior
>>>> engineers".
>>>> I think their thinking is that its a relatively "safe" way to use their
>>>> skills without too much risk (I think they expect developers to rework
>>>> the examples and not blindly incorporate them into product).  I know
>>>> that
>>>> the quality of support folks with which I interact varies based on the
>>>> dollar volume of the business I'm doing.
>>>>
>>>> The same is true of "application notes" -- both hardware and software.
>>>> Taking ANY of that stuff literally is almost certainly a bad idea.  I
>>>> don't think anyone actually proofreads the code/schematics...
>>>
>>> Two different topics:
>>> (1) 'support' desk
>>> The unfortunate side-effect of cheap development kits (which we all
>>> love):

Hi Don,

>>
>> Not everyone. I am the proof :-). In fact I have never wasted any time
>> with one of these. If I will design something I will have to design it
>> anyway, why would I waste time toying around with some other board
>> than the one I want to design.
>
> I think you're ignoring the fact that most folks don't design hardware,
> anymore.  The thinking seems to be that you can "save lots of time"
> by buying a board that you can glom some I/O's onto.
>
> Of course, now you have to design the I/O board and hope its a clean
> interface to the purchased board --

So you see I am not ignoring the fact they don't want to design
hardware; they have to design it anyway. Adapting it to a generic
board will cost at least as much as placing their own MCU on their
board.
The latter option would get them much closer to what they want but
they typically "don't know how to open the box" as Dave said in
a post before.

> .. and, that the purchased board
> meets *your* specific needs (gee, will it operate *reliably* over the
> full temperature and power supply range?  will it be repairable?
> will the vendor keep supplying THAT "component"?  etc.)
>
> So, folks are even more willing to buy their prototyping hardware...
> "so they can be writing code (that they've not fully DESIGNED!) sooner"!

The thing with prototyping is that it only wastes your time if you
know what you are doing. Why do everything TWICE? Typically I design
the boards, the first revision obviously needs some cuts etc but
is quite acceptable, typically a lot more acceptable than first boards
I have seen having been made after months of prototyping etc.

The reason why one might want to use some prototyping board is if they 
want to sell software to run on it or if they want to write software
for a year or more and thus wait for chips to come out/go extinct
by the date of their end design. I have done neither hence my
point of view.
But these two are quite valid reasons.

The main reason behind these boards being so popular is the fact
that the design decisions are taken by people who do not know what
they are doing so they don't have the confidence to design the
product and try to make it easier for themselves by using something
"readily available". Well guess what, using a board with an MCU
is _harder_ than using an MCU alone, it just looks easier to
people who can't figure out "how to open the box". And these
people are defining the market trend... as it has been throughout
history, the slowest ones define the pace of the group.

Dimiter

-=====================================================-
Dimiter Popoff, TGI             http://www.tgi-sci.com
-=====================================================-
http://www.flickr.com/photos/didi_tgi/

On Saturday, July 1, 2017 at 4:22:28 PM UTC-4, dp wrote:
> On 01.7.2017 г. 22:52, Dave Nadler wrote:
> > These boards are invaluable! On my desk I have one I used to bring up
> > most of a customer application, with stubs for the real hardware.
> > We sent a few to the end customer to debug their software against our
> > API before the real (hugely expensive) hardware was ready, and they
> > continue to use them for software development.
> 
> I understand they can be useful in your case where your goal is to
> sell just software, not a complete product. I have almost never been
> there hence my point of view.

No! We are making hardware products!
We used this eval board until real hardware was ready and working.
And we *still* use it when the expensive/huge real hardware isn't required.
For example when I have a rainy day at the races...
And the end-customer *still* uses it for working on their software,
with my simulation build loaded.

The cheapo eval boards are invaluable.
This is only the latest of many examples where I started projects
with these boards (from decades back when they were still expensive
and supported).