Entwicklung APC 3.0 -> Lisy_APC

[Black Knight]

Anregungen zum Lisy_APC sind bisher ja eher rar, also scheint nichts grundsätzliches mehr zu fehlen.

Daher will ich mir schon mal langsam Gedanken über die Integration des Raspi zu machen.

@bontango An welche Pins des Pi soll ich denn meine I2C Leitungen anschließen? Der Pi läuft ja auch mit 3,3V, oder?

Ich nehme an, wir würden den APC dann als Slave anschließen. Welche I2C Adresse hättest du gerne?

Gibt's sonst noch I2C Einstellungen, die ich vornehmen sollte? Ich habe die Tabelle mit den I2C Möglichkeiten des DUE mal angehängt.

[bontango]

Ja, der Pi hat auch 3,3 Volt level, SDA ist auf pin3 und SCL auf pin5, ist hier ganz gut erklärt

http://www.netzmafia.de/skripten/hardware/RasPi/RasPi_I2C.html

pullups hat der Raspberry schon drauf.

Auf der LISY-Mini hast Du SDA und SCL auch auf den Pins 3 & 5 auf der PHAT Schnittstelle, da könnstest Du zum Test einfach abgreifen.

( ich schau mal ob ich relativ einfach mit ner DIP Switch Einstellung von USB auf I2C beim APC umstellen kann )

Der PI läuft als Master, Adressen habe ich belegt  0x40 bis 0x43 (PICs) und 0x50 bis 0x58 (eeprom alte Version), wie wäre es mit 0x44?

I2C parameter fahre ich recht konservativ mit defaultwerten (ich meine 100KHz, muss ich aber nochmal schauen) , und mache einfach einen 'open' und danch 'fcntl'

//******************
 // PIC 1 - Displays
 //******************
 if ((fd_disp_pic = open( I2C_DEVICE,O_RDWR)) < 0)
        lisy80_error(2);
 // Set the port options and set the address of the device we wish to speak to
 if (ioctl(fd_disp_pic, I2C_SLAVE, DISP_PIC_ADDR) < 0)
        lisy80_error(3);

 

 

[Black Knight]

vor einer Stunde schrieb bontango:

ich schau mal ob ich relativ einfach mit ner DIP Switch Einstellung von USB auf I2C beim APC umstellen kann

Können wir nicht einfach den Erkennungswiderstand vom Lisy_Mini weg lassen? Dann müsste Lisy doch eigentlich auf I2C nachfragen und könnte anhand der Adresse erkennen, dass ein APC dran ist, oder?

100KHz müssen ja reichen, wir fahren den USB Port ja auch nur mit 115200Bd. Was mir mehr Sorgen macht ist, dass laut Arduino Seite in der I2C Library nur ein Puffer von 32Byte verwendet wird. Das ist gerade mal ein Viertel von dem was wir jetzt haben. Da werden wir die Lib wohl ändern müssen.

[bontango]

vor 11 Stunden schrieb Black Knight:

Können wir nicht einfach den Erkennungswiderstand vom Lisy_Mini weg lassen? Dann müsste Lisy doch eigentlich auf I2C nachfragen und könnte anhand der Adresse erkennen, dass ein APC dran ist, oder?

oder ich checke zuerst ob auf einer der I2C Adressen jemand wohnt, dann kann der Widerstand drin bleiben

[Black Knight]

Andererseits macht er auf dem Lisy_APC auch nicht mehr wirklich Sinn, oder?

[bontango]

Ging jetzt nur um den 'Schnelltest' um die I2C Verbindung mit der bestehenden HW zu testen. 'Nachher' kann der natülich weg.

[Black Knight]

Ah, OK.

Ja, das macht Sinn. Dann muss ich den nicht auslöten.

[Black Knight]

Dann schließe ich den Arduino jetzt also an Pin 3 und 5 des Raspi an, stelle 100Khz I2C clock ein und melde mich mit Adresse 0x44, OK?

[bontango]

OK, wo schliesse ich das dann am Arduino an?

btw: ne Leitung für GND brauchen wir auch noch, oder?

[Black Knight]

vor 1 Stunde schrieb bontango:

OK, wo schliesse ich das dann am Arduino an?

Ich würde dann die Pins SCL1 und SDA1 nehmen, das sind die beiden Pins direkt neben dem Reset-Taster. Da ist auch ein GND in der Nähe.

Ich habe aber noch nicht mit der Implementierung angefangen, du kannst also auch noch nix ausprobieren. Sollte aber eigentlich recht einfach sein, es gibt eine passende Library dafür:

https://www.arduino.cc/en/Reference/Wire

Machst du noch ein Lisy-Update, das den Erkennungswiderstand ignoriert und mit Adresse 0x44 spricht? Dann probiere ich das diese Woche mal aus.

[bontango]

vor 23 Stunden schrieb Black Knight:

Machst du noch ein Lisy-Update, das den Erkennungswiderstand ignoriert und mit Adresse 0x44 spricht?

Mach ich, bzw. schau ich mir an und melde mich ...

[Black Knight]

Super, ich werde mich dann vermutlich am WE auch mal um SW Unterstützung auf Arduino Seite kümmern.

Außerdem kämpfe ich gerade damit, den Pi auf dem APC unter zu bringen und sehe momentan keinen Platz mehr für die DIP-Schalter. Bei einem Zero würde das wohl noch passen, aber beim 3B sieht's schlecht aus (siehe Bild).

Das Ganze kann sowieso nur passen, wenn ich die drei UDN2981 Levelshifter ICs für die Spulentreiber los werde. Das ist zwar kein Problem, aber viel Freiraum habe ich danach trotzdem nicht. Wenn die Anschlüsse des PI noch erreichbar sein sollen, dann muss ich ihn so platzieren wie auf dem Bild. Ein klein bisschen nach oben schieben ginge wohl noch wenn ich den Anschluss für die SD-Karte nicht ändern möchte, aber dann wird's schon bald knapp falls jemand die USB-Buchsen des Pi benutzen möchte.

Also überlege ich gerade, was denn schief gehen kann wenn Lisy nur noch die drei LEDs, den Shutdown Taster und den den Serial Stecker für den Notfall zur Verfügung hat.

Nach dem Powerup stelle ich mir das so vor:

Lisy sucht über I2C nach Gesellschaft und findet den APC mit Adresse 0x44. Lisy weiß nun, dass keine DIPs da sind und holt mit dem neuen Lisy-API Befehl 'Read HW Setting' (0x40) die DIP Settings und ggfs. die PinMame Game Nr. ab, die der Nutzer über die APC Menüs vorher eingestellt hat.

Momentan sehe ich da nur zwei Einschränkungen: der APC muss eine SD-Karte haben, sonst gibt's nach dem Powerup nur die Defaultwerte, aber die braucht man ja für Sound sowieso. Weiterhin müssten wir einen Weg finden wie der APC Lisy mitteilen kann, dass sich die Settings geändert haben, sonst müsste man jedes mal einen Power-Cycle machen - andererseits ist das ja mit den DIP-Schaltern vermutlich auch so oder überprüft Lisy die regelmäßig?

Was kann denn sonst noch schief gehen? Wenn aus irgendeinem Grund keine Kommunikation zwischen Lisy und APC zustande kommt kann man dann natürlich keinen Debug Mode o.ä. einschalten, aber wenn das passiert ist sowieso was grundsätzliches faul.

[bontango]

vor 13 Stunden schrieb Black Knight:

Also überlege ich gerade, was denn schief gehen kann wenn Lisy nur noch die drei LEDs, den Shutdown Taster und den den Serial Stecker für den Notfall zur Verfügung hat.

Debug wär schon schön, hat mir in der Vergangenheit immer gute Dienste geleistet wenn Probleme 'remote' gelöst werden mussten.

