Jump to content

bontango

Liganisator
  • Content Count

    1,080
  • Joined

  • Last visited

About bontango

  • Rank
    100% Gottlieb
  • Birthday 09/05/1963

Previous Fields

  • Ligalogo
    Liga Koeln-Bonn

Contact Methods

  • Website URL
    https://www.lisy.dev

Profile Information

  • Gender
    Male

Recent Profile Visitors

1,225 profile views
  1. Ja denke auch, lass uns das mal auf beiden Seiten implementieren und schauen was passiert
  2. Ja, l├Ąuft ­čÖé Es ist halt wie immer: kaum macht mans richtig funktioniert es. Zum Protokoll: wie w├Ąre es wenn Du als Slave immer als erstes Byte einen Status zur├╝ck gibst? M├Âgliche Werte: 0 : nicht bereit/besch├Ąftigt -> Master wiederholt Befehl nach Wartezeit ( wie lange soll ich warten, 1ms ? ) Anzahl empfangener Bytes -> Befehl angenommen und ausgef├╝hrt ( Minimum 1 ) -1: Befehl angenommen aber Interpretationsprobleme : Error
  3. Ist das die aktuelle 14er Github Version? Dann w├╝rde ich die nochmal runterladen um meinen Startscript zu testen.
  4. Ich denke das Umschreiben ist keine grosse Sache. Beim derzeitigen Protokoll gef├Ąllt mir eh nicht dass keine Best├Ątigung erwartet wird. Das f├╝hrt immer dann zu Problemen wenn die Kommunikation 'aus dem sync' geht dann hat mein keine M├Âglichkeit mehr in den sync zu kommen und unvorhersehbare Dinge k├Ânnen passieren. Ich w├╝rde daher eher immer eine Antwort schicken lassen auf die der Master dann wartet. In der ersten Version als 'blocking' d.h. der Master wartet (recht lange) auf die richtige Antwort und macht nichts parallel. Das w├Ąre wesentlich f├╝r mich wesentlich einfacher
  5. Leider ganz schlechtmit der neuen Version, er sendet einen Haufen Nullbytes (h├Ârt gar nicht mehr auf) und im Seriell Monitor kommt gar nichts mehr 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)""
  6. 4 Abfragen Dip-Switch 2 wie unten, Ausgabe Monitor: 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 (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_str
  7. 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 ..
  8. Ä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"
  9. 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
  10. 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
  11. 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 ...
  12. 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]
  13. 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?
  14. 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.
×
×
  • Create New...

Important Information

Privacy Policy and Community Guidelines