Forum: Mikrocontroller und Digitale Elektronik Sinustabelle, header und Werte verwenden


von Michael (Gast)


Angehängte Dateien:

Lesenswert?

Hallo,

ich bin recht neu in Sachen µC und versuche mich gerade an SPWM in C für 
µC heran. Dabei fange bei der Sinustabelle (SineLookupTable.h) an. Diese 
sieht, sofern ich es beurteilen kann, auch ganz gut aus (in Excel 
erstellt und Werte dann rüberkopiert).
Nun möchte ich diese Tabelle einer Variablen in meinem Hauptprogramm 
übergeben. Mein Main (SPWM.c) sieht so aus:
1
#include <avr/io.h>
2
#include <util/delay.h>
3
#include <avr/interrupt.h>
4
#include "SineLookupTable.h"
5
6
int main(void)
7
{
8
  uint8_t SineTable[256];
9
  int i;
10
  for(i=0;i<256;i++)
11
    {
12
      SineTable[i]=sinelookup[i];
13
    }  
14
}
Jetzt versuche ich herauszufinden, ob die Werte im Headerfile 
"SineLookupTable.h" an die Variable "SineTable" übergeben werden, weil 
ich später bei der eigentlichen SPWM mit "SineTable" arbeiten wollen 
würde. Aber irgendwie schaffe ich es nicht, den Code vernünftig zu 
debuggen. Anbei ein Screenshot von AVR Studio 4.

Wie kann ich am besten in AVR Studio 4 überprüfen, ob und inwiefern mein 
Code funktioniert?

Ich verwende einen Atmega8 auf einem Steckbrett aufgebaut 
(Minimalbeschaltung), AVRISP mkII zusammen mit AVRStudio 4.

Vielen Dank.

Gruß

von Karl H. (kbuchegg)


Lesenswert?

Michael schrieb:


> Jetzt versuche ich herauszufinden, ob die Werte im Headerfile
> "SineLookupTable.h" an die Variable "SineTable" übergeben werden, weil
> ich später bei der eigentlichen SPWM mit "SineTable" arbeiten wollen
> würde.

Und wozu soll das gut sein?
Die Werte stehen doch schon in einer Variablen. Wozu umkopieren?
Ausser das du einen Haufen Speicher verbrutzelst, hast du damit nichts 
gewonnen.

von Karl H. (kbuchegg)


Lesenswert?

Michael schrieb:

> würde. Aber irgendwie schaffe ich es nicht, den Code vernünftig zu
> debuggen. Anbei ein Screenshot von AVR Studio 4.

Mach einen Einzelschritt mittels F10.
Noch steht der gelbe Pfeil ausserhalb der Funktion main().
D.h. noch ist das Array noch nicht erzeugt worden.

Mach einen Einzelschritt in die Funktion hinein und dann gibt es auch 
das Array. Variablen innerhalb einer Funktion - funktionslokale 
Variablen - werden mit dem Betreten einer Funktion erzeugt und beim 
Verlassen der Funktion zerstört. Ausserhalb dieser Lebensspanne 
existieren sie schlicht und ergreifend nicht. Daher auch "Location not 
valid" - noch existiert die Variable nicht.

von Michael (Gast)


Lesenswert?

Karl Heinz Buchegger schrieb:
> Und wozu soll das gut sein?
> Die Werte stehen doch schon in einer Variablen. Wozu umkopieren?
> Ausser das du einen Haufen Speicher verbrutzelst, hast du damit nichts
> gewonnen.

Damit hast du mir natürlich den Wind aus den Segeln genommen :D

Okay, hast recht, das war nicht sonderlich klug von mir ;)

Dann lasse ich die Idee mit dem umkopieren. Dennoch würde mich 
prinzipiell interessieren, wie ich meinen Code schrittweise debuggen 
kann, bevor ich ganz am Ende alles in den uC packe und feststelle, dass 
nichts geht.

Prinzipiell habe ich mich an dieses Tutorial gehalten:
http://www2.tech.purdue.edu/ecet/courses/ecet309/Reference_Materials/Simulation_AVR_Studio_4.pdf

Aber in meinem Hauptprogramm mit der for-Schleife um dem Kopieren der 
Variable scheint das nicht zu klappen, siehe Screenshot.

Ich hoffe, ich konnte mich klar und verständlich ausdrücken.

von Michael (Gast)


Angehängte Dateien:

Lesenswert?

Karl Heinz Buchegger schrieb:
> Mach einen Einzelschritt mittels F10.
Das ist das Problem. Ich befinde mich beim gelben Pfeil wie im 
Anfangsscreenshot (AVRStudio4.png) zu sehen. Dann drücke ich F10, und 
der gelbe Pfeil springt ans Ende der Main Funktion, siehe zweiten 
Screenshot (Untitled_1.png).
Auch wenn ich F11 drücke, also step into, passiert das gleiche.

