Moin,moin alle mitnander Die alte Frage PIC oder AVR, ich habe in diesem Forum schon so manches über dieses Thema gelesen und glaube dass es noch immer unstimmigkeiten gibt. Ich möche jetzt einfach eine Abstimmung machen:PIC VS AVR!! Jeder schreibt einfach für welchen der ucs er ist und warum. Binn schon mal gespannt was da rauskommt:
Dann starte auch die Abstimmungen: Windows <-> Linux C <-> Bascom schwarz <-> weiß etc. <-> pp Ist alles gleich sinnlos! avr
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....
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
Hallo, ich verwende PIC wenn es auf Schnelligkeit bei der A/D-Wandlung ankommt oder geringer Stromverbrauch notwendig ist. Den AVR wenn mir der gcc-Compiler bei größeren Projekten einen Vorteil bringt.
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
> Moin,moin alle mitnander > Die alte Frage PIC oder AVR, > ich habe in diesem Forum schon so manches über dieses Thema gelesen und > glaube dass es noch immer unstimmigkeiten gibt. > Ich möche jetzt einfach eine Abstimmung machen:PIC VS AVR!! > Jeder schreibt einfach für welchen der ucs er ist und warum. > Binn schon mal gespannt was da rauskommt: Diese Seite wirst Du sehr nützlich finden: http://www.duden.de/deutsche_sprache/sprachberatung/
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.
>Diese Seite wirst Du sehr nützlich finden: http://www.duden.de/deutsche_sprache/sprachberatung/ Warum haben die Österreicher die Hotline billiger? ;))
nabend probier doch einfach die dazugehörige software aus und studier die datenblätter von atiny 2313/pic16f84 = vergleich -> ENTSCHEIDUNG ist davon abhängig welche ideen du umsetzen möchtest. habe pic und avr ausprobiert und bin dann beim avr hängen geblieben.
AVR, vorzugsweise M8/88 Weil ich von langer Zeit einmal ein Projekt gestartet hatte und TTL-Gräber mit einem damals hochaktuellen AT90S1200 verkleinern wollte. Jahre nachdem das Projekt aus mangel an Zeit und Lust gestorben ist, hatte ich die ca. 20 uralt AVR's in meiner batelkiste gefunden und dachte, das man damit doch was machen könnte. Im Endeffekt hab ich die dann wieder in der Restekiste versenkt und hab mir ne Hand voll 2313 gekauft und bin dann bei den AVR hängen geblieben. Also nehm ich sie eigentlich nur aus Gewohnheit, weil ich mit der Softwareaustattung, die ich hier habe (AVRco und Ponyprog) gut zurecht komme. >Dann starte auch die Abstimmungen: > >Windows <-> Linux > > C <-> Bascom > >schwarz <-> weiß > > etc. <-> pp > >Ist alles gleich sinnlos! da fehlt nach die uralte Glaubensfrage : C <-> Pascal :-D Frank
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.
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
HI >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. Besser hätte ich die Eigenschaften von AVRs auch nicht beschreiben können. Danke. MfG Spess
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
Servus, nach dem ich nun bei Atxmega128a1 und Atxmega32 gelandet bin und mit den neuen Typen voll zufrieden bin, gibt es nur eine mögliche Antwort: ATMEL AVR. Wer sich erstmals neu in die Micros einlernen will, sollte sich mit der zukunftsicheren Technik der Atxmega-Modellen beschäftigen. Auch die Software (AVR-Studio und WinAVR) ist TOP!! Immer auf den neuesten Stand. Ich bin ein AVR'ler und bleib einer. Gruß GG
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.
nach z80 wollte ich erst mit pic oder dem 8051 (Elektor 89s8252-Flash-Board, 2001?) beginnen. dann laß ich etwas von den avrs. Auf sprut.de sah ich die komplizierten programmer für die pics, daraufhinn entschied ich mich für den avr (2313, M8) mit einem parPort-programmer (mit 74244). entscheidend war für mich (erstmal) der einfache programmer, sonst hätte ich die pics ausprobiert. 8051 und m16C, arm kamen dann noch hinzu.
@ Peter Dannegger @ spess53 Natürlich finden sich die Eigenschaften irgendwie auch bei den AVRs. Geht man beim direkten Vergleich allerdings etwas in die Tiefe, dann gehen die PIC18Fxxxx als Punktsieger hervor: Bei den PICs findet sich ein größeres Produktspektrum, was bei den einschlägigen Distributoren auch wirklich lieferbar ist. Zur Stabilität unter schwierigen Bedingungen können Euch Leute etwas verraten, die in EMV-Labors arbeiten. Ansonsten meine Frage: habt Ihr schon mal AVRs in 10 Meter Höhe unter absolut widrigen Umständen umprogrammiert? Mit PICs geht das problemlos.
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.
>Ansonsten meine Frage: habt Ihr schon mal AVRs in 10 Meter Höhe unter >absolut widrigen Umständen umprogrammiert? Mit PICs geht das problemlos. was soll da bei AVRs schwerer sein ^^ stöpsel dran und rein das prog. und ma ehrlich .. wer die µC nicht grade mit überspannungen quält ... da laufen die selbst bei den übelsten bedingungen weiter ich hab nun schon einige mit kurzschlüssen oder verolungen gequält und die laufen auch heute noch es erstaunt mich immer wieder wie robust die kleinen kerle sind
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.
> Auch AVRs sind in jeder Höhe problemlos zu programmieren. Die Aussage ging in die Richtung, dass zwischen Dir (und dem Mikrocontroller) und dem Hallenboden außer einer kleinen, wackligen schwer zu erreichenden Plattform nur 10 Meter Luft vorhanden waren. PICs lassen sich in diesen Situationen mit minimalem Equipment sicher programmieren. > Ich habe schon 2 PICs geschossen Bei meinen letzten 10.000 verwendeten PICs sind mir auch nur zwei Stück durch Überspannung (24V!) gestorben.
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
Ein wenig beachtetes Detail. Beim PIC gibt es die Entwicklungsumgebung MPLAB des Herstellers. Das besondere daran ist, dass aller verfuegbaren Compiler, auch von Drittherstellern, unter dieser Oberflaeche laufen. Dh das Entwickeln, Debuggen, Programmieren macht man immer mit denselben Tools. Mit RealICE gibt es einen Tracedebugger, der allenfalls mit dem AVR One! verglichen werden kann. Mit dem Unterschied, dass es den RealICE schon seit jahren gibt und auch viele Teile unterstuetzt. Das kann man vom AVR One! leider nicht sagen. Atmel ist auf der Debugseite leider etwas schwach. Zu schwach fuer mich. Ja. Der Mega32 hat auch schon eine JTAG Schnittstelle. Das Schwache daran ist, dass sie auf dem Analogteil liegt, sowie ein Teil auf dem PortC. IMO, leider unbrauchbar. Ich hab zuviel Zeit mit schwachen Debugmoeglichkeiten verpufft und werd nun fuer anspruchsvollere Designs auf den AVR32 gehen.
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.
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...
> Ich habe es mal ausprobiert. AVRs lassen sich auch bei 100km/h noch gut > programmieren. Höhe über NN ca 750m. ;-) ... und anschließend war ein toller Film fertig, der unter dem Stichwort "Crash" unter youtube wahnsinnige Zugriffszahlen hat :-)
Hallo Moderatoren, ich sehe gerade, dass ein Beitrag von einem AVR-Befürworter gelöscht wurde. Warum macht Ihr sowas?
Nach dem lesen kann ich immer noch nicht entscheiden, ob ich auf AVR umsteigen soll. Ich mache nur kleine Progs mit Pics in Assembler,ich glaube da lohnt es sich nicht. Obwohl ich schon AVR und PollinBoard habe,habe ich es noch nicht wieder versucht. Das was ich schätze:Bei Pics den kleinen Befehlssatz,Bei AVR die Unmenge an guten und schlechten Quellcode und natürlich eine größere Fangemeinde. Gruß
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.)
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. ;-)
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.