www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik PIC oder AVR, was ist besser


Autor: Pat (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Eine Frage: Was ist besser für Anfänger.
PIC oder AVR Prozessoren?
Drei Sachen sind mir wichtig:
1. Einfacher Einstieg und leicht erlernbar
2. Preisgünstiger Einstieg mit möglichst niedrigen Kosten.
3. Komfortables Arbeiten mit dem Prozessor unter Linux UND Windows mit 
der gleichen Programmiersprache und 100% gleiche Syntax.

Autor: Jochen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

hiermit eröffnest du die x-te Diskusssion über Gut und Böse.
Jeder hat dazu eine eigene Meinung und nutzt den Controller der für 
seine Anwendung am besten geeignet ist.
Datenblätter lesen und ein Programmiersprache lernen mußt du bei beiden.

Jochen

Autor: Jens (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
schau dir mal das MSP430 Launchpad oder die Einsteigersets von 
STMicroelectronics an. Da bekommst du für 5 oder 10 Euro Programmer und 
Hardware für den Einstieg.

Eigentlich hast du die Frage falsch gestellt. Es kommt darauf an, was du 
damit machen willst.


Jens

Autor: Pat (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was ich machen will?
Erst mal generell Erfahrung sammeln.
Kleine, einfachere Projekte, bevorzugt mit bedrahteten Bauteilen.
Die Leistungsklasse von 8Bit AVR/PIC wird mir noch einige Zeit reichen.
MPS430 / 16 Bit wäre dann die nächste Stufe. Oder gibts die MSP430 auch 
in DIL und als Billig-uC für einfache Sachen?

Wenn ich mal mehr brauche, dann nehme ich ARM, mit Linux. Oder AVR32 mit 
Linux. Das ist klar.
Mit tcp/ip Stack, Dateisystem und solche Sachen auf AVR/PIC 8 Bit oder 
MSP430 werde ich mich nicht befassen. Wenn ich das mal brauche, gehe ich 
auf eine gut linuxtaugliche uC Plattform. Linux kann das alles sehr gut 
und es ist ein einfacher Weg.

Autor: Gastino G. (gastino)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Pat schrieb:
> Eine Frage: Was ist besser für Anfänger.
> PIC oder AVR Prozessoren?
> Drei Sachen sind mir wichtig:
> 1. Einfacher Einstieg und leicht erlernbar
> 2. Preisgünstiger Einstieg mit möglichst niedrigen Kosten.
> 3. Komfortables Arbeiten mit dem Prozessor unter Linux UND Windows mit
> der gleichen Programmiersprache und 100% gleiche Syntax.

Die Forderungen werden zumindest von den ATmegas problemlos erfüllt. 
Mehr kann ich Dir mangels Erfahrung mit PICs nicht dazu sagen.

Autor: dasrotemopped (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
zur Frage, welche uC ist besser gibt es nur eine Antwort:
der uC mit dem DU dich am Besten auskennst ist der Beste. Denn nur mir 
Erfahrung kannst du aus einem uC die Funktionen rauskitzeln, die du 
implementieren willst.

Zu 1.: wenn es einfach wäre würde es jeder machen. Die Einarbeitung 
kostet Zeit und Fleiss. Es gibt keinen bequemen Weg, aber der Weg lohnt 
sich.
Zu 2.: Die IDE ist umsonst ( AVR Studio/ MPLab), Programmer ( AVRISP 
MKII/ Pickit 2/3 ) sind günstig.
zu 3.: Wie wäre es mit C als Sprache ? Sollte von den meisten 
Prozessoren /Compilern verstanden werden.

Das Betriebssystem, auf dem man entwickelt solle keinen Einfluss auf die 
Entscheidung pro oder contra für einen uC sein. Das OS, auf dem die IDE 
läuft ist nur ein notwendiges Werkzeug genau so wie ein Lötkolben. Habe 
mich noch nie davon leiten lassen ob ein Bauteil besser mit Weller oder 
Ersa zu löten ist.

Am besten eine Münze werfen, Kopf -> Microchip, Zahl -> Atmel. Diese 
Entscheidung wird dir hinterher keiner kaputtdiskutieren. Und eine 
bessere Begründung gibt es nicht, denke ich.

Gruß,

dasrotemopped.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Pat schrieb:
> PIC oder AVR Prozessoren?

Schau mal links oben, was da steht.
# Home
# AVR

Die PIC-Anwender sind also hier mit Sicherheit in der Minderzahl.

Pat schrieb:
> 3. Komfortables Arbeiten mit dem Prozessor unter Linux UND Windows

Folgt man dem Link, findet man z.B.:
AVR Eclipse: Win, Linux, Mac


Peter

Autor: Marvin M. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

eindeutig AVR.

Vor allem, wenn man interessehalber Assembler programmieren will, sind 
die AVRs wirklich einfach erlernbar. PICs in Assembler programmieren? 
Nur für Masochisten.
Die PICs, die ich mal gekauft habe, liegen ungenutzt in der Ecke, 
seitdem ich die AVRs entdeckt habe.

Autor: Intel Freak (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Intel MCS-48 Familie is the best! ;-)

Autor: Frank K. (fchk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Pat schrieb:
> Eine Frage: Was ist besser für Anfänger.
> PIC oder AVR Prozessoren?
> Drei Sachen sind mir wichtig:
> 1. Einfacher Einstieg und leicht erlernbar
> 2. Preisgünstiger Einstieg mit möglichst niedrigen Kosten.
> 3. Komfortables Arbeiten mit dem Prozessor unter Linux UND Windows mit
> der gleichen Programmiersprache und 100% gleiche Syntax.

Nummer 3 erzwingt AVR. Für den gibts einen freien GCC-Port, und der ist 
unter Linux und Windows identisch.

Bei PIC ist das anders. Die 8-Bit PICs (also bis PIC18) haben ein sehr C 
unfreundliches Design. Vollständig ANSI-kompatible C-Compiler gibts von 
Microchip (MPLAB C18) und von Microchip (Hitech C, Microchip hat die 
Firma gekauft), und hier hast Du die Wahl zwischen Windows und Windows. 
Man kann damit auch gut arbeiten, aber nicht unter Linux.

Ab PIC24 basieren die C-Compiler von Microchip auch auf dem GCC. 
Microchip bietet die nur für Windows an. Technisch könntest Du den auf 
Linux portieren (und dabei den Lizenzmanager rauswerfen), aber die 
Lizenz der Bibliotheken (kein GNU) verbietet Dir das. (*)

Das Debugging ist von Microchip meiner Meinung nach besser gelöst, die 
Tools billiger; und Du kannst z.B. MPLAB und ICD3 von PIC10 (6-Pinner) 
bis PIC32MX (80 MHz 32Bit MIPS-Kern) benutzen.

Architekturmäßig sind PIC24 und AVR relativ ähnlich, mit dem 
Unterschied, dass PIC24 eben 16-bittig intern ist.

Die kleineren PICs haben eine sehr spartanische Architektur, die 35 
Jahre alt ist und ein architekturbedingtes RAM-Maximum von 4k-128 Bytes 
hat, auch noch schön mit Bankswitching und so. Den Strass sparst Du dir 
beim AVR. Wenn Du einen mit externem Adress/Datenbus hast, kannst Du 
extern problemlos 64KB RAM anschließen, mit Bankswitching auch noch viel 
mehr.

fchk

(*) Ich bin kein Anwalt, daher keine Rechtsberatung!

Autor: Carsten Sch. (dg3ycs)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

Marvin M. schrieb:
> Hallo,
> eindeutig AVR.
>
> Vor allem, wenn man interessehalber Assembler programmieren will, sind
> die AVRs wirklich einfach erlernbar. PICs in Assembler programmieren?
> Nur für Masochisten.
> Die PICs, die ich mal gekauft habe, liegen ungenutzt in der Ecke,
> seitdem ich die AVRs entdeckt habe.

IMMER wenn jemand bei einer solchen Frage: Pic oder AVR sagt das EINER 
der beiden EINDEUTIG besser ist, dann ist die Aussage schon mal mit 
großer Vorsicht zu genießen - (Ich wollte jetzt nicht schreiben: HAt der 
keine Ahnung...)
Beide Plattformen haben ihre Vor- und Nachteile und sind in der Summe 
für den Hobbybastler gleichwertig! Als ein Beispiel: Die Pics, auch 
exoten, bekommst du in DL fast ALLE Problemos -und das recht günstig. 
Bei dem was nicht 08/15 Bastlerware ist wird es bei Atmel dafür deutlich 
teurer und/oder schwieriger. Geht schon bei den Typen mit integrierten 
CAN oder USB los... Ausserdem bietet Microchip auch sehr Leistungsfähige 
Varianten noch in DIP an, also auch noch fürs Steckbrett oder den 
Grobmotoriker geeignet. Atmel nicht!
Andererseits ist die deutschsprachige ATMEL AVR Community sicherlich 
einiges Größer als die ebenfalls nicht kleine PIC Commuunity. 
(International sieht es wieder anders aus)

Und auch bei Tutorials, Frameworks usw. Für PIC gibt es eine Menge 
hervorragender Tools, Frameworks Beispielcodes direkt gut verständlich 
aufbereitet kostenlos von Microchip selbst. Aus der Community gibt es da 
natürlich auch noch was dazu.
Bei ATMEL ist das Angebot von Atmel selbst bei weiten nicht so gut, das 
wird aber durch die Community wieder super wettgemacht! In der Summe 
kommt es wieder auf ein ähnliches Niveau heraus. Wem nun was lieber ist, 
das ist jedem Selbst überlassen. Ist auch eine Glaubensfrage Gibt PRO 
und CONTRA Argumente zu beiden Philosophien!

Und es gibt noch viele andere Punkte mehr, Suche benutzen...

Aber da die obige Meldung sich auf Assembler bezog:
Wenn man zwischen PIC und AVR in Assembler vergleicht, dann gibt es 
Unterschiede. PIC hat einige Eigenheiten die Gewöhnungsbedürftig sind, 
keine Frage. Aber da reden wir von Dingen die ein normal begabter Mensch 
nach einer Stunde verstanden haben sollte. Dafür ist der Befehlsumfang 
beim Pic wesentlich kompakter als beim AVR, der auch so seine Tücken 
hat.
Dem einen liegt daher eher der AVR Assembler, dem anderen die PIC 
Variante, der Dritte kapiert von beiden nichts...
(Ausserdem sind auch die Vorerfahrungen entscheidend, wenn jemand vorher 
mit einem Controller gearbeitet hat dessen Assemblerprogrammierung eher 
der des AVRs glich, dann kommt er nun einmal anfangs mit PIC nicht so 
gut zurecht...
Daher: Beides anschauen und dir deine eigene Meinung bilden!

Frank K. schrieb:
> Die kleineren PICs haben eine sehr spartanische Architektur, die 35
> Jahre alt ist und ein architekturbedingtes RAM-Maximum von 4k-128 Bytes
> hat, auch noch schön mit Bankswitching und so. Den Strass sparst Du dir
> beim AVR. Wenn Du einen mit externem Adress/Datenbus hast, kannst Du
> extern problemlos 64KB RAM anschließen, mit Bankswitching auch noch viel
> mehr.

In dem Beistrag (gesamt) von Frank stehen viele richtige Sachen. Einer 
der (leder zu wenigen) AVR Freunde (so scheint es zumindest) der 
sachliche Argumente bringt. Wobei ich die Compilerfrage unter Linux 
nicht beurteilen kann. Ich akzeptiere das geschriebene mal so als 
Tatsache. (Will hier nicht den nächsten Krieg anzetteln, aber DAS was 
ICH mit MEINEM PC machen will und muss, das bekomme ICH mit 
Windows einfach mit deutlich weniger Aufwand und Ärger hin...)

Zu dem oben zitierten Textabschnitt aber muss ich sagen: Stimmt, die 
alten PICs beruhen auf einem sehr alten, aber doch imemr 
weiterentwickeltem Design, erfüllen ihren Zweck sehr sicher, sind aber 
sicher alles ander als hochperformante Controller.
Allerdings zieht man ja wenn man Mercedes und BMW vergleicht ja auch 
nicht auf der einen Seite einen 20Jahre alten Dreier und auf der anderen 
eine drei Monate alte S Klasse heran.
Fakt ist: Microchip hat noch Controller mit den obigen Einschränkungen 
im Programm und wird die auch weiter noch vertreiben, zur Freude vieler 
Anwender - im gegensatz zu vielen anderen Herstellern die Rücksichtslose 
Abkündigungspolitik betreiben, aber es sind seit jahren andere 
Generationen Standart!

Wenn man heute Anfängt, dann sicher nicht mehr mit einem 16C54, auch 
nicht mit einem 16F84, beides Fälle fürs Museum, sondern mit einem 
halbwegs modernen µC wie zum beispiel dem 18F4550 der auch gleich noch 
eine integrierte USB Schnittstelle (die man ja nicht benutzen muss) und 
universelle Takterzeugung mit PLL mitbringt, sowie sowohl in Assembler 
als auch in C Programmiert werden kann. (Wobei die Optimierung ganz klar 
in richtung C geht. Und wenn man dann die USB Schnittstelle nutzen 
möchte, dann ist ausser für den HArdcore Masochichsten alles andere als 
C eh ausgeschlossen, wo dann auch gleich ein super USB Stack von 
Microchip zur Verfügung gestellt wird.

DAHER:
Es gibt keine EINDEUTIG richtige Wahl. Mal ganz davon abgesehen das es 
noch deutlich mehr unter der Sonne gibt als PIC und AVR. (Wobei einer 
der beidne für den Anfang schon wohl das beste ist)
Schaue dir beide mal genauer an, überdenke deiner Liste der 
Anforderungen noch einmal wie wichtig jetzt alles für sich genommen ist 
und ob vieleicht noch etwas dazu kommt, dann triff deine Wahl und fange 
mit dem dann an.
Wenn jetzt die Frage nach der Toolgleichheit zwischen Windows und Linux 
(ohne Anwendung von virtuellen Maschinen) bei dir eine hohe Priorität 
hat, dann könnte es durchaus ja der AVR sein... Wobei mir das erst 
einmal zweitrangig wäre, denn in der virtuellen Umgebung läuft auch die 
PIC Windows Software unter linux - aber das muss jeder für sich wissen!

Willst du aber später wirklich sinnvoll Arbeiten, solltest du unbedingt 
auch den anderen und noch weitere Controller nach deinen ersten 
erfolgreichen Schritten kennelernen wollen.

Gruß
Carsten
(PIC und AVR Verwender (neben einigen anderen), allerdings mit einer 
Vorliebe für die Pics bei gleicher Eignung fürs jeweilige Projekt...)

Autor: Master Snowman (snowman)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ich habe mich für die PICs entschieden, und bin bis heute mit der wahl 
glücklich (ich musste auch mal AVRs programmieren). der ratschlag, eine 
münze zu werfen, wenn man nicht weiss, was man will, finde ich die beste 
lösung.

Autor: Detlev T. (detlevt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wäre eine der beiden Architekturen der anderen wirklich größtenteils 
unterlegen, gäbe es sie sicher nicht mehr. Soviel zum Thema "besser". 
;-)

Einem Anfänger würde ich immer raten, mit C anzufangen und nicht mit 
Assembler. Sich mit der Hardware auseinander zu setzen ist auch so schon 
schwer genug. Details der Architektur wie "nur wenige, leicht erlernbare 
Assemblerbefehle" etc. sind da nicht mehr relevant.

Und das spricht aus meiner Sicht dann am Ende für die AVRs als 
Einsteiger-Familie. Denn im Gegensatz zum PIC kann man hier die ganze 
8-Bit-Familie - vom Acht-Beiner bis zum Tausendfüßler - mit ein und 
demselben Compiler (GCC) programmieren. Die Hardware ist in der Regel 
sehr konservativ und konsequent realisiert, so dass man sich bei einem 
neuen Stein sehr schnell zurecht findet. Das ist im Vergleich zu den 
PICs dem einen oder anderen vielleicht etwas langweilig ;-), ist für 
mich aber eher positiv zu werten.

Autor: Juppi J. (juppiii)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
-ausschlaggebend waren die 35 Befehle der kleinen Pics

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schau auch mal in die Errata der Bausteine.
Mit PIC bist du tendenziell flexibler, da es eine aberwitzige 
Typenvielfalt für alle erdenklichen Spezialfälle gibt. Vorallem kriegst 
du die zu Spottpreisen nachgeworfen, das es schon fast wehtut.

Die Kehrseite ist, dass Microchip ziemlich großzügig mit Bugs um sich 
wirft, selbst bei den kleinen 8-Bittern. Du wirst Mühe haben, 
irgendeinen Baustein zu finden, der keine Fehler im Silizium hat oder 
hatte.
Leider sind das meistens nicht Fehler der Art, die man mit zwei 
Kondensatoren mehr am Quarz (ATmega8..) oder einem gescheiten Programmer 
(Signaturbytes gehen flöten bei einigen AVR) umgehen kann.

Typische Fehler bei den PIC sind kaputte Instruktionen, die ungewollte 
Nebenwirkungen haben (löscht irgendwelche Bits) oder verbaute SRF: Der 
AD-Wandler hält nicht automatisch an, ein Timer-Modus ist kaputt, eine 
(erlaubte) Konfiguration des Timers löst einen Reset aus (der alte 
12F635), um ein paar Beispiele zu nennen.

Das kann ganz schön an die Nerven gehen. Als Hobby-Mensch ist das erst 
Recht frustrierend: Microchip flickt zwar auch Fehler, aber wenn du -- 
wie etwa bei Reichelt -- nicht erkennen kannst, welche Silizium-Revision 
du bekommst, ist das doof. Da ist der Fehler vielleicht schon drei Jahre 
behoben und du kriegst alte Lagerware.

Schau für Spaß mal ins Errata des ENC28J60 (dieser Ethernet-PHY) rein.

Verglichen damit sind die 8-Bit-AVR quasi 'perfekt'.

Autor: Carsten Sch. (dg3ycs)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,
Detlev T. schrieb:
> Wäre eine der beiden Architekturen der anderen wirklich größtenteils
> unterlegen, gäbe es sie sicher nicht mehr. Soviel zum Thema "besser".
> ;-)
Full Ack

> Einem Anfänger würde ich immer raten, mit C anzufangen und nicht mit
> Assembler. Sich mit der Hardware auseinander zu setzen ist auch so schon
> schwer genug. Details der Architektur wie "nur wenige, leicht erlernbare
> Assemblerbefehle" etc. sind da nicht mehr relevant.

Sehe ich etwas gespalten...
Also die ALLERERSTEN Schritte mit einem Mikrokontroller würde ich immer 
in Assembler machen! Wenn man ein Programm vernünftige entwickeln 
möchte, dann braucht man einfach ein gewisses Grundverständniss für die 
Plattform auf der es läuft. Erst recht wenn man nur die extrem 
eingeschränkten DebugMöglichkeiten eines µC Anfängers hat, der die 
sowieso schon eingeschränkten Möglichkeiten mangels teurer Ausstattung 
nicht mal ansatzweise ausschöpfen kann.

Aber klar! Alles was über einen LED Blinkschaltung mit Tastenabfrage 
hinausgeht braucht für einen Anfänger nicht merh in Assembler sein. Ich 
sage immer: Sobald die LED auf Tastendruck -anders- Blinkt gehe nach C!

Allerdings hat der TE ja explizit nahc Assembler gefragt! Und dann 
gehören sowohl der Vorteil der nur wenigen Befehle wie auch der Nachteil 
-zumindest bei den ALTEN Modellen- der Bankumschaltung bei den 16F Pics 
genannt. (Auf AVR verzichte ich jetzt mal)

> Und das spricht aus meiner Sicht dann am Ende für die AVRs als
> Einsteiger-Familie. Denn im Gegensatz zum PIC kann man hier die ganze
> 8-Bit-Familie - vom Acht-Beiner bis zum Tausendfüßler - mit ein und
> demselben Compiler (GCC) programmieren. Die Hardware ist in der Regel
> sehr konservativ und konsequent realisiert, so dass man sich bei einem
> neuen Stein sehr schnell zurecht findet. Das ist im Vergleich zu den
> PICs dem einen oder anderen vielleicht etwas langweilig ;-), ist für
> mich aber eher positiv zu werten.

Das ist aber bei den PICs auch der Fall wenn man möchte... Verwendet man 
statt des Microchip C Compilers nun den Hi-TEch Compiler, der ja 
ebenfalls, wenn auch mit für Hobbyisten völlig irrelevanter 
eingeschränkter Codeoptimierung, frei von Microchip Verfügbar ist.

Dann hat du auch vom 6Pinner bis zum "großen Brummer" alles mit 
demselben Compiler. Die gesamte 8Bit Familie!!!
Oder du entscheidest dich für den Microchip C-Compiler, weil du sagst 
OK, 6 und 8 Pinner brauche ich momentan nicht, wenn dann kann ich mich 
da auch noch kurz einarbeiten (SO Unterschiedlich sind die beiden 
Compiler ja nicht) dann hast du sowohl den modernen Teil der 8Bit 
Familie, die 16Bit Familie und die 32Bit Familie grundsätzlich mit 
demselben Compiler (auch wenn sich die interne Struktur natürlich 
ändert, aber das merkt man nicht)

Darüberhinaus hast du hier vom 8Bit 6 beinigem Käfer bis zum 32Bit High 
End Controller mit DSP eigenschaften dieselbe Programmierhardware welche 
schon in der Grundversion für 30 Eur. umfangreiche 
Debuggingeigenschaften bietet. Das hast du bei AVR wiederrum nicht,
Ach ja, der 32Bit µC von Microchip hat einen MIPS kern welches von der 
technologie eine der beiden großen Architekturen ist (neben ARM). 32 Bit 
MIPS µC werden auch von anderen Herstellern angeboten!
32BIT AVR haben etwas völlig eigenes welches in der Verbeitung um welten 
kleiner ist...

Hat man aber gar nicht vor irgendwann auch auf 32Bit zu gehen -natürlich 
völlig irrelevant.

DAHER:
Die Münze ist manchmal ein echt guter Rat...
(Ich würde ja PIC sagen, aber das ist rein meine eigene Sichtweise)

Gruß
Carsten

P.S.: Ein echtes pro PIC Argument fällt mir aber gerade noch ein, mit 
dem Anfänger oft echt bei AVR zu kämpfen haben - Und mir fällt da bei 
leibe kein Gegenargument ein wo die Vorteile davon liegen könnten:
Diese dämliche Eigenschaft der FuseBits beim AVR!
Man kann sich beim AVR selbst aussperren, so das man über ISP nicht mehr 
in den IC reinkommt. Dies kann passieren wenn man einen Fehler beim 
setzen der FuseBits macht oder aber auch einfach wenn der 
Programmiervorgang gestörtt wird. Hat man keinen HV Programmen, dann 
kann man den IC wegwerfen... Hat man einen HV Programmer, geht das 
natürlich meist, manchmal muss man aber trotzdem den µC aus der 
Schaltung ausbauen und in einen eigenen Sockel setzen. Sehr toll bei SMD 
oder ungesockelten µC!
Bei PICs kann dir das niemals passieren.

Eine andere, aber hier nicht wirklkich tragische, Falle ist dann noch 
das JTAG Bit - denke aber das man hier mit leben kann. Für Anfänger nur 
manchmal ein Grund zum Stutzen...

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Detlev T. schrieb:

> Wäre eine der beiden Architekturen der anderen wirklich größtenteils
> unterlegen, gäbe es sie sicher nicht mehr. Soviel zum Thema "besser".
> ;-)

In den 90ern entschied sich, welche Architektur den Server-, 
Workstation- und Desktop-Markt dominieren wird. Es war letztlich die 
unter diesem Aspekt unstrittig schlechteste von allen verfügbaren 
Alternativen. Das ist also kein Argument. Die Enscheidungen fallen 
anhand anderer Kriterien.

Autor: Carsten Sch. (dg3ycs)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sven P. schrieb:
> Die Kehrseite ist, dass Microchip ziemlich großzügig mit Bugs um sich
> wirft, selbst bei den kleinen 8-Bittern. Du wirst Mühe haben,
> irgendeinen Baustein zu finden, der keine Fehler im Silizium hat oder
> hatte.
> Leider sind das meistens nicht Fehler der Art, die man mit zwei
> Kondensatoren mehr am Quarz (ATmega8..) oder einem gescheiten Programmer
> (Signaturbytes gehen flöten bei einigen AVR) umgehen kann.
>
> Typische Fehler bei den PIC sind kaputte Instruktionen, die ungewollte
> Nebenwirkungen haben (löscht irgendwelche Bits) oder verbaute SRF: Der
> AD-Wandler hält nicht automatisch an, ein Timer-Modus ist kaputt, eine
> (erlaubte) Konfiguration des Timers löst einen Reset aus (der alte
> 12F635), um ein paar Beispiele zu nennen.
Naja, ganz so tragisch ist das aber nicht!
Bausteine die auf dem Markt sind und solche gravierenden Fehler haben, 
die musst du aber wirklich suchen. Und die gibt es auch bei AVR!
Da tun die sich nicht wirklich viel...
Natürlich, bei Microchip hast du in der Summer mehr µC mit Bugs, einfach 
weil es deutlich mehr Bausteine gibt! Und auch weil die fast nicht 
vollständig abkündigen sondern Bausteine für die es keinen Baustein gibt 
der garantiert fast ohne Codeänderung 100% kompatibel ist im Programm 
lassen. Da bleiebn halt auch die BUgs mit drin. In der Beschreibeung der 
Bausteine steht dann aber auch eindeutig das die nicht mehr für stand 
der technik sind.
Ob der Durchschnitt aber so viel schlimmer ist... Da gibt es bei AVR, 
wenn ich das jetzt noch richtig im Kopf habe, auch heute noch µCs wo zum 
beispiel das PWM Modul so buggy ist das es nicht zu nutzen ist.

> Das kann ganz schön an die Nerven gehen. Als Hobby-Mensch ist das erst
> Recht frustrierend: Microchip flickt zwar auch Fehler, aber wenn du --
> wie etwa bei Reichelt -- nicht erkennen kannst, welche Silizium-Revision
> du bekommst, ist das doof. Da ist der Fehler vielleicht schon drei Jahre
> behoben und du kriegst alte Lagerware.
Naja, normalerweise erkennt man es schon, wenn es nämlich bedeutende 
Fehler sind, dann schlägt sich die änderung im Namen nieder. Dann heist 
der URbaustein zum Beispiel 16Fxx0 und die bearbeitete Version 16Fxx0-A. 
Das stht auch drauf.
Davon abgesehen: Ich entwickle seit über 10 Jahren privat und beruflich 
Schaltungen mit µC. Und hatte erst -gerade extra noch nachgeschaut- drei 
mal den fall das ich bei Microchip wirklich im Errata Sheet nachschlagen 
musste warum der PIC nicht das macht was ich will und wie ich das zu 
umgehen habe. Bei AVR war es zwei mal der Fall. (Und ich nehme häufiger 
den PIC) Wenn man ehrlich ist, dann sind fast alle Fehler ja solcher aRt 
das die bei extrem speziellen Konstellationen erst auftreten!

> Schau für Spaß mal ins Errata des ENC28J60 (dieser Ethernet-PHY) rein.
Naja, wirkt erschreckend, aber das ist nun auch einer der ersten für 
Hobbyisten überhaupt verfügbaren Ethernet Controller gewesen. Und eine 
sehr Komplexe Funktion verbunden mit früher einführung ist nun einmal 
immer ein Fall für BUGs, KEIN Hersteller schaft das BUG-Frei.

Aber gerade der ENC28J60 ist ein schlechtes Beispiel, weil der ja 
eigendlich der Baustein ist den die ganze AVR Welt verwendet. Die PICler 
nehmen einfach einen der PICs mit integriertem Ethernetkern und sparen 
so Platz, Kosten und Bestückungsaufwand. Ausserdem bleibt die SPI 
schnittstelle frei ;-)
>
> Verglichen damit sind die 8-Bit-AVR quasi 'perfekt'.
Da wage ich zu wiedersprechen!

Gruß
Carsten

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Detlev T. schrieb:

> Wäre eine der beiden Architekturen der anderen wirklich größtenteils
> unterlegen, gäbe es sie sicher nicht mehr. Soviel zum Thema "besser".
> ;-)

Fortsetzung:

Wäre die Architektur wirklich ein Thema, die PICs wären aufgrund der 
Dominanz von Programmierung in C längst weg vom Fenster (und die übrigen 
Harvard-Biester einschliesslich AVR und i51 hätten auch einen schlechten 
Stand). Die PIC10/12/16 sind eine Katastrophe für einen C Compiler und 
die PIC18 sind in der Hinsicht auch erst in der zweiten 
Architektur-Revision erträglich - das ist diejenige, die im kostenlosen 
C18 nicht genutzt werden kann ;-).

