Frage zu SRAM-Testfunktion

[Frank (Gast)]

Hallo,
ich habe gerade ein Programm geschrieben, mit welchem ich Werte auf dem 
internen SRAM des Mikrocontrollers, in meinem Fall dem Atmega8515, 
ablegen möchte. Die ganze Aufgabe soll eine Funktion sram_test 
übernehmen, welche als Parameter den SRAM-Bereich und die Anfangsadresse 
des internen SRAMs übergeben bekommt und als Rückgabe einen Pointer 
zurückgeben soll.

Hier ist mein vorläufiges Programm:

#include <avr/io.h>
#include <util/delay.h>  
#include "lcd-routines.h"
#include <stdbool.h>
#include <avr/interrupt.h>
#include <stdio.h>        //nötig zur Benutzung von sprintf-Funktion




uint8_t *ergebnis_ptr;
char buffer[20];

uint16_t sram_anfangsadresse= 0x0060;  //Anfangsadresse des internen SRAMs
uint16_t sram_bereich= 0x0200;      //interner SRAM-Bereich von 512 x 1Byte
uint16_t sram_endadresse= 0x025F;
uint16_t test;


    


uint8_t* sram_test(uint16_t, uint16_t);    //Definition der Funktion



void delay_ms(uint8_t ms)
{
  while(ms>0)
  {
    _delay_ms(1);
    ms--;
  }
}




uint8_t* sram_test(uint16_t anf_adresse, uint16_t bereich)
{
  uint8_t *ptr= (uint8_t*) anf_adresse;    //Pointer an Anfangsadresse von SRAM-Bereich stellen
  uint16_t lauf, inhalt_zelle;


  PORTB &= ~(1<<PB5);    //LED an
  

  for(lauf=0; lauf < bereich; lauf++)    //alle Speicherzellen des internen SRAMs löschen
  {
    *ptr = 0;
    inhalt_zelle= *ptr;
    PORTB ^=(1<<PB7);
    
    
    lcd_setcursor(0,1);    
    itoa(lauf,buffer,10);    
    lcd_string(buffer);      //Ausgabe der Speicherzellennummer des internen SRAMs

    lcd_setcursor(0,2);
    itoa(inhalt_zelle,buffer,10);
    lcd_string(buffer);      //Ausgabe des Inhalts der jeweiligen Speicherzelle

    delay_ms(100);
    ptr++;    //Pointer zur nächsten Zelle weiterschieben
  
  }

  return ptr;    //Adresse zurückgeben, auf die Pointer momentan zeigt
}




  
  
int main(void)
{
  lcd_init();
  DDRB |= 0xFF;  //alle Pins als Ausgang
  PORTB |= 0xFF;  //alle LEDs aus
  
  
  ergebnis_ptr= sram_test(sram_anfangsadresse, sram_bereich);

  test= (uint8_t*) ergebnis_ptr;

  

  while(1)
  {
  
  }



}

Mein bisheriges Problem ist die for-Schleife in der Funktion sram_test. 
Eigentlich möchte ich, dass diese 512 mal durchlaufen wird und 
anschließend die Adresse der letzten Speicherzelle mittels Pointer ptr 
an den Funktionsaufrufer übergeben wird und dort an ergebnis_ptr 
übergeben wird.
Leider ist es momentan so, dass die for-Schleife nachdem sie 512 mal 
durchlaufen wurde, einfach wieder von vorne (mit lauf=0) durchlaufen 
wird. Sie wird also endlos durchlaufen und somit die Funtion sram_test 
nie mehr verlassen.

Da ich mir dieses Phänomen gerade nicht erklären kann, hoffe ich auf 
Hilfe in diesem Forum.

Gruß

[Nichtkönner (Gast)]

