Hallo, ich habe hier einen at89s52 mit dem ich ein eprom auslesen möchte und ich habe es wie im Anhang zu sehen montiert, also nicht über nPSEN sondern über nRD. Er liest nur Blödsinn. Ich benutze "movx a, @dptr" zum lesen. Schimmert es möglicherweise jmd. wo hier etwas nicht stimmt? Der EPROM Speicher ist ein HT27C512. Schönen Gruß!
Ist evtl. der OE vom 74HC573 gemeint ? hat der Pin einen internen Pull Up oder Pull Down oder floatet der nur ?
>Ist evtl. der OE vom 74HC573 gemeint ?
Der muss nat. auf GND, wenn Latch aktiv sein soll.
(\CE vom EPROM hängt hier fest an GND, gibt nat. Buskonflikt, wenn
mehrere Bausteine dran hängen)
Joghurt3000 schrieb: > Ich benutze "movx a, @dptr" > zum lesen. Schimmert es möglicherweise jmd. wo hier etwas nicht stimmt? Mit diesem Befehl gibt man die Adresse an P0 und P2 aus, und liest dann auch an P0 die Daten wieder ein. Da stimmt wohl mit dem Bus was noch nicht ganz. Im Augenblick sehe ich nur, daß P0 Adressen ans Latch ausgeben kann, aber da ist nichts mehr am P0 zum einlesen der Daten. Die 8 Datenleitungen des Speicherbausteines gehören also an P0. P2 hält lediglich nur das High-Byte der Adressen.
>Im Augenblick sehe ich nur, daß P0 Adressen ans Latch ausgeben kann, >aber da ist nichts mehr am P0 zum einlesen der Daten. laut seiner (grässlich lesbaren) Skizze gehen die EPROM-Daten-Leitungen an P0. (falls er dort mit 'ADn' AD0..7 gemeint hat)
Ja, die
Ich habe vergessen es einzuzeichnen. Die Datenleitungen vom ROM gehen an ADn (n=0..7), für die Skizze muss ich mich entschuldigen, aber meine Maus (nicht die Hand) verzieht den Cursor bisweilen (mußte aus diesem Grund eine lukrative Karriere als Quake Tunierspieler leider aufgeben ;-) ). Ein weiteres "Phänomen" was ich vergessen hatte zu erwähnen ist, dass wenn ich nCE vom ROM auf GND lege (momentan ist das noch als freischwingendes Kabel realisiert), dann bootet der 8051 nicht, RST ist of low, GND, VCC entprechend 0,+5V. Nach dem booten kann ich nCE dann snschließen und es läuft alles. (nPSEN ist nicht angeschlossen, EA auf 5v ^= internal flash boot). Vielen Dank für die bisherigen Kommentare. Wenn ich diese richtig interpretiere sollte es also möglich sein ein ROM mit nRD anzuschließen statt nPSEN und dann movx statt movc zu verwenden.
Joghurt3000 schrieb: > Ein weiteres "Phänomen" was ich vergessen hatte zu erwähnen ist, dass > wenn ich nCE vom ROM auf GND lege (momentan ist das noch als > freischwingendes Kabel realisiert), dann bootet der 8051 nicht Was soll denn da "booten"? Das Programm muß im internen Flash liegen. Nach dem Reset wird ausgeführt. Was außen am Bus hängt, kann die Ausführung nicht behindern. Oder hast Du noch andere Sachen am externen Bus? Dann brauchst Du ne Dekodierlogik. Wird bei >64kB aber nur mit Banking gehen. Peter
MCUA schrieb: > laut seiner (grässlich lesbaren) Skizze gehen die EPROM-Daten-Leitungen > an P0. (falls er dort mit 'ADn' AD0..7 gemeint hat) Stimmt. Ich bin der Schrift aufgesessen, und las ADh, anstatt ADn. @Joghurt: Ich hab das Datenblatt mal kurz überflogen. So wie es aus sieht, ist der µC vom Verhalten doch mit dem Standard-8051 identisch. Das sollte dann so klappen. Was du mit dem CE am EPROM machen könntest, anstatt es fest auf Low zu schalten: Und zwar an einen freien Portpin schalten, z.B. an P1 oder P3. Und jeweils vor dem Lesebefehl aktivieren, und nach dem Lesebefehl wieder deaktivieren. Der Baustein ist ja sonst nie im Standby. Obwohl, ich sah auch 8051-Schaltungen, in denen CE fest auf Low liegt. Die brauchen dann nur mehr Strom, weil eben nie im Standby. Ob das deinen Boot-Fehler aber behebt, weiß ich nicht. Das ist mir sehr suspekt. Es könnte noch sein, daß dein EPROM den Zugriffszeiten nicht genügt. Denn ich entnahm dem Datenblatt 33MHz Taktfrequenz für den µC.
Okay, zumindest die Sache mit dem Reset hat sich erledigt. Ich habe das alles auf einem Streifenraster aufgebaut und nPSEN war dadurch mit einem Datenpin des ROM verbunden (es ist zwar nicht klar warum dies ein "booten" unerbindet aber), nach dem Durchtrennen der Leitung wird nun ordnungsgemäß das Programm ausgeführt. Die gelesenen Daten sind immer noch nicht die erwarteten. Ich habe die Verbindungen mit dem Multimeter durchgemesen, ich denke ich werde zunächst versuchen die Ports manuell anzusteuern und dann messen ob alles funktioniert. Gibt es eine möglichkeit ALE manuell zu bedienen? Das Datenblatt(at89s52) sagt unter Register AUXR: "DISALE = 0 - ALE is emitted at a constant rate of 1/16 osc. freq.". Wenn ich also manuell in das Latch schreiben will: auf ADn-Port Wert ausgeben, DISALE aktivieren warten (16 nops), dann DISALE=1 oder ein movx mit dem entsprechenden Wert den ich im Latch haben will im DPL. Naja, genug "lautes" Denken, ich werde es testen!
>Wenn ich diese richtig interpretiere sollte es also möglich sein ein ROM >mit nRD anzuschließen statt nPSEN \RD / \WR ist für Daten , \PSEN ist für Programm , egal welcher Speichertyp verwendet wird! > Ein weiteres "Phänomen" was ich vergessen hatte zu erwähnen ist, dass > wenn ich nCE vom ROM auf GND lege (momentan ist das noch als > freischwingendes Kabel realisiert), dann bootet der 8051 nicht evtl Buskonflikt (schon erwähnt). >Es könnte noch sein, daß dein EPROM den Zugriffszeiten nicht genügt. Bei 8051?
Der Datenport ist bei MOVX-Befehlen open-drain. Deine Skizze hat keine Pull-Ups. Fraglich ob dann das Adress-Lowbyte richtig am Latch ankommt. Ralf
MCUA schrieb: >>Es könnte noch sein, daß dein EPROM den Zugriffszeiten nicht genügt. > Bei 8051? Warum nicht? Dazu müßte man eben mal den genauen EPROM-Typ und die Taktfrequenz des µC wissen. Ralf schrieb: > Deine Skizze hat keine > Pull-Ups. Fraglich ob dann das Adress-Lowbyte richtig am Latch ankommt. Die sind auch nicht nötig. Pull-Ups am Bus waren früher bei NMOS-Bausteinen üblich. Zur Adressausgabe hat Port 0 Push-Pull-Stufen. Wenn die Ausgänge des EPROM CMOS sind, ist das Einlesen kein Problem.
Okay, EPROM Typ ist: HT27C512-70 (also 70ns) - es lief in einem anderen Gerät mit einem 8051 mit 12MHz anstandslos Der AT89S52 ist mit einem 8MHz Quarz verkabelt (2x22pF) Folgender Text im Atmel Datenbaltt:
1 | Address Latch Enable (ALE) is an output pulse for latching the low byte of the address during |
2 | accesses to external memory. This pin is also the program pulse input (PROG) during Flash |
3 | programming. |
4 | In normal operation, ALE is emitted at a constant rate of 1/6 the oscillator frequency and may be |
5 | used for external timing or clocking purposes. Note, however, that one ALE pulse is skipped dur- |
6 | ing each access to external data memory. |
7 | If desired, ALE operation can be disabled by setting bit 0 of SFR location 8EH. With the bit set, |
8 | ALE is active only during a MOVX or MOVC instruction. Otherwise, the pin is weakly pulled high. |
9 | Setting the ALE-disable bit has no effect if the microcontroller is in external execution mode. |
Wenn ich also das Bit im AUXR(0x8E) nicht setzte messe ich am LE des hc573 tatsächlich ca. 1,68V. Wenn ich es setze
1 | mov A, #1 |
2 | mov 08eh, A |
habe ich 5Volt (weakly pulled up). Wenn ich es runterziehe mit 466 Ohm habe ich 0,16V mit 10k mehr. Ich wollte das nur ausprobieren um zu sehen ob das Latch wirklich die richtige DPL Adresse hält. Kurzum die untere Adresse die ich an den hc573 pins messe deckt sich nicht mit der die der movx setzen sollte.
Joghurt3000 schrieb: > Okay, EPROM Typ ist: HT27C512-70 (also 70ns) - es lief in einem anderen > Gerät mit einem 8051 mit 12MHz anstandslos > Der AT89S52 ist mit einem 8MHz Quarz verkabelt (2x22pF) Das sollte dann wirklich kein Problem sein. Die Zeit 70ns bezieht sich bei EPROMs üblicherweise auf CE low to Data valid. Ist CE schon low, halbiert sich die Zeit bei OE low to Data valid etwa. Genaueres sagt aber das Datenblatt. Bei 8MHz ist das Ding im grünen Bereich, das braucht man gar nicht erst nachzuschauen. > Wenn ich also das Bit im AUXR(0x8E) nicht setzte messe ich am LE des > hc573 tatsächlich ca. 1,68V. Hoffentlich mit einem Oszi. High-Pegel am LE-Input sollte etwa wenigstens 0,8VCC sein. Das steht aber genau in den 74HC-Spezifikationen. Vielleicht nimmst du da auch besser den 74HCT-Typ. Ich meine, im Datenblatt des µC gesehen zu haben, daß die Pegel eher TTL-kompatibel sind, als CMOS-symmetrisch. Bei meinen Standard-8051 in CMOS-Version sind die Pegel auch TTL-kompatibel. Da nehme ich aber trotzdem 74HC-Typen, das geht auch. In vielen Schaltplänen wird auch der 74HC genommen. Obwohl 74HCT etwas besser wäre. Er bietet ein klein wenig mehr Störabstand. Oft spielt es aber keine Rolle. Gerade schaute ich ins Datenblatt eines EPROM 27C64A von ST. Dort sind die Pinpegel aber auch TTL-kompatibel, nicht CMOS. Obwohl man sie sowohl in TTL- als auch in CMOS-Systemen verwenden kann. Denn es sind für TTL und CMOS jeweils verschiedene Belastungswerte angegeben.
Okay, mein erster Versuch mit 8051. Ich habe jetzt mal ab Adresse 0x200 gelesen und gelegentlich stimmen die ersten 3-4 Bytes. Ich werde es wohl früher oder später hinbekommen. Ich bedanke mich nochmal bei Allen die hier geantwortet haben, Danke! Hier ist übrigens mein Testprogramm: http://pastie.org/2187887 (ist unordentlich, muss niemand lesen, credits an Paul für die 8bit HEX print Fkt.)
Wilhelm Ferkes schrieb: > Vielleicht nimmst du da auch besser den 74HCT-Typ. Ich meine, im > Datenblatt des µC gesehen zu haben, daß die Pegel eher TTL-kompatibel > sind, als CMOS-symmetrisch. Eingangsmäßig sind die 8051 TTL-kompatibel. Die Ausgänge liefern aber volle 5V CMOS, nur die alten NMOS 8051 noch nicht. Die verbrauchten aber auch 200mA. Peter
Peter Dannegger schrieb: > Eingangsmäßig sind die 8051 TTL-kompatibel. > Die Ausgänge liefern aber volle 5V CMOS, nur die alten NMOS 8051 noch > nicht. Die verbrauchten aber auch 200mA. OK, stimmt beides, sowohl TTL als auch CMOS geht. Ich schaute mir ja auch mal das Datenblatt des 27C64 an. Ist auch für TTL und CMOS geeignet. Allerdings etwas unsymmetrisch. Sowohl EPROM als auch 8051 können wesentlich höhere Ströme nach Masse ziehen, als von VCC treiben. Deswegen tendiert der Spannungslevel eher zu TTL, als zu CMOS. Auch die CMOS-Versionen (80C51) treiben keine Ströme mit High-Pegel. Allenfalls 80µA. Da bedient man sich in den CMOS-Typen ja eines Tricks: Und zwar wird der Pin mit einem FET für 2 Taktzyklen voll auf High-Pegel getrieben, danach abgeschaltet. Weil ein Schaltvorgang oft Umschaltstrom braucht. Dann wirkt nur noch der interne Pullup. Sogar bei meinen Siemens SAB80C517A ist das so. Es hat mich auch nie wirklich gestört, und bin es gewohnt, z.B. LEDs nur zwischen Pin und VCC zu schalten. In der früheren Firma hatten wir mal massiv Ärger mit einem Gerät, welches sogar schon jahrelang produziert und verkauft wurde. Und zwar trieb man die Basis eines bipolaren NPN-Transistors, sowas wie BC547C, der ein Relais schaltete, mit High-Pegel eines Pins an Port 1. Ja, das geht, ist aber grenzwertig. Der Pin liefert ja auch die 80µA. Und die Transistoren waren wohl gut. Als die Schaltung überholt wurde, und ein Relais mit niedrigerer Spannung, jedoch höherem Strom, eingesetzt wurde, war Essig. Alle zuckten auf einmal die Schultern. Man mußte dem Pin einen zusätzlichen Pullup verpassen. Der Port 0 hat aber Push-Pull-Stufen, da sollte es am Bus keine Probleme geben. Der ALE-Pin kann laut Datenblatt wiederum auch keine hohen Ströme bei High-Pegel treiben. Ein paar µA. Für den Input eines 74HC(T) reicht das aber. MCUA schrieb: > 1,68V am In, darf nicht sein, egal ob HC oder HCT. Selbstverständlich nicht. Ich dachte, das sei anhand des Registers AUXR jetzt geklärt. Da stellt sich mir die Frage, ob da am Pin ALE sonst noch was dran hängt. Schlimmstenfalls ein Pulldown-Widerstand. ;-) Ob der TE nun Anfänger oder Profi ist: Ich sah viele Leute, die sich mit den Portstrukturen am 8051 sehr schwer taten, und die tollsten Konstruktionen bauten. Z.B. einen Taster einlesen, der auf der anderen Seite an VCC liegt. Mit auch noch einem Pulldown-Widerstand am Pin. Das macht die Sache schlimmer, als wenn man ihn ganz weg läßt, und den Taster einfach gegen Masse an den Pin schaltet, wie es sich gehört.
So, lesen funktioniert jetzt wenn auch auf unkonventionelle Weise. Habe gerade zwei 64k roms ausgelese. Von dem einen hatte ich vorher schon ein Image zum Vergleich und es passt. Das zweite habe ich gebraucht (bei Segor) gekauft und es war ungelöscht. Hier ist der einzige ASCII string den es im gebraucht EEPROM gibt:
1 | "TI01.5xx.xx (TelDaFax), TELES.iLCR-Box, Copyright (c) 1998 by TELES AG |
Übrigens auch 8051 code. Finales Projekt soll ein Brenner werden. Ich habe schon auf einem Steckbrett eine Schaltung mit MC34063 für VPP und theoretisch bis 100mA zu gebrauchen. Jetzt muss ich mir nur noch überlegen wie ich das integriere, das EEPROM will teilweise VPP an A9 und an anderen Stellen angelegt bekommen. Besten Dank nochmal an alle!
Joghurt3000 schrieb: > Das zweite habe ich gebraucht (bei > Segor) gekauft und es war ungelöscht. Ich habe hier locker 100 gebrauchte EPROM, und zwar aus Schrott. Nie war auch nur ein einziges defekt. Da muß man sich keine großen Sorgen machen. Sie haben ja auch unbegrenzte Anzahl an Brennzyklen, anders als bei EEPROM und Flash. Man kann sie nur durch Unachtsamkeit mal kaputt brennen, wenn die Einstellwerte nicht stimmen. Ein 12,5V-EPROM mit 25V brennen wollen, weil man dachte, man hätte den älteren NMOS-Typen drin. Das passierte mir sehr wohl schon. Bei parallelem EEPROM als EPROM-Ersatz und als Programmspeicher für den µC bin ich etwas vorsichtiger. Einmal verpolte ich in einer Testschaltung die Stromversorgung. Aber selbstverständlich mit Strombegrenzung, daß nichts defekt werden kann. So habe ich mal ein EEPROM komplett in der fertigen µC-Schaltung unabsichtlich gelöscht, die µC-Schaltung funktionierte dann eben nicht mehr. Und ich mußte den Stein einfach nur neu brennen. > Hier ist der einzige ASCII string > den es im gebraucht EEPROM gibt: > "TI01.5xx.xx (TelDaFax), TELES.iLCR-Box, Copyright (c) > 1998 by TELES AGÜbrigens auch 8051 code. Ja das ist manchmal amüsant, wo die Bausteine her stammen. In meinen Schrott-EPROMs fand ich auch so einige Dinge.
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.