Debug einschalten, testen, runterfahren, SD Karte lesen, Debugfile an mich schicken. Das kriegt fast jeder hin ...

Bekommst Du irgendwo noch einen Pin-Header unter, den man dann mit Jumpern bestücken kann? Bevorzugt 2x6, notfalls würde es auch 1x2 tun.

Alternativ könnte man auch überlegen die Platine zu vergroessern 😎

[Black Knight]

vor 1 Stunde schrieb bontango:

Debug einschalten, testen, runterfahren, SD Karte lesen, Debugfile an mich schicken. Das kriegt fast jeder hin ...

Das würde ja auch alles weiterhin funktionieren. Es geht mir jetzt nur um den Fall, dass die Kommunikation nicht zustande kommt und der Arduino dem Pi nicht sagen kann, dass der Debug-Mode eingeschaltet sein soll. Ist halt die Frage, ob der Debug-Mode dann überhaupt viel hilft.

vor 1 Stunde schrieb bontango:

Bekommst Du irgendwo noch einen Pin-Header unter, den man dann mit Jumpern bestücken kann? Bevorzugt 2x6, notfalls würde es auch 1x2 tun.

Ja, das muss noch irgendwo passen. Das wäre dann ja auch nur für den absoluten Notfall, wird also normalerweise gar nicht bestückt.

Wenn ich den I2C Zugang in die SW einbaue, dann würde ich auch direkt die Lisy-Settings anlegen. Wir können die DIP-Schalter und Jumper direkt abbilden, wie im Lisy API Beitrag vorgeschlagen:

Nr.   // Bedeutung
0     // PinMame Game number
1     // DIP value 1
2     // DIP value 2
3     // Debug Jumpers

Aber wir können das auch komfortabler machen und die Settings weiter aufschlüsseln. Ein Beispiel wäre:

Nr.   // Bedeutung
0     // PinMame Game number
1     // Facecandy (On/Off)
2     // Wlan Hotspot
3     // MPF (On/off)
4     // Lisy Sound Debug (On/Off)
5     // Lisy Switch Debug (On/Off)
 u.s.w.

Wie hättest du es denn gerne?

Bisher gibt es

- Bool-Settings -> also On/Off

- Num-Settings -> ein vom Nutzer einstellbarer Zahlenwert (z.B. Lautstärke)

- Text-Settings -> eine Liste von Texteinträgen

Intern ist jedes Setting ein Byte groß, beim Bool ist dieses dann entweder 0 oder 1, beim Num die eingestellte Zahl und beim Text die Position des gewählten Textes in der Liste.

Aber das System ist sehr flexibel, du hast da also die freie Auswahl.

[Black Knight]

Ich habe den Schaltplan für den Lisy_APC erstellt und den Lisy Block angehängt. Schau mal, ob das so OK ist.

Die kompletten Pläne gibt's hier

Außer Lisy hat sich nur noch was bei den Spulentreibern geändert. Da verwende ich jetzt Logic_level MOSFETs, um die Levelshifter weg zu sparen.

APC_Lisy.pdf

[bontango]

sieht bis auf die Jumper gut aus, hier die komplette Belegung der LSY_Mini

Ich vermute für die Jumper hast Du einfach freie GPIOs ab 'Pin 35' genommen?!

Nur zur Sicherheit würde ich die Gelb hinterlegten GPIOs nicht verwenden, die gehen zum 'PHAT' Anschluss,

den verwenden wir hier zwar nicht, aber wenn doch irgendwann (man könnte ja stacken) dann wären die Anschlüsse verfügbar.

Ich würde dann die GPIOs 5,6,12,13,16 und 20 für die Jumper vorschlagen.

 

[Black Knight]

vor 2 Stunden schrieb bontango:

Ich vermute für die Jumper hast Du einfach freie GPIOs ab 'Pin 35' genommen?!

Ja, ich will die Jumper am Ende des Pi Steckers haben, da wäre auf dem APC Board noch etwas Platz.

