PIC Oder AVR?

AVR ganz klooaaar!!!!!!!!!!!

MSP430 :)

8051

AVR packt mansches nicht was ich aber benötige..
also PIC16<=PIC18 :)

AVR, PIC24/33

eh schrieb:
> Die AVR packen auch einiges nicht, oder zuwenig. Daher bin ich nun am
> Umsteigen auf den AVR32. Der hat echt viel mehr Dampf. 64 MHz Whoa....

Ich steig z.z. auf Cortex um, 75MHz für ~10Eier Wuhaa ;)

Ich als Elektronik-Anfänger mit Assembler-Kenntnissen (x86, m68k) hab 
mich für meine Experimentiererei und Spielerei für die AVRs entschieden, 
im Wesentlichen wegen des aus meiner Sicht einfacheren und 
übersichtlicheren Assembler-Befehlssatzes. Das zweite Kriterium war das 
Vorhandensein einer freien Toolchain (avr-gcc et al.) und freier Tools 
(z.B. avrdude), die unter Linux laufen.

Stephan

das ist dann der Thread Nr. 2549834 über das Thema ...

soll der Dachdecker nun links oder rechts das Dach runter steigen?
Antwort: Da wo die Leiter steht ist angenehmer

Beteilige mich nur ungern an Glaubensfragen, nutze aber 8051-Architektur
und seit die 20 MIPS können, wow!

Gruß
RABIS

Weder noch. ST7 regelt. Thread würde besser nach /OT passen.

Kann nicht mal jemand diesem Thema den Gnadenstoß geben?! Das ist so 
alt, das  ist doch schon ein Zombie.

Meine Wahl der Waffe: Das FPGA! Damit kann man sich das beste aus allen 
Architekturen raussuchen und einen eigenen µController basteln.

Brandt schrieb:
> Natürlich PIC18Fxxxx
>
> Arbeitet auch in schwierigen Umgebungen stabil. Seine Software läßt sich
> auch im eingebauten Zustand leicht ändern. Gut zu beschaffen.
> Übersichtlicher Befehlssatz. Viele Typen der Familie sind zueinander
> pinkompatibel.

Das trifft bloß alles auch auf die AVRs zu.

Wobei ich den AVR-Befehlssatz übersichtlicher finde, er hat keine als 
Memoryzugriffe getarnten Befehle.


Peter

Tach!

Als ich mich damals zwischen AVR und PIC entscheiden musste, hat für 
mich der Befehlssatz den Ausschlag gegeben.

Wenn man nunmal das Assamblen auf x86 Architekturen gewöhnt ist, bekommt 
man schon ziemlich große Augen, wenn man sich die PIC Dokus durchliest.

Von der Hardware her sind AVR und PIC allerdings weitestgehen gleich. 
Zumindest ist mir noch kein Pic-Board untergekommen, dass ich nicht auch 
mit einem AVR hätte betreiben können.


In letzter Zeit fällt mir allerdings auf, das Atmel's 8-bit Ecke immer 
mehr zurückbleibt. Scheinbar werden Entwicklungskapazitäten von den 
AVR's abgezogen. Im Vergleich zu den TI MCUs sehen die AVR's schon 
ziemlich alt aus(das meine ich wortwörtlich). Wie das bei Microchip 
aussieht weis ich nicht, vielleicht kann sich dazu ja mal ein 
eingefleischter PICel äußern.

Die meisten Firmen konzentrieren sich momentan auf die Entwicklung von 
32bit CPUs. Die ARM Architekturen entsprechen da dem Zeitgeist.

Thor

Hallöle miteinander,

