Arduino Pinball Controller

[bontango]

Geht bei mir, was hast Du bei DIP Switch S2 eingestellt?

Am meisten siehst Du wenn Du mit S1 Dip7&8 auf ON startest und dich dann via ssh als user pi; pwd:bontango einlogst.

Dann von dort ./run_lisy_mini aufrufen, dann hast du den log direkt sichtbar.

[Black Knight]

Das scheint an dem PI3B+ zu liegen.

Wenn wenn ich stattdessen meinen PiZero in die Lisy_Mini stecke, dann bootet er und zeigt danach die rote LED - so wie ich das kenne, wenn er keine USB Verbindung findet. Außerdem schreibt er mir auch ein Log-File, in dem er sich über die fehlende USB Verbindung beschwert. Der Pi3B+ tut das alles nicht. Er reagiert auch nicht auf die Shutdown-Taste, sondern blinkt einfach nur stur mit der gelben LED herum.

Ich könnte den Pi Zero jetzt natürlich in den APC 3.0 stecken und über I2C betreiben, aber dazu müsste irgendein Held in Lisy einbauen, dass er nicht mehr die DIP-Schalter, sondern das APC Menü für PinMame Game-Nr. u.s.w. nutzt. 🙄

[Black Knight]

vor 14 Stunden schrieb Black Knight:

Ich könnte den Pi Zero jetzt natürlich in den APC 3.0 stecken und über I2C betreiben

Ich hab's einfach mal gemacht und I2C funktioniert. 👍 Nach dem Booten zeigt er im Display 'HotTip' und dann springt natürlich die rote LED an, da er das entsprechende ROM-File nicht findet.

Beim Pi3B+ auch im APC 3.0 dasselbe: er blinkt nur gelb.

[bontango]

Das hört sich wirklich nach einem Problem mit dem 3B+ an, leider habe ich keinen hier zum testen.

Könnte ein Problem mit der Wiring PI library von Gordon sein, da gab es schon mit dem 4B Probleme.

Gordon hat leider die Entwicklung eingestellt: http://wiringpi.com/news/

Ich schau mir das gern mal an wenn Du mir den 3B+ zukommen lässt

 

Gruesse

Ralf

[Black Knight]

vor 4 Stunden schrieb bontango:

Ich schau mir das gern mal an wenn Du mir den 3B+ zukommen lässt

Wenn wir das vorher gewusst hätten; das Ding hat ja ein paar Monate bei dir gelegen.

Mir wäre aber eigentlich wichtiger, das Kapitel APC 3.0 abschließen zu können. Meinst du, du könntest bei Gelegenheit mal den Dip-Schalter Ersatz einbauen? Damit könnte ich die Hard- und Software testen und den 3.0 releasen.

Wenn's bei dir gerade gar nicht passt, dann gib mir doch vielleicht einen Tipp, wo ich den entsprechenden Quellcode finde. Vielleicht werde ich da ja irgendwie schlau draus.

[bontango]

Bau ich ASAP ein 🙄 spätestens zum WE hörst Du was von mir!

[Black Knight]

Das wäre super.

[bontango]

vor 20 Stunden schrieb Black Knight:

Das wäre super.

habe gerade deinen letzten Stand 0.14 geladen und versucht zu kompilieren:

Arduino: 1.8.13 (Windows 10), Board: "Arduino Uno"

In file included from N:\Projekte\LISY_Mini\Williams\APC-00.14\APC\APC.ino:6:0:

Sound.h:31:13: error: expected ')' before '*' token

   CDAC(Dacc *_dac, uint32_t _dacId, IRQn_Type _isrId) : m_dac(_dac), m_dacId(_dacId), m_isrId(_isrId), m_cb(NULL) { m_cbData = NULL; };

             ^

In file included from N:\Projekte\LISY_Mini\Williams\APC-00.14\APC\APC.ino:6:0:

Sound.h:159:3: error: 'Dacc' does not name a type

   Dacc             *m_dac;

   ^~~~

 

 