> for(lauf=0;

muß es nicht:

> for(lauf==0;

heißen?

[holger (Gast)]

Super Idee das gesamte RAM mit 0 zu beschreiben.
Dabei machst du den Stack kaputt. Vermutlich startet
dein Prozessor einfach neu. Das sieht dann so aus
als würde deine Funktion nie verlassen.

[Dietrich L. (dietrichl)]

Nichtkönner schrieb:
>> for(lauf=0;
> muß es nicht:
>> for(lauf==0;
> heißen?
Nein. Das ist eine Zuweisung (Startwert!) und keine Abfrage.

[Frank (Gast)]

Nichtkönner schrieb:
>> for(lauf=0;
>
> muß es nicht:
>
>> for(lauf==0;
>
> heißen?

ganz sicher nicht. das ist nämlich eine Zuweisung und kein Vergleich

holger schrieb:
> Super Idee das gesamte RAM mit 0 zu beschreiben.
> Dabei machst du den Stack kaputt. Vermutlich startet
> dein Prozessor einfach neu. Das sieht dann so aus
> als würde deine Funktion nie verlassen.

Würde eigentlich das Verhalten erklären. Aber in der Vorlesung haben wir 
schon einmal so etwas mit einem anderen Mikrocontroller gemacht. Da 
haben wir die Speicherzellen nach dem löschen halt dann danach noch mit 
anderen Werten beschrieben, bevor wir die endadresse über den Pointer 
wieder an den Aufrufer übergeben haben.
Was muss ich dann jetzt am Programm ändern damit es funktionieren kann?

Gruß

[Rufus Τ. F. (rufus)]

Frank schrieb:
> Was muss ich dann jetzt am Programm ändern damit es funktionieren kann?

Sicherstellen, daß der "untersuchte" Speicherbereich nicht mit dem 
Stack, dem Heap und dem Speicher für statische/globale Variablen 
übereinstimmt.

[Karl H. (kbuchegg)]

Oder krasser ausgedrückt:

Ohne intime Kentnisse, wo im Speicher der Compiler was anordnet, ist das 
was der TO da macht eine extremst schlechte Idee.

Wer mit einer Hochsprache programmiert, muss akzeptieren, dass er eine 
gewisse Kontrolle abgibt. Dazu gehören die CPU-Register und 
selbstverständlich auch die exakte Verwaltung des Speichers. Arbeitet 
man da am Compiler vorbei, dann kann das enorm ins Auge gehen.

[Frank (Gast)]

Karl Heinz Buchegger schrieb:
> Oder krasser ausgedrückt:
>
> Ohne intime Kentnisse, wo im Speicher der Compiler was anordnet, ist das
> was der TO da macht eine extremst schlechte Idee.
>
> Wer mit einer Hochsprache programmiert, muss akzeptieren, dass er eine
> gewisse Kontrolle abgibt. Dazu gehören die CPU-Register und
> selbstverständlich auch die exakte Verwaltung des Speichers. Arbeitet
> man da am Compiler vorbei, dann kann das enorm ins Auge gehen.

Respekt. Das ist wohl echt das Problem an meinem Programm. Ist es dann 
eigentlich generell zu empfehlen auf dem internen SRAM Daten abzulegen, 
wenn es so kompliziert zu handlen ist?

Ich hab das Programm jetzt mal so abgeändert, dass nur noch die ersten 
62 Speicherzellen des internen SRAMs mit 0 beschrieben werden:

/*Dieses Programm demonstriert die Abspeicherung einer Zeichenkette. Die einzelnen Zeichen werden
immer nach den in der ASCII-Tabelle zugeordneten Werten abgespeichert.*/


#include <avr/io.h>
#include <util/delay.h>  
#include "lcd-routines.h"
#include <stdbool.h>
#include <avr/interrupt.h>
#include <stdio.h>        //nötig zur Benutzung von sprintf-Funktion




uint8_t *ergebnis_ptr;
char buffer[20];

uint16_t sram_anfangsadresse= 0x0060;  //Anfangsadresse des internen SRAMs
uint16_t sram_bereich= 0x0200;      //interner SRAM-Bereich von 512 x 1Byte
uint16_t sram_endadresse= 0x025F;
uint16_t test;


    


uint8_t* sram_test(uint16_t, uint16_t);    //Definition der Funktion



void delay_ms(uint8_t ms)
{
  while(ms>0)
  {
    _delay_ms(1);
    ms--;
  }
}




uint8_t* sram_test(uint16_t anf_adresse, uint16_t bereich)
{
  uint8_t *ptr= (uint8_t*) anf_adresse;    //Pointer an Anfangsadresse von SRAM-Bereich stellen
  uint16_t lauf, inhalt_zelle;


  PORTB &= ~(1<<PB5);    //LED an
  

  for(lauf=0; lauf < (bereich-450); lauf++)    //alle Speicherzellen des internen SRAMs löschen
  {
    *ptr = 0;
    inhalt_zelle= *ptr;
    PORTB ^=(1<<PB7);
    
    
    lcd_setcursor(0,1);    
    itoa(lauf,buffer,10);    
    lcd_string(buffer);      //Ausgabe der Speicherzellennummer des internen SRAMs

    lcd_setcursor(0,2);
    itoa(inhalt_zelle,buffer,10);
    lcd_string(buffer);      //Ausgabe des Inhalts der jeweiligen Speicherzelle

    delay_ms(100);
    ptr++;    //Pointer zur nächsten Zelle weiterschieben
  
  }


  return ptr;    //Adresse zurückgeben, auf die Pointer momentan zeigt
}




  
  
int main(void)
{
  lcd_init();
  DDRB |= 0xFF;  //alle Pins als Ausgang
  PORTB |= 0xFF;  //alle LEDs aus
  
  
  ergebnis_ptr= sram_test(sram_anfangsadresse, sram_bereich);

  test= (uint8_t*) ergebnis_ptr;

  delay_ms(2000);    //zwei Sekunden warten

  itoa(test,buffer,10);
  lcd_clear();
  lcd_setcursor(0,1);
  lcd_string(buffer);    //Adresse von Speicherzelle ausgeben, auf die Pointer am Ende zeigt

  while(1)
  {
  
  }



}

Jetzt scheint das Programm nicht mehr abzustürzen. Was mir allerdings 
immer noch nicht so recht zu funktionieren scheint sind die delay_ms() 
warteschleifen. Denn die laufen wesentlich schneller ab als sie sollten.
Kann das auch daran liegen, dass ich den internen SRAM beschreibe?

Gruß

[Peter D. (peda)]

Ein RAM-Test in einer Hochsprache ist eine ganz schlechte Idee. Er 
zerstört in der Regel benötigte Daten.
Wenn man dem Compiler die Verwaltung des RAM übergibt, dann darf man 
nicht mehr direkt auf den RAM zugreifen.

Schau Dir mal an, wie ein RAM-Test auf dem PC funktioniert. Zuerst wird 
der Grafikspeicher getestet. Dann wird die Testroutine in den 
Grafikspeicher kopiert und dort ausgeführt. Nun kann in aller Ruhe der 
gesamte RAM getestet werden. Nach dem Test ist das OS natürlich völlig 
durcheinander gewürfelt. Deshalb wird ein Neustart ausgeführt.

Einen RAM-Test sollte man sich also gründlich überlegen. Ansonsten 
erreicht man dadurch schnell das Gegenteil, d.h. das System wird 
unzuverlässiger.


Peter

[Frank (Gast)]

Peter Dannegger schrieb:
> Ein RAM-Test in einer Hochsprache ist eine ganz schlechte Idee. Er
> zerstört in der Regel benötigte Daten.
> Wenn man dem Compiler die Verwaltung des RAM übergibt, dann darf man
> nicht mehr direkt auf den RAM zugreifen.
>
> Schau Dir mal an, wie ein RAM-Test auf dem PC funktioniert. Zuerst wird
> der Grafikspeicher getestet. Dann wird die Testroutine in den
> Grafikspeicher kopiert und dort ausgeführt. Nun kann in aller Ruhe der
> gesamte RAM getestet werden. Nach dem Test ist das OS natürlich völlig
> durcheinander gewürfelt. Deshalb wird ein Neustart ausgeführt.
>
> Einen RAM-Test sollte man sich also gründlich überlegen. Ansonsten
> erreicht man dadurch schnell das Gegenteil, d.h. das System wird
> unzuverlässiger.
>
>
> Peter

Eigentlich möchte ich ja eigentlich nicht wirklich den SRAM testen (dass 
der richtig arbeitet glaub ich einfach), ich möchte mehr einfach Daten 
auf dem SRAM ablegen und sie später wieder auslesen und dabei die 
abgelegten Daten kontrollieren.
Ist es dann eigentlich generell eine schlechte Idee Daten auf dem 
internen SRAM abzulegen? Was gibt für Alternativen?

Gruß

[spess53 (Gast)]

Hi

>Ist es dann eigentlich generell eine schlechte Idee Daten auf dem
>internen SRAM abzulegen?

Eher üblich. Allerdings solltest du, wenn du nicht in Assembler 
programmierst, die Verwaltung der Daten deinem Compiler überlassen.

>Was gibt für Alternativen?

Z.B. Arrays.

MfG Spess

[Peter D. (peda)]

Frank schrieb:
> ich möchte mehr einfach Daten
> auf dem SRAM ablegen und sie später wieder auslesen und dabei die
> abgelegten Daten kontrollieren.

Wo ist das Problem?
Du legst Dir einfach Variablen an und dann kannst Du dort Daten ablegen 
und wieder auslesen.


Peter

[Frank (Gast)]

spess53 schrieb:
>>Was gibt für Alternativen?
>
> Z.B. Arrays.
>
> MfG Spess

Stimmt eigentlich. Dann war das was wir beim Studieren da im Praktikum 
gemacht haben also echt nur ein reiner Test des SRAMs. Dachte irgendwie, 
dass sich das SRAM zum Abspeichern von Informationen eignet.
Aber dann weiß ich jetzt wenigstens, dass das Ablegen abspeichern von 
Daten im internen SRAM keine arg sinnvolle Maßnahme ist.

Gruß

[Matthias S. (Firma: matzetronics) (mschoeldgen)]

Doch klar, machen wir alle so. Nur nageln wir sie nicht auf feste 
Adressen, sondern lassen es den Compiler machen.
Also z.B. :

uint_8t myArray[200];

 reserviert mir einen 200 bytes Bereich , in dem ich indiziert Daten 
anlege oder rauslese.
Den kann ich auch beliebig löschen:

for (i=0;i<201;i++){
   myArray[i]=0;
  }

[Peter D. (peda)]

Frank schrieb:
> Aber dann weiß ich jetzt wenigstens, dass das Ablegen abspeichern von
> Daten im internen SRAM keine arg sinnvolle Maßnahme ist.

Huch, das ist mir neu.
Jeder legt in C Daten im RAM ab, was soll er denn sonst damit machen?

Nur werden die Daten über den Variablennamen angesprochen und nicht über 
eine RAM-Adresse.
Die Adresse interessiert daher nicht.


Peter

[Tilo (Gast)]

Frank schrieb:
> Eigentlich möchte ich ja eigentlich nicht wirklich den SRAM testen (dass
> der richtig arbeitet glaub ich einfach), ich möchte mehr einfach Daten
> auf dem SRAM ablegen und sie später wieder auslesen und dabei die
> abgelegten Daten kontrollieren.
> Ist es dann eigentlich generell eine schlechte Idee Daten auf dem
> internen SRAM abzulegen? Was gibt für Alternativen?

Das kann man schon machen.
Wenn die Größe des Datensatz bekannt ist, kannst du ein festes Array 
verwenden.
Wenn die größe des Datensatz unbekannt ist, kannst du dynamische 
Speicherverwaltung mit new/delete verwenden. Der Zugriff erfolgt dann 
über einen Pointer, die Daten liegen im Heap.

Was willst du mit der Kontrolle erreichen? Reicht dafür eine Prüfsumme?
Musst du auch kontrollieren, ob das Programm korrekt ist?

[H.Joachim S. (crazyhorse)]

Und allein das spart einen Riesenteil der Fehler ein, die man 
unweigerlich macht, wenn man die Speicherzellen/Adressen selbst 
verwaltet.