Würde ein PIC besser zu mir passen als ein AVR?

Das ist wahrscheinlich eine Frage, die nur ich beantworten kann, aber ich fürchte, mir fehlt die Erfahrung. Es ist relativ schwieriger, Atmel-Teile zu beschaffen, wo ich lebe. So musste ich kürzlich den AT Mega 128L aus den USA bestellen, weil er in meinem Land nicht erhältlich war (die 5V-Version Mega 128 war aber da). Die PICs sind breiter verfügbar. Hier scheinen sie auch günstiger zu sein.

Bisher habe ich nur mit AVRs Erfahrungen gemacht. Nicht, weil ich sie bevorzuge oder so, aber ich war/bin ein Anfänger und all die Recherchen, die ich gemacht habe, haben mich zu der Annahme gebracht, dass es nicht wirklich wichtig ist, wann man anfängt. Also kaufte ich mir einen AVR ISP MKII und Mega 168 und lernte darauf zu programmieren.

Die andere Sache, die mich wirklich zu den PICs hinzieht, ist ein massiv billigerer Debugger. Das PICKit 3 scheint In-Circuit-Debugging zu haben und der AVR ISP MKII, den ich besitze, nicht. Ich nehme an, ich könnte den AVR Dragon kaufen, aber ich habe gehört, dass er seine eigenen Probleme hat. Und der AVR JTAG ICE MKII kostet 300 US-Dollar. Ich habe darüber nachgedacht, aber dann habe ich angefangen, über den Kauf eines PICKit 3 nachzudenken.

Schließlich habe ich das Gefühl, dass ich wissen sollte, wie man auf beiden Plattformen programmiert. Ich denke, das wäre sehr vorteilhaft, weil ich in der Lage wäre, einen Controller auszuwählen, der für den Job am besten geeignet ist.

Meine Hauptanforderungen sind im Moment wirklich nur das, was es haben sollte

  1. SPI
  2. 3,3 V Eingangsspannung
  3. In-Circuit-Debugging
  4. Etwa 50 E/A-Pins (ich denke, 64-Pin-TQFP wäre großartig)

Würden Sie eher zustimmen, dass ein PIC aufgrund der Verfügbarkeit, des Preises und des billigeren Debuggers die bessere Option wäre?

Religionskrieg hier. Mein Name ist Kenny und ich bin ein PIC.
@kenny ich auch....
Sie erwähnen, dass es schwierig ist, bestimmte Teile Ihres Wohnortes zu bekommen, aber Sie haben nicht gesagt, wo das ist. FÜLLEN SIE IHR PROFIL AUS. Denken Sie daran, dass eine Höflichkeit für uns nicht für Sie gilt.
Ich komme aus Pakistan, Olin. Habe gerade das Profil ausgefüllt.
@Saad - Sie sollten beachten, dass ICE! = ICD. Microchip hat seine eigenen ICE-Produkte; Sie sind viel teurer als das picKIT: microchip.com/stellent/…
Ich schlage vor, dass Sie sich auch den MSP430 ansehen, der mit dem Launchpad (4,30 US-Dollar) oder dem ez430-USB-Stick (20 US-Dollar) debuggt werden kann. Ihre Spezifikationen sind nicht schwer zu erfüllen, also wählen Sie den lokal verfügbaren Prozessor.
@KevinVermeer Könnten Sie bitte den Unterschied zwischen ICE und ICD beschreiben? Oder vielleicht einen Link posten. Ich habe versucht zu suchen und konnte nicht viel finden, was es gut erklärt.
@Saad - Kurz gesagt, ICE kann vollständige Ablaufverfolgungen durchführen und Datenbedingungen unterbrechen, ohne den Zielprozessor zu beeinträchtigen, während ICD Software-Haltepunkte erfordert. Vollständige Frage hier , in der Hoffnung, dass die Community helfen kann. Ich habe ICEs verwendet, aber nichts, wo ein picKIT die Arbeit nicht erledigt hätte.

Antworten (3)