Das Verhalten kann ich mir nicht erklären. Es scheint mir, als ob der 
Code innerhalb der Main Funktion nicht ausgeführt wird.

von Karl H. (kbuchegg)


Lesenswert?

Michael schrieb:

> Dann lasse ich die Idee mit dem umkopieren. Dennoch würde mich
> prinzipiell interessieren, wie ich meinen Code schrittweise debuggen
> kann, bevor ich ganz am Ende alles in den uC packe und feststelle, dass
> nichts geht.

Das tust du sowieso nicht :-)
Also das "ganz am Ende alles zum ersten mal in den µC packen".
Du fängst mit deiner Entwicklung so an, dass du möglichst schnell etwas 
hast, womit du auf die reale Hardware gehen kannst und womit du auf der 
realen Hardware möglichst schnell etwas zum testen hast (d.h. da wird 
ein tatsächlicher Output generiert)


> Aber in meinem Hauptprogramm mit der for-Schleife um dem Kopieren der
> Variable scheint das nicht zu klappen, siehe Screenshot.

2.tes Post nicht gesehen?
F10 drücken und einen Singlestep in die Funktion hinein machen

von Michael (Gast)


Lesenswert?

Okay, update:

Es scheint am Code zu liegen (vielleicht wegoptimiert?)

Denn folgender Code funktioniert problemlos:
1
#include <avr/io.h>
2
#include <util/delay.h>
3
#include <avr/interrupt.h>
4
#include "SineLookupTable.h"
5
6
int main(void)
7
{
8
  uint8_t SineTable[256];
9
  DDRB |= (1<<PB1);
10
11
  while(1)
12
  {
13
    PORTB |= (1<<PB1);
14
  }
15
}

Damit springt der Pfeil in die Main rein.

von Michael (Gast)


Lesenswert?

Karl Heinz Buchegger schrieb:
> 2.tes Post nicht gesehen?
> F10 drücken und einen Singlestep in die Funktion hinein machen

Da haben wir uns überlappt. :)

Beitrag "Re: Sinustabelle, header und Werte verwenden"

Gruß

von Karl H. (kbuchegg)


Lesenswert?

Michael schrieb:

> Das Verhalten kann ich mir nicht erklären.

Dein Compiler ist schlauer als du :-)
Der hat schon geschnallt, dass der Code de facto nichts macht.
Eine Variable die im Code nicht in einer Abfrage verwendet wird, braucht 
auch keine Werte zugewiesen bekommen. Denn das ändert nichts an dem, was 
ein Benutzer an den Pins sehen würde.

> Es scheint mir, als ob der
> Code innerhalb der Main Funktion nicht ausgeführt wird.

genau so ist es auch.

Tu was mit den Werten. Dann kann der Compiler das nicht wegoptimieren. 
Oder schalt den Optimizer aus.

Aber im Ernst: wozu willst du das debuggen? Hast du so wenig Vertrauen 
zu deinem Compiler, dass er eine Zuweisung in einer Schleife verbockt?

von Karl H. (kbuchegg)


Lesenswert?

1
int main(void)
2
{
3
  uint8_t SineTable[256];
4
  int i;
5
  for(i=0;i<256;i++)
6
    {
7
      SineTable[i] = sinelookup[i];
8
    }  
9
10
  for(i=0;i<256;i++)
11
    {
12
      PORTC = SineTable[i];
13
    }  
14
}

jetzt kann es natürlich immer noch sein, dass der Compiler schnallt, 
dass SineTable und sinelookup eigentlich das gleiche sind, und SineTable 
rauswirft, weil sich am Programm nichts ändert, wenn er in der 2.ten 
Schleife SineTable durch sinelookup ersetzt.

von Michael (Gast)


Lesenswert?

Hi,

Karl Heinz Buchegger schrieb:
> Dein Compiler ist schlauer als du :-)
Ich befürchte du hast Recht! Ist aber zugegebenermaßen auch nicht 
sonderlich schwer ;)

> Tu was mit den Werten. Dann kann der Compiler das nicht wegoptimieren.
> Oder schalt den Optimizer aus.
Habe ich gemacht, Optimizer ist ausgeschaltet. Nun funktioniert es. Ich 
werde ihn aber wieder einschalten, jetzt wo ich weiß, was wie warum 
passiert ist.

> Aber im Ernst: wozu willst du das debuggen? Hast du so wenig Vertrauen
> zu deinem Compiler, dass er eine Zuweisung in einer Schleife verbockt?
Ich vertraue meinem Compiler schon, nur mir nicht so wirklich :D

Aber vielen Dank für deine Hilfe. Jetzt bin ich wenigstens etwas 
schlauer und kann mich den Timern etc. widmen.

Und ja, natürlich sollte man so  früh wie möglich versuchen, das an der 
Hardware zu testen. Wird auch bald passieren :)

Falls ich weitere Fragen haben sollte, melde ich mich.

Vielen Dank für deine Hilfe bis hierhin :)

Bitte 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
Noch kein Account? Hier anmelden.