Serial Monitor zeigt nichts an

Ich mache mal einen neuen Thread auf.

Upload des sketch funktioniert. Aber keine Ausgabe auf dem Serial Monitor (ProMini, FTDI, Win 7).

http://forum.arduino.cc/index.php?topic=213126.msg1589949#msg1589949

Habe verschiedene USB Ports versucht, versch Baudraten, auch RTS on close.

Ich fürchte es liegt am sketch (kann aber auch Fehler in der Schaltung, der Komponenten, der Port-Einstellungen nicht ausschließen)
Muss man irgendwas verstellen (Parität, Stoppbits, Flusssteuerung usw)?
Müsste der Serial Monitor automatisch aufklappen, wenn Daten kommen, muss man irgendwas zuvor senden? Will ja nur auslesen.

Habe den code auch hier und da mal verändert . Auch normale Ausgabe per serial.write zeigt nichts an.

Neueste FTDI Treiber sind installiert.

Sollen wir jetzt raten welchen Sketch Du zum Test verwendest?
Grüße Uwe

Da fehlt ne Klammer

Der Sketch ist ja verlinkt

http://forum.arduino.cc/index.php?topic=213126.msg1561480#msg1561480

Wo fehlt ne Klammer?

Beim kompilieren gabs keine Fehler.
Es geht auch eher um grobe inhaltliche Fehler.

Sorry, ich klicke mich hier nicht gerne durch und schaue wo ein Sketch in einem alten Beitrag drinsteht. Haste vielleicht gut gemeint, aber dafür ist mir meine Freizeit zu schade (eigentlich auch dafür, das hier zu schreiben).
Daher war die fehlende Klammer ein i-Tüpfelchen auf Uwe's Frage und damit als dezenter Hinweis gedacht.

Leider kann ich Dir inhaltlich auch nach dem Lesen des Sketches nicht helfen, dazu kenne ich mich mit Deiner Thematik leider zu wenig aus.

Da steht doch auch, dass OE = OutputEnable = CipSelect sein soll.

Solange nicht alle (nötigen?) Pins verbunden sind soll da wohl kein OV (OutputVisible :D) anliegen

Sorry, ich hatte zuerst den falschen Post verlinkt und dies erst nach 1 Minute korrigiert.
Ich wollte auch den zusammenhängenden Thread verlinken, damit's klarer wird.

Also hier nochmals der sketch

// Gameking cart reader ino sketch by Gamekin. Mostly snippets from other sources
//1 game carts have 17 Adress lines (128 K), 4in1 carts 20. So need to read up to 1 MB
//Some pin functions are unknown or unsure. So can only use CE, not OE. And use 3V.
//No RAM no EEPROMs just 1 ROM. 3x74HC595, so I think I have to read 3 Bytes each loop.
//changed. multicarts obviously only 512 KB. But I first try to read 1 game for time reasons of poor slot


#include "pins_arduino.h" 
//taken from Atariromreader unknown if needed

//Pin connected to ST_CP of 74HC595
int latchPin = 10; //Latch, SS ? might be changed, but ProMini has limited pins
//Pin connected to SH_CP of 74HC595
int clockPin = 13; //SCK
////Pin connected to DS of 74HC595
int dataPin = 11; // MOSI

int d0Pin = 2; //necessary ? most don't have this, but I have wired this
int d1Pin = 3;
int d2Pin = 4;
int d3Pin = 5;
int d4Pin = 6;
int d5Pin = 7;
int d6Pin = 8;
int d7Pin = 9;
//Arduino ProMini has internal pull-up resistors, also for data lines. Unsure if I should use them. 
//digitalWrite(d0Pin, HIGH); d0-7, digitalWrite(irqPin, HIGH); would activate them
// I have external resistors and 3.3V Arduino and cart

//a buffer for bytes to burn
#define ROM_SIZE 133120 
// in bytes. 512 KB or 1MB , but for now read a bit more than 1 game=128 KB+2
// byte buffer[ROM_SIZE];  -used by other sketch. Overflow in arry dimension error with this value
int data = 0; //Used in counting up to the ROM's maximum byte
byte myByte = 0x00; // Used later as D0-D7 byte

//unknown if need more definitions like irqPin. What about CE (at the 74HC595) and SRCLR? physically tied to GND/VCC


void setup(){
  pinMode(latchPin, OUTPUT);
  pinMode(clockPin, OUTPUT);
  pinMode(dataPin, OUTPUT);   // ---one code says INPUT here, but maybe later
}
//taken from MEEPROMMER or other projects
  void	data_bus_input() {
  pinMode(d0Pin, INPUT);
  pinMode(d1Pin, INPUT);
  pinMode(d2Pin, INPUT);
  pinMode(d3Pin, INPUT);
  pinMode(d4Pin, INPUT);
  pinMode(d5Pin, INPUT);
  pinMode(d6Pin, INPUT);
  pinMode(d7Pin, INPUT);
}

