Montag, 16. Oktober 2017

MAX! Cube Umbau zu 4-fach Netzwerk CUL (CUN)

Es erfreut das Bastlerherz, was findige Tüftler so alles mit der Welt teilen. So auch die Portierung der CUL Firmware auf die Hardware des MAX! Cube. Damit wird der Cube ein starker Konkurrent gegen den einstmals günstigen USB-CUL von busware.de.

Doch damit nicht genug, der Benutzer Telekatz aus dem FHEM Forum hat in der Portierung gleich ein Multiplexing für bis zu drei zusätzliche Tranceiver vorgesehen.
MAX! Cube


MAX! Cube Unterseite
MAX! Cube Unterseite
Platine Oberseite mit angelötetem 433MHz Tranceiver
Platine Oberseite mit angelötetem 433MHz Tranceiver
Platine Unterseite
Platine Unterseite
Ich hatte zum Testen einen dritten CC1101 mit 868MHz angebaut, fand dafür aber keinen sinnvollen Verwendungszweck, da ich ausschließlich MAX! und Intertechno-kompatible Geräte verwende.
Wollte man tatsächlich drei zusätzliche CC1101 anschließen, so werden noch weitere Pins benötigt, welche man wegen fehlender Herausführung direkt am Prozessor abgreifen müsste (100pin LQFP Package!!!).
Allerdings werden die aufgrund von Hardwareeinschränkunngen (zwei freie Timer) sowieso nur zwei SlowRF Geräte unterstützt. Da der GDO0 des CC1101 auch nur für diese Betriebsart den Datenempfang signalisiert, könnte man auf die Prozessor Pins verzichten und  unbeschaltet lassen.

Meine board.h sieht daher so aus (2 SlowRF Geräte an CC0 und CC1 möglich):

//External Transceivers
//PORT 1
#define CC1100_1_CS_PIN           6
#define CC1100_1_CS_BASE          AT91C_BASE_PIOA
#define CC1100_1_OUT_PIN    25
#define CC1100_1_OUT_BASE   AT91C_BASE_PIOB
#define CC1100_1_IN_PIN     5
#define CC1100_1_IN_BASE          AT91C_BASE_PIOA

//PORT 2
#define CC1100_2_CS_PIN           10
#define CC1100_2_CS_BASE          AT91C_BASE_PIOA
#define CC1100_2_OUT_PIN    24
#define CC1100_2_OUT_BASE   AT91C_BASE_PIOB
#define CC1100_2_IN_PIN     11
#define CC1100_2_IN_BASE          AT91C_BASE_PIOA

//PORT 3
#define CC1100_3_CS_PIN           22
#define CC1100_3_CS_BASE          AT91C_BASE_PIOB
#define CC1100_3_OUT_PIN    20
#define CC1100_3_OUT_BASE   AT91C_BASE_PIOB
#define CC1100_3_IN_PIN     28
#define CC1100_3_IN_BASE          AT91C_BASE_PIOB


Auf Debian Stretch lässt sich der aktuelle Stand (1.26.05) direkt kompilieren (mit Jessie hatte ich keinen Erfolg!).
apt-get install bossa-cli minicom gcc-arm-none-eabi

Das Repository findet sich auf Github
git clone https://github.com/heliflieger/a-culfw.git


Anschließend wechselt man in das Verzeichnis
cd a-culfw/culfw/Devices/CUBe/

und erstellt eine Makefile.local
ARMBASE = /usr/lib/arm-none-eabi

INCLUDEPATH = $(ARMBASE)/include
LIBPATH = $(ARMBASE)/lib
TOOLPREFIX = arm-none-eabi-

Selbiges wird in das bootloader/ Verzeichnis kopiert.
Nun kann die Boarddefinition in board.h noch an die eigenen Bedürfnisse angepasst werden. Ich habe die CC1101 Out(GDO0) Pins der zwei Zusatzmodule auf PB25/PB24 gelegt und die Chip Selects und Inputs(GDO2) jeweils paarweise auf PA6/10 und PA5/11.
Nun kann die Firmware kompiliert werden:
make CUBEx4_BL # 4-fach Cube
make CUBE_BL   # 1-fach Cube ohne zusätzliche Tranceiver

und im bootloader/ Verzeichnis (die fertige Datei landet im CUBe/ Verzeichnis)
make bootloader_CUBE.bin

Um den Bootloader zu schreiben, muss der Originalbootloader gelöscht werden (Achtung: das originale MAX! System ist damit unwiederbringbar verloren!). Dazu verbindet man einfach die Kontakte JP1 z.B. mit einem Büroklammer und schaltet den Cube kurz ein. Beim erneuten Starten erwartet das System automatisch einen Bootloader:
~/a-culfw/culfw/Devices/CUBe$ bossash
Press Ctrl-D or enter "exit" to end session.
Enter "help" to display a command list.
bossa> scan
bossa> write bootloader_CUBE.bin
bossa> bootf true
bossa> exit