Diese Frage ob fruchtig oder sahnig verwirrt mich ein wenig, denn ich 
bin ein PICler. Hm die AVR`s haben 130 Befehle was wohl an diesen 16 
speziellen
16 Registern liegt. Das haben die PIC's bis 18f nunmal nicht, haben aber 
auch so um die 80 Befehle und ganz viel Peripherie.
Die AVR's haben bis 20 MIPS denke ich und PIC18f mit "J" bis 16.
Ja und genau diese 4 MIPS imponieren schon ein ganz klein wenig.

Mein Traum ist ja ein "picklicher" Synhtie auf 8 Bit Basis, doch da ist 
Befehlsdurchsatz unabdingbar.
Also was ich sagen will AVR's sind gut, PIC's aber auch!


PS: auch ein AVR darf in meinem Bauteilevorrat PLatz einnehmen.

PICs, weil ich möglichst schnell ans ziel kommen will, und weil gute 
dokus und erratas vom hersteller bereit gestellt werden und ich mir dies 
nicht erst durch diverse beiträge von benutzern in foren zusammenlesen 
will.

Wie in allen Glaubensfragen sollten man idealerweise für anderes offen 
sein.

Meine Prozessorauswahl:

- Anwendungsfall: Geschwindigkeit, Portanzahl, interne Schnickschnacks 
(Zusatzkomponenten)...
- Kostenfaktor: Möglichst günstig (relativ) und für Privatpersonen 
beschaffbar.
- Für privatpersonen günstige Programmierhardware muss verfügbar sein.
- Für privatpersonen günstige Programmiersoftware muss verfügbar sein.
- Möglichst große Bandbreite an Prozessoren mit der selben 
Hard-/Software programmierbar (ich möchte keine 1000 Programmer für 1000 
Prozessoren im Schrank haben).
- Es muss Dokumentation in ausreichender Menge verfügbar sein.
- Gut ist eine große Community bei eventuellen Problemen/Fragen.

Ich habe mit 6502 und 8051 angefangen, hatte mich kurz mit PICs 
beschäftigt und bin zur Zeit bei AVR angekommen. Gibt es aber für meine 
Projekte PICs die "besser" geeignet sind, habe ich nichts dagegen 
einzuwenden, diese zu verwenden.

Ich programmiere entweder in C oder in Assembler (oder beides 
gleichzeitig) - je nach Erfordernis.

Brandt schrieb:
> Geht man beim direkten Vergleich allerdings etwas in die Tiefe, dann
> gehen die PIC18Fxxxx als Punktsieger hervor:

Was ist das für eine Aussage?
Was meinst Du mit tief?

> Bei den PICs findet sich ein größeres Produktspektrum, was bei den
> einschlägigen Distributoren auch wirklich lieferbar ist.

Die Frage ist aber, welches Produktspektrum braucht man.
Hast Du mal ne Aufgabe, für die es einen PIC, aber keinen lieferbaren 
AVR gibt?

> Zur Stabilität
> unter schwierigen Bedingungen können Euch Leute etwas verraten, die in
> EMV-Labors arbeiten.

Es mag da marginale Unterschiede geben, aber bei nem vernünftigen Layout 
ist mir noch kein AVR abgestürzt.

> Ansonsten meine Frage: habt Ihr schon mal AVRs in 10 Meter Höhe unter
> absolut widrigen Umständen umprogrammiert? Mit PICs geht das problemlos.

Auch AVRs sind in jeder Höhe problemlos zu programmieren.
Sie haben doch keinen Höhensensor eingebaut, der das Programmieren 
erschwert.
Wenn ein AVR aber schwer zugänglich ist, programmiert man besser nen 
Bootloader rein, z.B. über CAN, RS-485 oder auch Funk.


Peter

Brandt schrieb:

> Zur Stabilität
> unter schwierigen Bedingungen können Euch Leute etwas verraten, die in
> EMV-Labors arbeiten.

Wie siehts mit ESD und Co aus?
Ich habe schon 2 PICs geschossen (von rund 8 jemals verwendeten!), den 
einen wohl durch ESD (oder er wahr schon defekt), den anderen durch ein 
um ein Pin versetztes Einsetzen in den Sockel.
Sowas ist mir bisher noch mir keinem anderen µC passiert, und die haben 
schon weitaus schlimmeres ertragen müssen. Von daher kann ich das nicht 
ganz glauben dass die neueren PICs EMV mäßig so gut sein sollen, wenn 
die schon bei sowas kaputt gehen.
Die alten eventuell schon, aber das liegt dann ganz einfach an der 
groben Struktur. Daher sind 8051er auch EMV unempfindlicher als AVRs.

Oje..

Mein PIC habe ich gestern versehentlich mit 12V 200mA am TX Pin gequält, 
dem hats nicht einmal gejuckt. Und falls ich mal ein PIN wirklich kaputt 
bekomme dann nutz ich einfach den nächsten.. (Schafft sowas ein AVR 
auch?)

Die PIC`s haben zudem ein etwas schnelleren ADC was bei manschen 
anwendungen besser ist.

