The nuts at TI who write datasheets

On 12/06/2014 08:59 AM, Simon Clubley wrote:
> On 2014-12-06, Mel Wilson <mwilson@the-wire.com> wrote:
>> On Fri, 05 Dec 2014 11:11:49 -0800, John Speth wrote:
>>
>>> Is this how the race to the bottom ends?
>>
>> Similarly Atmel's PDF Data Sheets for AVR don't include the Table of
>> Contents sidebar anymore.  Just thumbnails.  "I need to know what's on a
>> page that looks kind of like that."
>>
>
> Is that yet another recent screwup by Atmel along with increasing the PDF
> sizes by several times over what they used to be ?
>
> As of a few months ago, the following document:
>
> Atmel-8271-8-bit-AVR-Microcontroller-ATmega48A-48PA-88A-88PA-168A-168PA-328-328P_datasheet_Complete.pdf
>
> still contained a TOC sidebar when viewed in Evince (I've just checked
> the version I have locally.)
>
> Simon.
>


I just downloaded the 32u4 data sheet and had to click Index under the 
View tab before I saw the table of contents. The default seems to be the 
rather useless thumbnails.

On Sat, 06 Dec 2014 13:02:06 -0600, Dennis wrote:

> I just downloaded the 32u4 data sheet and had to click Index under the
> View tab before I saw the table of contents. The default seems to be the
> rather useless thumbnails.

Ahh!  That changes everything!

	Mel.

On 12/6/2014 12:02 PM, Dennis wrote:
>> still contained a TOC sidebar when viewed in Evince (I've just checked
>> the version I have locally.)
>
> I just downloaded the 32u4 data sheet and had to click Index under the View tab
> before I saw the table of contents. The default seems to be the rather useless
> thumbnails.

When you create the document, you indicate its initial "view".  I create
thumbnails, etc. but only turn them on in the initial view if I think that
they will aid the reader in locating something -- or, gauging the
extent of the document (for first time readers)

On Fri, 05 Dec 2014 18:38:27 -0700, Don Y wrote:

> On 12/5/2014 5:47 PM, Tim Wescott wrote:
>> On Fri, 05 Dec 2014 13:10:49 -0700, Don Y wrote:
>>
>>> On 12/5/2014 12:11 PM, John Speth wrote:
>>>> Apparently the screwballs at TI think that incomplete data sheets are
>>>> acceptable to customers.  The TCA1116 is an I2C I/O expander.  The
>>>> data sheet on the TI web site and everywhere else I could find it
>>>> contains a cover sheet and packaging information.  The absence of
>>>> programming details is terrible. There's an invitation to get the
>>>> "full data sheet"
>>>> by emailing for it but the email bounces.
>>>>
>>>> Is this how the race to the bottom ends?
>>>
>>> Manufacturers have done this sort of thing for years.  Sometimes
>>> because they haven't made real silicon, yet.  Or, haven't committed to
>>> making *production* silicon.  Or, to gauge the size of the market (by
>>> noting how many people jump over the hurdle to contact them for the
>>> data).
>>> Or, to hide details from competitors. etc.
>>>
>>> Lately, however, it seems like they have decided on ways to cut costs
>>> (skip the documentation, let the bugs remain in the silicon, etc.).
>>>
>>> What pressure do they have to adopt other policies?
>>
>> Wanting engineers to keep using their stuff should create _some_
>> pressure.  Of course, the bean-counters have to be smart enough to
>> understand that a bean saved today may be a bushel basket full that
>> never gets harvested tomorrow -- but, they're bean-counters, so how can
>> you know?
> 
> A "design in" tends never to be a "design out".  When everyone is doing
> the same thing (wrt quality, support, etc.) what incentive do they have
> to add to their costs?
> 
> While you may be working on *a* design with device X, chances are,
> others in your organization are working on designs using components from
> the same vendor.  There's a lot of inertia to fight -- and reps can sew
> FUD with upper management, your peers, etc.  Change upsets the power
> balance in relationships.  Even if you want it, you will inevitably
> instill fear in others (that they will never EXPRESS as "fear" but their
> behavior will clearly indicate that this is what is happening)
> 
> When the MPU industry started, there was a LOT of diversity.  Not just N
> different variants of ARM, M variants of "x86", etc.  And, lots of
> support (documentation, etc.).
> 
> But, that didn't pan out for the vast majority of MPU vendors.  Their
> products just disappeared.  They weren't "improved" or "enhanced"...
> they just went away.  Designs gravitated towards specific processors and
> specific vendors.  "Motogorilla shops", "Intel shops", etc.
> 
> And, with tools costing many kilobucks, you didn't change processor
> vendors lightly.  "Multiple second sources" (a prerequisite for many of
> us, early on) gave way to tweaked versions of "familiar products".  Not
> enough of a change to cause all of your personnel resources to lose
> their value (hey, it's still an 8051!) but enough to ensure you would
> only be buying your silicon from that ONE vendor.  Are *any* products
> truly second-sourced any more?  (drop in replacements)
> 
> When the Motogorilla rep at a moto shop got wind that I was talking to
> TI, NatSemi, Intel and even DEC about processor choices for our next
> generation product, he was stunned:  "You mean I have to COMPETE to KEEP
> this account??"
> 
> Couple this with shortened development cycles and product lifetimes and
> who has the time/inclination/risk to head down a different path?
> 
>     "Can't you just MAKE it work?"

That sort of stuff just stretches the cycle out, but it doesn't kill it.  
Employees turn over, managers change.  Good processors get a toehold that 
crappy processors can't keep.

The length of the cycle means that a company that doesn't stay awake to 
the nuances gets itself into _deep_ shit before realizing it.

-- 
www.wescottdesign.com