Jetzt muss der Cube ein letztes Mal per USB neu verbunden werden, um mit Minicom per X-Modem die CUBEx4_BL.bin (Doppelklick auf Spacetaste zum Verzeichniswechsel ;-) ) zu flashen. Dazu muss die Reset-Taste an der Unterseite des Cube während des Ansteckens gedrückt gehalten werden.

13 Kommentare:

  1. Moin! Ich möchte auch einen MAX!Cube mittels a-culfw einsetzen, bin eigentlich auch nicht auf den Kopf gefallen und habe auch schon den kompletten fhem-thread gelesen, aber ich kapiere nicht, wie ich zusätliche Funkmodule im Cube anlöten soll. Irgendwie fehlt mir komplett die Logik zischen Deinem Bild oben und der boards.h, in der die Pins definiert sind. Hast du da genauere Informationen oder einen passenden Link? Danke sehr!!

    AntwortenLöschen
    Antworten
    1. Der CC1101 hat neben den SPI Anschlüssen (MISO,MOSI,SCK noch den Chip-Select (CS) sowie IN und OUT Anschluss. Diese bilden die linke Seite der board.h.
      Auf der rechten Seite steht, wo diese Pins auf den CUBe gemappt werden (dazu die Bilder mit den erreichbaren Kontakten dieser Pins auf der Platine).

      Löschen
    2. Danke, langsam steige ich durch :-) Nachdem ich den Thread im FHEM-Forum nochmal angeschaut habe, nachdem ich mich auch eingeloggt hatte, konnte ich auch plötzlich da Bilder sehen :-)
      Vielen Dank!

      Löschen
  2. Hallo Alexander!

    Ich bin gestern auf deine Tolle Anleitung gestoßen, habe aber leider Probleme beim Kompilieren:

    /usr/lib/gcc/arm-none-eabi/7.3.1/../../../arm-none-eabi/bin/ld: section .ARM.exidx LMA [0011ccf0,0011ccf7] overlaps section .relocate LMA [0011ccf0,0011d25f]
    collect2: error: ld returned 1 exit status
    make[1]: *** [Makefile:125: CUBE_BL.elf] Error 1
    make[1]: Leaving directory '/home/pi/a-culfw/culfw/Devices/CUBe'
    make: *** [Makefile:97: CUBE_BL] Error 2

    Hast du eine Ahnung, was ich falsch mache?

    AntwortenLöschen
    Antworten
    1. Hallo Oern,

      ich habe Deinen Beitrag durch eine Google-Suche gefunden, weil ich auf das selbe Problem stieß. Laut telekatz

      https://forum.fhem.de/index.php/topic,38404.msg1088379.html#msg1088379

      funktioniert es nur mit GCC bis 6.2.1 und auf einem richtigen PC (nicht Pi).

      Ich habe wie in einer VM mit Debian Stretch (siehe auch Alexanders Anleitung oben) kompilieren können.

      Gutes Gelingen!

      Löschen
    2. Danke.
      Wenn du den verlinkten Beitrag weiter gelesen hast, dann hast du sicherlich auch gesehen, dass ich die VM Lösung dort eingebracht habe.

      Gruß

      Oern

      Löschen
    3. Wow, Deinen Usernamen habe ich im FHEM-Forum echt überlesen. Dann gilt mein Dank auch Dir! :)

      Löschen
    4. Alternativ gibts einen Fix (nicht von mir): https://github.com/Scyten/a-culfw/tree/bugfix-Fix-linker-script-for-CUBe-device

      Löschen
  3. Darf ich hier ganz freundlich mal einhaken? Ich habe exkat das gleiche Problem und absolut keine Idee mehr..

    AntwortenLöschen
  4. Hallo Alexander,

    ich habe den Cube_BL testweise als USB und LAN Gerät in Betrieb genommen und es läuft. Jetzt nach Umbau als CUBEx4_BL bräuchte ich einen Tipp wie ich über LAN auf die Tranceiver zugreifen kann in FHEM der interne läuft ja schon.

    AntwortenLöschen
    Antworten
    1. Hallo, schon eine Lösung gefunden? Also die Tranceiver einzeln anzusprechen? Ich habe hier auch noch einen Cube, wenn ich mir damit den SCC und Jeelink einsparen könnte, wäre ich happy.

      Löschen
    2. Also ich benutze STACKABLE_CC:
      defmod cul02 STACKABLE_CC cul01
      attr cul02 model CUN
      attr cul02 rfmode SlowRF

      (auch wenn das die "alte" Einrichtungsmethode ist: https://wiki.fhem.de/wiki/MapleCUN#Einrichtung_in_FHEM_(alt) )

      Löschen