Sie haben ab PIC18 einen 8x8 HW-Multiplikator der in einem Cyclus 
rechnet, ab dsPIC sogar noch viel mehr solcher ein cyclen Spielchen.

Man hat die Qual der Wahl unter den Prozessoren, Jenachdem was man 
Benötigt findet man auch einen und spart sich ggf. externe Bauteile.

Ich benötige am Quarz keine Kondensatoren.

Programieren geht bei AVR und PIC gleichermaßen einfach!!

Welche größeren Vorteile ein AVR hat außer das er etwas schneller als 
PIC18 (Welches 8x8HW-Mult. wieder weg macht) ist ist mir schleierhaft. 
aber vll. hat jemmand mal lust mir die Wirklichen vorteile vom AVR 
anzuvertrauen. (Softwaremäßig ausgeschlossen)

lg

Christian --- schrieb:
> (Schafft sowas ein AVR auch?)

Ja, bei den neuern Low Power Version wirds aber kritisch, was aber 
normal bei den kleineren Strukturen ist.

> Welche größeren Vorteile ein AVR hat außer das er etwas schneller als
> PIC18 (Welches 8x8HW-Mult. wieder weg macht) ist ist mir schleierhaft.

AVRs haben auch einen 8x8 HW Multiplizierer. Der braucht zwar 2 Takte, 
aber das ist kein wirklicher Unterschied.

> aber vll. hat jemmand mal lust mir die Wirklichen vorteile vom AVR
> anzuvertrauen. (Softwaremäßig ausgeschlossen)

Es gibt keine echten Vorteile (außer vielleicht dass es einen gcc 
Compiler dafür gibt), allerdings auch keine Nachteile. Die PIC18 und die 
AVRs sind vergleichbar. In manchen Punkten hat der eine seine Stärken, 
in anderen wiederum der andere. Am Ende läufts darauf hinaus, dass es 
kaum eine Anwendung gibt die nur mit einem von beiden machbar ist.

Von daher ist diese Diskussion eigentlich hinfällig.

PIC und Cortex M3

Wo kriegt man eigentlich die low voltage Versionen der PICs, ausser 
natürlich bei Digikey&Co oder Microchip direkt? Die sind mir im 
Unterschied zu den entsprechenden Versionen der AVRs kaum je begegnet.

Benedikt K. schrieb:
> Von daher ist diese Diskussion eigentlich hinfällig.

Jo, find ich auch...

Schon etwas von Beifahrern gehört?

Brandt schrieb:
> Hallo Moderatoren,
> ich sehe gerade, dass ein Beitrag von einem AVR-Befürworter gelöscht
> wurde.
> Warum macht Ihr sowas?

Fehlalarm. Das habe ich selber gemacht, weil mir auffiel, dass ich  Mist 
geschrieben hatte.

Ich hatte einen dummen Kommentar abgegeben, ob der PIC auf Zuruf 
programmiert wurde, bis mir auffiel, dass Du auf die lange 
Programmierleitung und nicht die Höhe meintest. Daraufhin hatte ich 
alles gelöscht.

Hi,

ich verwende neben ARM, div. 8051 derrivaten, dazu noch M68 und MCS48 
(beide natürlich nur noch für Altgerätesupport) auch AVR und PIC!

Wie schon angedeutet gibt es KEINE allgemeingültige Aussage welcher nun 
die bessere Lösung ist. Das hängt stark vom Anwendungszweck UND den 
Randbedingungen ab...

Viele der hier genannten Argumente treffen, auch wenn es manchmal anders 
aussieht, auf beide Familien zu: Es ist keinesfalls so das die 
Programmierhardware der PICs auc im Selbstbau immer kompliziert ist.
Wenn es nur um das reine Brennen geht, so ahbe ich das vor 14 Jahren 
schon mit 2-3 Wiederständen, einem Transistor und einem elko an der Ser. 
Schnittstelle gemacht.
Allerdings kann ich bei vielen Pics mit vertretbaren Mehraufwand gleich 
die Debug Funktionalität mit reinbringen - Dies siegt dann natürlcih ein 
wenig komplizierter aus.

Wenn ich die vom Hersteller angebotenen Programmiergeräte vergleiche, so 
bekomme ich für ca. 30 Eur. im Moment von µChip den PicKit3 der fast 
alles Proggen und viel Debuggen kann.
Bei Atmel liege ich mit dem Einfachen Interface AVRISP2 auch bei 29 
Eur.,
Debuggen kann ich damit aber nicht.

Wie es mit den besseren "Programmern" beider hersteller im vergleich 
aussieht kann ich nicht sagen. Habe da nur noch einen ICD2 NAchbau...

Der große Beliebtheitsgrad den die Atmel im Moment haben beruht eher auf 
der Tatsache das für diese schon viel früher ein kostenloder C Compiler 
verfügbar war, wo man für PIC - C Compiler noch richtig Geld lassen 
musste!
Microchip hat das wirklich verpennt.
Anfänger die keine Lust hatten wirklich noch in Assembler loszulegen 
wurden so natürlich abgeschreckt. Dadaurch gibt es erheblich mehr 
Beispielprojekte mit Atmel...

Darüberhinaus hatte Atmel sich zu der Zeit ja schon früh mit seinen 
"wenigen" aber Leistungsstarken Typen einen Namen gemacht, was für 
Hobbybastler natürlich sehr vorteilhaft ist. Man braucht nur einen oder 
zwei Typen auf Lager und kann sofort mit fast allem Loslegen. Sind die 
zu groß fängt man mit den Großen an, und arbeitet schon mal ein wenig 
bis die Tinys eintreffen.

Microhip hat dagegen eine riesen Programmpalette wo es fast möglich ist 
ähnlich wie im Baukastensystem nach "SEINEN Anforderungen" zu suchen.
Darüberhinaus bekomme ich auch als Hobbybastler JEDEN PIC jederzeit auch 
als Einzelstück geliefert, was bei Atmel objektiv nicht möglich ist.

Peter Dannegger schrieb:
> Die Frage ist aber, welches Produktspektrum braucht man.
> Hast Du mal ne Aufgabe, für die es einen PIC, aber keinen lieferbaren
> AVR gibt?
JA Bitte: Aus eigener Erfahrung:
Controller mit USB Schnittstelle, zwecks Nachbausicherheit/Handling im 
DIP Gehäuse...

Und selbst wenn man die Anforderung DIP weglässt:
Schon mal versucht einen solchen Controller als Hobbybastler in DL zu 
bekommen? Mit etwas Glück bei einigen Spezial-/ oder Spartenversendern, 
wobei die dann oft aber auch nur ein oder zwei Typen im Programm haben.
Den damals benötigten habe ich nicht bekommen, selbst über die Distris 
war nichts zu machen...
Die PIC Gegenstücke bekomme ich bei allen gängigen Versendern...

Nur um EIN Beispiel von vielen zu nennen...

Aber wie gesagt, ich bin nicht grundsätzlich "für" Pic und "gegen" 
Atmel.
Ich setze beide ein und entscheide vor jedem Projekt erneut welche 
Familie ich nehme. Da in in letzter Zeit aber oft auf spezialfunktionen 
angewiesen war, kam im letzten Jahr aber eigendlich nur PIC zum zuge. 
Atmel war nur mit den ARM vertreten...

Für jemand anderes mit anderem Einsatzzweck können aber AVRs in der 
Mehrzahl der Fälle auch objektiv die besseren sein!

Gruß
Carsten

Carsten Sch. schrieb:
> Controller mit USB Schnittstelle, zwecks Nachbausicherheit/Handling im
> DIP Gehäuse...

Stimmt, Atmel bietet nicht alle AVRs auch im DIP an.


> Schon mal versucht einen solchen Controller als Hobbybastler in DL zu
> bekommen?

Z.B. CSD hat den AT90USB162 und AT90USB1287.


Peter

Peter Dannegger schrieb:

> Stimmt, Atmel bietet nicht alle AVRs auch im DIP an.

Bietet Microchip eigentlich 64- oder 100-pinnige DIPs an? :-)

(Der einzige DIP-64, den ich je gesehen habe, war der MC68000.  Das
war vielleicht ein Klopper.)

AVR

Jörg Wunsch schrieb:
> Bietet Microchip eigentlich 64- oder 100-pinnige DIPs an? :-)

Nein, max DIP40.

Aber 128kByte Flash 16kbyte SRAM und ein 40MIPs, 16bit DSP in einem 
DIP28 Gehäuse ist heutzutage nicht unbedingt Standard.
Das mit den Gehäusen ist aber nicht nur bei µCern so, nahezu alle ICs 
von Microchip sind neben SMD auch noch in DIP erhältlich, was vor allem 
Prototypen etwas vereinfacht.
Bei anderen Herstellern kann man dagegen schon froh sein, wenn das IC 
überhaupt in irgendwas per lötbarem erhältlich ist.

Benedikt K. schrieb:

>> Bietet Microchip eigentlich 64- oder 100-pinnige DIPs an? :-)

> Nein, max DIP40.

War doch nur Spaß, ich wollte nur darauf hinaus, dass es rein
technologisch gar nicht möglich/sinnvoll ist, jeden IC auch noch
partout in DIP zu verlangen.

> Das mit den Gehäusen ist aber nicht nur bei µCern so, nahezu alle ICs
> von Microchip sind neben SMD auch noch in DIP erhältlich, was vor allem
> Prototypen etwas vereinfacht.

Spätestens bei höheren Taktfrequenzen ist aber DIP einfach mal
komplett untauglich.  Ich finde an QFPs mit 0,8- oder 0,65-mm-Raster
übrigens nichts, warum man das Zeug deshalb als ,,bastlerunfreundlich''
titulieren müsste.  Bei 0,5-mm-Raster wird's dann schon fummelig, ist
aber die einzige Variante, wie man viele Pins überhaupt noch normal
lötbar unterbringen kann.

Aber Georg Acher hat uns schon vor nunmehr 7 Jahren vorgemacht, dass
auch BGAs kein Hindernis für einen ambitionierten Bastler sein müssen:

http://www.lrr.in.tum.de/~acher/bga/index.html

:-)

Hi,

> War doch nur Spaß, ich wollte nur darauf hinaus, dass es rein
> technologisch gar nicht möglich/sinnvoll ist, jeden IC auch noch
> partout in DIP zu verlangen.

Das ist klar, irgendwann macht es einfach keinen Sinn mehr. Auch von 
Microcip bekommst du lange nicht alles im DIP!
Aber das wo es möglich ist, das Bekommst du Problemlos...

Und eine Begründung warum es problemlos möglich ist z.b. einen ATMEGA16 
im normalen DIP Gehäuse anzubieten, denselben aber mit USB Schnittstelle 
nicht mehr, die fällt mir nicht ein.

Und wenn ich überlege das ich mein erstes USB Device mit µChip 
Kontroller in <10 Min. auf Lochraster aufgebaut hatte und die Hello Welt 
FW in 5min lief, dann ist das sicherlich "Nachbausicher".

Der µC hatte 20Pins, das geht als DIP prima!
>
>> Das mit den Gehäusen ist aber nicht nur bei µCern so, nahezu alle ICs
>> von Microchip sind neben SMD auch noch in DIP erhältlich, was vor allem
>> Prototypen etwas vereinfacht.
>
> Spätestens bei höheren Taktfrequenzen ist aber DIP einfach mal
> komplett untauglich.  Ich finde an QFPs mit 0,8- oder 0,65-mm-Raster
> übrigens nichts, warum man das Zeug deshalb als ,,bastlerunfreundlich''
> titulieren müsste.  Bei 0,5-mm-Raster wird's dann schon fummelig, ist
> aber die einzige Variante, wie man viele Pins überhaupt noch normal
> lötbar unterbringen kann.

Natürlich ist es so, das du (und auch ich) wie einige andere Hier das 
hinbekommen. Aber man muss ja immer auch die "Einsteiger" im Blick 
haben.
für QFPs u.ä. brauche ich eigendlich IMMER eine gedruckte Schaltung. Mit 
schnell mal ebend etwas auf LR ausprobieren ist da nicht!
(Manchmal kann man sich noch mit auflöten auf Adaptern helfen, aber die 
muss man auch erst kufen/ätzen und es geht nicht immer)

Nur hat nicht jeder die Möglichkeit sich seine Platinen selber 
herzustellen. Und für einen ersten Prototyp einer privaten Bastellei ist 
die fertigung beim Lohnunternehmer einfach zu teuer!

Daher ist es schon sehr vorteilhaft, wenn ich für eine bestimmte 
Funktionalität zumindest Basisversionen im DIP bekommen kann!
Das nicht alles geht oder Sinn macht ist ja selbstverständlich!

Gruß
Carsten

Jörg Wunsch schrieb:

> Spätestens bei höheren Taktfrequenzen ist aber DIP einfach mal
> komplett untauglich.

Wobei es dem Gehäuse ziemlich egal ist, wieviele MHz drinnen Elektronen 
herumschubsen. 100MHz auf I/O-Pins brauche ich nicht, aber mir wäre es 
durchaus recht gewesen, wenn NXP den LPC2103 wie angekündigt auch als 
PLC44 rausgebracht hätte. Besserer Mega32 sozusagen.

Jörg Wunsch schrieb:
> Bei 0,5-mm-Raster wird's dann schon fummelig, ist
> aber die einzige Variante, wie man viele Pins überhaupt noch normal
> lötbar unterbringen kann.

Ja, das finde ich an den PIC32 nervig:
Microchip hat es bei den 16bit PICs geschafft, alle pinkompatibel zu 
machen, also egal ob man ein 24Fxxx PIC mit USB, ein normaler 24H PIC 
oder einen 33F dsPIC verwendet, alle haben die gleiche 
Anschlussbelegung. Und da auch die Peripherie großteils identisch ist, 
kann man zur Not die Software auch mal auf einem anderen Controller 
entwickeln bis der eigentlichen Typ dann endlich eintrifft. Das ist auch 
ein schöner Vorteil von denen. Nur bei den PIC32 mussten die von 0,5mm 
Pitch auf 0,4mm Pitch gehen...

> Aber Georg Acher hat uns schon vor nunmehr 7 Jahren vorgemacht, dass
> auch BGAs kein Hindernis für einen ambitionierten Bastler sein müssen:

Das Hauptproblem bei sowas ist: Wenn ich irgendeine Schaltung entwickle, 
hätte ich zumindest gerne eine Hardware die 100%ig richtig gelötet ist. 
Vor allem bei Prototypen gibts nichts schlimmeres wie die Suche nach dem 
Fehler:
Liegt er in der Software, in der Hardware, oder ist nur irgendein Pin 
nicht gelötet (was bei BGA nicht leicht zu prüfen ist)?

Carsten Sch. schrieb:

> Und eine Begründung warum es problemlos möglich ist z.b. einen ATMEGA16
> im normalen DIP Gehäuse anzubieten, denselben aber mit USB Schnittstelle
> nicht mehr, die fällt mir nicht ein.

Ich schon (weiß aber nicht, ob das hier zutrifft): wenn der Chip
zu klein ist.  Beide Controller müssen nicht notwendigerweise in
der gleichen Technologie gefertigt sein.  Wenn nun beispielsweise
der USB-Chip in einer kleineren Technologie gefertigt wird, dann
wird sein Chip kleiner.  Da kann es dann passieren, dass das Teil
nicht mehr in einen Standard-Leadframe eines DIP-40 passt, da es
eine maximal zulässige Bonddrahtlänge gibt.  (Der Leadframe ist das
Metallgerüst mit den Pins.)  Damit wäre aber plötzlich das DIP-40-
Gehäuse (das dem Hersteller ja keinerlei Gewinn bringt, da er davon
nie Stückzahlen verkaufen wird) ein Sondergehäuse mit Extrakosten...

Wie gesagt, keine Ahnung, ob das so ist.  Das soll nur mal andeuten,
dass es da technologisch manchmal schon Gründe geben kann.

Ich glaube, wir müssen uns einfach damit abfinden, dass DIP über
kurz oder lang aussterben wird.  Das wird nicht in den nächsten 5
Jahren sein, aber ich bin davon überzeugt, dass das passieren wird,
vielleicht bis auf wenige Sonderbauelemente wie solchen im
Hochspannungsbereich.

A. K. schrieb:

> Wobei es dem Gehäuse ziemlich egal ist, wieviele MHz drinnen Elektronen
> herumschubsen.

Den Drahtlängen der Zuleitung aber nicht mehr.  OK, rein für den
Core-Takt kann man sich da mit einer PLL drumrum mogeln.

> ..., wenn NXP den LPC2103 wie angekündigt auch als
> PLC44 rausgebracht hätte.

PLCC ist ja auch nicht DIP.  Ein DIP-40 hat einfach an den äußeren
Pins riesige Induktivitäten sitzen.  Wenn man dann noch ,klassisches'
Pinout hat (also wie bei 74xx oder 8051), dann sind ausgerechnet
die Versorgungsleitungen mit diesen Induktivitäten versehen. :-o

Allerdings scheint PLCC allmählich auszusterben, da es offensichtlich
kaum Vorteile gegenüber den diversen QFP-Varianten bringt.

Jörg Wunsch schrieb:

> Den Drahtlängen der Zuleitung aber nicht mehr.  OK, rein für den
> Core-Takt kann man sich da mit einer PLL drumrum mogeln.

Was heisst hier "mogeln"? Jenseits von 20-25 MHz kommt man um eine PLL 
sowieso kaum herum, denn Pflicht zu ein externen Oszillatoren ist bei 
Single-Chip Mikrocontrollern nicht üblich.

Weshalb ja schon die PIC18 eine drin haben.

> PLCC ist ja auch nicht DIP.

Ist aber genauso lötpunktrastertauglich. Nur Breadboarder und 
Lötstreifenfreaks gucken da in die Röhre.

> Wenn man dann noch ,klassisches'
> Pinout hat (also wie bei 74xx oder 8051), dann sind ausgerechnet
> die Versorgungsleitungen mit diesen Induktivitäten versehen. :-o

Jo, aber das muss man nicht unbedingt so machen, oder? Atmel hat das 
nach anfänglichen Fehltritten ja auch korrigiert.

> Allerdings scheint PLCC allmählich auszusterben, da es offensichtlich
> kaum Vorteile gegenüber den diversen QFP-Varianten bringt.

Der einzige Vorteil war und ist seit jeher die Fassung. Sie ist 
bezahlbar.

Jörg Wunsch schrieb:
> Wenn man dann noch ,klassisches'
> Pinout hat (also wie bei 74xx oder 8051), dann sind ausgerechnet
> die Versorgungsleitungen mit diesen Induktivitäten versehen. :-o

Das scheint aber kein ernster Hinderungsgrund zu sein.
Der neue AT89LP6440 im DIP40 hat immer noch das 8051 Standardgehäuse.

Und den AT89C51ED2 wollten sie erst bei der RoHS-Umstellung als DIP40 
abkündigen.
Später war das DIP aber doch wieder im Datenblatt und auch verfügbar.


Peter

Würde mich nicht wundern, wenn Atmel in solche Dinger einen internen 
Kondensator investiert. Ob nun auf dem Chip, oder als Teil des Bondings.

A. K. schrieb:
> Würde mich nicht wundern, wenn Atmel in solche Dinger einen internen
> Kondensator investiert.

Den Gedanken hatte ich auch schon dabei. ;-)