Electronics > Projects, Designs, and Technical Stuff

Best and Worst Component Manufacturers

<< < (6/7) > >>

coppercone2:
it fails under the absolute maximum @ rated temperature @ correct component choice?

bloguetronica:

--- Quote from: coppercone2 on January 29, 2019, 01:45:54 am ---it fails under the absolute maximum @ rated temperature @ correct component choice?

--- End quote ---
I've seen the TLV76050 failing at 24V supply, when in the datasheet says that it has over current ant thermal protection. Had one component failing mysteriously when supplying 30mA, and taking the rest of the components with it (which then became shorted). That failure occurred at a certain time, and the replacement component also failed (I think the board got damaged due to extensive heat, and something started to conduct, but it is still a mystery - excess flux residue somewhere?). Before failing, the first TLV76050 worked very well under the first 8 hours of operation.

As for the TPS55010, it simply failed after 5 minutes of idle operation. And that was on their evaluation board. The replacement also failed.

Kind regards, Samuel Lourenço

Gibson486:

--- Quote from: T3sl4co1l on January 28, 2019, 07:55:53 pm ---
--- Quote from: Gibson486 on January 28, 2019, 05:58:39 pm ---TI, on the other hand, has a great forum and the people who respond do a good job.

--- End quote ---

Either you've gotten lucky, or you asked about a fairly common problem, with a common answer.

I've never had a single question that was answered satisfactorily, typically taking three or four back-and-forth responses to insist on what it is I'm after.  Regardless of how much background, scope, detail or analysis I put in the original post.

So they can't read.  I doubt they are paid well enough to, anyway.  (If they were worth it, they'd be in the design department.)

Tim

--- End quote ---

Probably lucky. I asked about the noise density of their internal reference on one of their 32 bit ADCs. He responded back with graphs of data he personally took and even recommended me a better reference that they made if I ever needed it.  The op amp guys at TI, on the other hand, nope. Never answered my question.

IDEngineer:
I'll add another: NXP. I called an App Engineer asking for some obscure data for a discrete MOSFET. They'd never measured it so the guy said they couldn't offer any guidance. I thought that was the end of it, but many months later I got an email from them saying they'd recharacterized some parts, the one I'd asked about was on the list, and so they went ahead and characterized it for the parameters I'd asked about. Sent me a bunch of internal graph data and everything. The sad part was that, lacking the data originally, I ended up specifying another part. But that was serious followthrough in my book, and really improved my opinion of NXT. I've since bumped NXT up my informal list of preferred vendors and qualified more of their parts, largely in response to such great customer support.

Doctorandus_P:
I do not like the direction Atmel (now Microchip) has been going for some time.
20 odd years ago I switched to the Atmel AVR's because of GCC. It was in the begin days of FLASH uC's. They were also easy to program with open protocols. The first AVR I programmed was with a few resistors hanging from the LPT, to program a better AN910. I like that way of bootstrapping.

Lately it seems that Atmel developed another interface for programming their chips every year, and a lot of it is closed. One of their programmers, the EUR 50 "Dragon" was a fiasco, it regularly blew itself up unless connected to a powered USB hub.

The Fuse settings of their AVR processors are horrible. multiple bits squeezed into as less bytes as possible with weird combinations that change the meanings of other fuse bits.

Then the division between the "mega" and the "tiny" avr's. They are both small uC's for relatively simple applications but their peripherals are not compatible. You can not use an atmega I2C library (which atmel weirdly called "TWI") and use it on a "tiny". Some of the "tiny's" do not have a UART, but some horrible "USI", for which yet another library is needed, and which cost time and effort to get to know it, which is time I'd rather spend on writing real software. I also had a small uC project in which I needed I2C, selected an AVR and then later dicovered that the I2C pins were not slew-rate limited, which made the part useless. Without the limited slew rate, the much faster (but noisier) SPI was a better fit for that project, but needed extra software development time to separate the noise in time with the more sensitive stuff.

The amount of little insignificant differences in the timers is also pretty annoying.
I much prefer to see a description of a timer peripheral with a note in the datasheet. "there are 5 of these timers in this chip".

Then the pinouts. The ATmega328 has 28 pins, but no usable 8 bit port. The only 8-bit port it has is shared with the UsART, which is almost mandatory in each application and therefore not usable. Some of the smaller ATtiny's do have a usable 8-bit port, but then you get trapped into having to rewrite your libraries, which are for the Mega series.

Atmel "maintains" their own variant of GCC for the AVR's. but when I install gcc-avr with apt I get a version that is several years old.
Some of the microchip parts also use GCC, but they've hidden te source for their port very deep somewhere on their site. This does not instill confidence that GCC for the avr's will be distributed in a normal way anytime soon. I really don't want to go to some site, search through some menu structure, make an account or whatever just to download a C compiler with some support libraries.

These overall inconsistencies have added up to the point that I only use the Atmel AVR's I'm already familiar with (and fit my trusty USBasp), and am moving away from Atmel / Microchip for all uC projects those parts are not a good fit.

Over the years I've also killed 4 or 5 of the Cheap Chinese USBasp's. No biggy, just get the next one from the spare parts drawer. This would have been much more annoying with the Atmel programmers, which can easily cost EUR 100 each.
Some of the Atmel programmers also have unnecesarry small and fragile connectors which easily break and are hard to get cables for. Atmel wants EUR 20 for something which should have been a bog standard 0.1" IDC cable. But much worse is having to wait a few days to replace a broken cable.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

There was an error while thanking
Thanking...
Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod