PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : [ERLEDIGT] Am einfachsten anfangen ?



PICture
30.06.2011, 16:02
Hallo!

Ab jetzt möchte ich möglichst unkompliziert auch AVR's, wie bisher PIC's, in ASM programmieren, weil ich keinen vergleichbaren PIC zu dem ATtiny43U wegen Versorgungsspannung finden kann (siehe: http://de.farnell.com/jsp/displayProduct.jsp?sku=1773399&CMP=e-2072-00001000 ). Ich möchte zum ICSP Brennen LPT verwenden. Was für Hardware und Software brauche ich um ASM Programme bis 4kB effizient und möglichst kostenlos zu erstellen und brennen ?

Ich freue mich sehr auf Eure Hilfe. :D

5Volt-Junkie
30.06.2011, 16:42
Hi,

AVR Studio? ;)

PICture
30.06.2011, 16:46
Hallo Scheff!

Danke schön, dass werde ich dann installieren. :D

Wie kann ich nur nötigen Assembler Programm schaffen ohne den für mich unnötigen Schnick-Schnack ?

Leider habe ich in Wiki nichts konkretes gefunden, sonst hätte ich nicht gefragt. Und einfachste Hardware ? ;)

5Volt-Junkie
30.06.2011, 16:54
http://www.obd-shop.com/danila/product_details.php?id=356&lang=de

Ich besitze den hier, ist sehr günstig, handlich, schnell, zwei Spannungen zur Verfügung und sieht noch super aus! Kann ich nur empfehlen.

rideyourstyle
30.06.2011, 16:55
Eine guter Anfang für AVR und Assembler bietet folgende Seite:

http://www.mikrocontroller.net/articles/AVR-Tutorial

Es ist gut beschrieben und es hat auch Verweise auf einfache Programmieradapter, die auch selbst gebaut werden können!

Viel Erfolg... ;-)

PICture
30.06.2011, 16:59
Danke dir für bewährte Lösung, werde ich sicher anwenden und mir einen ICSP Anschluss dafür basteln. Ich möchte nur ASM Programme und keine Projekte erstellen. Was für ein Teil von AVR-Studio ist für mich unbedingt nötig um nur eine HEX-Datei aus meinem Quellcode zu kriegen und danach brennen ?

Mein Quellcode möchte ich, wie bisher (falls möglich), mit Texteditor erstellen. ;)

shedepe
30.06.2011, 17:06
Und irgendeinen ISP Programmer: z.B. den hier:
http://www.steitec.net/AVR-Programmer/AVR-ISP-Programmer--LPT-.html
Es gibt allerdings auch einige recht günstige mit USB Anschluss die meiner Meinung nach einfacher ins System einzubinden sind (hab mal schlechte Erfahrungen mit nem selbstgebauten LPT programmer gemacht)
Und der Rest sollte hier drin stehn :D
http://www.rn-wissen.de/index.php/AVR-Einstieg_leicht_gemacht

PICture
30.06.2011, 17:18
Na ja, ich bin leider kein Softwarefreak und habe mir bisher immer die gewünschte Hardware selber gebastellt und die Software aufs Minimum reduziert. In dem o.g. Wiki Artikel habe ich leider trotz mehrmaligen Durchlesen nichts für mich brauchbares gefunden, da es eben nur sollte ... :(

Übrigens, falls ich keinen ferigen Rezept hier bekomme, würde ich ausprobierte Minimalisiereungsmethode anwenden: ganzes AVR-Studio installieren und danach einzelne Komponenten in Papierkorb einwerfen und falls nicht mehr geht, das zuletzt gelöschte wiederherstellen. Es dauert ein bishen länger, bis ich mein Minimum habe, macht aber Spass. :)

rideyourstyle
30.06.2011, 17:20
AVR-Studio 4 war lange Zeit aktuell. Neu gibt es auch die Version 5. Mit der kann man dann auch Code für die avr32 Serie erstellen. Ist eigentlich egal welche du nimmst. Atmel dein Name verraten musst du bei beiden Versionen.

Ich denke du kannst problemlos mit irgend einem Editor das Schreiben, im AVR-Studio öffnen (bzw wenns offen ist sollte das Programm die Änderungen merken), Compilieren und du hast deine hex-Datei ;-)