[Black Knight]

Du hast als Board den Uno eingestellt, dass muss aber 'Arduino DUE (programming port)' sein.

[bontango]

Umgestellt, compile geht jetzt, Danke! (Musste die IDE nach meinem letzten PC Crash neu installieren)

Aber: meine LISY kommt jetzt nach dem ersten API Befehl mit nem segmentation fault um die Ecke

Info: I2C communication to APC successfull initiated
[917.010393][0.040917] ask for connected hardware
[917.010530][0.000137] API_write(1 bytes): 0x00
./run_lisy_apc: line 1:  3352 Segmentation fault

Ich versuche da nen SDtring zu lesen und lese bis ich \0 bekomme. Hattest Du da was geändert?

 

 

[bontango]

add on: das lief im mai schon mal, die letzte Version gab aber auch schon den erwartetetn 'APC' string nicht zurück, ist aber wohl nicht aufgefallen weil kein seg-fault kam.

Sollte so aussehen:

pi@lisy(ro):~$ ./run_lisy_apc
LISY basic DEBUG activ
[961.420030][0.000014] LISY DEBUG timer set
[961.420266][0.000236] Info: udp switch reader server for debug mode succesfully                                     started
[961.420302][0.000036] LISY APC Hardware init start
Info: I2C communication to APC successfull initiated
[961.460913][0.040611] ask for connected hardware
[961.460987][0.000074] API_write(1 bytes): 0x00
[961.462224][0.001237] API_read_string: APC

[Black Knight]

Läuft die Kommunikation über USB oder I2C?

Seit kurzem gibt es da ein neues Setting, mit dem das eingestellt werden muss - standardmäßig steht das auf 2 (USB).

