Hallo, ich beschäftige mich seit langem mal wieder mit µCs und stelle fest, dass (fast?) alle ATMELs einen integrierten Taktgenerator mit 10MHz haben und damit 10 Mio Befehle/s abarbeiten können. Etwas vergleichbares finde ich bei PICs nicht. Da gibt es nur selten 8MHz, die nur 2 Mio Befehle/s bringen. Obendrein sind die ATMELs auch noch preiswerter. Sehe ich das richtig, dass die PICs da derzeit nicht mithalten können?
von diesen hochgetakteten Teilen halte ich gar nichts. Vielleicht kennt jemand die CMUcam2. Da ist ein mit 75MHz getakteter 8051 Clone drauf. Kann Color Tracking mit einem Objekt und einer Farbe und der UART musste afaik in Software emuliert werden. Zu allem Überfluß braucht die gesamte Cam weit über 200mA Es gibt einen Nachbau mit einem ATmega8, der mit 17,7MHz getaktet wird. Heißt AVRcam. Kann Color Tracking mit 8 Objekten in 8 verschiedenen Farben und braucht dabei nur rund 50mA. Meine Meinung: Wenn ein AVR nicht mehr reicht kann man gleich nen ARM nehmen
Zumal es recht "dicke" AVRs oberhalb des Mega128 gibt, die schon ´ne ganze Latte an Peripherie mitbringen und auch gut Speicher für extravagante Anwendungen haben.
Mark Thalle wrote: > Hallo, > > ich beschäftige mich seit langem mal wieder mit µCs und stelle fest, > dass (fast?) alle ATMELs einen integrierten Taktgenerator mit 10MHz > haben und damit 10 Mio Befehle/s abarbeiten können. > Etwas vergleichbares finde ich bei PICs nicht. Da gibt es nur selten > 8MHz, die nur 2 Mio Befehle/s bringen. Es gibt viele 20MHz Typen (5 MIPS). Die PIC18 laufen je nach Typ mit 25 bis 64MHz, das sind nach der Microchip'schen Division durch vier immer noch bis zu 16 MIPS. > Obendrein sind die ATMELs auch noch preiswerter. Welchen Vergleich legst Du zugrunde? > Sehe ich das richtig, dass die PICs da derzeit nicht mithalten können? "Die PICs" sind eine extrem breit gefächerte Familie vom 6-Pin-Typ bis zum 100-Pin Typ. Dabei kommen von USB über CAN bis zu DSP alle möglichen Features vor. So gesehen kann ein realistischer Vergleich jeweils nur durchgeführt werden, wenn die Kriterien dokumentiert werden. (wie hiess es damals noch: "Dash wäscht weisser..."). Severino
Ich bezog mich jetzt auf die typischen Bastel-µCs mit FLashspeicher in der 2-Euro-Klasse. Da finde ich keinen PIC, der mit einem ATMEL mithalten kann, was die Rechenleistung und den Preis angeht. Vor allem finde ich auch den internen Takt von 9,6 MHz extrem praktisch.
Auf der CMUcam ist ein SX52 von Ubicom. 75MIPS @ 75MHz. Hat 3 Timer, nen Watchdog und das wars. Und dafür brauch er bei 75MHz noch >100mA. Irgendwie unbefriedigend. >>"Die PICs" sind eine extrem breit gefächerte Familie vom 6-Pin-Typ bis >>zum 100-Pin Typ. Dabei kommen von USB über CAN bis zu DSP alle möglichen >>Features vor. Naja, die neuen 16 Bit PICs kann man mit den "klassischen" ja nicht vergleichen. Da darf ich dann auch die AVR32 (zumindest die UC3) mit ranziehen. Die normalen AVR gibts auch von 8 bis 100 Pins, von 2-256kB Flash, USB, CAN, sogar FPGA. Und einen Controller mit >60MHz takten zu müssen um die Rechenleistung eines 16MHz Controllers zu erreichen? Kostet nur Strom Also was Preis/Leistung/Energieverbrauch... angeht sind die AVR unschlagbar. Die neueste Generation mit PicoPower braucht nur noch gut die Hälfte der Energie bei gleicher Rechenleistung (ATmega32/ATmega324P). Mag sein das es für Spezialaufgaben besser Controller gibt.
Also wenn ich z.B. mal einen Tiny 45 nehme, da gibt es zwar einige Befehle mit einem Takt, viele brauchen aber 2, 3 oder 4 Takte. Was den Preis angeht, ist es ein Unterschied, ob du als Firma tausende einkaufst oder ob du Hobbybastler bist. Und selbst als Hobbybastler macht es z.B. einen Unterschied, ob du die Preise von Reichelt oder Conrad als Messlatte nimmst. Oder noch andere. Mein letzter Vergleich bei sehr preiswerten Mikrocontrollern und Reichelt fiel auch zugunsten von AVR aus. Also die Klasse Tiny 11 oder Tiny 12/13. Die gibt es teilweise deutlich unter 1 Euro. Tiny 11 für 60 Cent. Nur: Was interessiert beim Basteln, ob ein Chip 1 oder 4 Euro kostet? Das ist doch absolut uninteressant. Die vielen Stunden, die man in ein Projekt steckt, da ist das völlig Peanuts. Und eine Holzleiste, die man im Baumarkt kauft, um sie irgendwo im Projekt zu verbauen, kostet schon 3-5 Euro. Anders sieht es aus, wenn man einige hundert Stück von irgendwas baut.
@Winfried: was das angeht geb ich dir völlig recht. Ein paar Cent rauf oder runter sind im Hobbybereich egal. Deshalb verstehe ich auch nicht warum viele unbedingt immer den kleinstmöglichen Controller für etwas verwenden wollen. Ich nehm sicherheitshalber immer 1-2 Nummern größer, sofern die Größe keine Rolle spielt
Also aer Vergleich AVR vs PIC ist ja irgendwie wie der Vergleich Linux vs Windows. Alles hat seine Vor und Nachteile. Ich bevorzuge als Hobbybastler die AVR's, da ich bis jetzt weder einen PIC, R8C oder MSP430 programmiert noch verbaut habe. Diese haben sicher auch einige Vorteile, bei denen sie gegen die AVR's punkten können, aber wenn ich die Einarbeitungszeit wieder rechne, spricht das bei einem Bastelprojekt eindeutig gegen einen Wechsel. Wenn es nicht unbedingt sein muss und nicht unbedingt das Feature X vom Chip Y brauche, werd ich also noch ne Weile bei den AVR's bleiben :-) Gruß Roland
Als ich heute gesehen habe, dass die ATMELs alle eine interne Taktversorgung haben, die keine externen Bauteile mehr benötigen, war ich überrascht. Und wenn man vergleichbare uCs zu PIC 16Fxxx von AVR ranzieht, dann sind die AVRs meistens schneller. Insofern finde ich das schon einen beachtlichen Vorteil. Der Preisunterschied mag nicht gewaltig sein und für Bastelprojekte auch nicht entscheidend, aber man kauft ja auch nicht nur einen Baustein, wenn man etwas bestellt, sondern gleich das Eine oder Andere dazu, was man meint bald mal gebrauchen zu können. Und wenn man dann 5 statt 2 Euro hinlegt, dazu noch die passenden Quarze und Kondensatoren, dann ist man schonmal einen Zwanni mehr quitt. Da ich gerade im Bereich Modellbau bastele, kommt es auf die Größe und das Gewicht an. Da fänd ich es schon angenehm, wenn ich mir ein zusätzliches Quarz sparen könnte und damit nicht auf der möglichst kleinen Lochrasterplatine die Portpins zubauen müsste.
> Sehe ich das richtig, dass die PICs da derzeit nicht mithalten können? Naja - das ist wieder ein halbes Troll-Posting ... Jeder nimmt das her was er kennt und woran er sich gewöhnt hat, ABER: in der Industrie setzt sich immer der preisgünstigste Controller durch der die gewünsche Aufgabe zufriedenstellend erledigen kann. Und hier können die PIC sehr wohl mithalten!
PICs sind GRATIS... hab noch nie einen Controller kaufen müssen, bestell mir regelmäßig Samples... Aber dieses PIC vs. AVR ist schon so oft diskutiert worden, nehmt doch was ihr wollt. Beim Entwickeln von Elektronik geht es schlussendlich nur darum, dass die Entwicklung das macht was man von ihr erwartet. Ob man das mit einem AVR oder PIC macht ist dann egal. Man kann PIC und AVR auch nicht wirklich gegenüberstellen. Bei PIC, auch wenn er schlechtere Performance hat, hat man eben mehr Auswahl an Typen mit unterschiedlichen Peripherien. Es geht nicht nur um MIPS!!! Wer MIPS braucht soll sich einen BF561 zulegen und taktet ihn mit 600MHz... Aber mein ARM7 kann viiiieeeeellll mehr als eure klumpigen AVRs und PICs ätsch lol
>PICs sind GRATIS... hab noch nie einen Controller kaufen müssen, bestell >mir regelmäßig Samples... Schnorrer
Clifford wrote:
> Schnorrer
Tja man tut was man kann ;-)
Aber das ist für Firmen ganz legitim.
"Aber mein ARM7 kann viiiieeeeellll mehr als eure klumpigen AVRs und PICs *ätsch*" Aus dem Alter bin ich raus. Ich benutze nur noch die ARM9 (von ST). Mehr Speicher, schneller durch längere Pipeline und höheren Takt, etc. pp.
Wenns den ARM9 in kleineren Bauformen geben würde und dann noch per Hand lötbar, würd ich dir zustimmen. Ich hab in meinem letzten Projekt einen AT91RM9200 verwendet, der funzt auch recht gut.
Das programmieren der ARM9er ist aber nicht so einfach wie AVR oder ARM7. Geht ja nix mehr ohne Betriebssystem (linux). Dann muss man ja irgendwie treiber für seine peripherie programmieren (kA mit was für funktionen linux dafür schon daher kommt) usw. Es fehlt auch an solch schönen tutorials für ARM7 und ARM9 wie die beiden AVR tutorials auf dieser Seite.
> Also was Preis/Leistung/Energieverbrauch... angeht sind die AVR unschlagbar So ähnlich hatte ich auch gedacht, bis ich mich mal mit der MSP430 Familie von TI beschäftigt habe. Seit dem bleiben die AVRs in der Kiste.
"Das programmieren der ARM9er ist aber nicht so einfach wie AVR oder ARM7. Geht ja nix mehr ohne Betriebssystem (linux). Dann muss man ja irgendwie treiber für seine peripherie programmieren (kA mit was für funktionen linux dafür schon daher kommt) usw." Das ist Quatsch. Der ARM9 ist schlichtweg ein aufgebohrter ARM7. Insofern (fast) kein Unterschied. Ich nutze die einfachste Variante, nicht die mit FPU oder MMU. Ein bißchen komplexer als ein AVR, aber der Umstieg vom AVR zum ARM9 ist nicht komplexer als der Einstieg in die Mikrocontrollerwelt. Im Übrigen läßt sich der STR9-80Pinner mit ruhiger Hand recht einfach löten. So viel größer als ein 64Pinner ist der auch nicht.
Heee! Hier ging es um PIC und AVR! Bitte, ARM7- und ARM9-Fans, und Fans von Exoten, eröffnet doch einen eigenen Thread für Euch. Die Diskussion um PIC vs. AVR ist endlos. Ganz im Ernst: sachliche Argumente wären sehr nützlich, sind aber in der ganzen Komplexität kaum statisch darstellbar. Eine einfache Tabelle mit Kriterien und Plus- und Minus-Punkten reicht da nicht, da offensichtlich die Kriterien sehr individuell gewichtet werden (inkl. Entwicklungsumgebung, Einarbeitungsaufwand, Support, langfristige Verfügbarkeit, ...) Severino
@Severino R.: Dann hätte die Aussage aber lauten müssen: "Also was Preis/Leistung/Energieverbrauch... angeht sind die AVR in der Klasse bis 2,- EUR den PIC in der Klasse bis 2,- EUR überlegen" Zudem würde ich die MSP430 - Familie nicht als Exoten bezeichnen.
@ Bastler0815 Nimm's nicht persönlich mit den "Exoten". Die MSP430 sind hervorragende Controller, nur leider weniger bekannt als andere. Ich wollte damit sagen, dass es ja schon schwierig ist, PIC und AVR einander gegenüber zu stellen. Wenn jetzt auch noch andere Produkte ins Spiel kommen.... Die zitierte Aussage ist ja nicht von mir. Aber Du siehst, es ist absolut unmöglich zu sagen, welcher Controller der bessere ist, da Uneinigkeit herrscht über die Bewertungskriterien und deren Gewichtung. Wertvoll wären Aussage wie: "Wenn Feature xxx ein Muss ist, dann ist Typ yyy im Vorteil". Alle wesentlichen Kriterien und deren Werte pro Mikrocontroller darzustellen bedeutet eine mehrdimensionale Tabelle erstellen. Was toll wäre (wenigstens für die "harten" Kriterien), einen Product Selector zu haben, wo man Kriterien auswählen und denen einen Minimum- und Maximum-Wert zuordnen, so wie die Tools auf den Websites des Hersteller. Doch das Ganze müsste dann herstellerübergreifend sein... (Wunschdenken). Severino
Zwei klare Vorteile von den PIC'S: 1) Vieeel bessere Dokumentation (Datasheets) 2) für low power Anwendungen mehr Möglichkeiten und deutlich weniger Stromverbrauch. Grüße Arno M.
Klare Argumente: - Es gibt keinen Freeware C-Compiler für PICs. - MPLAB ist dem AVR Studio unterlegen (maximal 64 Zeichen für die Verzeichnis/Dateinamen, es gab Versionen die Windows zerstört haben, die Anordnung der einzelnen Fenster durcheinander finde ich lässtig, usw.) - AVRs haben 32 Arbeitsregister, PICs nur 1. Bei geschickter Programmierung kann das ein ordentlicher Gewschwindigkeitsvorteil bringen kann. Dafür muss man bei AVRs erst alle Variablen in die Register laden. Meiner Erfahrung nach, sind AVRs entweder bei sehr einfachen Programmen wo man alle Variablen in den Registern lassen kann etwa schneller als PICs bei gleichen MIPS, ebenso bei komplizierten Operationen mit 16 oder 32Bit. Hier erspart man sich beim AVR das ständige Laden der Werte aus den File Registern. - AVRs haben einen durchgehenden Speicherbereich, kein Banking. Das ist nur eine Fehlerquelle und ist lästig. Die PIC Datenblätter der PICs halte ich für eine Katastrophe, wenn man mal was sucht. Teilweise sind die ziemlich chaotisch organisiert.
@Severino: > Heee! > Hier ging es um PIC und AVR! > Bitte, ARM7- und ARM9-Fans, und Fans von Exoten, eröffnet doch einen > eigenen Thread für Euch. Der OP hat in seinem Posting weder im Betreff noch im Text an irgendeiner Stelle den Begriff "AVR" erwähnt! Da steht nur was von ATMEL, und die bauen auch ARMs...
Benedikt K. wrote: > Klare Argumente: > - Es gibt keinen Freeware C-Compiler für PICs. Ist das erforderlich? Willst Du am Compiler herumentwickeln? > - MPLAB ist dem AVR Studio unterlegen (maximal 64 Zeichen für die > Verzeichnis/Dateinamen, es gab Versionen die Windows zerstört haben, die Nimm doch einfach die aktuelle statt einer früheren Version. > Anordnung der einzelnen Fenster durcheinander finde ich lässtig, usw.) Kannst Die Fenster ja anordnen wie Du willst. > - AVRs haben 32 Arbeitsregister, PICs nur 1. Bei geschickter > Programmierung kann das ein ordentlicher Gewschwindigkeitsvorteil > bringen kann. Dafür muss man bei AVRs erst alle Variablen in die > Register laden. Meiner Erfahrung nach, sind AVRs entweder bei sehr > einfachen Programmen wo man alle Variablen in den Registern lassen kann > etwa schneller als PICs bei gleichen MIPS, ebenso bei komplizierten > Operationen mit 16 oder 32Bit. Hier erspart man sich beim AVR das > ständige Laden der Werte aus den File Registern. Stimmt! > - AVRs haben einen durchgehenden Speicherbereich, kein Banking. Das ist > nur eine Fehlerquelle und ist lästig. Stimmt! Mit der Zeit weiss man's aber. Und dem C-Programmierer ist es eh egal. Und jetzt noch das: > Die PIC Datenblätter der PICs halte ich für eine Katastrophe, wenn man > mal was sucht. Teilweise sind die ziemlich chaotisch organisiert. Arno M. wrote: > Zwei klare Vorteile von den PIC'S: > 1) Vieeel bessere Dokumentation (Datasheets) Was jetzt? Hier geht es wohl um persönliche Vorlieben. Severino
Entschuldigung für folgende Destruktivität... ...aber ich werd mir jetzt doch einen Formel-1-Boliden kaufen statt einem VW Golf, weil Golf Sch*** ist... Man kann nicht so adhoc sagen welchen Controller man nehmen soll, einfach ausprobieren. Was einem liegt soll man nehmen. Die Entscheidung ist sowieso immer subjektiv und nur weil jemand aus diesem Forum meint AVR ist besser geeignet um irgendwelche LEDs zu schalten heißt dass noch lange nicht, dass der auch geeignet ist um Video Streaming zu realisieren. Also weg von diesem Schwachsinn PIC und AVR zu vergleichen. Betrachtet eure Anforderungen und dann sucht nach dem Controller der das schafft. Da irgendwelche Thesen und Meinungen bezüglich eines Typs kundzutun ist ja absolut wertlos. Die Energie die ihr dabei verbratet müßt ihr beim Abendessen wieder tanken, das kostet Geld, sicher mehr als 2€... damit könnte man einen AVR kaufen ggg Diese Diskussion wird nie ein Ende finden... Weshalb mit jemanden diskutieren der auf BLAU steht, wenn ich selbst überzeugter GELB Fetischist bin...
@ johnny.m Der OP hat anschliessend präzisiert: > Ich bezog mich jetzt auf die typischen Bastel-µCs mit FLashspeicher in > der 2-Euro-Klasse. Wo gibt's ARMs von ATMEL für 2 Euro?
Severino R. wrote: > Wo gibt's ARMs von ATMEL für 2 Euro? Hier gibts ARMs für 0 Cent ;-) http://www.atmel.com/forms/Samples.asp?family_id=605
@ Thomas P. Also, der Formel-1-Bolide wäre in ROT auch sehr schön, oder neuerdings doch eher SILBER? Hast aber im Prinzip recht. Wie oben schön zu sehen ist, werden immer "weiche" Kriterien angeführt, wo man ja geteilter Meinung sein kann. Das mit dem Banking / Paging bei den meisten PICs ist aber wirklich nicht so toll, das muss ich als Microchip-Kunde wirklich sagen. > Hier gibts ARMs für 0 Cent ;-) So, dann bestell mir doch bitte mal ein paar Hundert davon. Severino
Naja das Banking ist mir in der Hinsicht egal, weil das erledigt eh mein Compiler... Ich verwende auch PIC. Der Grund ist einfach der, weil die damals, liegt schon einige Jährchen zurück, für MICH (subjektiv) bessere Entwicklungsumgebungen und ausgereiftere Peripherie zur Verfügung gestellt haben und ich außerdem die Controller haufenweise geschenkt bekommen habe... Würde ich jetzt neu einsteigen, würd ich weder PIC noch AVR nehmen sondern direkt nach ARM greifen. Aber wie gehabt, alles eine Gefühlsentscheidung... Bei den meisten Projekten werden die Controller ohnehin überdimensioniert, da brauch ich nicht wegen ein paar einzelnen MIPS heulen.
Severino R. wrote:
> So, dann bestell mir doch bitte mal ein paar Hundert davon.
Willst dir damit den Fussboden pflastern? g
@Severino: > Wo gibt's ARMs von ATMEL für 2 Euro? Ist ein Argument... es ging mir aber eher darum, dass ich durchaus verstehen kann, dass bei einer solchen Fragestellung logischerweise Antworten aus dem Bereich kommen. Man fragt ja auch nicht "Was ist besser, ATMEL oder Philips?", gelle? Bei der Dokumentation denke ich auch, dass das durchaus mit persönlichen Vorlieben zu tun hat. Ich persönlich finde die Datenblätter und sonstige Dokumentation von ATMEL im Prinzip sehr gut (ausführliche Beschreibung, übersichtlicher Aufbau), mit einigen Abstrichen was bestimmte kleine aber feine Fallen angeht, deren Beschreibung irgendwo versteckt ist, wo man sie nicht auf Anhieb vermuten würde (z.B. die berühmte M103C-Fuse bei den ATMega103-Derivaten, die anderen Anschlüsse für die ISP bei eben diesen Bausteinen und noch ein paar andere Kleinigkeiten, nach denen man sich beim ersten Mal den Wolf sucht). PIC-Datenblätter kenne ich allerdings nur vom "mal reinschauen", da ich nicht mit PICs arbeite, hatte jedoch von dem was ich gesehen habe zumindest auf den ersten Blick keinen großartig negativen Eindruck (Auch was den oben mal kritisierten Aufbau angeht). Ich denke, es hängt im Wesentlichen davon ab, mit welchem System man angefangen hat. Irgendwann kennt man die Eigenheiten "seiner" Controller und speziell der Dokumentation. Und das ist weitgehend unabhängig vom Hersteller. Richtig "schlechte" Datenblätter kann sich ein namhafter Hersteller auf Dauer nicht leisten... Beim Umstieg auf einen anderen Hersteller muss man sich dann eben mit dessen Datenblatt-"Philosophie" anfreunden.
Thomas P. wrote: > Severino R. wrote: > > >> So, dann bestell mir doch bitte mal ein paar Hundert davon. > > > > Willst dir damit den Fussboden pflastern? *g* Nein, aber wenn wir von Preisen sprechen, dann sollen es normale Handelspreise sein, auch in beliebigen Mengen, und keine einzelne Gelegenheiten, die nicht beliebig wiederholbar sind wie: Samples, Geschenk, Ausschlachen aus altem Gerät, Diebstahl, "ohnehin rumliegen haben". Ein Preisvergleich von Samples ist ja nicht möglich, und ein Teil, das nicht als Sample erhältlich ist, kosten sonst ja unendlich Prozent mehr als ein Sample! Severino
johnny.m wrote: > es ging mir aber eher darum, dass ich durchaus verstehen kann, dass bei > einer solchen Fragestellung logischerweise Antworten aus dem Bereich > kommen. Man fragt ja auch nicht "Was ist besser, ATMEL oder Philips?", > gelle? Anscheinend ist es verbreitet, ATMEL als Synonym für AVR zu verwenden, da die anderen Controller von ATMEL ('51 und ARM) ja eben nicht ATMEL-typisch sind, sondern Cores verwenden, die auch bei anderen Herstellern eingesetzt werden. Bei einigen Kriterien ist aber die Frage nach ATMEL als Hersteller berechtigt (oder bei Microchip für die PICs): Firmenpolitik, ökologische und ethische Aspekte, Herkunftsland. Diese haben nichts mit der Architektur zu tun. Ansonsten bin ich betr. Dokumentation mit Dir einverstanden. Severino
Also seit es von Atmel den AVR-Dragon gibt, hab ich ein absolutes Totschlagargument für Atmels. Jeder der mal eine ganze Weile einen Fehler gesucht hat und bisher nur von Debugtools (z.B. JTAG-ICE) träumen durfte, hat jetzt die Möglichkeit relativ günstig an sowas ranzukommen. Vergleichen wir mal( allgemein - Tools ): PIC: ---- ISP-Programmer: (gibts wie Sand am mehr für ca. 10-20 Euro - Eigenbau) Debug-ICD2 von Microchip: ca. 300-400 Euro Nachbau ICD2: ca. 30 Euro (nur RS232 und SEHR langsam. Meiner Meinung nach zu langsam für vernünftiges Arbeiten. (Es gibt zwar einen Nachbau mit USB-Chip, dieser Chip ist allerdings abgekündigt und nicht mehr allzu leicht zu bekommen! kostet ca. 20 Euro) Der Picstart Plus - hier nicht weiter aufgeführt, weil schon durch ISP Programmer oben "ausgestochen vom Preis her) Atmel: ------ ISP-Programmer wie bei PIC (gleiche Preisklasse - Eigenbau) Debug-Tools: ca. 200-250 Euro JTAG-ICE MK2 (sehr schönes Gerät ;) ) Nachbau Evertool (alter JTAG ICE) ca. 30 Euro (Lochraster ;) ) (kann kein Debug-Wire, dafür kann er alle "klassischen AVRs mit JTAG ohne Begrenzung (siehe Dragon) debuggen und Flashen(JTAG)) AVR-Dragon: ca. 60 Euro (JTAG, Debug-Wire, HighVoltage parallel Prog.) meiner Meinung nach unschlagbares Preis-Leistungs-Verhältnis, aber kann keine Devices mit mehr als 32k Flash Debuggen (ok, Atmel möchte ja auch noch die teuereren JTAG-ICE MK2 verkaufen ;) ) Für Hobbyzwecke und "kleine Projekte" absolut unschlagbar. Ach ja, wer sich mal einen Ausflug zur "Embedded World" leisten will; dort wurden die Teile letztes Mal verlost. Hab auch einen abgestaubt ;) Es gibt wohl kaum jemand, der schonmal mit Debug-Tools gearbeitet hat, der hier sagen würde, dass es auch ohne Debug-Tool zeiteffiziente Fehlersuche gibt. (gut, hängt von der Art der Fehler ab die man macht ;) ) Aber jedes Mal zusätzlichen Code für Fehlersuche einbauen ist auch aufwändig und Zeitraubend, wenn man es viel einfacher mit nem Debug-Tool geht. Davon abgesehen, sind die Teile die USB beherrschen ziemlich schnell was Programmierung und Debug betrifft. Eine allgemeine Aussage noch: ----------------------------- Einer meiner Profs hier an der Hooschule hat mal gesagt, dass einem jeder Mikrocontroller spätestens nach 2-3 Wochen Einarbeitung "aus der Hand fressen" sollte. Vorausgesetzt man kennt sich mit den Mikrorechner Grundlagen aus.
Also, nochmal zusammenfassen: AVR: preisgünstig, universell, schnell, stromsparend, einfach, kostenlose Software, preisgünstige Programmier- und Debughardware und ein unschlagbares Angebot von sehr hilfreichen Application Notes vom Hersteller selbst Die Summe der Vorteile machts. Für alle anderen Controller sprechen in bestimmten Fällen vielleicht besondere Gründe, zb in der viel zitierten Industrie wo ein 5 Cent billigerer PIC genommen wird, ein ARM wenn Rechenleistung und/oder Speicher nicht mehr ausreicht oder ein spezielles Feature wie MP3 oder DSP. Aber ich habe bisher noch nichts davon gebraucht. Aber im Hobbybereich ist die Kombination der Vorteile ein erschlagendes Argument für die AVR. Oder für welchen Controller bekommt man ein komplettes Entwickungspaket mit C-Compiler, IDE, In System Programmer/Debugger usw für <100€ (selbstbastelkram mal weggelassen)?
Für den PIC ! PICKIT2 koste ca. 50 €, MPLAB und C-Compiler (Student Edition) für die interresanteren PIC's (18) giebt es dazu, und debuggen kann das Ding auch schon (noch nicht viele, aber mit jeder neuen MPLAB Version werden es mehr). Einen ICD2 Clone ohne spezial Chips giebt's auch. Ein PIC 16F877 und ein 18F4550 und ein wenig Kleinkram aus der Bastelkiste reichen. MFG
Ich habe schon viel mit beiden Controllerfamilien gearbeitet und finde beide gut! So! :) PS: Den C18 Compiler gibts umsonst - solange man den nur Privat verwendet und in Firmen sind die paar Euro eh nicht so wichtig (die würden für den AVR dann sowieso den IAR oder so kaufen)... Achja und AVRStudio stürzt ständig ab und hat ein paar nervige Bugs (s. anderen Thread hier im Forum...) - MPLAB läuft hingegen stabil.
Bei mir ist AVRStudio noch nie abgestürtzt, aber ein paar nervige bugs gibts, das stimmt :> aber man lernt damit umzugehen.
> MPLAB läuft hingegen stabil.
Das hängt vom PC ab auf dem es installiert ist.
Ich kenne beides, sowohl stabiler Betrieb über mehrere Tage als auch
Abstürze mehrmals am Tag.
Aus eigener erfahrung, kommt es immer auf den Anwendungsfall und den eigenen Wünschen und Vorstellungen an. Selber nutze ich AVR, M16C, PSOC. Vom Datenblatt her gefällt mir auch PIC24H. Diesen werde ich mir demnächst samt Pickit2 gönnen und begutachten. Einzigst das flashen von 1000mal finde ich nicht zeitgemäß. Gruß Sascha
> - Es gibt keinen Freeware C-Compiler für PICs. Es gibt eine kostenlose Studentenversion, die nach 90(?) Tagen lediglich spezielle Optimierungen abschaltet, auf die man eh verzichten kann zumal man kritische Teile ohne weiteres in ASM einbinden kann. >- MPLAB ist dem AVR Studio unterlegen (maximal 64 Zeichen für die >Verzeichnis/Dateinamen, es gab Versionen die Windows zerstört haben, die >Anordnung der einzelnen Fenster durcheinander finde ich lässtig, usw.) MPLAB erinnert mich so bisschen an DOS-Zeiten. Die Oberfläche, die Darstellung der Register usw. ist nicht sonderlich gut gelungegen. Dafür hat MPLAB einen ganz entscheidenden Vorteil: es läuft stabil*. Das neue AVR Studio ist einfach nur ne Katastrophe hinsichtlich Stabilität und Startverhalten. >Die PIC Datenblätter der PICs halte ich für eine Katastrophe, wenn man >mal was sucht. Teilweise sind die ziemlich chaotisch organisiert. Bei Microchip gibt es halt ein Datenblatt sowie i. d. R. ein Family Reference Manual. Generell finde ich, dass Microchip ausgezeichnete, verständliche und ausführliche Dokus veröffentlicht. Einzig die Infos zu den dsPICs sind unter aller Sau. *) Ist meine persönliche Erfahrung.
Oh, hab gerade gesehen, dass alles schon genannt wurde; naja egal...
Schorsch wrote: >> - Es gibt keinen Freeware C-Compiler für PICs. > > Es gibt eine kostenlose Studentenversion, die nach 90(?) Tagen lediglich > spezielle Optimierungen abschaltet, auf die man eh verzichten kann zumal > man kritische Teile ohne weiteres in ASM einbinden kann. Das ist kein gutes Argument: Dem Argument nach, kann man die Software gleich in Assembler schreiben... Außerdem werden alle Optimierungen abgeschaltet, wenn ich mich noch richtig erinnere. > Einzig die Infos zu > den dsPICs sind unter aller Sau. Eindeutig. Aber auch da bessern die sich langsam. Eigentlich ist bei den dsPICs so ziemlich alles unter aller Sau: Dieser "Visual Initializer" hat bei mir noch nie einen funktionierenden Code generiert. Die Errata sheets sind ziemlich lang und unvollständig. Die mitgelieferten dsPIC Libs sollen angeblich teilweise fehlerhaft sein. Der Compiler für die dsPIcs ist eigentlich nur ein normaler C Compiler und nutzt keine einzige DSP Funktion. Mein erstes Assembler Programm auf einem dsPIC war direkt doppelt so schnell wie der vom Compiler generierte Code.
Benedikt K. wrote: > Das ist kein gutes Argument: Dem Argument nach, kann man die Software > gleich in Assembler schreiben... Außerdem werden alle Optimierungen > abgeschaltet, wenn ich mich noch richtig erinnere. Du erinnerst Dich falsch... Einzig die Procedural Abstractions werden in der Student Edition nach Ablauf der 60 (?) Tage abgeschaltet. > Mein erstes Assembler Programm auf einem dsPIC war > direkt doppelt so schnell wie der vom Compiler generierte Code. Ist es ein schlechter Compiler oder Du ein guter Assembler-Programmierer? Es ist doch absolut nicht erstaunlich, dass ein Hochsprachen-Compiler langsameren Code generiert als ein Assembler-Programmierer. (Falls man C zu den Hochsprachen zählen will ;-) Severino
> Ist es ein schlechter Compiler oder Du ein guter > Assembler-Programmierer? > Es ist doch absolut nicht erstaunlich, dass ein Hochsprachen-Compiler > langsameren Code generiert als ein Assembler-Programmierer. (Falls man C > zu den Hochsprachen zählen will ;-) ...und weils so ist, braucht man keine Diskussion führen welcher Controller schneller ist. Wenn der Compiler schlecht ist, kann man 3x so viele MIPS haben und es bringt trotzdem nichts... Gibts eigentlich schon PICs mit JTAG? JTAG wäre schon ein schönes Feature.
JTAG ist ja auch nicht nur zum Programmieren da... folglich hat das auch rein gar nichts mit fachlicher Kompetenz zu tun, die dir offenbar fehlt, sonst würdest du nicht zu so einer Aussage kommen.
@ Thomas P. Nein, gibt es noch nicht. Es ist wohl vorgesehen, aber aktuell gibt es keinen bei dem es funktioniert.
Von der Peripherie und Scalierbarkeit sind die AVRs klasse. EMV-mässig sind die wegen der 5V-Technik sehr solide. Leider ist der Stromverbrauch bei AVR bescheiden.... aus dem Grund fällt bei mir die Wahl nur noch auf MSP...2-6uA sind schon nett...
mal eine frage was braucht ein MSP340 an strom wenn er rechnet und nicht in einem energiespar-modus ist?
kann ur für einige typen die ich kenne sprechen, das sind 600uA bei ca. 2MHz..Aber der interne DCO läuft nur kurz an, den großteil seiner Zeit schläft der Msp und wartet auf ein Int..... Das Prinzip ist kurz mit hoher Taktfrequenz was amchen, udn sonst schlafen...in der Summe kommt man da auf einen super schönen Verbrauch..
Also wenn ich einen PIC schlafen schicke, braucht er auch fast nix... MSP ist dennoch sicher die bessere Wahl wenn man batteriebetriebene Projekte realisiert und wenn man kaum Rechenleistung braucht, denn soviel ich weiß sind maximal 8MHz drinnen. Meinen Webserver oder MP3 Player hätte ich mich damit nicht realisieren getraut.
Die sind bnis 16MHz spect....meine der DCO kann mit einem externen Widerstand auch bis auf 16Mhz....
Also ich hab da noch ne Anmerkung zu den Entwicklungstools für PIC Controller: Der Debugger von PICKIT ist begrenzt. Un zwar heftiger als der AVR Dragon. Man kann damit nur ne Handvoll Controller Debuggen. Programmieren kann man wohl alle. Es gibt aber für den ICD2 inzwischen eine USB-taugliche Nachbauversion für knapp 70 Euro. Hab auch ein Gerücht gehört, dass die Teile auch im Original für ca. 120 Euro zu haben sein sollen. Hier die Bezugsquelle: http://www.wselektronik.at/WS/index.php?option=com_content&task=view&id=17&I Mit den 70 Euro liegt das Teil zwar noch über dem Dragon und ist "nur" ein Haufen Einzelteile, aber für die PIC-Enthusiasten wohl das Mittel der Wahl, wenn man nicht >100 Euro ausgeben will. Eigentlich hab ich nix gegen PIC Controller. Leider haben die ein paar "Eigenheiten", die ich nicht gerade praktisch finde und die einem das Leben unnötig schwer machen. Zum Beispiel wenn ein Controller auf einen Bereich 3V-5V spezifiziert wird aber zum "sauberen" Programmieren mindestens 4,5V benötigt werden! Da bin ich bei einem Projekt ganz schön auf die Nase gefallen. Auch das Fehlen einer vernünftigen indirekten Adressierung ist nicht gerade Programmierer-freundlich (PIC16xxx). Mit PIC 18 hab ich mich noch nicht befasst. Aber jeder hat so seine Präferenzen. Wer mit dem einen oder dem anderen angefangen hat, wird wahrscheinlich aus Gewohnheitsgründen nicht gerne wechseln. Ich hab geschäftlich mit PIC16xx und AVRs zu tun und muss mich damit abfinden, dass der PIC eben ein paar Eigenarten hat. Wenn man in C programmiert, dann ist das allgemein nicht ganz so tragisch. Ich persönlich würde mir >>nie<< freiwillig PIC-Assembler antun! Zumindest nicht bei der 16er Serie oder den kleineren PICs.
Also ich habe auch nichts gegen PICs, denn ich verwende keine. :-) Ich verwende AVRs, da ich mich aber auch für andere Kontroller interessiere, wäre ich schon einige Male dabeigewesen, mich in die PIC-Welt einzuarbeiten. Zwei Anläufe hat es gedauert und dann habe ich es aufgegeben. Nicht deshalb, weil ich zu blöd wäre, sondern weil ich die PICs blöd finde. Zum einen gibt es bei den PICs so viele verschiedene Familien, die alle nicht zusammenpassen. Ein C-Compiler funktioniert wieder nur für eine kleine winzige Anzahl von PICs und nicht für alle. Wenn man die gesamte Familie ausnützen würde, bräuchte man wahrscheinlich 5 verschiedene C-Compiler. Dann die Quarz-Division durch 4 gefällt mir nicht. Dann gibt es nicht für jeden IRQ einen eigenen Vektor. Angeblich ist das bei neueren PICs behoben (Wenn man Glück hat.). Mir kommt die PIC-Philosophie folgendermaßen vor: "Konstruieren wir mal einen Mikrocontroller. Diese Entwicklung hat zwar jetzt eine Menge Nachteile, aber bei der nächsten Familie können wir uns verbessern. Diese ist dann zwar wieder völlig anders als die erste, aber bei dem Durcheinander wird sich dann schon mal irgendjemand auskennen." Also mir scheinen die AVR-Entwickler sehr viel mehr nachgedacht zu haben. Ich habe einen Compiler, den Codevision AVR und mit dem kann ich alle AVRs programmieren. Alle AVRs funktionieren nach einem gleichen Schema. Die neueren Prozessoren haben zwar Verbesserungen gegenüber den älteren Modellen, aber die Grundstruktur ist gleich. (Bei der einen PIC-Familie ist ein Befehlssatz mal 12-BIT breit bei der anderen wieder anders.). Es stimmt zwar, dass es immer auf die Anwendung ankommt, welchen Typen man nimmt, aber ich habe das Gefühl, wie wenn ein AVR immer die bessere Wahl wäre als ein PIC. Und dann kommen immer so total nette Argumente von den PIC-Anhängern wie z.B. Die Fuse-Bits eines AVRs würden mich verwirren. Oder: Ich brauche keinen internen Oszillator auf einem Prozessor. .. Die Liste dieser Pseudoargumente ist unendlich lang und tatsächlich ist kein Argument wirklich überzeugend und jedes durch ein Gegenargument sofort entkräftbar. Es ist natürlich klar, dass wenn man mal eine Familie wie z.B. PIC gewöhnt ist, man dort weiterarbeiten möchte, aber ich finde es dann immer einwenig schwach, wenn dann PIC-Anhänger meinen, dass PICs besser sind. Also ich habe die Erfahrung gemacht, dass wenn sich einer in der PIC-Familie und in der AVR-Atmel-Familie auskennt, die AVR-Familie nicht nur bevorzugt, sondern nur noch diese verwendet. Tschüss Mario
Mario wrote: > Also ich habe auch nichts gegen PICs, denn ich verwende keine. :-) > > Ich verwende AVRs, da ich mich aber auch für andere Kontroller > interessiere, wäre ich schon einige Male dabeigewesen, mich in die > PIC-Welt einzuarbeiten. > Zwei Anläufe hat es gedauert und dann habe ich es aufgegeben. Nicht > deshalb, weil ich zu blöd wäre, sondern weil ich die PICs blöd finde. > ???? > Zum einen gibt es bei den PICs so viele verschiedene Familien, die alle > nicht zusammenpassen. Das würd ich so nicht behaupten, aber es sind eben verschiedene Familien und in jeder Familie gibt es Derivate und die sind bis zu einem gewissen Grad schon ähnlich/kompatibel. Passen alle AVRs zusammen? Blöd, weil dann braucht man sich ja eh immer nur ein und denselben kaufen ;-) > Ein C-Compiler funktioniert wieder nur für eine > kleine winzige Anzahl von PICs und nicht für alle. Wenn man die gesamte > Familie ausnützen würde, bräuchte man wahrscheinlich 5 verschiedene > C-Compiler. Verwende CCS Compiler und du kannst damit sowohl PIC16, PIC18 und dspPIC programmieren bzw. debuggen, also sogar Familien-übergreifend!!!! > Dann die Quarz-Division durch 4 gefällt mir nicht. Mir gefällt blau nicht, aber das hatte ich weiter oben schon erwähnt... > Dann gibt es nicht für jeden IRQ einen eigenen Vektor. Angeblich ist das > bei neueren PICs behoben (Wenn man Glück hat.). Na sicher gibts das. Wo soll es das nicht geben?? > Mir kommt die PIC-Philosophie folgendermaßen vor: "Konstruieren wir mal > einen Mikrocontroller. Diese Entwicklung hat zwar jetzt eine Menge > Nachteile, aber bei der nächsten Familie können wir uns verbessern. > Diese ist dann zwar wieder völlig anders als die erste, aber bei dem > Durcheinander wird sich dann schon mal irgendjemand auskennen." > > Also mir scheinen die AVR-Entwickler sehr viel mehr nachgedacht zu > haben. Ich habe einen Compiler, den Codevision AVR und mit dem kann ich > alle AVRs programmieren. Alle AVRs funktionieren nach einem gleichen > Schema. Die neueren Prozessoren haben zwar Verbesserungen gegenüber den > älteren Modellen, aber die Grundstruktur ist gleich. (Bei der einen > PIC-Familie ist ein Befehlssatz mal 12-BIT breit bei der anderen wieder > anders.). Und noch einmal, Familien dürfen unterschiedlich sein!!!!!!! Deswegen sind es auch verschiedene Familien... ist das so kompliziert?!?! > > Es stimmt zwar, dass es immer auf die Anwendung ankommt, welchen Typen > man nimmt, aber ich habe das Gefühl, wie wenn ein AVR immer die bessere > Wahl wäre als ein PIC. Wenn der PIC Gefühle hätte, wäre er jetzt sicher traurig... > > Und dann kommen immer so total nette Argumente von den PIC-Anhängern wie > z.B. Die Fuse-Bits eines AVRs würden mich verwirren. > Oder: Ich brauche keinen internen Oszillator auf einem Prozessor. > .. PIC hat auch FUSE-Bits, sofern wir jetzt vom gleichen sprechen. > Die Liste dieser Pseudoargumente ist unendlich lang und tatsächlich ist > kein Argument wirklich überzeugend und jedes durch ein Gegenargument > sofort entkräftbar. Achso? Bitte fang an... Gibts AVRs mit externem Speicherinterface, mit integriertem Ethernet, 16Bit???? > Es ist natürlich klar, dass wenn man mal eine Familie wie z.B. PIC > gewöhnt ist, man dort weiterarbeiten möchte, aber ich finde es dann > immer einwenig schwach, wenn dann PIC-Anhänger meinen, dass PICs besser > sind. > > Also ich habe die Erfahrung gemacht, dass wenn sich einer in der > PIC-Familie und in der AVR-Atmel-Familie auskennt, die AVR-Familie nicht > nur bevorzugt, sondern nur noch diese verwendet. > Ich hab die Erfahrung gemacht, dass solche Threads schlussendlich alle wertlos sind. Also mein Ratschlag: Nehmt PIC wenn ihr PIC wollt und nehmt AVR wenn ihr AVR wollt. Wenn PIC so scheiße ist, warum sind die dann so gut am Markt vertreten? Sicher nicht wegen den Kosten, weil bei 1000 Stück sind kaum noch Unterschiede. Nur noch eines... mir gefallen PICs einfach viiíeeeellll besser... das Gehäuse ist schwärzer und glatter als bei den AVRs... Ist das ein schlagkräftiges Argument??? loool
@ Thomas: --------- >Gibts AVRs mit externem Speicherinterface, mit SRAM oder DRAM? SRAM bis 64k kein Problem. Man kann an die Schnittstelle auch andere Peripherie dranhängen. Z.b. ein USB Controller mit parallelem Interface. >integriertem Ethernet, 16Bit???? Ethernet? Nein. Leider net. 16bit? -> Es gibt AVR32 mit 32bit. <Ironie> Was Ethernet betrifft, kann man ja auch nen AVR mit nem ENCxxxx von Microchip verbinden. Dann hat man auch Ethernet ;-) </Ironie>
Mein ARM ist größer, mein 8051 ist länger, PIC ist doof und AVR kann nix <- Nicht ernstgemeint, aber was bringt dieses Schw*nzvergleichen eigentlich. Was ist das für ein Argument "Ich finde PICs blöd?" Mein Gott, generell ist kein µC wirklich "schlecht" und ein µC muss nicht alles können sondern hat immer eine Nische. Sonst hätte wahrscheinlich bald jeder Hersteller alles in einem BGA4000 Gehäuse was man ja evtl. irgendwann mal brauchen könnte. Sagt doch lieber mal konkret "Das ist beim AVR nicht gut gelöst" "Das gefällt mir beim PIC gut/schlecht". Vorteile/Nachteile .. kein "blöd, doof, mag ich nicht, schönes Wetter"
der einzige grund einen avr zu bevorzugen ist der gcc-support... zumindest wars meiner und solang es keinen gcc für die pic dinger gibt werd ich sie auch nicht angreifen... sonst gilt das übliche.. man nimmt was grad gut passt... 73
Ja AVR32 kenn ich, aber das ist eine andere Liga. Für die Bastlerstube hat der eindeutig das falsche Gehäuse... und zu viele Pins zum Routen g Static Memory Controller, wie z.B. für Flash oder SRAM wäre gefragt um Programmspeicher bis zu 2MByte zur Verfügung zu haben. ENC28J60 zu verwenden zählt nicht :-)
> Wenn PIC so scheiße ist, warum sind die dann so gut am Markt
vertreten?
Leider hat sich in der Vergangenheit gezeigt, dass sich nicht immer das
beste System durchsetzt, sondern immer nur jenes, welches am besten
vermarktet wird.
Beispiel VHS und Video 2000
Windows und Linux
In der Steinzeit:
1,44MB-Floppies und 2,88MB-Floppies
Tschüss
Markus
PS: Nehmt doch was ihr wollt.
> Ich persönlich würde mir >>nie<< freiwillig PIC-Assembler antun! Warum nicht? Damit kann man aus jedem PIC das maximale herausholen und kann auch mit dem 12C508 sinnvolle Applikationen entwickeln. Durch die Verwendung von Hochsprachen ist das nicht zu schaffen. Es gibt eine bessere Auswahl an PICs in extrem vielen Kombinationen, man findet fast immer genau den PIC der ideal ist. C oder gar BASIC ("BASCOM AVR", etc) auf einem 8-Bit MCU? Nein danke!
Nichts gegen Assembler, ich mache das mal so mal so. Nur finde ich die Assemblersprachen der PICs sehr gewöhnungsbedürftig. In meisten Assemblersprachen gibt die Syntax der Operanden schon einen gewissen Hinweis darauf, wo Quell- und wo Zieloperand liegen. Nicht so die PICs, in denen eine harmlose 0 oder 1 hinten dran angibt, ob das Ergebnis im Speicher oder im Akku landet. Natürlich gibt es auch andere abstossende Beispiele. Zilog beispielsweise hat ziemliche Klimmzüge gemacht, damit die Z80 auch ja keine optische Ähnlichkeit mit 8080 hat (Copyright?). Weshalb alle Zilog-CPUs mit dem Ladebefehl auch speichern, aus Gewohnheit auch jene bei denen das nie nötig gewesen wäre (Z8).
>Nur finde ich die Assemblersprachen der PICs sehr gewöhnungsbedürftig. Stimmt. Der Mensch ist aber zum Glück kein enthirntes Wesen sondern kann sich an bestimmte Situationen anpassen und eben gewöhnen. >In meisten Assemblersprachen gibt die Syntax der Operanden schon einen >gewissen Hinweis darauf, wo Quell- und wo Zieloperand liegen. >Nicht so die PICs, in denen eine harmlose 0 oder 1 hinten dran angibt, >ob das Ergebnis im Speicher oder im Akku landet. Gerade das ist doch positiv. Mir ist das so lieber, als noch einen zusätzlichen Befehl zu haben. >C oder gar BASIC ("BASCOM AVR", etc) auf einem 8-Bit MCU? Nein danke! Bei BASIC stimme ich dir zu, aber ein 8-Bit µC ohne C? Möchte dich mal sehen, wenn du die Aufgabe bekommst, einen TCP/IP-Stack auf einem 8-Bitter zu implementieren und du das unbedingt in ASM machen willst. Ich will nicht bestreiten, dass es grundsätzlich geht. Du kannst auch eine Textverarbeitung für Windows XP in ASM schreiben. Allerdings läufst du dann Gefahr, dass dich jemand in die Anstalt einliefert.
A.K. wrote: > Assemblersprachen gibt die Syntax der Operanden schon einen gewissen > Hinweis darauf, wo Quell- und wo Zieloperand liegen. Nicht so die PICs, > in denen eine harmlose 0 oder 1 hinten dran angibt, ob das Ergebnis im > Speicher oder im Akku landet. Das ist so nicht ganz richtig, unter MPASM steht f für file-register und w für working-register. Dabei kann f=1 oder w=0 als Operand gegeben werden. Reicht um einen Rückschluss auf Quelle und Ziel ziehen zu können. Gruss, Edson
Also ich verwende PIC un bin damit zufrieden. Ich wurde dazu genötigt mich mit PICs zu beschäftigen da diese in der Abschlussprüfun vorkommen. Ob ich PIC oder AVR genommen hätte wenn ich mich frei entscheiden hätte können weiß ich nicht, da ich mich mit AVR noch nicht näher beschäftigt habe. Gruß Carsten
ich glaube, bezüglich preis/leistung gibts hier nicht zu motzen: http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=2018&mcparam=en530724 ...ich bleibe bei den PICs, denn mit denen habe ich mich gut angefreundet, und kenne ich mittlerweile recht gut und bin sehr zufrieden. ich finde, man soll einfach bei einer sorte bleiben (ARM, Atmel, Microchip...), wenn man nicht (z.b. aus beruflichen gründen) drauf angewiesen ist, die vierschiednen "marken" zu gebrauchen
Ich bin für beides. Wie viele weiter oben geschrieben haben ist das total egal. Aktuell kommt es mir aber so vor als ob Reichelt die Atmel Preiße anzieht. (weil ein ehemals 95 ct teurer Chip heute auf einmal 160 ct kostet) Die PIC haben für den selben Preiß mehr Programmspeicher aber dafür kein EEPROM. Beispiel (Preiße laut Reichelt): ATMEGA 8-16 (DIL-28) max. 16MHz und 23 IO Ports 8kB Flash, 512B EEPROM, 1kB RAM -> 2.60€ PIC 16F648A-I/P max.20MHz und 16 IO Ports 4kx14 Flash, 256B EEPROM, 256B RAM dafür USART -> 2.30€ Also ich denke das man das in vielerlei Hinsicht interpretieren kann. Ich habe mit atmel angefangen und würde mich auch nicht vor PIC scheuen ... es ist nur eben was anderes
Hi Warum gräbst du eine 4 Jahre alte Leiche aus? Außerdem kann man jemand, der Preis mit 'ß' schreibt nicht ernst nehmen. MfG Spess
Mir ist neulich aufgefallen, daß bestimmte ATMEL µC (z.B. der 164 oder 328) keinerlei Spezifikationen über maximale ADC-Fehler in den Datenblättern enthalten. Was soll man davon halten??
Hi >Mir ist neulich aufgefallen, daß bestimmte ATMEL µC (z.B. der 164 oder >328) keinerlei Spezifikationen über maximale ADC-Fehler in den >Datenblättern enthalten. Was soll man davon halten?? Das du keine Datenblätter lesen kannst. In den Datenblättern unter: Electrical Characteristics->ADC Characteristics zu finden. Auch bei den von dir genannten Typen. MfG Spess
Angehängte Dateien:
-
atm164_adc_specs.PNG
21 KB
>In den Datenblättern unter: > >Electrical Characteristics->ADC Characteristics > >zu finden. So, und wo??
Ähm... Wie wär's mit "Absolute accuracy"? Gruß Jonathan
>Ähm... Wie wär's mit "Absolute accuracy"?
Faßt alle vier anderen Fehlerarten zusammen, ist aber nur typisch
spezifiziert, nicht maximal!
In den "Notes" findet sich übrigens noch das nette Sprüchlein "Values
are guidelines only", können also jederzeit beliebig unter- bzw.
überschritten werden...
Kann man den Thread vieleicht mal sperren? Das hat mit dem "blödsinnigen" Thema nichts zu tun. Unterhaltet euch doch per E-Mail.
Ina schrieb: > In den "Notes" findet sich übrigens noch das nette Sprüchlein "Values > are guidelines only", können also jederzeit beliebig unter- bzw. > überschritten werden... Das steht bei den anderen Typen aber auch drin. Bei denen mit "max". Dieser innere Widerspruch ist Atmel wohl mittlerweile aufgefallen und "max" musste weichen.
spess53 schrieb: > Hi > > Warum gräbst du eine 4 Jahre alte Leiche aus? > Außerdem kann man jemand, der Preis mit 'ß' schreibt nicht ernst nehmen. > > MfG Spess Jau, und dann noch den Vergleich mit dem wohl ältesten Bausteinen die überhaupt im Katalog zu finden waren zu ziehen... Die Pic16F84 waren vor 10 Jahren schon als Auslaufend gekennzeichnet und werden heute nur noch in kleiner Stückzahl eigendlich für Altdesigns hergestellt... Zudem: tanolino schrieb: > Die PIC haben für den selben Preiß mehr Programmspeicher aber dafür kein > EEPROM. > Ähh... PIC und keinen EEPROM? Bei diesem deinen Vergleich? > ...PIC16F84 > 4kx14 Flash, ***256B EEPROM***, > dafür USART Nicht jeder PIC hat EEPROM, aber gerade der 16F84, (bzw. der C84 wie er vor der Überarbeitung hieß...) hatte schon EEPROM da war von ATMEGA8 und Co. noch nicht mal die Rede! Aber wenn wir schon willkürlich vergleichen wollen: Dein Beispiel AVR: ATMEGA 8-16 (DIL-28) max. 16MHz und 23 IO Ports 8kB Flash, 512B EEPROM, 1kB RAM -> 2.60€ Und dann vergleiche hiermit PIC 18F14K50, DIL-20, Temperaturbereich -40 ... +125 °C, 8-bit Program Memory, 16 KBytes, Self-Write yes, RAM, 768 Byte, EEPROM 256Byte, I/O-Pins 15, 1 8-bit Timer, 3 16-bit Timer, Geschwindigkeit 48 MHz, Internal Oscillator 16 MHz, 32 kHz. Anschlüsse / Schnittstellen: 9 ADC, 1 A/E/USART (Auch USB), MSSP (SPI/I²C) Elektrische Werte: Spannungsbereich 1,8 - 5,5 V -> PREIS: 2,30 Euro (reichelt) Und wie sieht es nun aus? JA- der Vergleich hinkt auch, einfach weil der Atmega8 auch ein altes Design ist. Trotzdem liegen diese beiden Designs viel näher zusammen als dein ursprünglicher Vergleich... Mal ganz davon abgesehen das man wie schon geschrieben das so gar nicht vergleichen kann. Denn z.B. die IO Ports hängen vom Gehäuse ab das man wählt. Wer ein DIL 28 mit einem DIL 20 vergleicht, obwohl es auch dort DIL28 modelle gibt, der kann wohl nicht ernsthaft die Anzahl IOs als argument heranziehen wollen. Genauso gibt es Modelle mit größerem, aber auch ohne Eprom speicher... usw. usf! Aber einen großen Vorteil speziell für Bastler gibt es bei den PIC, der hier auch noch nicht genannt wurde: Es gibt viel viel mehr auführungen noch im DIP Gehäuse! Auch neue Modelle. Bei den AVR ist ja alles was nur ein wenig moderner ist ja nur noch in SMD zu bekommen. Für die Industrie egal, ja meist sogar gewünscht, aber für die Einsteiger... Aber trotzdem bleibt es dabei: Es gibt nicht den einen Universalcontroller. Für jede Anwendung kann es ein anderer sein. Trotzdem ist bei mir im 8Bit bereich der PIC fast immer das Mittel der Wahl... (Im 32Bit bereich halten sich ARM und PIC32 die Waage, je nach Anforderung) Gruß Carsten
>Das steht bei den anderen Typen aber auch drin. Bei denen mit "max". >Dieser innere Widerspruch ist Atmel wohl mittlerweile aufgefallen und >"max" musste weichen. Das Problem ist nur, wenn mich mein Chef fragt, wie genau denn der ADC ist, kann ich ihm keinen Maximalfehler angeben. Ich muß dann sagen: "Typisch weniger als 3LSB. Maximale Abweichung ist aber unbekannt". Kommt garnicht gut...
Bei den PICs ist es aber auch nicht viel besser: Die geben zwar Maximalwerte an, halten sich aber nicht immer dran. Im Errata steht dann manchmal, daß die Maximalwerte leider nicht eingehalten werden...
Hi Ina schrieb: >Mir ist neulich aufgefallen, daß bestimmte ATMEL µC (z.B. der 164 oder >328) keinerlei Spezifikationen über maximale ADC-Fehler in den >Datenblättern enthalten. Was soll man davon halten?? Ich habe jetzt mal ein paar Datenblätter durchgesehen (die ältesten von 2006, zum Ausgraben älterer ATMEL-CDs hatte ich keine Lust). Dort habe ich nirgends deine vermissten Angaben gefunden. Scheint also schon länger (oder immer) so zu sein. Oder hast du ein Datenblatt, in dem das drin steht. Die AVR vs. PIC Diskussionen gehen mir übrigens an der hinteren Körperöffnung vorbei. MfG Spess
>Ich habe jetzt mal ein paar Datenblätter durchgesehen (die ältesten von >2006, zum Ausgraben älterer ATMEL-CDs hatte ich keine Lust). Dort habe >ich nirgends deine vermissten Angaben gefunden. Scheint also schon >länger (oder immer) so zu sein. Oder hast du ein Datenblatt, in dem das >drin steht. Nee, ist mir erst neulich aufgefallen, als ich extra danach gesucht habe. Wir setzen bisher sowieso schnelle, externe 12bit-Wandler ein. Ich frage mich nur, welcher Profi einen ADC einsetzt, bei dem keine Maximalwerte spezifiziert werden. Die ATMEGAs zielen dabei doch keineswegs nur auf Bastler ab, oder? Die Teile sind sonst doch ganz potent und ich arbeite auch gerne mit ihnen.
spess53 schrieb: > Ich habe jetzt mal ein paar Datenblätter durchgesehen (die ältesten von > 2006, zum Ausgraben älterer ATMEL-CDs hatte ich keine Lust). Dort habe > ich nirgends deine vermissten Angaben gefunden. Im Mega16(A) Datasheet, aktuelle Version. Scheint aber wirklich der einzige zu sein wo das drinsteht.
Meiner Meinung nach ist der AVR-GCC + AVRDude ein absolutes Todschlagargument für die AVRs. Ich muss mich leider mit den PICs etwas quälen. Es ist schon hart einen PIC in C zu programmieren, wenn man den GCC gewohnt ist ;-) (Natürlich muss man auch erst einmal den richtigen Compiler für den jeweiligen PIC finden...Und bei ~300 Zeilen Code kommt dann so ein tolles "Demo limit". Da könnt ich den ganzen Scheiss einfach ausm Fenster schmeißen. Aber das Hexfile dann auf den Controller zu bekommen ist genauso ein gefrickel. 16F887/18F4550+EasyPic6+MikroCPro (so heißt das Programmiertool glaub ich, bin mir aber nicht sicher). In der Doku für MikroCPro finden sich wunderbare Beispiel zum Ansteuern über die Kommandozeile. Der Shicedreck ist aber total nutzlos wenn das in keinster Weise funzt! Diese Programm ist einfach nicht in der Lage das via Parameter übergebene Hexfile zu flashen... (bzw. mit einer Warscheinlichkeit von etwa 10%). Und wenns mal geht (oder man alles manuell macht) kommt zu 70% keine Fehlermeldung, der PIC ist aber trotzdem NICHT geflasht. Wobei ich mich frage warum das "verify" dann erfolgreich ist??) Ich werde wohl in meiner Abschlussprüfung einen AVR verwenden, und keinen PIC wie er in der Berufsschule benutzt wird... (Und das nicht unbedingt weil der PIC an sich so schlecht währe, sondern die Entwicklertools (meiner Meinung nach) einfach schlecht sind) Gruß
>(Und das nicht unbedingt weil der PIC an sich so schlecht währe, sondern >die Entwicklertools (meiner Meinung nach) einfach schlecht sind) Für Volldeppen sind die nicht gemacht. Die AVR Tools auch nicht. Viel Spass beim ersten verfusen deines AVR. Das geht bei PICs gar nicht;) Soviel mal zu besser oder schlechter. Und wenn wir schon mal bei leistungsfähiger und billiger sind: Ein Cortex M3 ist billiger und leistungsfähiger als ein AVR. Warum sollte man überhaupt noch AVR benutzen? Das ist uralter Kram der den heutigen Anforderungen überhaupt nicht mehr standhalten kann. Soviel mal zu PIC versus AVR. Stellen wir doch mal eine neue Frage: Warum AVR benutzen wenn es ARM gibt?
Na geht's noch länger? http://www.youtube.com/watch?v=I-jfS0bxW-o&feature=related Oben kam schon mal was von ARM9... So und jetzt macht mal jemand diesen ollen Thred dicht!
Hi, Simon S. schrieb: > Meiner Meinung nach ist der AVR-GCC + AVRDude ein absolutes > Todschlagargument für die AVRs. Nö... Denn GCC basierende Compiler sind auch bei PIC üblich... Zwar nicht für die kleinen 8bitter, aber die Compiler für die Leistungsfähigeren basieren auf GCC und sind sogar Open Source., nur mit dem Unterschied das der Support hier in erster Linie durch Microchip eigene Programmierer erbracht wird die ganu dafür angestellt sind und bezahlt werden... Im gegensatz zum AVR wo man dann daruaf angewiesen ist das sich jemand mal in der Freizeit erbarmt und dazu gleich dann zig unterschiedliche Versionen nebeneinander existieren. > Ich muss mich leider mit den PICs etwas quälen. Es ist schon hart einen > PIC in C zu programmieren, wenn man den GCC gewohnt ist ;-) > (Natürlich muss man auch erst einmal den richtigen Compiler für den > jeweiligen PIC finden...Und bei ~300 Zeilen Code kommt dann so ein > tolles "Demo limit". Da könnt ich den ganzen Scheiss einfach ausm > Fenster schmeißen. Aber das Hexfile dann auf den Controller zu bekommen > ist genauso ein gefrickel. 16F887/18F4550+EasyPic6+MikroCPro (so heißt > das Programmiertool glaub ich, bin mir aber nicht sicher). In der Doku > für MikroCPro finden sich wunderbare Beispiel zum Ansteuern über die > Kommandozeile. Der Shicedreck ist aber total nutzlos wenn das in > keinster Weise funzt! Diese Programm ist einfach nicht in der Lage das > via Parameter übergebene Hexfile zu flashen... (bzw. mit einer > Warscheinlichkeit von etwa 10%). Und wenns mal geht (oder man alles > manuell macht) kommt zu 70% keine Fehlermeldung, der PIC ist aber > trotzdem NICHT geflasht. Wobei ich mich frage warum das "verify" dann > erfolgreich ist??) > ... > (Und das nicht unbedingt weil der PIC an sich so schlecht währe, sondern > die Entwicklertools (meiner Meinung nach) einfach schlecht sind) > > Gruß Warum fällt es einigen so schwer zwischen Entwicklungsumgebung von dritten und dem Produkt sowie der dafür vom Hersteller herausgegebenen Entwicklungsumgebung zu unterscheiden. Alles was du hier beschreibst sind einzig deine Probleme mit der MikroC umgebung... Dabei wird hier - und an vielen anderen Stellen- immer wieder darauf hingewiesen das man es sich doch nicht so schwer machen soll und man direkt die Original Tools verwenden soll. Für den Einstieg ein PK3 (oder Clone) ab 20 Euro und MPLAB +microchip Compiler... DAs läuft zusammen, ist Stabil, dafür gibt es gute Dokumentationen und es gibt keinerlei Codelimit. Lediglich die maximale Optimierung wird nach drei Monaten zurückgefahren... (Das kann man aber bei den GCC basierenden Compilern auch umgehen in dem man die Quellcodes -die ja offen liegen- selbst kompiliert) Mit dieser Umgebung sieht es dann so aus: Einmal den µC auswählen, sowie ob der Debug Mode oder aber nur reines Brennen geplant ist. Danach Programm schreiben, auf Compilieren klicken und dann noch einmal schaltfläche (oder Tastenkürzel) brennen. Fertig! Man kann aber auch einstellen das direkt nach erfolgreichen Build gebrannt werden soll, dann ist es nur noch ein Tastendruck/Click. Und wenn dann MPLAB meldet das der Vorgang erfolgreich war, DANN war es auch erfolgreich. Wer sich da mit Merkwürdigen Fremdprodukten (Woebi ich zugeben muss das ich MikroC gar nicht wirklich kenne) rumquält, der ist selbst schuld... Aber alles was du oben als "Nachteil" geschrieben hast ist nun einmal ein Problem des Fremdproduktes. Im Gegenteil - bei der Original IDE muss man sich überhaupt keine Gedanken über iregenwelche zusammengestellten Toolchains machen, das läuft alles Intern ohne das der Nutzer für die StandartKonfig da irgendetwas ändern muss. Ein Click und fertig. Zudem: Die Microchip IDE gibt es im Original auch für Linux. AVR Studio nicht... Markus Müller schrieb: > So und jetzt macht mal jemand diesen ollen Thred dicht! Und warum dies... Bringt doch nichts, spätestens nach 12 Std. ist dann der nächste Thread eröffnet udn das ganze geht wieder von vorne los. Dann lieber einen Thread wo sich das alles sammelt. Zudem geht es ja hier sogar noch merkwürdig gesittet zu. Das kenne ich bei diesem Thema ganz anders. Gruß Carsten
ich möchte auch mal etwas benzin ins feuer werfen und habe eine uralte benchmark angehängt (keine ahnung mehr, woher ich die habe). leider sind da die aktuelleren uC nicht drin (z.b. ARM, oder die 60MIPS PIC24s oder 60MIPS dsPICs, ich vermuete mal, dass auch bei Atmel neuere uC draussen sind)
Ina schrieb: > Mir ist neulich aufgefallen, daß bestimmte ATMEL µC (z.B. der 164 oder > 328) keinerlei Spezifikationen über maximale ADC-Fehler in den > Datenblättern enthalten. Was soll man davon halten?? Verwendet habe ich den ADC bisher beim ATmega8 und beim ATtiny261 mit 10Bit Auflösung. Mit einem 10-Gang Poti konnte ich auf der Anzeige jede Zahl von 0 .. 1023 stabil einstellen. Ich hab jetzt nicht alle 1024 Stufen nachgemessen, aber die Wandlungen sind streng monoton und sehr stabil, also der ADC sehr rauscharm. Man kann selbst mit dem Mittelwert über 256 Messungen kein elftes Bit rauskitzeln, dazu müßte man erst die Eingangsspannung mit nem Dreiecksignal überlagern. Der ADC hätte also durchaus das Potential für 12Bit. Wenn man sich dagegen die Errata der neuen Xmega-Serie ansieht, scheint dort der ADC deutlich schlechter zu sein. Peter
holger schrieb: > Viel Spass beim ersten verfusen deines AVR Dank AVR-Burn-O-Mat passiert das nicht ;-) holger schrieb: > Für Volldeppen sind die nicht gemacht. Die AVR Tools auch nicht. Privat habe ich folgende Konfiguration: AVR-GCC + Geany + AVRDude + AVRBurnOMat für Fuses Diese Kette ist für mich viieeel einfacher zu Bedienen und logischer als MPLAB, MikroCPro usw... Die sind mir so unangenehm zu bedienen, dass ich nicht die Mühe gescheut habe, Geany zu installieren und jeweils ein make-all.bat-Skript und make-program.bat-Skript zu schreiben (in der Arbeit ist Win angesagt)... (Allerdings bei make-program eben das Problem dass man sich den Programmer eigentlich in den Popo schieben kann) Carsten Sch. schrieb: > Nö... > Denn GCC basierende Compiler sind auch bei PIC üblich... > Zwar nicht für die kleinen 8bitter, aber die Compiler für die > Leistungsfähigeren basieren auf GCC und sind sogar Open Source. Die bei uns verwendeten Controller sind 16F887 (laut Sprut 14Bit) und 18F4550 (16Bit). Für die gibt es ja dann GCC-Derivate? Kannst du mir die nennen oder einen Link geben? Währe wirklich eine große Erleichterung für mich! Dann hätte ich endlich Compiler, die Fehlermeldungen in vollständigen, deutschen Sätzen ausgeben. Wo das interpretieren der Fehlermeldung schneller geht als sich nur die Zeilennummer rauszupicken und sich die 5 Zeilen davor/dahinter selbst nochmal durchzulesen... z.B.
1 | for(unsigned char bla=0; bla<10; bla++) |
2 | {
|
3 | //blubb
|
4 | }
|
ist da nur "Syntax error". Nix weiter. (Ich weis, dass das nicht C-konform ist. Aber es ist ein Stückchen Komfort des GCC, und diese nichtssagende Fehlermeldung rechtfertigt das auch nicht (Ich hab 0h5 damit verbracht rauszufinden was die Fehlermeldung soll)) Carsten Sch. schrieb: > Für den Einstieg ein PK3 (oder Clone) ab 20 Euro und MPLAB +microchip > Compiler... Hardware ist schon vorhanden: http://www.mikroe.com/eng/products/view/297/easypic6-development-system/ Compiler möchte auf jeden Fall ein GCC-Derivat. Gibt es für dieses Board einen anständigen Programmer? (also Software meine ich jetzt). Am besten Kommandozeile. Tut mir leid wenn ich so blöd frage, aber ich benutze nur AVRDude und damit geht mehr oder weniger ALLES... Gruß
> Gibt es für dieses Board einen anständigen Programmer? (also Software
Das macht MPLAB mit, wenn Du ein PICkit oder ICD als Hardware nimmst
holger schrieb: > Stellen wir doch mal eine neue Frage: > Warum AVR benutzen wenn es ARM gibt? Weil es kein ARM-Studio gibt? Eine freie Entwicklungs-Umgebung für ARM hätte mal was - und kommt mir jetzt bloss nicht mit so einem Schrott wie Yagarto mit Eclipse. Truestudio ist schon ganz drollig, sowas wie AVR-Studio ist das aber längst nicht.
Ich schrieb: > Truestudio ist schon ganz drollig, sowas wie AVR-Studio ist das aber > längst nicht. Truestudio IST Eclipse... Und welches AVR-Studio meinst du? Das veraltete 4er oder das verbuggte 5er?
Simon S. schrieb: > Privat habe ich folgende Konfiguration: AVR-GCC + Geany + AVRDude + > AVRBurnOMat für Fuses Bis auf AVRBurnOMat verwende ich das auch. Ich hab mir ein einfaches Script geschrieben, in dem ich avrdude aufrufe. Das nenne ich jeweils so wie das Target und mache es ausführbar. Dann kann ich einfach auf den "Run" Button von Geany klicken oder F5 drücken. Mich stört aber, dass man zum Compilieren immer zu einer passenden Datei wechseln muss. > > Für die gibt es ja dann GCC-Derivate? Kannst du mir die > nennen oder einen Link geben? Währe wirklich eine große Erleichterung > für mich! Es gibt den SDCC. Was der allerdings taugt weiß ich nicht.
Simon S. schrieb: > Privat habe ich folgende Konfiguration: AVR-GCC + Geany + AVRDude + > AVRBurnOMat für Fuses > > Diese Kette ist für mich viieeel einfacher zu Bedienen und logischer als > MPLAB, MikroCPro usw... Für den PIC wäre es aber auch nur MPLAB (inkl C18/30 -> C-Compiler) + PICKIT2 oder 3 (Brenner). Wem eine IDE und ein Gerät zum programmieren, brennen, debuggen und emulieren zu umständlich ist, den kann ich nicht verstehen. Ein Programm nur für Fuses?? DAS klingt für mich umständlich. Außerdem: Wieso sollte man eine kostenlose Version eines Compilers mit Code-Limit benutzen, statt dem Original-Compiler ohne Codelimit, der auch kostenlos ist? Zumindest, wenn der Code groß wird? Das Video was es genau auf den Punkt bringt, was aus meiner Sicht auch ALLES Wahr ist, ist dieses hier: http://www.youtube.com/watch?v=DBftApUQ8QI
Master Snowman schrieb: > ich möchte auch mal etwas benzin ins feuer werfen und habe eine uralte > benchmark angehängt (keine ahnung mehr, woher ich die habe). leider sind > da die aktuelleren uC nicht drin (z.b. ARM, oder die 60MIPS PIC24s oder > 60MIPS dsPICs, ich vermuete mal, dass auch bei Atmel neuere uC draussen > sind) Hallo Snowman, Das interressanteste am Benchmark wäre für mich der Vergleich PIC18F gegen die anderen - insbesondere gegen Ateml. Leider steht aber an keiner PIC18 Zeile irgendwas. Kennst da jemand eine Quelle ? MFG:MBP Markus.
Markus B. p. schrieb: > Master Snowman schrieb: >> ich möchte auch mal etwas benzin ins feuer werfen und habe eine uralte >> benchmark angehängt (keine ahnung mehr, woher ich die habe). leider sind >> da die aktuelleren uC nicht drin (z.b. ARM, oder die 60MIPS PIC24s oder >> 60MIPS dsPICs, ich vermuete mal, dass auch bei Atmel neuere uC draussen >> sind) > > Hallo Snowman, > > Das interressanteste am Benchmark wäre für mich der Vergleich PIC18F > gegen die anderen - insbesondere gegen Ateml. > Leider steht aber an keiner PIC18 Zeile irgendwas. > > Kennst da jemand eine Quelle ? Dafür nicht (sollte aber mit dem Simulator vom MPLAB genau genug machbar sein), aber es gibt zumindest für einige AVR, AVR32, PIC18, PIC24, PIC32 Coremark-Ergebnisse: http://www.coremark.org/benchmark/index.php (Atmel und Microchip auswählen, suchen und nach Coremark/MHz sortieren...) > MFG:MBP > Markus.
Nun interressante Diskussion - ich kann die gut verstehen. PIC und MEGA-AVR haben alle ihre Daseinsberechtigung. Mittlerweile nutzte ich beide insbesondere wegen CAN-Bus. Auch wenn ich anfangs von PIC nichts wissen wollte. Bei AVR habe ich mit 100% Assembler begonnen. (AVR Assembler 2 und Makros ist was echt feines.) Bin mittlerweile aber meist bei 100% C. PIC18 / dsPIC programmiere ich nur in C, der ASM von PIC18 gefällt mir überhaupt nicht. Da ich also beide kenne, so habe ich auch viel verglichen. Sowohl die Datenblätter als auch die Features. So wie es aussieht, so gibt es noch immer keine TQFP44 AVR mit CAN oder habe ich da was übermerkt ? --> PLUS für PIC. Die TQFP44 Pinbelegung von MEGA16 VS PIC18... PIC18F SPI schließt Hardware-TWI aus. (mit ext. TWI Puffer gehts.) PIC18F45x 8 Kanal ADC mit Externer ARef: GEHT NICHT. PIC18F4xxx 8 Kanal ADC mit Externer ARef: klaut Digitale IO's Aber auch Atmel ist nicht perfekt: Wenn man zB. einen 8-Bit breiten IO Port benötigt, so muss man auch auf SPI, ADC, TWI oder UART verzichten. --> dennoch ein knappes PLUS für AVR. Wenn man die Datenblatt-Optik von Atmel gewöhnt ist, so findet man sich anfangs bei PIC wirklich nicht zurecht. Mit der Zeit geht aber auch das vorbei. --> Unentschieden. Somit kann auch ich keinen eindeutigen Sieger küren. Ähm... S12/S12X sticht Mega-AVR's ;-) S12 = Freescale (früher Motorola) Und... Der dsPic ist übrigens auch was ganz nettes, der hat die Port-Probleme vom PIC18 nicht, kann zwar keine 5V ab, dafür aber eine PLL, die aus fast jedem Quarz den richtigen System-Takt erzeugt. Ja ich weiß die sind BEIDE eine andere Klasse. ABER ES BLEIBT DABEI: Je nach Anwenfungsfall ist meist EINER besser als ein anderer. (manchmal erst recht auch mehrere) MFG:MBP Markus.
Arc Net schrieb: > aber es gibt zumindest für einige AVR, AVR32, PIC18, PIC24, PIC32 > Coremark-Ergebnisse: > http://www.coremark.org/benchmark/index.php Danke ! Oh, da sieht PIC18 aber schlecht gegen die beiden AVR aus. Selbst noch, wenn man das PIC Ergebniss mit 4 multiplizert. Naja... Irgendwer hat mal gesagt: "Traue keiner Statistik, die Du nicht selbst gefälscht hast." Da muss ich mir wohl wirklich eine selber fälschen. Aber die Idee mit dem Simulator ist gut. MFG:MBP Markus.
Master Snowman schrieb: > ich möchte auch mal etwas benzin ins feuer werfen und habe eine uralte > benchmark angehängt (keine ahnung mehr, woher ich die habe). Wahrscheinlich von hier: Beitrag "Re: LPC2103 63MIPS?" Weiter unten im Thread wurden die Benchmarkergebnisse von anderen Forenteilnehmern um weitere Controllertypen ergänzt. Markus B. p. schrieb: > da sieht PIC18 aber schlecht gegen die beiden AVR aus. > Selbst noch, wenn man das PIC Ergebniss mit 4 multiplizert. Wenn ich mir den Befehlssatz der beiden Controller anschaue, würde ich sagen, dass sich ein 64MHz-PIC18 und ein 20MHz-ATmega nicht allzu viel schenken. Der ATmega ist zwar etwas höher getaktet (1 Befehlstakt des PIC entspricht ja 4 Oszillatortakten), dafür führt der PIC18 einige Befehle in 1 Zyklus aus, wo der ATmega 2 braucht (z.B. die Multiplika- tion). Jeder der beiden Controller hat ein paar Befehle, die man auf dem jeweils anderen aus zwei oder mehr Befehlen zusammensetzen muss. Dass die Benchmarkergebnisse so weit auseinander liegen, würde ich des- wegen darauf zurückführen, dass der Benchmark auf Grund der getesteten Kriterien den ATmega bevorzugt, oder dass der AVR-GCC besser optimiert als der C18-Compiler des PIC. Die Ergebnisse im obigen benchmark.c für den ATmega erscheinen mir übri- gens viel zu hoch. Bei den ersten beiden Tests und einer Taktfrequenz von 16MHz komme ich mit einem aktuellen GCC (4.3 oder neuer) auf 96,4µs statt 641µs bzw. 657µs. Entweder war damals der GCC sehr viel schlechter als heute oder (wahrscheinlicher) es wurde vergessen, die Optimierung einzuschalten.
John schrieb: > "Aber mein ARM7 kann viiiieeeeellll mehr als eure klumpigen AVRs und > PICs > *ätsch*" > > > Aus dem Alter bin ich raus. > Ich benutze nur noch die ARM9 (von ST). Mehr Speicher, schneller durch > längere Pipeline und höheren Takt, etc. pp. Dafür nur Portzugriff, keine Bitmanipulation....
frankman schrieb: > Dafür nur Portzugriff, keine Bitmanipulation.... Sehr viele ARMs haben GPIO-Ports mit Bitmanipulation. Nicht unbedingt als Prozessorbefehl, aber als Eigenschaft des Ports. Nur eben jeder anders.
Nein ich schrieb: > Truestudio IST Eclipse... Stimmt auffällig, ist aber dennoch besser integriert als so ein Gemurkse wie Yagarto. Und gefallen tut mir alles nicht was ich bisher an kostenlosen IDEs für ARM gesehen habe. > Und welches AVR-Studio meinst du? Das veraltete 4er > oder das verbuggte 5er? Die finde ich beide besser als alles was mir für den ARM bisher untergekommen ist. Wobei das 4er ARV-Studio kaum als veraltet bezeichnet werden kann und das 5er Studio gerade mal den ersten Release hatte. Das 4er Studio wird für die 8-Bit AVR noch lange seinen Dienst tun, so schnell wirft Atmel dann auch nicht mit neuen Controllern nach dem Markt das man da ein Problem bekommt. Zumal man das was Atmel ankündigt noch lange nicht auf dem Tisch haben wird.
Hi, "Ich nochmal" Es ist schon recht interessant auf was hier einige Ihre Wahl gründen. Und noch interessanter sind diejeniegen die hier meinen "Schwanzvergleiche" führen zu müssen und anscheinend dadurch den Eindruck von Kompetenz vermitteln zu wollen das SIE ja die "Dicksten" Controller verwenden und alles andere Spielzeug ist. (Ich verwende nur noch ARM...) Das ist abe rmitnichten ein Merkmal von Kompetenz, sondern genauso Frickelverhalten wie die Bemühungen wirklich alles mit einem einzigen AVR Typ erledigen zu wollen. Egal ob man dazu fünf verschiede Interfacebausteine anhängen muss und es genügend andere µC gibt die alle, oder zumindest den Großteil, der Funktionen bereits an Board haben und dabei sogar noch weniger Kosten. JA, die Leistungsfähigen Controller haben natürlich ihre daseinsberechtigung. Für einen großen Teil der Anwendugnen sind sie die Einzig Sinnvolle Wahl, da die Aufgaben mit den kleinen Brüdern nur mit erheblichen Aufwand -oder überhaupt nicht- lösbar sind. Aber diese Schlacht um MIPS und Co ist absoluter Blödsinn. Wenn man es in der Masse sieht, dann ist wohl klar das der absolute Großteil de rheute verbauten Prozessoren sich einfach nur "langweilt", die vorhandene Leistung nicht mal Ansatzweise ausgenutzt wird. Es spielt schlicht keine Rolle ob der CPU Kern nun zu 10% oder zu 5% ausgenutzt ist. Die 32Bit µC sind überall da das Mittel der Wahl wo große Datenmengen verarbeitet werden müssen. Das können sehr schnelle Datenerfassungsgeräte sein, komplexere Web Basierende Systeme, alle Arten von schnellen Modems oder schlicht Anwendungen mit aufwendiger Grafik. Wie weiter oben schon geschrieben haben die 32Bit aber in der Regel keine "einfache" Möglichkeit für simple Funktionen wie Pin-Togglen. Gerade das ist aber die Stärke der 8Bitter. Schon wenn man sich deren Ports ansieht merkt man schnell das die Ausgabe in ganzer Busbreite von den Herstellern als eher unbedeutend eingeschätzt wird und die Schwerpunkte auf bitweise Ausgaben und den im bereich einfacher Aufgaben vorherschenden seriellen Bussysteme. Es handelt sich also um zwei recht verschiedene gedachte Einsatzgebiete die natürlich auch mal geringe Überschneidungen haben können. Gerade aber recht einfache Steueraufgaben die mit fast allen 8 Bittern mit einem Handstreich erledigt werden können erfordern bei den 32 Bittern einiges an Aufwand. Insbesondere gilt das für alles was man früher durch "Gattergräber", teilweise ergänzt durch Datentabellen irgendwo im Speicher (fest verdrahtet, Prom) gelöst hat. Wer für solche Sachen auf teufel komm raus einen 32Bitter einsetzen will, der hat irgendetwas nicht verstanden. Wenn man dies überdenkt, dann wird schnell klar warum also für einen 8Bitter die vorhandene Peripherie und Bibliotheken dazu viel viel wichtiger sind als die reine REchenleistung. GRuß Carsten
>Wie weiter oben schon geschrieben haben die 32Bit aber in der Regel >keine "einfache" Möglichkeit für simple Funktionen wie Pin-Togglen. Nur manche 32Biter (typ.weise LD/ST Archit.) haben diese Probleme. Auch AVR ist LD/ST und ist langsam, wenn im RAM (nicht im IO) bits geändert werden müssen.
Yalu X. schrieb: > Wenn ich mir den Befehlssatz der beiden Controller anschaue, würde ich > sagen, dass sich ein 64MHz-PIC18 und ein 20MHz-ATmega nicht allzu viel > schenken. Der ATmega ist zwar etwas höher getaktet (1 Befehlstakt des > PIC entspricht ja 4 Oszillatortakten) Hallo Yalu, Das scheint mir auch realistischer, als der andere Benchmark. Die 4 Oszillator-Takte kann man ja bei den PIC18 mit dem HS-PLL-Mode wieder reinholen - somit sind 10 MHz außen 10 MIPS innen. "Optimierung" ... stimmt. Für einen schlechten Compiler, oder gar ein mieses Programm kann der Controler ja nichts. Eigenlich müsste man die selbe Aufgabe in der jeweiligen Assemblersprache des Controlles selbst erstelen und optimieren, um wirklich nur Controller und nicht auch die Compiler zu vergelichen. Selbst die FFT auf AVR (ASM) (Abgewandelt aus [ 1 ]) benötigt bei einem Testaufbau von mir mehr Zeit für das Sampeln und Filtern des Signales vor den Funktionen der FFT und für die Datenausgabe danach. [ 2 ] Auch ich habe den AVR nur wegen der Abtastrate Übertaktet: 48 KSps @ 20MHz, NF 24 KHz MAX, 187,8 Hz each Bar, 128 Bars. Somit sollten die MIPS bei "Kleinkram" wohl wirklich selten bedeutsam werden. MFG:MBP Markus ********************************************************************* [ 1 ] Beitrag "Schnelle FFT in Assembler" Dass Dort im Thread was von PIC = SEHR LANGSAM steht, das fällt wohl auch wieder unter fehlende / falsche Optimierung, bzw. den Vergelich C vs. ASM etc. [ 2 ] Der eigentliche Flaschenhals ist RS232 @ 115 KBaud zu meinem VB6-Programm. Die 1. Test-Daten-Ausgabe / Aufzeichnung hat alles ausgbremst. Nach Änderungen läuft die Live-Auswertung unter WIN XP reibungslos auf dem etwas betagen AMD Athlon XP 2000+. Ein Experiment mit dem selben PC und dem VB6-Programm unter Wine/Linux: Die Auswertung läuft über 2 Minuten nach Testende immer noch...
Carsten Sch. schrieb: >Wie weiter oben schon geschrieben haben die 32Bit aber in der Regel >keine "einfache" Möglichkeit für simple Funktionen wie Pin-Togglen. Pin Toggeln ist auch auf 32Bittern einfach, nur meist nicht besonders schnell ;). Die LPC122x hätten aber ein spezielles Pin-Toggel Register. Damit lassen sich sogar mehrere Pins gleichzeitg toggeln. Da streichen dann die 8Bitter wiederum die Segel. > Wenn man dies überdenkt, dann wird schnell klar warum also für einen > 8Bitter die vorhandene Peripherie und Bibliotheken dazu viel viel > wichtiger sind als die reine REchenleistung. Ich verwende fast nur noch 32Bitter. Aber eben nicht wegen der Geschwindigkeit sondern aufgrund von Peripherie, Preis und Kompatibilität. Als Takt stelle ich bisweilen auch mal 1Mhz ein. Einige PICs haben mitunter recht interessante Zusätze. Doch Pullups nur an vier Pins. Pulldowns fehlen ganz. Die Timer haben nur 8 oder 16 Bits und deren Prescaler sind sehr unflexibel. Wenn ich bei einem 32Bitter die Clock durch 285 teilen will dann stelle ich den Vorteiler entsprechend ein. Bei allen GPIOs kann man Pullup-/down/opendrain einstellen. SPI und I2C lassen sich gleichzeitig verwenden. Wenn der Takt für eine nachträglich eingebaute Funktion nicht ausreicht kann man einfach per Software die PLL umkonfigurieren und so z.B. von 12Mhz auf 15Mhz gehen. Oder auf 60Mhz. Ein spezielles Programmiergerät wird nicht benötigt. Die Uarts brauchen keine Baudratenquarze. Wenn der LPC1764 gerade nicht lieferbar ist, setze ich eben einen LPC1766/1768 oder 1769 ein. Die sind binärkompatibel. Wie oft habe ich mich schon über Microchip geärgert weil ein Chip gerade nicht lieferbar ist und der Liefertermin bei MicrochipDirect Woche um Woche nach hinten geschoben wird. Ein Programm ist zwar schnell für einen anderen Typen angepasst aber das gibt ein neues Binary. Bei zukünftigen Updates muss man also erst nachsehen welcher µC gerade in dem Gerät verbaut ist. Und wenn ich mir dann einmal die Preise ansehe - zumindest ab 32k Flash - frage ich mich schon weshalb ich für einen Controller der weniger kann mehr Geld ausgeben soll. Weil er ausreicht und 32Bit "übertrieben" sind? Markus B. p. schrieb: > Für einen schlechten Compiler, > oder gar ein mieses Programm kann der Controler ja nichts. Für ein schlechtes Programm kann er nichts, für den Compiler zwar auch nicht aber wenn ich in C programmieren will/muss und mir kein gescheiter Compiler zu Verfügung steht, dann muss das letzlich der Controller ausbaden. Das trifft in dieser Diskussion vor allem die Microchip Compiler in den kostenlosen Ausführungen. Beim C18 weiß ich nicht was passiert (habe ihn nie verwendet) aber bei den GCC basierten C30 und C32 steht nach der Testzeit anscheinend nur noch die Optimierungsstufe "-O1" zur Verfügung. Das habe ich mal bei einem M3 Projekt mit einem GLCD probiert. Gegenüber der Stufe "-O2" kostet das über 20% Geschwindigkeit und das Programm ist etwa doppelt so groß. Wenn das bei den PICs auch so ist dann aber gute Nacht.
Hi >Die LPC122x hätten aber ein spezielles Pin-Toggel Register. >Damit lassen sich sogar mehrere Pins gleichzeitg toggeln. Da streichen > dann die 8Bitter wiederum die Segel. Bei den ATXMegas (8 Bit) hat jeder Port sogar jeweils ein Register zum Setzen, Löschen und Togglen von Pins. Und bei neueren AVRs bewirkt ein Schreiben einer 1 auf ein, oder mehrere, Bit(s) auf das bei allen AVRs vorhandene PIN-Register ein Togglen der angesprochenen PINs. Da werden eher Segel gehisst. MfG Spess
spess53 schrieb: > Schreiben einer 1 auf ein, oder mehrere, Bit(s) auf das bei allen AVRs > vorhandene PIN-Register ein Togglen der angesprochenen PINs. Da werden > eher Segel gehisst. Es gibt neben dem Setzen, Löschen und Toggeln einzelner Bits eine weitere wesentliche aber eben nicht obligatorische Grundoperation auf Ports: Eine Untermenge der Bits (>1) eines Ports gleichzeitig und atomar auf einen bestimmten Wert setzen. Nicht-atomar ist das die übliche read-modify-write Kiste aus mehreren Befehlen. Nicht extrem schnell, aber sonst kein Problem. Aber wenn der Port auch in einer ISR verwendet wird, dann wirds schwieriger und da sind die CISCs ohne Hilfestellung durch Portlogik meist auch nicht besser dran als die RISCs. Sowas kann man dann per Maske lösen wie bei der ARM PrimeCell in der Adresse und den LPCs im Register, oder aber in wie bei den STM32 in den Daten selbst. Bei den AVRs kommt man u.U. mit der erwähnten XOR-Masche der PINx weiter. Hat man nichts dergleichen, dann muss man Inerrupts sperren. Unschön. Bei den PIC30 geht das zwar im Prinzip sehr einfach, bildet sich aber extrem schlecht auf C-Programmierung ab.
Michael G. schrieb: > Die LPC122x hätten aber ein spezielles Pin-Toggel Register. > Damit lassen sich sogar mehrere Pins gleichzeitg toggeln. Da streichen > dann die 8Bitter wiederum die Segel. > > Als Takt stelle ich bisweilen auch mal 1Mhz ein. > Wenn ich bei einem 32Bitter die Clock durch 285 teilen will dann stelle > ich den Vorteiler entsprechend ein. > Bei allen GPIOs kann man Pullup-/down/opendrain einstellen. SPI und I2C > lassen sich gleichzeitig verwenden. > Wenn der Takt für eine nachträglich eingebaute Funktion nicht ausreicht > kann man einfach per Software die PLL umkonfigurieren und so z.B. von > 12Mhz auf 15Mhz gehen. Oder auf 60Mhz. > Ein spezielles Programmiergerät wird nicht benötigt. Die Uarts brauchen > keine Baudratenquarze. Klingt nach Xmega SCNR
spess53 schrieb: > Und bei neueren AVRs bewirkt ein > Schreiben einer 1 auf ein, oder mehrere, Bit(s) auf das bei allen AVRs > vorhandene PIN-Register ein Togglen der angesprochenen PINs. Aua. Die armen AVR-Anfänger oder Umsteiger auf AVR. Wenn ich mich recht erinnere, so hat "Write" an "PIN" früher einfach NIX geändert, und nun Toggelt der... Wer das nicht beachtet und einen solchen neuen Controller erwischt, der hat noch größere Freude am Fehlersuchen als ich damals. Da ist PIC18 echt einsteigerfreundlich :-) Aus dem PIC18F4685 Datenblatt: "Reading the PORTA register reads the status of the pins, whereas writing to it, will write to the port latch." MFG:MBP Markus.
Ja, das wieder so ein typischer "Religionskrieg". So was gab es übrigens schon immer, berühmt war beispielsweise in den 1980gern der Z80 - 6502 Krieg. Für mich persönlich ist das so: Ich habe mir mal die PICs angeschaut, aber die die ich da gesehen hatten konnten damals nur 16 Bytes auf einmal aufrufen, den Rest musste man per Bankswitching machen. Auch waren die für die ersten Sachen die ich machen wollte damals zu langsam. AtMegas hab ich mir dann mal angeschaut als ich eine CCD Kamera gegen ein Evaluationsboard von Atmel getauscht habe. Der war dann auch schnell genug für Video. MSP430 hab ich mir mal ein wenig angeschaut, damals gab es aber noch keine freien Entwicklungswerkzeuge. Inzwischen gibts zumindest einen freien C-Compiler, aber anscheinend noch keinen freien Assembler. Da ich persönlich C nicht mag, ist das ein Ausschlusskriterium für mich. Wie schon gesagt, das sind persönliche Meinungen. Wenn mir jemand eine komplett freie Entwicklungsumgebung Assembler für die MSP430 Serie zeigen kann, oder ein Unix, welches auf den Controllern läuft. (Dann würde meiner Meinung nach C Sinn haben)
> Die LPC122x hätten aber ein spezielles Pin-Toggel Register. > Damit lassen sich sogar mehrere Pins gleichzeitg toggeln. Da streichen > dann die 8Bitter wiederum die Segel. Das ist nichts weiter als ein NOT/NEG-Befehl. Dauert bei STM8 1 Takt; bei einigen anderen Nicht-32-Bitern 1..4 Takte. > Ich verwende fast nur noch 32Bitter. Aber eben nicht wegen der > Geschwindigkeit sondern aufgrund von Peripherie, Preis und > Kompatibilität. Bei einigen 8/16/32-Bit-Serien ist die Peripherie gleich.
Hier wird sogar von einem ARM zu Xmega gewechselt http://www.kickstarter.com/projects/itdaniher/cee-the-usb-analog-electronics-multi-tool/posts/102466 ARM ist kein Allheilmittel. Und so lange man unter Debian zum installieren und einrichten einer funktionierenden Toolchain länger braucht als eine Schnecke um die Erde ist es eh uninteressant.
Hi >Die armen AVR-Anfänger oder Umsteiger auf AVR. >Wenn ich mich recht erinnere, >so hat "Write" an "PIN" früher einfach NIX geändert, >und nun Toggelt der... Ja. Und das steht dann auch im jeweiligen Datenblatt. Wie bei deinem PIC. Wo ist das Problem? MfG Spess
Markus B. p. schrieb: > Wer das nicht beachtet und einen solchen neuen Controller erwischt, ...ist selber schuld. Wer schreibt schon in das PIN Register?
>> Ich verwende fast nur noch 32Bitter. Aber eben nicht wegen der >> Geschwindigkeit sondern aufgrund von Peripherie, Preis und >> Kompatibilität. > Bei einigen 8/16/32-Bit-Serien ist die Peripherie gleich. Zum Beispiel?
Michael G. schrieb: >> Bei einigen 8/16/32-Bit-Serien ist die Peripherie gleich. > > Zum Beispiel? Bei STM8 und STM32 sind sie zwar nicht gleich, aber verwandt. Auch bei PIC18/30/32 finden sich Verwandschaften.
Markus B. schrieb: > ARM ist kein Allheilmittel. Und so lange man unter Debian zum > installieren und einrichten einer funktionierenden Toolchain länger > braucht als eine Schnecke um die Erde ist es eh uninteressant. Man bräuchte für ARM so eine Art CP/M. Quasi ein kleines Betriebssystem mit dem man direkt auf den Controllern entwickeln könnte.
spess53 schrieb: > Hi > >>Die armen AVR-Anfänger oder Umsteiger auf AVR. > >>Wenn ich mich recht erinnere, >>so hat "Write" an "PIN" früher einfach NIX geändert, >>und nun Toggelt der... > > Ja. Und das steht dann auch im jeweiligen Datenblatt. Wie bei deinem > PIC. Wo ist das Problem? > > MfG Spess Hi Spess, Problem sehe ich für mich keines, aber viele Anfänger werden die Datenblätter entweder nicht lesen, oder nicht verstehen. Selbst wenn sie es lesen und verstehen, so gibt es für sie noch immer die Möglichkeit den Fehler zu machen. Und die Möglichkeiten nutzt man als Anfänger fast ALLE aus. Aber frage einmal AVR Anfänger - jene werden diese Stelle am AVR als Schwierig einstufen, bis sie Routine daruf haben. Bei AT89S52 gibt es gar nur ein Register pro Port. Das wäre für Anfänger also noch einfacher. MFG:MBP Markus.
Aus welchem Grund ist es so kompliziert eine funktionierende Toolchain für ARM-xy zu installieren? Sollte es doch für die gebräuchlichsten Typen vorgefertigt geben, oder beißen sich da Interessen(gruppen) irgendwo?
Hi >Problem sehe ich für mich keines, >aber viele Anfänger werden die Datenblätter entweder nicht lesen, >oder nicht verstehen. Wer sie nicht lest hat eh verloren. Verdient keine Gnade. Wer sie liest kann nachfragen. Ich stamme aus einer Zeit wo man sich Wissen ohne Internet aneignen musste. Deshalb habe ich für Weicheier in dieser Beziehung kein Verständnis. MfG Spess
Christian Berger schrieb: > Man bräuchte für ARM so eine Art CP/M. Quasi ein kleines Betriebssystem > mit dem man direkt auf den Controllern entwickeln könnte. Siehe da: http://www.freertos.org/ Ich habe neulich nach einem Controller gesucht, mit dem ich die PWM für drei LED-Schaltregler in Software implementieren kann, und wurde da bei den MSP430 fündig -- davon gibt es sogar einige sehr einfache Modelle (4kB Flash, 8MHz, DIP, ca. 1,5€) mit vier 16-Bit-PWM-Kanälen, beim AVR muss es dann schon ein ATMega8U2 oder größer sein (der hat dann auch USB etc. und ist entsprechend teurer, außerdem schwer zu bekommen).
Sebastian G. schrieb: > Christian Berger schrieb: >> Man bräuchte für ARM so eine Art CP/M. Quasi ein kleines Betriebssystem >> mit dem man direkt auf den Controllern entwickeln könnte. > Siehe da: http://www.freertos.org/ FreeRTOS scheint weder eine Shell zu haben, noch einen C-Compiler. Das scheint ein reiner Kernel zu sein. Zu einem Betriebssystem gehört jedoch auch das "Userland", sprich die ganzen Betriebssystemswerkzeuge. Unter FreeRTOS scheint es weder einen Texteditor, noch einen Compiler zu geben. > Ich habe neulich nach einem Controller gesucht, mit dem ich die PWM für > drei LED-Schaltregler in Software implementieren kann, und wurde da bei > den MSP430 fündig -- davon gibt es sogar einige sehr einfache Modelle > (4kB Flash, 8MHz, DIP, ca. 1,5€) mit vier 16-Bit-PWM-Kanälen, beim AVR > muss es dann schon ein ATMega8U2 oder größer sein (der hat dann auch USB > etc. und ist entsprechend teurer, außerdem schwer zu bekommen). Ich verstehe irgendwie nicht, was an der LED PWM-Steuerung so besonders sein soll. Das scheint mir ein Trivialproblem zu sein, das auf jedem Controller einfach funktioniert. Entweder mit Hardware PWM, oder einfach einen Timer laufen lassen, der dann die PWM für die n-Kanäle laufen lässt. Pro Kanal sind das grob 10 Taktzyklen. Macht bei 8 Kanälen 80 Taktzyklen, also kann man beispielsweise mit einem 128-tel der Taktfrequenz arbeiten.
tanolino schrieb: > Die PIC haben für den selben Preiß mehr Programmspeicher aber dafür kein > EEPROM. > Beispiel (Preiße laut Reichelt): > ATMEGA 8-16 (DIL-28) max. 16MHz und 23 IO Ports > 8kB Flash, 512B EEPROM, 1kB RAM > -> 2.60€ > > PIC 16F648A-I/P max.20MHz und 16 IO Ports > 4kx14 Flash, 256B EEPROM, 256B RAM > dafür USART > -> 2.30€ > Das Problem war die Wirtschafftskrise, da hatte Atmel teilweisse die Preisse verdoppelt während Microchip bei den niedrigen Preissen blieb.
Christian Berger schrieb: > FreeRTOS scheint weder eine Shell zu haben, noch einen C-Compiler. Das > scheint ein reiner Kernel zu sein. Zu einem Betriebssystem gehört jedoch > auch das "Userland", sprich die ganzen Betriebssystemswerkzeuge. Unter > FreeRTOS scheint es weder einen Texteditor, noch einen Compiler zu > geben. http://rowebots.com/products/dspnano_rtos scheint eine shell zu bieten. Wikipedia nennt noch ein paar weitere: http://en.wikipedia.org/wiki/List_of_operating_systems#Embedded Christian Berger schrieb: > Ich verstehe irgendwie nicht, was an der LED PWM-Steuerung so besonders > sein soll. Das scheint mir ein Trivialproblem zu sein, das auf jedem > Controller einfach funktioniert. Entweder mit Hardware PWM, oder einfach > einen Timer laufen lassen, der dann die PWM für die n-Kanäle laufen > lässt. Ich wollte 3W-RGB-LEDs ansteuern, und hatte selbst bei 16-Bit-PWM einen merklichen Unterschied zwischen Helligkeitsstufe 1/65536 und 2/65536. Nun wollte ich noch die Strombegrenzung mit der PWM implementieren (Schaltregler), was dazu führt, dass ich die 16 Bit noch nicht einmal komplett ausschöpfen kann (da z.B. 330mA Maximalstrom z.B. 50% duty cycle entsprechen und ich somit für die Helligkeitseinstellung nur den Bereicht von 0-50% zur Verfügung habe).
Markus B. p. schrieb: > Eigenlich müsste man die selbe Aufgabe in der jeweiligen > Assemblersprache des Controlles selbst erstellen und optimieren, um > wirklich nur Controller und nicht auch die Compiler zu vergelichen. Diese Zahlen spiegeln aber nicht das wieder, was dich an einem µC interessiert, nämlich wie leistungsfähig er in der Entwicklungsumgebung ist, die tatsächlich eingesetzt wird bzw. werden soll. Was bringt dir ein Assembler-Benchmark wenn angedacht ist, den µC in C zu programmieren oder umgekehrt? Nichts ausser ein paar nichtssagenden Zahlen. Einige Compilerhersteller frickeln ewig an ihren Tools rum, um gute SPEC oder welche Benchmarks auch immer zu erzielen und schöne Zahlen veröffentlichen zu können. Das ist doch alles Augenwischerei; was wirklich interessiert ist die letztendliche Entwicklungsumgebung und die Anatomie der Software (Dateilastig, Arithmetik, ...): µC, Energieverbrauch, Softwareumgebung, Support, Architektur (die man nicht dauern wechseln will), Kosten, zu lösende Probleme und ein Profiling unter diesen Rahmenbedingungen. Master Snowman schrieb: > ich [...] habe eine uralte benchmark angehängt > (keine ahnung mehr, woher ich die habe). Gleiche Kerbe: Wer programmiert schon mit lokalen volatiles? Einfach ein unrealistischer Märchencode. Carsten Sch. schrieb: > Denn GCC basierende Compiler sind auch bei PIC üblich... > Zwar nicht für die kleinen 8bitter, aber die Compiler für die > Leistungsfähigeren basieren auf GCC und sind sogar Open Source. Jeder GCC ist Freie Software (was anderes als Open Source). Übrigens ist frei nicht gleichbedeutend mit kostenlos: free as in freedom not as in free beer :-) > nur mit > dem Unterschied, daß der Support hier in erster Linie durch Microchip > eigene Programmierer erbracht wird, die genau dafür angestellt sind und > bezahlt werden... Im Gegensatz zum AVR, wo man dann darauf angewiesen > ist, daß sich jemand mal in der Freizeit erbarmt und dazu gleich dann > zig unterschiedliche Versionen nebeneinander existieren. Du kannst auch ein Softwarehaus mit GCC-Expertise mit einem avr-gcc Support beauftragen; entsprechende Portokasse vorausgesetzt. Allerdings sehe ich hier eher Atmel, also den Hersteller der AVRs, in der Pflicht, mehr für den Support von avr-gcc, seine Weiterentwicklung und Qualitätssicherung zu tun. Aber irgendwie bekommt Atmel es nicht auf den Appel.
Meiner Meinung nach hat fast jeder einzelne Microcontroller seine Daseinsberechtigung. Wenn ich ein kleines Ambi-Light machen will mit 3 Tastern und einem PWM-Ausgang, würde ich nie im Leben einen 16bit, gescheige denn einen 32bit MCU nehmen. So habe ich einen kleinen 8bit, 8pol PIC genommen und alles hat wunderbar geklappt. Auch, wenn ein SOIC8 vielleicht halb so groß ist, wie ein TQFP44 oder 64 eines 32bitters und wenn der 32bitter vielleicht nur 10 cent teurer aber deutlich leistungsfähiger ist, bringt mir das trotzdem nichts. Anders hingegen sieht es aus, einen FTP-Server und Touch-LCD auf einen MCU zu bringen. Deswegen: Für alles gibt es Anwendungsfälle. Da ist für mich ein Argument wie "Der und der kann aber besser/einfacher Pins togglen" viel zu speziell und unwichtig.
ich schrieb: > Für alles gibt es Anwendungsfälle. Da haste schon recht, aber hier gings ja um "ATMEL billiger und leistungsfähiger als PIC"- und dem muss man eigentlich uneingeschränkt zustimmen. Zum gleichen Preis erhält man bei Atmel meist die technisch bessere Lösung. Und zumindest auch aus meiner bescheidenen Assemblerprogrammierer-Sicht. Wenn ich daran zurückdenke wie ich mich bei meinem ersten Projekt mit dem kastrierten Befehlssatz und dem elenden Banking rumgeschlagen habe! Da waren die aufkommenden Atmels eine Erlösung! Dann bleibt man natürlich dabei und mir fehlt bis heute jeder Grund wieder umzusteigen. Und wenns wirklich mal was Multimediales sein soll dann besser gleich zu ARM & Co.
Atmel hat eigentlich nur zwei Fehler gemacht, und das gleich zwei mal. Sowohl USB als auch CAN kamen zu spät und zu inkonsequent. Es gibt bis heute keine "großen" ATmega mit USB. Auch ein Xmega A1 mit USB fehlt noch. Dafür gibt es keine kleinen ATmega mit CAN und Xmega mit CAN gibt es gar nicht. Dazu kommt noch, dass die ersten ATmega mit USB noch auf einer veralteten AVR Architektur aufbauten und es keine DIP Versionen gibt. PS: ich sehe gerade, dass es inzwischen immerhin TQFP32 mit CAN gibt. Dafür wurden aber wieder Features weggelassen wie ein 8 Bit Timer oder TWI
Da hast du wohl recht. Dann ist das Thema wohl zwischendurch ein wenig abgedriftet. Ich kenn mich zu wenig mit AVRs aus um hier qualitativ mitzureden ;) Das, was ich hier im Forum mal mitbekommen habe ist, das 8bit-PICs, wenn es um CAN, USB und Ethernet geht, wohl besser geeignet sein sollen, als 8bit-AVRs. Doch das kann ich wie gesagt nicht beurteilen.
ich schrieb: > Das, was ich hier im Forum mal mitbekommen habe ist, das > 8bit-PICs, wenn es um CAN, USB und Ethernet geht, wohl besser geeignet > sein sollen, als 8bit-AVRs. Doch das kann ich wie gesagt nicht > beurteilen. Besser geeignet würde ich nicht sagen. Aber besser und konsequenter vermarktet. Die AVR mit USB sind ja inzwischen schon nicht schlecht, mit Bootloader und so. Und dank dem LUFA Projekt bleiben eigentlich auch kaum Wünsche offen. Aber wie ich schon schrieb halt zu spät, nur in SMD usw.
>Wenn ich daran zurückdenke wie ich mich >bei meinem ersten Projekt mit dem kastrierten Befehlssatz und dem >elenden Banking rumgeschlagen habe! Dies (grässliche Banking) gilt nicht mehr bei 16-Bit-Datenbreite-PICs! Die sind auch schneller als AVR. (Sehr viele (rel complexe Befehle) mit nur 1 Cyc(2Takte)). wie Bsp: (innerhalb 64kB-Bereich) MOV{.B} [Ws++], [Wd++] oder ADDC{.B} Wb, [Ws++], [Wd++] Allerdings kann bei diesen PICs Ext.Mem-Anschaltung umständlich werden.
Soll das heißen das ein 16bit Controller schneller ist als ein 8bitter ?
Das hätte ich jetzt nicht gedacht. Bist du dir da sicher?
>Allerdings kann bei diesen PICs Ext .Mem-Anschaltung umständlich werden.
Was will uns der Künstler damit sagen?
das thema stellt sich an und für sich nur für einsteiger. als solcher würd ich bei der umfangreicheren pic-modellpalette heute eher schwach werden, insbesondere als c-programmer. nun bin ich allerdings lange jahre atmel-sozialisiert und werd einen teufel tun da noch mal umzusteigen.
spess53 schrieb: > Warum gräbst du eine 4 Jahre alte Leiche aus? Na siehst doch, wie groß der Bedarf ist :) PIC vs. AVR ist halt in einem MC-Forum immer ein aktuelles Thema! Conny
Hi >Na siehst doch, wie groß der Bedarf ist :) >PIC vs. AVR ist halt in einem MC-Forum immer ein aktuelles Thema! Aber nur für Leute mit fortgeschrittenem Alzheimer. MfG Spess
spess53 schrieb: > Aber nur für Leute mit fortgeschrittenem Alzheimer. na na na... das ist schon ein wenig von oben herab, meinst Du nicht auch? Irgendwie hat dieser Thread ja wohl sebst auf Dich noch ein wenig Anziehungskraft :)
Conny schrieb: > Na siehst doch, wie groß der Bedarf ist Für Religionskriege ist bei einigen Leuten immer Bedarf... ...
da Atmel demnächst 40 Typen der ATmega-Serie einstampfen wird, ist das Thema wieder offen. Wer wird dann gegen PIC antreten dürfen ? ....
die Typen sind mir noch nicht bekannt, aber das es kommen wird, habe ich heute erfahren. Atmel will nur noch 32-Bit machen.
Down schrieb: > da Atmel demnächst 40 Typen der ATmega-Serie einstampfen wird Naja, von vielen Typen gibt es bis zu vier Untertypen (*, *A, *P und *PA). Wenn man hier die veralteten weglässt, hat man die 40 schon fast zusammen. > Atmel will nur noch 32-Bit machen. Dass in näherer Zukunft (nächste 5 Jahre) alle 8-Bitter abgeschafft werden sollen, kann ich mit kaum vorstellen. Aber die Entscheidung treffe natürlich nicht ich, sondern irgendwelche Strategen bei Atmel.
Down schrieb: > die Typen sind mir noch nicht bekannt, aber das es kommen wird, habe ich > heute erfahren. Atmel will nur noch 32-Bit machen. In welchem Kaffeesatz hast du denn das gelesen? Klar kann es sein, dass Atmel demnächst jede Menge ATmega aus dem Programm schmeißt ATmega8-16PU und ATmega8L-8PU - Wird ersetzt durch ATmega8A-PU ATmega8-16AU und ATmega8L-8AU - Wird ersetzt durch ATmega8A-AU ATmega8-16MU und ATmega8L-8MU - Wird ersetzt durch ATmega8A-MU Sind schon sechs. Das ganze noch mit ATmega16, ATmega32, 64, 128. Die ATmega88 werden vermutlich auch bald durch ATmega88PA ersetzt usw usw usw
> Dass in näherer Zukunft (nächste 5 Jahre) alle 8-Bitter abgeschafft nein, das habe ich ja auch nicht geschrieben, aber das Angebot von den 8 Bittern wird erheblich reduziert. Der XMEGA wird bleiben, aber andere Typen werden einfach verschwinden. Wir setzen selbst einen Atmega in >20k ein, deshalb war ich heute auch etwas geschockt. > In welchem Kaffeesatz hast du denn das gelesen? mit Kaffee hat das eigentlich nichts zu tun. Frage einfach deinen Distri und schaue ihn dabei in die Augen. Das sagt alles.
Ich denke auch, daß es nur darum geht, den Wildwuchs quasi identischer AVRs zu bereinigen. Also alle ATmega*, ATmega*A, ATmega*P weg und nur jeweils den ATmega*PA übrig lassen. Die Abschaffung der 5V-Typen generell wäre aber schlecht. Das würde ne Menge Arbeit kosten, auf 3,3V umzustellen, ohne das die technischen Daten schlechter werden. Bei 3,3V hat man kaum noch Luft für saubere Analogsignale. Echtes Rail to Rail funktioniert nicht wirklich. Peter
Down schrieb: > Der XMEGA wird bleiben, aber andere > Typen werden einfach verschwinden. Also ausgerechnet der, den keiner braucht. Gibt doch schon reichlich andere 3,3V MCs. Peter
Peter Dannegger schrieb: > Also ausgerechnet der, den keiner braucht. Gibt doch schon reichlich > andere 3,3V MCs. Also ich finden die Xmega mehr als interessant. Alte Tools weiterverwenden, neue Features und mehr Rechenleistung bekommen
Peter Dannegger schrieb: > Die Abschaffung der 5V-Typen generell wäre aber schlecht. Es würde allen Kunden signalisieren: Finger weg von Atmel Produkten, weil ab und zu populäre Ware ohne langfristige Ankündigung und kompatiblen Ersatz eingestampft wird. Der sicherste Weg in die Pleite. Kaum anzunehmen.
So schlecht kann doch AVR bei Atmel nicht angesehen sein, immerhin haben sie in Ermangelung einer besseren Idee AVR32 danach benannt. Ganz im Bewusstsein, daß AVR einen guten Namen hat und in der Hoffnung, daß es ein bissl auf AVR32 abfärbt -- was wohl nicht ganz gelang.
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.