Forum: Mikrocontroller und Digitale Elektronik PIC Oder AVR?


von Hannes Obermeier (Gast)


Lesenswert?

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:

von Ch D. (chrisu) Benutzerseite


Lesenswert?

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

von avr (Gast)


Lesenswert?

Dann starte auch die Abstimmungen:

Windows <-> Linux

      C <-> Bascom

schwarz <-> weiß

   etc. <-> pp

Ist alles gleich sinnlos!

avr

von Jörg S. (joerg-s)


Lesenswert?

MSP430 :)

von Peter D. (peda)


Lesenswert?


von Hannes Obermeier (Gast)


Lesenswert?

Was ist dein Problem bin doch nur neugierig.

von Christian -. (kakuijin)


Lesenswert?

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

von Benedikt K. (benedikt)


Lesenswert?

AVR, PIC24/33

von eh (Gast)


Lesenswert?

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....

von Christian -. (kakuijin)


Lesenswert?

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 ;)

von Stephan M. (stephanm)


Lesenswert?

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

von Gast (Gast)


Lesenswert?

AVR, u.a wegen GCC und avrdude

von Anja (Gast)


Lesenswert?

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.

von Weingut P. (weinbauer)


Lesenswert?

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

von 3-2-1 Keins (Gast)


Lesenswert?

Ja.

von R. B. (rabis)


Lesenswert?

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

Gruß
RABIS

von Иван S. (ivan)


Lesenswert?

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

von Bernd (Gast)


Lesenswert?

> 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/

von AVR 4-ever (Gast)


Lesenswert?

Erststimme:
[X] ATmega8

Zweitstimme
[X] Atmel AVR

Warum:
Weil es das AVR-GCC-Tutorial gibt.

von Sigint 112 (sigint)


Lesenswert?

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.

von Michal (Gast)


Lesenswert?

>Diese Seite wirst Du sehr nützlich finden:
http://www.duden.de/deutsche_sprache/sprachberatung/

Warum haben die Österreicher die Hotline billiger? ;))

von chris (Gast)


Lesenswert?

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.

von Frank501 (Gast)


Lesenswert?

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

von Brandt (Gast)


Lesenswert?

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.

von Peter D. (peda)


Lesenswert?

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

von spess53 (Gast)


Lesenswert?

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

von Alex S. (thor368)


Lesenswert?

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

von GG (Gast)


Lesenswert?

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

von Maik W. (werner01)


Lesenswert?

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.

von Gnubbel (Gast)


Lesenswert?

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.

von Brandt (Gast)


Lesenswert?

@ 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.

von Master S. (snowman)


Lesenswert?

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.

von Christian H. (netzwanze) Benutzerseite


Lesenswert?

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.

von gast (Gast)


Lesenswert?

>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

von Peter D. (peda)


Lesenswert?

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

von Benedikt K. (benedikt)


Lesenswert?

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.

von Brandt (Gast)


Lesenswert?

> 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.

von Christian -. (kakuijin)


Lesenswert?

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

von eh (Gast)


Lesenswert?

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.

von Benedikt K. (benedikt)


Lesenswert?

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.

von Star K. (starkeeper)


Lesenswert?

PIC und Cortex M3

von (prx) A. K. (prx)


Lesenswert?

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.

von Christian -. (kakuijin)


Lesenswert?

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

Jo, find ich auch...

von Brandt (Gast)


Lesenswert?

> 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 :-)

von Christian H. (netzwanze) Benutzerseite


Lesenswert?

Schon etwas von Beifahrern gehört?

von Brandt (Gast)


Lesenswert?

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

von juppi (Gast)


Lesenswert?

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ß

von Christian H. (netzwanze) Benutzerseite


Lesenswert?

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.

von Carsten S. (dg3ycs)


Lesenswert?

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

von Peter D. (peda)


Lesenswert?

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

von gast (Gast)


Lesenswert?

Z80 was sonst?

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.)

von Michael G. (linuxgeek) Benutzerseite


Lesenswert?

AVR

von Benedikt K. (benedikt)


Lesenswert?

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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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

:-)

von Carsten S. (dg3ycs)


Lesenswert?

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

von (prx) A. K. (prx)


Lesenswert?

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.

von Benedikt K. (benedikt)


Lesenswert?

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)?

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.

von (prx) A. K. (prx)


Lesenswert?

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.

von Peter D. (peda)


Lesenswert?

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

von (prx) A. K. (prx)


Lesenswert?

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

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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
Noch kein Account? Hier anmelden.