vor 2 Stunden schrieb bontango:

Ich würde dann die GPIOs 5,6,12,13,16 und 20 für die Jumper vorschlagen.

GPIO6 ist der Shutdown Schalter, den sollten wir also vermutlich auch überspringen. Was ist mit GPIO26?

[bontango]

Stimmt der GPIO6 ist für shutdown, dann also GPIOs 5,12,13,16,20 und 26

[Black Knight]

OK, ist geändert.

Zusätzlich habe ich auch mal einen Stecker vorgesehen, um den I2C Bus abzugreifen. Das hatte MK47 vorgeschlagen und könnte ganz praktisch sein, falls man noch zusätzlich etwas über I2C steuern möchte. So wie ich das verstanden habe ist der zweite I2C Anschluss des Pi ja nicht am Hauptstecker verfügbar, daher der Abzweig.

APC_Lisy.pdf

[bontango]

Am 10.5.2020 um 09:49 schrieb Black Knight:

Ich habe schon angefangen; in Version V0.14 ist schon I2C drin.

Wollte es gerade mal ausprobieren, 0.14 gibt mir Fehlermeldungen

APC:181:23: error: 'HandleTextSetting' was not declared in this scope

   {"DISPLAY TYPE    ",HandleTextSetting,&TxTDisplaySelect[0][0],0,6},

                       ^

APC:182:23: error: 'HandleTextSetting' was not declared in this scope

   {" ACTIVE GAME    ",HandleTextSetting,&TxTGameSelect[0][0],0,4},

                       ^

APC:183:23: error: 'HandleNumSetting' was not declared in this scope

   {" NO OF  BALLS   ",HandleNumSetting,0,1,5},

 

[Black Knight]

Bei mir läuft's einwandfrei. Arbeitest du unter Linux? Da passiert das nämlich viel seltener.

Das ist so'n Arduino Mist. Beim Eclipse kann man dann 'Clean Project' machen und dann klappt's wieder.

Ich nehme an, das liegt an dem blöden .ino Format und das es dabei keine Header-Datei gibt. Dadurch beschwert er sich manchmal über undefinierte Routinen, obwohl die weiter hinten im Programm ganz normal definiert sind.

Unter Linux kannst du auch einfach das tmp Verzeichnis löschen, in dem er kompiliert. Wenn er danach nochmal drauf schaut klappt's meistens. Unter Windows habe ich keine Ahnung, in welchem Verzeichnis der Kompiler seinen Kram ablegt.

Wenn alles nichts hilft, muss ich die entsprechenden Routinen am Anfang der Datei nochmal definieren. Das sollte bei .ino zwar eigentlich nicht nötig sein, aber wenn's sonst nicht klappt ...

[Black Knight]

Bevor du deine Zeit jetzt mit irgendwelchen Arduino IDE Bugs verschwendest habe ich die Funktionen jetzt einfach nochmal am Anfang definiert. Ich hoffe, das hilft.

[bontango]

Das hat geholfen, mit deiner neuen Version klappt es auch unter Windoof 👍

[Black Knight]

Super. Ich weiß jetzt hoffentlich auch, wie man den zweiten I2C Bus anspricht. Mir wäre es aber trotzdem lieber wenn wir es erst mal mit den anderen Pins ans laufen kriegen, dann haben wir nicht so viel neues Zeug auf einmal. Umschalten können wir dann immer noch.

[bontango]

Grundsätzlich sieht der Pi den Arduino über I2C schon mal 🙂

pi@lisy(ro):~$ i2cdetect -y 1
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- 44 -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --

Dann werde ich mich jetzt mal ans umschreiben meiner USB library machen.

Was hast Du denn schon alles drin? Erstmal 1:1 zum USB Protokoll oder auch schon die Umsetzung der DIPs?

Das mit dem zweiten I2C Bus habe ich noch nicht versstanden, wieso willst Du da wechseln?