Welches Programmiergerät für AVR und AVR32

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

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.

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).

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

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

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