Takterzeugung in Assembler sinnvol?

Claudio Hediger schrieb:

> Ist es sinnvoll solch ein Signal mit dem AVR mit ein bisschen Assembler
> zu erzeugen?

Und was erhoffst du dir dabei von Assembler?

Deinen Takt kann der Timer des AVR ganz alleine erzeugen. Ein paar 
Konfigurationsbits richtig setzen und du hast deinen Takt an einem Pin.
(Das ist eine PWM mit einstellbarem TOP Wert und einem Comparewert genau 
in der Mitte).

> Mit welchen Maximalen Taktraten kann ich in etwa rechnen bei einem 12Mhz
> bzw. einem 20MHz AVR Takt?

theoretisch müsste man auf die Halfte der Taktfrequenz kommen.
Die eigentliche Frage ist aber eine andere: Wie genau kannst du von der 
Maximalfrequnz ausgehend abstufen und ist es erlaubt bei hohen 
Frequenzen von 1:1 abzuweichen.

Karl heinz Buchegger schrieb:
> theoretisch müsste man auf die Halfte der Taktfrequenz kommen.
> Die eigentliche Frage ist aber eine andere: Wie genau kannst du von der
> Maximalfrequnz ausgehend abstufen und ist es erlaubt bei hohen
> Frequenzen von 1:1 abzuweichen.

Die Maximalfrequenz ist eigentlich irrelevant. Es spielt also keine 
rolle ob es 1MHz 2 oder 5MHz sind. Wobei 5MHz ein idealer Wert sein 
dürfte.

Ich nehme an, das ich durch Setzen eines Flags den Timer direkt Starten 
kann oder?

Karl heinz Buchegger schrieb:
> und ist es erlaubt bei hohen
> Frequenzen von 1:1 abzuweichen.

Ja es ist minim erlaubt

Claudio Hediger schrieb:

> Ich nehme an, das ich durch Setzen eines Flags den Timer direkt Starten
> kann oder?

So ist es.
Vorteiler setzen    -> der Timer läuft
Vorteiler wegnehmen -> der Timer steht

Karl heinz Buchegger schrieb:
> So ist es.
> Vorteiler setzen    -> der Timer läuft
> Vorteiler wegnehmen -> der Timer steht

Ok sehr schön :)

Und damit ich weiss wie viele Takte bereits ausgegeben wurden, wäre es 
meiner meinung nach die beste lösung eine Variable in der Interrupt 
Funktion des Timers zu erhöhen. Was meinst du?

Claudio Hediger schrieb:
> Karl heinz Buchegger schrieb:
>> So ist es.
>> Vorteiler setzen    -> der Timer läuft
>> Vorteiler wegnehmen -> der Timer steht
>
> Ok sehr schön :)
>
> Und damit ich weiss wie viele Takte bereits ausgegeben wurden, wäre es
> meiner meinung nach die beste lösung eine Variable in der Interrupt
> Funktion des Timers zu erhöhen. Was meinst du?

Dass du dann bei hohen Taktfrequenzen Schwierigkeiten kriegen wirst, 
weil auch der ISR Aufruf und dessen Abarbeitung Zeit braucht.

Claudio Hediger schrieb:

> Wäre es denn im ISR Aufruf sinnvoll direkt mit Assembler befehlen den
> eigenen Zähler zu erhöhen und zu prüfen, ob der gewünschte wert bereits
> erreicht ist?

In dem Fall bin ich tatsächlich geneigt 'ja' zu sagen.
Nicht weil der Compiler erhöhen und Abfrage nicht genausogut hinkriegst 
wie du selber.
Sondern, weil du höchst wahrscheinlich einen besseren Funktion 
Prolog/Epilog hinkriegst als der Compiler.

Claudio Hediger schrieb:
> Karl heinz Buchegger schrieb:
>> Dass du dann bei hohen Taktfrequenzen Schwierigkeiten kriegen wirst,
>> weil auch der ISR Aufruf und dessen Abarbeitung Zeit braucht.
>
> Wäre es denn im ISR Aufruf sinnvoll direkt mit Assembler befehlen den
> eigenen Zähler zu erhöhen und zu prüfen, ob der gewünschte wert bereits
> erreicht ist?

Das kann ebenfalls die Harware erledigen. Einfach das Signal extern auf 
einen Eingang zurückgeben und einen zweiten Timer damit hochzählen 
lassen.

Claudio Hediger schrieb:

> nur noch eine kleine frage, was ist mit prolog und epilog genau gemeint?

http://en.wikipedia.org/wiki/Function_prologue

Claudio Hediger schrieb:

> nur noch eine kleine frage, was ist mit prolog und epilog genau gemeint?

Solange du das fragen musst .... lass Assembler Assembler sein und 
programmiere alles in C.