Statt dessen halten sich im 8-Bit Markt standhaft jene Architekturen, 
bei denen der C-Programmierer gezwungen ist, um Absonderlichkeiten der 
Hardware herumzuprogrammieren, wie getrennte Adressräume für ROM und RAM 
und ggf. gleich mehrere für RAM, Besonderheiten im Umgang mit Daten und 
Unterprogrammen in Interrupt-Handlern, ...

Tatsächlich aber kann man auch Architekturen sehr wohl nutzen, die einem 
in mancher Hinsicht das Leben schwer machen. Eben weil es auch andere 
Gründe gibt. Die Funktionalität der I/O-Module der PICs wurde schon 
genannt. Andere wie i51 haben der Vorteil, dass sie irgendwie immer 
schon da waren und fast jeder Hersteller mit dazu beiträgt. Und ein 
bischen auch, weil man es so gewohnt ist, schon immer so gemacht hat, da 
könnte ja jeder kommen ;-).

Das Gegenmodell wäre z.B. MSP430. Blitzsaubere Architektur, aber die 
Funktionalität hält sich verglichen mit PIC18, PIC24, AVR, ... sehr in 
Grenzen.

Und die Interessen der Massenkunden sind sowieso gänzlich anders. Anders 
als Atmel und Microchip schert sich Freescale einen feuchten Dreck um 
Bastler und Krämer und überlebt dennoch. Denn in deren Markt steckt das 
Geld, nicht im Kleinkram.

Autor: Carsten Sch. (dg3ycs)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:
> Die PIC10/12/16 sind eine Katastrophe für einen C Compiler und
> die PIC18 sind in der Hinsicht auch erst in der zweiten
> Architektur-Revision einigermassen brauchbar - das ist diejenige, die im
> kostenlosen C18 nicht genutzt werden kann ;-).

Welche µCs können den im kostenlosen Compiler nicht genutzt werden... 
Das ist mir neu das es da welche gibt... ausser der schlechteren 
Codeoptimierung gibt es keine Einschränkung beim Compiler - und die ist 
für den Hobbyisten völlig irrelevant das diese in 95% der Fälle eh 
keinen Code schreiben der den Speicher selbst völlig ohne Optimierung 
auch nur Ansatzweise füllen würde. Und in den restlichen 5% der Fälle 
investiert man einfach die 10-20ct für den Bautein mit dem nächsthöheren 
Speicher.
Bei der Massenproduktion mit Stückzahlen im 1000er -oder auch schon nur 
100er- Bereich pro Tag sind die 10ct Baustein auf den Monat oder gar das 
Jahr gerechnet aber richtig Asche!

Das die PIC10-16 Architektur für C einen Katastrophe sind würde ich 
jetzt nicht so sagen. Schwierig in der Umsetzung des Compilers - Ja auf 
jeden Fall! Aber wenn man sich nicht selbst eine Compiler schreiben will 
dann spielt das ja keine Rolle, den Kopf haben sich andere bereits lange 
vorher Erfolgreich zerbrochen ;-)
Davon abgesehen waren die ja lange vor den AVR schon da, als von C als 
Standart-Programmiersprache für µC noch keine Rede war, die µC Welt fast 
Ausschließlich nur ASM Sprach!

