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.