Das kriegt dir der C-Compiler genauso hin.
Aber ganz so einfach ist es dann auch wieder nicht.
Du willst ja die Frequenz auch einstellen können.

Claudio Hediger schrieb:

> Oh das tut mir leid... anscheinend habe ich da was falsches
> geschrieben...
> Die frequenz muss nicht unbedingt einstellbar sein.

Okay. Kann auch sein, dass ich im Eröffnungsposting etwas rausgelesen 
habe, was nicht dort steht.

Das ändert die Situation allerdings.

D.h. du willst nur eine bestimmte Anzahl an Pulsen möglichst schnell 
rausblasen.

Claudio Hediger schrieb:

> Wie könnte ich die anzahl takte mittels Parameter in der Funktion
> übergeben?

Indem du den Compiler arbeiten lässt :-)

1

#include <avr/io.h>

2

3

void Burst( uint16_t Count )

4

{

5

  while( Count-- )

6

    PINB |= ( 1 << PB0 );

7

}

8

9

int main()

10

{

11

  Burst( 32 );

12

}

wird übersetzt zu (wenn man den Compiler am inlining hindert)

1

  6c:  02 c0         rjmp  .+4        ; 0x72 <Burst+0x6>

2

  6e:  b0 9a         sbi  0x16, 0  ; 22

3

  70:  01 97         sbiw  r24, 0x01  ; 1

4

  72:  00 97         sbiw  r24, 0x00  ; 0

5

  74:  e1 f7         brne  .-8        ; 0x6e <Burst+0x2>

6

  76:  08 95         ret

und das ist doch nicht schlecht. Den 2ten sbiw könnte man noch 
einsparen. Aber sonst sehe ich nicht mehr viel Potential.

Claudio Hediger schrieb:

> Was genau meinst du mit ihn am inlining hindern?

Bei dir passt irgendwie gar nichts zusammen.
Auf der einen Seite willst du alles unbedingt in Assembler machen, auf 
der anderen Seite schimmert immer wieder durch, dass du davon (sagen 
wirs mal freundlich) keine Ahnung hast.

Die Frage gehört auch dazu

> Wie lange dauert denn in diesem fall der assembler code?

genauso wie die hier

> und ist es ein duty cycle cvon 1/1?

die letzte lässt sogar darauf schliessen, dass du von Programmieren 
nicht allzuviel Ahnung hast.

Natürlich ist der Duty Cycle 1:1. In jedem Durchlauf wird der Pin 
getoggelt (in den anderen Zustand gebracht). 1 Durchlauf dauert immer 
gleich lang (bis auf ev. den ersten bzw. den letzten), daher kann der 
Duty Cycle nur 1:1 sein.

Claudio Hediger schrieb:

> Hmmm also Ich habe früher mal mit Assembler die AVRs programmiert...
> das ist jedoch schon ein weillchen her.

Das muss schon sehr lange her sein. Du scheinst so gut wie alles 
vergessen zu haben. Daher wäre es besser, wenn du von der Prämisse 
ausgehst: Ich steig wieder bei 0 ein.

> jedoch war ich irritiert, da beim ASM Code lediglich eine 0 mit sbi
> geschrieben wird

Schau dir bitte im Instruction Set an, was der Befehl sbi wirklich 
macht!
Und was bei neueren AVR ein Bitsetzen am PIN Register bewirkt.

Claudio Hediger schrieb:

> Zudem ist es meiner meinung nach nicht schlimm etwas nicht zu wissen.

Da hast du recht.
Das ist nicht schlimm.

Warum es geht: Wenn du in C schreibst, dann schreib auch in C

Die meisten, die das das erste mal versuchen, wissen gar nicht worauf 
sie sich einlassen, wenn sie Assembler mit C mischen wollen. Die meisten 
denken auch, dass sie den Compiler ja leicht übertrumpfen. So nach dem 
Motto: Ich krieg gerade mal eine for-Schleife im 3ten Anlauf fehlerfrei 
hin, aber hey: so schwer kann das doch nicht sein, den Compiler 
auszustechen.

Wenn du Laufzeit Probleme hast, dann sieh erst mal zu, dass du sie mit 
dem Compiler lösen kannst. Viele Codestellen, die als ineffizienter 
Assemblercode vom Compiler erzeugt werden, haben ihre Ursache darin, 
dass der Programmierer C nicht beherrscht und daher dem Compiler 
entweder zuviele Freiheitsgrade lässt oder dem Compiler Nebenbedingungen 
aufs Auge drückt die ihn am Optimieren hindern.

Auf Assembler weicht man als C-Programmierer nur dann aus, wenn man 
tatsächlich über jeden Takt die Kontrolle braucht und das auch nur dann, 
wenn man sich angesehen hat, was der Compiler erzeugt und man einen Weg 
hat, wie man das besser machen kann.