Bernd_Stein
30.06.2011, 17:36
Hallo!

Ab jetzt möchte ich möglichst unkompliziert auch AVR's, wie bisher PIC's, in ASM programmieren,...

Mach es mit dem AVR-Studio.
http://www.robomodules.de/portal/index.php?id=199



Ich möchte zum ICSP Brennen LPT verwenden. Was für Hardware und Software brauche ich um ASM Programme bis 4kB effizient und möglichst kostenlos zu erstellen und brennen ?

Muß es unbedingt " LPT " sein ?

Ansonsten würde ich den AVR ISP MKII empfehlen.

Bernd_Stein

PICture
30.06.2011, 17:36
@ rideyourstyle

Danke dir sehr, das finde ich für mich optimal und eine Übung/Spielerei damit ist für mich selbstverständlich. :)

Es bleibt nur das Problem die hex-Datei an den AVR zu übergeben. Ich vermute, das für mich grösstes Problem wäre die Wahl aus dem AVR-Studio Menü des richtigen Brenners, womit es funktioniert. ;)

@ Bernd_Stein

Danke sehr, bin aber leider kein ASM und µC Anfänger, möchte ich nur als nächstes mit AVR's spielen ... :D

@ alle

Ich wollte mir durch fragen nur ein bisschen Zeit sparen, sonnst dauert es nur länger, bis ich das gewünschte habe. ;)

Bernd_Stein
30.06.2011, 17:59
@ Bernd_Stein
Danke sehr, bin aber leider kein ASM und µC Anfänger, möchte ich nur als nächstes mit AVR's spielen ...

Habe mir das mit dem AVR-Studio nicht durchgelesen. Dachte es wäre eine Beschreibung wie man mit dem AVR-Studio umgehen muß.

Bernd_Stein

Richard
30.06.2011, 18:15
Hi,

AVR Studio? ;)

Dem schließe ich mich an und @Picture Drucke Dir schon einmal die Datenblätter aus..Register und AVR ASM Code. :-)

Viel Spaß beim "Umschulen", Richard

PICture
30.06.2011, 18:24
Danke, ich brauche eigentlich nur kompletten Befehlsatz um anderen Prozessor/µC zu programmieren, aber zuerst muss ich den weg vom Quellcode zum Programmspeicher kennen. :(

Richard
30.06.2011, 18:33
Übrigens, falls ich keinen ferigen Rezept hier bekomme, würde ich ausprobierte Minimalisiereungsmethode anwenden: ganzes AVR-Studio installieren und danach einzelne Komponenten in Papierkorb einwerfen und falls nicht mehr geht, das zuletzt gelöschte wiederherstellen. Es dauert ein bishen länger, bis ich mein Minimum habe, macht aber Spass. :)

Das studio ist ein echter Brocken, sehr groß kann aber viel. Für kleine ASM Programme aber schon happig. Ich habe früher (unter DOS) auch nur einfache Text Editoren wie Notepad verwendt und mit entsprechenden Zusatzprogramme daraus intelHEX Files erzeugt, damals auch für PIC's. :-) Das klappte noch mit einem 16 Mhz 286 Tandom PC. :-)

Aber das Studio hat auch seine Berechtigung, ordentlich geordnete Projekte, Debugger, Simulator und mit entsprechender Hartware (Programmer) und (einigen) AVR's auch Debuggen in der Schaltung.....Dafür ist die Einarbeitung nicht ganz ohne. :-( Nur die Harten kommen in den Garten. :-)

Gruß Richard

PICture
30.06.2011, 18:38
Aha, jetzt weiss ich zumindest warum ich in PICerei so weit gekommen bin. Beim AVR's bin ich nicht so anspruchsvoll, möchte sie nur fürs Beleben meiner Spielzeuge mit einem 1,2 V Akku missbrauchen ...:p

