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

    Der Bootloader wird nach 0x8000000 geflasht. So wie vorher die Firmware. 0x8000000 ist sozusagen die Startadresse, egal ob für die Firmware oder den Bootloader.
    Der Bootloader ist dann dafür zuständig die Firmware nach 0x8002000 zu flashen, und die Firmware muss dafür ausgelegt sein, statt von 0x8000000 dann von 0x8002000 zu laufen.
    Bei jedem Start wird dann erst der Bootloader gestartet, und der startet dann die Firmware.
    Zum Firmware flashen per Bootloader wird erst das Skript aufgerufen, und dann der ST-Link angesteckt.


    Ich habe mir mal https://github.com/UweBonnes/b…/stlink/dfu_upgrade.c#L33 angeguckt, und vielleicht geht es auch ohne Pulldown Widerstand, indem man direkt USBDP runter zieht. Das müsste dann nur anfangs beim Initialisieren in der Firmware gemacht werden.

    Zitat von olebowle

    Ich hab es mal als Version 0.1 getagged. Dabei habe ich auch gleich noch eine README hinzugefügt und irmp aktualisiert.
    EDIT: Ich hab den Tag gerade noch einmal angepasst. Ich weiß macht man eigentlich nicht, aber es waren ja nur ein paar Minuten.


    Kein Problem, komme sowieso erst heute Abend dazu. Danke für die rasante Reaktion! Aktuell läuft auch gerade ein Build mit dem ich versuche der Wetek Play WOL beizubringen ;).


    Gerald


    HP Proliant MicroServer Gen8, Xeon E3-1230, 12 GB RAM, 3xWD red 2TB im RAID 5, 2xSundtek MediaTV Home DVB-C/T, L4M TWIN-C/T, Ubuntu Server 14.04.1, Plex Media Server
    Samsung UE55H6470

    Sehr interessanter Fund! PA11 und PA12 sind also ganz normale GPIO-Anschlüsse. Das erklärt warum auch STM32-Chips, in denen im Datenblatt kein Wort von USB steht, so betrieben werden können. Ist wohl alles in Software umgesetzt.

    Ich bin nicht sicher, ob es wirklich ohne Pulldown geht. Ich habe ein paar Versuche gemacht, leider erfolglos, und habe jetzt keine Zeit mehr.
    Vielleicht schafft es ja ein Anderer.
    Widerstand einlöten geht schneller als Firmware Versuche ;) .


    Das Flashen mit dem Bootloader macht wirklich Spaß, es ist sehr viel bequemer als vorher!


    Der Rote mit Pulldown (mit SMD und Fädeldraht wäre es natürlich viel eleganter):

    Zitat von M-Reimer

    Das erklärt warum auch STM32-Chips, in denen im Datenblatt kein Wort von USB steht, so betrieben werden können. Ist wohl alles in Software umgesetzt.


    Nein, der Vorteil ist ja gerade, dass USB in Hardware läuft.
    Dass es drum herum Software gibt, würde man auf einem PC "Treiber" nennen.


    Dass der F101CB mehr kann, als im Datenblatt steht, ist eigentlich nicht ungewöhnlich.
    Z.B. steht im Datenblatt vom F103C8, dass er 64k Flash hat. Er hat aber tatsächlich 128k, ist also ein F103CB.
    Der F101CB kann offiziell nur 36 MHz, läuft aber mit 72 MHz als ST-Link und bei uns.
    USB 2.0 geht erst ab 48 MHz.


    Meine (spekulative, aber begründete) Schlussfolgerung:
    Genauso wie der F103C8 tatsächlich ein F103CB ist, ist der F101CB tatsächlich ein F103CB.
    Bei Google habe ich dazu zwar nichts gefunden, aber der chinesische Hersteller weiß wohl mehr.
    Bei CPUs z.B. gab es das auch schon.

    Wenn wir es gerade von Typbezeichnungen haben: Ich habe hier eine ST-Link V2 Platine bekommen auf der ein F101CBT6 verbaut ist. Ich habe gleich zwei davon bestellt. Eine bleibt wie sie ist als Programmer.


    Geht da die normale F103er Firmware?


    Ich wollte am Wochenende mal versuchen dort den Bootloader draufzubekommen.

    olebowle: irctl lies sich problemlos für die Wetek Play übersetzen. Wie es scheint läuft es auch, tut natürlich noch nicht viel ohne Hardware.


    Habe schon neue ideen für die Benutzung des STM32. Mit Hilfe eines ESP8266 sowas wie Wake on LAN, in diesem Fall über WLAN, nachrüsten ;).


    Gerald


    HP Proliant MicroServer Gen8, Xeon E3-1230, 12 GB RAM, 3xWD red 2TB im RAID 5, 2xSundtek MediaTV Home DVB-C/T, L4M TWIN-C/T, Ubuntu Server 14.04.1, Plex Media Server
    Samsung UE55H6470

    Zitat von M-Reimer

    Geht da die normale F103er Firmware?

    Ja.
    Auf den Projektseiten sind der rote und der blaue ST-Link sowie das Developer Board abgebildet, und in config.h können diese ausgewählt werden.
    Ich teste (falls ich Zeit habe) auf den drei Boards. Die Commits bis einschließlich 21.1. sind auf allen drei Boards erfolgreich getestet.

    Zitat von gda

    Mit Hilfe eines ESP8266

    Interessant!


    Das könnte aber daran scheitern, dass, zumindest auf den ST-Links, kein herausgeführtes TX/Rx Paar vorhanden ist.
    Außer du lötest an PA2+3.


    Mit dem Dev-Board natürlich kein Problem.

    Zitat von jrie

    Das könnte aber daran scheitern, dass, zumindest auf den ST-Links, kein herausgeführtes TX/Rx Paar vorhanden ist.
    Außer du lötest an PA2+3.


    Oder ich passe auch die Firmware auf dem ESP an und der zieht dann nur ein Beinchen hoch, aber erstmal warte ich mal auf ranseyers ST-Link.


    Gerald


    HP Proliant MicroServer Gen8, Xeon E3-1230, 12 GB RAM, 3xWD red 2TB im RAID 5, 2xSundtek MediaTV Home DVB-C/T, L4M TWIN-C/T, Ubuntu Server 14.04.1, Plex Media Server
    Samsung UE55H6470

    So ich habe mal zwei der blauen Programmer mit dem Bootloader (*pre2 aus diesem Thread) versehen. => Sollte erfolgreich sein...


    Wenn ich die Firmware (aktueller Stand; unter Linux mit "make") kompiliere endet das so:



    Der erste Versuch zu flashen über den Bootloader ging schon mal in die Hose. (Habe dann halt mal eine alte Firmware genommen. Ist ja erst mal egal ob diese auch funktioniert.)


    Aber Ubuntu 14.04 bietet dfu-util in Version 0.5. Also hab ich von hier die V0.8 kompiliert: http://dfu-util.sourceforge.net/releases/


    Leider kein Erfolg:

    "
    Falls der Bootloader über die USB-ID erkannt wird: Ich konnte auch kein Device mit dieser ID sehen (auch nicht mit hektischem lusb direkt nach dem einstecken...)


    Und jetzt muss ich erst mal "praktische Dinge" erledigen...

    Ahh der Programmer mit dem Widerstand erzeugt keine Meldungen in der syslog. Der zweite (noch ohne Widerstand) meldet sich korrekt. Das muss das Problem sein...


    So ist es richtig:

    Mist vermutlich ist einer der ST-Links defekt...


    Mit dem zweiten klappt das flashen (der unpassenden) Firmware...

    Frank bastelt gerade an IRMP, und wenn man sein svn runter lädt, bekommt man was halbfertiges bzw. halb kaputtes, auch wenn es schnell zu fixen ist (Typen anpassen). Nimm lieber seine zip Datei:
    http://www.mikrocontroller.net/wikifiles/7/79/Irmp.zip
    Wenn du die Windows prepare.bat ausführst, wird die automatisch gewählt, das Linux prepare.sh nimmt die zur Zeit kaputte irmp.tar.gz
    Ein neueres dfu-util wäre ratsam, 0.5 ist schätze ich zu alt.


    Wenn er als "Maple 003" erkannt wird, ist das richtig.


    So schnell wie man denkt, sind die ST-Links nicht kaputt zu kriegen. Versuch es einfach noch mal von vorne. ;)

    Zitat von jrie

    Frank bastelt gerade an IRMP, und wenn man sein svn runter lädt, bekommt man was halbfertiges bzw. halb kaputtes, auch wenn es schnell zu fixen ist (Typen anpassen). Nimm lieber seine zip Datei:
    http://www.mikrocontroller.net/wikifiles/7/79/Irmp.zip
    Wenn du die Windows prepare.bat ausführst, wird die automatisch gewählt, das Linux prepare.sh nimmt die zur Zeit kaputte irmp.tar.gz


    Wäre es nicht sinnvoll das auch unter Linux auf die ZIP-Datei zu verknüpfen? Wenn man einfach "ins Blaue" aus dem SVN runterlädt hat man ständig andere Versionen. Unter Umständen halt auch mal eine defekte. Ich kann dir gerne auch ein Pull-Request dazu schicken.

    Gibt es einen Grund warum du beim "Roten" den USB-Descriptor geändert hast und beim "Blauen" nicht?


    So wie ich das sehe hast du eine zweite LED in den Bootloader gepatcht. Gehe ich recht in der Annahme das die eine der LEDs dann die "werksseitig verbaute" ist und die zweite die optional extern anzuschließende "Toggle LED"?


    Ich versuche gerade das ganze auf eine Platine zu portieren, die bisher noch nicht dokumentiert ist. Deshalb die Frage.


    Ach ja: Pinnen auf eine bestimmte Version bei IRMP würde prinzipiell gehen. Würde da etwas dagegen sprechen?

    Falls du den USB-Descriptor vom Bootloader meinst, kann man so oder so machen, ich hatte mich da nicht entschieden, und es so gelassen, wie es gerade war. "Richtiger" wäre es die anderen auch nach zu ziehen.


    Deine Annahme bezüglich der LEDs ist richtig.


    Mit der IRMP Version kann ich mich nicht so recht entscheiden.
    1. Die zip Version ist sicher und man muss nicht ab und zu was anpassen. Sie ist aber manchmal alt.
    2. Eine festgepinnte svn Version ist auch sicher, muss aber ab und zu angepasst werden.
    3. Mit der aktuellen svn ist man immer auf dem neuestem Stand, aber es kommt vor, dass sie defekt ist.
    Wenn man dann aber Frank Bescheid gibt, fixt er das in der Regel umgehend (war gestern auch so).


    Ich bitte alle, mal ihre Meinung dazu zu äußern.


    Mir persönlich ist 3 am liebsten.
    Ich hatte nur noch keine Muße, das Windows Skript anzupassen, da es dort etwas aufwendiger ist und man noch einen Entpacker runter laden muss, der tar.gz kann.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden