Hallo, ich bin neu in der AVR-Programmierung und habe mir das AVR-Studio runter geladen und da dann das folgende Programm für ATmega8 geschrieben .include "m8def.inc" ldi r16,0x00 call m1 ende: rjmp ende m1: ldi r16, 0xFF ret wo er mir sagt das er call und ret nicht kennt aber in einem Programm von myavr funktioniert call und ret wieso nicht bei AVR Studio? bzw wenn es nicht geht gibt es einen befehl um den Programmcounter zu sicher, habe in der liste der befehle keinen gefunden :-( bin über jede Hilfe dankbar, grüße Micha
sorry, für den post mir ist irgendwie gerade der Geistesblitz gekommen und habe das Problem gelöst, es hat nur das r vor call gefehlt. Thema kann gelöscht werden von mir aus. Grüße Micha
sry, aber so kann des eig net funktionieren, weil die ret und call befehle ja nur funktioniert, wenn der stack initialisiert ist. Korrigiert mich bitte, wenn ich stuss schreibe.. Gruß Jochen
Jochen Rösch wrote: > sry, aber so kann des eig net funktionieren, weil die ret und call > befehle ja nur funktioniert, wenn der stack initialisiert ist. Das ist im Prinzip schon korrekt: Bei den älteren AVRs (und dazu zählt der Mega8) muss der Stack noch explizit initialisiert werden, sonst gibt's Registersalat. Möglicherweise fällt es bei diesem Minimalprogramm nur nicht auf. Bei neueren AVRs ist das allerdings nicht mehr erforderlich, weil der Stack Pointer automatisch auf das Ende des SRAM initialisiert wird.
ok, dann bin ich doch net verkehrt, des freut mich
Johannes M. wrote: > Bei neueren AVRs ist das allerdings nicht mehr erforderlich, weil der > Stack Pointer automatisch auf das Ende des SRAM initialisiert wird. Welche sind denn das zum Beispiel? Hör ich ja gerade zum ersten mal. Hab ich aber auch nicht viel am Hut mit, zusammen mit einem WinAVR ;)
>>Welche sind denn das zum Beispiel? Das ist ABSOLUT uninteressant. Weil es zu JEDEM (JEDEM!!!!!) vernünfitigen Programmierstil gehört, sowas wie den Stack SELBST und EXPLIZIT zu initialisieren. Genau durch so einen SCHEISS und solche völlig überflüssigen Gimmicks entstehen in der Folge nämlich wieder diese endlosen Probleme besonders bei Anfängern. Die sollen gefälligt Sorgfalt lernen und sich nicht auf blödsinnige Gags verlassen, die dann bei einem anderen AVR nicht vorhanden sind. Und schon geht der Ärger dann los. Jochen Müller
Jochen Müller wrote:
> ...blablabla...
Danke für deinen Kommentar!
>>Jochen Müller wrote: > ...blablabla... Jochen hat völlig recht, ein wahreres Wort wurde selten gesprochen. Das ist kein blabla. Und wenn du mal nachdenken würdest oder ahnung hättest dann würdest du das auch erkennen. Dennis
Dennis wrote: >>>Jochen Müller wrote: >> ...blablabla... > > Jochen hat völlig recht, ein wahreres Wort wurde selten gesprochen. > Das ist kein blabla. Und wenn du mal nachdenken würdest oder ahnung > hättest dann würdest du das auch erkennen. Noch so einer. Mir brauchst du von vernünftigem Programmierstil nichts zu erklären und wie ich schon sagte interessiert es mich nur so. Üblicherweise arbeite ich mit dem AVR-GCC mit dessen Startup Code ich als Programmierer wirklich gar nichts zu tun habe. Ich wollte mich lediglich mal etwas näher informieren und im Datenblatt des entsprechenden Chips umschauen wo es denn einen Satz dazu gibt. Tja, leider aber ist es nicht so einfach hier eine solche Information zu bekommen. In diesem Sinne noch ein mal Danke an euch beide. Achja, ich habe nie bezweifelt, dass er nicht Recht hatte, das hast du leider so aufgefasst. Es war nur nicht die Antwort auf meine Frage, sondern, im Gegenteil, eine Blockierung auf die Antwort - und sowas mag ich gar nicht leiden.
Hi >lediglich mal etwas näher informieren und im Datenblatt des >entsprechenden Chips umschauen wo es denn einen Satz dazu gibt. Bei Stackpointer: 'Initial Value'. MfG Spess
möchte mich noch bedanken für die Infos mit dem Stack und von den AVR's bedanken. Weil ich hätte eher gedacht das der Kopf drüber geschüttelt wird. grüße micha
Michael Muster wrote: > möchte mich noch bedanken für die Infos mit dem Stack und von den AVR's > bedanken. Weil ich hätte eher gedacht das der Kopf drüber geschüttelt > wird. > > grüße micha Hast dein Problem doch schon fast selber lösen können ;) :D
ja du sagst es "fast" und später bei 100 Zeilen Code den Fehler gesucht und wäre verzweifelt aso was mich noch Interessieren würde gibt es einen Befehl um den PC zu speichern
Jochen Müller wrote: >>>Welche sind denn das zum Beispiel? > > Das ist ABSOLUT uninteressant. Der Jochen mal wieder! Wenn Simon die Frage stellt, dann ist sie für ihn offensichtlich nicht uninteressant! Dir steht es nicht zu, anderen Leuten vorzuschreiben, was sie zu interessieren hat! > Weil es zu JEDEM (JEDEM!!!!!) vernünfitigen Programmierstil gehört, > sowas wie den Stack SELBST und EXPLIZIT zu initialisieren. > > Genau durch so einen SCHEISS und solche völlig überflüssigen Gimmicks > entstehen in der Folge nämlich wieder diese endlosen Probleme besonders > bei Anfängern. Die sollen gefälligt Sorgfalt lernen und sich nicht auf > blödsinnige Gags verlassen, die dann bei einem anderen AVR nicht > vorhanden sind. Und schon geht der Ärger dann los. Mann, komm wieder runter! Ich gebe Dir zwar Recht, dass man sich das explizite Initialisieren des Stack Pointers nicht abgewöhnen sollte, auch wenn die Hardware es selber macht, da die vier zusätzlichen Codezeilen bei der Initialisierung im Regelfall keinen jucken. Das kann man aber auch anders schreiben. Die Entwickler bei ATMEL werden sich jedenfalls was dabei gedacht haben. Es ist jedenfalls sinnvoll, sich über die Features der Controller zu informieren, und das kann sich niemand von jemandem wie Dir verbieten lassen.
Michael Muster wrote: > ja du sagst es "fast" und später bei 100 Zeilen Code den Fehler gesucht > und wäre verzweifelt > > aso was mich noch Interessieren würde gibt es einen Befehl um den PC zu > speichern PC auf den Stack "sichern"
1 | rcall savepointer |
2 | savepointer: |
dann kannst du mit pop die beiden bytes abholen, und mußt (siehe Datenblatt!!) noch ein paar bits ausmaskieren.
Jochen Müller wrote: >>>Welche sind denn das zum Beispiel? > > Das ist ABSOLUT uninteressant. > Weil es zu JEDEM (JEDEM!!!!!) vernünfitigen Programmierstil gehört, > sowas wie den Stack SELBST und EXPLIZIT zu initialisieren. > > Genau durch so einen SCHEISS und solche völlig überflüssigen Gimmicks > entstehen in der Folge nämlich wieder diese endlosen Probleme besonders > bei Anfängern. Die sollen gefälligt Sorgfalt lernen und sich nicht auf > blödsinnige Gags verlassen, die dann bei einem anderen AVR nicht > vorhanden sind. Und schon geht der Ärger dann los. Das ist totaler Schwachsinn. Vernünftiger Programmierstil ist es, wenn man das Datenblatt zu lesen und vorallem zu verstehen vermag. Schließlich verlässt du dich ja auch ansonsten auf die Standardwerte der Spezialregister. Oder initialisierst du grundsätzlich und immer sämtliche Timer, USARTs, SPI, ADC und so weiter, auch wenn du sie garnicht brauchst? Siehste, da verlässt du dich auch drauf, dass die stabil genullt werden. Und überflüssig sind die Gimmnicks schon garnicht. Das nennt man wohl "Fortschritt" oder "Weiterentwicklung". Und dazu gibts auch weiterentwickelte Datenblätter, logo. Und wenn da drinne steht, dass der Stack automatisch initialisiert wird, freut mich das und gut.
nana... immer diese gezanke, jeder wie er will! Und ich hatte gerade beim Mega48 das Problem, das leider die vorinistialisierung nur beim PowerOn Reset gemacht wird! Beim Reset mittels programmer aber (scheinbar) nicht... zumindest kann das ganzschön zum Haareraufen sein, wenn auf einmal immer noch das UART eine Pin blockiert, obwohl man die Stelle wo die UART eingeschaltet wird auskommentiert hat grr
@sven: >>Das ist totaler Schwachsinn. Vernünftiger Programmierstil ist es, wenn >>man das Datenblatt zu lesen und vorallem zu verstehen vermag. Das ist alles andere als Schwachsinn, jedenfalls im professionellen bereich. >>Schließlich verlässt du dich ja auch ansonsten auf die Standardwerte der >>Spezialregister. Oder initialisierst du grundsätzlich und immer >>sämtliche Timer, USARTs, SPI, ADC und so weiter, ALLERDINGS!!!! Und in fast allen Spezifikationen und Pflichtenheften, die je auf meinem Schreibtisch lagen, steht das sogar ausdrücklich drin. Für Hobbybastler mag das zutreffen, was Du sagst, im prof. Bereich niemals. Ausserdem gibt es auch Probleme mit der Portierbarkeit, wenn auf dem einen AVR der Stack automatisch gesetzt wird und auf dem anderen nicht. Warum Du Dich nur wegen der paar Codezeilen so vehement für eine völlig überflüssige Schlamperei stark machst ist mir ein Rätsel. Das kann doch nicht Dein Ernst sein, Nachlässigkeiten zu propagieren. Ausserdem ist das nur für Assembler-Leute interessant, ein Hochsprachencompiler setzt den Stack eh selbst. Und nicht einmal der wird sich auf das automatische Setzen verlassen. Annemarie
Annemarie wrote: >>>Schließlich verlässt du dich ja auch ansonsten auf die Standardwerte der >>>Spezialregister. Oder initialisierst du grundsätzlich und immer >>>sämtliche Timer, USARTs, SPI, ADC und so weiter, > ALLERDINGS!!!! > Und in fast allen Spezifikationen und Pflichtenheften, die je auf meinem > Schreibtisch lagen, steht das sogar ausdrücklich drin. Für Hobbybastler > mag das zutreffen, was Du sagst, im prof. Bereich niemals. Oh mann. Da steht drin, dass alle I/O Register initialisiert werden müssen, für den Falle, dass der AVR mal seine Tage hat oder was? Die Register werden zu 1000% richtig initialisiert, so wie es im Datenblatt steht. > Ausserdem gibt es auch Probleme mit der Portierbarkeit, wenn auf dem > einen AVR der Stack automatisch gesetzt wird und auf dem anderen nicht. Es gibt auch Probleme der Portierbarkeit im Assembler-Sprachsatz, wenn du unbedingt Assemblerprogramme portieren willst. > Ausserdem ist das nur für Assembler-Leute interessant, ein > Hochsprachencompiler setzt den Stack eh selbst. Und nicht einmal der > wird sich auf das automatische Setzen verlassen. Eben, und wer bitte portiert Assembler Programme? Das lohnt sich nur bei Hochsprachencompilern wirklich. Aber wieso wird sich der Hochsprachencompiler nicht auf das automatische Setzen verlassen? Also ich kenne keinen Hochsprachencompiler für AVRs, der ALLE I/O Register setzt in seinem Startup Script. Du siehst mir eher nach einem Wichtigtuer aus.
Läubi Mail@laeubi.de wrote: > nana... immer diese gezanke, jeder wie er will! > Und ich hatte gerade beim Mega48 das Problem, das leider die > vorinistialisierung nur beim PowerOn Reset gemacht wird! Beim Reset > mittels programmer aber (scheinbar) nicht... zumindest kann das > ganzschön zum Haareraufen sein, wenn auf einmal immer noch das UART eine > Pin blockiert, obwohl man die Stelle wo die UART eingeschaltet wird > auskommentiert hat *grr* Seite 47 des Mega48 Datasheets 01/08 sagt: During reset, all I/O Registers are set to their initial values, and the program starts execution from the Reset Vector. ... The I/O ports of the AVR are immediately reset to their initial state when a reset source goes active.
@simon Also mit Wichtigtuerei hat das ja nun garnichts zu tun. Ich schätze mal Du wärst sehr überrascht, was in Specs und Pflichtenheften alles drinsteht. Da kann ich persönlich nichts dran ändern, also wirf es mir nicht vor. Ich bringe hier sachliche Argumente, wieso musst DU aus der Rolle fallen? Was Compiler angeht so werden die das schon alleine deshalb nicht machen, weil die überhaupt nicht unterscheiden können (oder nur mit Zusatzaufwand) aus welcher Baureihe der jeweile z.B. Mega8 kommt. Es ist nämlich absolut davon auszugehen, dass spätere Produktionen des gleichen AVR-Modells dann z.B. das Stack-Feature haben und ältere eben nicht. Das eine Hochsprache alle Register und Portfeatures expilzit setzt, habe ich auch garnicht behauptet. Es ging mir nur um den Stack. Man sieht genau daran, dass Du es eben nicht gewohnt bist, sorgfältig zu arbeiten, das fängt ja bei Dir beim lesen schon an. Kein Wunder, dass Du dann bei dem Stack-Init ebenso schlampig arbeiten willst. Annemarie
Annemarie wrote: > Das eine Hochsprache alle Register und Portfeatures expilzit setzt, habe > ich auch garnicht behauptet. Es ging mir nur um den Stack. Nö, das ist ne glatte Lüge! Zitat von 18:21: >>>Schließlich verlässt du dich ja auch ansonsten auf die Standardwerte der >>>Spezialregister. Oder initialisierst du grundsätzlich und immer >>>sämtliche Timer, USARTs, SPI, ADC und so weiter, > ALLERDINGS!!!! > Und in fast allen Spezifikationen und Pflichtenheften, die je auf meinem > Schreibtisch lagen, steht das sogar ausdrücklich drin. Für Hobbybastler > mag das zutreffen, was Du sagst, im prof. Bereich niemals. Hier geht es eindeutig nicht nur um den Stack, sondern um "sämtliche Timer, USARTs, SPI, ADC und so weiter"! > Man sieht > genau daran, dass Du es eben nicht gewohnt bist, sorgfältig zu arbeiten, > das fängt ja bei Dir beim lesen schon an. Ach, und das was Du hier verzapfst, nennst Du sorgfältig? Weißt nach einer halben Stunde schon nicht mehr, was Du geschrieben hast? Und behauptest das Gegenteil, obwohl es oben anders steht? Mannmannmannmann...
DAS SCHRIEB ICH: (ICH REDE NUR VOM STACK) >Ausserdem ist das nur für Assembler-Leute interessant, ein >Hochsprachencompiler setzt den Stack eh selbst. Und nicht einmal der >wird sich auf das automatische Setzen verlassen. DAS DU: (DU VERALGEMEINERST UND VERDREHST MEINEN TEXT) >Eben, und wer bitte portiert Assembler Programme? Das lohnt sich nur bei >Hochsprachencompilern wirklich. Aber wieso wird sich der >Hochsprachencompiler nicht auf das automatische Setzen verlassen? Also >ich kenne keinen Hochsprachencompiler für AVRs, der ALLE I/O Register >setzt in seinem Startup Script. Auch beim ZWEITEN MAL lesen, hast Du es nicht erfasst. Das wird langsam bedenklich. Gewöhne Dir bitte Sorgfalt an, SO geht das nicht. Unabhängig davon ist diese Aussage völliger Unsinn: >Eben, und wer bitte portiert Assembler Programme? Das lohnt sich nur bei >Hochsprachencompilern wirklich. Annemarie
Sorry, dass ich mich auch noch einmische, aber das was Johannes da schreibt ist nun wirklich Quatsch, der so nicht stehen bleiben kann. >Eben, und wer bitte portiert Assembler Programme? Gerade DIE werden oft portiert, oder glaubst Du dass wir für jedes Display oder Tastatur, etc. das Rad neu erfinden? Natürlich werden da bestehende Routinen auf andere AVR-Typen portiert, das ist hier Tagesgeschäft. Siggi
Hihi, jetzt schreibt Taschenbuch schon als Annemie.... Köstlich.....
Siegfried wrote: > Sorry, dass ich mich auch noch einmische, aber das was Johannes da > schreibt ist nun wirklich Quatsch, der so nicht stehen bleiben kann. >>Eben, und wer bitte portiert Assembler Programme? Sorry, dass ich mich noch mal melden muss, aber das habe ich gar nicht geschrieben. Die Aussage stammte von Simon. Ist hier irgendeine Seuche ausgebrochen, dass die Leute nicht mehr lesen können?
Wer von euch initialisiert eigentlich den PC?
Wenn man alle Register beim Programmstart zusätzlich zur automatischen
Initialisierung noch einmal initialisiert, müsste man dies doch
konsequenterweise auch mit dem Programm-Counter tun. Wer weiß, ob der
tatsächlich immer automatisch mit 0 initialisiert wird ;-)
Verfechter der doppelten Initialisierung sollten auch in Erwägung
ziehen, jeden schreibenden Zugriff auf eine RAM-Zelle zweimal
hintereinander auszuführen, damit der Wert auch wirklich fest
drinsteckt.
Spaß beiseite: Wenn der Auftraggeber so etwas möchte und es sich nicht
ausreden lässt, wird es natürlich so gemacht. Professionelles Arbeiten
heißt: Der Auftraggeber zahlt, und der Auftragnehmer versucht, dessen
Wünsche bestmöglich zu erfüllen, auch wenn sie nicht immer
nachvollziehbar sind.
Professionalität hat (leider) nicht immer etwas mit technischer
Sinnhaftigkeit zu tun.
Bärbel schrieb:
> Hihi, jetzt schreibt Taschenbuch schon als Annemie....
Witzig, daran musste ich auch gerade denken :)
Annemarie wrote: > Was Compiler angeht so werden die das schon alleine deshalb nicht > machen, weil die überhaupt nicht unterscheiden können (oder nur mit > Zusatzaufwand) aus welcher Baureihe der jeweile z.B. Mega8 kommt. Es ist > nämlich absolut davon auszugehen, dass spätere Produktionen des gleichen > AVR-Modells dann z.B. das Stack-Feature haben und ältere eben nicht. Ist doch gar nicht so. Natürlich kann der Compiler zwischen den Controllern unterscheiden, man gibts ihm ja auf der Kommandozeile mit. > Kein Wunder, dass Du dann bei > dem Stack-Init ebenso schlampig arbeiten willst. Was man sich alles unterstellen lassen muss, nur weil man wissen wollte, welche Controller es genau sind, die dieses neue Feature unterstützen. Interessant! Übrigens mache ich selber keine Stack-Init, da es der Compiler für mich macht. Das habe ich jetzt bestimmt schon zum dritten mal geschrieben. Leider werden konsequent Sachen überlesen und aus bestimmten Aussagen leider sofort Schlussfolgerungen gezogen. Ich bekomme nicht gerne unterstellt, dass ich schlampig arbeite, denn das tue ich gewiss nicht. Aber ich brauche es auch nicht zu beweisen (nicht vor dir, nicht vor anderen hier), denn da hätte ich im Nachhinein eh nichts von. In diesem Sinne.
yalu wrote: > Professionalität hat (leider) nicht immer etwas mit technischer > Sinnhaftigkeit zu tun. Das habe ich mir in dem Zusammenhang jetzt auch Gedacht. Warum schreibt der Auftraggeber Sachen ins Pflichtenheft, wo er keine Ahnung von hat? Mit Ordentlichkeit hat es jedenfalls nichts zu tun, Sachen zu initialisieren, die ja schon beim Controllerstart initialisiert werden. Hast du ja auch schon gesagt, yalu.
> Warum schreibt > der Auftraggeber Sachen ins Pflichtenheft, wo er keine Ahnung von hat? Weil der Auftraggebär meist ein BWLer ist. Und BWLer kennen meist nix Anderes außer ihrer schön- und hochgerechneten (meist falschen) Zahlen. Das ist einer der Berufe, die die Welt nicht braucht. ;-) MfG, Bärbel
Achja, von folgenden AVRs weiß ich, dass sie den Stackpointer selbst initialisieren: - Tiny13 - Tiny24/44/84 - Tiny25/45/85 - Tiny261/461/861 - Tiny48/88 - Mega48/88/168 - Mega644 MfG, Bärbel
Hi Ein oder zwei schon initialisierte Register noch einmal zu initialisieren ist zwar unnötig, aber kein Fehler. Bei einer etwas umfangreicheren Hardwareinitialisierung kann man das unter 'ferner liefen' abbuchen. Also was soll die ganze Krümelkackerei. GCC-User sollten erst mal nachsehen was der Compiler wirklich macht. MfG Spess
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.