Für PIC hat man ja mit MPLAB X IDE, einem XC-Kompilern und dem PICkit3 alles was man zum Arbeiten braucht. Zwei Programme installieren, Projekt erstellen und schon kann mit einem Klick C kompilieren bzw. ASM assemblieren und das *.hex in Circuit (HV) auf den yC flashen. Zusätzlich kann man damit auch noch Simulieren und Debuggen. Geht das so auch bei AVR ohne ein Vermögen für Hard- und Software auszugeben? P.S. Ich will jetzt nicht’s von PIC vs. AVR hören, sondern einfach nur eine Antwort auf meine Frage.
Mark Q. schrieb: > Antwort auf meine Frage. Nein, das geht nicht. Ich brauche immer zwei Clicks zum Compilieren und auch zwei Clicks zum Flashen.
Mark Q. schrieb: > Geht das so auch bei AVR ohne ein Vermögen für Hard- und Software > auszugeben? Klar, Atmel Studio als IDE (kostenlos) und den AVR ISPmkII als Programmer (ca. 39€) bzw. die vielen Nachbauten. Im Prinzip kein Problem, mit geringstem finanziellen Einsatz die AVR-Familie zum Funktionieren zu bringen :-)
Für AVR gibt es unzählige In-Circuit Programmer, die preislich im Rahmen von 10 Euro oder weniger liegen, dazu eben den Chip. Alternativ Arduino oder artverwandter Clone davon, Kostenpunkt liegt auch unter 15 Euro. Software ist gratis (AVR-GCC), mit einer IDE kann ich dir nicht weiterhelfen (benutze keine)
Ok, alles gut un schön. Aber nun trennt sich der Spreu vom Weizen: wie sieht es mit ICD aus? Debugwire soll ja nicht so der bringer sein ... und geht das auch mit den ganzen (billigen) clones? Was ist das Pendant bei PICs?
Mark Q. schrieb: > Geht das so auch bei AVR ohne ein Vermögen für Hard- und Software > auszugeben? Ja, sogar wesentlich günstiger als PIC.
AVR hat doch fast mehr Debugprotokolle als Chiptypen. Und wenn man einen JTAG Debugger will, zahlt man mehr als fuer viele Cortex Boards inklusive Debugger und CDCACM Usart on Board...
G. H. schrieb: > Debugwire soll ja nicht so der bringer sein ... PICs sollen ja auch nicht so der Bringer sein ... Oder was genau wolltest du damit sagen? Dass du vom Hörensagen jemanden kennst, der damit schon mal nicht klar gekommen ist? Genauso kenne ich jemanden vom Hörensagen, der mit PICs schon mal nicht klar gekommen ist. Heißt das nun, dass PICs deshalb Mist sind? Bestimmt nicht. > und geht das auch mit > den ganzen (billigen) clones? Nein, Debuggen geht nur mit Atmel-Hardware. Da bist du mit einem AVR Dragon oder ATMELICE dabei, letzteres gibt es in drei Varianten: Beitrag "Re: Jtag ICE Programmer Emulator Debugger" Die neuesten Demo-Boards von Atmel (Xplained Pro) bringen gleich einen Debugger/Programmer mit, allerdings gibt es da kaum noch welche mit AVRs (nur ATmega256RFR2, welches ein Funk-Chip ist und ein neuerer Xmega), das meiste macht Atmel dort mittlerweile auf der ARM-Schiene. > Was ist das Pendant bei PICs? Keine Ahnung, habe ich viel zu lange nicht mehr in den Fingern gehabt. PIC ist ja ohnehin ein Sammelsuriums-Name, hinter dem sich in Wirklichkeit sehr viele verschiedene Architekturen verbergen.
Uwe B. schrieb: > AVR hat doch fast mehr Debugprotokolle als Chiptypen. Es sind derer drei (klassisch JTAG, Xmega mit PDI, debugWIRE bei den Tinys) oder vier, wenn du ARM mit SWD mitzählst. > Und wenn man einen > JTAG Debugger will, zahlt man mehr als fuer viele Cortex Boards > inklusive Debugger und CDCACM Usart on Board... Auch da lebst du hinter dem Mond, seit Atmel auf ihren XplainedPro den Debugger gleich mit draufpackt (CDC inklusive), und auf der anderen Seite seit sie das nackte Board vom ATMELICE für noch weniger verkaufen als den Dragon. Was sie allerdings nicht tun, ist eine massive Quersubventionierung der Demoboards, wie das manch anderer Hersteller tut, sondern man bezahlt offenbar so in etwa den Selbstkostenpreis dafür. (Die Atmel-ARMs dürfte man auch mit Lowcost-Dongles debuggen können, aber im Thread wurde explizit nach AVRs gefragt, insofern wäre das hier off-topic.)
Mark Q. schrieb: > Für PIC hat man ja mit MPLAB X IDE, einem XC-Kompilern und dem PICkit3 > alles was man zum Arbeiten braucht. Zwei Programme installieren, Projekt > erstellen und schon kann mit einem Klick C kompilieren bzw. ASM > assemblieren und das *.hex in Circuit (HV) auf den yC flashen. > Zusätzlich kann man damit auch noch Simulieren und Debuggen. > > Geht das so auch bei AVR ohne ein Vermögen für Hard- und Software > auszugeben? Ja, aber. IDE ist die von Visual Studio, also Windows only. Compiler ist GCC. Debugger ist was eigenes. Compilieren, flashen, ausprobieren: kein Problem. Debuggen: kommt drauf an. ISP ist eine reine Programmierschnittstelle. Debuggen geht damit nicht. Das haben alle (nicht-XMega) AVRs. Mit JTAG kannst Du programmieren und debuggen. Haben aber nur die größeren Chips ab 40 Pins. debugWire ist ein Krampf, das willst Du nicht. Diese Geschichte ist bei den PICs deutlich besser gelöst, vor allem, da Du Dich bei den AVRs durch falsches Setzen von Fuses (==Config Words) aussperren kannst. XMegas haben PDI. Das ist eine Programmier- und Debugschnittstelle. Es gibt unzählige Drittanbieter-Tools, wobei die meisten nur ISP können. Um richtig debuggen zu können, brauchst Du ein Atmel-Tool. fchk
Na da passt ja meine Leidgeschichte. MPLABX + XC8 sind nach gefühlten 5 Minuten auf der Platte. Nach weiteren 5 Minuten tackere ich Single-Step durch einen alten 18F2550 mit nem Pickit2 (derzeit für 8,48 bei ali). Versuch bei einem der Forenlieblinge: Atmega328. Hierzu muss ich erstmal Windows installieren. Als Linuxer heißt das VirtualBox. Die Installation vom Atmel Studio 6 ist sehr zäh. Liegt vielleicht an der VB, dachte ich. Installationsdauer im Vergleich zu PIC ewig. Dann der ominöser Fehler, dass der Treiber nicht installiert wird, wenn Windows nicht zuvor online war und irgendwelche Zertifikate geupdatet hat. Der Trick mit dem falschen Datum ging auch nicht. Also eine weitere 1/2 Stunde mit der Installation verbracht. Als Hardware das Atmel-ICE, wollte ich Single-Step durch den Mega. Pustekuchen. AS6 schaltet den Debugwire an, danach ging nichts mehr. Also probier ich mal ein FW-Update des ICE. Freude oh Freude, jetzt ist auch das ICE gebrickt. Entlastung für Atmel: Die VB war schuld. Nochmal Win + AS6, diesmal mit QEMU. Tada: ICE wieder entbrickt. Vielleicht jetzt Single-Step? Mit dem ersten 328 ging es nicht. Also ein Neuer: Tada jetzt sind 2 Megas mit "Debugwire on" unansprechbar. Letzter Versuch: Zweite Festplatte organisiert und Windows mit Update installiert. Jetzt das Atmel Studio. Kurwa masz, die Installation dauer ja wieder 1 h. Erfolg: Keinen. Die beiden ATmega328 habe ich einem Kumpel geschenkt. Der hat sie mit dem JTAG MKII unter Studio 4 wieder flott bekommen. Was sein soll weiss ich nicht. Flashen geht mit dem ICE richtig schnell. Auch sind die Signale mit dem Oszi betrachtet ordentlich sauber. Wenn Atmel damit Werbung machen will: "Are you kidding me?". Da gebe ich 60€ für den Atmel-ICE aus, weil ich mal debuggen will. Aber debuggen geht nicht. Insofern als Antwort auf deine Frage: Bis jetzt bin ich 60€ los, und mehr als Flashen kann ich die AVR nicht. Mein PK2 gabs für knapp 14€ (und brennt auch AVR unter avrdude).
AVR ist mehr für Hobbyisten und Amateure. Im Profibereich hingegen sind eher die PICs zu finden. Einfach Entscheidung also.
neuer PIC Freund schrieb im Beitrag #4183656: > Versuch bei einem der Forenlieblinge: Atmega328. Wobei er sicher nicht wegen seiner überragenden Debug-Fähigkeiten ein Forenliebling ist. ;-) Die meisten Hobby-Nutzer interessiert on-chip debugging ziemlich wenig, lehrt die Erfahrung. Sonst hätten sie wohl eher einen ATmega16 benutzt. Interessant finde ich die (ja nun mehr als einmal genannten) Klagen über debugWIRE: ich als nicht-Windowser habe damit eigentlich kaum Probleme gehabt, wenn ich es denn mal benutzt habe. Das geht im AVaRICE relativ flüssig. (Allerdings habe ich es noch nicht geschafft, den HID-Krempel vom ATMELICE ins AVaRICE zu bringen, sorry for this.) > Die Installation vom Atmel Studio 6 ist sehr zäh. Liegt > vielleicht an der VB, dachte ich. Nee, das liegt an diesem Riesenkolloss von Visual Studio, für den sich Atmel damals entschieden hat. (Wobei ein Eclipse, was als Alternative mal zur Debatte stand, nicht viel weniger zäh ist.) > Entlastung für Atmel: Die VB war schuld. Ja, die USB-Implementierung der VirtualBox ist Sche***e. Wenn du eine vernünftige VM haben willst, dann solltest du zu VMware greifen. Benutze ich auf Arbeit, wenn ich denn mal ein Windows brauche, und damit hat auch das olle Studio kein Problem. (Als kostenlose Version kannst du den einfachen VMware Player nehmen.)
:
Bearbeitet durch Moderator
Jochen schrieb: > AVR ist mehr für Hobbyisten und Amateure. Jaja, die Erde ist eine Scheibe, und der Mond wird mit der Stange geschoben. Aber diese Diskussion hatten wir bereits x-mal, die brauchen wir nicht erneut. Lass dir einfach gesagt sein, dass sich kein Hersteller auf dieser Welt von Hobbyisten und Amateuren finanzieren lassen könnte. Das allein genügt vollkommen um zu begreifen, wie unsinnig solche Behauptungen sind.
Jochen schrieb: > AVR ist mehr für Hobbyisten und Amateure. Im Profibereich hingegen sind > eher die PICs zu finden. Einfach Entscheidung also. ja ne is klar und Atmel hat die Dinger nur für Hobiesten entwickelt waaa... Mark Q. schrieb: > Für PIC hat man ja mit MPLAB X IDE, einem XC-Kompilern und dem PICkit3 > alles was man zum Arbeiten braucht. jo bietet AVR Studio4/6 auch > Zwei Programme installieren, Projekt > erstellen und schon kann mit einem Klick C kompilieren bzw. ASM > assemblieren und das *.hex in Circuit (HV) auf den yC flashen. jo bietet AVR Studio4/6 auch > Zusätzlich kann man damit auch noch Simulieren und Debuggen. jo bietet AVR Studio4/6 auch > Geht das so auch bei AVR ohne ein Vermögen für Hard- und Software > auszugeben? AVR Studio4/6 kostenlos und für die Brennerhardware mal paar € ausgeben ist, naja sollte drin sein, muss aber jeder selbst wissen. Denn nix ist umsonst und wenn im Umkehrschluss dadurch die SW kostenlos ist, ist das ein guter Kompromiss. Achso JA na klar. > P.S. Ich will jetzt nicht’s von PIC vs. AVR hören, sondern einfach nur > eine Antwort auf meine Frage. Einfaches JA
Nachtrag: chris schrieb: >> Zwei Programme installieren, Projekt >> erstellen und schon kann mit einem Klick C kompilieren bzw. ASM >> assemblieren und das *.hex in Circuit (HV) auf den yC flashen. > > jo bietet AVR Studio4/6 auch sogar nur eine SW für Sim/Debug/Brennen
Mach ich alles vom Programmer's Notepad aus dem WinAVR-Paket. Eingeben und ein Klick zum make und Brennen. Alles umsonst mit einem kleinen Download.
Jörg W. schrieb: > Die meisten Hobby-Nutzer interessiert > on-chip debugging ziemlich wenig, lehrt die Erfahrung. "Was der Bauer nicht kennt,..."
keine Ahnung was ihr für Probleme mit debug wire habt. Bei mir hat das immer 1a funktioniert. Habs schon bei allen möglichen attiny und atmegas verwendet. Ich glaube die meisten DW Probleme sind hausgemacht mit RC Glieder am Reset, die guten resetschaltungen aus den 80ern braucht heut kaum noch ein controller.
Jörg W. schrieb: > Die meisten Hobby-Nutzer interessiert > on-chip debugging ziemlich wenig, lehrt die Erfahrung. Das verwundert mich eigentlich die ganze Zeit. Da wird eine LED drangebastelt um zu sehen, ob der Code eine bestimmte Stelle erreicht, statt da einen Breakpoint hinzusetzen. Da heißt es: "im Simulator gehts aber ....". Ich bin nur mal versehentlich automatisch im Simulator gelandet, als der PICKit nicht angeschlossen war. Und bei den 16 Bittern, den PIC24, gibts mehrere Code und auch Datenbreakpoints. Die Zeiten, in denen man blind programmiert hat, sind eigentlich vorbei. Und das sagt einer, mal mit einer "Pipeline" von UV-Eproms im Löschgerät gearbeitet hat, weil ein ICE viel teurer als ein Auto war. MfG Klaus
Klkaus schrieb: >> Die meisten Hobby-Nutzer interessiert >> on-chip debugging ziemlich wenig, lehrt die Erfahrung. > > Das verwundert mich eigentlich die ganze Zeit. Ja, mich auch. Klar, es gibt immer Situationen, wo man den Echtzeitbetrieb nicht durch Anhalten des Programms unterbrechen darf, da muss man sich was einfallen lassen. (Cortex-ARMs sind da besser dran, dort ist der Debug Access Point so definiert, dass man auch zur Laufzeit mit untergeordneter Priorität vom Debugger aus auf den Bus kommt, sodass man sich bspw. globale Variablen parallel zur Ausführung ansehen kann.) Aber in vielen Fällen hilft es enorm, wenn man einfach direkt nachschauen kann, was da los ist. Ist ja nicht so, dass AVRs das nicht könnten, und auch den AVR Dragon als preiswertes Tool gibt's nun schon wenigstens 10 Jahre lang. Wenn das bei den Bastlern weiter verbreitet gewesen wäre, dann hätte sich der ATmega8 (und seine Nachfolger) vermutlich zugunsten eines ATmega16 weniger durchgesetzt, denn den gibt's nun auch schon seit 13 oder 14 Jahren, er hat JTAG (und damit Debugging), und es gibt ihn im steckbrettfreundlichen DIP-40-Gehäuse. Preislich spielen sie auch einigermaßen in der gleichen Liga.
> kein Hersteller auf dieser Welt von Hobbyisten und Amateuren finanzieren lassen
könnte
Und ich dachte noch, als ich die 8 Arduino Nano Bein Cinamann für unter
20€ bestellt hab, ob die wohl bei Atmel deshalb Sekt öffnen werden ;-)
Jochen schrieb: > AVR ist mehr für Hobbyisten und Amateure. Im Profibereich hingegen sind > eher die PICs zu finden. Einfach Entscheidung also. Das liegt (eher lag) daran, dass es die PIC schon viel länger gibt als die AVR und die PICs gibt es in tausenden von Varianten, so dass man eigentlich immer einen Typ findet, der am wirtschaftlichsten ist. Die Vielfalt bei den AVRs ist mittlerweile aber auch der Hammer ... einen 8Bit AVR in einem SOT25-5 Gehäuse zB ... Sehr cool :)
Mit welchen PIC vergleichen wir hier eigentlich den AVR? C Compilierung ist meines Wissens erst ab PIC18 so richtig sinnvoll verwendbar. Nach oben gibts dann noch PIC24 und PIC32 die eine etwas andere Klasse sind.
Steffen R. schrieb: > C Compilierung ist meines Wissens erst ab PIC18 so richtig sinnvoll > verwendbar. Was soll daran nicht sinnvoll sein? Der kleinste, den ich einsetze, ist ein PIC12F18xx. Passt gut als flexiblere Alternative zum 555. Und natürlich mach ich alles in C, das ist schneller programmiert als die Kondensatoren an einen 555 gelötet. Daß sich der Compiler für den kleinen Kerl möglicherweise mehr Mühe geben muß, ist ja nicht mein Problem. Ich selber werde mich aber nicht mit Carry oder Zero-Bit beschäftigen nur um mal mit 16 oder 32 Bit Integer zu rechnen. MfG Klaus
Steffen R. schrieb: > Mit welchen PIC vergleichen wir hier eigentlich den AVR? Ich würde mal sagen keinen konkreten. Das im Eröffnungspost genannte, gilt soweit ich weiß für alle von PIC12 bis PIC32 (vllt. auch PIC10, damit habe ich aber 0 Erfahrung). > C Compilierung ist meines Wissens erst ab PIC18 so richtig sinnvoll > verwendbar. Die neueren Enhanced Mid-Range PIC12/-16 habe einen C-Compiler freundlicheren Instruction Set. Auf den Mid-Range kann der XC8 aber auch was machen.
PICjaner schrieb: > Ich würde mal sagen keinen konkreten. Das im Eröffnungspost genannte, > gilt soweit ich weiß für alle von PIC12 bis PIC32... ...mal abgesehen davon, dass man für die kleineren Controller den passenden Header braucht.
Georg G. schrieb: > Nein, das geht nicht. Ich brauche immer zwei Clicks zum Compilieren und > auch zwei Clicks zum Flashen. Irgendwas machst du falsch, ich klicke immer auf "Start without Debuging", dann wird compiliert und anschließend geflasht. 1 Klick also.
:
Bearbeitet durch User
oder CTRL+ALT+F5, geht schneller als zur maus greifen und button finden+drücken
Ingo L. schrieb: > Georg G. schrieb: >> Nein, das geht nicht. Ich brauche immer zwei Clicks zum Compilieren und >> auch zwei Clicks zum Flashen. > Irgendwas machst du falsch, ich klicke immer auf "Start without > Debuging", dann wird compiliert und anschließend geflasht. 1 Klick also. Dein Ironiedetektor muß mal in die Werkstatt.
PP schrieb: > oder CTRL+ALT+F5, geht schneller als zur maus greifen und button > finden+drücken Ich habe eine Gamingtastatur, die hat mit den frei belegbaren Tasten auch seine Vorteile in der Arbeitswelt ;) Axel S. schrieb: > Dein Ironiedetektor muß mal in die Werkstatt. Eher der Ironieersteller von Georg G.
:
Bearbeitet durch User
Ingo L. schrieb: > Irgendwas machst du falsch Sorry, aber die Fragen des TO waren für mich so bescheuert, dass da nur eine entsprechende Antwort möglich war. Was soll der n+1te Flamewar über AVR oder PIC? Jeder wie er mag. Und manche nehmen sogar beides.
Mampf F. schrieb: > Das liegt (eher lag) daran, dass es die PIC schon viel länger gibt als > die AVR und die PICs gibt es in tausenden von Varianten, so dass man > eigentlich immer einen Typ findet, der am wirtschaftlichsten ist. > > Die Vielfalt bei den AVRs ist mittlerweile aber auch der Hammer ... > einen 8Bit AVR in einem SOT25-5 Gehäuse zB ... Sehr cool :) Hier möchte ich noch anmerken, das ein STM32F030 einiges günstiger als ein pic12F675 ist und wesentlich mehr bietet. von wegen wirtschaftlich ... wir ersetzten ihn gerade in einer applikation mit kleinen stückzahlen, wir können nur für den Chip schon 0.3€ einsparen! die 32-Biter werden über kurz oder lang die kleinen, vermeintlich günstigen 8-Biter ablösen .... so nun hab ich das Thema ganz auf die scheife bahn geworfen ... zur originalfrage kann ich nur sagen: Ja AVR's mit AtmelStudio und JTAGICE MKIII bekommen auch alles hin was die PICs mit PICKit3 können (ich bevorzuge das PICKit 2, läuft wesentlich stabiler wie das PICKit 3 ...). Und ob die Diskusion ob Linux, Windows, MAC ... ach Leute ...
solala schrieb: > JTAGICE MKIII bekommen auch alles hin was die PICs mit PICKit3 können Zu mehr als dem doppelten Preis. Kann man damit auch Chips programmieren, bei denen der Reset als IO verwenden wird?
solala schrieb: > wir ersetzten ihn gerade in einer applikation mit kleinen stückzahlen, > wir können nur für den Chip schon 0.3€ einsparen! Und das lohnt sich ernsthaft bei „einer applikation mit kleinen stückzahlen“? ;-) Bei einem Stundensatz von nur 60 Euro und einer „kleinen“ Stückzahl von 200 darfst du dann für die Änderung gerade mal eine Stunde brauchen …
PICjaner schrieb: > Zu mehr als dem doppelten Preis Das Geld für die Hilfsmittel vergiss mal schnell. Wenn ich durch bessere Technik 2 Stunden Zeit spare, ist das schnell wieder drin. Genauso zählt die Einarbeitungszeit. Wenn du 2 Wochen vertrödelst, bis du das Datenblatt richtig gelesen hast und endlich die Schönheiten der Architektur verstehst, hast du schon aufs falsche Pferd gesetzt. Lieber ein paar Euro mehr für die Hardware investiert und dafür Zeit gespart. Bei Stückzahlen in den Tausendern täglich sieht das anders aus. Nur, darüber reden wir hier ja weniger.
PICjaner schrieb: > Zu mehr als dem doppelten Preis. Pfffff.... zu dem Preisunterschied bekomme ich nicht einmal eine Tankfüllung Sprit für mein Auto. Also das ist nun wirklich ein Kindergartenargument. Ausserdem ist die Frage schon lange beantwortet: Ja.
Tja diese Rechnungen kenn ich ... Bei uns wird anderst gerechnet, wir leben den KVP in Preis und Funktion. Das Entwicklungs-Team ist ja zu 100% Angestellt, sind keine bezahlte Kundenprojekte da, arbeiten wir an sochen Änderungen welche das Produkt weiterbringen. Ich weiss, Luxusproblem, aber schön das wir das noch so machen können ... BTW ... kleine stückzahlen sind 25-50k ...
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.