Gut: Dein Problem ist von der Sorte - jeder Taktzyklus zählt.
Aber auch dann, schreibt man sich immer erst eine entsprechende 
C-Routine, sieht sich an, wie der Compiler das umsetzt und tauscht dann 
Funtkionsinhalte durch Assembler Code aus.

Und dann stellt sich die Frage nach: Wie kriege ich da Argumente rein, 
wie mache ich Dinge variabel so gar nicht mehr. Der Compiler hat das 
Framework erzeugt und nur noch die innersten Konstrukte tausch ich aus.

Als C-Programmiere fängt man so gut wie nie damit an, gleich erstmal 
einen Assemblerteil zu postulieren nur weil man das Gefühl hat, das man 
den brauchen wird.


Wenn dein Auto (deiner Meinung nach) zuviel Sprit braucht, dann kann 
dein erster Gedanke nicht sein, wie du die Verbrennung in den 
Brennkammern optimieren kannst. Sondern du schaust dir zb erst einmal 
den Reifendruck an, nimmst die Dachträger vom Dach etc.

Claudio hediger schrieb:

> Leider kommt damit kein Clock raus :(

Das war auch kein komplettes vollständiges Beispiel, sondern es ging nur 
um die Fragestellung: Was macht der Compiler aus der Schleife in der 
Funktion Burst.

Um das im Assembler Listing zu sehen, muss ich zb keinen Port auf 
Ausgang schalten. Ich kann auch davon ausgehen, dass der µC tatsächlich 
einer von der Sorte ist, der mittels Bitsetzen im Pin Register den 
Ausgabeport toggelt (das hängt aber vom tatsächlichen Typ des AVR-µC ab. 
Ältere können das nicht)

Claudio hediger schrieb:

> Somit würde mir nur noch die Assembler variante bleibe oder sehe ich da
> was nicht?

Und wie würdest du das dann in Assembler schreiben?


(Die C Variante sieht genau gleich aus wie die Assembler Variante. Wenn 
du es in C nicht kannst, kriegst du es auch in Assembler nicht hin. Ich 
kann ehrlich dieses ewige sofortige 'dann muss ichs in Assembler machen' 
schon nicht mehr hören. Für dich scheint Assembler die Lösung aller 
Probleme zu bedeuten)

Schreibs komplett in Assembler, dann stellt sich die Frage schon nicht 
mehr.

Claudio hediger schrieb:

> ich habs nun also so programmiert:

>

1

> void fast_clock(void)

2

> {

3

>   unsigned char ucR16 = 0x02;

4

>   unsigned char ucR17 = 0x00;

5

> 

6

>   while(1)

7

>   {

8

>     PORTC &= ucR17;

9

>     PORTC |= ucR16;

10

>   }

11

> }

12

>

>
> Einfach mal als kleiner test
> Ich komme jedoch auf 1Mhz getaktet ist der AVR mit 12Mhz
> Müsste das nicht flotter sein?

Du möchtest hier keine Variablen benutzen.
Denn dann bleibt dem Compiler nichts anderes übrig, als tatsächlich die 
Operationen so auszuführen, wie du sie hingeschrieben hast

   Wert vom Port holen
   Variablenwert holen
   miteinander verunden
   Wert an den Port schreiben

1

#define CLOCK_PIN   PC1

2

#define CLOCK_PORT  PORTC

3

4

void fast_clock(void)

5

{

6

  while(1)

7

  {

8

    CLOCK_PORT &= ~( 1 << CLOCK_PIN );

9

    CLOCK_PORT |=  ( 1 << CLOCK_PIN );

10

  }

11

}

 1 << CLOCK_PIN ist eine Konstante (0x02). Und erst jetzt ermöglichst du 
dem Compiler zu optimieren was nur geht (sofern der Optimizer 
eingeschaltet ist).

Der Umweg über die #define hat nur den Zweck, die komplette 
Hardwarekonfiguration an einer Stelle beisammen zu haben. Ändert sich 
der Pin, brauchst du das nur beim CLOCK_PIN an einer Stelle ändern und 
neu kompilieren.

1

void fast_clock(void)

2

{

3

  while(1)

4

  {

5

    PORTC &= ~( 1 << PC1 );

6

    PORTC |=  ( 1 << PC1 );

7

  }

8

}

würde genau dasselbe machen, aber die Hardwareinfo ist über mehrere 
Stellen verstreut.

AVR-GCC-Tutorial

Claudio hediger schrieb:
> Karl heinz Buchegger schrieb:
>> void fast_clock(void)
>> {
>>   while(1)
>>   {
>>     PORTC &= ~( 1 << PC1 );
>>     PORTC |=  ( 1 << PC1 );
>>   }
>> }
>
> Ok vielen dank...
>
> Also ich hab das mal soweit getestet....
> Ich komme damit auf etwa 1.2Mhz

Assembler Code ansehen.

Das müsste in eine Schleife

    cbi  ...
    sbi  ...
    rjmp ...

übersetzt werden. Das sind in Summe 6 Takte, d.h du bist bei 12/6 = 2Mhz

Durch Loop Unrolling ginge da noch was, aber wesentlich schneller wirds 
nicht mehr. Und du willst ja auch noch Pulse zählen.

Claudio hediger schrieb:

> Merkwürdigerweise ist das signal alles andere als stabil!
> Es schwankt zwischen 1Mhz und 1.5Mhz hin und her!

Da zweifle ich mal die Verwendung des 12Mhz Quarzes an.

Interne 8Mhz würden bedeuten:

  8 / 6 = 1.33Mhz

und das passt ziemlich gut zu deinen 1.2Mhz. Und auch die Schwankungen 
würden sich dadurch erklären.

-> Fuse-Bits ansehen, ob der Mega tatsächlich auf Quarz gefused ist.

Claudio hediger schrieb:
> Hmmm also wenn ich den Quarz entferne läuft nix mehr

OK. Das genügt mir um den Quarz zu akzeptieren. Das ist ein deutliches 
Indiz.
Aber ein Quarz schwingt nicht so unregelmässig (ausser er ist defekt)

Irgendwelche Interrups aktiv?

Claudio hediger schrieb:

> Ich habe den quarz kurzerhand ausgetauscht... Leider das selbe ergebnis

Hmm.
Gibts doch gar nicht.

Das Messverfahren ist über jeden Zweifel erhaben?

Claudio hediger schrieb:

> das duty cycle ist 8:2 (2 ist low)
>
> Kann man das noch etwas optimieren?


Jetzt ist der Zeitpunk, an dem man auf Assembler muss

Aus

1

  4c:  a9 98         cbi  0x15, 1  ; 21

2

  4e:  a9 9a         sbi  0x15, 1  ; 21

3

  50:  01 97         sbiw  r24, 0x01  ; 1

4

  52:  00 97         sbiw  r24, 0x00  ; 0

5

  54:  d9 f7         brne  .-10       ; 0x4c <fast_clock+0x2>

6

  56:  08 95         ret

muss

1

        cbi  0x15, 1  ; 21

2

        sbiw  r24, 0x01  ; 1

3

        sbi  0x15, 1  ; 21

4

        brne  .-8

5

        ret

werden. Dann sollte sich ein 1:1 Verhältnis einstellen.
Das kriegen wir nicht mehr in C gebacken, weil wir ihm nicht 
vorschreiben können, dass er Teile des Schleifenkonstrukts mitten 
zwischen die Setz und Lösch Anweisungen reinziehen soll.
Ich bin in inline_Assembler aber zu schwach. Mit diesen Clobber Listen 
hab ich so meine liebe Mühe :-)
Aber ich probiers mal, wenn ich zu Hause bin.