Richard
30.06.2011, 18:51
Danke, ich brauche eigentlich nur kompletten Befehlsatz um anderen Prozessor/µC zu programmieren, aber zuerst muss ich den weg vom Quellcode zum Programmspeicher kennen. :(

Der ist letztendlich doch überall gleich. :-) das Studio unterstützt viele Adapter, und kann aus der Oberfläche heraus ein Programm debuggen, simulieren, brennen.....Aber auch Programme wie z.B. poniprog können .Hex oder .bin Dateien in den AVR schieben. Ich benutze Studio4 und kann nicht klagen, allerdings mit dem STK500 von Amtel. Halt damals zusammen erworben. Wie das allerdings mit selbst gebastelten LPT "Brennern" zusammen arbeitet????? Wenn ich nicht WÜSSTE das DU Deinen Eigenen Kopf hast. :-) Würde ich ja vorschlagen einen käuflichen "Brenner" zu nehmen, aber DAS würde voll gegen Deine "Entwickler Würde" verstoßen. :-) :-)

Gruß Richard

PICture
30.06.2011, 19:20
Es ist schlimmer als du denkst: mit etwas fertiges war ich bisher noch nie zufrieden und musste es für mich gleich anpassen. Weil es unnötige und schwerere Arbeit ist, lieber mache ich alles, was ich kann, von Anfang selber, damit war ich bisher immer glücklich. :)

Richard
30.06.2011, 19:40
Es ist schlimmer als du denkst: mit etwas fertiges war ich bisher noch nie zufrieden und musste es für mich gleich anpassen. Weil es unnötige und schwerere Arbeit ist, lieber mache ich alles, was ich kann, von Anfang selber, damit war ich bisher immer glücklich. :)

Das ist (mir) klar, darum schlage ich auch NIX fertiges vor. :-) Beib einfach wie Du bist, ist zumindest für mich voll OK. :-)

Gruß Richard

PICture
30.06.2011, 21:25
Ich habe schon mir gefallendes Assemblerprogramm von http://www.sixca.com/tool/download/avr_wasm32.html runtergeladen und installiert, da ich nur einen Dolmetscher für Quellcode -> Hexdatei brauche. Für Brenner habe ich diese Hardware und Software gewählt: http://www.holger-klabunde.de/avr/avrboard.htm#AVR%20/%20ATMega%20Prommer .

Um das alles auszuprobieren muss ich jetzt Entwicklungsplatine für Tiny's und den ICSP Brenner basteln. Für ATtiny43U muss ich angeblich die Versorgungspannung beim Brenner auf 3 V reduzieren und den µC mit einem 1,2 V Akku versorgen. Nach anschauen des Datenblattes vom ATtiny 43U habe ich festgestellt, dass es wegen externen "boost-converter" mit L,D,R und 4 C's (also 7 Bauteilen) für mich uninterressant ist, da ein Spannungsverdoppler mit ICL7660 bzw. MAX660 viel einfacher ist (nur 2 Elkos).

Besten Dank an alle die mir bisher geholfen haben. :D

rideyourstyle
01.07.2011, 10:39
Hehe dann noch was OffTopic: Müsstes du jetzt nicht deinen Namen ändern in PIC_AVRture? ;-)

PICture
01.07.2011, 12:50
Hallo!

Gute Frage, die ich aber zufällig, wie auch immer, sicher beantworten kann: Nein, weil der AVR nur der nächste µC ist, den ich mit Regiter- und Mnemonicstabelle auf dem Tisch in ASM programmieren möchte. Einfacher wäre für mich Änderung auf "picture", weiss aber leider nicht, wie´s am einfachsten geht. :lol:


Ich habe das alles bisher noch nie auswendig gelernt und habe es nicht vor. Das Datenblatt von z.B. ATtiny45V ist für mich ein 234-seitiges Buch denn ich ein mal durchfliege um alle für meine Anwendung nötige Register auszufischen. Üblicherweise arbeite ich eben mit universieller Programmiersprache (Programmablaufsdiagramm, kurz: PAD), die ich dann entsprechend zum gewünschten Prozessor/µC mit entsprechenden Mnemonics aus dem Befehlsatz ins Quellcode "übersetze".

Als Übungen werde ich zuerst durch Austausch von Mnemonics, die mit PIC's ausprobierte Programme bei AVR's anwenden versuchen. Ich habe bisher noch kein Prozessor/µC kirchlich geheiratet. Ich habe eben als erstes gelernt, dass man das momentan nötiges Stück vom Wissen, wie ein Buch aus einer Bibliothek, kurzzeitig ausleien kann.