//switch IO lines of databus to OUTPUT state.  --- Unknown why input and output. EEPROM write? or combined ADR and Data lines for SegaGen
void data_bus_output() {
  pinMode(d0Pin, OUTPUT);
  pinMode(d1Pin, OUTPUT);
  pinMode(d2Pin, OUTPUT);
  pinMode(d3Pin, OUTPUT);
  pinMode(d4Pin, OUTPUT);
  pinMode(d5Pin, OUTPUT);
  pinMode(d6Pin, OUTPUT);
  pinMode(d7Pin, OUTPUT);
}

//set databus to input and read a complete byte from the bus
//be sure to set data_bus to input before    --- do I have to write to the data_bus?
byte read_data_bus(){


  Serial.begin(57600);   //max 57600 for atmega328p, unknown if FTDI drivers needs other than serial, unsure if serial.begin before pinmode
}               


void loop() {
  while (Serial.available() <=0){
    delay (200);
  }
  
  //for (int i=0; i<24; i++){    // 3x8 bits ?? first attempt from other sketch
    //void shiftOut24bit(int clockPin, int latchPin, int dataPin, unsigned long value) {  //taken from sgcexplorer
	//digitalWrite(latchPin, LOW);
	//shiftOut(dataPin, clockPin, MSBFIRST, (value & 0x00FF0000) >> 16);
	//shiftOut(dataPin, clockPin, MSBFIRST, (value & 0x0000FF00) >> 8);
	//shiftOut(dataPin, clockPin, MSBFIRST, (value & 0x000000FF));
	//digitalWrite(latchPin, HIGH);

    
 
  digitalWrite(latchPin, LOW); //make shift reg listen 
  if (data < ROM_SIZE) {                          //Do I need to open a file and filename before?
    shiftOut(dataPin, clockPin, MSBFIRST, (data >> 16)); //read 3 Bytes and shift. binary output?
    shiftOut(dataPin, clockPin, MSBFIRST, data >> 8);
    shiftOut(dataPin, clockPin, MSBFIRST, data);
    
    digitalWrite(latchPin, HIGH);
    delay(5);
    myByte = d7Pin  //originally called myDigitalRead (9), data pin 9-2 , taken from AtariRomread
         | d6Pin <<1
         | d5Pin <<2
         | d4Pin <<3
         | d3Pin <<4
         | d2Pin <<5
         | d1Pin <<6
         | d0Pin <<7;
    Serial.write(myByte);
    data++;
    delay (5);
    //digitalWrite(latchPin, LOW);
    }
   }

Die Thematik ist eigentlich ein simples lesen eines (EEP)ROMS.

Alle Pins sind leider nicht exakt bekannt, insbesondere nicht OE. Im englischen Forum meinte man, CE reicht.

Ich mache die ganze Sache auch nicht für mich alleine.
Wie lange meine Sockelkonstruktion hält kann ich nicht sagen.
Daher suche ich jemanden, der sich kurzfristig mal den Code angucken kann und mir Tipps geben kann.
Vielleicht nur ne Kleinigkeit die ich oben vergessen hab.

Gibts da nicht irgendein kurzes Testprogramm für den Serial Monitor (per FTDI)?
Das Problem liegt wohl schon am Anfang oder bei der Einstellung.

In meiner alten Zeit war OE schon nötig, sonst sind die Outs auf tristate geschaltet; da kommt dann nix.

Das ganz hat ja schon jemand mal gemacht (allerdings ohne Arduino).

http://web.archive.org/web/20071027114125/http://www.bripro.com/low/gameking/index.php?page=carts

Da ging es wohl auch ohne OE. OE soll intern an GND sein.
Die Person im englischen Forum scheint ein Experte zu sein und meint es geht auch ohne.

Nee, da heißt es: It's possible that pin #24 (GND) is /OE, but just connected to GND on the PCB.
Also nix intern an GND, sondern per Platine an GND. Das ist schon was anderes.
Häng den Pin doch einfach mal an GND - über Widerstand geht sicher auch, zur Sicherheit - und schau was passiert.

Pin 24 ja oben unter dem Epoxychip.
Ich bin nicht ganz sicher welcher Pin das unten ist. Ich vermute 46 (also hinten= S3).
Es gibt auch größere Bilder der Platinen in Web. Außerdem sehen die Multigame-Module komplett anders aus und haben mehr ADR-Leitungen.

Ich werde das versuchen, habe aber wenig Hoffnung.
Doppelte GND und VCC habe ich sonst nicht angeschlossen.
S3, wie S2 und S1 hätten ja keine Funktion über die Platine. Und ich verstehe es so, dass er die gar nicht angeschlossen hat.
Seltsam sind die Goldkontakte oben, die ja gar nicht überbrückt sind.
Vielleicht für das Nachfolgegerät, das ja ein Farbdisplay hat.

Bei den Multigames gibt es die Bezeichnungen S1-S3 nicht, dafür U1 nahe Pin 46, der hier senkrecht runter geht.
Eigentlich der einzige Pin, der für OE in Frage käme.
Ärgerlich, dass das Pinlayout und die Funktion auf der Seite nicht aktualisiert wurden.

Oh, den Code muss ich ja sicher auch noch anpassen.
Reicht da eine Def oben?

Update:

