Hallo, Ich möchte mit einem Arduino Mega ein Intersil/Harris 6654A EPROM auslesen (512x8). Der hat 2xCE und 1xCS. https://deramp.com/downloads/mfe_archive/050-Component%20Specifications/Harris/Harris%20IM6654.pdf Ich habs mal versucht aber der dump sieht falsch aus (viele FF und 00). Eine vermutliche 0 ist eine 1. 60ns sind weniger als 1 cycle. Geht das nur mit direct port manipulation? Vielleicht hab ich auch falsch angeschlossen. Ich verstehe auch das Datenblatt nicht ganz. VDD is 'normally' tied to VCC. Data remains valid until 'either' CE1 or CS returns to a higher level. Address lines and CE2 must be valid one setup time before TAVEL and one hold time after TELAX. CE1 must remain high one minimum positive pulse width before the next cycle can begin. Vielen Dank im voraus!
Im Datenblatt auf Seite 5, unten, steht doch alles haarklein. Was ein Stolperstein sein könnte: /CE1 ist flankensensitiv.
Armin schrieb: > 60ns sind weniger als 1 cycle. Geht das nur mit direct port > manipulation? Das ist die Zeit die es dauert bis nach dem Anlegen einer Adresse bzw. dem enabled die Daten auf dem Datenbus stabil sind. Für dich also quasi die Mindestzeit die du warten musst bevor du die Daten einlesen kannst. Du kannst aber auch beliebig länger warten. Dauert dann halt einen Moment länger bis du alle Daten ausgelesen hast, bist dafür aber auf der sicheren Seite.
Sorry, ich bin kein Fachmann, daher ja auch die Frage. Geht das denn nun ohne direct port manipulation? (Antwort auf H.H.) Was bedeutet normally tied? Was bedeutet either im 2. Satz. Kann man sich da eins aussuchen? Mit den Flanken sah ich eigentlich weniger Probleme. Alle activ low. Aber ich bräuchte da leider etwas detailliertere Hilfe.
:
Bearbeitet durch User
Zeig doch mal deinen bisherigen Code zum auslesen.
Armin schrieb: > Was bedeutet normally tied? "wird für den normalen Betrieb verbunden mit", also abgesehen von exotischen Experimenten immer. > Was bedeutet either im 2. Satz. Kann man sich da eins aussuchen? "die Daten sind gültig, bis einer der beiden..." Beide Leitungen müssen zum Lesen auf Low sein, sobald eine der beiden es nicht ist, werden die Daten ungültig.
Armin schrieb: > Was bedeutet normally tied? Dass VCC und VDD in einer normalen, typischen Anwendung das gleiche Potential (+5V) haben. Wenn man Bock drauf hätte, gäbe es spezielle Anwendungen, bei denen zwei verschiedene Spannungen sinnvoll sein könnten (VDD ist die Spannung der Ausgangstreiber, VCC die Versorgung der Logik. Steht im DB). Ist für dich aber eher irrelevant. Armin schrieb: > Geht das denn nun ohne direct port manipulation? (Antwort auf H.H.) Ja. Du kannst dir beim Auslesen so viel Zeit wie du möchtest lassen. Du kannst die Adresse anlegen und meinetwegen auch nach 5 Sekunden die Daten einlesen. Du musst aber mindestens 60ns warten. Da es dir aber egal ist, ob der Dump nun 1 Sekunde oder 1 Minute dauert, kannst du dir auch eine Millisekunde pro Byte Zeit lassen. Armin schrieb: > Was bedeutet either im 2. Satz. Kann man sich da eins aussuchen? Naja, jein. Da du ja mehrere Bytes vom gleichen Chip auslesen möchtest, wäre CE (Strobe) für dich wohl der richtige Pin, CS (Chip Enable) kann dabei auf low bleiben, da du ja keinen anderen Chip selektieren möchtest und nur einen am Bus hast.
Ich habe den code von dieser Seite (geringfügig geändert, Speichergröße und Leitungen) mit diesen Steuerleitungen #define VCC_pin 24 #define CE1_pin 28 #define CS_pin 27 #define CE2_pin 26 #define VDD_pin 29 https://danceswithferrets.org/geekblog/?p=315
Armin schrieb: > mit diesen Steuerleitungen ohne den Code zu kennen... VCC und VDD solltest du fest verdrahten. Das sind KEINE Steuerleitungen.
Das ganze Unterfangen ist genau Null zeitkritisch! Du kannst notfalls auch die Daten mit der Hand anlegen und die einzelnen Bits ausmessen! Heist, langsamer als 60ms ist kein Problem!
Beitrag #7390935 wurde vom Autor gelöscht.
Armin schrieb: > Hier ist der code als Anhang Wo finde ich die Behandlung der Chip Enable, des Strobe Signals usw...? Der Code ist für einen voll statischen Speicher geschrieben.
Entscheidend aber ist: Änderungen an Adressleitungen werden erst mit einer fallenden Flanke an E̅1̅ übernommen. Das heißt, für jedes zu lesende Byte ist wie folgt vorzugehen: 1: E̅1̅ auf high 2: Adresse anlegen 3: E̅1̅ auf low 4: (nach einem Moment Innehalten) Daten einlesen 5: bei 1: weitermachen
Harald K. schrieb: > 2: Adresse anlegen > 3: E̅1̅ auf low Auch dazwischen sollte man eine kleine Pause einlegen. Denn je nach realem elektrischen Aufbau kann es etwas dauern bis die Adresse stabil auf dem Bus liegt.
Als Anfänger habe ich versucht, ähnliche Projekte zu finden. Zuvor hatte ich einen anderen, längeren Code (von Charles Baetsen) mit verschiedenen EPROM typen zB 1702, 2708, 8316A, 2102. Da war das Ergebnis komplett verzogen und jedesmal anders nach Änderung von delays. Die meisten Projekte haben zusätzliche shields.
:
Bearbeitet durch User
Max M. schrieb: > Auch dazwischen sollte man eine kleine Pause einlegen. Wenn man das mit einem AVR und dessen I/O-Ports macht, ist das implizit gegeben. Ansonsten ja, die "setup time" muss berücksichtigt werden. Theoretisch. Denn die liegt laut Datenblatt bei 0 nsec (Tabelle "AC Electrical Characteristics" auf S. 6 / 6-273).
Der Anschluss an den Arduino ist kein Problem. Man kann ja praktisch alles an die digitalen pins anschließen. Man muss dann "nur" den richtigen code schreiben. Leider findet man fast nur Beispiele für EEPROMs. Ich hatte mich schon auf direct port manipulation eingestellt. Nach tagelanger Suche fand ich 2 Beispiele (hatte schon verdrahtet). Aber wenn's ohne geht mach ich's lieber ohne. Ich versuch's dann nochmal mit eigenem code. Ohne gute Beispiele ist das für Anfänger schwer. Schon mal vielen Dank an alle!
Der Chip scheint 2704 / 2708 Kompatibelzu sein, such dir jemand der einen EPROM Programmierer hat.
Ich habe ein shield zum Auslesen von 2708. Und habe schon 8x 2708 ausgelesen. 2 hatten teils leere Bereiche. Fehlerhaft gedumpt? Aber brauchen die nicht 3 Spannungen zum lesen und 4 zum schreiben?
Ich hatte zuerst auch überlegt, ihn als 2708 auszulesen, da ich das shield und die Software habe. Die pins/Layout könnte man ja modifizieren. Aber leider konnte man die Windows Software nicht ändern und auch die Lese-Einstellungen nicht. Der Quellcode ist zudem sehr kompliziert und nicht nur für verschiedene EPROM typen sondern auch 2 verschiedene Programme. Aber vermutlich sind die anderen technischen Daten (Timing, Reihenfolge) ohnehin anders. Und wenn man eh selbst programmieren muss, kann man ja auch direkt anschließen.
2708 benötigt drei Versorgungsspannungen. Der 6654 hat mit 2708/04 absolut keine Gemeinsamkeiten, außer, dass es auch ein EEPROM ist. Ein 2704 ist übrigens ein 2708 mit Defekt in einer Speicherhälfte.
Armin schrieb: > Ich möchte mit einem Arduino Mega ein Intersil/Harris 6654A EPROM > auslesen (512x8). > Der hat 2xCE und 1xCS. > > https://deramp.com/downloads/mfe_archive/050-Component%20Specifications/Harris/Harris%20IM6654.pdf > > Ich habs mal versucht aber der dump sieht falsch aus (viele FF und 00). > Eine vermutliche 0 ist eine 1. > 60ns sind weniger als 1 cycle. Geht das nur mit direct port > manipulation? Vielleicht hab ich auch falsch angeschlossen. > [viel unnützes Zeug gelöscht] Was ist blos aus der guten alten uC.ger geworden, oder was habt ihr zugelassen, zu was sie sich entwickelt hat? Ich komme hier alle 1-2 Wochen mal vorbei - und bin zunehmend schockiert, was für ein Tinnef hier verzapft wird. Ganz schlimm ists geworden, seit die "Letzten Guten" - wohl durch Registrierungswut - verscheucht wurden. Seither rennen hier leider verstärkt Semi-<censored> rum ... Zu eurem Problemchen: Was redet ihr denn da? Hier gehts um 50 Jahre alte Technik. So ein oller COSMAC (Takt: wenige MHz) aus den '70er musste so'n Bauteil ganz ordinär per Businterface lesen - und ihr macht euch Sorgen um Setupzeiten >0/5 ns - das Timing mit einem dilettantisch C-Programm nachprogrammiert? Ich wette Stein und Bein, dass es hier keine 10 Leute mehr gibt, die ns-Schaltungen überhaupt noch entwerfen, geschweige denn Schaltzeiten in diesem Bereich messen können. BTDT, hatte so was 1000-fach mit meinem ollen Magnastat in "bleihaltig" zusammengebraten - und mit meinem ollen hp1725A ausgemessen - besser als es alle China-"Lötstationen" und -"Rigols" je könnten. Macht mal zu, lest das Dingens straightforward aus (ein timing diagram sollte man schon lesen können, nicht nur als Rigoler) und macht euch ECHTE Gedanken über: > Ich habs mal versucht aber der dump sieht falsch aus (viele FF und 00). > Eine vermutliche 0 ist eine 1. Und dann löscht ihr die vielen 0'en und 1'en - weil anfangen könnt ihr damit eh nichts. Oder ihr druckt es halt aus und heftet es ab...
:
Bearbeitet durch User
Joe L. schrieb: > Ich komme hier alle 1-2 Wochen mal vorbei - und bin zunehmend > schockiert, was für ein Tinnef hier verzapft wird. Ganz schlimm ists > geworden, seit die "Letzten Guten" - wohl durch Registrierungswut - > verscheucht wurden. Seither rennen hier leider verstärkt Semi-<censored> > rum ... Niemand wird dich vermissen.
Wolfgang R. schrieb: > Der 6654 hat mit 2708/04 absolut keine Gemeinsamkeiten, außer, dass es > auch ein EEPROM ist. Nun, das Ding hat immerhin das übliche JEDEC-Pinout. 2708 hat halt noch A9 (statt E̅2̅ ) und Vee (statt S̅), der Rest aber ist identisch belegt.
Joe L. schrieb: > Ich komme hier alle 1-2 Wochen mal vorbei Bei dem Schmarrn, den du verzapfst, wäre das hier auch nicht nötig gewesen.
Harald K. schrieb: > Wolfgang R. schrieb: >> Der 6654 hat mit 2708/04 absolut keine Gemeinsamkeiten, außer, dass es >> auch ein EEPROM ist. > > Nun, das Ding hat immerhin das übliche JEDEC-Pinout. > > 2708 hat halt noch A9 (statt E̅2̅ ) und Vee (statt S̅), der Rest aber > ist identisch belegt. Und das Gewicht ist auch noch ähnlich...
Ich hab jetzt mal einen neuen code verfasst, abgewandelt von meinem 2. verlinkten. Ich wäre sehr dankbar, wenn da mal jemand drüberschauen könnte. Ist die Stelle mit CE1 auf low dort richtig? Was ist eigentlich mit CE2 und CS? Ich habe mich hiernach gerichtet. Harald K. schrieb: > 1: E̅1̅ auf high > 2: Adresse anlegen > 3: E̅1̅ auf low > 4: (nach einem Moment Innehalten) Daten einlesen > 5: bei 1: weitermachen
Armin schrieb: > Ich habe mich hiernach gerichtet. Hast Du nicht, denn > digitalWrite(CE1_pin, LOW); steht in setup(). Stattdessen gehört es nach jeden Aufruf von SetAddressPins(), und nach jeden Aufruf von ReadDataValue() gehört ein > digitalWrite(CE1_pin, HIGH); In setup() hingegen gehört > digitalWrite(CE1_pin, HIGH); und > digitalWrite(CE2_pin, LOW); und > digitalWrite(CS_pin, LOW); Deine Schleifen sind sehr, sehr ungeschickt aufgebaut. Es ist völlig überflüssig, zwei Schleifen für High- und Low-Address zu haben, abgesehen davon zählen beide Schleifen je ein Element zu weit. Genügen würde
1 | for (i = 0; i < MaxAddress; i++) |
2 | {
|
3 | SetAddressPins(i >> 8, i & 0xff); |
4 | digitalWrite(CE1_pin, LOW); |
5 | dataValue = ReadDataValue(); |
6 | digitalWrite(CE1_pin, HIGH); |
7 | |
8 | // irgendwas mit dataValue anstellen
|
9 | }
|
MaxAddress ist 512, denn das EPROM kann 512 Byte speichern. Wenn Du die I/O-Zugriffe nicht mit den umständlichen digitalRead-/Write-Funktionen, sondern einem direkten Portzugriff durchführen würdest (was voraussetzt, daß Du Data_D0_pin bis Data_D7_pin auf einen der Ports des AVR legst, und zwar in der richtigen Reihenfolge), dann würde die Funktion ReadDataValue() in sich zusammenfallen zu einem > dataVaue = PINB; (wenn der verwendete Port zufälligerweise Port B des AVR ist). Vergleichbares würde für die unteren acht Adressbits in SetAddressPins zutreffen, das würde mit > PORTA = LowAddress; deutlich übersichtlicher werden. (wieder vorausgesetzt, daß die acht unteren Adressbits passend an einem Port angelegt werden und der PortA heißt).
H. H. schrieb: > Was ein Stolperstein sein könnte: /CE1 ist flankensensitiv. Der ATmega2560 hat doch ein externes Memoryinterface, da kann man einfach den Chip direkt anschließen. /CE1 geht an ALE, d.h. das Latch ist schon im Chip, einen extra 74HC573 braucht man nicht. Q7..0 werden mit A7..0 an AD7..0 der AVR angeschlossen. /S geht an /RD des AVR. /CE2 an GND, A8 an A8 Nicht vergessen, das externe Memoryinterface einzuschalten. Falls der AVR zu schnell ist, kann man noch den Clock-Prescaler einschalten. Und dann einfach nur auslesen, z.B. von extern in den internen SRAM kopieren.
:
Bearbeitet durch User
Peter D. schrieb: > Falls der AVR zu schnell ist Das wird er wohl sein, bei 300 bis 600 nsec Zugriffszeit ...
Harald K. schrieb: > Das wird er wohl sein, bei 300 bis 600 nsec Zugriffszeit ... Mit Prescaler 256 und 3 Waitstates bei 16MHz dauert der Lesepuls 256 * 3 / 16MHz = 48µs Sollte also dicke reichen. Siehe ATmega2560 Datenblatt: Figure 9-6. External Data Memory Cycles with SRWn1 = 1 and SRWn0 = 1 Man kann den CPU-Prescaler einschalten, die Daten in den RAM kopieren, dann den Prescaler wieder ausschalten und die Daten per UART senden.
:
Bearbeitet durch User
Vielen Dank für all die Hinweise! Also es gibt nun 3 Möglichkeiten, jeweils mit anderer Anschlussart und anderer Programmierung. Direct Port Manipulation ist erst mal raus. Also alles komplett von vorne. Über das externe Memory interface klingt ja jetzt am einfachsten. Einen Code braucht man aber so oder so. Und jetzt geht's wieder um's timing. Der Anschluss (Q7 mit A7 an AD7) ist auch nicht unbedingt schlichter. Nach längerer Suche (am besten Arduino Mega XMEM) habe ich bislang nur diese Seite mit Code-Beispielen gefunden (eigene Bibliothek 2011, gibt es da mittlerweile offizielle oder bessere?). Vieles ist mir noch unklar (Buffergröße). Zudem fehlt da wohl der entscheidende Code + timing. https://andybrown.me.uk/2011/08/28/512kb-sram-expansion-for-the-arduino-mega-software/ Teils findet man 10 Jahre alte Beispiele die trotz XMEM zusätzliches Latch und Bauteile verlangen. Praktisch alles dreht sich um eine RAM erweiterung, also lesen und schreiben mit SRAM. Als Anfänger werde ich mich da wohl ein paar Tage einlesen müssen und hoffe, mehr Beispiele zu finden. Ich fand auch den Proteus Simulator. Aber zumindest in der Testversion fehlt das exakte Bauteil bzw kann nicht geändert werden. Das Datenblatt ist auch sehr knapp diesbezüglich, zumindest mit code. Wer kann mit gute Seiten/Beispiele empfehlen. Oder notfalls ein Video? Verschiedene Code-Schnipsel von verschiedenen Projekten zusammenklauben ist auch sehr fehleranfällig. Über XMEM finden man noch weniger als ohnehin schon.
Harald K. schrieb: > Direct Port Manipulation Alles hat doch offenbar Vor- und Nachteile. Für zeitkritisches bräuchte man es halt, was ja nicht der Fall ist. Für Anfänger leichter ist es doch auch nicht unbedingt. Und nicht kompatibel mit anderen Boards, also Beispiele von anderen Projekten kann man so nicht übernehmen. Die meisten Projekte sind über die normalen digitalen Ports und normaler Programmierung. Als Anfänger kann ich nur das sagen, was ich mir bisher angelesen habe. Via externes Memoryinterface klingt nach der Beschreibung oben einfacher. Ich lasse mich natürlich gerne von anderem überzeugen. Zum Lernen wäre es natürlich auch interessant.
:
Bearbeitet durch User
Armin schrieb: > Via externes Memoryinterface klingt nach der Beschreibung oben > einfacher. Für Profis schon, aber nicht wenn man Arduino nutzt.
Armin schrieb: > Via externes Memoryinterface klingt nach der Beschreibung oben > einfacher. Magst Du noch erklären, warum Du Anmerkungen zu Deinem geposteten Versuch komplett ignorierst? Beitrag "Re: Altes EPROM auslesen Intersil 6654A (2xCE) mit Arduino"
Ich dachte, diese low-level Programmierung wäre eher für Profis. Ich meine mehrfach gelesen zu haben, dass die nur empfohlen wird, wenn man's unbedingt braucht. (Ich weiß nicht mehr wo). Gut dass ich es noch nicht neu verkabelt habe. Das wäre 2x umsonst gewesen. Ich muss jetzt erst mal schauen, was jetzt wirklich für mich am einfachsten ist. Möglichst mit einem Beispielcode, den man nur geringfügig abändern muss.
Harald K. schrieb: > Magst Du noch erklären, warum Du Anmerkungen zu Deinem geposteten > Versuch komplett ignorierst? Wie gesagt, klang das mit XMEM und Direkt-Anschluss einfacher. Weil das ja empfohlen wurde.
Harald hat alles nötige geschrieben. Du musst nur deinen letzten Code danach etwas anpassen.
Armin schrieb: > Ich dachte, diese low-level Programmierung wäre eher für Profis. Worauf beziehst Du Dich bitte? Auf das, was ich gerade geschrieben habe?
Armin schrieb: > Mit den Flanken sah ich eigentlich weniger Probleme. Alle activ low. Nein, offenbar verwechselst Du Pegel mit Flanken. Befasse Dich lieber mal mit den absoluten Grundlagen der Digitaltechnik.
Armin schrieb: > Ich dachte, diese low-level Programmierung wäre eher für Profis. > Ich meine mehrfach gelesen zu haben, dass die nur empfohlen wird, wenn > man's unbedingt braucht. (Ich weiß nicht mehr wo). Komisch. Als ich damals(tm) meinen ersten EPROM-Brenner an einen Sharp MZ-80K dranknüpperte, war mir von vornhrein völlig klar, wie die ganze Ansteuerung und das Timing aussehen mussten. Und damals gab es keine Internetforen, sondern nur das Datenblatt für mein EPROM (2716, 2732) und zwei Bücher über den Z80. Und meine Programmiersoftware funktionierte trotzdem auf Anhieb, was natürlich auch das Auslesen der EPROMs beinhaltete. Und damals, d.h. Mitte der 1980er Jahre, muss ich ca. 16 Jahre alt gewesen sein.
Armin schrieb: > Möglichst mit einem Beispielcode, den man nur > geringfügig abändern muss. Denn hat dir Harald doch gezeigt: > Genügen würde
1 | for (i = 0; i < MaxAddress; i++) |
2 | {
|
3 | SetAddressPins(i >> 8, i & 0xff); |
4 | digitalWrite(CE1_pin, LOW); |
5 | dataValue = ReadDataValue(); |
6 | digitalWrite(CE1_pin, HIGH); |
7 | // irgendwas mit dataValue anstellen
|
8 | }
|
Du must lediglich bei SetAddresspin() einen korrekte steigende Flanke haben damit die Adressen gelatched werden. Also einfacher wirds nimmer.
1 | void SetAddressPins(byte HighAddress, byte LowAddress) |
2 | {
|
3 | digitalWrite(addr_A00_pin, (LowAddress & 0b00000001)); |
4 | digitalWrite(addr_A01_pin, (LowAddress & 0b00000010)); |
5 | digitalWrite(addr_A02_pin, (LowAddress & 0b00000100)); |
6 | digitalWrite(addr_A03_pin, (LowAddress & 0b00001000)); |
7 | digitalWrite(addr_A04_pin, (LowAddress & 0b00010000)); |
8 | digitalWrite(addr_A05_pin, (LowAddress & 0b00100000)); |
9 | digitalWrite(addr_A06_pin, (LowAddress & 0b01000000)); |
10 | digitalWrite(addr_A07_pin, (LowAddress & 0b10000000)); |
11 | |
12 | digitalWrite(addr_A08_pin, (HighAddress & 0b00000001)); |
13 | digitalWrite(CE1_pin, LOW); |
14 | digitalWrite(CE1_pin, HIGH);// rising edge is strobe |
15 | }
|
(Mehrfacher Bearbeitungskonflikt, Änderungen nicht mehr möglich)
> Worauf beziehst Du Dich bitte? Auf das, was ich gerade geschrieben habe?
Nein. Komplett allgemein. Sorry, wenn ich mich unklar ausgedrückt habe.
Mir XMEM wurde es mir ja danach (als vermeintlich) bessere Möglichkeit
angeboten, wissend das ich Anfänger bin. Ist ja nicht persönliches.
Auch das mit Möglichst mit einem Beispielcode... von mir war anders
gemeint, da ja der Weg noch unklar ist. Wenn es jetzt mehrere "beste"
Optionen gibt.
@Andreas S.
Die Theorie ist klar, steht ja im Datenblatt. Mit einem Gerät, Software
und Büchern ist das aber anders, als wenn ein Anfänger einen Arduino in
verschiedenen Arten programmieren muss.
@ Thomas Z. Vielen Dank! Auch hier konnte ich den post erst danach lesen, da ich gerade am schreiben war. Ich werde es mal direkt probieren. Ich bin halt vorsichtig, ich habe mir schon mal einen USB-Port am PC zerschossen durch solche Basteleien. Wie man an meinem Beispiel oben sieht ist es für einen Anfänger nicht leicht alles 100% zu verstehen und dann korrekt umzusetzen. Man muss nur richtig anschließen und dann nur noch...
:
Bearbeitet durch User
Der Strobe an E1 ist in SetAddresspin() nicht mal notwendig, schadet aber auch nicht.
Harald K. schrieb: > Deine Schleifen sind sehr, sehr ungeschickt aufgebaut. > > Es ist völlig überflüssig, zwei Schleifen für High- und Low-Address zu > haben, abgesehen davon zählen beide Schleifen je ein Element zu weit. Der Code ist ja nicht von mir. Wie gesagt ein Shield für mehrere Typen. Wahrscheinlich erscheint er deshalb ungeschickt. Warum die Schleifen zu weit zählen ist mir allerdings unklar. Ich habe die Kommentare (u.a. mit den Pinbelegungen) und überflüssige EPROM-typen gekürzt. Das Original habe ich ja als EPROM5.ino verlinkt.
Das letzte Sondermöhren-EPROM, welches ich mit einem Arduino ausgelesen habe, habe ich mit HC595-Schieberegistern angesteuert. War eine Sache von einer halben Stunde. Ich verstehe die Komplexität hier nicht...
Harald K. schrieb: > MaxAddress ist 512, denn das EPROM kann 512 Byte speichern. Ich habe den Code vom 2704 übernommen, daher oben word EPROMSize=511; Warum der Programmierer später schreibt ist mir auch unklar. Bei ihm scheint es aber zu funktionieren. int MaxHighAddress = (EPROMSize)/256; Schieberegister habe ich glaube ich keine. Müsste ja auch ohne gehen (beim Mega).
:
Bearbeitet durch User
Wolfgang R. schrieb: > Das letzte Sondermöhren-EPROM, welches ich mit einem Arduino > ausgelesen > habe, habe ich mit HC595-Schieberegistern angesteuert. War eine Sache > von einer halben Stunde. Ich verstehe die Komplexität hier nicht... Eine Blinddarm OP ist ja auch ganz einfach, für einen Chirurgen. Armin ist ja offensichtlich Anfänger, und noch ziemlich ganz am Anfang...
H. H. schrieb: > Eine Blinddarm OP ist ja auch ganz einfach, für einen Chirurgen. > > Armin ist ja offensichtlich Anfänger, und noch ziemlich ganz am > Anfang... Das stimmt natürlich.
Angehängte Dateien:
-
read_eprom.png
36 KB
Thomas Z. schrieb: > digitalWrite(CE1_pin, HIGH);// rising edge is strobe Also im Datenblatt steht was anderes. Ab /E1 = high sind die Daten ungültig (4-5).
Armin schrieb: > Der Code ist ja nicht von mir. Wie gesagt ein Shield für mehrere Typen. > Wahrscheinlich erscheint er deshalb ungeschickt. Warum die Schleifen zu > weit zählen ist mir allerdings unklar.
1 | for (i = 0; i <= 10; i++) |
hat elf Schleifendurchläufe. Armin schrieb: > word EPROMSize=511; Wenn man so einen Unfug macht, funktioniert die falsche Schleife natürlich. Ist nur halt durchs Knie ins Auge. Logisch wäre es, die Größe als die tatsächliche Größe anzugeben. Da passen 512 Byte rein, also schreibt man 512 hin.
Angehängte Dateien:
-
read_xmem.png
41 KB
Hier zum Vergleich das Timing des AVR. Man sieht schön, ALE = /E1.
Also, ich schreibe gerade den code und habs verdrahtet. Leider sind da noch grundlegende Unklarheiten. Ist das jetzt doch die direct Port Manipulation? Dann war das das Missverständnis und muss das überlesen haben. Sorry! Ich dachte, ich könnte meinen code geringfügig ändern. Dann brauche ich doch noch spezielle (andere) binäre Definitionen am Anfang und muss das komplett neu aufzäumen. Was ist mit ADR 8? Ich habe da C0 genommen. Oder muss man C7 nehmen? Bzw vergleichbare. Bei direktem Portzugriff muss ich da nochmals alle Pins/Ports prüfen/ändern. Brauche ich noch etwas von meinem code (außer der Ausgabe?) Unklar ist ja jetzt noch die Sache mit E1. Wenn ich keine Unklarheiten gehabt hätte, hätte ich das beinahe schon ausprobiert.
:
Bearbeitet durch User
I2C converter for HD44780 LCD display zweckentfremden! Fuer Adress-Bus noch ein paar Leitungen extra. Einer fuer Daten, der andere fuer die Adressen. Versorgungsspannung anlegen. Chip Enable und Output Enable setzen. Nochmal ins Datenblatt schauen wg. evtl. Invertierungen bei letzteren Signalen. Laest sich leicht zum Programmer erweitern und vermeidet unnoetige Loeterei und Kabelsalat. Das Timing ist voellig unkritisch da statisch. SRAM geht damit ebenso. S' cool man!
Ich versteh nur Bahnhof. Programmieren geht mit Sicherheit ohne externe 4 Spannungen nicht (Ich glaube u.a. -40 V). Aber brauch ich auch nicht. Löten tu ich auch nicht am Breadboard. Jetzt sind es 4 Möglichkeiten. Nach 8 Std heute habe ich nichts geschafft. Und steh ganz am Anfang. Immerhin haben sich Missverständnisse offenbar teils aufgeklärt.
Wie wäre es für den Anfang einfach mal alle Adresseleitungen statisch , per Draht, auf Low zu legen und dann die korrekte Sequenz an die E und S- Signale zu legen. So wie es im Datenblatt steht. Kann sein das dann mit dem Multimeter auf den Datenleitungen nur Nullen erscheinen, kann aber auch sein das schon Einsen auftauchen. So klimpert man ein paar Bytes durch und weiß dann wenigstens das das PROM nicht defekt ist. Dann weiß man auch das die Sequenz korrekt ist. Und dann an die CPU anschließen und genau das selbe in SW machen. Schritt für Schritt, eine Baustelle nach der anderen.
:
Bearbeitet durch User
Harald K. schrieb: > Ich geb's auf. Was ist denn so schwer daran, sich das Datenblatt anzuschauen, siehe Ausschnitt? - Adresse anlegen, /E2 = low - /E1 = low - /S = low - Lesen - /E1 = high - fertig Wenn es Dir zu kompliziert ist, das den AVR automatisch machen zu lassen, dann mach es eben zu Fuß.
Peter D. schrieb: > Was ist denn so schwer daran, sich das Datenblatt anzuschauen, siehe > Ausschnitt? Du verwechelst mich. Ich habe das Datenblatt angesehen und verstanden, und ich habe dem Threadstarter beschrieben, wie er sein Codebeispiel anpassen müsste, damit er was erreichen kann. Ich gebe nur auf, zu versuchen, dem Threadstarter helfen zu wollen. Denn seine Reaktionen sind ... schwierig.
So, ich habe jetzt (nach einem anderen Beispiel) es mit direktem Portzugriff versucht. Ursprünglich waren dort 19 Adressleitungen (27c800) andere Ports usw. Ich habe es angepasst nach dem letzten Schema von Peter D. Harald K schrieb ja oben 1: E̅1̅ auf high 2: Adresse anlegen 3: E̅1̅ auf low 4: (nach einem Moment Innehalten) Daten einlesen 5: bei 1: weitermachen Ich weiß auch nicht, ob da jetzt ne Flanke drin ist.
1 | long addressCounter = 0; |
2 | byte readWord[1] = {0, 0}; //war 2 |
3 | void setup() { |
4 | DDRA = B11111111; //A0-A7 1= output |
5 | DDRL = B00000000; //Q0-Q7 |
6 | DDRC = B00000001; //A8 C0 |
7 | pinMode(41, OUTPUT); // CE1 |
8 | pinMode(40, OUTPUT); // CE2 |
9 | pinMode(39, OUTPUT); // CS |
10 | Serial.begin(9600); //war 115200 |
11 | digitalWrite(40, HIGH); // Flanke? |
12 | digitalWrite(41, HIGH); |
13 | digitalWrite(39, HIGH); |
14 | |
15 | }
|
16 | |
17 | void loop() { |
18 | if (Serial.available() > 0) { |
19 | while (addressCounter != 512) { //war 524288 aber oben steht 0, 511? |
20 | PORTC = (addressCounter & 512) >> 8; //war A 65280 |
21 | PORTA = addressCounter & 255; //war C |
22 | digitalWrite(40, LOW); //war 3 |
23 | delayMicroseconds(1); |
24 | digitalWrite(41, LOW); //war 2 |
25 | delayMicroseconds(1); |
26 | digitalWrite(39, LOW); |
27 | delayMicroseconds(1); |
28 | readWord[0] = PINL; //war K |
29 | Serial.write(readWord, 1); //war 2 |
30 | digitalWrite(41, HIGH); //war 3 |
31 | addressCounter++; |
32 | }
|
33 | }
|
34 | }
|
Armin schrieb: > digitalWrite(40, HIGH); // Flanke? > digitalWrite(41, HIGH); > digitalWrite(39, HIGH); Was soll der Quatsch?
Armin schrieb: > Ich weiß auch nicht, ob da jetzt ne Flanke drin ist. Dann nimm Dir Karopapier und Bleistift und zeichne den zeitlichen Verlauf auf, dann siehst Du die Flanken, wenn Dir die Abstraktion "Programmcode anschauen -> Zeitverlauf sehen" schwer fällt. Ein Tip, spendiere noch drei #defines für die 39, 40 und 41, dann fällt auch das Verstehen einfacher.
Was ist denn daran falsch. Das ist das Original Beispiel aus dem Arduino Forum https://forum.arduino.cc/t/simple-27c800-eprom-dump-to-serial/437245 . Ich fand noch ein 2. Beispiel a la DDRD = 0b11111111; //All pins in PORTD are outputs PORTD = 0b11111111; //All pins in PORTD are high
:
Bearbeitet durch User
Armin schrieb: > Was ist denn daran falsch. Das ist das Original Beispiel aus dem Arduino > Forum Vorher hast Du wenigstens symbolische Namen verwendet, jetzt verwendest Du "magic numbers". So etwas ist maximal fehlerträchtig.
Der code funktioniert leider nicht.
Erst gab es einen Fehler bezüglich
byte readWord[1] = {0, 0};
Ich habe dann statt 1 wieder 2 genommen als auch nur {0}.
Dann ging der code, aber ich bekomme absolut keine Ausgabe.
Weder mit Serial.write noch Serial.print. Weder mit Terminal Software
noch im Monitor.
Ich habe alles mögliche versucht, readWord, readWord, HEX, ,1 .
Mit 0, 1 und 2. Mit Klammern und ohne.
Im Original werden da 2 Bytes gelesen.
Armin schrieb: > Der code funktioniert leider nicht. Welcher, ich sehe keinen. Armin schrieb: > Dann ging der code, aber ich bekomme absolut keine Ausgabe. D.h. Deine UART sendet nicht. Aktivier mal die Pullups an den Dateneingängen. Dann liest Du 0xFF, wenn es nicht funktioniert oder der EPROM leer ist. Armin schrieb: > Im Original werden da 2 Bytes gelesen. Wen interessiert das. Dein Stein hat Q7..0, das ergibt ein Byte je Lesezyklus.
Armin schrieb: > @Andreas S. > Die Theorie ist klar, steht ja im Datenblatt. Offenbar scheint sie Dir nicht ansatzweise klar zu sein, denn ansonsten hättest Du überhaupt kein Problem damit, den entsprechenden Dreizeiler selbst zu schreiben. > Mit einem Gerät, Software > und Büchern ist das aber anders, als wenn ein Anfänger einen Arduino in > verschiedenen Arten programmieren muss. Genau, mit einem Arduino ist es hundertmal einfacher. Du hast offenbar nicht einmal eine Vorstellung davon, wie mühsam es damals war, solch ein Programm zu schreiben. Ein damaliger Rechner wie der MZ-80K war eher wie ein Microcontroller mit Bildschirm statt wie ein heutiger PC.
Den code habe ich etwas höher geposted (11h20). Auch mit aktivierten Pullups keinerlei Ausgabe. Sofern ich das richtig und an der richtigen Stelle gemacht habe. Gestern, mit anderem code ging es noch. Ich hab vergessen, den noch mal zu testen. Hole ich gleich nach. Oder teste das Board besser anderweitig. Das EPROM ist auch nicht leer, wie eingangs beschrieben konnte ich ja teilweise Bytes auslesen. Ich kann natürlich nicht ausschließen, dass mittlerweile was defekt ist. Aber ich vermute eher, dass der code falsch ist. Gerade bei der Definition des zu lesenden Bytes gab es ja die Fehlermeldung. Also der Arduino und UART funktionieren noch per Test. Muss also am code und/oder Anschluss liegen (siehe Kommentare im code).
:
Bearbeitet durch User
Ich hatte (zuletzt) CE2 und CS vertauscht. Wie das trotz verschiedener Kabelfarben passieren konnte ist mir schleierhaft. Ich hab den code neu erstellt, diesmal wieder ohne direktem Portzugriff. Ich hab jetzt einen neuen Dump, der sieht etwas besser aus. Allerdings habe ich weder opcodes entdeckt, noch Text, noch sonst sinnvolle Daten. Die genaue Funktion des PROMs ist nicht bekannt. Das Gerät (soweit testbar) funktioniert jedoch mit diesem PROM noch. Der Fall ist soweit erledigt. Ich bedanke mich vielmals für die Geduld und die Hilfe!
Armin schrieb: > Allerdings habe ich weder opcodes entdeckt Woran meinst Du die erkennen zu können? War da denn ein Dir bekannter Mikroprozessor angeschlossen, dessen Opcodes Du in binärer Form auswendig kennst? (Und warum nur kommt mir das so unendlich unwahrscheinlich vor?)
Harald K. schrieb: > Und warum nur kommt mir das so unendlich unwahrscheinlich vor? Wenn man den TO so in mehr als 50 Beiträgen zu seiner Lösung hinbeten bzw. hintragen muss dann verwundert mich das nicht. Armin schrieb: > Ich hab den code neu erstellt Jedes Mal das Programm neu eingetippt?
Die CPU ist eine Intersil 6100, also 12 bit. Die opcodes sind zu hoch. Die Programme habe ich teils neu erstellt. Aber nicht vollständig neu eingetippt. Die Grunddefinitionen, Ausgabe usw. habe ich übernommen, aber angepasst. Letztendlich basiert der letzte code auf dem ersten.
Armin schrieb: > Die CPU ist eine Intersil 6100, also 12 bit. Die opcodes sind zu hoch. Schon mal an Endianess gedacht?
Die opcodes sind zu hoch (16 bit). Außerdem startet es mit vielen 00. Falls der Dump korrekt ist, könnte es am ehesten eine Datentabelle sein. Bei 76 76 76 76 kann es an Endianness nicht liegen.
Armin schrieb: > Ich hab jetzt einen neuen Dump, der sieht etwas besser aus. > Allerdings habe ich weder opcodes entdeckt, noch Text, noch sonst > sinnvolle Daten. Nachdem du dich standhaft weigerst sowohl "funktionsfähigen" Code also auch deine Schaltung bzw. Aufbau zu zeigen darf man annehmen dass da schon noch etwas oder einiges im Argen liegt.
Ich habe 3 codes geposted. Der Fall war zudem für mich abgeschlossen. Weitere Fehler kann ich natürlich nicht ausschließen.
:
Bearbeitet durch User
Armin schrieb: > Ich habe 3 codes geposted. Die alle nicht funktioniert haben. Armin schrieb: > Der Fall war zudem für mich abgeschlossen. Schon klar, wenn du schreibst: Armin schrieb: > Ich hab jetzt einen neuen Dump, der sieht etwas besser aus. Armin schrieb: > Weitere Fehler kann ich natürlich nicht ausschließen. Das würde ich nach dem jetzigen Thread-Verlauf annehmen.
Ich habe jetzt nochmals den 3. code getestet. (Code wie gepostet. Die verwechselten Steuerleitungen nun umgesteckt). Bei der Definition von readWord kann ich mich im Moment nicht erinnern, was ich letztlich dort genommen habe. 1 und 0,0 gab ja einen Fehler. Ich glaube es war 1 und nur eine 0 in der Klammer. Bin auf einer anderen Partition. Der code wurde ja (inhaltlich) nicht bemängelt; keine Fehler benannt. Die Versorgungsleitungen sind direkt angeschlossen, der Rest steht ja im Kommentar. Diesmal kommt eine Ausgabe, und diese sieht "noch etwas" besser aus. (Trotz im Prinzip gleicher Logik etwas anders). Kaum noch FF. Inhalt startet nicht mit 00. Dafür 10x70 (Hex). Weiterhin also höchstens eine Datentabelle, was jedoch richtig sein kann, da das Gerät weitere PROMs hat. Wenn sich jemand den 3. code nochmals ansehen könnte, wäre ich sehr dankbar!
Armin schrieb: > Der code wurde ja (inhaltlich) nicht bemängelt; keine Fehler benannt. Hatte wohl niemand mehr Lust so wirren Code zu lesen. Aber eines ist mir doch aufgefallen: bei deinem Code wird A8 immer 0 sein.
Ich habe jetzt herausgefunden, warum ich keine Monitor Ausgabe hatte: Die baudrate (9600) war zu niedrig. Es dauerte 1-2 Minuten bevor etwas kam. Da hatte ich nicht mehr mit gerechnet. Das ging bei früheren Versuchen und gleicher Rate wesentlich schneller. Ich bin auch nicht sicher, ob ich die Flanke zu spät erhöht habe. Nach dem Lesen ist klar. Aber vor oder nach der Monitor-Ausgabe? Es gab weitere Probleme und Fehlermeldungen. Einstellungen (insbesondere des Ports) bei der Terminal-Software usw. Da dies ein anderes/allgemeines Thema ist, erstelle ich dazu einen neuen Thread. Bezüglich A8 habe ich verschiedene Vermutungen. Viel Möglichkeiten gibt es bei dem kurzen Code ja nicht. Aber ich muss erst mal die Ausgabe hinkriegen.
Armin schrieb: > Bezüglich A8 habe ich verschiedene Vermutungen. Armin schrieb: > PORTC = (addressCounter & 512) >> 8; //war A 65280 Sehen wir uns doch mal an, was da rauskommt. Schritt für Schritt.
1 | addresscounter | & 512 | >> 8 |
2 | ---------------+-------+-----
|
3 | 254 | 0 | 0 |
4 | 255 | 0 | 0 |
5 | 256 | 0 | 0 |
6 | 257 | 0 | 0 |
7 | ...
|
8 | 510 | 0 | 0 |
9 | 511 | 0 | 0 |
512 kann nicht auftreten, denn man fängt bei 0 mit dem Zählen an. Hmm. Sieht nicht gut aus. Warum?
bin(512) = '0b1000000000' d.h. eine 8-Bit-Zahl wird mit & immer 0
Stephan S. schrieb: > d.h. eine 8-Bit-Zahl wird mit & immer 0 Nö, das ist es nicht: Armin schrieb: > long addressCounter = 0;
Dank Hilfe klappt jetzt die Ausgabe (array-Fehler). Ich habe die Tabelle auch nicht verstanden. Auch die 2. Erklärung lässt Spekulationen des Fehlers offen. Long oder 0. (Ich habe beides getestet). Vermutlich soll statt 0 eine 1 stehen, damit nicht wieder von 0-511 gezählt wird. Offenbar ist die Zählung ab 0 doch nicht selten, zumindest international. Im Original wird trotz 0 die volle Größe angegeben. Je nach Art der Ausgabe, werden zB bei Hex stets nur 11 Bytes ausgegeben. Bei addressCounter 0: 11x30, bei 1 11x00. BIN: Ausgabe von 3 Bytes 1-OCT: 6x 162 1-DEC: 11x00 Das 12. Byte ist fast immer das Ersetzungszeichen �. Bei Ändern des arrays, werden bei HEX-Ausgabe auch nicht Hex-Zeichen wie LL, sowie auch das Ersetzungszeichen ausgegeben. Ich habe ja jetzt einen Vergleich zur Ausgabe von code 1 (mit allen Bytes). Falls es nur an A8 liegt, glaube ich nicht, dass aus langen Datenkolonnen plötzlich sinnvoller Text oder auch opcodes rauskommen.
Armin schrieb: > Auch die 2. Erklärung lässt Spekulationen des Fehlers offen. > Long oder 0. (Ich habe beides getestet). Du hast nicht ansatzweise verstanden, was Du da machst.
Angehängte Dateien:
-
Diagram_Auszug_Read.png
89 KB
H. H. schrieb: > Was ein Stolperstein sein könnte: /CE1 ist flankensensitiv. Wie schon von H.H. gesagt. Die Prozedur in ein Ausleseprogramm umschreiben. Und dann hast Du die Daten parallel anliegen. Dann brauchst Du noch eine weitere Routine. Wie willst Du die Daten dann behandelt wissen. Im Terminal darstellen über RS232 oder irgendwo zwischen"puffern". Das wären so meine prinzipiellen Überlegungen. Und nein, mein Eprombrenner würde da nicht funktionieren, da wie oben schon gesagt, Abfrageimpuls dynamisch. Sonst wäre das recht einfach. Adressen anwählen, Output enable und schon ist was auf dem Ausgang. ciao gustav
Alter Falter, das muss doch schon wehtun. Wenn aber Armin daran Spaß hat, soll er sich ruhig weiter seinem neuen Hobby widmen. Vermutlich riskiert er damit weder die Gesundheit von Mensch und Tier noch einen großen Sach- oder Umweltschaden. Vielleicht sollte man ihn mal mit Kurt B. verknüpfen? Ach nee, lieber dann. Dann könnte es doch noch gefährlich werden. Aber vielleicht Josef G. als neuer Spielkamerad? Völlig harmlos.
Harald K. schrieb: > Armin schrieb: >> Auch die 2. Erklärung lässt Spekulationen des Fehlers offen. >> Long oder 0. (Ich habe beides getestet). > > Du hast nicht ansatzweise verstanden, was Du da machst. In Fachkreisen auch "Management by surprise" genannt. 😂
Armin schrieb: > Ich habe jetzt nochmals den 3. code getestet. Schön. Und welcher ist das denn? Du kannst alte Beiträge direkt verlinken (Zitatfunktion) oder rechte Maus auf Überschrift im gelben Balken. Und Code immer als Anhang und vollständig (compilierbar).
Habtas jetzt? Kann ja nicht soo schwer sein... Schade, dass eben durch solche Anfragen, welche deutlich erkennen lassen, dass der TO überhaupt nicht verstanden hat, was da eigentlich passiert, der Ruf jender User, welche einen Arduino (ich nehm die "Pro Mini" wirklich gern für jeden Quark) hernehmen, derart zwiegespalten ist. Aber ist wirklich schon kaum mehr mit anzusehen(lesen). Auch wenn die Ausdrucksweise vom "Joe L." weiter oben recht harsch klingt, trifft sie in jedem Fall zu: Beitrag "Re: Altes EPROM auslesen Intersil 6654A (2xCE) mit Arduino" dem ist nichts hinzuzufügen. Einfach was kopieren und hoffen, dass es das macht, was man will. Das geht genau aundersrum. Aber: nun gut. Ich wollte erst garnix dazu schreiben. Es ärgert mich schon ..
:
Bearbeitet durch User
Bei den paar Bits ist man doch mit Kippschaltern und LED schneller, als eine Kanone auf diesen Spatz zu programmieren.
Dieses sich-Antworten-geben-lassen-und-weitestgehend-ignorieren-Spiel läuft hier jetzt schon seit einer Woche.
Harald K. schrieb: > Dieses sich-Antworten-geben-lassen-und-weitestgehend-ignorieren-Spiel > läuft hier jetzt schon seit einer Woche. Wenn es nur díeses eine Spiel wäre. Es kommen ja dauernd wieder solche hochqualitativen Threads hoch. Und nix anderes mehr.
--- Hallo zusammen --- na - habs am Rande mitbekommen, aber kein wirkliches Interesse verspürt bekommen, mich einzuklinken. "Wird ja so schwer nicht sein" dachte ich. Als ich mittendrin, fast am Ende das hier las, war ich mir da nicht mehr so sicher Armin schrieb: > long addressCounter = 0; > byte readWord[1] = {0, 0}; //war 2 das kannte ich aus nem anderen Thread ;) Man braucht doch nur einen Port hochzählen,nämlich den, wo man die Adressleitungen dran hat (A0 - A7 an portpin PB0 - PB7 meinetwegen) wenn erledigt, A8 auf H setzen, um an den oberen Adressbereich zu kommen und PORTB wieder von Null anfangend, hochzählen. Wenn man genugt Ports zur Verfügung hat, kann man die Daten dann an einem anderen Port einlesen, im SRAM zwischenspeichern und blockweise auf der UART ausgeben. Wenn man nur wenige Portpins zur Verfügung hat, kann man den Arduino auch so anschliessen, wie im Datenblatt auf der letzten Seite und teilt sich Adress - und Datenpins. War ja früher so üblich. Adresse anlegen (E2, S auf LOW lassen, Portpins, die man A0 - A9 zugewiesen hat, setzen (Hochzählen) und dann E1 von HIGH nach LOW. Die Daten auf dem Port einlesen, wo man die Datenleitungen halt dran hat und E1 wieder von LOW (issa ja noch) wieder auf HIGH. Jetzt das gelesene Byte wegspeichern, LeseIndex erhöhen und merken(!) und von vorn. Hat man das meinethalben 16x gemacht, lässt man den Riegel in Ruhe, als wenn er garnicht da wäre und gibt die 16Bytes auf der Uart aus. Dann wieder von vorn. Man kann auch die Adresse direkt vorgeben und die zuordnung der Portpins vorab vereinbaren und die entsprechende "PORTPIN Setz - und Löschroutine" on the fly machen, wie im oben aufgezeigten Beispiel unter: https://danceswithferrets.org/geekblog/?p=315 Hier könnte man einfach irgendeine Adresse, die einen gerade interesiert, angeben und diese auslesen, was aber im Programm nicht gemacht wird. Was hier natürlich fehlt, ist das PIN-Wackeln des E1-Pins. Logisch, dass man da nix auslesen kann. Ist ja auch n ganz anderer Chip. Jedoch: all dies steht, verteilt und sicher wohlwollend gemeint, hier schon beschrieben. Ziemlich gut sogar, wie ich finde.
Aber das hier ist kompletter Schwachsinn. Ein Array mit nur einem
Element Größe, das ist schon ohne den Versuch, zwei Elemente zu
initialisieren, grober Unfug.
>> byte readWord[1] = {0, 0}; //war 2
Nee, in dem Sinn einfach nur Unwissenheit. Is ja aber auch blöd: der Index fängt bei NUll an, beim initialisieren wird aber nicht der Index, sondern die Anzahl der zu initialisierenden Elemente angegeben, wie die meisten von uns wissen. Das Beispiel liest auch einen 27C800 aus, also einen 16bit ROM. Klar, dass man da, so man garnicht mit dem Thema vertraut ist, komplett ins Straucheln kommt. Hier braucht es garkein Array. Eine "normale" Byte-Variable hätte es auch getan. Mich wumrt die "kopieren und wundern", wenn es dann so garnicht klappen will.
Harald K. schrieb: > zwei Elemente zu > initialisieren, grober Unfug. > >>> byte readWord[1] = {0, 0}; //war 2 Ist es nicht sogar ein zweidimesionales Array, was so initialisert werden würde? Mit den geschweiften KLammern bin ich mir auch etwas unsicher gerade.
1 | byte readword[16] = {0}; |
initialisiert alle 16 elemente im Array "readWord" mit "0", dachte ich. Mit Eckigen Klammern initialisiert man jedes der Elemente separat, mit Komma getrennt, dachte ich. (ich bin da ganz vorsichtig in meiner Schreibweise, da ich mir nicht sicher bin - hab da wenig mit zu tun)
Auch scheint mir die Wandlung einer Dezimalzahl in eine binäre noch ein wenig Verständnis zu bedürfen. Gerade, wenn die Adresspins auf verschiede Ports wild verteilt sind, was ja beim Arduino meist immer gegeben ist. Ist zwar in den Beispielen hingeschrieben, aber nicht erklärt. Muss immer alles erklärt stehen? Wie man hier anschaulich sieht, ja. Also die Zahl einfach nacheinander mit allen zweierpotenzen verunden, bei treffer, Bit setzen, wenn nicht, portbit nicht setzen. Auch blöd erklärt. Aber: erklärt.und man kann die Arduino-Nummerierung verwenden und muss sich um das interene Mapping nicht scheren. Zeit genug ist ja für "digitalWrite". Na - und wenn der ROM nur 512 Speicherplätze hat, muss man natürlich nicht auf 512 prüfen, um gegebenenfalls noch ein Portbit setzen zu wollen. Es gibt hierfür keinen Eingang, es gibt keinen A9-Adresseingang am ROM!
Axel R. schrieb: > Gerade, wenn die Adresspins auf > verschiede Ports wild verteilt sind, was ja beim Arduino meist immer > gegeben ist. Er hat einen Mega2560, da hat es genug 8 Bit breite Ports.
Axel R. schrieb: > Is ja aber auch blöd: der > Index fängt bei NUll an, beim initialisieren wird aber nicht der Index, > sondern die Anzahl der zu initialisierenden Elemente angegeben Du verwechselst Initialisieren mit Deklarieren.
1 | int bla[2]; |
deklariert ein Array vom Typ int mit zwei Elementen.
1 | int bla[2] = { 1 }; |
deklariert ein Array vom Typ int mit zwei Elementen und initialisiert das erste davon mit dem Wert 1. Das zweite Element bleibt hier uninitialisiert.
1 | int bla[2] = { 1, 2 }; |
deklariert ein Array vom Typ int mit zwei Elementen und initialisiert das erste davon mit dem Wert 1 und das zweite mit dem Wert 2.
1 | int bla[] = { 1, 2 }; |
deklariert ein Array vom Typ int und bestimmt die Anzahl der Elemente aus der Anzahl der Initialisierer, hier also ebenfalls zwei. Axel R. schrieb: > Ist es nicht sogar ein zweidimesionales Array, was so initialisert > werden würde? Nein, das ist die Initialisierung eines eindimensionalen Arrays mit mindestens zwei Elementen. Axel R. schrieb: > Mit Eckigen Klammern initialisiert man jedes der Elemente separat, mit > Komma getrennt, Das gibt es erst ab C99 und ist das Array-Äquivalent der "designated initializers" von Strukturen. Wie auch immer: Um das eine aus dem Eprom gelesene Byte zwischenzuspeichern, ist ein Array --egal, wieviele Elemente es hält-- einfach der falsche Ansatz. Wie man im anderen Thread des Threadstarters sieht, ist das auch der Grund, warum sein Versuch, den Wert auszugegeben, so gründlich fehlschlägt. Weil er der Ausgabefunktion sein Array übergibt, statt den Wert, den er ausgeben will.
Ich bedanke mich bei allen, die noch versuchen, mir zu helfen. Danke auch für neue Vorschläge, es ohne Arduino zu machen (gabs schon 2x) oder nochmals versuchen das Datenblatt zu erläutern. Das ist nicht mehr nötig. Das Pin-Wackeln hatte ich ja selbst (eigenständig) eingefügt wie gepostet. Die Codes sind ja eben nicht nur 1:1 kopiert, sondern mühsam angepasst. Wenn ich es richtig verstanden habe, geht es nur noch um 2 falsche Zeilen? (Definition+Ausgabe; hängt aber zusammen). Dann wäre ich ja theoretisch kurz vor einer Lösung (und das ohne ausreichende Programmierkenntnisse). Aber vermutlich gibt es da noch mehrere Fehler (was war nochmal mit A8?) Ich habe es jetzt ohne Array versucht. Also int readWord; und bei der Ausgabe Serial.print (readWord, HEX);. Ich habe auch andere Datentypen versucht wie byte, short, unsigned usw. Die Ausgabe wird immer besser und bei int auch etwas länger. Aber egal was ich mache, ich erhalte immer 1 oder mehrere Ersetzungszeichen. Bedeutet das, dass das EPROM defekt ist? Oder warum ist eine Hex-Ausgabe nicht Hex? Geht es überhaupt so einfach in einer Zeile analog zu Serial.write. Oder braucht man da eine Schleife?
Du machst es Dir und allen beteiligten halt maximal schwer. Dadurch,
daß Du statt Deinen vollständigen Quelltext zu zeigen immer nur wirre
Prosa von Dir gibst, dadurch, daß Du nicht fehlerhafte Ausgaben o.ä.
zeigst, sondern diese ebenfalls nur durch wirre Prosa beschreibst
("Ersetzungszeichen").
Und nein, sich auf die gezeigten Codefragmente zu beziehen ist was
anderes, als den tatsächlich konkret von Dir verwendeten Quelltext in
Gänze zu zeigen (als Dateianhang!).
Du musst lernen, Dich verständlich, konkret und eindeutig auszudrücken.
Wirre Prosa? https://de.wikipedia.org/wiki/Ersetzungszeichen Vollständiger code ist gepostet. 2 Änderungen erklärt. Beitrag "Re: Altes EPROM auslesen Intersil 6654A (2xCE) mit Arduino" Laut Forenregeln soll man nur längeren code als Anhang posten.
:
Bearbeitet durch User
Armin schrieb: > Vollständiger code ist gepostet. 2 Änderungen erklärt. Armin schrieb: > Die Ausgabe wird immer besser und bei int auch etwas länger. Aber egal > was ich mache, ich erhalte immer 1 oder mehrere Ersetzungszeichen. Poste doch einfach den vollständigen Code - so wie Du ihn aktuell ausführst - und zeige auch dessen aktuelle Ausgabe (die immer besser wird), statt alles in Deinen eigenen Worten zu paraphrasieren. Dann kann einer der mitleidigen Mitleser (die extreme Geduld zeigen) Dir vermutlich sofort sagen, woran es hapert. Ansonsten gab es schon mehrfach den Tip, kritische Teile Deines Programms separat zu testen, z.B. in "setup()" könntest Du schon mal bekannte Werte als HEX ausgeben und die Ausgabe kontrollieren:
1 | Serial.println( "Test1" ); |
2 | for ( int n = 250; n < 260; ++n ) |
3 | Serial.println( n, HEX ); |
u.s.w. P.S. hast Du die Warnungen aktiviert - gerade als Anfänger solltest Du das tun (Menü: File/Preferences/Compiler Warnings, bzw. Datei/Voreinstellungen/Compiler-Warnungen)
Armin schrieb: > Ich habe auch andere Datentypen versucht wie byte, short, unsigned usw. Was willst Du uns damit sagen? Das Ding hat 8 Datenanschlüsse, also ist uint8_t (= 1 Byte) das richtige Format. Deine Versuche mit "short, unsigned usw." sind daher sinnlos. Und als Adreßzähler verwendet man vorzugsweise uint16_t, da 9 Anschlüsse. Unsigned Formate, um Seiteneffekte bei gesetztem MSB zu vermeiden.
Armin schrieb: > Laut Forenregeln soll man nur längeren code als Anhang posten. Noch nicht mal das hast Du verstanden. Da steht was anderes: > Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang
Damit nichts anbrennt hab ich mal was vorbereitet. Ist zwar dem Lernerfolg des TO nicht förderlich, aber ich habe diesbezüglich keine Hoffnung dass da etwas weitergeht ..... Ohne das EPROM in Händen zu halten und testen zu können: der Sketch sollte prinzipiell so funktionieren, vielleicht muss man nochmal an den CE1, CE2 und CS herumprobieren ob das mit dem Bus Handling so stimmt.
Wastl schrieb: > Ohne das EPROM in Händen zu halten und testen zu > können... ist das nicht sehr hilfreich. Warum nimmst du nicht ein aehnlich organisiertes?
🕵︎ Joachim L. schrieb: > Wastl schrieb: > >> Ohne das EPROM in Händen zu halten und testen zu >> können... > > ist das nicht sehr hilfreich. Warum nimmst du nicht ein aehnlich > organisiertes? EPROMs mit Adress-Latch sind selten.
Wer den Sketch des TO ausprobiert hat wird erkennen dass er noch an ganz anderen Stellen bereits Probleme hat. Nun, ich lasse Meckereien zu meinem letzten Beitrag einfach mal so stehen.
Hallo, Peter D. schrieb: > Unsigned Formate...Seiteneffekte...MSB Bist du dir sicher das Armin weiß was diese Begriffe bedeuten? rhf
seit >1 Woche wird hier herumgewurstelt und ich habe irgenwie das Gefühl, das sich der TE gar nicht helfen lassen will, jedenfalls geht er nicht auf etliche Posts ein. Sollte ein Moderator der gleichen Ansicht sein, dann bitte ich darum den Thread zu schliessen.
Vielen, vielen Dank für den Code! Er funktioniert soweit, allerdings habe ich festgestellt, dass nach jedem neuen Durchlauf, andere Werte ausgegeben werden. Es sieht aber so aus, dass es nur um etliche Bytes verschoben wird. Ich muss dies nochmals ausgiebig prüfen. Manche Werte hatte ich schon durch meine Codes erhalten. Etliche Werte sind erneut 16 bit, so dass es sich zumindest nicht ausschließlich um opcodes handeln kann. Nach strings muss ich noch suchen und verschiedene character sets testen.
Armin schrieb: > Etliche Werte sind erneut 16 bit, Nein. Ganz, ganz sicher nicht. Das ist ein 8-Bit-EPROM, da können nur 8 Bit breite Werte (d.h. welche im Wertebereich zwischen 0 und 255 bzw. 0 und 0xff) drinstehen. Und davon exakt 512 Stück. Wenn Du da irgendwo 16-Bit-Werte siehst, hast Du einen Anzeige- oder Interpretationsfehler.
Harald K. schrieb: > Wenn Du da irgendwo 16-Bit-Werte siehst, hast Du einen Anzeige- oder > Interpretationsfehler. Ab jetzt gibt mein Trolldetektor deutliche Alarmsignale aus.
Wastl schrieb: > Ab jetzt gibt mein Trolldetektor deutliche Alarmsignale aus. Was exakt willst Du damit sagen?
Harald K. schrieb: > Wastl schrieb: >> Ab jetzt gibt mein Trolldetektor deutliche Alarmsignale aus. > > Was exakt willst Du damit sagen? Dass er Armin für einen Troll hält.
H. H. schrieb: > Harald K. schrieb: >> Wastl schrieb: >>> Ab jetzt gibt mein Trolldetektor deutliche Alarmsignale aus. >> >> Was exakt willst Du damit sagen? > > Dass er Armin für einen Troll hält. Er hat ja auch keinen Grund angegeben, warum er das auslesen will. Muss? Kann? Spass an der Freud'? Da kann einem ein solcher Gedanke schon mal durch das Huern flutschen. Ich habe das Kistchen mit den ollen EPROMS an einen Tech-Schmuck Bastler verkauft und mir dafuer 'ne Stange TSOP Eeproms zugelegt. Die sind viel viel einfacher zu benutzen und man muss sich keinen abfaedeln.
H. H. schrieb: > Dass er Armin für einen Troll hält. es wurde mehrfach hier erklärt das immer nur 8-Bit Byte aus dem EPROM kommen, https://datasheetspdf.com/pdf-file/539392/Intersil/IM6654/1 die Wiederholung Armin schrieb: > Etliche Werte sind erneut 16 bit ist nun trollig oder der TO versteht es nicht besser, auch dann kann man nicht mehr helfen!
:
Bearbeitet durch User
Stephan S. schrieb: > seit >1 Woche wird hier herumgewurstelt und ich habe irgenwie das > Gefühl, das sich der TE gar nicht helfen lassen will, jedenfalls geht er > nicht auf etliche Posts ein. > > Sollte ein Moderator der gleichen Ansicht sein, dann bitte ich darum den > Thread zu schliessen. Wastl schrieb: > Harald K. schrieb: >> Wenn Du da irgendwo 16-Bit-Werte siehst, hast Du einen Anzeige- oder >> Interpretationsfehler. > > Ab jetzt gibt mein Trolldetektor deutliche Alarmsignale aus. Ich möchte nochmal auf meinen Vorschlag verweisen!
H. H. schrieb: > EPROMs mit Adress-Latch sind selten. Ich hab die früher oft verwendet, z.B. von ST den M87C257. Man sparte damit den 74LS573 am 80C51. Es gab auch SRAM mit Adreßlatch, z.B. in der DDR den U6516.
Ja, sorry, die Werte bzw Größe eines Bytes sind natürlich 8 bit. Da die CPU aber 12 bit ist, müssen die opcodes passen. 16 bit Worte passen da nicht. Hatte ich aber bereits erklärt. Kann vielleicht jemand beantworten, warum es jedesmal verschiede Ausgaben gibt? Ich hatte leider noch keine Zeit die Daten komplett zu analysieren. Strings sind nicht in ASCII.
Armin schrieb: > Da die CPU aber 12 bit ist, müssen die opcodes passen. Nö, die CPU bastelt sich erst intern die 12 Bit zusammen. Entweder aus 2 Bytes und schmeißt je 4 Bit weg. Oder je 2 Befehle aus 3 Bytes. Welche CPU ist das denn?
Armin schrieb: > Er funktioniert soweit Ja, das übliche Spiel. Bisschen schwanger sein geht nicht. Entweder es funktioniert oder eben nicht. Armin schrieb: > Kann vielleicht jemand beantworten, warum es jedesmal verschiede > Ausgaben gibt? Vermutlich weil das Bus-Handling noch nicht stimmt. Wenn drei Select- bzw Enable-Signale vorhanden bzw. zu steuern sind sagt mir der gesunde Menschenverstand dass die auch zyklisch bedient werden müssen. Das ist im aktuellen Code nicht der Fall. Nur CE1 wird dauernd auf und ab gesteuert. Wastl schrieb: > Ohne das EPROM in Händen zu halten und testen zu > können: der Sketch sollte prinzipiell so funktionieren, > vielleicht muss man nochmal an den CE1, CE2 und CS > herumprobieren ob das mit dem Bus Handling so stimmt.
haah, fetzt Vielleicht packst du deinen Kram zusammen und es findet sich jemand, der dir das fürn größeres Packen Pall-Mall-Rot schnell am Samstag richtet und es Dir zurückschickt. Iss es denn wichtig? Was willst' denn "häggen"? Das wird doch hier nichts.
Wastl schrieb: > Wenn drei > Select- bzw Enable-Signale vorhanden bzw. zu steuern sind sagt > mir der gesunde Menschenverstand dass die auch zyklisch bedient > werden müssen. Das ist im aktuellen Code nicht der Fall. Nur CE1 > wird dauernd auf und ab gesteuert. Du hast nicht ins Datenblatt gesehen.
H. H. schrieb: > Du hast nicht ins Datenblatt gesehen. Hätte ich das irgendwo behauptet? Dann bitte das Zitat dazu.
...mit /CE1 "wackeln" sollte reichen, oder?
Armin schrieb: > Strings sind nicht in ASCII. Zeig doch mal (per C&P, nicht in Deinen eigenen Worten).
Axel R. schrieb: > ...mit /CE1 "wackeln" sollte reichen, oder? Vielleicht muss man die Adresse erst mal 'reinlatchen. So einfach mir nichts dir nichts eine Adresse Anlegen und sich freuen muss nicht unbedingt funktionieren.
Wastl schrieb: > H. H. schrieb: >> Du hast nicht ins Datenblatt gesehen. > > Hätte ich das irgendwo behauptet? Dann bitte das Zitat dazu. "Wenn man keine Ahnung hat, einfach die Klappe halten!"
Angehängte Dateien:
Wolln, wir das alles nochmal durchnehmen? Das wurde doch nun hinreichend erklärt, wie man das Teil ausliest... /E2 und /S können auf LOW bleiben. Adresse anlegen, /E1 auf LOW ziehen Daten auslesen /E1 wieder auf H vorn vorn
:
Bearbeitet durch User
Peter D. schrieb: > Welche CPU ist das denn? Armin schrieb: > Die CPU ist eine Intersil 6100, also 12 bit. Die anderen 8 PROMs haben 12 bit Worte, gebildet aus 2 Bytes. Es handelt sich um ein SPS Programmiergerät. Da ich in den 8 PROMs auch nach umfangreicher Suche und verschiedenen Kodierungen keine Strings finden kann vermutete ich diese in dem letzten PROM. Oder wenigstens opcodes. Lebensnotwendig ist es nicht, verschicken lohnt nicht. Der dump startet mit 70 70 00 00. Etwa die Hälfte ist 70 00 (Hex). Strings können es ohnehin nicht sein, dafür gibt es nicht genügend unterschiedliche Bytes. Ich erinnere mich noch an folgende Bytes 20 30 BD 8D AD, ganz wenig FF. Als strings findet man im prinzip nur ab und zu ein p (70). Das Gerät kann aber auch kein ASCII, soviel ist bekannt.
Du hast eben auch keinerlei Ahnung von Code für eine PDP-8.
H. H. schrieb: > Du hast eben auch keinerlei Ahnung von Code für eine PDP-8. Ich beschäftige mich erst seit etwa 1 Jahr damit.
Armin schrieb: > H. H. schrieb: >> Du hast eben auch keinerlei Ahnung von Code für eine PDP-8. > > Ich beschäftige mich erst seit etwa 1 Jahr damit. Dann wird es wohl noch Äonen dauern...
Wastl schrieb: > Entweder es funktioniert oder eben nicht. Ja, wenn ich die Wahl habe, dann funktioniert es nicht. Aber der Code ist ja nicht gänzlich falsch. Wahrscheinlich nur eine Kleinigkeit. Ich vermute dass es irgendwie am Timing liegt (chip und/oder Arduino). Ich habe einen Intersil 6654 AI. Der hat andere Zugriffszeiten. Ich weiß nicht, ob diese beim Auslesen eine Rolle spielen, aber ich sehe die Charakteristika gar nicht im Code. TE1LE2X Chip Enable Hold time minimum 60 ns E1 Pulse Width (Negative) min 300 ns Sowie aber auch andere max Werte wie OE time max 60 ns. Und für High Speed Zugriff braucht der 10V (Seite 1) oder sehe ich das falsch?
Armin schrieb: > Ja, wenn ich die Wahl habe, dann funktioniert es nicht. Exakt so ist es. > Aber der Code ist ja nicht gänzlich falsch. Wenn Du weiterhin solch ein Geheimnis aus Deinem Programmcode machst, kann ihn niemand überprüfen. Deine bisher völlig durcheinandergewürfelten Codeschnipsel lassen keine Aussage zu. Und insbesondere kennen wir auch nicht Deinen Aufbau, d.h. welche Pins miteinander verbunden sind, und vor allem auch nicht Dein Stromversorgungskonzept. > Wahrscheinlich nur eine Kleinigkeit. Ich vermute dass es irgendwie am > Timing liegt (chip und/oder Arduino). Nein, nicht der Chip oder der Arduino sind daran schuld, sondern ausschließlich DU selbst. Bei normalem Portgeklimper per Firmware dürfte es Dir allerdings kaum gelingen, ein Timing zu erzeugen, das zu schnell für das EPROM wäre. Und außerdem könntest Du ja ggf. mittendrin auch explizite Verzögerungen einbauen. > Ich habe einen Intersil 6654 AI. Der hat andere Zugriffszeiten. > Ich weiß nicht, ob diese beim Auslesen eine Rolle spielen, aber ich sehe > die Charakteristika gar nicht im Code. Beim Erzeugen des Timing per Firmware spielt das nahezu überhaupt keine Rolle. Außerdem müsstest Du das ja schon längst mit einem Oszilloskop oder Logikanalysator geprüft haben. Warum verheimlichst Du auch schon wieder solche Bilder/Fotos/Screenshots/Tabellen? > TE1LE2X Chip Enable Hold time minimum 60 ns > E1 Pulse Width (Negative) min 300 ns > Sowie aber auch andere max Werte wie OE time max 60 ns. Das sind alles nur die zugesicherten maximalen Latenzen des EPROMs. Jede langsamere Ansteuerung ist zulässig. > Und für High Speed Zugriff braucht der 10V (Seite 1) oder sehe ich das > falsch? So sieht es aus. Bei 10 V ist aber Dein Arduino hinüber. Außerdem ist das aus den genannten Gründen nicht erforderlich.
Andreas S. schrieb: > ein Geheimnis aus Deinem Programmcode machst Es geht doch gar nicht mehr um meinen Code, sondern um den von Wastl Beitrag "Re: Altes EPROM auslesen Intersil 6654A (2xCE) mit Arduino" Die Pins sind natürlich genauso angeschlossen. Versorgungsleitungen direkt. Andreas S. schrieb: > schon längst mit einem Oszilloskop > oder Logikanalysator geprüft haben Habe ich als Anfänger natürlich nicht. Andreas S. schrieb: > könntest Du ja ggf. mittendrin > auch explizite Verzögerungen einbauen Das habe ich gestern mal schon vor deinem Post versucht. Je nach Verzögerung ist das Ergebnis immer anders, als auch nach jedem Durchlauf mit gleichen Einstellungen. Die Daten sind komplett falsch. Auffällig ist, dass es in der 1. Hälfte sehr viele 00 sind und in der 2. Hälfte viele FF. Praktisch jedes 2. Byte. Auch auffällig ist, dass bei weiteren Durchläufen sich nicht nur Bytes verschieben, sondern auch einzelne Bytes bzw Bits geringfügig ändern. Aus 70 wird manchmal 72. Im Prinzip Datenmüll. Und weiterhin viel zu wenig unterschiedliche Bytes. Das letzte Byte ist (wenn es nicht FF ist) fast immer 85. Das 1. Byte häufig 00 oder 38, manchmal 10. Wenn es nicht am Timing liegt, woran könnte es denn noch liegen?
Armin schrieb: > Wenn es nicht am Timing liegt, woran könnte es denn noch liegen? Ein interotaler Fehler!
Armin schrieb: > Es geht doch gar nicht mehr um meinen Code, sondern um den von Wastl sprintf (prbuff, "addr 0x%04X: val 0x%02X \r\n", addressCounter, byte_read); printf möchte Werte 16-bittig:
1 | sprintf (prbuff, "addr 0x%04X: val 0x%02X \r\n", addressCounter, (uint16_t)byte_read); |
Peter D. schrieb: > printf möchte Werte 16-bittig Leider gleiches Problem der Ausgabe. (Jede Zeile ein neuer Durchlauf) 00 70 00 00 20 .. 00 30 00 00 20 00 30 00 00 30 Bei Verzögerungen (an verschiedenen Stellen mit verschiedenen Werten getestet, hier 4ms nach der letzten Flanke) 70 00 00 70 00 30 00 00 Vermutlich muss die Definition oben auch geändert werden? Gibt es denn noch andere Fehler? Vielleicht Tipps bzw. Verzögerungswerte?
:
Bearbeitet durch User
Armin schrieb: > Wenn es nicht am Timing liegt, woran könnte es denn noch liegen? Zeig mal ein Bild Deines Aufbaus. Keine Skizze, ein Foto.
Wieviel Fotos soll ich denn posten, so dass man alles erkennen kann? Oder was soll genau dargestellt werden? 1 Foto reicht da sicher nicht. Und warum reicht da keine Beschreibung der Anschlüsse? Die Address- und Datenleitungen sind definitiv richtig (der Reihe nach gemäß Portskizze). Die Steuerleitungen wurden nochmals überprüft, da wurde ja schon eine Verwechslung erkannt. Bleiben die Versorgungsleitungen. Wie gesagt direkt angeschlossen. GND (VSS) an GND. VCC und VDD an +5V (Digitalanschlüsse).
Sieht so aus, als würden Deine Datenpins floaten. Hast Du mal die Pullups an den Dateneingängen aktiviert, wie oben empfohlen. Dann muß ohne EPROM 0xFF gelesen werden.
Armin schrieb: > Wieviel Fotos soll ich denn posten, so dass man alles erkennen kann? So viele, wie nötig sind. Armin schrieb: > Und warum reicht da keine Beschreibung der Anschlüsse? Weil damit eine Fehlerquelle nicht erkennbar ist. Du hast eine, Du siehst sie nicht. Andere, die mehr Erfahrung als Du haben, können aber anhand eines Bildes Deines Aufbaus möglicherweise mehr erkennen. Willst Du Dir helfen lassen? Wozu hast Du diesen Thread hier angelegt? Also.
Ich werde es nachm Essen nochmals mit den Pullups versuchen. Hatte ich zwar bereits, aber da unter anderen Bedingungen. Dauert etwas, auch weil die Angaben für einen Anfänger nicht konkret genug sind. Ich musste damals schon selbst recherchieren, wie man das überhaupt macht. Da ich ja selbst lernen soll, dauert das eben dann Tage. Muss das EPROM denn raus dazu? Oder was ist sonst zu beachten? Alte Befehle raus? Oder zusätzlich, wenn ja wo? Gute Fotos zu erstellen ist derzeit schwierig (Lichtverhältnisse).
Bei Aktivierung der Pullups ist nicht alles FF. Beim ersten Durchlauf ist Byte 1 00, dann folgen 15x72 dann 16xFF, dann wieder 16x72 usw. 15x abwechselnd Reihen von 72 und FF, der Rest ist FF. Beim 2. Durchlauf startet es mit 16x72. Sonst wie oben. Was bedeutet dies nun?
Armin schrieb: > Bei Aktivierung der Pullups ist nicht alles FF. > > Beim ersten Durchlauf ist Byte 1 00, dann folgen 15x72 dann 16xFF, dann > wieder 16x72 usw. 15x abwechselnd Reihen von 72 und FF, der Rest ist FF. > > Beim 2. Durchlauf startet es mit 16x72. Sonst wie oben. > > Was bedeutet dies nun? Mit oder ohne eingestecktes EPROM?
Armin schrieb: > Lebensnotwendig ist es nicht, verschicken lohnt nicht. Wie Du meinst. man könnte der Nachwelt (alle, die in nächster Zeit in Bedrullie geraten, sowas auslesen zu müsen) einen RiesenGefallen tun, und zeigen wie es geht. Meinthalben Durchaus mit einem ATmega2560 Adruino, aber als Alternative auch mit gemeinsamen Adress - und Datenleitungen. Denn das ist ja gerade der Vorteil dieses Typs. Dann kann man auch ein Setup hernehmen, bei dem nicht so viele Porst zur Verfügung stehen. Andererseits wurde ja schon auf funktionierende Beispiele verlinkt, die - rein von der Architektur her - eine Auslesen ermöglichen.
Armin schrieb: > Die Address- und Datenleitungen sind definitiv richtig (der Reihe nach > gemäß Portskizze). Die Steuerleitungen wurden nochmals überprüft, da > wurde ja schon eine Verwechslung erkannt. Dann funktioniert doch alles! Problem gelöst.
Axel R. schrieb: > man könnte der Nachwelt (alle, die in nächster Zeit in Bedrullie > geraten, sowas auslesen zu müsen) einen RiesenGefallen tun Es heißt doch unisono, dass alles ein Kinderspiel sei, und es nur an mir läge. Und dass das EPROM gar nicht so selten sei. Es wäre zwar wirklich interessant, ob das jemand schafft, oder gar zu beschreiben. Aber ich kann ja alle Anweisungen ausprobieren. Übrigens: Sämtliche funktionierende Beispiellinks stammen von mir.
Und Du hast noch nicht mal eine Lampe in Deinen Räumlichkeiten, so daß es nicht möglich ist, wenigestens ein Bild Deines perfekt funktionierenden und garantiert total richtigen Versuchaufsbaus zu machen und zu zeigen. Klar.
Ich habe jetzt einen Fehler (selbst) gefunden. VPP hatte ich nicht angeschlossen (weil ich nicht programmiere und auch die Spannung nicht habe) muss aber beim Lesen an 5V. Geschenkt. Geht aber immer noch nicht. Ich habe mal CS direkt an GND angeschlossen. Die Ausgabe ist jetzt stabil und nicht nach jedem Durchlauf verschoben. Ich habe aber den Eindruck, dass dies erst stabil ist, wenn der Chip warm wird. Nach wie vor gibt es viele falsche Werte (häufig 00 und FF, FE, F8), ab und zu kommt hier und da ein Byte, was richtig sein könnte, auch in späteren Durchläufen häufig das selbe. Es könnte jetzt lediglich am Timing liegen. Habe aber da vieles ausprobiert. Muss da vielleicht noch was mit E2 passieren? Datenblatt: Latched by E1. Und: wenn die Adresse gültig ist, ist die Ausgabe ungültig und umgekehrt. Davor und danach ist man im Z-Zustand. Vielleicht ist auch die Spannung nicht stabil 5V oder man braucht doch 10V. Ich hatte zwischenzeitlich auch andere Ports versucht. Pullup ohne EPROM bringt FF. Und ja, meine Beleuchtung ist nicht gut genug, für gute, verwacklungsfreie Fotos. Ich muss den Chip auch nochmal einbauen, ob da eine Fehlermeldung kommt. Falls nicht könnte er aber auch schon vorher defekt gewesen sein.
Da Du nach wie vor kein Bild von Deinem Aufbau zeigst, frage ich mich, was diese Berichte für einen Zweck haben.
Harald K. schrieb: > was diese Berichte für einen Zweck haben Vielleicht hat da jemand Tipps und kann auf meine Fragen eingehen. Niemand wollte bisher ernsthaft Bilder sehen. Alles ist ja beschrieben.
Armin schrieb: > Vielleicht hat da jemand Tipps und kann auf meine Fragen eingehen. Damit du die Antworten ein weiteres mal ignorierst? > Niemand wollte bisher ernsthaft Bilder sehen. Alles ist ja beschrieben. In deinen Träumen.
Armin schrieb: > Niemand wollte bisher ernsthaft Bilder sehen. Es wäre mir neu, daß ich "niemand" bin. Meine Fragen und im übrigen auch hilfreichen Hinweise an Dich waren hingegen ernstgemeint.
Armin schrieb: > Niemand wollte bisher ernsthaft Bilder sehen. Alles ist ja beschrieben. Niemand kann beurteien ob du auch beim Aufbau alles richtig gemacht hast da man durch deine blumigen Beschreibungen nichts sehen kann. Durch falschen Aufbau kann nichts passieren? Ach so, dann funktioniert ja alles und dein Thread kann hiermit beendet/geschlossen werden. Ich behaupte mal es muss massive Gründe geben weswegen du hier keine Bilder deines Testaufbaus zeigst, sonst wären du und wir schon einen grossen Schritt weiter.
Das ist schon Realsatire was hier abgeht. Solange aber immer noch gut gemeinte Antworten kommen, wird Armin immer so weiter machen. Deshalb mein Vorschlag: Bevor Armin nicht - Bilder seines Aufbaus - den aktuell verwendeten Code - und die dazugehörige Ausgabe bringt, sollte auch keiner mehr irgendwie geartete, gut gemeinte Tipps geben. Dann geht's es entweder voran oder es ist Ruhe, und beides wäre auf seine Art gut.
:
Bearbeitet durch User
Klaus schrieb: > Solange aber immer noch gut gemeinte Antworten kommen ..... > ........ Du hast ja sooo Recht. Eigentlich sollte man hier zumachen.
Der Code ist exakt der von Wastl. Die Ausgabe ist jedesmal anders (Datenmüll). Blieben die Bilder. Warum man wegen ein paar eventuell strittigen Leitungen, deren Anschlüsse man besprechen könnte, Bilder posten soll bleibt unklar. Da hier wieder Spekulationen auftauchen (es gab ja schon mal andere, die ich widerlegt habe, zB die CPU), geht es doch offenbar um etwas anderes bei den Fotos. Genau das gleiche wie "meine" wirren Codes oder vermeintlichen Fragmente, die nachher auch niemand mehr sehen wollte. Gut gemeinte Antworten... Nur nicht zum Thema.
Armin schrieb: > Warum man wegen ein paar eventuell strittigen Leitungen, deren > Anschlüsse man besprechen könnte, Bilder posten soll bleibt unklar. Weil Menschen mit Erfahrung und Ahnung auf diesen Bildern möglicherweise erkennen können, was Du die ganze Zeit lang falsch machst. Ein EPROM auszulesen, auch eines mit einer etwas spezielleren Ansteuerung wie dem, das Du hier hast, ist eine trivial simple Aufgabe. Und die bekommst Du sehr offenkundig nicht hin. Also wird irgendwo noch ein Problem vorhanden sein, das man weder in Deinen blumigen Umschreibungen noch Deinem "unveränderten" Code von Wastl (damit wirst Du ja vermutlich das hier meinen Beitrag "Re: Altes EPROM auslesen Intersil 6654A (2xCE) mit Arduino") erahnen kann. Denn: Hättest Du alles richtig gemacht, würde es ja funktionieren. Da es aber nicht funktioniert, hast Du irgendwo irgendwas eben doch nicht richtig gemacht.
Hallo, Armin schrieb: > Warum man wegen ein paar eventuell strittigen Leitungen, deren > Anschlüsse man besprechen könnte, Bilder posten soll bleibt unklar. Weil hier viele (eigentlich alle) glauben (oder eher sicher sind) das du elementare Verdrahtungsfehler gemacht hast, die genau für die von dir beschriebenen Effekte verantwortlich sind. > ...Nur nicht zum Thema. Ich habe mittlerweile den Eindruck, das hier so ziemlich alle, mit Ausnahme von dir, im Thema sind. rhf
:
Bearbeitet durch User
Ich habe schon am 20.04 ein Ende des Threads gefordert Beitrag "Re: Altes EPROM auslesen Intersil 6654A (2xCE) mit Arduino" jetzt wird es wirklich Zeit, dass ein Mod den Laden dicht macht. Bitte - Bitte - Bitte
Stephan S. schrieb: > jetzt wird es > wirklich Zeit, dass ein Mod den Laden dicht macht. Du brauchst doch einfach nicht mehr mitzulesen. Solange hier nicht Godwin's Law erfüllt, ist es doch eher amüsant, gelegentlich solch einen völlig lernresistenten Vollhonk zuzuschauen.
der EEPROM wird auf einem anderen Breadbord (die Dinger mit den viereckigen Löchern, die ungtereinander zu viert verbunden sind) stecken und Masse wird nicht mit dem Arduino verbunden sein, oder ein Loch daneben stecken, oder Horizontal und Vertikal in den Lochreiehen vertauscht worden sein und daher keine Verbindung bestehen. irgendsowas triviales wird es am Ende sein. Ist doch immer so: wenn's nur ne IR-LED ist, die verkehrtrum angeschlossen ist.
:
Bearbeitet durch User
Thread beobachten
Seitenaufteilung abschaltenBitte 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.