Hallo,
Ich habe versucht ein externes RAM an meinen AT90CAN128 anzuschließen.
Wie ich das mit dem Controller verbunden habe, ist auf dem Ausschnitt
des Schaltplans zu sehen. Ich hab das ganze auch schon mal auf der
Platine durchgemessen, ob irgendwo Kurzschlüsse zu finden sind oder evtl
Pins nicht angeschlossen sind. Dabei ist mir nichts aufgefallen.
Das Problem jedoch ist, dass der RamRiegel falsche Werte zurück liefert.
Das ganze kann man gut bei Textmeldungen über die UART sehen. Teils
stimmen die Buchstaben und das Wort ist auch zu erkennen, aber alles in
Allem sind duzende Buchstabendreher drin.
Also zur Technik:
Im makefile hab ich den Ramriegel so eingebunden:
1
# 32 KB of external RAM, starting after internal RAM
Damit ist alles, außer dem Stack im externen Ram ausgelagert. Jetzt will
ich aber noch den RAM zur Compilerzeit bekannt machen, also noch schnell
die Register bereits im makefile setzen...
1
# List Assembler source files here.
2
# Make them always end in a capital .S. Files ending in a lowercase .s
3
# will not be considered source files but generated files (assembler
4
# output from the compiler), and will be deleted upon "make clean"!
5
# Even though the DOS/Win* filesystem matches both .s and .S the same,
6
# it will preserve the spelling of the filenames, and gcc itself does
7
# care about how the name is spelled on its command-line.
Das sollte doch eigentlich funktionieren, oder? Also ich hab keine
Ahnung mehr. Soweit ich mich erinnern kann, habe ich mit dieser
Einstellung bereits die "langsamste" Betriebsart des RamRiegels gewählt.
Daran sollte es dann auch nicht mehr liegen. Ach ja der 62256 ist von
Conrad (15ns).
Hat jemand ne Idee? Evtl doch schon ein Fehler im Layout?
Hallo,
ein 62256 -15 hat 150ns, nicht 15ns.
Ist ziemlich das langsamste, was man noch so beommen dürfte.
Allerdings habe ich auch schon 120ns Ram mit 16MHz ohne WaitStates
stabil betrieben. Der 74HC573 dürfte dafür aber zu langsam sein, ich
habe meist AC oder ACT drin.
Gruß aus Berlin
Michael
Wieso empfiehlt Atmel eigentlich den AC/AHC? Ich kann laut Datenblatt
keinen einzigen Wert erkennen, der für diesen spricht. Das
Geschwindigkeits begrenzende Kriterium ist der RD\ Impuls, der bei 16MHz
nur rund 50ns hat.
Von AHC rate ich ab, die Dinger funktionieren nur auf einem ordentlichen
Layout mit passender Terminierung usw. Ansonsten verursachen die mehr
Überschwinger als sonst was. Die AC sind OK.
Wieso empfiehlt Atmel eigentlich den AC/AHC? Ich kann laut Datenblatt
keinen einzigen Wert erkennen, der für diesen spricht.
Haben AC oder AHC kleinere Gatekapazitäten? habs nicht nachgeprüft...
Hallo, danke schon mal für die vielen Infos. Auf der Conrad-Seite steht
tatsächlich 15ns für den 62256 und das Datasheet ist immer noch nicht
betrachtbar. Naja. Evtl mal eine kleine E-Mail schreiben :)
Aber zu dem 74HC:
Ich hatte schon mal einen 74HCT573 mit einem V62C518256 bei 16MHz in
Betrieb. HC und HCT sollten doch beide bei ca. 15ns arbeiten, oder?
Meiner Meinung nach ist damit das RAM schuld. Hmm. Wieder viel Lötzeit
fürn **** und noch mehr Lötzzeit für Aus- und Einlöten für die
Zukunft....
Oh. /E hab ich ganz vergessen. Pin20 ist mit ADR15 bzw. PC7 verbunden.
Den SRam, den ich von Conrad bekommen habe, ist in Wirklichkeit ein
IS61C256AH-15J. Sollte laut Datenblatt 15ns schaffen. Wo liegt
eigentlich der signifikante Unterschied zu einem 62256?
Damit weiß ich nun wieder nicht worans liegt :)
Paule_ wrote:
> Den SRam, den ich von Conrad bekommen habe, ist in Wirklichkeit ein> IS61C256AH-15J. Sollte laut Datenblatt 15ns schaffen. Wo liegt> eigentlich der signifikante Unterschied zu einem 62256?
Der 61C256 ist ein Cache SRAM wie er in 486ern für den L2 Cache
verwendet wurde. Der 62256 ist dagegen ein normaler, langsamer SRAM.
Der Geschwindigkeitsunterschied macht sich auch im Stromverbrauch
bemerkbar.
Der 61C256 dürfte auch optisch deutlich anders aussehen als ein normaler
SRAM: Die Cache SRAMs sind im SDIP28/29 untergebracht, die normalen
SRAMs haben dagegen das normale, breite 28/32 DIP.
Als SMD dürften die Cache SRAMs meist SOJ haben, während die normalen
SRAMs meist SOP haben.
Nur in TSOP sind beide erhältlich.
Mal ne Halb-OT-Frage, weil vorhin das Layout angesprochen wurde: Wie
layoutet ihr solche µC-Latch-SRAM-Konstrukte? Ich kann evtl. gleich mal
mein Layout rauskramen, was ich mit überlegt hab. Kommt mir aber noch
nicht so optimal vor...
Ich nehm an, man sollte mit den 3 ICs und allen Adress- und
Datenleitungen mögl. auf einer Ebene bleiben?
Hat mal jemand ein Stück Layout für mich zum anschauen?
Danke im Voraus
Sebastian
Hab das Ganze jetzt nochmal genauer analysiert.
Anscheinend wird immer, wenn ein Fehler beim Lesen vom SRAM oder
vielleicht auch beim Schreiben auftritt, nur ein einzelnes Bit in einem
Byte gedreht und das ist immer das 4-wertige.
Daraufhin habe ich nochmal die Verbindung von AD2 und auf von AD5
geprüft aber kein Problem bzw Unterschied zu den Anderen erkannt.
Lediglich bei AD5 am SRAM direkt mußte ich mich mit einer kleiner
Drahtbrücke behelfen, welche aber auch an GND und ADR6 des gleichen ICS
ähnlich verlötet ist. Die Brücke schließt nur den dort etwas großen
Zwischenraum zwischen PAD und PIN. Leider ist mir dort einfach kein
Lötzinn reingeflossen.
Dieses "Bittauschen" tritt aber nicht immer auf und auch in mir keinem
erkennbaren Muster. Hat irgendjemand eine Ahnung worans leigen
könnte????
Der Fehler ist 100%tig wiederholbar. Sprich neu Programmieren und der
Fehler ist genauso wie vor 10 Programmiervorgängen.
Verdammte Verschreiberei. Kann leider nichts ändern aber in meinem
obigen Post muß es heißen:
zweiter Absatz
"[...]von AD2 und auch von AD5[...]"
"[...]Lediglich bei AD2 am SRAM direkt mußte ich mich mit einer kleiner
Drahtbrücke behelfen,[...]"
OH NO!
Es waren tatsächlich diese 3mm Draht, die alles Zunichte gemacht haben.
Jetzt funktioniert alles einwandfrei bzw. solange bis ich Bitdreher in
ADR6 feststelle, da ist nämlich auf eine Brücke verbaut :)
Danke fürs miträtseln!
Hallo,
der Draht als solcher wohl weniger, eher kalte Lötstelle, weil man nicht
richtig rankommt und zu vorsichtig ist...
Hatte ich letztens bei einem Tiny85 geschafft, die Effekte waren ähnlich
zufällig.
Gruß aus Berlin
Michael
Hier mal mein Layout, noch ohne Stützkondensatoren, RD und WR. Was ich
vor allem blöd finde, ist daß zwei Leitungen aus dem Adress-High-Byte
deutlich länger sind als alles andere. Besser bekomm ichs aber nicht.
Deswegen wollte ich fragen, wie ihr die ICs anordnet.
Vielleicht bin ich da etws vorschnell, aber ich glaube nicht, dass du
aufgrund der Längenunterschiede Probleme bekommst. Das sind wohl eher
Sorgen des HF'lers.
@Mechatroniker
Zum Layout bei RAMs musst Du dir keinen Knick ins Hemde machen. Da ja
der Prozessor schreibt und liest ist es egal, ob Adresspins
untereinander oder Datenbits untereinander vertauscht sind. Im ersten
Fall landet das entsprechende Byte an einer falschen Stelle, wird aber
auch von da gelesen. im zweiten wird das Byte als falscher Wert
geschrieben aber beim Lesen zurück"konvertiert". Probleme treten nur
auf, wenn z.B. EPROMs, EEPROMs oder Flash-Speicher extern beschrieben
und dann eingebaut werden.
Das hab ich aber auch schon benutzt, um komplizierte Layouts zu
vermeiden. Muss man halt beim Programmieren entsprechend umsortieren.
Funktioniert dann aber auch als Schutz gegen Hacker-Anfänger.
ram_con.JPG
(87 KB)
