Live data from Hacker News

New Texas Instruments 5532 chips are not the 5532s we’ve used for decades

groupdiy.com

51–59 of 59 posts

Re: New Texas Instruments 5532 chips are not the 5532s we’ve used for decades

#51
post #27

Earlier quoted context omitted.

Kind of. I want all 7400s to be four NAND gates, regardless of how they are implemented. As long as the results are correct, you might as well put a little ARM controller pretending to be four NAND gates. For analog parts, I agree any change to the data sheet should receive at least a different suffix letter.

I disagree. At a certain moment you start to rely on behavior, knowingly or unknowingly. These kind of changes might surface bugs that you never had. https://xkcd.com/1172/

In software, this is known as Hyrum's Law: https://www.hyrumslaw.com/

Re: New Texas Instruments 5532 chips are not the 5532s we’ve used for decades

#54
post #15
post #7

Earlier quoted context omitted.

It annoys me too but part numbers are not a spec but more of a strong hint. The attitude of the industry is that it’s up to you to read data sheets carefully and test. Even for a 2N2222 or whatever.

Keeping in mind, though, that this is a jellybean part. You're supposed to be able to order "a" 5532 without specifying the supplier, because many vendors produce "a" 5532, and they're all the same. Different vendors' 5532s are supposed to be able to be treated as the same SKU — literally dumped into co-mingled stock in warehouses — with no ill consequence! (And yes, until TI's recent move, that was true of the 5532.…

> Different vendors' 5532s are supposed to be able to be treated as the same SKU — literally dumped into co-mingled stock in warehouses — with no ill consequence!

That may be true for a small webshop or a brick-and-mortar electronics store (what few of those still exist). Or be true for end users / manufacturers of equipment that includes such a part.

But (afaik) that's not how it works for large reputable distributors like Mouser, Digikey & co. You don't order a generic "5532" there, you order a 5532 from there. Part from manufacturer A may, or may not be interchangeable with same-numbered part from manufacturer B. There's even some parts that have same # but very different function between manufacturers. In other words: buyers, designers do your homework.

Likewise in a design, if you specify "5532" that should read as "any manufacturer's 5532 should do". If not (or unsure / untested), one should specify the part including its manufacturer. Or a list of acceptable manufacturer/part# combo's.

Ofcourse changing the spec significantly for a jellybean part like discussed here (and one with many 2nd sources), that's just evil. Change a part like that, give it its own part #.

Re: New Texas Instruments 5532 chips are not the 5532s we’ve used for decades

#55
post #4

This sort of thing really annoys me. Part numbers are for use of engineers, not for the marketing dept. If you change the specs, change the part number.

> If you change the specs, change the part number.

They took it from SW. You know this joke with "Windows is a single platform" ? Or the joke with "use rust if you can compile it" ? Or "your browser version is not supported" ?

Enshitification reaches everything.

Re: New Texas Instruments 5532 chips are not the 5532s we’ve used for decades

#56
post #15
post #7

Earlier quoted context omitted.

It annoys me too but part numbers are not a spec but more of a strong hint. The attitude of the industry is that it’s up to you to read data sheets carefully and test. Even for a 2N2222 or whatever.

Keeping in mind, though, that this is a jellybean part. You're supposed to be able to order "a" 5532 without specifying the supplier, because many vendors produce "a" 5532, and they're all the same. Different vendors' 5532s are supposed to be able to be treated as the same SKU — literally dumped into co-mingled stock in warehouses — with no ill consequence! (And yes, until TI's recent move, that was true of the 5532.…

>You're supposed to be able to order "a" 5532 without specifying the supplier

This is not true.

>because many vendors produce "a" 5532

This is true, in the sense of a "5532-type part". But you will note that all the 5532 variants have different manufacturer's part numbers (prefixes and suffixes) to prevent this confusion. They don't just do that for branding.

>and they're all the same.

This is emphatically and trivially not true, and it tells me you haven't done the work of carefully comparing data sheet specs across suppliers. Try it, you'll learn something.

>Different vendors' 5532s are supposed to be able to be treated as the same SKU — literally dumped into co-mingled stock in warehouses — with no ill consequence!

That might happen somewhere, but authorized distributors do not do this and volume manufacturers do not do this. You might have an internal part number with an authorized suppliers list that includes more than one variant of 5532 that has been vetted for production.

>And yes, until TI's recent move, that was true of the 5532. All the other vendors' 5532s had matching datasheet specs

Again, emphatically and trivially not true. Take a careful look at the NJM and On Semi data sheets. Spec by spec. Do the work and be amazed.

>the warehouse they're sourcing from has comingled any TI 5532s into the general 5532 stock

Authorized distributors do not do this. It gets hairy when you're sourcing NOS from grey market dealers for old designs or in severe part crunches like 2020-2022 era, but that's a different story.

>no real recourse except to change your entirely supply chain to one that specifically excludes TI

This concept is backwards. You would have an internal part number for 5532-type op amp, and it would have an authorized vendors list that would only include vetted parts. "Any 5532 but TI" is asking for trouble from someone else.

And parts do change or get updated and if you are buying from authorized distributors for production you and your supply chain and quality people will get product change notices. At that point it's your job (or the component engineer's, if you're fortunate enough to have one) to validate the new version or find a suitable alternate.

Re: New Texas Instruments 5532 chips are not the 5532s we’ve used for decades

#57
post #44

There are better and superior alternative of NE5532 these days. People should just move on. OPA1612 is the king in highest-end audio performance, at least on datasheet paper.

The ne5532 is not an awesome part by any means.

It is a decent part, and an extremely popular one found in loads of designs.

There's the saying anything you hear has passed through a pack of those before reaching your ears.

This is why it is so bad for TI to change the specs without changing the part number.

Re: New Texas Instruments 5532 chips are not the 5532s we’ve used for decades

#58
post #10

Earlier quoted context omitted.

Why do companies always do this? Always the largest companies with all the money to quietly host what at most a couple hundred mb of data and they just don't. Kill the old download links. Ruin all the old support articles that point to those old download links. Ruin all the old forum posts that point there. What is even crazier is sometimes they still have the files they just don't expose them, they make you beg for…

Because they're changing out their backend CMS and have deemed it too expensive to port ask three old documentation over.

Does not explain the attempts to scrub from archives.

Re: New Texas Instruments 5532 chips are not the 5532s we’ve used for decades

#59
post #40

This is the electronics equivalent of Python3's breaking changes to string handling. It's pure evil, and will have 2nd order effects for decades.

Because unicode and f-string replacements in an open source project are the devil and have completely similar parallels to a proprietary hardware chiplet being altered without any recourse? Axe grind me harder daddy.

Unicode isn't the devil. Deliberately break compatibility and forcing everyone to rewrite code is. There were compatible ways to do it, but political correctness won out.

>Axe grind me harder daddy.

My axes are ambient authority based operating systems, programmers who call themselves engineers, and case sensitive programming languages. Unicode is fine, just don't take away my ASCII. ;-)

Post reply on HN