Posts by FrankJepsen

    Und hier noch eine neuer Shutdown Hook mit Testmodus. Einfach ohne Parameter aufrufen. Dann wird die Uhrzeit und ein Timer in 2 Minuten gesetz. Dann VDR mit init 0 runterfahren und abwarten was passiert.


    Linvdr User können das Script mit leichten Anpassungen auch zum Testen verwenden.


    Tschüß Frank

    Donnerstag habe endlich mein neues Grafikdisplay (128x64) zum laufen gebracht. Nein, nicht an der Wakeup-Platine. Da sieht es mangels freier Ports erstmal schlecht aus. Dafür müssten wir warscheinlich auf einen ATMega16 mit mehr Ports umsteigen.


    Nun habe ich mich mal wieder an die Software gemacht. Und hier sind die ersten Früchte der Arbeit:


    Tschüß Frank

    Hallo,


    Quote

    Die Beschaltung der DSUB-F 9polig in der Steckerbelegung.pdf ist falsch.

    Es wurden Platinen mit beiden unterschiedlichen Steckerbelegungen gefertigt. Also einfach aufpassen beim Löten des seriellen Kabels.


    Quote

    eine Frage zu dem shutdown90.wakeup-modul.sh script aus "c’t Shutdown-Hook". Bei timern unter der MIN_PRE_TIMER (hier 5 Minuten) schreibt er ATS01000101 in den chip. So wacht der vdr aber nicht auf wenn noch andere timer gesetzt sind. Gehört das so?

    Wie kann der Timer kleiner 5 Minuten (300) sein? Ein Timer der jetzt startet hat den Wert 1083952223! Vielleicht hilft ein Auszug aus Deiner /var/log/messages weiter.


    Quote

    Ich habe leider noch ein power Problem. Wenn ich die Schaltung mit 5V standby von meinem PC-Netzteil (ATX Pin9) versorge funktioniert weder lirc noch wake_on_ir. Auch ist keine Komunikation mit dem chip möglich. Sobald die 5V (ca 40mA) vom Labornetzteil kommen geht alles. Woher kriege ich genug power? Liefern der PS/2- und WOL-Anschluss genug Strom oder kommt das auch vom 5V standby?

    Die 5V Standby Leitung sollte mehr als genug Strom liefern. Mit Ihr werden ja der WOL, PS/2 usw. versorgt. Ich nutze den WOL Stecker. Habe dazu ein altes CDROM-Audiokabel mit dem Messer ein bischen zurechtgeschnitzt damit es in die Buchse passt. Hast Du denn auch mal nachgemessen?


    Quote

    Jetzt meine Frage: braucht der Atmega noch zusätzlich Spannung oder wird er durch den Com-Port versorgt ?

    Klar braucht der Atmel Power. Lass Ihn doch einfach in der Schaltung. Hat bei mir prima geklappt.


    Tschüß Frank

    Hallo abvdr,


    ich habe zwar eine URC-7562 aber auch mit der URC-7030 sollte es keine Probleme geben. Leider kann ich Dir den Code den ich verwende gerade nicht sagen, aber probier einfach mal einen Philips-Code aus.


    Die URC-7562 kann ich übrigens nur empfehlen, denn man sie ist lernfähig und man kann sie sogar mit einem einfachen Kabel am Parallelport vom PC aus programmieren.


    Tschüß Frank

    Hallo,


    schön, das Nils sich bereitgefunden hat eine Seite für dieses Projekt zu pflegen.:applaus


    Quote

    - wozu wird der Pull-Up Widerstand benötigt, den starter unter die Platine gelötet hat????

    Der interne Pullup wird von der Version 1.3 nicht aktiviert.


    Übrigens in der poweroff.pl für die LinVDR-Nutzer wird noch nicht echo -n verwendet. Das sollte geändert werden.


    Tschüß Frank

    Hallo,


    ich bin auch für einen neuen Thread.
    Man sollte aber dort die wichtigsten Links, Bilder und Infos erst einmal zusammentragen. Oder hat schon jemand Seiten erstellt die aktueller als Rasputins Seiten sind? Dann könnte allgemeine Infos dort zusammengetragen werden und dem Forum bliebe die Diskussion vorbehalten.


    Freiwillige vor! :versteck



    Tournevis :
    Die Lösung mit dem Powerschalter finde ich auch universeller zumindestens, wenn man die Platine sowieso in das Gehäuse baut. Kannst Du Deine Beschaltung damit es ganz eindeutig wird auch mal als Schaltbild kundtun?


    Tschüß Frank

    Quote

    1.Es war nie vorgesehen etwas anderes als definierte Kommandos in einer definierten Zeit an das Modul zu senden.

    Ist vorerst auch nichts gegen zu sagen. Leider haben viele (auch ich) übersehen, das echo ein \n hinten dran hängt. Es ist also wichtig echo -n zu verwenden. Zur definierten Zeit läßt nur sagen, dass Interupts nun mal die unangenehme Eigenschaft haben zu jeder Zeit auftreten zu können. Also vor, während und nach der Verarbeitung.


    Quote

    2. Es findet nie ein Pufferüberlauf statt, egal was an das Modul gesendet wird.

    Ohne diesen Pufferüberlauf würde die Software, so wie sie ist, garnicht funktionieren. Denn dann würde ein zuviel gesendetes \n am Anfang des Puffers landen und alle nachfolgenden Befehle würden nicht mehr erkannt.
    Das Ganze läßt sich mit einem Terminalprogramm leicht reproduzieren. Wenn man die Befehle hier langsam tippt startet die Verarbeitung des Befehls nach dem 11. Zeichen und das Return(\n) landet am Anfang des Puffers. Dann geht erstmal nichts mehr.
    Da die Überprüfung des Pufferinhalts nur höchstens alle 100ms statt findet, kann man theoretisch 100 Bytes in den Puffer schreiben bevor das Programm was mitbekommt. Da mit echo alle Bytes hintereinanderweg in ca 10ms geschickt ist nur die Warscheinlichkeit relativ hoch das alle 12 Bytes komplett im Puffer landen bevor die Verarbeitung stattfindet. Trotzdem werden Fälle auftreten, wo das \n nach dem Verarbeiten der ersten 11 Bytes eintrifft, an den Anfang des Puffers geschrieben wird und den nachfolgenden Befehl verstümmelt. Oder das \n trifft während der Verarbeitung ein und stört sie, weil eine hinter dem Puffer liegende Variable überschrieben wird.


    Deshalb für Alle ganz wichtig immer genau als 11 Byte pro Befehl senden und zwischen den Befehlen mehr als 100ms warten. Dann gibt es nur noch bei echten Übertragungsstörungen (nicht übertragene Bytes) Probleme.


    Tschüß Frank

    steini  
    Es ist genauso wie beschrieben. Nach dem 11.Zeichen wird der Befehl ausgeführt und keine Überlaufprüfung.


    starter
    Für das Anlernen brauchst Du nur die Spannung anzulegen. Ich denke Du hast nur immer noch keinen RC5 Code gefunden. Ich habe einen Philips TV Code genommen.
    Man kann auch von Windows aus testen. Habe gerade mal Hyperterminal gestartet und ATS01020304 eingetippt. Sobald ich die vier getippt hatte sprang das Display um.


    Hier noch die geänderten Scripte für die c't Distribution:

    Tschüß Frank

    Files

    • ctvdr.zip

      (1.46 kB, downloaded 67 times, last: )

    Hallo,


    ich habe mir die Source noch mal angeschaut und hier C-ähnlich dargestellt, um die problematischen Stellen deutlich zu machen:

    Code
    1. void RXCompleteIntFunc()
    2. {
    3. int c=RXin;
    4. int pos=strlen(ReceiveBuf);
    5. ReceiveBuf[pos++]=c; // Keine Überlaufprüfung!!
    6. ReceiveBuf[pos]=0;
    7. }

    Wie gesagt, es findet leider keine Überlaufprüfung statt. Man kann sich also leicht andere Variablen, die hinter dem Puffer liegen überschreiben, während sie in der Hauptschleife verwendet werden, wenn man zu schnell oder zu viele Daten über den Comport schickt. Für die Verarbeitung wird weder ein Start- noch ein Stoppzeichen verwendet. Erst wenn mehr als 10 Zeichen empfangen wurden fängt sich das ganze wieder, weil dann der Puffer verarbeitet oder gelöscht wird. Im Augenblick ist die Software so geschrieben, dass jeder Befehl genau 11 Bytes umfassen muss. Deshalb sollte man echo -n beim Senden verwenden. Weil der Puffer nur 12 Zeichen groß ist kann es sonst entweder durch den Pufferüberlauf oder weil das überflüssige \n dem nächsten Befehl vorangestellt wird (die Verarbeitung kann ja schon nach dem 11. Byte starten) zu Problemen kommen. Auch wenn sich diese Überläufe nur selten auswirken, wäre es doch ärgerlich dadurch eine Aufnahme zu verpassen.


    rasputin Lösungsvorschlag:
    In der Interruptroutine bei Pufferüberlauf den Puffer löschen und bei Empfang von \n ein zusätzlich einzurichtendes Flag zu setzen. In der Hauptschleife dann nicht auf die Länge sondern diese Flag testen.


    Tschüß Frank

    Hallo,


    rasputin
    Schön, dass Du weiter mitmachst. Ich habe auch nichts dagegen, dass Du bei Deiner Software die Oberhand behälst und der Herausgeber der aktuellen Version bleibst. Ich werde mich bei Dir wegen meiner Änderungsvorschläge melden.


    Hier mal eine kleine Dokumentation der LEDs:
    [IMG:http://www.jepsennet.de/wakeup_board.jpg]


    LED1: (bei mir grün)

    • blinkt beim Start zweimal
    • ist im Betrieb aus, wenn kein Timer gesetzt ist
    • leuchtet im Betrieb, wenn Timer gesetzt ist
    • blinkt als Bestätigung nach dem Programmieren der RC5-Codes
    • beim Einschalten mit der Fernbedienung blinkt Sie zusammen mit dem RING-Signal.


    LED2:

    • leuchtet nur während Jumper auf Programmierung des RC5-Codes zum Einschalten gesetzt ist.


    LED3:

    • leuchtet nur während Jumper auf Programmierung des RC5-Codes zum Schalten des Relais gesetzt ist.


    LED4:

    • leuchtet nur während das Relais eingeschaltet ist.


    Mit dieser Info sollte es eigentlich möglich sein einen groben Funktionstest der Schaltung nur mit Hilfe der LEDs durchzuführen.
    Einschalten -> LED1 blinkt
    /etc/init.d/lirc stop
    setserial $WAKEUP_PORT uart 16550A
    echo ATS00000000 > /dev/ttyS0 -> Init
    echo ATS01020304 > /dev/ttyS0 -> LED1 geht an
    echo ATS00000000 > /dev/ttyS0 -> LED1 geht aus
    usw.
    Ich bin übrigens ganz systematisch vorgegangen und habe erst mal den Comport mit einem gekreuzten Kabel an einem anderen PC und Terminalprogramm getestet.


    Tschüß Frank

    Wenn ich die Source nicht ganz nicht ganz falsch interpretiere, wird bei jedem empfangenen Zeichen ein Interrupt ausgelöst. In der Interruptroutine wird das empfangene Zeichen ohne Rücksicht auf Verluste hinten an Empfangspuffer drangehängt. Erst in der Hauptschleife des Programms wird dann irgendwann geschaut, ob mehr als 10 Zeichen im Puffer stehen und ein eventuell drinstehendes Kommando ausgewertet. In der Hauptschleife war außerdem glaube ich eine Verzögerung von 100ms. Deshalb muß nach jedem Kommando immer erst gewartet werden, um Pufferüberläufe zu vermeiden. Leider habe ich die Source jetzt nicht hier. Aber gestern hatte ich auf die schnelle nichts gesehen was den Empfangspuffer wieder synchronisiert. Das würde ja bedeuten, dass die Schaltung bei jedem falsch übertragenen Zeichen resettet werden müsste. Wenn ich wieder zu Hause bin schaue ich noch mal rein, denn das wäre ja denn doch zu übel.


    rasputin :
    Ich möchte Dir auch nochmal meinen Dank aussprechen. Ohne Dein Bemühen und Deine Arbeit müsste ich meinen VDR-Rechner heute wohl immer noch von Hand einschalten. Schade, dass bei Dir der Eindruck entstanden ist, alle würden nur an Dir herum meckern.
    Der Sinn von Open Source ist ja nicht an der Arbeit anderer rumzumäkeln sondern gemeinsam daran zu arbeiten Software und Hardware zu verbessern, Fehler auszumerzen und neue Features hinzuzufügen.


    Tschüß Frank

    Hallo Ihr Alle,


    ich melde mich auch mal wieder. Meine Schaltung, die ich auf Grundlage der von Carlo geätzten Platine gebaut habe, hat glücklicherweise gleich funktioniert. Sehr hilfreich beim Testen war ebenfalls ein Display was ich aus einem alten Gerät ausgebaut habe. So siehts bei mir inzwischen aus:


    [IMG:http://www.jepsennet.de/wakeup_board.jpg]


    Netterweise hat mir Carlo nicht nur eine Platine geätzt sondern auch gleich einen programmierten Atmel zur Verfügung gestellt. Heute habe ich auch endlich meinen seriellen Programmieradapter fertiggestellt und mit PonyProg erfolgreich getestet.


    [IMG:http://www.jepsennet.de/wakeup_prog.jpg]


    Ich habe vorerst nur den Cursor abgeschaltet und die Anzeige für mein 16x2-Zeichen Display angepasst.


    [IMG:http://www.jepsennet.de/wakeup_all.jpg]


    Am Anfang hatte ich auch das RC5-Problem. Ich habe auch erst meine Fernbedienung OneForAll URC-7562 auch erst auf einen RC5-Code umprogrammieren müssen.


    Dann musste ich, da ich LIRC benutze den COM-Port erst freibekommen um die Wakeup-Schaltung zu programmieren. Hier mein ShutdownHook für die c't-Distribution:


    Die Parameterübergabe über die serielle Schnittstelle ist leider so gut wie garnicht abgesichert. Schickt man mehr als 11 Bytes bevor der Befehl abgearbeitet wurde, kann es sogar zu Überläufen im Datenbereich des Atmel kommen. Deshalb Vorsicht, es ist leider kein Endezeichen vorgesehen. Die Newlines \n dürften das Programm total aus dem Tritt bringen. Ich hoffe das hilft Euch erstmal ein bischen weiter.


    So nun muß ich aber langsam ins Bett.


    Tschüß Frank

    Hallo Ihr Bastler,


    da Rasputin sich anscheinend nicht rührt und seine Source nicht rausrücken will habe ich mal den guten IDA Disassembler bemüht und kann als erstes kleines Ergebnis eine Version ohne Cursor zur Verfügung stellen. An dem Pullup-Problem arbeite ich zur Zeit mit Carlo zusammen, da meine Platine noch nicht fertig ist.


    Tschüss Frank

    Files