Hallo, ich will für meine zukünfigen Projekte AVR Controller einsetzen, da man für diese im Netz sehr viel findet. Das was mich bis jetzt noch von denen abgehalten ist, ist dass das Programmieren/Debuggen über JTAG teuer ist(Programmiergerät). Kennt jemand einen Debugger der kostengünstig ist, aber trotzdem AVR und AVR32 programmieren kann? Hab diesen debugger gefunden: http://elmicro.com/de/avrjtag.html kann aber nur Atmegas debuggen. Grüße Martin
Martin schrieb: > Hab diesen debugger gefunden: http://elmicro.com/de/avrjtag.html kann > aber nur Atmegas debuggen. Das ist ein Nachbau des allerersten AVR JTAG ICE. Nicht kaufen, der kann NUR DIE ANGEGEBENEN AVRs, und das sind schon recht alte. Die aktuellen AVRs kann er nicht! Du wirst Dich zwischen einem JTAG ICE3 und dem neueren Atmel ICE entscheiden müssen. Kosten beide so 120€. fchk
Vielen Dank für die Antwort Frank. Werde dann mal vorerst mit ISP Programmieren und später dann vielleicht ein JTAG Programmiergerät kaufen. Bei den PIC wäre der Debugger billiger, aber diese sollen angeblich nicht so bequem zum programmieren sein. Grüße
Martin schrieb: > Vielen Dank für die Antwort Frank. Werde dann mal vorerst mit ISP > Programmieren und später dann vielleicht ein JTAG Programmiergerät > kaufen. > > Bei den PIC wäre der Debugger billiger, aber diese sollen angeblich > nicht so bequem zum programmieren sein. Doch klar. Wenn Du in C programmierst, ist das kein großer Unterschied. Mit der gewöhnungsbedürftigen Architektur der 8-Bit PICs (und nur dieser!) kommst Du nicht in Berührung. Und die 16 und 32 Bitter sind ohnehin eine ganz andere Sache mit völlig anderen Architekturen. Der Vorteil bei Microchip ist die Peripherie: Du hast eine größere Bandbreite, mehr Auswahl, und die Peripherieeinheiten sind auch leistungsfähiger. Beispiel UARTs: Viele haben Support für LIN, ab den 16 Bittern auch Support für IRDA und Hardware-Flusskontrolle. Beispiel SPI: Ab den 16 Bittern hast Du Support für Framed SPI und größere Wortlängen. Beispiel Ethernet: Die mit Abstand billigste Möglichkeit für einen Ethernet-Knoten ist der PIC18F67J60. Einfacher, billiger und kleiner geht es nicht. Prozessor, Ethernet MAC, Ethernet PHY und Speicher und sonstige Peripherie in einem Chip. Beispiel CAN: Viele AVR-Leute hühnern hier mit einem Mega 8 und einem MCP2515 herum. Ein PIC18F26K80 ist nur wenig teurer als der MCP2515, enthält eine verbesserte Variante des MCP2515 und hat zudem den Prozessor schon gleich mit drin. Schön blöd, wer da mit AVR arbeitet. Sicher, die AVR-Architektur hat auch ihre Vorzüge. Die Peripherie ist es allerdings nicht. fchk
Frank K. schrieb: > Schön blöd, wer da mit AVR arbeitet. An dem Tag an dem es einen freien (oder zumindest einen kostenlosen vollwertigen) Compiler für PIC gibt wird diese Architektur interessant. Vorher nicht.
Martin schrieb: > Das was mich bis jetzt noch von > denen abgehalten ist, ist dass das Programmieren/Debuggen über JTAG > teuer ist Man kommt mit der richtigen Herangehensweise auch komplett ohne Debugger aus. Gerade bei so einfachen Architekturen die auch zu verhältnismäßig gut überschau- und verstehbarer Software führen wird das unverhältnismäßig überbewertet und in der Praxis ist es meist auch überhaupt nicht sinnvoll anwendbar. Wenn Du diese Anforderung streichst bist Du schon mit einer einstelligen Eurosumme dabei und kannst sofort loslegen. Meine wichtigsten Debug-Instrumente sind ein Oszilloskop, geeignete Instrumentierung meines Codes und ggf. ein serielles Terminal.
:
Bearbeitet durch User
Was für ein Programmiergerät empfehlt ihr, um AVR32, Tinys und die neueren Atmegas zu programmieren? Bernd K. schrieb: > Wenn Du diese Anforderung streichst bist Du schon mit einer einstelligen > Eurosumme dabei und kannst sofort loslegen. Was für ein Programmiergerät ist das?
Martin schrieb: > Was für ein Programmiergerät empfehlt ihr, um AVR32, Tinys und die > neueren Atmegas zu programmieren? Über alle Mikrocontroller- und FPGA-Architekturen hinweg bist Du mit den Originaltools des jeweiligen Herstellers am Besten aufgehoben. Das sind nicht immer die billigsten, meist aber die problemlosesten. Der Atmel AVRISP mkii kann ISP, PDI und TPI und damit alle relevanten Protokolle zum Programmieren von AVR/AVR32. Debuggen ist hiermit nicht möglich, auch nicht über PDI, das das im Prinzip kann. Funktioniert mit Target-Spannung von 5.5V bis hinunter zu 1.8V. Kostenpunkt etwa 30€. > Bernd K. schrieb: >> Wenn Du diese Anforderung streichst bist Du schon mit einer einstelligen >> Eurosumme dabei und kannst sofort loslegen. > > Was für ein Programmiergerät ist das? Schrott. Kann wahrscheinlich nur ISP, verwendet den nicht standardkonformen VUSB Software-Lowspeed-USB-Hack, hat keine richtige Schutzbeschaltung und keine Levelshifter für variable Targetspannungen. Wegwerfelektronik. fchk
Martin schrieb: > Was für ein Programmiergerät ist das? Für ATTiny und ATmega tuts bereits irgendein chinesischer USBAsp-Nachbau für 4€. Hab selber einen, nutze ihn unter Linux, dort benötigt er keinerlei Treiber und spielt problemlos mit avrdude zusammen. Um erste Schritte mit ATTiny und ATMega zu machen und den Einstieg zu finden ohne großes Geld auszugeben ist das vollkommen ausreichend. Wenn es 100% Avrisp-mk2-kompatibel sein soll (jedoch ohne dessen Hardware-Unzulänglichkeiten) und unter Windows und AtmelStudio6 und ohne Treibergefrickel verwendet werden soll dann empfehle ich (hab ich selbst im Einsatz) den Diamex-ALL, jedoch kommen wir hier schon in den 30€-Bereich aber den Diamex ziehe ich jederzeit dem AvrISP-Mk2 vor (habe beide hier rumliegen). Die AVR32 haben meines Wissens nach einen Bootloader schon ab Werk drin, hier geht evtl eine reine Softwarelösung. Jedoch hab ich AVR32 noch nicht verwendet, ich weiß nicht ob ich mir die überhaupt noch antun sollte, ich strecke gerade die Fühler in Richtung ARM aus und da ist man auch schon recht preisgünstig dabei (die Lernkurve nicht mitgerechnet).
:
Bearbeitet durch User
Bernd K. schrieb: > Wenn es 100% Avrisp-mk2-kompatibel sein soll (jedoch ohne dessen > Hardware-Unzulänglichkeiten) und unter Windows und AtmelStudio6 und ohne > Treibergefrickel verwendet werden soll dann empfehle ich (hab ich selbst > im Einsatz) den Diamex-ALL Verwendest du den Diamex-All auch unter Linux? Möchte schon, dass es auch Linux kompatibel ist, da ich dort programmieren will.
Martin schrieb: > Was für ein Programmiergerät empfehlt ihr, um AVR32, Tinys und die > neueren Atmegas zu programmieren? Atmel ICE: http://www.reichelt.de/AT-ATMEL-ICE/3/index.html?&ACTION=3&LA=446&ARTICLE=143878&artnr=AT+ATMEL-ICE&SEARCH=Atmel+ICE ein Programmer für alle Atmel Controller http://www.atmel.com/tools/atatmel-ice.aspx
1 | Atmel-ICE supports: |
2 | |
3 | Programming and on-chip debugging of all Atmel AVR 32-bit MCUs on both JTAG and aWire interfaces |
4 | Programming and on-chip debugging of all Atmel AVR XMEGA® family devices on both JTAG and PDI 2-wire interfaces |
5 | JTAG and SPI programming and debugging of all Atmel AVR 8-bit MCUs with OCD support on either JTAG or debugWIRE interfaces |
6 | Programming and debugging of all Atmel SAM ARM Cortex-M based MCUs on both SWD and JTAG interfaces |
7 | Programming of all Atmel tinyAVR® 8-bit MCUs with support for the TPI interface |
Was gerne vergessen, unterschlagen, nicht gesagt, nicht beachtet wird: Sowohl JTAG ICE MKII als auc der neue ATMEL ICE funtionieren nicht unter AVR Studio 4.x (und darunter dann wohl auch nicht).
Berichtigung der vorangegengenen Post: Was gerne vergessen, unterschlagen, nicht gesagt, nicht beachtet wird: Sowohl JTAG ICE MK III als auch der neue ATMEL ICE funtionieren nicht unter AVR Studio 4.x (und darunter dann wohl auch nicht).
Na wenn du unter Linux arbeiten willst, ist doch die PIC-Schiene viel besser geeignet. MPLABX + 15€ Pickit3-Clone aus China, und du kannst source-level debuggen. Habe gerade ein Stück Code vom ATtiny44A auf einen PIC16F1454 portiert. Der kostet bei Reichelt gerade mal 5ct mehr, hat dafür aber 3 HW-Breakpoints. 2 Breakpoints kann ich da setzen, und der 3. ist für single-step reserviert. Ob das der Tiny auch kann? Zumindest hast du hierzu als Einstiegshürde 40€ für die Platine des neuen ICE. Und der XC8 schlägt sich nicht allzu schlecht. Auf dem PIC sind 2.88% vom Speicher belegt, und das bei der Speed-Einstellung. Der avr-gcc verlangt mit -Os für die gleiche Problemlösung 13.5%. Erfreulicherweise läuft auch die ISR schneller. Die fehlende Push-Pull-Orgie bringt es. Beim Tiny gehen 35 Cpu-Takte für nichts drauf. Der PIC braucht hier maximal 33 Cpu-Takte gesamt. Auch kann ich durch die PLL beim PIC einen höheren Systemtakt fahren. Die 5mA Stromaufnahme bei 12MHz Cpu-Takt stören hier nicht. Und demnächst werde ich mal den USB-Teil des 1454 ausprobieren. Damit dieses unsägliche vusb-Gefrickel ein Ende hat. Da kommt der PIC wiederum günstiger, weil der ohne Quarz auskommt. Und das im achsogeliebten DIL Gehäuse bei 5V. Ein weiterer Pluspunkt ist die Tatsache, bei Reichelt bekommst du viel mehr PICs zur Auswahl als AVRs. P.S. Mit dem Pickit2 kannst du Tinys und Megas ISP programmieren. Als Bastler kannst du dir diesen sogar selbstbauen.
Also, was ich sehr empfehlen kann ist dieser Programmer. Ich hatte den letzte Woche gekauft gehabt und bin damit sehr zufrieden. http://www.ebay.de/itm/Programmer-fur-alle-AVR-ATMEL-XMEGA-ATMEGA-ATTiny-mit-ISP-TPI-und-PDI-/161509987962?pt=Wissenschaftliche_Ger%C3%A4te&hash=item259abed67a
Stefan schrieb: > Also, was ich sehr empfehlen kann ist dieser Programmer. Ich hatte den > letzte Woche gekauft gehabt und bin damit sehr zufrieden. > > http://www.ebay.de/itm/Programmer-fur-alle-AVR-ATMEL-XMEGA-ATMEGA-ATTiny-mit-ISP-TPI-und-PDI-/161509987962?pt=Wissenschaftliche_Ger%C3%A4te&hash=item259abed67a Würde der Threadersteller denn auch damit sehr zufrieden sein? Kann der den zB auch AVR32 programmieren und debuggen?
Er hatte doch geschrieben: Martin schrieb: > Vielen Dank für die Antwort Frank. Werde dann mal vorerst mit ISP > Programmieren und später dann vielleicht ein JTAG Programmiergerät kaufen. Mit einem ISP/TPI/PDI Programmer wäre er doch gut bedient.
Martin schrieb: > Verwendest du den Diamex-All auch unter Linux? Möchte schon, dass es > auch Linux kompatibel ist, da ich dort programmieren will. Der liegt in der Firma (und da gibts nur Windows), da hab ich das noch nicht ausgiebig getestet. Was ich jedoch sagen kann ist daß er auch dort von avrdude anstandslos unterstützt wird (genau wie der avrisp-mkII) und zwar über den libusb-Filtertreiber. Daraus schließe ich daß er unter Linux ebenso problemlos funktionieren wird. Entsprechende Forum-Posts anderer Nutzer bestätigen das.
neuer PIC Freund schrieb im Beitrag #3932996: > Na wenn du unter Linux arbeiten willst, ist doch die PIC-Schiene viel > besser geeignet. > > MPLABX + 15€ Pickit3-Clone aus China Ja klar. 500€...1000€ für IDE und Compiler hinlegen aber dann an der Hardware knausern. Microchip will ganz offensichtlich nichts mit Privat/Hobby-Anwendern zu tun haben, das kommunizieren die ganz unmißverständlich über den Preis der Werkzeuge. Nun gut, sollen sie. Daß eben diese verprellten Hobbyisten oft auch die Entscheidungen in den Firmen beeinflussen in denen sie arbeiten ist dann aber deren Problem. Bei Atmel gibts alle benötigte Software selbstverständlich kostenlos, der offizielle(!) Compiler ist sogar freie Software. Die Linux-Unterstützung für die AVRs ist exzellent: Eclipse + AVR-Plugin + avr-gcc + avrdude alles freie Software und alles aufeinander abgestimmt, kein umständliches Gefrickel, keine Einschränkungen, installieren und läuft out of the box.
Bernd K. schrieb: >> MPLABX + 15€ Pickit3-Clone aus China > > Ja klar. 500€...1000€ für IDE und Compiler hinlegen aber dann an der > Hardware knausern. Meep. 6 setzen. MPLAB und MPLABX sind kostenlos und waren es schon immer. Die Compiler gibts in kostenlosen Versionen, wo nur die höheren Optimierungsstufen abgeschaltet sind. Keine Größenbeschränkung, keine anderen Einschränkungen. Die vollen Optimierungen sind wichtig, damit Du statt eines bestimmten PICs den nächstkleineren nehmen kannst, um ein paar Cent in der Massenproduktion zu sparen. Bei Einzelstücken nimmst Du einfach den PIC mit dem größten Flash aus der entsprechenden Serie, und gut ist. Ja, mir wäre komplett freie Compiler auch lieber, und ja, Microchip hat sich dadurch in der Vergangenheit auch einiges verbaut, aber mit der aktuellen Situation kann man eigentlich ganz gut leben. Das eigentliche Problem sind die Idioten, die Hörensagen verbreiten, die nicht bzw nicht mehr stimmen, und die nur den PIC16C54 von 1978 (da hieß Microchip noch General Instruments) kennen und nicht die aktuellen PIC-Familien bis hin zu dsPIC33EP und PIC32. PS: die Compiler für PIC24/dsPIC und PIC32(MIPS16) sind auch nur gcc-Derivate. So viel dazu. > der offizielle(!) Compiler ist sogar freie Software Du weißt aber schon, dass der eigentliche offizielle Compiler der von IAR ist? IAR saß bei der Entwicklung der AVR-Architektur mit am Tisch und hat den Befehlssatz mit definiert, damit deren Compiler optimalen Code erzeugen kann. Das tut er bis heute und ist weitaus besser an die Architektur angepasst (oder andersherum) als der gcc, der eigentlich für 32 Bit Prozessoren entwickelt wurde und wird. > Die Linux-Unterstützung für die AVRs ist exzellent: Und schon mal ein MPLABX unter Linux oder OSX gesehen? Na? Wie kannst Du da vergleichen? fchk
Frank K. schrieb: > Die Compiler gibts in kostenlosen Versionen, wo nur die höheren > Optimierungsstufen abgeschaltet sind. Ja, komplett ohne Optimierung, also ungefähr das Äquivalent von gcc -O0 wo der Code doppelt so groß und halb so schnell wird weil zwischen jeder zweiten Instruktion erst nochmal ne komplett unnötige Runde Spilling und Filling eingebaut wird. Wenn ich sowas sehe hab ich schon keine Lust mehr. Man geht im Hobby oftmals Kompromisse ein aber jeder hat eine Grenze, jeder hat andere Prioritäten, für mich persönlich zum Beispiel ist ein Compiler der absichtlich auf -O0 kastriert ist nicht akzeptabel, vor allem in Anbetracht von existierenden freien und hochoptimierenden Compilern für andere Architekturen. > Und schon mal ein MPLABX unter Linux oder OSX gesehen? > Na? Wie kannst Du da vergleichen? Ist leider in der free-Version nur ein unterirdischer Compiler dabei und damit steht und fällt alles. Lieber noch würd ich mich zwingen lassen nur mit vim und make auf der Kommandozeile arbeiten wenn dann wenigstens ein ordentliche Compiler vorhanden wäre, aber Hochglanz-IDE (ist übrigens auch nur Netbeans, also keine Alientechnologie, selbe Liga wie Eclipse), ohne ordentlichen Compiler macht das alles keinen Spaß.
Frank K. schrieb: > PS: die Compiler für PIC24/dsPIC und PIC32(MIPS16) sind auch nur > gcc-Derivate. So viel dazu. Dann nehm ich an daß gemäß Lizenzbestimmungen der Sourcecode veröffentlicht wurde? Wo gibts diese Compiler dann in der unlimitierten Version?
Bernd K. schrieb: > Frank K. schrieb: > >> PS: die Compiler für PIC24/dsPIC und PIC32(MIPS16) sind auch nur >> gcc-Derivate. So viel dazu. > > Dann nehm ich an daß gemäß Lizenzbestimmungen der Sourcecode > veröffentlicht wurde? Wo gibts diese Compiler dann in der unlimitierten > Version? http://www.microchip.com/pagehandler/en_us/devtools/mplabxc/ Zum Ende unter "Source Archives" scrollen. Viel Spaß beim Bauen. fchk
Sorry wollte nicht so eine große Diskusion lostreten. Ok scheinbar kann man mit dem Pickit3 auch PIC32 programmieren und debuggen, doch hab gelesen, dass diese die auch teilweise kaputt machen ;) Wie werden die kleinsten PICs programmiert, bei AVR werden die ja über eine einzelne Leitung programmiert. Tendiere eher zu AVR, da im deutschen Raum einfach extrem viel darüber gefunden wird. Kaj G. schrieb: > Atmel ICE: > http://www.reichelt.de/AT-ATMEL-ICE/3/index.html?&ACTION=3&LA=446&ARTICLE=143878&artnr=AT+ATMEL-ICE&SEARCH=Atmel+ICE Ist mir viel zu teuer um damit anzufangen. Stefan schrieb: > Also, was ich sehr empfehlen kann ist dieser Programmer. Ich hatte den > letzte Woche gekauft gehabt und bin damit sehr zufrieden. > > Ebay-Artikel Nr. 161509987962 Mit dem kann man aber keine AVR32 Programmieren.
Martin schrieb: > Sorry wollte nicht so eine große Diskusion lostreten. > Ok scheinbar kann man mit dem Pickit3 auch PIC32 programmieren und > debuggen, doch hab gelesen, dass diese die auch teilweise kaputt machen Das Problem sitzt meist vor der Tastatur. Wer 5V auf einen 3.3V PIC gibt, ist eben selber schuld. > Wie werden die kleinsten PICs programmiert PICs brauchen zwei IO-Pins (PGC+PCD) plus Reset(!MCLR). Die meisten PICs haben mehrere PGC+PCD Paare, so dass Du das Paar wählen kannst, das keine Funktionalitäten blockiert und/oder layouttechnisch am besten passt. Der ICSP funktioniert immer, Du kannst Dich normalerweise nicht wie bei AVRs wegen einer falschen Konfiguration (bei AVRs "Fuses", bei PICs "Config Words") aussperren, egal wie dumm Du Dich anstellst. Die ICSP-Schnittstelle gibts bei allen PICs, egal ob 8, 16, 32 Bit, und Du kannst programmieren UND debuggen. >, bei AVR werden die ja über > eine einzelne Leitung programmiert. Nein. Du hast wohl das DebugWire im Kopf, was eine reine Debug-Schnittstelle ist (ist im Übrigen ein Krampf). dW haben nur neuere AVRs, nicht die alten Mega8/16/32. Programmieren tust Du über ISP, das wie SPI funktioniert, aber teilweise andere Pins belegt (feste Pins, Du hast keine Auswahl wie bei PICs). Du hast SCK, MOSI, MISO, und brauchst noch !RESET, das zum Programmieren auf low gezogen wird. ISP ist eine reine Programmierschnittstelle, debuggen kannst Du darüber nicht. > Tendiere eher zu AVR, da im deutschen Raum einfach extrem viel darüber > gefunden wird. Ja, die AVR-Fanboys sind hier in der Überzahl. Beides hat seine Sonnen- und Schattenseiten, und die siehst Du erst, wenn Du wirklich damit gearbeitet hast. Ich kenne beides und kann Dir sagen: immer schön geistig flexibel sein. Wenn Du nur einen Hammer hast, sieht alles wie ein Nagel aus. Für den Anfang hätte ich Dir PIC24 ans Herz gelegt, weil der am einfachsten zu handhaben ist und ziemlich viel kann, aber die Entscheidung musst Du selber treffen. fchk
Vielen Dank Frank und auch den anderen die sich bei der Diskussion beteiligt haben.
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.