Ja, Sie müssen guten Code schreiben, der wartbar sein soll und es Ihnen leicht macht, Fehler zu erkennen, bevor Sie ihn ausführen. Das Debuggen ist jedoch immer noch Realität. In einem kleinen eingebetteten System können Sie Druckanweisungen nicht überall platzieren. Es gibt keinen Ort zum Drucken. Auf einem PC kann man den Code auch nicht in der gleichen Sprache testen, weil man es auf einem Mikrocontroller immer mit der Hardware zu tun hat, die auf dem PC nicht vorhanden ist.

Ein Simulator auf einem PC kann ein nützliches Werkzeug sein, aber je mehr Ihr Code mit externer Hardware interagieren muss, desto weniger nützlich wird er. Schließlich müssen Sie auf der realen Zielhardware testen und debuggen. Leute, die Ihnen sagen, dass sie das nicht tun oder dass Sie es nicht brauchen, haben offensichtlich nicht viele echte Mikrocontroller-Projekte durchgeführt.

Ich kenne die Atmel-Debugging-Umgebung nicht, kann sie also nicht mit der von PICs vergleichen. Beide Prozessorfamilien können machen, was Sie wollen. Wenn einer von ihnen in Ihrer Nähe eine bessere Verfügbarkeit hat oder Sie der Meinung sind, dass das Setup einen Kostenvorteil hat, entscheiden Sie sich dafür. Mit PICs werden Sie sicherlich nichts falsch machen, obwohl dies wahrscheinlich auf alle wichtigen Mikrocontroller-Linien zutrifft.

Genau das habe ich mir gedacht. Ich entwickle ein Board, in dem ich ungefähr 64 Leitungen steuere (natürlich nicht direkt von der MCU), über SPI mit einem CPLD und einer SD-Karte spreche und dann die Daten für die eigentliche Anwendung verarbeite. Ich denke, das Debuggen würde mir massiv helfen - weit mehr als Anweisungen drucken. Viele Leute möchten eine RS232-Schnittstelle in ihre Anwendung einbetten, damit sie "sehen" können, was vor sich geht, aber ich denke, ein Debugger ist die bessere Wahl.

Diese Fragen können das blaue Touch-Papier zum Leuchten bringen, also werde ich versuchen, das PIC vs. Atmel-Zeug zu vermeiden :-)

Es ist leistungsmäßig so wenig drin (ungeachtet dessen, was manche sagen mögen), dass es irrelevant wird, es sei denn, Sie treiben die Dinge an ihre Grenzen (in diesem Fall gehen Sie normalerweise sowieso nur ein Level nach oben) oder benötigen z. B. ein bestimmtes Peripheriegerät nur von einem der beiden bereitgestellt.
Bei den von dir gestellten Anforderungen sollte das kein Problem sein.

Bleiben also nur noch Preis und Verfügbarkeit. Wenn PICs in Ihrer Nähe billiger und leichter verfügbar sind, dann würde ich sagen, dass es eine einfache Wahl ist. Ich denke, im Allgemeinen ist der Preis / die Verfügbarkeit / die Langlebigkeit von PICs sowieso etwas besser als bei Atmel (nur basierend auf dem, was ich höre, nicht auf persönlicher Erfahrung mit Atmel, daher kann ich mich ziemlich irren).

Natürlich spricht nichts dagegen, auf Dauer nicht beides zu nutzen. Es ist gut, Erfahrung mit verschiedenen Teilen zu haben, aber wägen Sie Kosten und Nutzen des Mehraufwands unbedingt ab.