Übrigens, wenn die Zielschaltung, in der der AVR per ICSP Programmiert wird, eigenene Versorgungspannung (VCC) hat, brauche ich sie nicht durch Verbindungskabel vom Brenner zuführen und kan bereits vorhandenen 5-adriges Kabel für PIC's verwenden.

Dafür brauche ich nur die VCC vom Brenner entsprechend einstellen, damit der H-Pegel passt (z.B. für ATtiny43U auf 3V). Dafür muss ich anstatt 74 HCT... 74HC... Treiber verwenden, die ab 2 V funktionieren. Notfalls könnte ich auch zusätzlich eine Leitung für VCC verwenden. Weil das Kabel um 3 m lang ist, könnte der Teiber zu schwach sein und ich werde das Kabel wahrscheinlich kürzen bzw. zwei Treiber paralell schalten müsen oder beides. Ich werde später ausprobierte Schaltung skizzieren. ;)

radbruch
01.07.2011, 13:47
Hallo

Wenn du dich eingearbeitet hast kannst du ja mal einen direkten Vergleich und eventuell eine Beurteilung der Stärken der Chipfamilien posten.

Ein kleine Anmerkung: In meinem 2006er Tiny25-45-85-Datenblatt gibt es nur 222 Seiten. Darin wird der Begriff "ICSP" nicht gefunden, wohl aber das Kürzel "ISP" welches meiner Meinung nach für "in system programming" steht ;)

Viel Erfolg und Spaß mit den AVRs.

Gruß

mic

PICture
01.07.2011, 14:05
Natürlich werde ich gerne tun ! :D

Die Begriffe ISP ("in system programming") und ICSP ("in circuit serial programming") sind für mich gleichbedeutend, aber ICSP durch mich unbewusst von der PICerei übernommen worden ist.

Danke dir, aber ich, als Optimist, kenne bisher nur Spass und kein Frust. Auf Erfolge, falls überhaupt möglich, muss ich leider ein bisschen warten. :D

Richard
01.07.2011, 14:07
Ich habe eben als erstes gelernt, dass man das momentan nötiges Stück vom Wissen, wie ein Buch aus einer Bibliothek, kurzzeitig ausleien kann. :lol:



Auch Ärzte oder andere hochgebildete wissen nicht alles auswendig, aber sie wissen wo sie Nachschlagen können. :-) Aus diesem Grund sind ja letztendlich auch (einige) Bücher auf Prüfungen zugelassen. Vom Prinzip her ähneln sich Prozessoren b.z.w. deren Programmierung. Wobei allerdings die von Neumann Maschinen anders "gestrickt" sind als die Systeme mit Harvard Architektur. Das ist dann auch der größte Unterschied zwischen PIC und AVR.

Gruß Richard

radbruch
01.07.2011, 15:44
Nach wikipedia sind pic und avr "Harvard Architektur":

http://de.wikipedia.org/wiki/PICmicro#Speicheraufteilung
http://de.wikipedia.org/wiki/Atmel_AVR#Speicherarchitektur

avr ist scheinbar für c optimiert, aber das plapper ich nur nach. Ich kenne und verwende nur avr, aber alle Geräte mit µc die ich bisher geöffnet habe hatten einen pic drin. Letztlich ist es wohl so wie bei den Programmiersprachen: Wenn man mit den gewählten Mitteln das Ziel erreicht ist es ok.

Meine bisher gnadenloseste Anwendung eines AVR funktioniert auch mit PIC:
https://www.roboternetz.de/community/showthread.php?47457-Hardware-Mitmach-Projekt-Kamera-f%FCr-den-RP6&p=479441&viewfull=1#post479441

Gruß

mic

PICture
01.07.2011, 16:10
Letztlich ist es wohl so wie bei den Programmiersprachen: Wenn man mit den gewählten Mitteln das Ziel erreicht ist es ok.

Genau, das ist mein Grund, warum ich jetzt gerne auf AVR's wechseln muss: es gibt kein PIC, der mit einem 1,2 Akku funktioniert und interne ADC Referenzspannung , wie AVR's, gleich 1,1 V hat. Ich habe nie versucht verschiedene Prozessoren/µC's miteinander zu vergleichen. Auf den ersten Blick ist der AVR wegen keiner interner Taktteilung, wie bei PIC, sicher 4-fach schneller, sonst für mich gleich. :)

