IRMP auf STM32 - ein USB IR Empfänger/Sender/Einschalter mit Wakeup-Timer

  • Eine Bestätigung und Ergänzung von Martins Messung, am blauen ST-Link Emu ist
    SWIM – 22 - 45
    NRST – 42
    CLK – 37
    DIO – 34
    TCK – 15 – 26
    TMS – 27
    Also im Vergleich zum roten ST-Link Emu sind CLK und TCK sowie DIO und TMS vertauscht.
    Wenn man nun mit dem Blauen programmieren will, muß man das CLK Kabel an TCK und das DIO Kabel an TMS befestigen.
    Es ist kaum zu glauben, das der chinesische Hersteller das vertauscht hat! Wenn man standardmäßig ein Kabel auf die Pins aufsteckt, kann man nicht programmieren!
    Das BOOT0 und BOOT1 vertauscht waren, fand ich schon schlampig, aber dies schlägt dem Faß den Boden aus.


    Jetzt muß ich mir erst mal überlegen, ob ich die Pins für den Fernbedienungsempfänger remappe oder lieber in TCK und TMS Stifte einlöte und diese nutze.
    Ich weiß nicht, was für Nebenwirkungen das Remappen für ein späteres Firmware Update hat, wenn die Programmiereingänge anders belegt sind.
    Da ich im Moment keine Lust auf Experimente mit fragwürdigem Ausgang hab (wenn es nicht klappt, hätte ich einen ST-Link zu wenig), neige ich dazu TCK und TMS zu nutzen.
    Besser wäre es, den Blauen zu meiden, und nur die Roten zu benutzen.
    Aber Martin hat schon einige Blaue.
    Was nun?
    Im Moment entscheide ich mich beim Blauen für
    SWIM - PB11 - PB8 – IR empfangen
    TCK - PB13 - PA5 - ToggleLED
    TMS - PB14 – Einschalter
    NRST - PB6 – IR senden
    Falls jemand eine bessere Idee hat, bitte mitteilen.

  • Hi,
    das sieht sehr interessant aus, vielen Dank für das Projekt! Da würde ich auch gerne mitspielen. :)


    Gibt es abgesehen von der Größe einen Grund die ST-LINK Dinger zu nehmen?
    Preislich nehmen sie sich ja nicht wirklich was zum größeren STM32F103C8T6 Board, was abgesehen vom 32kHz XTAL zudem ja noch wesenlich mehr I/O-Pins hat.

  • Nachdem ich eine Firmware, die PA13 (DIO) und PA14 (CLK) benutzt, geflasht habe, wird der blauen ST-Link nicht mehr zum neu flashen erkannt. Daher wird die Empfehlung sein, TCK und TMS zu benutzen (statt CLK und DIO). Um ihn wieder flashen zu können, braucht man die Möglichkeit, ihn zu Beginn des Flashens zu resetten. Dazu muss man ein Massekabel kurz an die rot markierte Stelle halten.
    Am besten flasht es sich unter Linux mit st-flash von texane.
    Vorher ist es nötig erst unter Windows mit dem ST-Link Utility unter "Option Bytes" die Read Out Protection auf Disabled zu stellen.
    Insgesamt ein bisschen stressig.


    An den Ein/Ausgängen der ST-Links sind ja auch noch PullUps/Downs. Mir fällt jetzt erst ein, dass die ja auch stören könnten. Muss ich mal untersuchen.

  • Am Roten ist der PullUp am TSOP IR Eingang so klein, dass der TSOP nicht mehr richtig runter ziehen kann. Auch am Blauen war, soweit ich mich erinnere, manches "hakeliger" als am Entwickler Board. Es wäre also nötig, die entsprechenden Widerstände zu entfernen.
    Bisher war das Flashen reversibel, man findet in einem russischem Forum die nötige Firmware. Bei den beiden ST-Links, die ich jetzt habe, will ich die Widerstände aber nicht entfernen, die brauche ich noch.
    Dafür, dass man dann einen schön kleinen IR Empfänger hat, ist es doch etwas aufwändig und ich frage mich so langsam, ob sich der Aufwand lohnt, oder ob es unter diesen Umständen nicht doch besser ist, die etwas größeren Entwicklungsboards zu nehmen.
    Trotzdem werde ich das mal machen, wenn ich die nötige Hardware habe.
    Bis dahin konzentriere ich mich auf andere Baustellen.
    Anbei ein Schaltplan vom ST-Link. Die Hersteller verbauen anscheinend teils stark abweichende Werte.

    Dateien

  • Ich habe es jetzt noch mal am EntwicklerBoard getestet, und auch da ist es hakelig. Genauer gesagt, gibt es zwischendurch immer wieder IR Empfangspausen. Also in gewissen Zeitintervallen geht es, und in anderen nicht. Anders gesagt, nach ein paar empfangenen Tastendrücken ist es eine Zeit lang blockiert. Die USB Kommunikation ist davon nicht betroffen, die geht permanent. Das Blaue ist insofern "rehabilitiert".

  • Makefile und Linker-Skript fürs Kompilieren mit arm-none-eabi-gcc unter Linux.
    Danke an olebowle für das Makefile!


    Die kommen ins Verzeichnis, in dem main.c liegt, dann dort ein "make" und es wird kompiliert.

    Dateien

    Dieser Beitrag wurde bereits 1 Mal editiert, zuletzt von jrie ()

  • Hast du einen github-Account? Wäre eigentlich der optimale Ort um alles zusammenzufassen und auch die zukünftigen Entwicklungsschritte verfolgen zu können.


    Was ich nicht so ganz verstanden habe: Wie kommen denn nun die IR-Codes beim VDR an? Braucht man einen LIRC-Patch?


    Wie wird der Button für das "Wakeup" angelernt?

  • github einrichten steht auf meiner Todo Liste.
    irmplircd als lirc Server gibt die HID events weiter an die Anwendung. Man kann aber auch selbst was stricken.
    stm32F103IRconfig richtet den Wakeup Code und Anderes ein, letzte Version hier:
    https://www.mikrocontroller.net/topic/347290
    Da sieht man auch eine andere Art, die IR Codes zu verarbeiten, indem /dev/hidraw gelesen und beschrieben wird.

    Dieser Beitrag wurde bereits 1 Mal editiert, zuletzt von jrie ()

  • Das mit dem WakeUp-Code anlernen (und abfragen) ist echt frustrierend. Jedes Projekt kocht da sein eigenes Süppchen:

    Eigentlich fänd ich es ganz geil, wenn man sich auf ein Protokoll oder zumindest ein Programm einigen könnte, was das vereinheitlichen oder zumindest abstrahieren würde. Sowas gibt es meines Wissens aber noch nicht? Auch kernelmäßig gibts dafür glaube ich keine Infrastruktur.

  • Nein, dafür gibt es noch nichts. Würde ich jetzt aber "kernelseitig" auch nicht erwarten.


    Wobei der pragmatischere und einfachere Weg wäre, wenn man den PC dafür garnicht bräuchte. Zumindest Atric und Yausbir haben die Möglichkeit mit einem Taster als Eingabe und einer LED als Ausgabe den Einschaltcode anzulernen ohne dafür eine Tastatur an den VDR anschließen zu müssen oder mit Laptop und SSH zu hantieren. Keine Ahnung wie viel Mehraufwand das wäre sowas optional mit in die Firmware zu nehmen damit diejenigen, die mit Taster anlernen wollen, einen solchen an einen freien Eingang hängen können.

  • Der USB IR Remote Receiver (der Vater vom usbasp) merkt sich einfach den ersten empfangenen IR Code, dafür braucht man weder Taster noch LED. Der Code dafür ist einfach. Wäre das was?

  • Pragmatisch vermutlich, bei komfortabel und intuitiv wär ich mir nicht so sicher. Ich will den Empfänger dann in meine Gehäuse verbannen und den dann rauskramen zu müssen finde ich nicht sonderlich toll. Außerdem: Wenn ich mit einem Gerät über blinkende LEDs kommunizieren muss fühle ich mich irgendwie an den Anfang der 90er beim Konfigurieren unseres ersten Sat-Reveivers ohne On-Screen-Menü versetzt. Scheinbar hatten wir dabei die Kindersicherungs akiviert, weil wir es nicht geschnallt haben - aber das ist eine andere Geschichte. Aber optional geht sowas sicherlich. Das wird nur problematisch bei den ST-Links, die nur wenig freie Pins haben.
    Anlernen durch ersten empfangenen Code geht halt nur einmal, dann heißt es vermutlich neu Flashen?


    Ich hab mir mal Gedanken gemacht wie man die verschiedenen Programme hoffentlich vereinheitlichen/abstrahieren könnte: https://github.com/olebowle/irctl. Ich habe darüber auch schon mit jrie gesprochen. Was haltet ihr davon?

  • Wenn man den ersten empfangenen angelernten Code dann verändern will, müsste man das Konfigurationsprogramm benutzen.
    Mir persönlich reicht das Konfigurationsprogramm, die Frage ist halt, was für den unbedarften Normal-Nutzer das freundlichste wäre.

  • Nichts gegen die Idee mit dem "ersten empfangenen Code". Für diejenigen, die sich nicht extra etwas auf den Rechner basteln wollen um später einmal einen neuen Code anzulernen (macht man ja eher selten. Man tauscht ja nicht täglich die Fernbedienung) wäre dennoch nicht verkehrt eine Art optionale "Reset-Taste" zu haben mit der der Chip wieder in den Zustand "erster empfangener Code wird gelernt" versetzt werden kann.


    Da mag jeder andere Vorlieben haben, aber ich finde einen Taster schon komfortabler als mich nach X Jahren nochmal daran zu erinnern wie ich nun die neue Taste angelernt bekomme.

  • Ein Wakeup-Reset Taster, der "pack den nächsten empfangenen IR Code ins Wakeup Eeprom" auslöst, sollte einfach umzusetzen sein und erscheint mir einfach und praktisch.
    Wenn keiner eine bessere Idee hat, kommt das auf die Todo Liste für später mal, wenn die wichtigeren Sachen fertig sind.

  • Gut wenn es nur um ein Tastendruck gleich Code löschen geht, klingt das für mich auch ganz sinnvoll. Aber Menüs und Untermenüs in denen man sich befindet mit Blinkcodes per LED auszugeben und darüber zu navigieren finde ich wenig sinnvoll.

  • Hab's eingebaut. Funktioniert aber noch nicht ganz richtig.
    Sieht jemand den Fehler?


    Solange bis ich github habe, ist der Download im mikrocontroller.net Diskussions-Thread.


    Der schönere Stil der main.c ist olebowles Anregungen zu verdanken.

    Dieser Beitrag wurde bereits 1 Mal editiert, zuletzt von jrie ()