Hallo Zusammen, ich bin gerade dabei mir mit einem MSP1611 eine Heizungssteuerung zusammen zu basteln. Ich habe mich ein bisschen in die C-Programmierung (ohne Vorkenntnisse) rein gefuchst. Obwohl die Software ganz gut funktioniert, würde ich mich noch als ziemlichen Anfänger bezeichnen. Denn viele Beispielprogramme die man hier im Forum findet sind für mich noch böhmische Dörfer. Ich hab mit dem MSP angefangen weil ich mit jemanden unterhalten habe der nur mit MSPs arbeitet. Es gib bei mir noch einige Projekte ich zukünftig noch mit Mikroprozessoren machen will, für die ein MSP aber ein bisschen überdimensioniert wäre. Außerdem sind sie schlecht zu händeln weil es sie nur in SMD Bauweise gibt. Deshalb bin ich am Überlegen mich auch mal mit einem Anderen µC u beschäftigen. Ich weiß aber nicht welchen ich nehmen soll Atmel oder PIC o.ä. Wo ist der Unterschied? Welcher ist für Einsteiger am besten geeignet? Wie bekommt man die Programme in den µC. Kann man die auch in C programmieren, oder muss ich neu anfangen zu lernen? Ich hätte noch viel mehr Fragen, aber fürs Erste soll es erst mal gut sein. Ich hoffe ihr könnt mir ein paar Tipps geben. Danke Markus
Markus S. schrieb: > Wo ist der Unterschied? Atmel == Hersteller PIC == MPU-Familie von Microchip Die Frage ist also so nicht zu beantworten. Ausserdem hast du jetzt das Prädikat einen Flamewar angezettelt zu haben. Lässt sich wahrscheinlich nicht vermeiden.
Lehn dich entspannt zurück und kuck dir diesen Video an: http://www.youtube.com/watch?v=DBftApUQ8QI Dave beantwortet dir deine Frage. Übrigens: Ich benutze beide.
> Atmel (AVR) oder PIC Teufel oder Beelzebub? ;-) wenn du in C programmierst ist der unterschied nicht so groß, entscheide halt anhand der peripherie, die in den controller integriert ist. ich nutze die AVRs (atmel) weil die PICs mit denen ich zuerst angefangen habe absolut beschissen in assembler zu programmieren waren. dementsprechend schnell habe ich mich von denen wieder getrennt. im grunde ist das aber eine reine geschmackssache.
Ist genau wie der Unterschied Audi oder BMW. Oder Renault oder Peugot, oder Honda versus Yamaha. Beide vergleichbar, jeder hat spezifische Vor oder Nachteile unterschiedliche aber im allgemeinen ähnliche Produktpalette. Nimm das was du kennst, wo du schon eine Entwicklungsumgebung hast, wo du passende Versionen güstig bekommst, wo es die Varianten gibt, die das haben was du brauchst. Thats all.
1. Die Suchfunktion liefert dazu tausende Treffer 2. Diese Diskussion führt hier regelmäßig zu Forumskriegen. Die PICler schwören auf PIC, die AVRler auf AVR. Die Meinungen sind festgefahren - ein regelrechter Glaubenskrieg ist das. Ich würde mich hüten den hier erneut anzuzetteln. 3. Ganz grob gesagt ist es egal mit was man anfängt. Beide Seiten haben Pro und Contras. Nichts überwiegt wirklich - für einen Anfänger ist das ohnehin nicht relevant.
PIC ist besser.Mit AVR habe ich schlechte Erfahrungen gemacht.Aleine das mit den "fuses" ist schon zu verwirend.Und sie sind auch schwireger zu programieren weil es zu viele Befehle gibt und alles ist im algemeinen viel komplizierter als beim PIC.
Programist schrieb: > PIC ist besser.Mit AVR habe ich schlechte Erfahrungen gemacht.Aleine das > mit den "fuses" ist schon zu verwirend.Und sie sind auch schwireger zu > programieren weil es zu viele Befehle gibt und alles ist im algemeinen > viel komplizierter als beim PIC. Da fehlen wohl ein paar Anschläge, da der Schreiber viel zu schnell getippt hat und der PC ist leider nicht hinterher gekommen, um alle Buchstaben hier aufzuführen. Der Herr "Programist" hat auf jeden Fall meine Respekt - bei so vielen Anschlägen/s ;)
Habe vergessen zu sagen, dass wenn du beim AVR die fuses falsch setzt, dann war's das.Der chip ist dann nicht mehr zu gebrauchen.Beim PIC gib's das nicht.
Programist schrieb: > Habe vergessen zu sagen, dass wenn du beim AVR die fuses falsch setzt, > dann war's das.Der chip ist dann nicht mehr zu gebrauchen.Beim PIC gib's > das nicht. lol. Beschäftige dich mal mit AVRs. Ich hab bisher höchstens mal die CLK Fusen falsch gesetzt. Dann erzeugt man halt ein Taktsignal und setzt die Fuse zurück. Programist schrieb: > PIC ist besser. Kann man auch nicht sagen. Bleib mal konstruktiv. Programist schrieb: > Und sie sind auch schwireger zu > programieren weil es zu viele Befehle gibt und alles ist im algemeinen > viel komplizierter als beim PIC. Und warum? Weil sie mehr Features haben! Dein Text spricht eindeutig für Avrs. Achja fürs Pic braucht man übrigens ein nicht ganz günstigen Programmer. Da kann man sich kein usbasp für 5€ bauen.
Hi >Habe vergessen zu sagen, dass wenn du beim AVR die fuses falsch setzt, >dann war's das.Der chip ist dann nicht mehr zu gebrauchen. Verbreite bitte nicht solchen Blödsinn. Bisher musste ich noch keinen wegen den Fuses entsorgen (in 13 Jahren). >Und sie sind auch schwireger zu programieren weil es zu viele Befehle gibt Dann hast du noch keinen in den Fingern gehabt, der ein mehrfaches der paar Befehle eines AVR hat. Probiere es mal mit einem x86. Ich denke, auf deine inkompetente Meinung kann der TO verzichten. MfG Spess
Ich hab beide programmiert. Ich empfehle dir für private zwecke den PIC, obwohl sie sich wie vorhin beschrieben nicht sehr voneinander unterscheiden. Der Grund weswegen ich den PIC nehmen würde wäre folgender: Es gibt das PICKIT 2 oder auch das PICKIT 3 für wenig geld. Sehr robust, und man kann damit Debuggen. Außerdem behaupte ich dass man beim Reichelt mehr Auswahl hat und bei gleichen Kosten der Pic deutlich mehr kann( PIC24 für unter 2 euro :) ). Gruß Tarkan
Joachim schrieb: > Schön daß der Krieg AVR vs PIC endlich weitergeht. Cola und > Kartoffelchips stehen bereit. Ist ja auch schon wieder Freitag. Nimmt jemand Wetten an? Ich setze eine Tüte Alt-ICs auf Sieg AVR in der 33ten Runde, durch mehrfaches Einsetzen der "Deutscher Support hier im Forum"-Karte.
Programist schrieb: > PIC ist besser.Mit AVR habe ich schlechte Erfahrungen gemacht.Aleine das > mit den "fuses" ist schon zu verwirend.Und sie sind auch schwireger zu > programieren weil es zu viele Befehle gibt und alles ist im algemeinen > viel komplizierter als beim PIC. Das ist das, was Lehrmann Michael meint mit der festgefahrenen Position. Und dann noch so ein Unsinn: >Und sie sind auch schwireger zu programieren weil es zu viele Befehle gibt Ist völlig egal, auf wieviele Meinungen du hier noch wartest. Am Ende bist du genau so schlau wie vorher. Markus S. schrieb: > Wie bekommt man die Programme in den µC. Mit einem Programmieradapter. Das ist dann der Stoff für den nächsten Glaubenskrieg. Markus S. schrieb: > Kann man die auch in C programmieren Kann man. Sowohl AVR als auch PIC. Guck' dir mal die Tools zum Programmieren an, die Preise für einen Programmieradapter und das C-Tutorial in diesem Forum. Das ist nämlich sehr gut. Wenn du damit was anfangen kannst, hast du deinen Controller gefunden. Das wäre dann ein AVR. Weil das hier nämlich hauptsächlich ein AVR-Forum ist. Aber geh' auch mal in ein reines PIC-Forum. Vielleicht findest du da was besseres. Die Entscheidung kann dir hier keiner abnehmen. Ich hatte mal einen Kollegen, der wollte mich ständig überreden mir einen Ford zu kaufen. Ich wurde das Gefühl nie los, daß er das tat, damit er nicht mehr der einzige ist, der so eine Scheißkiste fährt. Bei den Controllern kommt mir das manchmal genauso vor. mfg.
Hier noch ein paar Fakten: http://www.mikrocontroller.net/articles/Mikrocontroller_Vergleich Kann mir einer erklären was Interrupt-fest heißt? Ich verstehe diese Zeile nicht:
1 | Das ist besonders bei AVR (ausser den Typen seit 2004: ATtiny2313 usw.) ein Problem. Architekturbedingt ist nur ein Teil der Ports bitweise schaltbar, kein Port kann mehrere Bits gleichzeitig interrupt-fest schalten. |
Ich finde wichtiger als der uC sind die verfügbaren Entwicklungsumgebungen. Bei AVR hast Du von Atmel gratis das AVR-Studio, mit Assembler, C-Compiler, Emulator, Programmer, Debugger etc... ohne irgendwelche Demo/Eval Einschränkungen. Du kannst aber auch mit Eclipse + AvrGcc (C-Compiler) arbeiten, es gibt ein AVR-Plugin für Eclipse..
Samuel K. schrieb: > Kann mir einer erklären was Interrupt-fest heißt? In dem Kontext: Wenn du an einem Port zwei Bits gleichzeitig umschalten willst, brauchst du mehrere ASM-Befehle (Read-modify-write). Wenn ein IRQ dazwischenfunkt, und ebenfalls den Port verstellt, geht das in die Hose. => Port-Pins immer einzeln nacheinander schalten, oder Interrupts aussenrum sperren, oder in IRQs auf direkte Portzugriffe verzichten.
Hi >Wenn du an einem Port zwei Bits gleichzeitig umschalten willst, brauchst >du mehrere ASM-Befehle (Read-modify-write). >Wen ein IRQ dazwischenfunkt, und ebenfalls den Port verstellt, geht das >in die Hose. >=> Port-Pins immer einzeln nacheinander schalten, oder Interrupts >aussenrum sperren, oder in IRQs auf direkte Portzugriffe verzichten. Neuere AVR können zumindest beliebige Bits eines Ports mit einem Befehl togglen. Bei den XMegas sollte noch einiges mehr drin sein. MfG Spess
> Schön daß der Krieg AVR vs PIC endlich weitergeht. > Cola und Kartoffelchips stehen bereit. lädst du mich ein? :) !bier ;)
>Ich verstehe diese Zeile nicht: >>Das ist besonders bei AVR (ausser den Typen seit 2004: ATtiny2313 usw.) ein >>Problem. Architekturbedingt ist nur ein Teil der Ports bitweise schaltbar, >>kein Port kann mehrere Bits gleichzeitig interrupt-fest schalten. Ist etwas unglücklich formuliert: Bei AVRs liegen einige Port-Register im Memory-Bereich und nicht im I/O Bereich. Bei Registern im Memory- Bereich kann nicht mittels Bit-Set oder Bit-Clear Funtion direkt auf einzelne Bits zugeriffen werden, sondern es muss ein Byte zuerst gelesen werden, das gewünschte Bit modifiziert und dann das Byte wieder zurückgeschrieben werden. (Read-Modify-Write Zugriff) Es sind also dann mindestens 3 Instruktionen erforderlich und zwischen diesen Instruktionen kann natürlich ein Interrupt auftreten. Das war aber für mich noch nie ein Problem. Aber man muss sich dem ganzen Bewusst sein, falls solche Register von Interrupt-Routinen und auch vom Hauptprogram verwendet werden und dann während den Zugriffen die Interrupts sperren... Das ganze betrifft natürlich auch jegliche Variabeln im RAM, besonders für solche die Grösser als 1 Byte sind! (auch beim PIC) siehe auch unter => Volatile => Atomic Zugriffe
spess53 schrieb: > Neuere AVR können zumindest beliebige Bits eines Ports mit einem Befehl > togglen. Klar, mit Write auf die PIN-Register. Erfordert etwas Umdenken, geht nicht bei den ganz alten AVRs, und der Compiler kann es nicht automatisch verwenden. Und wenn der Port-Zustand vorher nicht bekannt ist, ist ein kleines zusätzliches CLI/SEI einfacher und schneller, als sich vorher die richtige Maske raus-zu-XORen. > Bei den XMegas sollte noch einiges mehr drin sein. Die fehlen noch fast ganz im Mikrocontroller Vergleich-Artikel. Kennt sich da jemand gut genug mit aus, um die zu ergänzen? Obwohl, die PICs werden dort ja auch quer über alle Architektur-Varianten zusammengefasst...
also ich empfehle die AVR. Begründung: Irgend eien AVR kaufen irgend ein programmer aus irgendeinem IC oder einfach nur nen paar widerstände zusammenfriemeln Software umsonst von atmel runterladen assembler und C(++) DataSheet des Prozis Runterladen loslegen also kostet sehr wenig geht alles sehr schnell aus alten Bauteilen zu machen was man braucht Entwicklungsumgebung ist umsonst. wenns nicht gefällt mal das gleiche mit PICs machen
Uwe schrieb: > wenns nicht gefällt mal das gleiche mit PICs machen Geht genauso. Mit dem Unterschied, dass man sich die PICs früher kostenlos und portofrei von Microchip hat zuschicken lassen können. und mit den '51ern geht das auch. Und wenn man noch jung im Kopf ist, kann man auch drei und mehr Architekturen lernen.
Uwe schrieb: > Irgend eien AVR kaufen irgend ein programmer aus irgendeinem IC oder > einfach nur nen paar widerstände zusammenfriemeln Software umsonst von > atmel runterladen assembler und C(++) DataSheet des Prozis Runterladen > loslegen Echt? Dann mach das mal mit einem TCP-Stack, einer File-System-Lib, Grafik-LCD-Lib, etc. Wie? Gibt's nicht Ready-To-Rum bei Atmel fertig zum Runterladen? Sowas... Hatte ich mich bei Microchip so dran gewöhnt. Support inklusive. Hab mich schon immer gefragt, wie die AVRler auf die Idee kommen, irgendwelche Stacks und Librarys von irgendwo aus dem Netz zu saugen und auf ihre Plattform zu portieren. Möchte meine Zeit lieber in meine Applikation investieren. Und nicht damit, irgendwelche Standartanwendungen auf dem MCU zum Laufen zu bringen, die der Hersteller eigentlich mitliefern sollte, wenn er mir sein Zeug verkaufen will. Aber wenn das inzwischen anders ist lasse ich ich mich gerne belehren.
Samuel schrieb: > Achja fürs Pic braucht man übrigens ein nicht ganz günstigen Programmer. > Da kann man sich kein usbasp für 5€ bauen. Um die 36€ (PICKit 3 ICD) etwas weniger als der AVRDragon dafür robuster... Peter schrieb: > Ich finde wichtiger als der uC sind die verfügbaren > Entwicklungsumgebungen. Bei AVR hast Du von Atmel gratis das AVR-Studio, > mit Assembler, C-Compiler, Emulator, Programmer, Debugger etc... ohne > irgendwelche Demo/Eval Einschränkungen. > > Du kannst aber auch mit Eclipse + AvrGcc (C-Compiler) arbeiten, es gibt > ein AVR-Plugin für Eclipse.. MPLAB, die Einschränkungen des Compilers (gcc...) im Eval-Modus (nicht alle Optimierungen) sind in vielen Fälle vernachlässigbar. MPLAB X ist NetBeans (je nach Vorlieben das bessere Eclipse). Ein Vorteil der PICs sind imo die Libs (USB, Grafik, TCP/IP etc.) die vom PIC18 bis hin zum PIC32 verwendet werden können. Wenn man allerdings viel Rechenleistung und niedrigen Stromverbrauch haben will, gibt's das nur mit den AVR32 (auch verglichen mit div. Cortex-M3).
OK Leute, das war nicht meine Absicht hier einen Krieg anzuzettel :o) Ich danke allen die ihre Meinung geäussert haben. Ich werde versuchen mir alles in Ruhe anzusehn und dann entscheiden was ich nehme. Vielen Danke für Eure Hilfe. Gruß Markus P.S. ich bin für den Weltfrieden (auch hier im Forum)
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.