Ich habe also den vermeintlichen OE mit Widerstand an GND angeschlossen.
Seitdem funktioniert das FTDI-Board nicht mehr. Zuvor hatte ich ein FTDI eigenes Testprogramm probiert, was für den 232C ist (Test failed), womöglich lags auch daran oder es gab von den zahlreichen Kabeln und Widerständen irgendwo einen Kurzschluss.

"Das FTDI-Board hat einen Fehler gefunden und wurde deaktiviert" oder so ähnlich hieß es später als ich die IDE starten wollte. Nachher nicht mal diese Meldung.

Sowohl automatische als auch manuelle Treiber-Neuinstallation brachten keinen Erfolg.
Unbekanntes USB-Gerät. bzw USB-Gerät wurde nicht erkannt. Neueste Treiber seien stets bereits installiert. Die Treibersoftware zeigt 2 grüne Haken.
Es wird kein COM-Port mehr zur Verfügung gestellt.
Auch auf einem anderen PC wird FTDI nicht mehr erkannt.
Dort hatte ich plötzlich 2 USB-Tastaturen. Offenbar ein Konflikt, der aber so nicht angezeigt wurde.
Alles probiert. Da steht dann nur noch versuchen Sie es erneut einzustecken. Oder ersetzen Sie ansonsten das Gerät.

:frowning: So weit mal wieder zum Thema try&error :roll_eyes:

Bei Datenleitungen ist das "ausprobieren" kein Thema, aber wenn Pegel oder Strom anliegen manchmal halt tödlich für den Käfer.

Tja, was soll man machen? Ich frage mich, wofür es Widerstände usw gibt.

Ich wette aber, mein Code war falsch. Und alle (auch anderswo) haben gesagt, der wär soweit OK. Wahrscheinlich hat den kaum einer richtig gelesen.

Wenn ich von Anfang an den richtigen Code gehabt hätte, hätte es wahrscheinlich geklappt.

Ich habe insgesamt für Geräte, Spiele, Arduino und Elektronik ca 300 EUR ausgegeben. Stundenlang gelötet, tagelang gelesen usw.
Gelernt habe ich natürlich trotzdem. Nämlich, dass ich es nicht kann.

Vielleicht kommt irgendwann doch noch einer, der mehr Ahnung hat und meine Spiele braucht und irgendwann gibt es sicher einen Emulator. Nur ne Frage von Jahren.
Auch ärgerlich, das es kaum Experten gibt und viele nicht mal Willens sind, sich das ganze anzuschauen. Viel gelernt habe ich von Hilfeforen nicht. Oft wird nur abgelästert und philosophiert.

Ich frage mich, wofür es Widerstände usw gibt.

Googlen hilft immer 8)

Und alle (auch anderswo) haben gesagt, der wär soweit OK. Wahrscheinlich hat den kaum einer richtig gelesen.

Joa, wahrscheinlich - bleibt ja auch nichts Anderes übrig

Wenn ich von Anfang an den richtigen Code gehabt hätte, hätte es wahrscheinlich geklappt

So ist das immer - dann bräuchte es dafür keine Threads mehr

Ich habe insgesamt für Geräte, Spiele, Arduino und Elektronik ca 300 EUR ausgegeben. Stundenlang gelötet, tagelang gelesen usw.
Gelernt habe ich natürlich trotzdem. Nämlich, dass ich es nicht kann.

:zipper_mouth_face:

Vielleicht kommt irgendwann doch noch einer, der mehr Ahnung hat und meine Spiele braucht und irgendwann gibt es sicher einen Emulator. Nur ne Frage von Jahren.

Auf jeden Fall

Auch ärgerlich, das es kaum Experten gibt und viele nicht mal Willens sind, sich das ganze anzuschauen.

Jepp - wie oben nach dem Motto ne stramme Behauptung ist immer besser wie der schwächste Beweis

Viel gelernt habe ich von Hilfeforen nicht.

Tja, bei den einen fällt die Lernkurve flache aus als bei Anderen - das macht aber nichts, solange man dran bleibt und somit ernstes und echtes Interesse an einer Problemlösung hat

Oft wird nur abgelästert und philosophiert.

Mag sein, auf jeden Fall nicht immer

Ich sage warum ich mich nicht beteiligt habe:
Außer beruflichen Stress, ist Spielmodule auslesen und weiterzugeben, auch wenn sie alt sind, immernoch ein Copyrightverstoß. Ich will nicht dabei behilflich sein.
Viele Grüße Uwe

Wer sagt denn, dass ich ausgelesene ROMs weitergegeben hätte? Falls mir jemand geholfen hätte, hätte ich ihm auch das Original geben können. Die Spiele kann man ja teils auch für wenig Geld kaufen, dann hätte man das Original und den Dump. Nur wer kann die schon selber dumpen, vor allem ohne Sockel.

Es ging doch darum, dass es überhaupt erst mal einen Emulator gibt. Man kann dann ja auch Homebrews entwicklen usw.
Abgesehen davon sind die Spiele bzw Inhalte selbst größtenteils geklaut (Moduldesign, Cover, Titelgrafiken, Sound usw).