Hallo Leute, da ich mich mit Mikrocontrollern bis dato noch nicht richtig auskenne, mich das Thema aber sehr interessiert stehe ich jetzt, überwältigt vom Angebot dieser Teile vor einer (für mich) schweren Frage. Sollte ich mich zuerst den 8051 Derivaten wie z.B. 80C535 widmen unterstützt von z.B. Bernd vom Berg`s Literatur oder sollte ich einen AVR nehmen ? Gibt es Vor- oder Nachteile wenn ich mich mit 8051 Derivaten auseinandersetze ? Zeitgemäß ? Welche prinzipiellen Gruppen gibt es noch die sich für den Einstieg lohnen und mit denen man dennoch interessante Sachen wie z.B. CAN Anwendungen machen kann ? Sagt euch Bernd vom Berg was ? Wenn ja was haltet Ihr davon...ganz objektiv !? Ich danke euch schon mal für eure Beiträge. Gruß Bernd
Mit welchem Controller du Anfängst, hängt davon ab was du damit machen willst und wieviel du dafür ausgeben willst. Ich selbst arbeite mit PICs (hab früher mit 8051ern gearbeitet) und da du diese nicht aufgelistet hast rate ich dir nicht zu diesen, sondern empfehle AVRs. Sie sind billig, schnell und leicht zu programmieren. Des weiteren gibt es viel Information und Hilfe zu den AVRs in diesem Forum. "Welche prinzipiellen Gruppen gibt es noch die sich für den Einstieg lohnen und mit denen man dennoch interessante Sachen wie z.B. CAN Anwendungen machen kann ?" Wie vorher erwähnt arbeite ich mit PICs und kann dir nur von dieser Seite sagen, dass man (fast) alles damit machen kann. Manche haben gleich eine CAN- Schnittstelle integriert oder auch andere faxen wie zb. USB,UART(hat eh schon fast jeder),Ethernet, usw... aber Atmel wird sicher auch solche Controller anbieten. Mit welchen du anfangen sollst, kann ich dir also nicht sagen. aber du kannst dir zb einen AVR (zb ATmega8) kaufen und dein Glück einmal damit probieren. Du könntest aber vl auch einen Distributer anrufen und fragen ob sie dir nicht vl ein Exemplar zuschicken würden. Bei Ribu geht das angeblich. Und falls du vl. auch einmal einen PIC ausprobieren willst, dann kannst du dir von Microchip ein paar, gratis, Samples zuschicken lassen. www.microchip.com In der Linkliste findest du auch sehr gute Seiten bezüglich PICs, da du hier nicht so viel Hilfe finden wirst. Und noch zum Schluss: http://www.mikrocontroller.net/articles/AVR_PIC_51-Vergleich
Servus Schoaschi, danke erstmal für die schnelle Antwort. So wie ich dich verstehe ist es im Prinzip eigentlich egal...hängt von der Anwendung ab. Wenn ich mich jetzt z.B. aber auf das in der Industrie übliche konzentrieren wollte, was wäre dann das beste, oder ist es dort auch so, daß es quer beet geht ? PS: Ich wollte auch nochmal fragen, ob C167 Prozessoren wieder etwas eigenes sind oder ob das unter einen der von uns schon genannten Oberbegriffe fällt und wie relevant diese Prozessoren sind. Danke schon mal
"So wie ich dich verstehe ist es im Prinzip eigentlich egal" Richtig. Aber wenn Du schon Literatur dazu hast, ist es keine schlechte Idee auch nen 8051-er zu nehmen. Auch gibt es zum 8051 die meisten Webseiten (z.B. 8052.com). Allerdings solltest Du Dir das Leben leicht machen und solche Typen nehmen, die einen Bootloader haben, z.B. Atmel AT89C51ED2, Philips P89C668, Maxim DS89C420 usw. Dann brauchst du nämlich kein extra Programmiergerät. Hier steht auch einiges dazu: http://www.mikrocontroller.net/forum/read-1-25968.html#new "oder ist es dort auch so, daß es quer beet geht" Ja. Mit den 8051-ern bist Du aber auch sehr flexibel, da es davon mit Abstand die meisten Typen gibt und ständig neue entwickelt werden. Meine ersten 8051-er habe ich z.B. aus defekten Festplatten ausgebaut. Peter
Ich denke, der 80C535 ist nicht so geeignet, da er doch schon recht alt ist. Nimm lieber einen neueren Typ, wie Peter sie genannt hat.
Servus, für den Privatgebrauch würd ich dir auch ATMEL AVR empfehlen, allein schon wegen dem STK500, eine Entwicklungsumgebung für AVR die nur um die 100 kostet und natürlich wegen der gut kommentierten kostenlosen Software (AVR-Studio). Für die Industrie würd ich allerdings 8051 raten. Diese Controller gibt es von div. Herstellern mit allem erdenklichen Zubehör. Gruß Marco
Danke für die Antworten, was mich jetzt nur noch interessieren würde, ist, wo ich die C167 Prozessoren einordnen soll ? Danke
Ich würde auf jeden Fall AVR empfehlen. Ist einfach der am besten designte. Der 8051 ist zu alt, der MSP ist mit den normalen 5V-ICs inkompatibel und der PIC ist zu sich selbst inkompatibel.
Ich betrachte die C166 / C167 als die 16Bit Nachfolger der 8051er. Es gibt hier im Forum aber bestimmt Leute die das wesentlich genauer und/oder besser wissen. Einfach mal noch eine Weile auf Postings warten. Dieter
Der 8051 hat als Nachfolger die Intel 80251 sowie Philips 8051-XA. Beide besitzen spezielle Kompatibilitäts-modi, sodaß sich auch 8051-Assembler-Software ohne großen Aufwand auf ihnen einsetzen läßt. Weite Verbreitung haben sie aber nicht erfahren. Die C166/167er dagegen sind völlig unterschiedlich.
Ich habe grad mal einen Blick in die Philips-XA Referenz geworfen. Die CPU ist ja ok, wenngleich ich wenig von Segmentierung/Paging und all dem Gedöns halte mit dem schon Intel krampfhaft 16-bittern grosse Adressräume nahebringen musste. Aber solange man bei 64KB bleibt ist das ja egal. Und ein Extra-Lob für die Idee mit den 2 Stackpointern. Vor allem aber musste ich überrascht feststellen, dass trotz weitreichenden Neudesigns sich an der reichlich problematischen Struktur der 8051-er I/O-Ports wenig geändert hat. Zwar sind die High-Side-Driver der Outputs besser einstellbar, aber an der für Compiler sehr problematischen Unterschiedung zwischen Latch und Pin bei Lesen von Ports durch den Character des Befehls hat sich nichts geändert (http://www.mikrocontroller.net/articles/AVR_PIC_51-Vergleich#Zugriff_auf_I.2FO-Ports). Als Intel das anno 8051 so definierte, hat kein Mensch an C-Compiler gedacht, allenfalls PLM/51 war drin. Kein Vorwurf an Intel also. Aber wie man ein wesentliches Neudesign heute rausbringen kann ohne diesen Punkt gradezubiegen, das ist mir unerklärlich.
Ich hab zwar noch nichts mit den C166/167er gemacht , aber mir die Instruction Set Summary angeguckt . Soo gross finde ich den Unterschied zu den 8051er nicht . Im gegenteil , die Ähnlichkeiten sind bestimmt nicht rein zufällig .
@A.K. "aber an der für Compiler sehr problematischen Unterschiedung zwischen Latch und Pin bei Lesen von Ports durch den Character des Befehls hat sich nichts geändert" Wüßte nicht, was daran problematisch sein soll. Eher im Gegenteil, Software-I2C oder 1-Wire oder sonstige bidirektionale Busse werden dadurch einfacher. Und daß man eben Lasten Low-aktiv ansteuert ist doch nur eine reine Definitonssache. Ich hatte jedenfalls bisher nie Probleme damit und programmiere vorwiegend in C. Was aber ein großer Vorteil der 8051-er Ports gegenüber den AVRs ist, daß sie atomar geODERt, geANDet und geXORt werden. Peter
Gegen die Ports selbst habe ich nichts. Was mich stört ist der Zugriff darauf. Dass also MOV A,port den Pin liest, AND port,A jedoch das Latch (als Bestandteil eines read-modify-write Befehls). Folge ist, dass ein Statement der Art port = port <operator> <value>; unterschiedliche Ergebnisse zur Folge hat, je nachdem ob es vom Compiler in eine einzigen Befehl übersetzt wird, oder aus irgendwelchen Gründen der Port erst gelesen, dann im A modifiziert und wieder zurückgeschrieben wird. Nachgewiesen beim aktuellen Keil Compiler, siehe Link oben. Ich kenne einige (non-8051) Compiler, die in solchen Fällen abhängig von Optimierungsgrad mal die eine mal die andere Variante ausspucken. Damit kann man m.E. nur umgehen, wenn man trotz C eigentlich in Assembler programmert, d.h. Port-I/O zwar in C formuliert, aber stets genau im Auge hat, was der Compiler für Befehle erzeugt. Will man das korrekt machen, kann man definieren, dass direkter Zugriff auf einen Port lesend immer die Pins liest. Was freilich port |= 0x01 sinnlos macht, weshalb dafür spezielle Compiler-Funktionen nach Art port_set(0x01) notwendig werden. Das ist dann zwar nicht schön, aber wenigstens mit der Sprachdefinition von C vereinbar. Alternativ kann man natürlich auch verschiedene Pseudo-Ports definieren, also z.B. PORTA für's Latch (nur write und read/write möglich) und PINA für die Pins (readonly).
Woraus ich eigentlich raus will: Warum gibt's in 51-er oder eben XA nicht endlich verschiedene SFR Adressen für Pin und Latch. Im Fall von XA wären es dann 3, eine 51-kompatible und zwei neue für saubere Programmierung.
@A.K. "Nachgewiesen beim aktuellen Keil Compiler, siehe Link oben." man muß eben im Hinterkopf behalten, daß nur reine &, | und ^ atomar sind. Kombinierte &,| werden daher mit dem Input-Register ausgeführt, was low getriebene Eingänge falsch setzen kann. Z.B. um 4 Pins zu setzen (LCD 4Bit) ohne die anderen zu beinflussen geht folgende Lösung: P1 &= 0x0F; P1 |= (i & 0xF0); Im Prinzip hast Du recht, man könnte mit nur einem weiteren Portregister, welches immer nur das Ausgangslatch liest, die Sache bereinigen. Es scheint aber bisher kein echter Leidensdruck in diese Richtung zu herrschen. Peter
Thread beobachten
Seitenaufteilung abschaltenBitte 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.