Dem Recht deines Beitrages könnte ich aber Bedenkenlos unterschreiben!

Gruß
Carsten

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Carsten Sch. schrieb:

> Bausteine die auf dem Markt sind und solche gravierenden Fehler haben,
> die musst du aber wirklich suchen.

Schon mal den CAN Controller der PIC18Fxx8 bewundert? Klar, es gibt 
längst die PIC18Fxx8x, die den urigen Adressierungsfehler nicht haben. 
Dafür einen anderen Bug. Nur dass der Adressierungsfehler leichter 
umgehbar ist.

Überhaupt die CAN Controller. Mindestens die Hälfte aller integrierten 
CAN Controller von Microchip haben einen Bug drin, der bei Störungen auf 
dem Bus oder weglaufender Takterzeugung zu defekten aber nicht als 
solches erkennbaren Messages führen kann.

Trösten tut einen allenfalls, dass es anderen nicht besser ergeht. 
Philips/NXP hatte sich in der ersten Generation der LPC2000 auch nicht 
grad mit Ruhm bekleckert.

Autor: Jens (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:
> Denn in deren Markt steckt das
> Geld, nicht im Kleinkram.

Das kann schon sein, der junge Entwickler, der nach dem Studium sein 
erstes eigenes Projekt hat, nimmt dann vermutlich eher eine vertraute 
Architektur, einfach um schnell ein Ergebnis zu erzielen und vor dem 
Chef gut dazustehen. Das dürfte in den meisten Fällen PIC oder AVR sein. 
Mir fällt auf die Schnelle keine Anwendung ein, für die ein PIC im 
Gegensatz zu 430, 8051, etc nicht geeignet ist. Bei den AVRs dürfte das 
ähnlich sein.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Carsten Sch. schrieb:

> Welche µCs können den im kostenlosen Compiler nicht genutzt werden...

Sie können durchaus genutzt werden. Aber nicht in dem Modus, der für 
C-Compiler eminent interessant ist. Die erste Architektur-Revision hatte 
noch auf die klassische statische Adressierung aller lokaler Daten 
abgezielt, erst im zweiten Anlauf schwenkte Microchip bei den Chips auf 
die umgänglichere Datenadressierung über einen Stack um (ich habe grad 
nicht in parat wie die das nennen).

Der kostenlose Modus des C18 unterstützt diese zweite Revision jedoch 
nicht, verwendet daher die alte Methode. Wahlweise statisch oder auch 
als Stack, letzteres dann aber eher ineffizent.

Übrigens war das Ziel meines Sermons oben gerade nicht, Architekturen, 
die für C Compiler weniger geeignet sind, zu verdammen. Sondern im 
Gegenteil, ich schrieb ja, dass sie trotzdem verwendet werden können und 
verwendet werden. Was ich schrieb war nur: Die zweite Revision der PIC18 
Architektur ist für C Compiler deutlich besser geeignet als die erste.

> Das die PIC10-16 Architektur für C einen Katastrophe sind würde ich
> jetzt nicht so sagen. Schwierig in der Umsetzung des Compilers - Ja auf
> jeden Fall!

Eben, genau das war gemeint. Ich bin da ein bischen vorbelastet, weil 
ich sowas schon gemacht habe. Sowohl was geeignete wie auch was 
ungeeignete Architekturen angeht. Zeig mit eine ISA (Instruction Set 
Architecture) und ich sage dir, wieviel Flüche derjenige ablässt, der 
den Compiler dafür stricken darf ;-).

