Am einfachsten anfangen ?

[PICture]

Hallo!

Vielen Dank für Eure Hilfe und verständliche Erklärungen.

Leider ist für mich komplizierte Denkweise unannehmbar, weil ich als Minimalist geboren bin. Ich werde sicher nie "ldi r16,(0 << EEPM1) | (0 << EEPM0)" anstatt "ldi r16,0" schreiben können. Das verwirrt mich so, das ich, wie gewöhnt, nur mit Befehlsatz und Registerliste für Prozessor/µC auf dem Tisch vor mir, sicher nie mein PAD in Quellcode übersetzen kann.

Beim Macroassembler scheint mir leider jeder Macro ein zuaätzlicher Befehl zu sein, den man sich merken muss. Bei mehreren Programmen wird es mich auch sicher zu Verwirrung und unnötiger Zeitverlust führen, wenn ich nach ein paar Jahren eine Kleinigkeit im Programm ändern möchte.

Deshalb bleibt mir nur mich herzlich bei allen Helfer zu bedanken übrig und weiterhin mit Spass PIC's in ASM programmieren. Jetzt ist mir aber ganz klar, das die Fa. ATMEL die AVR's nicht für mich herstellt.

[Besserwessi]

Die Schreibweise für die Bits ist eigentlich unabhängig von Prozessor - das sollte auch beim PIC, ARM, PowerPC, 8086, Z80, 68000 und anderen genau so gehen. Beim 4004 hatte man ggf. die Schreibweise noch nicht und musste zu Fuß die Zahlen zusammenstellen. Im Prinzip könnte man es aber auch da genau so machen. Die Schreibweise sollte als dsa kleinste Problem beim Umstieg vom PIC zum AVR sein.

Der Atmel Assembler hat sogar schon _BV(x) als (1<<x) definiert. Man kann also die Umrechnung von Bit Nummer in Bitwert auch damit machen. Nur die 0 muss man dann wohl als 0 schreiben oder als 0*x.

[Richard]

"ldi r16,(0 << EEPM1) | (0 << EEPM0)"

Ist ja auch etwas "krank" diese Schreibweise. Zumindest auf einer Deutschen Tastaturt bei der die benötigten Tasten ewas weit auseinander liegen..."ldi r16,0" ist da weitaus bequemer / Anwender freundlicher. -) Andererseits, ist das aber beinahe immer so wenn der Prozessor Typ gewechselt wird. Andere Syntax, andere Register, andere Speicher Verwaltung u.s.w. Da muss (?) man halt durch. Ich habe da auch keinen Bock drauf, PIC's habe ic nur in ASM Programmiert die AVR jetzt nur noch in Basic. Zur Not mit inline ASM wenn es denn sein muss. Damals als noch der gute alte c-64 mein Hauptrechner war, hatte ich mir eine extra minni Zusatz Tastatur für solche Eingaben wie hex Zahlen u.s.w. gebaut. Die konnte mit einem Tastendruck Sonderzeichen, Hex, Bin auf dem Bildschirm "zaubern".

Gruß Richard

[PICture]

Hallo Besserwessi !

Es tut mir leid, falls ich dich enttäuscht habe, aber ich hatte nie auf AVR's umsteigen wollen, sondern nur bisher geglaubt habe, dass sich meine mit Spass gebaute Spielzeuge mit AVR's hardwaremässig einfacher aufbauen und auch mit Spass in ASM programmieren lassen. Ich habe etwas neues nicht zum ersten mal im Leben versucht und mit negativen (für mich eben immer positiven) Ergebnis rechtzeitig verworfen. Es ist für mich ganz normales und kein frustierendes Vorgehen.

Hoffentlich wird dieser Thread trotzdem für jemanden nützlich.

[Besserwessi]

Von der Hardware Seite nehmen sich die PICs und AVRs vermutlich nicht viel - mal geht der eine mal der andere etwas besser, und oft geht es gleich gut mit beiden. Bei der Peripherie scheinen die PICs sogar eher mehr Auswahl zu haben, da sind die AVRs doch alle sehr ähnlich - was für die Programmierung aber wieder an Vorteil ist. Wenn man den einen kennt, braucht man den anderen eher nicht. Da wäre dann eher eine Nummer Leistungsfähiger (z.B. dsPic33 oder ARM ) interessant.

Bei der Progammierung in ASM macht es die einfachere Struktur bei den AVRs es aber eher einfacher. Nach etwas Gewöhnung sind die 32 fast gleichwertigen Register eine echte Erleichterung. Mir viel das eventuell besonders leicht, weil ich davor etwas mit dem 68000 (mit 16 universellen Registern wenn ich mich richtig erinnere) gemacht hatte. Für kleine Programme kann man sogar das RAM ganz (außer für den Stack) unbenutzt gelassen und alles in den Registern halten.

