On 2/20/2017 7:38 AM, Dave Nadler wrote:
> On Friday, February 17, 2017 at 8:40:03 PM UTC-5, Don Y wrote:
>> ... I'd expect part of the example to HIGHLIGHT the differences
>> in the execution environment. E.g., "need big heap to support
>> the allocations in this example (other example doesn't need ANY heap, etc.)"
>
> And you will be sadly disappointed.
I wouldn't doubt it. Rather, I'm indicating how examples can be used
*effectively*. Every (virtual or otherwise) "call to tech support"
bears a cost -- for the provider AND consumer! And, while consumers
ultimately pay all of the costs they "impose" on the provider, the
reverse is also true: providers eventually end up paying the costs
that they've forced/coerced on their consumers (in terms of product
satisfaction, loyalty, etc.)
Its not hard to create good examples -- it just requires the attitude
that there is intrinsic VALUE in the examples.
> I would love to see this in all examples,
> but even partial notes like this are pretty rare.
>
>> I usually start with crt0.s and the "helper routines". This removes
>> a lot of uncertainty from "what I'm seeing" (no need to wonder what lies
>> UNDER the examples) as well as gives me a general idea as to what the
>> vendor THINKS that I will be doing.
>
> The problem in this instance (and similar), is that there
> are many other parts of the puzzle...
I'm a hardware person, by nature. So, I immediately look at the lowest layers
of the software system to see what I can/should "expose" of the hardware and
what I should deliberately obscure. (e.g., in some cases, exposing the
underlying page size of the MMU is a win; in others, a useless detail).
>> I think you are being generous saying "misconfigured". While I can't
>> see how all these parameters are defined/established (code elided),
>> I can't imagine any way that the result (0x20005c0 IIRC) can rationally
>> come from the start/end/request of your example.
>
> There is no excuse for this kind of error.
> "Misconfigured" because this error is a combination of errors in ALL of:
> - linker file
> - library configuration (newlib)
> - external hooks provided as required to support library
> - overrides in project files for things like heap and stack size
> - unwitting use of library routines that use free storage
> - etc.
Undoubtedly "misconfigured". But, the code could have SCREAMED of this
instead of letting you "trip over" it.
// success
ASSERT( allocation != NULL )
ASSERT( allocation >= heap_start )
ASSERT( allocation+allocated_size-1 <= heap_start+heap_size-1 )
return( allocation )
This reinforces the module's contract with the caller (in ways that are
a lot more precise and explicit than a verbose textual "SYNOPSIS").
*And*, acts as a pair of watchful eyes during development ("How the
hell did *this* happen??")
>> Were you able to track down the source of the error?
>
> Of course, I had to get something working to the customer
> months ago! I will try to put together a web page explaining
> the components, and providing working examples for:
> - bare
> - FreeRTOS
The above sort of defensive coding would probably have rendered the
problem moot. But, if you're not the author/owner of the module...
One advantage to "owning the IP" is that you can impose this sort of
consistency on *everything*. So, if (when!) you reuse an algorithm,
you don't worry (as much) about these sorts of subtleties biting you.
[How would you document the requirements that malloc imposes on the
linker, support library, etc.? And, in a way that a new developer would
be sure to notice and implement? I.e., my solution is to let the
code do it for me lest some detail be overlooked (or unmaintained).
Esp valuable as you can "specify" lots of constraints when you have
a programming language available to you! :> ]
>> Sounds like the folks who pieced together the support didn't do
>> a very thorough job.
>
> Now you are being extremely charitable ;-)
Who is there to act as a "check" on them? The fab line, no doubt, has
inspectors ensuring the quality of the components they are producing.
Where is the equivalent for their documentation/support?
(Ans: user community. And, is anyone/corporate actively watching the
community's grumblings as a crude indication of the quality of the support
THEY are providing?)
>> IME, the folks who write the app notes (hardware/software) and these
>> sorts of "examples" aren't typically a "cherished resource". Perhaps
>> summer interns, fresh hires, etc. Company is focused on selling silicon,
>> not software. Only pays grudging lip service to the software in order
>> to get the hardware sold!
>
> In this case the support operation appears to be Chinese.
> Race to the lowest cost, quality be damned...
There can also be an impedance mismatch -- folks focused on building silicon
may not have the skillsets to understand *using* it!
We were car shopping, recently. The quality of the "tech" in modern vehicles
is abominable. You have to wonder how a "professional" could produce such
crap -- regardless of the hardware/cost constraints!
Obviously, the car manufacturers don't have that expertise and farm it out
to a third (fourth?) party. OK, that's understandable and likely makes good
business sense.
*But*, because they don't have the skillsets to understand what is possible,
they can't adequately evaluate the quality of the resulting product! And, the
chosen vendor (assuming he is NOT being unscrupulous) can rationalize away
any behaviors as LOGICAL consequences of the problem addressed.
E.g., I recently "misplaced" the local JCPenney store; couldn't recall on
which of several parallel streets it was located.
"Ah! Let the car's GPS give me the address -- no need for 'directions'
once I know which street its on!"
Type in JCPENNY [sic] and select from the menu presented... but, the street
names are all wrong!
"What the hell did I do wrong??"
Long story short (_Clue_: "Too late!"), the locations found were located in
OH (I'm in AZ). There's a difference between JCPENNeY and JCPENNY and the
search algorithm isn't smart enough to think: "What are the chances that
he really is looking for a destination 1500 miles away?"
Had this been demoed to an auto executive, the implementation would look
*perfect* -- it FOUND the "JCPENNY" that the user specified! Would the
auto executive have had the initiative to suggest this would likely
NOT have been what the user sought? Would he have thought of imposing
some sort of distance/travel time criteria on the result to check for
sanity?
"No results (JCPENNY) found within 100 miles. Expand search: Yes/No?"
[Or, better yet, a SOUNDEX implementation?]
>> I had a client show me his first pass of a hardware design to give me
>> an idea of where his project/product was headed. It was hard to
>> politely say, "This will NEVER work!" (it wasn't like it could be
>> tweaked A LITTLE to be viable).
>>
>> After gently pressing for details of portions of the circuitry, ("So,
>> what are you trying to do, here?") he eventually folded and said he'd
>> pieced it together from app notes. (OK, maybe he transcribed things
>> inappropriately or made unfounded assumptions at the boundaries of
>> each sub-design).
>>
>> When I later examined the "source app notes", the flaws were present
>> there, as well. I.e., no one had apparently ever BUILT the circuit that
>> was published! AND, no one had ever proofread the document with even
>> a rudimentary understanding of the material presented (lest they would
>> have found the errors before making it into print).
>
> I'll raise you one: I've seen the all of the above in a shipping product!
> Best app note blunder I've seen: serializer-deserializer note said the
> parallel lines had to have equal length traces!
> Think about that one for a bit. Witless non-engineer designed a board
> using low-end free CAD trying to do this...
I watched an engineer design a ~8x10 multilayer board covered with DIP switches
to configure his product (which was another board) -- in a MICROPROCESSOR
CONTROLLED DEVICE (didn't it occur to him that the processor could do this
stuff *for* him and improve the UX?)
"Impedance mismatch"
>> I learned that when I document things, I have to cut and paste the
>> ACTUAL source materials into the final/formal document -- to ensure
>> no transcription errors AND that the design/circuit/code is EXACTLY
>> as I'd implemented.
>
> And deliver the PDF component spec sheets with annotations appropriate
> to the part usage in the design...
I approach that by creating a "circuit description" document. This lets me
speak less formally -- but more specifically -- about what I did and why I
made specific design choices. Often, The Next Guy may not have the focus to
think-ahead to all of the potential issues that he (now "his" product) may
encounter. Having a forum where I can speak to him avoids his faulty
"optimization" of my design (i.e., removing things whose purpose he doesn't
immediately grasp) :>
Of course, the same is true of software: "Here, there be dragons" *should*
ratchet-up the reader's attention!
>> Returning to my final queries: is the reason the client wants to move
>> to Kinetis/FS parts because of the "support quality" on the NXP parts?
>
> A combination of factors: tools and documentation not updated for 2+
> years, bugs everywhere, extremely poor examples, miserable support,
> and worries about the future of Kinetis product line after years of
> Freescale austerity, NXP merger, and upcoming potential Qualcomm merger.
> Utter disarray with the tools: Freescale started with their "Processor
> Expert" component system, discontinued it for a new SDK, released an
> updated SDK with numerous undocumented incompatibilities, the examples
> and documentation do not use the current tool set, etc.
So, you're (they're) unhappy with the *provider*, not the *product*.
But, mainly from the support side of the picture (i.e., its not like
you're having a hard time getting parts or defects in the parts
themselves).
I.e., why buy from Walmart when you can buy from Costco?
Sad as they *could* fix this by throwing some resources at the problem.
But, until they see a cost to NOT doing that, it is unlikely that they
ever will! :-(
> The hardware is extremely capable, but challenging to use with the
> above issues... NXP is threatening to release support based on their
> Expresso Eclipse (replacing the Kinetis Development System Eclipse),
> and rationalizing their tool support this spring. We'll see how that
> goes. I did a couple products using NXP Cortex M0 a few years ago
> and had good experience with the NXP tools (and support when their were
> tool issues)...
I'm pretty much "stuck" having to roll my own tools as my execution
environment isn't typical (distributed multiprocessors, task migration,
etc.). So, I lose a lot of "pretty" (that would be available in fleshier
toolsets) but gain a lot of "essential" (that would have been absent, for
my environment, in those verysame toolsets)!
[Eventually, I'll have to make this stuff "ready for primetime" but that's
low on the priority list... only so many hours in a day!]