Dass eine Architektur für C weniger geeignet ist, heisst nicht, dass man 
damit nicht in C arbeiten kann. Es heisst nur, dass der entstehende Code 
oft etwas krampfig aussieht. Das kann und wird vielen Anwendern egal 
sein. Wer da nicht öfter mal reinschaut, den interessiert das allenfalls 
beim evtl. etwas gedrosselten Tempo oder irgendwann beim Platz im ROM. 
Letzteres ist jedoch selten ein Thema, weil Microchip den vergleichbaren 
Teilen traditionell wohlweislich erheblich mehr ROM gönnt als 
beispielsweise Atmel oder TI.

Autor: Moppel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Carsten Sch. schrieb:
> Das ist aber bei den PICs auch der Fall wenn man möchte... Verwendet man
> statt des Microchip C Compilers nun den Hi-TEch Compiler, der ja
> ebenfalls, wenn auch mit für Hobbyisten völlig irrelevanter
> eingeschränkter Codeoptimierung, frei von Microchip Verfügbar ist.

Na gut, aber wenn ich als Hobby-Fummler auf der anderen Seite auch 
Optimierung haben kann, dann gehe ich doch da hin, oder?

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jens schrieb:

> Mir fällt auf die Schnelle keine Anwendung ein, für die ein PIC im
> Gegensatz zu 430, 8051, etc nicht geeignet ist. Bei den AVRs dürfte das
> ähnlich sein.

