Hallo,
ich bin auf der Suche nach einem Rechenintensiven Beispielprogramm für 
den kleinen Atiny2313 in C oder ASM.
Am liebsten wäre mir was ohne externe Hardware also keine Display 
Ansteuerung zum Beispiel. Probiert habe ich selber schon Fibonacci in C, 
bin mir aber sicher das der Kleine auch noch mehr kann.
Gibt es irgendwelche Hash-Wert Implementierungen z.B.? Ich bin sehr 
gespannt auf eure Anregungen und was Ihr schon so schönes damit gemacht 
habt.
Gruß
eac

Ich wollte eigentlich verschiedene Debugger damit testen und vergleichen 
und while(1) gibt mir da nicht so viel Aussage.
Die Zahl Pi auf 1000 Stellen mit einem 8bit µController geht das?
Gruß
eac

Paul E. schrieb:
> Die Zahl Pi auf 1000 Stellen mit einem 8bit µController geht das?

Klar. Das Ergebnis ist 3.0 ;)

Paul E. schrieb:
> ich bin auf der Suche nach einem Rechenintensiven Beispielprogramm für
> den kleinen Atiny2313 in C oder ASM.

int main()
{
  uint64_t i, j;

  DDRB = 0xFF;
  for( j = 0; j; j++ )
    for( i = 0; i; i++ )
      PORTB = i;
  PORTB = 0xA5;   
}

Das ist so rechenintensiv, daß keiner von uns das Ergebnis erleben wird.
Man könnte nachrechnen, ob die Erde dann noch existiert.


Peter

Jo so ungefähr war mein Gedankengang auch. Obwohl ich eine Festkommazahl 
genommen hätte. Dann wären es immerhin 5 Nachkommabits ;-D
Noch andere Vorschläge? Gibt es keine Verfahren mit denen man Daten für 
die Übertragung per Usart z.B. verschlüsselt?
eac

11001000=3.125

Ich weiß schon das die Herausforderung eines Debbugers eher in der 
Peripherie besteht also z.B. Usart mit Stimuli. Dazu sollte aber erst 
mal der innere Kern zu 100% funktionieren. Man könnte sich jetzt  einen 
Testcase aus den Fingern saugen der alle Befehle benutzt, aber ich 
dachte das ein kleines sinnvolles C-Programm mit irgendwelchen 
Berechnungen. Siehe Fibonacci. Das ist dann Realitätsnäher und sinnvoll.
Gruß
eac

Du könntest zum Beispiel Laufzeit-Tests aus GCCs testsuite [1] 
durchnudeln wie zum Beispiel [2] oder [3] falls die Programme nicht 
bereits zu groß für einen ATtiny2313 sind.

Interrupts finden sich in der Testsuite natürlich nicht.

[1]
http://gcc.gnu.org/viewcvs/trunk/gcc/testsuite/gcc...

[2]
http://gcc.gnu.org/viewcvs/trunk/gcc/testsuite/gcc...

[3]
http://gcc.gnu.org/viewcvs/trunk/gcc/testsuite/gcc...

pFFTh schrieb:
> Johann L. schrieb:
>> Interrupts finden sich in der Testsuite natürlich nicht.
>
> Womit diese zum Debugger-Auswählen auch nicht so wirklich taugen.
>
> Das ist als wenn man sich ein Fahrrad für eine Alpenüberquerung danach
> aussucht, ob man damit ohne Platten zum Aldi und zurück kommt.

Nicht ganz. Ein Programm besteht ja nicht nur aus ISRs...
Für nen Debugger ist ja auch die allgemeine Usability wichtig:

• Wie werden rekursive/komplexe Strukturen und Unions dargestellt?
• Wie sieht's mit rekursiven Funktionen aus?
• Und Werten in drunterliegenden Call-Frames?
• Wie werden geinlinte Funktionen dargestellt?
• Wie werden expandierte Makros dargestellt?
• Werden Funktions-Prologe richtig erkannt?
• Auch mit -mcall-prologues? auch mit -maccumulate-args?
• Funktioniert Step-Over auch bei geinlinten Funktionen?
• Wie sieht's mit Function Clonig aus?
• Werden weg-optimierte Variablen angezeigt?
• Welche Debug-Formate werden unterstützt? dwarf-2? dwarf-3? dwarf-4?
• Kommt der Debugger auch mit den Prologen von avr-gcc 4.7 zurecht?
• Wie sieht's mit Plattformunabhängigkeit aus?
• Ist der Debigger skriptbar?
• Hat er einen integrierten Simulator?
• Oder bietet zumindest anbindung an einen Simulator?
• Kann man Programme damit nachladen?
• Hat er eine Socket-Anbindung?
• ...

> Fehler in den Algorithmen debuggt man am Einfachsten, indem man den
> Sourcecode einfach am PC übersetzt und dort ausführt.

Bezüglich der GCC-Testsuite ist jetzt ein Scherz, oder?
Die GCC-Testsuite gehört zur Qualitätssicherung des Compilers.
Was bringt es für einen avr-gcc, den Code für einen PC zu übersetzen
und dort laufen zu lassen?

Ok ich seeh schon, Es gibt viel zu beachten. Außerdem scheint der kleine 
tiny nicht so geeignet zu sein mathematisch anspruchsvolle Dinge zu 
machen.
Der beschränkte Zahlenbereich von 8 bit und der fehlende Hardware 
Multtplizierer erschweren die Sache ungemein.
Gruß
eac

Eben mal angetestet:

#include <math.h>

int volatile A, B, C, D;

float rezi (float a, float b, float c, float d)
{
    return a/b - c*d + a > b;
}

int __attribute__((OS_main))
main (void)
{
    return rezi ((long) A / B, B, C, (long) C*D);
}

Das saugt einiges an Code aus den Libs:

