Atmel und SRAM, timing

Hallo,

18Mhz sind 55ns Pro Takt

Einfach zwei:
asm("nop");

solten reichen

VG

Bei 10Mhz und ohne delay hättest du 100ns.
Bei 20Mhz und mit einem NOP auch.

Mit deinen 14Mhz Taktfrequenz geht nur 140ns.

1

PORTD &= ~WE;

2

asm volatile ("nop");

3

PORTD |= WE;

Micha schrieb:
> der einen 70ns SRAM schreiben soll

Da dürfte eigentlich kein Delay nötig sein, der WE-Inpuls darf 
wesentlich kürzer als 100 ns sein. Du könntest aber ein oder ein paar 
Assembler-NOPs einfügen. Und aufpassen dass nichts weg optimiert wird.

Ich vermute, das Delay ist eigentlich nach dem Setzen der Daten 
notwendig.

Gruss Reinhard

Ach, es waren ja 18Mhz. Also kommst Du auf 110ns.

Vielen Dank für die Tips!
Der Code ganz oben hatte ohne das delay teilweise funktioniert, mit 
gelegentlichen Aussetzter, d.h. es kamen manchmal aber nicht immer die 
richtigen Daten im SRAM an.
Das mit dem nop liest sich nach einer guten Idee. Unklar ist mir 
momentan die Bedeutung des "volatile" bei einem der beiden Vorschläge, 
diese Inline-Assembler Statement zu verwenden.

Vorschläge bezügl. uC mit Speicher-Interface, Interrupt sowie 
Hardware-Handshake für die ser. Schnittstelle machen Sinn, kommen aber 
für mich im gegebenen Kontext kurzfristig nicht in Frage (Schaltung 
schon aufgebaut, Firmware auch fast komplett).

Ohne volatile darf der Compiler das nop weg optimieren, wenn er meint, 
dass es nicht gebraucht wird. Volatile verhindert das.

wow - das ist interessant!
Hab noch nie in die Header-Definition von _delay_us geschaut, immer 
angenommen dass da nur eine Ganzzahl als Argument geht. Jetzt sehe ich 
dass das Argument von Typ double ist.

nachdem ich endlich zu Hause war und es ausprobieren konnte:

funktioniert wirklich! _delay_us kann mit einer gebrochenen Zahl als 
Argument verwendet werden. Da wär ich allein NIEMALS drauf gekommen.

Für mich galt immer die felsenfeste 'IMPLICIT ASSUMPTION' dass _delay_us 
ein Ganzzahl-Argument erwartet. Möglicher Grund: bei Microcontrollern 
wie den Atmels hat man normalerweise fast nie was mit Fliesskomma-Zahlen 
zu tun.

Was mich ausserdem begeistert: dass das Statement _delay_us(0.1) 
offenbar schon zu Compile-Zeit umgesetzt wird und nicht erst zur 
Laufzeit - dann wär es ja ziemlich gaga, trotzdem beeindruckend dass ein 
moderner Compiler das so hinbekommt...

Micha schrieb:

> Für mich galt immer die felsenfeste 'IMPLICIT ASSUMPTION' dass _delay_us
> ein Ganzzahl-Argument erwartet. Möglicher Grund: bei Microcontrollern
> wie den Atmels hat man normalerweise fast nie was mit Fliesskomma-Zahlen
> zu tun.

Das Lustige ist: Das bekommt er hier auch nicht. Alles, was mit dieser 
Float-Zahl passiert, passiert bereits zur Compile-Zeit.

> Was mich ausserdem begeistert: dass das Statement _delay_us(0.1)
> offenbar schon zu Compile-Zeit umgesetzt wird und nicht erst zur
> Laufzeit - dann wär es ja ziemlich gaga

Im konkreten Fall wäre es (außer für die Codegröße) scheißegal, nichts 
eignet sich schließlich besser zum Bremsen als 
Fließkommazahlen-Berechnungen.

> trotzdem beeindruckend dass ein
> moderner Compiler das so hinbekommt...

Das hat mit modernem Compiler oder nicht rein garnichts zu tun. Das 
hängt nur am Vorhandensein und der Mächtigkeit eines Präprozessors. Geht 
also z.B. in Assembler ganz genauso.