Eigentlich erst jetzt sehe ich einige Nachteile von PIC's:

- unterschiedliche Befehlsätze für unterschiedliche Familien

- Umschalterei von Speicherbänke von SFR's, ausser 18F... Familie

- kein direkter Zugriff auf Stapel ("stack") mit fester Grösse per "push" und "pop" Befehle

- interner Taktgeber nur bei wenigen Typen aus PIC12F... und PIC16F... Familien

- meistens nötige fürs Brennen 13 V Spannung

- nötige externe Schaltung und ein Pin für ADC Referenzspannung unter VCC und fehlender DC Verstärker x 20

Bei AVR's werden sich die Nachteile noch zeigen:

- kompliziertes Konfigurieren per Fuses

- feste Prioritäten für Interruptquellen

- länger dauernde Bearbeitung von mehreren gleichzeitig anstehenden Interrupts, weil man immer zuerst eine ISR mit "iret" verlassen muss, bevor man in nächste ISR springen kann.

- viele unverständliche Bedingungen, die angehalten werden müssen um einige Befehle ausführen zu können

- nur ein Prescaler für alle Timer/Counter

Übrigens, ich kenne bisher kein Prozessor/µC der alles kann und jedem gefällt, sonst gibt es nur diesen. :D

Richard
01.07.2011, 20:22
Übrigens, ich kenne bisher kein Prozessor/µC der alles kann und jedem gefällt, sonst gibt es nur diesen. :D

Das wirkliche Problem sitzt eh immer VOR der Tastatur, Jeder Prozessor macht genau das was man ihm "einredet". :-( Was nicht immer sinnvoll ist.Brain.0.1 macht auch gelegentlich Fehler ein µC niemals (bis gelegentlich)...

Gruß Richard

PICture
02.07.2011, 01:41
Das stimmt und um das zu vermeinden, habe ich mir kompletten Befehlsatz für 8-bit AVR's runtergeladen und schnell überflogen: http://www.atmel.com/dyn/resources/prod_documents/doc0856.pdf . Dort gibt es sogar sehr viele gleiche Mnemonics, wie bei PIC's. Weil das Programmieren für mich nur ein Mittel ist, um meine Hardware "lebendig" zu machen, möchte ich mir zuerst die gleich, wie bei PIC's, funktionierende zig Befehle auszufiltern und verwenden. Wenn es nötig wird, werde ich mein Befehlsatz zukünftig nach Bedarf erweitern. :)

Übrigens, in "Operation" für jeden Befehl sind sehr ännliche Symbole verwendet, wie in meinen PAD's. Ich sehe daher als Anfänger den Wiki Artikel "PIC Assembler": http://www.rn-wissen.de/index.php/PIC_Assembler nach Änderung den Befehlen und Register für AVR's völlig anwendbar. Lediglich war der Titel damals schon vorgegeben, sonst würde er heissen: "Assemblerprogrammierung". ;)

Als erste Übungen um ASM Programme für AVR's effizient schreiben zu können, möchte ich mit "Übersetzung" von: http://www.rn-wissen.de/index.php/PIC_Assembler#Hilfsmittel für AVR anfangen, da ich den "PIC Miniterminal" bereits seit langem verwende. ;)

PICture
10.07.2011, 02:20
Hallo!

Ich habe mit "studieren" des Datenblattes von ATtiny24/44/84 ( http://www.atmel.com/dyn/resources/prod_documents/doc8006.pdf ) angefangen und festgestellt, dass die Interruptvektoren (1 ... 17) auf Seite 48 für alle Interrruptsquellen schon fest definiert sind und können nicht beliebig geändert werden. Stimmt das ? ;)

radbruch
10.07.2011, 02:35
Man kann die Zieladressen in der Sprungtabelle der Interrupts ändern. Defaultmässig springen die zu einem RETI. Einfach die Adresse der selbstgemachten ISR eintragen.

PICture
10.07.2011, 02:49
Das ist mir noch nicht ganz klar, weil selbstverständlich an den Adressen (0 ... 17) entsprechende ISR Adressen/Marken stehen werden. Beispielweise, wenn ich den Timer/Counter0 permanent laufen lasse, wird nach jedem Überlauf an die Adresse 0x000Bh und weiter an dort stehende Adresse/Marke entsprechender ISR gesprungen und das kann ich nicht ändern, oder ? ;)

