C Programm zu langsam

Peter Zz schrieb:


> void SPI_Send_LL_Word(unsigned long long int Word)

Mach deinem AVR eine Freude und zwinge ihn nicht ...

>     Word >>= 1;

... ständig 64 Bits durch die Gegend schaufeln zu müssen, bzw. ...

>     if (!(Word & 0x01))

... mit 64 Bit hantieren zu müssen, wenns nicht sein muss.



einen unsigned long long kann man in 2 unsigned long aufteilen, die 
wiederum in 2 Stück unsigned int und die in 2 unsigned char.
Prseäntier ihm alles in mungerechten Happen in seiner Lieblingsgröße (8 
Bit), dann läuft der auch zu Hochform auf.

Peter Zz schrieb:
> CKDIV8 habe ich ausgeschaltet.

Und was für eine Quarzfrequenz?

- Wenn man das Problem in 8 bits zerlegen kann, würde sich eine 
Hardware-SPI anbieten, falls möglich und vorhanden.

- Alternativ manuelles Loop-unrolling etwas mehr bringen

- Vielleicht auch mal die Code-Optimierung auf max. einstellen.

Peter Zz schrieb:
> mein C Programm ist sehr langsam.

Peter Zz schrieb:
> void SPI_Send_LL_Word(unsigned long long int Word)

Welcher Compiler?

Die 64 Bit Operationen sind beim AVR-GCC nur sehr unwillig 
implementiert, sogar mit double wärst Du schneller.
Ab AVR-GCC 4.7. ist einiges gepimmt worden, aber ein Schnellläufer ist 
64 Bit trotzdem nicht.

Nimm ein Byte-Array und der AVR läuft Dir davon.


Peter

>>Leider ist dort kein Code-Beispiel, weder in ASM noch in C

echt?
http://www.atmel.com/Images/AVR319.zip

Bei Atmel's AppNote Übersicht gibt's jeweils einen PDF- und Zip 
Download.
(http://www.atmel.com/products/microcontrollers/avr/default.aspx?tab=documents)

Peter Zz schrieb:
> Leider ist dort kein Code-Beispiel, weder in ASM noch in C

Programmieren bedeutet nicht Codebeispiele abzuschreiben oder zu 
kopieren.
Hast du denn mal ausprobiert statt dem unsigned long long ein unsigned 
char array zu benutzen?

1

void SPI_Send_LL_Word(uint64_t Word)

2

{

3

  uint8_t* bytes = (uint8_t*)(&Word);

4

  uint8_t i= 6; // 48bits = 6byte

5

  for( ; i!=0; --i, ++bytes)

6

  {

7

    SPI_Send_Byte(*bytes);

8

  }

9

  PORTB |=  (1 << RCK);

10

  PORTB &= ~(1 << RCK);

11

}

wenn man weiß, dass der Zustand von RCK immer 0 ist, kann man das auch 
optimieren:
PINB =  (1 << RCK); // toggle einmal
PINB =  (1 << RCK); // toggle noch einmal

sbi+cbi brauchen zusammen 4 Takte, 2x out aber nur 2 Takte und ist 
deshalb schneller.

Jörg

Klaus schrieb:
> uC Writer schrieb:
>> - Wenn man das Problem in 8 bits zerlegen kann, würde sich eine
>> Hardware-SPI anbieten, falls möglich und vorhanden.
>
> Ja.
>
>> - Alternativ manuelles Loop-unrolling etwas mehr bringen
>
> Quatsch.
>
>> - Vielleicht auch mal die Code-Optimierung auf max. einstellen.
>
> Unsinn.
Selbstverständlich bringt manuelles Loop unrolling etwas, macht aber aus 
einem Käfer kein Ferrari.

Und wenn man nicht manuell "loop unrolled" macht es vielleicht der 
Compiler, wenn Optimierungen einschaltet sind.

kopfkratzer schrieb:
> Der Tiny84 hat USI in Hardware,

ehrlich gesagt, die USI habe ich bisher noch nicht so richtig 
verstanden.

Meinem Verständis gibt man der die Daten und muss dann trotzdem selbst 
für jedes Bit, was rausgesendet werden soll einen Befehl ausführen.
Von Parallelität also keine Spur. Der einzige Vorteil ist, dass es ein 
klein wenig schneller ist, als Bitbanging, aber sonst ein ziemlich 
verkrüppeltes Interface. Oder hab ich nur das Datenblatt nicht 
verstanden?

kopfkratzer schrieb:
> Vlad Tepesch schrieb:
>> Meinem Verständis gibt man der die Daten und muss dann trotzdem selbst
>> für jedes Bit, was rausgesendet werden soll einen Befehl ausführen.
>
> Nö,
> man stellt ein ob's SPI oder TwoWire ist, definiert ob Master oder Slave
> und dann beschickt man das Register und wartet bis die Hardware den Rest
> erledigt hat, um ein neues Datum einzutragen.
> Ist vergleichbar dem ADC im FreeRunningMode :-)

Das sieht hier
[Beitrag "SPI mit Attiny84"]
aber anders aus. Hab' aber USI nie benutzt.

Vlad Tepesch schrieb:
> Meinem Verständis gibt man der die Daten und muss dann trotzdem selbst
> für jedes Bit, was rausgesendet werden soll einen Befehl ausführen.

Pro Bit sind es 2 Befehle und damit kommt man schon auf F_CPU/2 als 
SPI-Takt.
Schneller ist das ATmega-SPI auch nicht. Nur etwas weniger Code (keine 
16 Out-Befehle nötig).

Im Datenblatt steht auch ein Assembler-Beispiel, leicht auf C 
umzuschreiben:
14.3.2 SPI Master Operation Example

Man muß natürlich trotzdem die lahmen "long long" Variablen vermeiden, 
sonst frißt das die gesparte Zeit fast wieder auf.


Peter

Peter Dannegger schrieb:
> Pro Bit sind es 2 Befehle und damit kommt man schon auf F_CPU/2 als
> SPI-Takt.
> Schneller ist das ATmega-SPI auch nicht. Nur etwas weniger Code (keine
> 16 Out-Befehle nötig).
die SPI mag genauso langsam sein, aber die macht es nebenbei, während 
mein Prozessor was anderes rechnet (zb die nächsten Daten 
zurechtpopelt).
Spi ist quasi fire-and-forget, während die USI eher sowas wie betreutes 
Wohnen ist.

>
> Im Datenblatt steht auch ein Assembler-Beispiel, leicht auf C
> umzuschreiben:
> 14.3.2 SPI Master Operation Example

genau das kenne ich .

Vlad Tepesch schrieb:
> Spi ist quasi fire-and-forget, während die USI eher sowas wie betreutes
> Wohnen ist.

Der Spruch ist geil, den muss ich mir merken :)


MfG Dennis

Vlad Tepesch schrieb:
> die SPI mag genauso langsam sein, aber die macht es nebenbei, während
> mein Prozessor was anderes rechnet (zb die nächsten Daten
> zurechtpopelt).

Diese freien 16 Zyklen bringens natürlich, das ist der absolute Turbo.
Im Ernst, das wirst Du kaum merken.
Und SPI als Interrupt kostet ja schon >20 Zyklen Prolog+Epilog, da wirds 
also sogar langsamer.

Ein merkbarer Unterschied wäre erst, wenn das SPI gepuffert wäre, am 
besten gleich 16 Byte.
Dann könnte man auch SPI-Slave machen, ohne daß der Master immer nach 
jedem Byte lange Gedenkpausen einlegen muß.


Peter