Beiträge von sd582

    Hallo

    Eigentlich ist ein Treiber ja Software, aber dann gehts ja doch wieder um Hardware - ich hoffe also einigermaßen den richtigen Bereich getroffen zu haben ;)

    Also, ich hab da einen Schnittstellenkonverter USB auf 4 verschiedene Schnittstellen - im Grunde alles das Selbe - RS232, UART, SIO und RS485. Das ergibt unter Windows _eine_ COMx und unter Linux normalerweise ein /dev/ttyUSBx. Es handelt sich um einen Print meiner Firma. Er basiert auf einem FTDI Chip und sollte daher am PI über den standard FTDI-Treiber funktionieren.

    Jetzt habe ich gelesen, dass ein FTDI-Treiber bereits im Kernel vorhanden sein soll.
    Dazu meine erste Frage: kann ich irgendwie checken, ob dem so ist? Kann ich das irgendwie abfragen?

    Ich hatte da ein ähnliches Thema mit einem Device auf cp210x Basis.
    Von da habe ich noch eine Anleitung von der ich annehme, dass sie auch mit dem FTDI-Treiber funktionieren sollte.
    Da hieß es:
    Den Treiber laden mit "modprobe cp210x" und dann das eigene Device anmelden mit "echo [VID] [PID] > /sys/bus/usb-serial/drivers/cp210x/new_id"
    Dann sollte das Device als /dev/ttyUSBx erscheinen.

    Ich hätte da einmal blauäugig "modprobe FTDI" probiert - sagt mir der PI, den Witz hat er jetzt nicht verstanden ;)
    Frage dazu: wie würde den der FTDI-Treiber korrekt heißen, wenn er den auf diese Art verfügbar wäre?

    Und zum Abschluss die Frage: bin ich da mal grundsätzlich auf dem richtigen Weg?

    Gruß
    Franz

    Hallo

    Bei meinem ist nur 1 Chip auf der Rückseite. So wie bei diesem hier (wurde auf der Seite unten angezeigt)
    http://www.ebay.de/itm/1Stk-4-Bit…ce&talgo=origal

    Ob das jetzt vergleichbar ist, kann ich nicht sagen.

    Meines sieht jedenfalls nur nach i2c aus - habe auch zuerst mit i2c probiert.
    Aber funktionieren tut's nur mit der Eigenimplementierung.
    Es handelt sich offenbar nur hardwaremäßig um einen i2c ähnlichen Anschluss aber das Protokoll weicht offensichtlich vom i2c Standard ab.

    Angeschlossen habe ich es mit CLK auf 23 und DIO auf 24. Plus und GND sind eh klar.
    Darauf sind die Programme abgestimmt.

    Gruß
    Franz

    >> Die IP vom Laptop kann ich nicht anpingen

    Das hört sich nach einem Problem mit der Firewall an. Das hatte ich vor Kurzem aus einer VM heraus.
    Zum Test kurz die Firewall abgedreht und schon ging es.
    Dann eine entsprechende InboundRule eingetragen und die Sache war gegessen.

    Also auch mal in diese Richtung prüfen.

    Gute Nacht :)

    Was mir auffällt, aber vielleicht nicht relevant ist - ich würde am LAN-Adapter des Laptops kein Gateway eintragen und auch keinen DNS.

    ping am pi auf seine eigene ip sollte ja funktionieren - ok?
    ping am pi auf die ip des Laptops 192.168.13.20 funktioniert auch?

    Welche IP hat der WLAN-Adapter am Laptop?
    Das sollte keine Adresse aus dem Bereich 192.168.13.x sein!
    Die beiden Adapter sollten auf jeden Fall in unterschiedlichen Subnetzen sein.

    Dann wäre das nächste - ein ping am pi auf die ip des WLAN-Adapters.
    So kann man sich schrittweise durchs Netz pingen und damit rausfinden, ab wo es Probleme macht.

    Am Laptop muss als Gateway dein Internet-Router eingetragen sein. Das wird wahrscheinlich automatisch per DHCP passieren. Oder du hast das schon richtig eingestellt. Sonst würdest du mit dem Lapi nicht ins Internet kommen.

    Am pi musst du die IP-Adresse des LAN-Adapters als Gateway einstellen.
    Der Pi hängt ja im selben Netzwerk (Subnet) und kennt daher diese IP Adresse.
    Mit der Gateway Einstellung sagst du dem pi, dass er alles was an ihn unbekannte Adressen gesendet werden soll, an diese Adresse senden muss.
    Der Laptop weiß dann durch das ICS und sein eigenes Gateway, wohin er es weiterleiten muss.

    Klar soweit?

    Gruß
    Franz

    Achtung, Windows ist da etwas gemein :)

    Wahrscheinlich hast du sogar eine Meldung bekommen, dass die IP-Adresse des LAN-Adapters auf irgendeine Krumme IP geändert wird.
    Keine Ahnung warum Windows das macht. Aber als nächsten Schritt gehst du her und korrigierst die IP-Adresse deines LAN-Adapters.
    Dann müsste die Verbindung zum Pi wieder funktionieren.

    Und dann musst du dem Pi noch diese IP-Adresse als Gateway eintragen. Dann kommst du auch vom Pi aus über den Schleppi ins restliche Netz.

    Ach ja, und der Netzwerkbereich von WLAN und LAN sollte nicht der gleiche sein!

    Vielleicht auf der einen Seite 10.0.0.x und auf der anderen Seite 192.168.0.x - kannst mir folgen?

    Gruß
    Franz

    PS. der Pi muss wissen, dass er über den Laptop ins Netz kommt -> Gateway!

    Hi

    Einen ähnlichen Kommentar habe ich auch bei Conrad hinterlassen.
    Ich finde das Zeugs vor allem wegen der total fehlenden Doku (die paar PDFs, die man bei Conrad runterladen kann sind wirklich nicht sehr hilfreich) ziemlich überteuert.
    Das größte Problem war das Display.
    Hier in Forum findet ihr eine C++ und eine python Implementierung, die ich nach langem Forschen machen konnte.

    Gruß
    Franz

    PS. ich sehe, du hast anstatt des Relaise einen Beeper dabei.
    Bei meinem Kit war noch ein Schiebepoti und ein Drehpoti dabei und eben das Relaise anstatt des Beepers.

    Hi

    Ich denke, da musst du dir auf dem Raspi einen Server programmieren, mit dem dein C# Programm dann kommuniziert und der für dein C# Programm die GPIO Zugriffe übernimmt.

    Möglicherweise ließe sich etwas mit pigpio machen. Der deamon (pigpiod) wäre grundsätzlich ja remote ansprechbar. Ob das irgendwie mit C# und von Windows aus geht, das weiß ich aber nicht.

    Ich würde mir da meinen eigenen Server inklusive Protokoll schreiben - ist aber ein Haufen Arbeit.

    Gruß
    Franz

    Er will's einfach nicht glauben, dass ich einfach ein Bit zu wenig geschickt habe.

    Liest du nicht was man schreibt? Oder ist es dir egal was man schreibt und du musst unbedingt auf einer völlig unnötigen Schleife rumhacken, die man nach aktuellem Wissensstand auch einfach weglassen kann?

    Ich wollte mit der Anmerkung meiner Softwareentwicklerlaufbahn lediglich darauf hinweisen, daß ich nicht auf der Brennsuppe dahergeschwommen bin - dass ich schon weiß, wovon ich spreche.

    >>> Nur weil etwas in C schnell bearbeitet wird bedeutet das nicht zwangsläufig das der selbe Weg 1:1 auch genau so schnell in Java (oder python) bearbeitet wird.


    Genau deshalb hab ich ja gefragt, ob python dafür vielleicht zu langsam sein könnte.

    Schluss jetzt!
    Die Sache ist seit gestern schon erledigt und klar.
    Da muss man nicht auf einer unwichtigen Schleife rumreiten!

    Da ich vor Kurzem ja auch mit dem Thema gekämpft habe - versuchen wir es nochmal :)

    Was sagt ls -l /dev/i2*

    [font="Courier"]pi@raspy2 ~/Develop/tm1637 $ ls -l /dev/i2*
    crw-rw---T 1 root i2c 89, 1 Feb 26 20:17 /dev/i2c-1
    [/font]

    Zeigt sich hier ein /dev/i2c...irgendwas?

    Wenn ja, dann muss ich passen.

    Wenn nein, dann prüfen wir noch mal ob der Devicetree abgeschaltet ist:

    > cat /boot/config.txt

    Bei mir sieht das Ende der Datei so aus:

    [font="Courier"]#dtparam=spi=on
    #dtparam=i2c_arm=on
    device_tree=
    [/font]
    Die beiden auskommentierten Einträge kommen von den Versuchen mit dem Devicetree.

    /etc/modprobe.d/raspi-blacklist.conf
    Hier muss blacklist i2c-bcm2708 auskommentiert oder rausgelöscht sein.

    In /etc/modules sollte dann i2c-dev eingetragen sein. Damit wird das modul automatisch gestartet
    Ich hatte versuchsweise auch i2c-bcm2708 eingetragen. Das brauchts aber nicht!

    Wenn das alles passt - reboot
    Dann kannst du noch mit lsmod schauen. Da muss dann i2c_bcm2708 und i2c_dev zu finden sein. Und wenn dann /dev/i2c-1 auch noch zu finden ist, dann müsstest du eigentlich gewonnen haben :)

    Gruß
    Franz

    PS.

    >> Ich glaube ich habe das Image vom 31.1.15 drauf, wie kann man das denn herausfinden welche Version installiert ist?

    sag mal uname -a

    [font="Courier"]Linux raspy2 3.18.5+ #744 PREEMPT Fri Jan 30 18:19:07 GMT 2015 armv6l GNU/Linux[/font]

    Das wäre z.B. mein aktuelles

    Mannohmann!

    Die schleife zählt nicht nur einfach hoch!
    Die Schleife zählt nur so lange hoch, solange der Eingang nicht auf Low ist!
    Und wenn alles passt, dann ist der Eingang auf Low - und zwar noch vor dem Eintritt in die Schleife.

    Muss ich da wirklich den Code eines mir fremden Chinesen verteidigen?

    Ich hab den Mist nur nach python übertragen (von C) und wollte dabei möglichst wenig ändern, weil ich noch nicht kapiert hatte, was das da eigentlich genau macht.

    Inzwischen ist mir sonnenklar was das Zeugs macht und das ist schon ok so als Notbremse (Panikfunktion)

    Darfst mir ruhig glauben. Ich bin seit 30 Jahren Softwareentwickler im Embeded Bereich und arbeite mit verschiedensten Sprachen von Assembler über ein paar exoten, über Java, C/C++ bis C#.

    Mein Problem war schlicht und einfach dass ich ein Bit zu wenig gesandt hatte.
    >>> for i in range(0,7): <<<<-- zählt nicht von 0 bis 7 sondern nur von 0 bis 6

    PS. das dort ist nicht der C Code.
    Das ist bereits ein stark überarbeteter C++ Code und ein Post darunter der optimierte pyton code.

    PPS.

    Das hier ist der original C Code:
    http://www.sc2web.net/Downloads/TM1637OriginalC.ZIP

    PPPS. ich habe den originalcode deshalb nicht gezeigt, weil er für meine Frage völlig unerheblich war!

    Die Frage war, ob es daran liegen kann, dass python vielleicht dafür zu langsam ist!

    Und natürlich habe ich in python etwas anders gemacht, weil for( int i=0;i<8;i++) funktioniert in python nun mal nicht.

    Sorry, dass ich mich erdreistet habe, zu fragen, ob python vielleicht langsam sein könnte :(

    Und nochmal:

    ... und des Rätsels Lösung:

    for i in range(0,7): <<<<-- zählt nicht von 0 bis 7 sondern nur von 0 bis 6

    Dem Display fehlte daher noch ein Bit und deshalb gabs auch kein ACK.

    Die while schleife kommt garnicht zum hochzählen, weil typischerweise die Leitung bereits low ist.
    Wie gesagt, die Funktionalität der Schleife ist offenbar eine reine Vorsichtsmaßnahme, für den Fall, dass sich das ACK doch einmal verzögern sollte.

    Und in diesem Fall ist es absolut gewünscht, dass das Script nichts anderes macht, bevor die Schleife beendet werden kann!

    Gruß
    Franz

    PS. ich habe mir das mit der Schleife nochmal genauer angesehen.
    Das ist eine reine Panik-Funktion!
    Der Zähler bleibt eigentlich _immer_ auf 0 - sprich, die Leitung ist beim ersten read bereits LOW.

    Also keine Veranlassung, da etwas mit Interrupt machen zu müssen.

    Gruß
    Franz

    Hi

    Die Vorgehensweise, also der genaue Programmmablauf entstammt direkt einem Beispielprogramm in C, welches ich auf der Herstellerseite gefunden hatte.

    In C++ funktioniert das auch gut so.
    Ich denke (habs nicht nachgeprüft) dass dort auch der Zähler kaum mal über 5 hochzählen wird.

    Und ich wollte das natürlich mal so nahe an einem funktionierenden Beispiel wie möglich ausprobieren, bevor ich mir Verbesserungen überlege, die dann vielleicht erst recht wieder nicht funktionieren.

    Das Thema ist jetzt also weniger ob es eine CPU-Zeit schonendere Methode gäbe. Ausser das Display könnte damit zur Zusammenarbeit bewegt werden.

    Ich vermute viel mehr, dass die Signalwechsel _vor_ der Schleife zu langsam sind, so dass das Display das nicht akzeptiert und daher die Leitung nicht runterzieht.
    Wenn das Ding die Leitung nicht runterzieht, wird wohl auch kein Interrupt helfen. Weil der kommt dann ja auch nicht.

    Gegenstand der Frage ist also nicht die CPU-Zeit fressende Schleife, sondern die Verarbeitungsgeschwindigkeit der paar Zeilen vor der Schleife.

    Gruß
    Franz

    ... und des Rätsels Lösung:

    for i in range(0,7): <<<<-- zählt nicht von 0 bis 7 sondern nur von 0 bis 6

    Dem Display fehlte daher noch ein Bit und deshalb gabs auch kein ACK.

    Hallo

    Könnte es sein, dass python dafür einfach zu langsam ist, oder muss doch noch irgendwo ein Fehler vergraben sein?

    Es geht um die Ansteuerung des 7-Segment Displays tm1637.
    Ich habe dafür ja eine C++ Implementierung geschrieben. Siehe LED 4 Segment I2C Display

    Und jetzt kämpfe ich mit einer davon abgeleiteten python implementierung, die aber leider zu keinem Ergebnis führt.
    Da es hier offenbar um doch sehr schnelle Signalwechsel auf den beiden GPIO-Pins geht, befürchte ich, dass das nicht Funktionieren eben daran liegt, dass python einfach zu langsam dafür ist.

    Könnte ich da richtig liegen?

    Das wäre z.B. die Funktion, die _ein_Byte_ zum Display schiebt.
    Da bleibt das Ding dann in der while-Schleife hängen, weil offenbar das ACK nicht kommt.

    Gruß
    Franz