Searcher
10.07.2011, 08:09
Hallo PICture,

ich seh das auch so, daß die Zuordnung von Interruptquelle und Programmadresse bei dem ATtiny festgelegt sind.

Das kann man nicht ändern und legt auch gleichzeitig in der Reihenfolge der Interruptnummern die Prioritäten fest. Der Inhalt der Programmadresse kann geändert werden und sollte bei generellem Gebrauch von Interrupts die Anweisung (zB RJMP) zum Aufsuchen der ISR enthalten. :)

Als Pre-Anfänger in ASM stelle mir das so vor, das der Programmcounter durch den Interrupt HW gesteuert unbeeinflußbar auf den in der Tabelle 9-1 aufgeführten unveränderbaren Wert gesetzt wird. Dort sollte dann ein Befehl stehen, der die Programmausführung mit der ISR fortführt.

;)
Gruß
Searcher

Besserwessi
10.07.2011, 08:40
Die Interruptsvektoren sind fest, am Anfang des Flash je 1 (bzw. 2 ab 16 Kbytes Speicher) Worte auseinander. In der Regel steht da dann ein Sprung (RJMP oder JMP) auf die eigentliche ISR. Wenn man die Interrupts dahinter nicht braucht kann man da auch direkt mit der ISR anfangen ohne den Sprung. Da dies im Flash steht kann man es zur Laufzeit nicht (oder nur sehr umständlich) ändern. Falls man da je nach Programmteil eine andere ISR braucht macht man das als normale Verzweigung im Code.

Ein Sprung auf ein RETI für einen nicht genutzten Interrupt ist übrigens ziemlich sinnfrei: Da könnte auch gleich das RETI hinschreiben, und außerdem aktiviert man einen ungenutzten Interrupt einfach nicht.

PICture
10.07.2011, 12:42
Hallo!

