- LiFePO4 Speicher Test         
Seite 1 von 2 12 LetzteLetzte
Ergebnis 1 bis 10 von 20

Thema: Timing für SRAM 62256 (32k x 8) gesucht

  1. #1
    Erfahrener Benutzer Roboter Experte
    Registriert seit
    22.11.2005
    Ort
    Braunschweig
    Alter
    47
    Beiträge
    685

    Timing für SRAM 62256 (32k x 8) gesucht

    Anzeige

    LiFePo4 Akku selber bauen - Video
    Moin allerseits!
    Mittlerweile habe ich es doch hinbekommen, mein SRAM an einen Mega32 zu hängen, allerdings hab ich nun noch ein kleines Problem, ich vermute mit dem Timing. Zu Testzwecken habe ich eine kleine Routine geschrieben, die einfach einen Wert schreibt und anschließend wieder ausliest. Aber leider scheint das Schreiben gelegentlich fehlzuschlagen, sprich, ich schreibe an jede Speicherstelle eine '0' und lese anschließend das ganze aus, dann hab ich in den 32K so ca. 10 falsche Bytes, wiederhole ich den Spaß ein paar mal, werden die Fehler immer weniger.
    Durch ändern der Timings kann ich die Fehlerrate ändern (ich habe im Moment zwischen jeder Pinänderung eine Verzögerung mit _delay_us() eingebaut), aber selbst wenn ich eine Verzögerung im ms-Bereich nehme, tauchen Fehler auf. Hat jemand einen Tipp. wo das Timing von so einem SRAM ausführlich beschrieben ist?
    Danke schonmal!!

  2. #2
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    07.12.2005
    Ort
    Euskirchen-Großbüllesheim
    Alter
    74
    Beiträge
    2.063
    Hallo,
    auf dem SRAM sollte nach dem xxx 62256 noch eine Zahl stehen, die Zugriffszeit wie z.B. 70 = 70 ns oder 120 = 120ns oder 12 = 120ns.
    µs oder ms gibt's nicht mehr, das sind Ewigkeiten.
    Da stimmt im Ablauf der Ansteuerung was nicht.
    Zum Lesen:
    1. Adresse anlegen
    2. Chip Select anlegen (oder immer auf GND)
    3. RD-Signal auf Low
    4. nach der Zugriffszeit Daten vom Bus einlesen
    5. RD-Signal auf High

    Zum Schreiben:
    1. Adresse anlegen
    2. Daten anlegen (kann zusammen mit der Adresse angelegt werden)
    3. Chip Select anlegen (oder immer auf GND)
    4. WR-Signal auf Low
    5. nach der Zugriffszeit WR-Signal auf High

    Das Umschalten der I/O-Pins zum Lesen = Eingänge oder Schreiben = Ausgänge nicht vergessen.
    MfG Karl-Heinz
    HobbyElektronik hier klicken ....

  3. #3
    Erfahrener Benutzer Roboter Experte
    Registriert seit
    22.11.2005
    Ort
    Braunschweig
    Alter
    47
    Beiträge
    685
    Hallo!
    Das RAM hat 80ns Zugriffszeit, da kann ich ja eigentlich mit meinem händischen Protokoll gar nicht zu schnell werden...
    Die Verzögerungen habe ich nur zum Debuggen eingebaut.

    Folgendermaßen verdrahtet:

    PORTA an 2 Latches 74hc573n und an I1-I8 vom RAM
    Ausgänge der Latches an A0-A14, und CS vom RAM
    PB0 an Latch LE für A0-A7, OE vom Latch auf GND
    PB1 an Latch LE für A8-A15, OE vom Latch auf GND
    PB2 an WE vom RAM
    PB3 an OE vom RAM


    Das Lesen aus dem SRAM funktioniert auch wunderbar ohne irgendwelche Verzögerungen. Inzwischen habe ich auch eine art Verify eingebaut, wo er den grad geschriebenen Wert auslesen und bei Nichtübereinstimmung nochmal schreiben soll, aber irgendwie klappt das nicht. Die falschen Werte stehen auch immer mal woanders und variieren in der Anzahl...

    hier der Code :
    Code:
    #include <memory.h>
    #include <util/delay.h>
    #define r 1
    #define w 5
    
    void initinterface(unsigned char value)
    
    {
    	// unsigned int addr;
    	DDRA=0;
    	PORTA=0;
    	DDRB |= 15;
    	PORTB |= (1<<WE);
    	PORTB |= (1<<OE);
    	PORTB &= ~(1<<LE_low);
    	PORTB &= ~(1<<LE_high);
    
    /*	for (addr=0;addr<65535;addr++)
    	{
    		writemem(addr,value);
    	}
    */
    }
    
    void writemem(unsigned int addr, unsigned char value)
    {
    	unsigned char check;
    
    	PORTB |= (1<<WE);		//WE auf high
    	PORTB |= (1<<OE);		//OE auf high
    	
    	DDRA=0xff;	//PORTA als Ausgang
    	
    	PORTA = (addr >> 8);	//Highbyte der Adresse ausgeben
    	PORTB |= (1<<LE_high);	//Latch 1 input enable
    	 _delay_us(w);
    	PORTB &= ~(1<<LE_high);	//Latch 1 input disable
    	 _delay_us(w);
    	PORTA = (addr & 255);	//Lowbyte der Adresse ausgeben
    	 _delay_us(w);
    	PORTB |= (1<<LE_low);	//Latch 2 input enable
    	 _delay_us(w);
    	PORTB &= ~(1<<LE_low);	//Latch 2 input disable
    	 _delay_us(w);
    	PORTB &= ~(1<<WE);		//WE auf low
    	_delay_us(w);
    	PORTA = value;			//Daten ausgeben
    	_delay_us(w);
    	PORTB |= (1<<WE);		//WE auf high
    	_delay_us(w);
    	
    	// check
    	do
    	{
    		DDRA = 0;
    		PORTA = 0;
    		PORTB &= ~(1<<OE);		//OE auf low
    		_delay_us(w);
    		check = PINA;			//Daten lesen nach 'value'
    		_delay_us(w);
    		PORTB |= (1<<OE);		//OE auf high
    	
    		if (check != value)
    		{
    			DDRA=0xff;
    			PORTB &= ~(1<<WE);		//WE auf low
    			_delay_us(w);
    			PORTA = value;			//Daten ausgeben
    			_delay_us(w);
    			PORTB |= (1<<WE);		//WE auf high
    			_delay_us(w);
    		}
    	}
    	while (check != value);
    
    }
    
    unsigned char readmem(unsigned int addr)
    {
    	unsigned char value;
    
    	PORTB |= (1<<WE);		//WE auf high
    	PORTB |= (1<<OE);		//OE auf high
    	
    	DDRA=0xff;				//PORTA als Ausgang
    	
    	PORTA = (addr >> 8 );	//Highbyte der Adresse ausgeben
    	PORTB |= (1<<LE_high);	//Latch 1 input enable
    	// _delay_us(r);
    	PORTB &= ~(1<<LE_high);	//Latch 1 input disable
    	// _delay_us(r);
    	PORTA = (addr & 255);	//Lowbyte der Adresse ausgeben
    	PORTB |= (1<<LE_low);	//Latch 2 input enable
    	// _delay_us(r);
    	PORTB &= ~(1<<LE_low);	//Latch 2 input disable
    	_delay_us(r);			
    	DDRA = 0;
    	PORTA = 0;
    	
    	PORTB &= ~(1<<OE);		//OE auf low
    	_delay_us(r);
    	value = PINA;			//Daten lesen nach 'value'
    	PORTB |= (1<<OE);		//OE auf high
    	_delay_us(r);
    	return value;
    }

  4. #4
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    07.12.2005
    Ort
    Euskirchen-Großbüllesheim
    Alter
    74
    Beiträge
    2.063
    Ich kann / mag zwar kein C, sehe aber die Reihenfolge:
    - WE auf low
    - Daten ausgeben
    - WE auf high
    Die richtige Reihenfolge hatte ich im ersten Beitrag bereits angegeben:
    - Daten ausgeben
    - WE auf low
    - WE auf high

    Zum Einlesen ist die Reihenfolge richtig.
    MfG Karl-Heinz
    HobbyElektronik hier klicken ....

  5. #5
    Erfahrener Benutzer Roboter Experte
    Registriert seit
    22.11.2005
    Ort
    Braunschweig
    Alter
    47
    Beiträge
    685
    Hallo!
    Danke für's rüberschauen!
    Oh, die Reihenfolge hatte ich zwischendurch geändert, um den Fehler einzugrenzen und das ganze so in meinem Datenblatt steht. Vorher hatte ich es richtig herum, also Adresse anlegen, Daten anlegen, WE auf LOW, WE auf HIGH, leider trat mein Fehler da auch schon auf....
    Hmm, noch eine schlaue Idee?

    MfG Volker

  6. #6
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    07.12.2005
    Ort
    Euskirchen-Großbüllesheim
    Alter
    74
    Beiträge
    2.063
    Sind Keramik-Kondensatoren 100...220nF unmittelbar an Vcc und GND des SRAM ?
    Evtl. noch einen an den D-Latch's ?
    MfG Karl-Heinz
    HobbyElektronik hier klicken ....

  7. #7
    Erfahrener Benutzer Roboter Experte
    Registriert seit
    22.11.2005
    Ort
    Braunschweig
    Alter
    47
    Beiträge
    685
    Hallo!
    Ups.... nö....

    hab ich total vergessen Hab nur einen am Controller....
    Das werd ich bei gelegenheit versuchen, im Moment hänge ich grad erstmal woanders fest.

    Danke für den Tipp!!

    MfG Volker

  8. #8
    Erfahrener Benutzer Roboter Experte
    Registriert seit
    22.11.2005
    Ort
    Braunschweig
    Alter
    47
    Beiträge
    685
    So, jetzt hängt auch ein Kondensator dran, allerdings passiert immer noch genau das gleiche. Und wenn ich in der Leseroutine nach dem OE=LOW kein _delay_us(1) habe, dann lese ich nicht die Daten aus dem RAM, sondern das zuletzt angelegte Adressbyte... Sind evtl. die Latches zu langsam?
    Der Mega32 läuft übrigens mit 16MHz.
    Ich hab auch noch ein anderes merkwürdiges Problem mit dem RAM, dazu stell ich gleich nochmal ein wenig Code und zwi 'Screenshots' ein.
    Vorab schonmal :
    Ich lese Bilddaten einer GB_CAM, die an einem Tiny26 hängt, blockweise ein, immer 16 Bytes pro Block, schubse ich die Daten gleich per RS232 auf den PC in mein kleines Anzeigetool, dann krieg ich ein schönes Bild, schreibe ich die Daten aber erstmal ins RAM und sende sie anschließend aus dem RAM, sieht es so aus, als würde in X-Richtung eine Art Pixelverdoppelung auftreten, wie gesagt, Bildchen kommen noch, muß nur grad erstmal was essen!!

  9. #9
    Erfahrener Benutzer Roboter Experte
    Registriert seit
    22.11.2005
    Ort
    Braunschweig
    Alter
    47
    Beiträge
    685
    So, ich hab das ganze mal im GCC-Forum fortgesetzt, ich weiß nicht, ob es ein Software oder Hardwareproblem ist....

    MfG Volker

  10. #10
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    07.12.2005
    Ort
    Euskirchen-Großbüllesheim
    Alter
    74
    Beiträge
    2.063
    Das sieht jetzt aber mehr nach einem Software-Problem aus, wenn Du beim Lesen statt der Daten die Adresse zurück bekommst.
    Die Latch's können nicht zu langsam sein, selbst die langsamen CMOS-Typen sind 50ns schnell. Da ist der Mega32 selbst bei 20MHz viel zu langsam.
    Ich tippe auf einen Fehler beim Umschalten auf Eingang / Ausgang ?

    PS: Ich lege immer erst die Daten an das Port und schalte dann das Port auf Ausgang.
    Wird zuerst das Port auf Ausgang geschaltet, liegt das letzte Bit-Muster an den Ausgangspins; dann wird das neue Bit-Muster ausgegeben
    Daraus ergeben sich unnötige Bus-Aktivitäten.
    MfG Karl-Heinz
    HobbyElektronik hier klicken ....

Seite 1 von 2 12 LetzteLetzte

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •  

LiFePO4 Speicher Test