[PICture]

Natürlich !

Schade, das AVR's nicht zur meiner Natur passen, bin aber kein Programmierer und möchte vor allem die Software (vielleicht als Hardwarefreak), am einfachsten haben. Für mich, als Elektroniker, ist die kompliziertere Hardware bisher noch kein Problem.

Übrigens, ich habe im Tiny's DB's etwas über "HV" Programmierung mit 13 V gelesen, aber leider ohne Erklärung. Vielleicht lassen sich die AVR's mit vorhandenem PIC Brenner nach kleinen Hardwareänderungen, umstecken der Letungen am LPT und entsprechender Software auch flaschen, wenn ich unbedingt etwas fertiges mit AVR nachbauen wollte ?

[Besserwessi]

Die HV Programmierung ist die "alte" Methode und wird nur eher selten eingesetzt. Dazu wird ein Spannung von z.B. 13 V an den Reset Pin angelegt und die Übertragung passiert dann bei den kleinen ähnlich wie bei ISP, nur ggf. auf anderen PINs. Bei den Größeren Chips geht die Übertragung dann parallel über mehr Leitungen. Es gibt 3 nicht sehr häufige Anwendungen für die HV programmierung:
1) es geht ggf. etwas schneller
2) Man ist unabhängig vom Takt und kann auch bei beliebigen Fuse Settungs programmieren (verfusete Chip wiederbeleben)
3) Es geht auch wenn der Reset Pin als IO Pin genutz werden soll (vor allem 8 PIN Chips)

Einen PIC Brenner auch für die AVRs zu nutzen wäre eher für die LV ISP möglich. Die Software AVRDUDE ist beim LPT sehr flexibel und kann für fast jede Belegung eingestellt werden. Ist nur die Frage ob genug Leitungen da sind (3 zum µC und eine zurück).

P.S. : Die HV Programmierung steht auch in DB, nur weiter hinten unter 22.7 . Da braucht man aber eine Leitung mehr als für ISP, ist also eher schwieriger. Ein gemeinsamer Programmer für PIC, AVR und JTAG wäre aber ohne viel Aufwand möglich. Ein Problem ist dabei aber eventuell die Softwareunterstützung für JTAG und HV-Seriell Prog. beim AVR.

[PICture]

Danke dir sehr für die ausführliche Erklärung laut ATNEL nicht für Anfänger !

Ich lerne, wie auch immer, unbewusst über AVR's immer mehr. Mein PIC Brenner hat bisher 5 Leitungen (VCC, VPP, DATA, CLK und GND) und die VPP mit 13V müsste dann auf Reset ? angelegt werden. Ausserdem muss man die eine bidirektionale Leitung (DATA) auf zwei unidirektionale (MISO und MOSI) verteilen. Die vorhandene Treiber müssten bloss getrennt und auf zwei Leitungen verteilt werden. Angeblich kann die statische 13 V als zusätzliche unabgeschirmte Leitung sein.

Man weisst aber heute nicht, was man morgen brauchen könnte und auf überdimensioniertes Wissen glaube ich bisher noch nicht.

So gesehen weisen für mich beim Brennen PIC's und AVR's praktisch keine Unterschiede auf, weil bei PIC's gibt es auch s.g. "LV" Programmirung mit VCC. Zum Brennen von PIC's, die "normal" mit 2V arbeiten habe ich bisher VCC=5V aus dem Brenner benutzt.

[Besserwessi]

Wenn ich die PIC Programmer so sehe wäre das vermutlich eher die Leitung vom µC zum LPT die man einfach direkt (bzw. mit Widerstand, 1-2 Dioden als Schutz) mit dem LPT verbindet. Die PIC Programmer für den LPT scheinen mit nicht so einheitlich, aber die Richtung vom PIC zum LPT kommt mir eher ungewöhnlich vor. Die scheint auch als Ausgang nutzbar zu sein.

[PICture]

Ja, aber ich wollte bloss 3m langes Kabel haben ...

Der für mich einziger Unterschied ist: bidirektionale Leitung DATA bei PIC's enspricht zwei unidirektionalen Leitungen MISO und MOSI bei AVR's.

Ausserdem wird es bei PIC's gemeinsam CLK vom Brenner zum Lesen und Schreiben benutzt, unabhängig davon, wie das interne Clock konfiguriert ist. So was kompliziertes, wie Fuses bei AVR's, gibt es dort nicht. Deshalb sind PIC's für so einfache Menschen, wie ich, noch mit Spass beherrschbar.