Versuch mal, Bendikts Text-Ansteuerung eines controllerlosen QVGA-LCDs 
mit einem 8-Bit PIC an Stelle eines Mega8 zu machen. ;-)

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Carsten Sch. schrieb:

> Davon abgesehen waren die ja lange vor den AVR schon da, als von C als
> Standart-Programmiersprache für µC noch keine Rede war, die µC Welt fast
> Ausschließlich nur ASM Sprach!

Keine Frage. Es ist massgeblich das Verdienst von Microchip, den Markt 
von kleinen günstigen Controllern mit damals noch EPROM erkannt zu 
haben. Die waren davor in Form von 8751 oder Huckepack-Versionen 
prohibitiv teuer. Und die wurden meist in Assembler programmiert. Viele 
altgedienten PIC-Fans tun das noch heute - es gibt wenige Controller, 
bei denen sich das so hartnäckig hält.

Autor: micro1 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

also ich benutze beruflich AVR, AVR32, Infineon, PIC und TI.
Und ich muss sagen mir gefällt von allen die AVRs egal ob 32bit oder 8 
bit am aller besten.

Einer der Gründe ist der gute Support von Atmeleinem
Man schreibt via E-Mail ein request und bekommt innerhalb von 1 
Arbeitstag eine Antwort. Infineon ist da zum Beispiel das aller letzte.

Ich finde auch die Programmiertools von Atmel (AVR ISP mk2 oder JTAG ice 
MK2 oder AVR Dragon) besser, da diese den besseren Connector haben.
Bei PIC z.B so ein komische 6 polige Telefonbuchse. Da muss man immer
irgendwelche Adpater basteln.

Zwar hat PIC die größere Auswahl wie Atmel das ist ganz klar,
dass macht es aber auch schwerer sich sinvoller zu Entscheiden
welchen µC ich nun einsetze.

Mit den BUGs ist das so ne sache. Bis jetzt musste ich einemal ein
Workaround für den AVR32 machen.

Ich bin froh das ich am meisten mit den Atmel µCs arbeiten kann.

Aber letztendlich muss das jeder für sich selbst entscheiden.

Autor: RudolfRednose (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Pat schrieb:
> PIC oder AVR Prozessoren?
> Drei Sachen sind mir wichtig:
> 1. Einfacher Einstieg und leicht erlernbar

Nimm Picbasic, einfacher geht es wohl nicht

> 2. Preisgünstiger Einstieg mit möglichst niedrigen Kosten.
Kannst ja alles bei ebay kaufen und hinterher verkaufen. Dann sind deine 
Kosten nahe 0 (Versand ist eh gleich teuer)

> 3. Komfortables Arbeiten mit dem Prozessor unter Linux UND Windows mit
> der gleichen Programmiersprache und 100% gleiche Syntax.
Interessantes Kriterium

Nimm ein Fernwartungsmodul unter Linux zu einem Windwos PC (ist nun mal 
Standard).  Dann sieht alles fast gleich aus. Achte darauf das man deine 
beiden Monitore (natürlich mit gleicher Auflösung) Farbkalibrieren kann 
sonst sind Unterschiede nicht ausgeschlossen.

Auch würde ich bei den Tastaturen Wert auf min. 5 Jahre Verfügbarkeit 
legen, sonst must du bei defekt gleich mehrere kaufen ;-).

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jens schrieb:

