Hab ne kurze Frage zum HW Stack vom ATtiny12. Im Datenblatt steht "3-level-deep Hardware Stack". Unterprogrammaufruf in einem Unterprogrammaufruf in einer ISR wäre dann zuviel, oder?
Hi >Unterprogrammaufruf in einem Unterprogrammaufruf in einer ISR wäre dann >zuviel, oder? Nein. Hört sich aber trotzdem nach schlechter Programmierung an. MfG Spess
Der ist da mit drinnen :-) d.h. dein eigentliches Problem ist nicht nur die ISR, sondern auch wo genau der Interrupt unterbricht. Kommt der während gerade ein UP läuft, hast du entsprechend weniger Stack.
Naja, es werden nur Unterprogramme in der ISR aufgerufen, in der Hauptschleife passiert garnichts. Eines dieser Unterprogramm ruft u.U. ein weiteres Unterprogramm auf. In der Simulation hab ich dann einen HW Stack Overflow bekommen. Mir ist aber eben aufgefallen, dass ich statt der Unterprogrammaufrufe mit rcall auch einfach rjmp benutzen könnte.
Chris Herch schrieb: > Mir ist aber eben aufgefallen, dass ich statt der Unterprogrammaufrufe > mit rcall auch einfach rjmp benutzen könnte. Aber nur wenn eine Funktion auch nur genau von einer Stelle aus aufgerufen wird. Denn du musst ja ans ende dann auch einen Jump zurück machen und der ist ja dann fix. Und wenn dem so ist, warum dann überhaupt ein Unterprogramm? Warum den Code dann nicht direkt an die Stelle schreiben wo er hingehört? Dir ist klar, wofür ein Unterprogramm gedacht ist? Und NEIN, nicht zum steuern des Programmflusses. gruß cyblord
>> Warum den Code dann nicht direkt an die Stelle schreiben wo er hingehört?
Weils dann unübersichtlicher wird? ^^
Aber stimmt schon, ein Unterprogramm bräuchte ich eigentlich nur an
einer Stelle, weil das von mehreren Stellen aus angesprungen wird.
Chris Herch schrieb: >>> Warum den Code dann nicht direkt an die Stelle schreiben wo er hingehört? > Weils dann unübersichtlicher wird? ^^ Es stellt sich halt die Frage ob ein rumspringen quer durch den Code übersichtlicher ist.
Warum willst Du Dich mit einem veralteten IC abquälen, der schon lange nicht mehr hergestellt wird? Nimm einen ATtiny25. Was sich Atmel damals mit dem Hardwarestack gedacht hat, ist mir eh ein Rätsel. Vielleicht saß mal ein PIC-Programmierer mit im Team und fand einen richtigen Stack zu einfach und zu bequem. Peter
Peter Dannegger schrieb: > Was sich Atmel damals mit dem Hardwarestack gedacht hat Tja, den Chip so billig wie möglich zu produzieren. Es gibt/gab genug Anwendungen, wo der völlig ausreichend war. Zumindest, wenn man bereit war, in Assembler zu programmieren.
Wenn du die Funktionen nur verwendest um den Code übersichtlicher zu machen kannst du auch inline Funktionen verwenden, da wird der Funktionscode an der Aufruf-Stelle direkt eingebunden
Ja, es geht hier aber nur um Assembler, den ATtiny12 kann man nicht in C programmieren.
crazy horse schrieb: > Tja, den Chip so billig wie möglich zu produzieren. Komischer Weise hatte aber der Vorgänger ATtiny22 SRAM und nen echten Stack. Aber statt darauf aufzubauen, wurde der wieder eingestampft. ATtiny11,12,15,13 waren völlig überflüssige Entwicklungen. Einfach vom ATtiny22 direkt zum ATtiny25,45,85 hätte wirklich Kosten gespart. crazy horse schrieb: > Zumindest, > wenn man bereit war, in Assembler zu programmieren. Nö, auch da ist der viel zu klein. Hierbei habe ich mich ganz schön anstrengen müssen, um damit auszukommen: Beitrag "DCF77-Uhr mit ATTINY12" Ich hab mir dazu extra einen Pseudo-Call entwickelt für einmal aufgerufenen Funktionen. Und ich hab auch Funktionen zusammen fassen müssen. Peter
Leute es geht hier nicht um den Tiny, oder um Pro und Contra HW Stack. Der TE will nunmal den Tiny12 nutzen, so what? Schreibt doch ein Buch "Welcher AVR finde ich am besten", oder erzählts eurem Friseur ;-) Ist doch auch mal Spannend auf so einem Teil zu proggen, da kommts dann nämlich auch auf etwas mehr Skill an. Also zum Thema: Klar ist, auf nem HW Stack Controller macht man keine unsinnigen UP Aufrufe nur weils dann schöner aussieht. Und ein sinnloses rumjumpen macht den Code unübersichtlich. Einer der Gründe warum goto und Basic überhaupt derart in Veruf geraten sind (abgesehen vom geschwätzigen Syntax von Basic) Obwohl man in C goto durchaus einsetzen kann und darf, wenn man es richtig und umsichtig tut. Das nur mal so am Rande. Modulkonzept ist ja in der Programmierung schön und gut und übersichtlich, hat aber IMO auf einem winzigen Controller und bei Programmierung mit Assembler nicht viel zu suchen. Dazu kommt ja noch, dass ein UP Aufruf oder Goto in Assembler lange nicht so übersichtlich und selbsterklärend ist, wie in C. Wenn in C da steht: "tuwas();", sieht man sofort was getan wird, sofern die Funktion korrekt benannt ist, in ASM muss man das über Kommentare lösen und damit häßlich. Also Code der zusammengehört, auch zusammen aufschreiben und nicht künstlich zerteilen dann klappts sowohl mit der Übersichtlichkeit als auch mit dem Stack. So Vorlesung für heute beendet. gruß cyblord
cyblord ---- schrieb: > Wenn in C da steht: "tuwas();", sieht > man sofort was getan wird, sofern die Funktion korrekt benannt ist, in > ASM muss man das über Kommentare lösen und damit häßlich. Was bitte ist an call tuwas komplexer als tuwas(); Gruß, Christian
Christian Erker schrieb: > cyblord ---- schrieb: >> Wenn in C da steht: "tuwas();", sieht >> man sofort was getan wird, sofern die Funktion korrekt benannt ist, in >> ASM muss man das über Kommentare lösen und damit häßlich. > > Was bitte ist an > > call tuwas > > komplexer als > > tuwas(); > > Gruß, > Christian In diesem Fall nichts, aber was ist mit Parameterübergabe und Rückgabe. Aber ich gebe zu, das Beispiel war nicht gut gewählt.
Man kommt je nach dem auch gänzlich ohne rcall aus, man muss halt wirklich gut kommentieren so dass man nicht den Überblick verliert. Über Sinn und Unsinn kann man sich streiten. Fakt ist (bei meinem vorletzten Projekt), dass ich rcall sinnvoll höchstens in der Hauptroutine gebraucht hätte. Diese dauert durch mehrmalige Definitionen und andere hässliche Optimierungen nur 40 Takte. Eine strukturierte Programmierung hätte die Routine mindestens um Faktor 2 verlangsamt, wäre jedoch deutlich kleiner gewesen (schätzungsweise 80-90%).
Hi >Man kommt je nach dem auch gänzlich ohne rcall aus, man muss halt >wirklich gut kommentieren so dass man nicht den Überblick verliert. Bei maximal 500 Befehlen den Überblick verlieren? MfG Spess
spess53 schrieb: > Bei maximal 500 Befehlen den Überblick verlieren? Das geht gut, schau dir den Code mal an: Beitrag "17 Kanal Avr Synthesizer in Asm" Die gesamte Code besteht aus gut 500 Befehlen. Auf Anhieb blickst du wahrscheinlich nicht durch. Ich muss aber auch zugeben, dass in der geposteten Version noch ein paar Bugs sind, aber die sieht man nicht so schnell.
HI
>Die gesamte Code besteht aus gut 500 Befehlen.
Was hat 'der Programmierer behält den Überblick' mit 'Auf Anhieb blickst
du wahrscheinlich nicht durch' zu tun?
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.