Danke schön Euch beiden für ausführliche und verständliche Erklärungen. Man muss also damit leben, dass auftretende z.B. ein Timer1 interrupt immer die Timer0 interrupt für die Ausführung der ISR von Timer1 anhalten kann, was mir aber nicht gefällt. :(

Wann genau wird das Interruptflag in GIFR Register (einzige Möglichkeit die Quelle zu erkennen) gelöscht ? So wie ich das bisher verstanden habe wird es hardwaremässig (intern) vor dem Zwangsprung in die entsprechende ISR gemacht, oder ?

Dann hätte man keine Chance rechtzeitig die Interruptquelle zu erkennen und die Ausführung der entsprechender ISR zu verhindern/verzögern.

Besserwessi
10.07.2011, 14:00
Wann genau das Interrupt-flag gelöscht wird, ist nicht so wichtig. Die Annahme beim Sprung zum Interruptvector kommt mir auch plausibel vor. Es gibt aber ein paar Ausnahmen wo das Bit gar nicht von der Hardware gelöscht wird und das von Hand gemacht werden muss (z.B. USI ?).

Da man für praktisch jede Interrupt-quelle einen eigenen Interrupt-vektor und damit bei Bedarf eine eigene ISR hat, braucht man die Interruptflags nicht um die Quelle zu erkennen. Gelöscht wird aber immer nur das Flag von der aktuell aufgerufenen ISR. Man könnte also in der ISR von Timer0 immer noch feststellen ob auch das Flag von Timer1 gesetzt ist. Wenn einem der Interupt von Timer1 so wichtig ist, kann man in den anderen ISRs ggf. per SEI weitere Interrupts zulassen. Das reduziert die Verzögerung, verhindert sie aber nicht ganz.

PICture
10.07.2011, 14:18
Danke sehr für deine Bestätigung meiner Vermutung. :D


Wann genau das Interrupt-flag gelöscht wird, ist nicht so wichtig.

Für mich wäre es aber aus Gewöhnheit schon wichtig, aber im Datenbblatt (DB) unauffndbar. :(


Da man für praktisch jede Interrupt-quelle einen eigenen Interrupt-vektor und damit bei Bedarf eine eigene ISR hat, braucht man die Interruptflags nicht um die Quelle zu erkennen.

Wie auch immer nehme ich es so an, wie es ist, ohne zu fragen warum. ;)

Übrigens, wie genau ich leider bin, könnte folgender von mir zufällig bemerkter Fehler im Datenblatt von ATtiny24/44/84 ( http://www.atmel.com/dyn/resources/prod_documents/doc8006.pdf ) bestätigen: 5 Seite, 11 Zeile, 2 Wort. Dort anstatt "disabled" steht "disbaled" ... nach Murphy: "Ein Fehler tritt erst dann auf, nachdem die letzte Kontrolle durchlaufen worden war."

PICture
17.07.2011, 03:19
Hallo!

Ich habe das im vorherigen Beitrag DB von ATtiny24/44/84 weiter aufmerksam gelesen, jedoch auf der Seite 18 war für mich schon Ende, weil ich in "Essembly Code Example" auf einen Befehl gestossen bin, wo in ein Register für mich unbekannte Zahl geladen wird: ldi r16,(0 << EEPM1) | (0 << EEPM0). Im darauf folgenden "C Code Example" kommt identische Zahl vor.

Deshalb meine wahrscheinlich letzte Frage: ist es überhaupt möglich AVR's ausschliesslich nur mit normalen Hexzahlen, wie bei allen bisherigen Prozessoren und µC's, in ASM zu programmieren ?

Ich möchte gleich sagen, dass ich C schon vor zig Jahren erfolgslos erlernen versucht und negativ für immer abgehackt habe. Es freut mich, das ich die AVR's näher kennenzulernen versucht habe, aber fast sicher muss ich anderen µC mit niedriger Referenzspannung für ADC nehmen oder beim PIC als Referenz den LM385-Z1,2 anwenden.

Besserwessi
17.07.2011, 09:15
Klar kann man auch für die AVRs direkt die Zahlen hinschreiben. Es ist aber meist einfacher und besser verständlich wenn man die Symbolischen Namen benutzt. Bei einigen Registern wie z.B. ADMUX oder zur Einstellung des AD Teilers mache ich das auch, zumindest teilweise.

Die Schreibweise aus dem Beispiel ist halt wirklich an C angelehnt und etwas gewöhnungsbedürftig. Besonders mit der 0 ist es auch nicht so verbreitet, denn (0 << EEPM1) ist schließlich nichts anderes als eine umständliche Schreibweise für 0. Gängiger ist (1 << EEPM1) um das Bit mit dem Namen EEPM1 zu setzen. Sinnvoll halte ich die Version mit der 0 an Stellen wo man ab und zu mal was ändern muss und um zu zeigen das man das Bit explizit löscht.

Wenn man einen Macroassembler nutzt kann man sich auch ein Markro definieren für den Bitwert. Also z.B. BW(x) für (1 << x).
Das macht man zum Teil auch in C, z.B. wenn man von den ganzen << einen Linksdrall bekommt.

Searcher
17.07.2011, 09:57
Hallo PICture,

die im Datasheet gebrauchten Assembleranweisungem scheinen mir im AVR-Assembler geschrieben. Dazu habe ich bisher kein anderes als dieses http://www.atmel.com/dyn/resources/prod_documents/DOC1022.PDF User Guide gefunden.

Dort ist zB in Kapitel 4.6.3.8 das << erklärt.


Gruß
Searcher

PICture
17.07.2011, 14:52
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. :D

Besserwessi
17.07.2011, 15:15
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
17.07.2011, 15:30
"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
17.07.2011, 15:45
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. :D

Besserwessi
17.07.2011, 18:27
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
17.07.2011, 18:46
Natürlich ! :D

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
17.07.2011, 20:43
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
17.07.2011, 21:00
Danke dir sehr für die ausführliche Erklärung laut ATNEL nicht für Anfänger ! :D

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. :p

Besserwessi
17.07.2011, 21:18
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
17.07.2011, 21:38
Ja, aber ich wollte bloss 3m langes Kabel haben ... :lol:

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