Es ist wirklich nicht meine Absicht, hier einen Krieg zwischen PIC und Atmel zu beginnen. Um ehrlich zu sein, habe ich das ziemlich satt, und ich habe mein Bestes versucht, meine Frage so zu formulieren, dass sie keinen Forumskrieg auslöst. :) Ich stimme in Bezug auf die Leistung zu und deshalb habe ich es nicht einmal erwähnt. Was halten Sie vom Debugger für PICs?
Ihre Frage war gut formuliert, ich habe nur Spaß gemacht :-) Ich benutze jetzt hauptsächlich einen ICD3, was ausgezeichnet ist. Das PicKit3 ist meiner Meinung nach ziemlich ähnlich, obwohl es ein paar Kinderkrankheiten hatte, denke ich, dass das jetzt alles geklärt ist. Ich habe auch ein PicKit2, das seinen Preis wert war - es hat einen seriellen Port-Emulator, zB PIC UART zu PC, und auch als einfachen Logikanalysator.

Verlassen Sie sich nicht zu sehr auf den Debugger, es ist die Krücke, die zu Faulheit führt.

Ich habe alle Tools, die für das In-Circuit-Debugging mit AVR (AVR JTAG ICE MKII) erforderlich sind, und ich verwende es nie. Stattdessen mache ich Folgendes:

  1. Verstehen Sie den Code
  2. Achten Sie darauf, robusten Code zu schreiben.
  3. Schreiben Sie Code, der auf dem PC getestet (und mit viel besseren Debuggern debuggt) werden kann, in einem Framework, das viel bessere Daten liefert, als in der eigentlichen Anwendung verfügbar sind.
  4. Fügen Sie print-Anweisungen ein, die #ifdef'ed sind, wenn etwas schief geht.

Die Vorteile, den Code wirklich zu verstehen und testbaren Code zu schreiben, können nicht hoch genug eingeschätzt oder durch einen Debugger ersetzt werden.

Tatsächlich verwende ich selten einen Debugger, selbst auf Plattformen, auf denen es sehr, sehr einfach ist (IDEA für Java oder Perl zum Beispiel).

Das Starten eines Debuggers kann Sie dazu verleiten, die Symptome von Problemen zu beheben, anstatt zu verstehen, was vor sich geht.

Sicher, Debugger haben ihren Nutzen, aber lassen Sie sich nicht davon leiten, es ist nicht so wichtig im Vergleich zu Ihren Fähigkeiten, der Verfügbarkeit von Teilen, der Software oder der Unterstützung durch die Community.

Davon abgesehen, wenn es andere Gründe für die Verwendung eines PIC gibt, machen Sie es, es ist wichtig, Erfahrung mit einer Vielzahl von Teilen zu sammeln.

Hier ist ein Überblick über einen Vortrag, an dem ich teilgenommen habe, der Ihre Ansicht unterstützt: andrewsterian.com/424/Lecture23.pdf - Er hat ein sehr ähnliches Prioritäts-/Debugging-Set, eine bemerkenswerte Ergänzung ist, dass jemand anderes sich den Code ansieht.
@Kevin: Der Vortrag, den du verlinkt hast, klingt, als hätte er eine Axt zu schleifen. Er weist das Debuggen als schwierig und zeitaufwändig einzurichten ab, unterstützt dieses Argument jedoch nicht. Er rät sogar, zuerst printf und blinkende LEDs zu verwenden, weil sie angeblich einfacher sind. Ich weiß nicht, welche Debugger er verwendet hat, aber das ist meiner Erfahrung nach völlig rückständig. Das Einstecken eines RealIce in den USB und das andere Ende in den ICSP-Port auf Ihrem Board ist ziemlich schnell und einfach, sicherlich schneller als das Anlöten von LEDs und das Modifizieren des Codes, um sie entsprechend anzusteuern.
Nun, meiner Erfahrung nach gibt es zwei Arten von Code, die komplizierten Algorithmen, die ein geeignetes Unit-Testing-Framework und geeignete Debugger benötigen, diese werden auf dem Host getestet, nicht auf dem Ziel, die andere Art von Code ist der einfache Hardware-Manipulationscode, der dies kann läuft nur auf der MCU und ist häufig zeitempfindlich, sodass Sie nicht mit einem Debugger einbrechen und ein nützliches Ergebnis erhalten können.
Würde ein PIC besser zu mir passen als ein AVR?
AntwortenHierDatenschutz-Bestimmungen1y, 0v