• Vektortabelle
• Startup-Code
• 32-Bit integer * und /
• float +, -, * und /
• float Vergleich
• float → int und int → float Konvertierung

Das belegt ca. 1800 Bytes, und für "einfache" arithmetische Berechnungen 
ist man damit gut gerüstet. Die Codegröße wächst nicht mehr sooo viel 
wenn man das Zeug lediglich verwendet und sich keine weiteren Routinen 
reinzieht.

Man hat also noch ≈250 Bytes für eine Berechnung von π auf 1000 Stellen. 
Das ist zwar sehr ambitioniert, scheint mir aber durchaus im Rahmen des 
möglichen; vor allem weil man keine 32-Bit Arithmetik dazu braucht.

pFFTh schrieb:

> Aber der TE ist keiner der Entwickler des AVR-GCC und will seinen
> Debugger auch sicher nicht dafür verwenden, Fehler im AVR-Backend
> der GCC zu finden.

Oh mann ist das soooo schwer zu verstehen?

1) Der TE fragte nach "Rechenintensiven Beispielprogramm"
2) Ich habe ihm einen Link auf ein Verzeichnis gennannt, das viele
   ausführbare C-Programme enthält, die out-of-the-Box funktionieren.

Nicht mehr und nicht weniger.

Die Programme machen keine Voraussetzungen wie "dieses LCD muss hier und 
so angeschlossen werden" oder "das geht aber nur mit ATmega weil 
Assembler" oder "dafür sind's zu wenig Ports" etc.

Wo die Programme stehen und zu welchem Projekt die gehören ist doch 
sowas von Wurscht, also überlies diese Meta-Info einfach.

Daß die Programme keinen ISR-Code enthalten schrieb ich bereits. Der TO 
wird die Information für sich auszuwerten wissen — irgendwas von "das 
stört überhaupt nicht" bis hin zu "damit ist das uninteressant fü meine 
Zwecke".

Johann L. schrieb:
> Eben mal angetestet:
>
>

#include <math.h>
> 
> int volatile A, B, C, D;
> 
> float rezi (float a, float b, float c, float d)
> {
>     return a/b - c*d + a > b;
> }
> 
> int __attribute__((OS_main))
> main (void)
> {
>     return rezi ((long) A / B, B, C, (long) C*D);
> }

Nicht schlecht, danke!
Mit der math.h rechnet er meine Fibonacci Folge auch gleich mal viel 
länger:

0000000
0000001
0000001
0000002
0000003
0000005
0000008
000000D
0000015
0000022
0000037
0000059
0000090
00000E9
0000179
0000262
00003DB
000063D
0000A18
0001055
0001A6D
0002AC2
000452F
0006FF1
000B520
0012511
001DA31
002FF42
004D973
007D8B5
00CB228
0148ADD
0213D05
035C7E2
05704E7
08CCCC9
0E3D1B0
1709E79
2547029
...

Hier der auch noch der Quellcode zur Vollständigkeit:

/*
 * AVRGCC1.c
 *
 * Created: 10.02.2012 14:10:37
 *  Author: Paul E.
 */ 

#include <avr/io.h>
#include <math.h>
int volatile long a,b,sum;
int main ()
{
  DDRB=255;
  PORTB=a;
  int n;
  n=50;
  fibonacci(n);
  return 0;
}


int fibonacci(int n)
{
  a = 0;
  b = 1;
  sum;
  int i;

  for (i=0;i<n;i++)
  {
  //PORTB=a;
    sum = a + b;
    a = b;
    b = sum;
  }
  return 0;
}

ohne externe Beschaltung verhält sich jedes Programm genauso wie ein
while(1) {}

Paul E. schrieb:

> Mit der math.h rechnet er meine Fibonacci Folge auch gleich mal
> viel länger

Hmmm. Dein Code verwendet die math.h überhaupt nicht.

Mein Schnipsel übrigens auch nicht — my bad. Ich hatte vorher was mit 
pow() versucht, aber das ELF wurde schon viel zu groß für einen 
ATtiny2313. Daher hab ich pow() wieder entfernt und das math.h aber 
drinne gelassen.

Eine aufwändige Berechnung von Fibonacci geht über deren explizite 
Darstellung, die auch verwendet werden kann, um die "rekursiven" 
Ergebnisse zu testen:

mit dem Goldenen Schnitt

Der zweite Summand in fib(n) get rasch gegen 0 und es ergibt sich

Das führt zu folgendem kleinen C-Programm:

#include <math.h>
#include <stdio.h>

float phi;

static unsigned long fib (int n)
{
    return round (pow (phi, n) / sqrt (5));
}

int main (void)
{
    int i;
    
    phi = (sqrt (5) + 1) / 2;
    
    for (i = 0; i < 15; i++)
    {
        printf ("f[%d] = %lu\n", i, fib (i));
    }
    
    return 0;
}

Die Wurzel-Konstanten werden übrigens bereits vom Compiler ausgewertet.

Auf einem ATmega88 ausgeführt (und mit etwas Magie in anderen Modulen, 
um printf transparent funktionsfähig zu machen) erhält man folgende 
Ausgabe:

f[0] = 0
f[1] = 1
f[2] = 1
f[3] = 2
f[4] = 3
f[5] = 5
f[6] = 8
f[7] = 13
f[8] = 21
f[9] = 34
f[10] = 55
f[11] = 89
f[12] = 144
f[13] = 233
f[14] = 377

Wie gesagt ist pow() berweits zu groß für einen tiny2313; das obige 
Programm verschlingt ca 4500 Bytes.

pow() brauch man hier aber nicht unbedingt, denn die Exponenten sind 
ganzzahlig. Man könnte das x^n also auch händlisch implementieren und 
braucht dann nur Multiplikation anstatt pow().