const byte APC_defaults[64] =  {0,3,3,1,2,0,0,0,		 	// system default settings
                                        X

Wenn du über I2C kommunizieren möchtest, dann musst du aus der 2 eine 1 machen.

[bontango]

Jetzt läuft er durch, aber den richtigen String gibt er immer noch nicht zurück

[038.075892][0.040557] ask for connected hardware
[038.076031][0.000139] API_write(1 bytes): 0x00
[038.076630][0.000599] API_read_string:
Info: hardware ID is  (1)

Aber so komme ich erst mal weiter und kann anfangen den 0x40er API zu implementieren.

Was sollte ich denn per default da zurück bekommen und wie kann ich das (auf dem Schreibtisch) ändern?

[Black Knight]

vor 40 Minuten schrieb bontango:

Jetzt läuft er durch, aber den richtigen String gibt er immer noch nicht zurück

OK, USB klappt bei mir alles noch, also nehme ich an du probierst gerade I2C, richtig?

vor 43 Minuten schrieb bontango:

Was sollte ich denn per default da zurück bekommen und wie kann ich das (auf dem Schreibtisch) ändern?

Mit 0x40 1 fragst du immer ein Setting aus der Gruppe 1 (aktive Game) ab. Da wir beim APC als 'Aktive Game' USBcontrol gewählt haben, bekommst du also die Settings aus USBcontrol zurück. Wie im APC.ino stehen auch im USBcontrol.ino die Standardsettings am Anfang in USB_defaults. Normalerweise ist da alles 0, aber wenn du z.B. folgendes einträgst:

							// offsets of settings in the settings array
#define USB_Watchdog 0		// watchdog enable setting
#define USB_Debug 1		    // USB debug mode
#define USB_LisyMode 2		//
#define USB_PinMameGame 3	// number of the game to be run in PinMame
#define USB_DebugDisplay 4	// selected debug mode
#define USB_DebugSwitch	5	// selected debug mode
#define USB_DebugLamp	6	// selected debug mode
#define USB_DebugCoil	7	// selected debug mode
#define USB_DebugSound	8	// selected debug mode
#define USB_PinMameSound 9	// use APC sound HW or old sound board?

const byte USB_defaults[64] = {0,0,45,46,47,0,0,0,   // game default settings

dann bekommst du mit

0x40 1 2

den Wert 45 zurück, was wir ja jetzt als Wert für die Options-DIP-Schalter nehmen wollen. Mit 

0x40 1 3

kriegst du 46, was die Nummer des PinMame Games wäre u.s.w.

[bontango]

Ja, über I2C, muss ich da trottdem in USB_defaults etwas eintragen?

Derzeit bekomme ich bei com über I2C nur Nullen zurück:

LISY basic DEBUG activ
[969.397819][0.000014] LISY DEBUG timer set
[969.398129][0.000310] Info: udp switch reader server for debug mode succesfully started
[969.398228][0.000099] LISY APC Hardware init start
Info: I2C communication to APC successfull initiated
[969.438906][0.040678] ask for connected hardware
[969.439036][0.000130] API_write(1 bytes): 0x00
[969.439647][0.000611] API_read_string:
Info: hardware ID is  (1)
[969.439807][0.000160] API_write(1 bytes): 0x06
[969.440371][0.000564] API_read_byte: 0x00
[969.440469][0.000098] API_write(1 bytes): 0x01
[969.441028][0.000559] API_read_string:
[969.441124][0.000096] LISY_Mini: Client has SW version:
[969.441214][0.000090] API_write(1 bytes): 0x02
[969.441775][0.000561] API_read_string:
[969.441871][0.000096] LISY_Mini: Client uses API Version:
[969.441960][0.000089] API_write(1 bytes): 0x03
[969.442522][0.000562] API_read_byte: 0x00

 

[Black Knight]

vor einer Stunde schrieb bontango:

Ja, über I2C, muss ich da trottdem in USB_defaults etwas eintragen?

Nö, nur wenn du wirklich die Settings abfragen willst, aber die normale Kommunikation muss auch so funktionieren.

Hast du eine SD-Karte am APC auf der irgendwelche Settings gespeichert sein könnten?

Hast du GIT installiert? Könntest du also mal meine SW Version vom 15.5. 11:03Uhr einspielen? Da hat es ja meines Wissens nach noch geklappt.

[bontango]

Hatte die alte Version noch auf der Platte, da sah es zumindest erst einmal besser aus

aber beim Rückswitch auf die aktuelle Version war es da genau so.

Ich vermute er verhaspelt sich irgendwo und kommt dann aus dem Tritt,

evtl. bin ich auch zu schnell unterwegs.

Ich wühl mal was, melde mich ...

 

[Black Knight]

OK. Ansonsten könntest du mal versuchen, den ersten IF in I2C_transmit() raus zu nehmen

void I2C_transmit() {  // send a byte on master request (I2C)
    if (APC_settings[ConnType] == 1 && APC_settings[ActiveGame] == 3) { // I2C selected and USBcontrol active?
        if (USB_I2C_TxReadPointer == USB_I2C_TxWritePointer) {  // no data in buffer
            ErrorHandler(40,0,USB_I2C_TxReadPointer);}
        Wire1.write(USB_I2C_TxBuffer[USB_I2C_TxReadPointer]); // send byte
        USB_I2C_TxReadPointer++;           // increase buffer pointer
        if (USB_I2C_TxReadPointer > USB_I2C_TxBuffer_Size) { // end of buffer reached?
            USB_I2C_TxReadPointer = 0;}}} // start from 0

Da wird geprüft, ob I2C (APC_settings[ConnType] == 1) und USBcontrol (APC_settings[ActiveGame] == 3) selektiert sind. Falls nicht, wird keine Antwort gesendet.

Das ist so ziemlich das Einzige, was ich im Bereich I2C geändert habe.

[bontango]

sieht so aus als hätte ich noch manchmal noch ein Nullbyte im I2C Buffer, woraufhin er dann

bei den Befehlen immer einen hinterher hinkt.

Wenn ich APC und PI boote klappt es (einmal), ist nur blöd für die Tests

Ich schau mal dass ich das failsafe mache und entweder Flushe oder am Anfang so lange

lese bis ich 'APC' bekomme.

 

Morgen mehr

 

Gruesse

Ralf

[bontango]

Ich ignoriere/überlese jetzt \0 Bytes die ich am Anfang von 'get connected hW bekomme'

Das funktioniert auch soweit gut. Habe jetzt ein kleines 'standalone' programm geschrieben

welches nur den I2C Bus abfragt. (brauche ich für meinen bash startscript)

By erkennatem I2C  client auf 0x44 checke ich dann mit Befehl '0' ob

das wirklich ein 'APC' ist und frage dann erst über 0x40 den DIP Switch ab.

 

Dabei tritt ein komischer Effekt auf, bei jedem fünften Aufruf bekomme ich statt der

erwarteten '0' für den Dispswitch '67' zurück. Der nächste Aufruf hat dann mit

den führenden \0 Bytes zu kämpfen, dann geht es wieder vier Mal, und so weiter

(siehe Log unten)

Kannst Du Dir da einen Reim drauf machen?

 

 

pi@lisy(rw):~/lisy/src/lisy/testprogs/i2c$ ./getDIPfromAPC 1 -v
we are in verbose mode
try to get value of dip number 1
API_read_string: Byte no 0 is (0x41)"A"
API_read_string: Byte no 1 is (0x50)"P"
API_read_string: Byte no 2 is (0x43)"C"
connected HW is: APC
value of Dip number 1 is 0

pi@lisy(rw):~/lisy/src/lisy/testprogs/i2c$ ./getDIPfromAPC 1 -v
we are in verbose mode
try to get value of dip number 1
API_read_string: Byte no 0 is (0x41)"A"
API_read_string: Byte no 1 is (0x50)"P"
API_read_string: Byte no 2 is (0x43)"C"
connected HW is: APC
value of Dip number 1 is 0

pi@lisy(rw):~/lisy/src/lisy/testprogs/i2c$ ./getDIPfromAPC 1 -v
we are in verbose mode
try to get value of dip number 1
API_read_string: Byte no 0 is (0x41)"A"
API_read_string: Byte no 1 is (0x50)"P"
API_read_string: Byte no 2 is (0x43)"C"
connected HW is: APC
value of Dip number 1 is 0

pi@lisy(rw):~/lisy/src/lisy/testprogs/i2c$ ./getDIPfromAPC 1 -v
we are in verbose mode
try to get value of dip number 1
API_read_string: Byte no 0 is (0x41)"A"
API_read_string: Byte no 1 is (0x50)"P"
API_read_string: Byte no 2 is (0x43)"C"
connected HW is: APC
value of Dip number 1 is 0

pi@lisy(rw):~/lisy/src/lisy/testprogs/i2c$ ./getDIPfromAPC 1 -v
we are in verbose mode
try to get value of dip number 1
API_read_string: Byte no 0 is (0x41)"A"
API_read_string: Byte no 1 is (0x50)"P"
API_read_string: Byte no 2 is (0x43)"C"
connected HW is: APC
value of Dip number 1 is 67

pi@lisy(rw):~/lisy/src/lisy/testprogs/i2c$ ./getDIPfromAPC 1 -v
we are in verbose mode
try to get value of dip number 1
API_read_string: Byte no 0 is (0x00)""
API_read_string: Byte no 0 is (0x00)""
API_read_string: Byte no 0 is (0x41)"A"
API_read_string: Byte no 1 is (0x50)"P"
API_read_string: Byte no 2 is (0x43)"C"
connected HW is: APC
value of Dip number 1 is 0

pi@lisy(rw):~/lisy/src/lisy/testprogs/i2c$ ./getDIPfromAPC 1 -v
we are in verbose mode
try to get value of dip number 1
API_read_string: Byte no 0 is (0x41)"A"
API_read_string: Byte no 1 is (0x50)"P"
API_read_string: Byte no 2 is (0x43)"C"
connected HW is: APC
value of Dip number 1 is 0
pi@lisy(rw):~/lisy/src/lisy/testprogs/i2c$

 

[Black Knight]

vor einer Stunde schrieb bontango:

Kannst Du Dir da einen Reim drauf machen?

Versuch doch mal in USB_defaults einen anderen Wert als Null für die DIP-Switches zu nehmen, z.B. mit

const byte USB_defaults[64] = {0,0,45,46,47,0,0,0,   // game default settings

Dann wüssten wir, ob der 0x40 Lesebefehl überhaupt funktioniert oder ob einfach nur Nullen zurück kommen.

[bontango]

Ähnliches Verhalten, erst kommt (richtig) die 45 zurück, aber nach ein paar Versuchen wieder die 67 und danach die führenden Nullen. Zudem braucht er zwei/drei mal wenn ich auf einen anderen Switch umschalte dass er den richtigen Wert zurück gibt, Anfangs gibt er den Wert des alten Switch zurück.

 

pi@lisy(ro):~/lisy/src/lisy/testprogs/i2c$ ./getDIPfromAPC 1 -v
we are in verbose mode
try to get value of dip number 1
API_read_string: Byte no 0 is (0x00)""
API_read_string: Byte no 0 is (0x41)"A"
API_read_string: Byte no 1 is (0x50)"P"
API_read_string: Byte no 2 is (0x43)"C"
connected HW is: APC
value of Dip number 1 is 0
pi@lisy(ro):~/lisy/src/lisy/testprogs/i2c$ ./getDIPfromAPC 2 -v
we are in verbose mode
try to get value of dip number 2
API_read_string: Byte no 0 is (0x00)""
API_read_string: Byte no 0 is (0x00)""
API_read_string: Byte no 0 is (0x00)""
API_read_string: Byte no 0 is (0x00)""
API_read_string: Byte no 0 is (0x00)""
API_read_string: Byte no 0 is (0x00)""
API_read_string: Byte no 0 is (0x00)""
API_read_string: Byte no 0 is (0x00)""
API_read_string: Byte no 0 is (0x00)""
API_read_string: Byte no 0 is (0x00)""
API_read_string: Byte no 0 is (0x00)""
API_read_string: Byte no 0 is (0x00)""
API_read_string: Byte no 0 is (0x41)"A"
API_read_string: Byte no 1 is (0x50)"P"
API_read_string: Byte no 2 is (0x43)"C"
connected HW is: APC
value of Dip number 2 is 45
pi@lisy(ro):~/lisy/src/lisy/testprogs/i2c$ ./getDIPfromAPC 2 -v
we are in verbose mode
try to get value of dip number 2
API_read_string: Byte no 0 is (0x41)"A"
API_read_string: Byte no 1 is (0x50)"P"
API_read_string: Byte no 2 is (0x43)"C"
connected HW is: APC
value of Dip number 2 is 0
pi@lisy(ro):~/lisy/src/lisy/testprogs/i2c$ ./getDIPfromAPC 2 -v
we are in verbose mode
try to get value of dip number 2
API_read_string: Byte no 0 is (0x00)""
API_read_string: Byte no 0 is (0x00)""
API_read_string: Byte no 0 is (0x00)""
API_read_string: Byte no 0 is (0x00)""
API_read_string: Byte no 0 is (0x00)""
API_read_string: Byte no 0 is (0x00)""
API_read_string: Byte no 0 is (0x00)""
API_read_string: Byte no 0 is (0x41)"A"
API_read_string: Byte no 1 is (0x50)"P"
API_read_string: Byte no 2 is (0x43)"C"
connected HW is: APC
value of Dip number 2 is 45
pi@lisy(ro):~/lisy/src/lisy/testprogs/i2c$ ./getDIPfromAPC 2 -v
we are in verbose mode
try to get value of dip number 2
API_read_string: Byte no 0 is (0x41)"A"
API_read_string: Byte no 1 is (0x50)"P"
API_read_string: Byte no 2 is (0x43)"C"
connected HW is: APC
value of Dip number 2 is 45
pi@lisy(ro):~/lisy/src/lisy/testprogs/i2c$ ./getDIPfromAPC 2 -v
we are in verbose mode
try to get value of dip number 2
API_read_string: Byte no 0 is (0x41)"A"
API_read_string: Byte no 1 is (0x50)"P"
API_read_string: Byte no 2 is (0x43)"C"
connected HW is: APC
value of Dip number 2 is 45
pi@lisy(ro):~/lisy/src/lisy/testprogs/i2c$ ./getDIPfromAPC 2 -v
we are in verbose mode
try to get value of dip number 2
API_read_string: Byte no 0 is (0x41)"A"
API_read_string: Byte no 1 is (0x50)"P"
API_read_string: Byte no 2 is (0x43)"C"
connected HW is: APC
value of Dip number 2 is 67
pi@lisy(ro):~/lisy/src/lisy/testprogs/i2c$ ./getDIPfromAPC 2 -v
we are in verbose mode
try to get value of dip number 2
API_read_string: Byte no 0 is (0x00)""
API_read_string: Byte no 0 is (0x2d)"-"
API_read_string: Byte no 0 is (0x41)"A"
API_read_string: Byte no 1 is (0x50)"P"
API_read_string: Byte no 2 is (0x43)"C"
connected HW is: APC
value of Dip number 2 is 45
pi@lisy(ro):~/lisy/src/lisy/testprogs/i2c$
pi@lisy(ro):~/lisy/src/lisy/testprogs/i2c$
pi@lisy(ro):~/lisy/src/lisy/testprogs/i2c$ ./getDIPfromAPC 3 -v
we are in verbose mode
try to get value of dip number 3
API_read_string: Byte no 0 is (0x41)"A"
API_read_string: Byte no 1 is (0x50)"P"
API_read_string: Byte no 2 is (0x43)"C"
connected HW is: APC
value of Dip number 3 is 45
pi@lisy(ro):~/lisy/src/lisy/testprogs/i2c$ ./getDIPfromAPC 3 -v
we are in verbose mode
try to get value of dip number 3
API_read_string: Byte no 0 is (0x41)"A"
API_read_string: Byte no 1 is (0x50)"P"
API_read_string: Byte no 2 is (0x43)"C"
connected HW is: APC
value of Dip number 3 is 45
pi@lisy(ro):~/lisy/src/lisy/testprogs/i2c$ ./getDIPfromAPC 3 -v
we are in verbose mode
try to get value of dip number 3
API_read_string: Byte no 0 is (0x41)"A"
API_read_string: Byte no 1 is (0x50)"P"
API_read_string: Byte no 2 is (0x43)"C"
connected HW is: APC
value of Dip number 3 is 46
pi@lisy(ro):~/lisy/src/lisy/testprogs/i2c$
pi@lisy(ro):~/lisy/src/lisy/testprogs/i2c$
pi@lisy(ro):~/lisy/src/lisy/testprogs/i2c$ ./getDIPfromAPC 3 -v
we are in verbose mode
try to get value of dip number 3
API_read_string: Byte no 0 is (0x41)"A"
API_read_string: Byte no 1 is (0x50)"P"
API_read_string: Byte no 2 is (0x43)"C"
connected HW is: APC
value of Dip number 3 is 46
pi@lisy(ro):~/lisy/src/lisy/testprogs/i2c$ ./getDIPfromAPC 3 -v
we are in verbose mode
try to get value of dip number 3
API_read_string: Byte no 0 is (0x41)"A"
API_read_string: Byte no 1 is (0x50)"P"
API_read_string: Byte no 2 is (0x43)"C"
connected HW is: APC
value of Dip number 3 is 67
pi@lisy(ro):~/lisy/src/lisy/testprogs/i2c$ ./getDIPfromAPC 3 -v
we are in verbose mode
try to get value of dip number 3
API_read_string: Byte no 0 is (0x00)""
API_read_string: Byte no 0 is (0x2d)"-"
API_read_string: Byte no 0 is (0x41)"A"
API_read_string: Byte no 1 is (0x50)"P"
API_read_string: Byte no 2 is (0x43)"C"
connected HW is: APC
value of Dip number 3 is 46
pi@lisy(ro):~/lisy/src/lisy/testprogs/i2c$ ./getDIPfromAPC 3 -v
we are in verbose mode
try to get value of dip number 3
API_read_string: Byte no 0 is (0x41)"A"
API_read_string: Byte no 1 is (0x50)"P"
API_read_string: Byte no 2 is (0x43)"C"
connected HW is: APC
value of Dip number 3 is 46
pi@lisy(ro):~/lisy/src/lisy/testprogs/i2c$ ./getDIPfromAPC 4 -v
we are in verbose mode
try to get value of dip number 4
API_read_string: Byte no 0 is (0x41)"A"
API_read_string: Byte no 1 is (0x50)"P"
API_read_string: Byte no 2 is (0x43)"C"
connected HW is: APC
value of Dip number 4 is 46
pi@lisy(ro):~/lisy/src/lisy/testprogs/i2c$ ./getDIPfromAPC 4 -v
we are in verbose mode
try to get value of dip number 4
API_read_string: Byte no 0 is (0x41)"A"
API_read_string: Byte no 1 is (0x50)"P"
API_read_string: Byte no 2 is (0x43)"C"
connected HW is: APC
value of Dip number 4 is 47
pi@lisy(ro):~/lisy/src/lisy/testprogs/i2c$

 

[Black Knight]

In I2C_transmit in USBcontrol.ino werden die Bytes gesendet, wenn der Master sie anfordert (onRequest). Wenn der Master mehr Bytes anfordert, als im Transmit-Puffer stehen, dann gibt es eine Fehlermeldung auf den Displays, die du jetzt natürlich nicht siehst.

Die gleiche Fehlermeldung wird allerdings auch über den seriellen Anschluss ausgegeben, d.h. wenn du bei deiner Arduino IDE den seriellen Monitor einschaltest (der Button oben rechts in der Ecke), dann solltest du diese Meldungen sehen können. Wenn dann ein 'Error 40' auftaucht, dann wissen wir, dass der Transmit-Puffer leer läuft.

Zusätzlich könntest du noch einen Serial.write einfügen, dann könntest du am seriellen Monitor sehen, was er auch über I2C ausgibt. Das sähe dann so aus:

void I2C_transmit() {                                       // send a byte on master request (I2C)
  if ((APC_settings[ConnType] == 1) && (APC_settings[ActiveGame] == 3)) { // I2C selected and USBcontrol active?
    if (USB_I2C_TxReadPointer == USB_I2C_TxWritePointer) {  // no data in buffer
      ErrorHandler(40,0,USB_I2C_TxReadPointer);}
    Wire1.write(USB_I2C_TxBuffer[USB_I2C_TxReadPointer]);   // send byte
    Serial.write(USB_I2C_TxBuffer[USB_I2C_TxReadPointer]);  // diesen Befehl einfügen um as Gleiche auf den seriellen Anschluss zu schicken
    USB_I2C_TxReadPointer++;                                // increase buffer pointer
    if (USB_I2C_TxReadPointer > USB_I2C_TxBuffer_Size) {    // end of buffer reached?
      USB_I2C_TxReadPointer = 0;}}}                         // start from 0

 

[bontango]

habe die Line eingefügt, leider nur 'Schmutzzeichen' im Monitor, könntest Du das noch formatieren?

Wobei ich bei den fehlerhaften Ausgaben mehr Schmutzzeichen bekomme ..

 

[Black Knight]

Da wird die Bitrate nicht stimmen. In dem Fenster des seriellen Monitors kann man die unten einstellen, das müssen 115200Bd sein.