MWS schrieb:
> Karl Heinz, will Dir jetzt den Spaß nicht verderben ;-)

Ganz im Gegenteil.
Wenn Assembler vermeidbar ist, dann umso besser

>

1

unsigned int Ctr = 65535;

2

> while(Ctr)

3

> {

4

>   PORTC |= ( 1 << PC1 );

5

>     Ctr--;

6

>       PORTC &= ~( 1 << PC1 );

7

> }

Kopfklatsch.
Manchmal ist alles so naheliegend und man siehts trotzdem nicht.
Ich war so sehr auf
   while( Ctr-- )
fixiert, dass ich in die Richtung gar nicht nachgedacht habe.

Danke.

spess53 schrieb:
> Hi
>
> Mal ehrlich. Mit Assembler wäre man schon zehn mal fertig. Statt dessen
> wird hier tagelang mit C Problemen herum gedoktert, die man ohne C nicht
> hätte.
>

Übertreib nicht.
Ein C-Kundiger hat die Schleife genauso schnell, wie du das alles in 
Assembler (ok. bei der Schleife hab ich etwas geschlafen um sie auf 1:1 
zu bringen)
Und vom ganzen Rest rundherum reden wir mal nicht :-)

Wenn sich Vuvuzelatus spielen will, soll er das tun.
Für den Rest ist

1

void Burst( unsigned int Ctr )

2

{

3

  while(Ctr)

4

  {

5

    PORTC |= ( 1 << PC1 );

6

    Ctr--;

7

    PORTC &= ~( 1 << PC1 );

8

  }

9

}

perfekt und spielt alle Stückchen die man braucht.