> Das kann schon sein, der junge Entwickler, der nach dem Studium sein
> erstes eigenes Projekt hat, nimmt dann vermutlich eher eine vertraute
> Architektur,

Aber nur wenn dieser junge Entwickler in einem eher kleinen Unternehmen 
steckt, in dem das Projekt massgeblich sein eigenes Kind ist. Ist er 
aber beispielsweise in einer Schublade eines grösseren Unternehmens mit 
Ziel Massenproduktion untergebracht, dann hält sich seine 
Entscheidungskompetenz über solche Fragen wohl in Grenzen.

Autor: Rupert (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ts, ts. Ein Glaubenskrieg zu Weihnachten. Kann das nicht bis morgen 
warten?

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Verglichen mit dem schon seit Tagen laufenden AC/DC-Krieg ist das hier 
doch harmlos, gesittet und sogar sachlich.

Und anderswo streitet man sich grad drum, ob man Leuten überhaupt frohe 
Weihnachten wünschen darf, ohne sich als Religionsfanatiker zu outen.

Autor: Frank K. (fchk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
micro1 schrieb:

> Ich finde auch die Programmiertools von Atmel (AVR ISP mk2 oder JTAG ice
> MK2 oder AVR Dragon) besser, da diese den besseren Connector haben.
> Bei PIC z.B so ein komische 6 polige Telefonbuchse. Da muss man immer
> irgendwelche Adpater basteln.

Nö, musst Du nicht. Einfach AC164110 ordern, dann hast Du das passende.

http://www.microchipdirect.com/productsearch.aspx?...

Auch das PICkit3 benutzt den Pfostenstecker.

fchk

Autor: Lukas K. (carrotindustries)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Warum geht es hier denn immer nur um AVR vs. PIC? Die MSP430 sind IMHO 
auch eine alternative, insb. weil es mit MSPGCC und mspdebug eine 
brauchbare Toolchain für Linux gibt. Damit, dass es die nur in SMD gibt, 
muss man sich abfinden.

Autor: Maik Fox (sabuty) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Luk4s K. schrieb:
> Damit, dass es die nur in SMD gibt,
> muss man sich abfinden.

Nun ja, die MSP430 Value Line gibt's auch in DIP. Siehe LaunchPad.

Autor: Wilhelm F. (ferkes-willem)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Intel Freak schrieb:

>Intel MCS-48 Familie is the best! ;-)

Das ist auf Grund der geringen Komplexität der µC zum Einstieg gar nicht 
so abwegig. Ebenso wie die anderen alten Gurken aus den 1970-er Jahren, 
wie z.B. 8085, Z80, 6502, 6809. Der 8048 ist auch noch nicht 
ausgestorben, befindet sich z.B. immer noch in neueren Massenprodukten 
wie PC-Tastaturen.

Im Grunde kommt aber alles in Frage, was sich an Kleincontrollern am 
Markt befindet.

Selbst beschäftige ich mich gelegentlich mit alten 8051-Derivaten. 
Irgendwas in Richtung Freeware gibt es im Netz immer. Verwende den 
vollwertigen und unlimitierten SDCC-Compiler erfolgreich, und als IDE 
einfach nur für den Project-Tree mißbrauche ich eine alte Keil-Demo. Den 
EPROMMER habe ich noch aus alten Zeiten, aber sowas wäre auch mal 
schnell selbst gebaut. Statt EPROMs brennen, machte ich mir ein 
Monitor-EPROM. Das erspart neues Brennen für Testsoftware, geht so gut 
wie Flash. Bloß flasht man nichts auf Dauer oder durch einen 
Softwareirrtum kaputt.

Für den 8051 gibt es auch Flash-Versionen, Demo-Boards mit USB, SiLabs 
ist sehr modern. Ich fand an diesen Dingern immer den Befehlssatz und 
die Architektur sehr klar und schön.

Einen ARM7, z.B. LPC2xxx von NXP, ist schön, halte ich zum Einstieg aber 
schon etwas oversized.

Mit dem PIC-Assembler kann man sich auch anfreunden, hat er doch nur 35 
Befehle. Habe da letztens ein wenig mit dem PICkit1 experimentiert, ein 
paar Basteleien auf Assembler gemacht, und sie dann auf C portiert.

Das sind alles nur meine persönlichen Meinungen.

Autor: Master Snowman (snowman)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
zum adapter: ich hab da ein 10-poliges flachbandkabel an das 
telefonsteckerkabel gemacht, wobei jede 2. ader des flachbandkabels GND 
ist und vorne den stecker deiner wahl. wenn jede 2. ader GND ist, kann 
das kabel ohne weiteres 50cm lang sein, was ich sehr praktisch finde :-) 
...und btw: so ein adapter bastelst du dir genau ein mal ;-)

Autor: Thomas Eckmann (Firma: Thomas Eckmann Informationst.) (thomase)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Intel Freak schrieb:
> Intel MCS-48 Familie is the best! ;-)

Genau!

endlich sagt das mal einer!

mfg.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mir fehlt dann aber unbedingt noch der 3850 (F8). Der Mikrocontroller 
der ersten Jahre. Der 8048 war doch bloss ein Abklatsch davon.

Autor: Arc Net (arc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank K. schrieb:
> Nummer 3 erzwingt AVR. Für den gibts einen freien GCC-Port, und der ist
> unter Linux und Windows identisch.
>
> Bei PIC ist das anders. Die 8-Bit PICs (also bis PIC18) haben ein sehr C
> unfreundliches Design. Vollständig ANSI-kompatible C-Compiler gibts von
> Microchip (MPLAB C18) und von Microchip (Hitech C, Microchip hat die
> Firma gekauft), und hier hast Du die Wahl zwischen Windows und Windows.
> Man kann damit auch gut arbeiten, aber nicht unter Linux.

Kleine Ergänzung: Auf 
http://ww1.microchip.com/downloads/MPLAB/X_Beta/in... Linux x86 
auswählen...

> Ab PIC24 basieren die C-Compiler von Microchip auch auf dem GCC.
> Microchip bietet die nur für Windows an. Technisch könntest Du den auf
> Linux portieren (und dabei den Lizenzmanager rauswerfen), aber die
> Lizenz der Bibliotheken (kein GNU) verbietet Dir das. (*)
>
> Das Debugging ist von Microchip meiner Meinung nach besser gelöst, die
> Tools billiger; und Du kannst z.B. MPLAB und ICD3 von PIC10 (6-Pinner)
> bis PIC32MX (80 MHz 32Bit MIPS-Kern) benutzen.
>
> Architekturmäßig sind PIC24 und AVR relativ ähnlich, mit dem
> Unterschied, dass PIC24 eben 16-bittig intern ist.

Wobei die PIC24/dsPICs wesentlich besser in Maschinensprache 
programmierbar sind...

Autor: micro1 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Master Snowman schrieb:
> zum adapter: ich hab da ein 10-poliges flachbandkabel an das
>
> telefonsteckerkabel gemacht, wobei jede 2. ader des flachbandkabels GND
>
> ist und vorne den stecker deiner wahl. wenn jede 2. ader GND ist, kann
>
> das kabel ohne weiteres 50cm lang sein, was ich sehr praktisch finde :-)
>
> ...und btw: so ein adapter bastelst du dir genau ein mal ;-)Beitrag melden | 
Bearbeiten | Löschen |

