hallo, ich hätte lust mal was ´mit PIC oder Amtel ics zu machen, habe allerdings null erfahrung in die richtung. ich habe bis jetz nur ein bisschen mit cmos4XXX und ein paar anderen gebastelt, und kenn mich da auch noch net sehr gut aus. jetz is meine frage, was is für einsteiger besser PIC oder amtel? auch von den kosten her, weil ich will eigentlich net mehr als 30 für son board ausgeben. ich hab auch schon welche gesehen die bauen sich an der rs232 selber ausn paar widerständen und so selber sonen kleine adapter, ist das empfehlenswert? sepp
was ist den der eigentliche unterschied zw. den beiden? gibt es große unterschiede im funktionsumfang?
Deine Frage hier wurde schon des öfteren besprochen. Einige werden sagen, dass du PICs nehmen sollst(unteranderem auch ich ;-)) die anderen werden sagen, dass du AVRs nehmen sollst :-). Von den Kosten her ist es auch recht egal welchen Hersteller das du wählst, denn diese µC befinden sich fast alle in der selben Preisklasse(wenn nicht sogar die AVRs vl etwas günstiger sein mögen). Programmiergeräte sind ebenfalls in der selben Klasse. Es gibt welche die nur aus ein paar Widerständen bestehen oder etwas aufwändigere(sowohl für PIC als auch AVR). zb.: PIC http://www.stolz.de.be/ AVR: http://homepage.sunrise.ch/mysunrise/peterfleury/avr-starterkit.html#ISP Enwicklungsboards sind recht einfach selbst gemacht .. auch gute ;-)... denn es gibt schon sehr viele davon Schaltungen davon im Internet zu finden und man braucht sie nur nachbauen. Dadurch halten sich da die Kosten auch geringer. Somit ist es von diesen Standpunkten her egal welche du nimmst. Der Grund warum ich mit den PICs arbeite ist einfach der, da mir der Compiler einfach mehr zugesagt hat. Ein weiterer Grund warum ich PICs empfehlen kann ist der, da die PICs untereinander sehr gut Pin-Kompatibel sind(ich kenne mich hier bei den AVRs nicht aus und will es nicht abstreiten, dass sie es auch währen). d.H. Ich kann jetzt einen PIC18F benutzen und wenn dieser zu langsam ist, dann nehme ich einfach einen PIC24F her und setze diesen ein, ohne das ich hier etwas an der Hardware verändern muss. Achja... welche Programmiersprache willst du denn überhaupt benutzen? mfg Schoasch
Also ich finde ja du solltest den R8C nehmen. Schon allen deshalb weil es da noch keine Megadiskussion gab was denn nun besser ist. :-) Ein praxisnaher Vorteil des R8C koennte aber sein das sich jetzt auch problemlos an einem USB-RS232 Adapter brennen laesst. Olaf
Habe die erfahrung gemacht, das die avr ganz schön schmerzfrei sind, mal einen verkehrt eingesetzt, und nix passiert. also zum basteln ideal.
@Schoaschi Pin-Kompatibel sind die AVR's nur "teilweise". Die 8-Pin-Typen sind soweit ok, bei den größeren hängt es dann schon davon ab ob ein AD vorhanden ist oder nicht... die mit AD-Wandler haben u.a. teilweise die Spannungsversorgung an anderen Pinnen. Ich denke mal aus dem Grund sind bei dem STK500 auch für jeden Prozessor 2 Sockel vorhanden...
@Olaf "Also ich finde ja du solltest den R8C nehmen. Schon allen deshalb weil es da noch keine Megadiskussion gab was denn nun besser ist. :-)" Das ist natürlich ein super Grund. Und wenner dann Fragen hat, steht er voll im Regen !!! Also gefühlsmäßig würde ich sagen, daß Du hier im Forum bei AVR-Fragen die meisten Antworten bekommst. Und das würde ich für einen Anfänger als oberste Priorität setzen. Was nützt die allerschönste Architektur, wenn man damit nicht klarkommt. Peter
Die avr teilen die taktfrequenz nicht, wenn du schnelle sachen hast, dann fährst de damit bestimmt besser
Ich finde AVR viel besser als PIC, denn PIC hat zahlreiche Nachteile: Wenn du z.B. unter C programmieren möchtest deckst du mit einem Compiler alle AVRs ab. Bei PIC-Prozessoren deckst du immer nur eine winzig-kleine Familie ab, da die einzelnen PIC-Architekturen sehr inkompatibel zueinander sind. Auch mit der Jumperei tun sich die Pics recht schwer. Die Quarzgeschwindigkeit wird bei den AVRS nicht heruntergeteilt, bei den Pics schon. AVRS: Jede Einheit hat einen eigenen IRQ-Vector. - Pic: Es muss erst in der IRQ-Routine festgestellt werden, welcher IRQ aufgetreten ist und dies benötigt wertvolle Zeit. AVRS: Große Auswahl. Pics: So große Auswahl (mindestens an die über verschiedene 200 Modelle), dass man im Prinzip keine Ahnung mehr hat, welchen man nehmen soll. Tschüss, Martin
Ob ein Prozessor seinen Takt nun teilt oder nicht ist doch erstmal vollkommen egal. Wichtig ist doch wie schnell er letztlich ist. Ich hab mit dem R8C letzte Woche ein FIR-Filter mit fs=40kHz und 51Taps gebaut. Damit ist der R8C/13 dann gut ausgelastet. Wobei er aber AD-Wandlung und DA-Wandlung (ueber PWM) gleich miterledigt. Wieviel macht denn da so ein AVR oder PIC? Olaf
Irgendeiner schrieb hier von Pinkompatibilität der Pic's. Vergiss es... Die Entwicklungsumgebungen von AVR und PIC sind Vergleichbar, was die Assemblerprogrammierung betrifft. Vorteil AVR: GNU-C (gefällt mir prima, daß es im AVR-Studio implementiert wird (echter Pluspunkt, kostet beim Pic richtig Geld). Noch ein Nachteil PIC: die indirekte Adressierung. Man kann eine echte Kriese bekommen. Ach mich wunderts, es gibt Fans vom R8C? Jetzt habe ich wenigstens schon mal gehört, daß er benutzt wird.
Das kann schon sein. Der R8C ist ja ein 16-Bit, wenn ich das richtig im Kopf habe, aber wenn man mal schnell einen Port-Pin softwaremäßig tooglen möchte, ist der R8C um Längen langsamer als ein AVR. Außerdem ist mir aufgefallen, dass der R8C bereits durch kleinste Störeinflüsse einfach in den Programmiermodus fallen kann. Warum hältst du so an dem Renesas fest? Arbeitest du bei dieser Firma?
>Vorteil AVR: GNU-C (gefällt mir >prima, daß es im AVR-Studio implementiert wird (echter Pluspunkt, >kostet beim Pic richtig Geld) Nö, zumindest bei der 18F Reihe. Kostenloser C Compiler der sich auch in das MPLab integriert.
ich kenne viele geräte die den m16c nutzen (autoradios etc).. So schlecht scheinen die nicht zu sein. Aber leider kaum verbreitet (das ist wie mit windows- da findest du sehr viel hilfe, wenn du welche brauchst) wenn du erst anfängst mit programmieren ist bascom echt ne feine sache.. da kannst du programmieren ohne wirklich nah mit der hardware in berührung zu kommen, und es ist ein simpler syntax
@Olaf "Ich hab mit dem R8C letzte Woche ein FIR-Filter mit fs=40kHz und 51Taps gebaut. Damit ist der R8C/13 dann gut ausgelastet." Dann stell doch mal den C-Code hier rein, damit man auch sehen kann, wie der AVR damit zurecht kommt. Peter
O.k. kann ich nicht mitreden. Habe nur 12C??? --> 16F??? benutzt. Aber grundsätzlich ist das prima, daß wenn einer den Anfang macht, es andere ebenfalls dazu animiert, C-Compiler zur Verfügung zu stellen.
Ich rate vom R8C auch ab. Begründung: Die Seite die im Elektor angegeben ist, ist ein ziemlicher Mi**. Man findet keine informationen und sie schaut recht unprofesionell aus. Des weiteren gibt es hierfür noch nicht so viele Hilfen und schon Beispiele(zumindest nicht so Massenhaft wie für AVRs und PICs). Was mich dann doch etwas gewundert hat, war die tatsache das der R8C 8MIPS schaft und der PIC jedoch 10MIPS. Wie schon vorher erwähnt wirst du hier im Forum sehr viele Antworten auf AVR Fragen bekommen. Jedoch gibt es das Forum von Fernando Heitor(www.fernando-heitor.de), welches sich Hauptsächlich mit PICs beschäftig. Ich bin dort sehr gerne, da es sehr kompetente Leute dort gibt, die dir auf (fast) jede Frage eine Antwort geben. WElche Programmiersprache willst du eigentlich benutzen???
> Ob ein Prozessor seinen Takt nun teilt oder nicht ist doch erstmal > vollkommen egal. Wichtig ist doch wie schnell er letztlich ist. Ja. Ich hab zwar keinen Vergleich, aber AVRs sind da sehr gut, da ein Großteil der Befehle nur einen Taktzyklus brauchen und auch die anderen recht flott sind. Bei einem Takt von teilweise bis zu 20Mhz kann man da schon ganz schön was rausholen. > Ich hab mit dem R8C letzte Woche ein FIR-Filter mit fs=40kHz und > 51Taps gebaut. Damit ist der R8C/13 dann gut ausgelastet. Da ich noch kein FIR-Filter implementiert hab, kann ich nicht sagen, wie schnell das auf dem AVR wohl wäre. > Wobei er aber AD-Wandlung und DA-Wandlung (ueber PWM) gleich > miterledigt. Die kriegst du bei den meisten AVRs auch schon dazu. Der AD-Wandler kann aber nur 15kHz. Die PWM ist weniger kritisch, vor allem, wenn man einen mit highspeed-PWM verwendet.
Hab noch nix mit AVR's gemacht, aber falls Du mit PIC's anfangen willst: Nimm die PIC18F! Lohnt nicht mehr mit den alten 16er anzufangen, denn die sind gegenüber den AVR's echt benachteiligt (langsam, wenig Speicher, keine vernünftigen kostenlosen Compiler, elendes RAM-Banking) Bei den PIC18F kriegste von Microchip ne megafette IDE umsonst mit allen Schikanen, nem kostenlosen Compiler der alle Controller unterstützt und eine Busladung voll Apllication Notes und Beispielen. Bei den 16ern findet man dagegen kaum einen Compiler ohne Einschränkungen, der mal wirklich die ganze Familie abdeckt. Zitat "Pics: So große Auswahl (mindestens an die über verschiedene 200 Modelle), dass man im Prinzip keine Ahnung mehr hat, welchen man nehmen soll." Dafür hat Microchip aber nen Tool auf der Seite :) Ausserdem ist Reichelt so freundlich, das Problem für uns zu lösen, denn die beschränken die Auswahl auf ein wesentlich überschaubareres Maß. Gute Typen-Übersichten gibts bei www.sprut.de (im übrigen eh eine geniale & super-wertvolle Seite!)
Mal ne Frage: Haben die AVR's auch soviel Zusatzhardware? Sprich: CAN,USB,ZigBee,RF-Schnittstellen usw. ? Ist nämlich gerade für Heimprojekte ein wichtiger Faktor!
Mal ein paar Antworten zusammengefasst: 1. Nein ich arbeite nicht fuer Renesas. (und auch nicht fuer Glyn oder Elektor) Ich fand es nur schade das immer alle nur dasselbe machen. Es erweitert doch den eigenen Horizont ungemein wenn man auch mal etwas anderes anschaut. 2. Ich hab das Projekt mit dem Filter vor ein paar Tagen an Burkhard (schreibt in der Elektor oefter als B.Kainka) geschickt und er wollte es auf der Homepage von Elektor veroeffentlichen. Ich weiss aber nicht ob er es schon getan hat. Ich weiss auch nicht ob das viel helfen wird. Das Knowhow dieser Filter liegt im ausrechnen der Koeffizienten. Der eigentliche Filter ist dann Spielkram. Man muss nur 51x zwei 16Bit Zahlen multiplzizieren und das Ergebniss 32bittig addieren. Und das ganze natuerlich 40000mal pro Sekunde. Dafuer hat der R8C einen speziellen Assemblerbefehl. Daher denke ich nicht das ein AVR da mithalten kann. Interessanter waere es vielleicht wenn mal jemand vergleicht wie gut die Prozessoren bei primitiven Portzugriffen und aehnlichem sind. Aber ich denke auch da wird ein R8C gut wegkommen weil man bei den Assemblerbefehlen auch direkt nur eine Wortbreite von einem Byte angeben kann. Ausserdem kann er auch Bitweise zugreifen. 3. Da ich nun fuer keine der am Elektorprojekt beteiligten Firmen arbeite kann ich auch offen meine Meinung sagen. Vor dem Hintergrund versteh ich wirklich nicht was das genoergel an der Doku soll. Es ist naemlich vollkommen egal was auf irgendwelchen Homepages steht. Wer mit einem Prozessor umgehen will der sollte mal einfach sein Datenblatt lesen. Zwar koennte das English der Renesas Datenblaetter sicher etwas besser sein, aber sie lassen sich durchaus verstehen. Vielleicht sollte also so manche dessen Kenntnisse sich ueberwiegen aus abschreiben und jammern nach fremden Codeschnipseln besteht vielleicht einfach mal auf den Arsch setzen und ein Buch lesen! 4. Der Grund warum es mir Spass macht die R8C zu benutzen ist uebrigens das sie insgesammt als 16Bit Prozessoren in einer ganz anderen Liga spielen als die kleinen. Gerade wenn man in C programmiert fallen einem viele Dinge deutlich leichter weil man eben nicht so schnell Wertebereich ueberschreitet. Auch der Umgang mit Fliesskommazahlen ist im begrenzten Umfang machbar. Aber das bedeutet jetzt natuerlich nicht das ich immer R8C oder M16C(der ist uebrigens richtig goil) benutzen werde. Man waehlt einen Microcontroller schliesslich nach der Aufgabe aus die man loesen moechte. 5. Unabhaengig wie man zu Elektor steht, und ich stehe dem Blatt eher kritisch gegenueber, hat das aktuelle Heft den Vorteil das man wie sonst nirgendwo an die Hand genommen wird und einem alles recht einfach nahegebracht wird. Wer es damit nicht schafft sollte vielleicht doch besser Briefmarken sammeln. Olaf
@Olaf Ich habe ja nichts gegen Exoten am richtigen Platz und kann auch deiner Argumentation folgen. Jeder der mehrere Controller unterm Finger hatte wird dir aber auch sagen, daß es als Anfänger oft nicht auf den optimalsten Mikrocontroller ankommt, sondern Dinge wie: Foren oder priv. Sites primär zum Lernen wichtiger sind. Deswegen ist der Rat einem Anfänger den R8C nahezulegen zwar gut gemeint aber nicht wirklich das wahre.
hab auch mit nem AVR(ATMega162) in Assembler angefangen und hatte keine Probleme. Man beachte das einsteiger tut gaaaaaaaaaaaaaaaanz oben links. Das hat mir sehr geholfen.
Um wirklich sinnvolles zustande zu bringen, ist es meiner Meinung nach nicht so wichtig, den dafür idealen MC zu finden. Viel wichtiger ist eine genaue Kenntnis "meines" Prozessors und meiner Werkzeuge. Ok, wenns nicht geht, gehts nicht, dann muss man sich umorientieren. Mit einem unbekannten Rechenmonster bekomme ich nicht automatisch ein besseres Gesamtergebnis als mit der vertrauten Gurke (95% meiner Projekte mache ich mit AVR). Ohne Not bewege ich mich da kein Stück. Und um alles zu testen, was interessant wäre, fehlt mir die Zeit.
> Man muss nur 51x zwei 16Bit Zahlen multiplzizieren und das > Ergebniss 32bittig addieren. Und das ganze natuerlich 40000mal pro > Sekunde. Dafuer hat der R8C einen speziellen Assemblerbefehl. ATmegas haben auch einen Multiplikationsbefehl, der aber nur 8bit-Zahlen mutlipliziert. > Daher denke ich nicht das ein AVR da mithalten kann. Überschagsmäßig: eine 16bit-Multiplikation lässt sich aus vier 8bit-Multiplikationen zusammensetzen. Macht also etwas über 8000000 Multiplikationen für die er jeweils zwei Taktzyklen braucht, also gut 16 Millionen Taktzyklen. Werte Einlesen und Rausschreiben und die üblichen Schiebereien kosten natürlich auch noch was, also dürfte es bei einem maximalen Takt von 20Mhz doch arg eng werden. > Interessanter waere es vielleicht wenn mal jemand vergleicht wie > gut die Prozessoren bei primitiven Portzugriffen und aehnlichem > sind. > Aber ich denke auch da wird ein R8C gut wegkommen weil man bei den > Assemblerbefehlen auch direkt nur eine Wortbreite von einem Byte > angeben kann. Ausserdem kann er auch Bitweise zugreifen. Der AVR braucht zum Schreiben eines Byte an einen Port einen Taktzyklus. Einzelne Bits gehen auch, aber das braucht dann zwei Taktzyklen. > 4. Der Grund warum es mir Spass macht die R8C zu benutzen ist > uebrigens das sie insgesammt als 16Bit Prozessoren in einer ganz > anderen Liga spielen als die kleinen. Gerade wenn man in C > programmiert fallen einem viele Dinge deutlich leichter weil man > eben nicht so schnell Wertebereich ueberschreitet. Auch beim AVR kann ich gerade in C auch problemos mit größeren Datentypen arbeiten. > Auch der Umgang mit Fliesskommazahlen ist im begrenzten Umfang > machbar. Das ist ebenfalls beim AVR machbar.
HI Kleine Entscheidungshilfe: sieh dir mal die Datenblätter von vergleichbaren Atmel und PICs an und entscheide womit du mehr anfangen kannst. MfG HG
Mit der Entscheidung sollte man vielleicht noch ein paar Monate warten, da die aktuellen 18F PICs anscheinend alle haufenweise Fehler haben (einfach mal einen Blick in die Errata werfen, beispielsweise beim 18F4620). Laut der Antwort auf ein Ticket von mir sollen diese Bugs im ersten Quartal 2006 behoben werden, was aber eine recht schwammige Aussage ist und ich weiß immer noch nicht mit Sicherheit, ob wirklich alle Errata beseitigt werden. Mir ging es im Ticket insbesondere um einen Bug bei RS232-Transmit mit Parität, was beim 18F452 tadellos funktioniert, beim 18F4620 aber den Baudratengenerator neu initialisiert sobald TX9D gesetzt wird, was dann den Inhalt des TSR zerschießt...
@Michael "Mit der Entscheidung sollte man vielleicht noch ein paar Monate warten, da die aktuellen 18F PICs anscheinend alle haufenweise Fehler haben" Warum warten, ich finde, daß erleichtert die Entscheidung doch ungemein. Und warten tue ich grundsätzlich nicht, das kann ich mir nicht leisten. Ich nehme nie die allerneuesten Chips, sondern nur solche, die mindestens 1..2 Jahre am Markt sind. Ich habe nicht die Zeit, die Bugs zu finden, d.h. für den Hersteller die Arbeit zu machen. Außerdem will ich auch keine Lieferengpässe. Peter
@Schnupperkursbesucher: Ich habe schon diverse MCs hinter mir, 8048, 6502, 6800 etc.und die AVR erscheinen von Ausstattung und Programmierbarkeit noch mit am einfachsten. Dazu kommt, mittlerweile sind die Teile auch sehr preiswert geworden. Empfehlenswert zum Einstieg: ATMega8(8kB), ATMega16(16kB), ATMega32(32kB) Für kleinere Projekte den ATTiny2313. Eine Warnung allerdings: Beim grossen C sollte man die Teile nicht kaufen, man bezahlt sich dumm und dusselig. Gute Quellen: www.Reichelt.de , www.elektro-nix.de . Entwicklungssystem: http://www.atmel.com/dyn/products/tools_card.asp?tool_id=2725 Daten: http://www.atmel.com/dyn/products/devices.asp?family_id=607 Programmiergerät: http://www.lancos.com/prog.html Und wie schon weiter oben bemerkt, ganz links oben in der Ecke das Tutorial. Hoffe, das hilft weiter Gruss Jadeclaw.
Hallo, also ich hab mit PICs 17C und 18F Erfahrungen sammeln "dürfen" und muss sagen nie wieder. Als Assemblerprogrammierer kann man auf den Teilen echt ausflippen, das ganze Bankingzeugs ist einfach grauenhaft und der Accumulator-Zentrierte CPU-Kern ist echt scheußlich. Der Protz im C64 war da sogar bedeutend angenehmer. Der PIC schaft zwar bis 10MIPS aber viele Befehle kann man sich auf einem ordentlichen Protz sparen so das unterm Strich recht wenig übrig bleibt. Auch C-Compiler tun sich mit nur einem Register recht schwer. Vor gut einem Jahr hab ich mit den AVRs von Atmel angefangen und muss sagen die sind von der Programmierung her deutlich besser, eben fast richtiges RISC. Auch sonst findet man viele Details wo die AVRs eichfach besser sind (z.B. Interruptvektoren). Die C-Compiler können sich auf diesem CPU-Kern auch deutlich besser austoben und erzeugen IMHO effizienteren Code. Die Peripherie ist bei beiden nicht gerade schlecht und viele Standartkomponenten, wie z.B. UART, sind sich sogar recht ähnlich. Auch die Ausstattung (PWM,Timer,UART,I2C,SPI,EEPROM ...) an sich ist recht ähnlich. Das Preis/Leistungsverhältnis ist auch etwa gleich (wenn man mal von dem beschissenen CPU-Kern der PICs absieht). Das Spectrum an Gehäusevarianten ist ebenfalls ungefähr gleichwertig. Für größere Sachen bevorzuge ich übrigens ARM, aber die sind nicht unbedingt einsteigerfreundlich. Grüße Erik the Vikinger
merci8 für die vielen antworten, mal schauen was ich jetz da mache... UND, beim C bestell ich sowieso NIX mehr. dass war reine naivität mit meinen 13 jahren damals!
Wie stehts es eigentlich mit der Fachliteratur. Beim Suchen in amazone.de werden die Bücher für PIC's und AVR's ziemlich schlecht bewertet. Gibt es trotzdem für Einsteiger gute (und noch erhältliche) Bücher, die man empfehlen kann?
@Olaf, Früher oder später holt man sich die original Datasheets, Usermanuals, Applicationnotes vom Hersteller, denn je näher eine Dokumentation an der Quelle sitzt, umso weniger Fehler enthält sie und umso aktueller ist sie. Für den AVR ist neben diesem hier auch das avrfreaks.net Forum sehr kompetent. Da ich schon 1997 mit dem AVR angefangen habe, stellte sich das Problem der Fachliteratur erst garnicht, es gab nur Atmel. Immerhin hatten sie damals noch Datenbücher gedruckt und verteilt. Peter
@Peter Dannegger: Gibt es die Datenbücher heute nicht mehr in gedruckter Form? Wenn es diese noch gibt, wo kann man sie bekommen?
@Peter Dannegger "Warum warten, ich finde, daß erleichtert die Entscheidung doch ungemein." Stimmt, so kann man es natürlich auch sehen. Zumindest momentan kann ich die aktuellen PIC18 nicht wirklich empfehlen und die älteren sollte man laut Microchip eigentlich nicht mehr für neue Designs verwenden. Was die Beschränkung der PIC-Architektur betrifft: Es gibt inzwischen mit PIC24 eine 16-Bit Architektur mit mehr Registern. Die habe ich mir aber nur kurz mal angeschaut und nicht damit gearbeitet. Da die auch noch recht neu ist, sollte man (insbesondere nach meinen kürzlich gemachten Erfahrungen mit PIC18) vorher auf jeden Fall einen sehr genauen Blick auf die Errata werfen.
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.