ATtiny12 Stacktiefe

3*9bit Stack -> 3 Unterprogramme bzw. 2 + ISR

Was ist mit dem Stack aus dem Hauptprogramm?

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

Hatte den halt noch daheim rumfliegen...

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

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.

Ok, überzeugt.