CMOS vs TTL

[MarkT]

Of course CMOS scales to much faster clock rates with smaller processes and lower voltages - a 1.8V CMOS logic family would be interesting.

I have an old Sci Am special on microelectronics, published some time in the 80's - they forecast that I2L (integrated injection logic) would take over from MOSFET technology.  Never happened!

The other feature of TTL that ought to be mentioned is that the static power dissipation of gates is many orders of magnitude higher than CMOS (factor of millions I think) - this means TTL cannot be used for VLSI at all since the quiescent power dissipation would be measured in kW and MW.  A chip with 50 TTL gates on it is feasible, with a million gates: totally impossible.

[funkyguy4000]

Aren't FTDI chips TTL?  Such as the one and the arduino Duemilanove?

[JoeN]

Aren't FTDI chips TTL?  Such as the one and the arduino Duemilanove?

You mean this part?

http://www.ftdichip.com/Support/Documents/DataSheets/ICs/DS_FT232R.pdf

Though it interfaces CMOS to TTL, I can't see it being TTL.  Maybe BiCMOS?  The datasheet does not what technology the chip is made from.

[retrolefty]

Aren't FTDI chips TTL?  Such as the one and the arduino Duemilanove?

I think you would be hard pressed to find any mass produced IC developed in the last 10 years (perhaps even longer) that is bipolar (as pure TTL is based on) tech, rather then the various CMOS derived tech. Once they got the speed and output drive to be competitive with bipolar TTL, the other overwhelming features of CMOS made it the mainstream tech to use in IC development. I think newer bipolar IC designs are probably only used in few low volume specialized niche applications, it at all?

[davidhbrown]

I would suggest starting here:
https://www.google.com/search?q=difference+between+TTL+and+CMOS

Couldn't resist the thread necromancy to say that's almost exactly how I found _this_ page, 7+ years later :-)  (excepting I included the term 'Arduino'). Thank you all (belatedly) for your insights.

[Paul__B]

I think it is fair to say that now, seven years later, TTL (74LS) is completely obsolete.  Even for service replacement (just use a 74HCT part).  

[raschemmel]

As a follow up you might want to look up Don Lancaster's TTL COOKBOOK & CMOS COOKBOOK.

Most of these guys either have a tattered old copy or had one at one time and maybe gave it to their son
as a hand me down..


At least one of them will add:

or threw it in the trash !

[Smajdalf]

TTL (74LS) is completely obsolete.  Even for service replacement (just use a 74HCT part).

AFAIK unconnected TTL inputs are held safely HIGH. Unconnected CMOS input float even in HCT family. When you do the replacement in a circuit which rely on this feature...

[Grumpy_Mike]

AFAIK unconnected TTL inputs are held safely HIGH.

Well they float high, I wouldn't say it was safe because they are prone to EMI pickup in this mode. That is it is not a recommended operating configuration.

Ah, this is obviously some strange usage of the word 'safe' that I wasn't previously aware of.
Douglas Adams, Arthur Dent in "The Hitchhikers Guide to the Galaxy"

[Paul__B]

As a follow up you might want to look up Don Lancaster's TTL COOKBOOK & CMOS COOKBOOK.

Most of these guys either have a tattered old copy or had one at one time and maybe gave it to their son
as a hand me down..

Look it up you say?

Not actually necessary!

[Smajdalf]

Well they float high, I wouldn't say it was safe because they are prone to EMI pickup in this mode.

Unconnected pin has quite low capability for EMI pickup. I made a very loosely related "experiment". In my project I had standalone ATMega with reset pin unconnected. No reset was caused in about half a year. After adding a programming connector (about 10 cm of wire) there was a reset about monthly.

I would guess a floating TTL input is HIGH at least 99.9% of time. Any LOW period will be very short. I can imagine plenty of situations where this is no issue (i.e. Enable of a 7 segment LED display driver). OTOH HCT input may float to LOW for considerable time period.

But you are right, "safe" was not the best word to use there.