Ja klar im Hobbybereich vielleicht. Aber ich sag mal wenn
mehrere Entwickler mit einem Tool arbeiten müssen, oder auch eine
kleine Produktion damit arbeiten muss geht so ein Basteladapter sehr 
schnell kaputt.

Da bevorzuge ich doch den einfachen 6 oder 10 poligen von Atmel.
Der Connector kann dann direkt auf der Leiterplatte sein

Autor: Thomas Eckmann (Firma: Thomas Eckmann Informationst.) (thomase)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:
> Mir fehlt dann aber unbedingt noch der 3850 (F8). Der Mikrocontroller
>
> der ersten Jahre. Der 8048 war doch bloss ein Abklatsch davon.

Aber ich arbeite nur mit modernen Systemen. Immer auf der Höhe der Zeit!

mfg.

Autor: Jens (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also während meiner Ausbildung habe ich ausschließlich mit Pic und 
Assembler gearbeitet. Nun Arbeite ich mit dem ATmega32 und C als 
Sprache.
Ich schließe mich Grundsätzlich den Antwortern an die sagen, das du 
selbst rausfinden musst welcher Baustein für deine Anwendung der 
geeignetste ist.
DU brauchst auf jedenfall, egal welcher baustein das Datenblatt. Das ist 
Esenziell. ICh steh zwar auch noch am Anfang mit den AVR´s, aber das 
sind eben erfahrungen die man bereits am Anfang sammelt, und es ist auch 
eine Verständiss sache. Nimm aber am Bestenm gleich einen Baustein, der 
dir nicht zu bald zu schwach oder zu klein wird.
Ich hab mich für den ATmega32 entschieden weil der für später Einiges 
Parat hält und wenn ich den von der Pike auf benutze und damit Groß 
werde, verstehe ich diesen vllt auch richtig.

Aber auf jedenfall steht fest Ohne Fleiß kein Preis

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dass die alten PIC so eine Katastrophe für Assembler und C waren, lag ja 
nicht an der geringen Zahl von Befehlen.
Es lag und liegt daran, dass die Architektur 'alt' und aus heutiger 
Sicht total verkorkst ist. Alles irgendwie durch ein Arbeitsregister zu 
quetschen ist nervig, die Bank-Umschalterei selbst bei so wenig RAM ist 
für Compiler eine Zumutung.

Z80 wäre auch noch da.

Autor: Master Snowman (snowman)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@micro1: adern auftrennen, die richtigen miteinander verlöten, 
schrumpfschlauch und fertig - sieht sauber aus und ist kein gebastel: 
aufwand 15min und kosten 2.- (zumindest meiner sieht sauber aus und hat 
schon viele strapazen überlebt)
wenn entwickler nicht fähig sind einen robusten adapter zu entwickeln, 
sind die entwickler das grössere problem für die firma als der 
suboptimale adapter ;-) ..aber wir reden hier ja sowieso von 
privat-hobby-entwicklern.

Autor: Wilhelm F. (ferkes-willem)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:

>Der 8048 war doch bloss ein Abklatsch davon.

Immerhin war das olle Ding damals (tm) gut genug, damit die Entwickler 
noch jeweils 20 HW- und SW-Fehler in die Geräte hinein produzierten.

Und zwar baute ich als TK-Techniker damals (tm) bei Kunden 1981 die 
ersten Familientelefonanlagen auf, die etwas intelligenter waren als 
alles zuvor. Manchmal fielen die Dinger reihenweise aus, und ich war bei 
manchen Kunden 3 mal zum Auswechseln. Aus Neugier, meine Kollegen taten 
das nicht, schaute ich auch mal in so eine Anlage hinein. Nur 8035, 2k 
EPROM, 2k RAM. Industrielle und frei gegebene Geräte. Trotzdem hatte man 
das nicht im Griff.

Und da fangen heute manche mit einem ARM-Board an, je größer desto 
besser, besser ARM9 als ARM7, und wissen oft nicht mal, was ein 
CMOS-Prozess ist, oder gar ein Spannungsteiler aus 2 Widerständen. Genau 
da sträuben sich mir die Haare, aber extrem. Die Fragen ließt man ja 
hier in der Threadliste immer wieder.

Autor: Wilhelm F. (ferkes-willem)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sven P. schrieb:

>Z80 wäre auch noch da.

Die Z80 und 8085 fand ich mal interessant, weil sie einfach einen 
gigantischen Stack bis zu 64kByte im von-Neumann-Adressraum hatten... Da 
kann man die Software demnach gestalten, daß Speicherinhalte schon mal 
auf den Stack gepusht werden, anstatt in Registern abgelegt. Bei 8048, 
8051, PIC, ist das völlig unmöglich. Ich experimentierte gelegentlich 
mal mit einer so selbst gebauten 8085-Schaltung, allerdings in 
Assembler, das war ganz nett.

Autor: Thomas Eckmann (Firma: Thomas Eckmann Informationst.) (thomase)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wilhelm Ferkes schrieb:
> Und da fangen heute manche mit einem ARM-Board an, je größer desto
>
> besser, besser ARM9 als ARM7, und wissen oft nicht mal, was ein
>
> CMOS-Prozess ist, oder gar ein Spannungsteiler aus 2 Widerständen. Genau
>
> da sträuben sich mir die Haare, aber extrem. Die Fragen ließt man ja
>
> hier in der Threadliste immer wieder.

Richtig!

Wer mal mit 8085 oder 8048 oder so angefangen hat, hat nicht nur rund 30 
Jahre Erfahrung auf dem Buckel, sondern die ganze Materie zumeist auch 
wirklich verstanden. Wenn dann ein neuer Controller ran muß, nimmt man 
sich das Datenblatt...

mfg.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.