Selbstbau CUN (MapleCUN)

[PeMue]

Hallo Ranseyer,

ich würde einen ESP01 nehmen, der hat zwar Durchsteckkontakte (braucht Vorder- und Rückseite im Layout), ist aber sonst relativ platzsparend, da er über der Platine sitzt. Mittlerweile gibt es die auch mit 1MByte Speicher (für OTA). Und für eine transparent bridge reicht das allemal ...

Gruß PeMue

[Ranseyer]

Schade dass ich meine Meinung zum ESP geändert und ausprobiert habe ob das sinnvoll auf begrenztem Platz machbar ist.
Ich werde es nicht nutzen und schon gar nicht das Steckmodul. (Eine Bridge kann man sicher auch mit einem Kabel flashen falls denn überhaupt ein Update nötig ist)

Aber es scheint ganz gut machbar nach anderen Optimierungen. Daher bleibt der ESP03 erst mal zusätzlich.
Da mir das ganze nicht wichtig ist habe ich mal soweit alles verzichtbare (inkl. Widerlinge) weggelassen.

Anmerkungen ?

[Ranseyer]

Ich würde gerne meinen Leidensdruck für den MAPLE Bootloader nochmals erklären...

A) Läuft das Flashen absolut geschmeidig: Flash-Skript starten, MAPLE anstöpseln, warten, fertig !

B) Die Position der Buttons für Reset und Flashen liegen auf der Unterseite des Moduls.
Mir war bisher nicht so bewusst, dass wenn man den Maple fest verlötet (=fast 1 Zerntimeter weniger Höhe und weniger Arbeit), dass man dann an diese Buttons nicht mehr sinnvoll drankommt. Selbst wenn man in eine Platine entsprechende Löcher bohrt wäre das Flashen nur noch wenig spassig.

Wenn man also den Maple fest verlöteten will, geht das m.E. nur sinnvoll wenn man künftig per USB flashen kann

Bonus: Wenn man den MAPLE fest verlötet passt er bei kleinen Gehäusen ggf auch auf die Unterseite der Platine, und wenn man ein hohes LAN Modul direkt daneben hat gibt es viel weniger Konflikte.

Ob ich das selbst gelöst bekomme weiss ich nicht (Hinweise dazu liegen mir vor). Ich habe im Moment nicht einmal eine funktionierende Toolchain weil ich eine andere Kompiler-Version für ein anderes Projekt "nutze".




ed: Die HW-Seitige Umsetzung könnte diesen Thread sprengen. Daher hier: https://forum.fhem.de/index.php/topic,50990.msg598278.html#msg598278

[Telekatz]

Nachdem der multiCC Branch mittlerweile in den Master Branch übernommen wurde, schaue ich mir das mal als nächstes an. Trotzdem solltest du dir überlegen, wie du im Notfall auch den Maple Bootloader über den integrierten Bootloader flashen kannst.

Für den MapleCUN gibt es jetzt nur noch zwei verschiedene Firmware Dateien. MapleCUNx4_W5100.bin und MapleCUNx4_W5500.bin, je nach verwendeten Wizchip. Für einen MapleCUL kann mein beide Versionen verwenden. Falls kein Netzwerkmodul angeschlossen ist wird das automatisch erkannt. Auch die Anzahl der Transceivermodule wird automatisch erkannt.

Auch habe ich bei den ARM Modellen die Umschaltung zwischen den RF Protokollen wie hier schon einmal vorgeschlagen wurde angepasst. Dies funktioniert mit Ausnahme von KOPP_FC mit allen Protokollen.

Folgende Einschränkungen gibt es für den Betrieb mit mehreren Transceivern:

• SlowRF funktioniert nur an CC0 und CC1.
• MBUS funktioniert an jedem Transceiver aber insgesamt nicht an mehr als einem Transceiver gleichzeitig.
• KOPP_FC funktioniert nur an CC0.

Die restlichen Protokolle funktionieren an allen Transceivern und auch mehrfach gleichzeitig.

Ob ich das selbst gelöst bekomme weiss ich nicht (Hinweise dazu liegen mir vor). Ich habe im Moment nicht einmal eine funktionierende Toolchain weil ich eine andere Kompiler-Version für ein anderes Projekt "nutze".

Falls du Eclipse verwendest, kannst du die PATH Variable für jedes Projekt individuell auf deine Toolchain anpassen (Einstellungen->C/C++ Build->Enviroment). Dadurch kannst du auch unterschiedliche Toolchains verwenden.

[rizzir]

Moin moin,

ich muss hier doch erstmal ein Lob an Telekatz und Ranseyer loswerden (und natürlich auch an alle anderen Beteiligten ). Ich bin gestern durch Zufall auf diesen Thread gestoßen und weil ich in meiner Bastelschublade noch ein Maple Mini rumliegen hatte hab ich mal die Schaltung aus dem Wiki auf einem Steckbrett aufgebaut und es hat auf Anhieb tadellos funktioniert.

Ich hatte die Firmware zuerst per ST-Link geflasht aber daraufhin war ich neugierig und habe es mit dem USB-Bootloader (aus dem STM32-Duino Projekt hier) probiert, was dann leider nicht funktioniert hat. Das Linker-Script hatte ich natürlich angepasst. Ranseyer was hast du denn gemacht, dass es bei dir funktioniert hat und funktioniert es mit der aktuellen Firmware aus der Master-Branch immer noch?

Dann habe ich auch gleich noch probiert eines der Blue-Pill Boards (F103C8T6) zu flashen, da ich von denen auch noch welche rumliegen hatte, was leider auch nicht funktioniert hat. Habe über USB jedenfalls überhaupt keine serielle Verbindung zum Rechner bekommen. Angepasst habe ich da zwar nichts aber wenn dann sollte es auch nur an der Peripherie auf dem Board liegen (LED, Quartz, etc.), wenn es nicht läuft, da der C8T6 genau wie der CBT6 128KB Flash hat und lediglich von ST künstlich gedrosselt (umgelabelt) wird. Die Originalsoftware von ST versagt zwar ihren Dienst wenn man per SWD mehr als 64KB große Programme da drauf schieben möchte aber mit OpenOCD oder anderer Software ist das kein Problem. Dementsprechend sollte es auch kein Problem für eigene EEPROM-Emulatoren sein. Das die C8T6 Boards keine Transistoren für die Reenumeration haben ist mir schon klar aber auch ein ab- und anstecken brachte nichts.

Was das vorhalten von mehreren Toolchains auf einem Rechner angeht benötigt man übrigens auch kein Eclipse um zwischen denen umschalten zu können. Passt man im Makefile die Targets entsprechend so an

Code Auswählen Erweitern


MapleCUL:
make TARGET=MapleCUL CC=$(CC) OBJCOPY=$(OBJCOPY) build


dann kann man mit einem einfachen

Code Auswählen Erweitern

make CC=/path/to/favorite/toolchain/arm-none-eabi-gcc OBJCOPY=/path/to/favorite/toolchain/arm-none-eabi-objcopy MapleCUL einfach die Toolchain seiner Wahl nutzen.

Eine letzte Sache habe ich noch was das Flashen mit internem Bootloader per UART angeht. Es ist wichtig, das man zuerst den Reset-Button loslässt und dann (nach einer Weile, kann beliebig lang sein) erst den anderen Button. Das hat den Grund, dass der STM32 nur dann in den seriellen Bootloader bootet, wenn beim Start der Boot0-Pin auf VCC liegt (was man durch drücken des Buttons erreicht), jedoch überhaupt erst dann bootet wenn der Reset-Pin nicht auf GND liegt (was erst dann passiert wenn man den Reset-Button loslässt). Das sollte gegebenenfalls auch noch im Wiki-Artikel im Abschnitt über das Flashen klargestellt werden.

Ich werde mich die Tage auch mal ein bisschen in die Firmware reinfuchsen. Mit der ST-HAL habe ich leider bis jetzt noch gar keine Erfahrung, da ich bisher bei den STM32 entweder direkt auf Registerebene per CMSIS-Header oder mit anderen HALs gearbeitet habe (mbed, ChibiOS). Ich habe jedenfalls auch großes Interesse daran, die Firmware so zu erweitern, dass eine Transparent-Bridge zum Beispiel mit einem ESP8266 mit ESP-Link problemlos möglich ist. Meine Idee wäre dann diese Kombination (STM32, CC1101, ESP8266) in ein kompaktes Gehäuse zu packen und gegebenfalls noch mit einer 1-Wire und einer IR Schnittstelle zu garnieren.

[Telekatz]

Der Bootloader für den Maple Mini wird jetzt auch unterstützt. Die Firmwaredateien zum herunterladen sind entsprechend umgestellt worden. Die Anleitung dazu ist in der readme.md vom MapleCUN.

[Ranseyer]

Danke ! Das ist eine sehr gute Nachricht.

Muss es der Bootloader von RogerClarkMelbourne sein, oder darfs auch der originale sein ?

[rizzir]

Ich hatte schon gedacht ich hätte die Bootloader-Option im Makefile und in der Readme übersehen und dann doch festgestellt, dass du es gerade eben noch geändert hast. Also bei mir funktioniert das mit dem STM32Duino Bootloader ganz hervorragend. 

Mit dem BL von Maple wird es wohl so nicht klappen:

Code Auswählen Erweitern

#define VECT_TAB_OFFSET  0x2000 /*!< Vector Table base offset field.
                                    This value must be a multiple of 0x200. */

beim original Maple ist der Offset 0x5000 und im dfu-util muss man --alt 1 statt --alt 2 wählen. Der Bootloader von Roger Clark Melbourne hat aber eine Kompatiblitätsoption, so dass man wenn man ihn mit -a 1 befeuert sich wie ein Maple-Bootloader verhält. Das kostet zwar die 3kB RAM, die eigentlich eingespart wurden aber wenn man sich die verkneifen kann, wäre eine Kompatibilität mit dem Standard-BL vermutlich schon besser. Für den Otto-Normalverbraucher wäre sicherlich am meisten gewonnen, wenn er gar nicht erst mit dem UART-Bootloader in Berührung käme.

[Telekatz]

Man kann den Original Maple Bootloader auch ohne seriellen Bootloader auf die RogerClarkMelbourne Version patchen.
https://github.com/rogerclarkmelbourne/STM32duino-bootloader/blob/master/STM32F1/maple_mini_bootloaer_updater/maple_mini_bootloaer_updater.ino

Ich lass das jetzt mal so.

[rizzir]

Wenn du nichts dagegen hast würde ich geschwind Makefile, Linkerscript und Startup-Code anpassen so dass man eine Auswahl hat. In etwa für den Maple-BL

Code Auswählen Erweitern


make BOOTLOADER=MAPLE MapleCUL


oder für den STM32Duino-BL

Code Auswählen Erweitern


make BOOTLOADER=STM32DUINO MapleCUL


und ohne BL dann

Code Auswählen Erweitern


make MapleCUL


ein extra Target für jeden Bootloader wäre vermutlich etwas unübersichtlich.

[Telekatz]

Ich will da nicht zu viele Varianten reinbringen. Deshalb nochmal:

Ich lass das jetzt mal so.

[A.Harrenberg]

Hi,

darf ich als Maple-Neuling mal ein paar dumme Fragen dazu stellen??

Man kann den Original Maple Bootloader auch ohne seriellen Bootloader auf die RogerClarkMelbourne Version patchen.
https://github.com/rogerclarkmelbourne/STM32duino-bootloader/blob/master/STM32F1/maple_mini_bootloaer_updater/maple_mini_bootloaer_updater.ino

WIE geht das? Mein Verständnis ist das der mitgelieferte Bootloader nicht über die USB-Schnittstelle ansprechbar ist, sondern nur über die interne Serielle... Wie kann man dann ohne diesen Bootloader geflasht zu haben einen Sketch zum patchen hochladen? Jedenfalls kann ich den Maple-mini nicht über den Arduino (1.6.13, Duo-Package + STM32 Package installiert) ansprechen.

Wenn ich mir die Seite von rogerdarkmeldbourne anschaue steht selbst da das man das nur per serieller Schnittstelle machen kann...

Wenn das irgendwie OHNE die serielle gehen würde wäre das cool. Momentan sind meine Maple noch jungfräulich und OHNE Stiftleisten, dann könnte ich mal testweise einen flashen ohne dafür die Stiftleisten einlöten zu müssen. Die würde ich nämlich erst anlöten wollen wenn ich den Zusammenbau auf der Platine mal angeschaut habe um dann je nachdem evtl. längere oder kürze Stiftleisten zu verwenden.

Wäre für eine kurze Mini-Anleitung dankbar.

Danke,
Andreas.

[Ranseyer]

Wie man den Bootloader umbiegen kann, kann ich dir nicht sagen. Das war mir den Aufwand nicht wert.

Für den STM32 Bootloader braucht man  RX+TX, GND wäre auch besser zu haben. VCC auch vom "USB-Wandler" oder Mini-USB am MAPLE.
Also max. 2*2 zusammenhängende Pins. Wenn man also an den beiliegenden Pinleisten nur die 2x2 Pins einlötet bekommt man die super-einfach wieder raus. (Oder halt alle einlöten wenn man dann zufrieden ist)

Das Flashen per STM32-Bootloader mit den Tastern drücken hat bei mir nicht funktioniert (3 MAPLE, einer neu).

Was ganz einfach war:
-Mini-USB halb einstecken
-bot32 gedrückt halten (oder war es Reset?)
-Mini-USB mit der anderen Hand ganz einstecken
-bot32 loslassen

Damit man zeitlich nicht aufpassen muss die übliche Schleife:

#! /bin/sh
while (true); do

sudo ./stm32flash -w maple_mini_boot20.bin -v /dev/ttyUSB0 #Step 1: Bootloader tauschen
#sudo dfu-util --verbose --device 1eaf:0003 --cfg 1 --alt 2 --download MapleCUNx4_W5500_BL.bin #Step2:  Firmware per USB
if [ $? -eq 0 ]
then break
fi
sleep 1
done
exit

PS: Ich stelle heute Abend Mal ein paar Fotos rein im anderen Thread. (In der Anlage V1.2 ist noch eine unnötige Nachverdrahtung zwischen GND der beiden UARTs)

[Telekatz]

Der STM32F103 hat nur den seriellen Bootloader. Dieser ist im µC integriert und kann auch nicht gelöscht oder überschrieben werden. Um ein komfortables Flashen über USB zu ermöglichen werden die Boards wie die Arduinos mit einem vorinstallierten USB Bootloader ausgeliefert. Dies ist normalerweise der original Maple Bootloader von LeafLabs. Dieser benötigt 16kB Flash und 3kB RAM. Ein "dfu-util --list" liefert bei aktivem Bootloader folgende Meldung:

Code Auswählen Erweitern


Found DFU: [1eaf:0003] ver=0201, devnum=8, cfg=1, intf=0, path="1-11.1", alt=1, name="DFU Program FLASH 0x08005000", serial="LLM 003"
Found DFU: [1eaf:0003] ver=0201, devnum=8, cfg=1, intf=0, path="1-11.1", alt=0, name="DFU Program RAM 0x20000C00", serial="LLM 003"

Daneben gibt es dann den verbesserten STM32duino Bootloader, der lediglich 8kB Flash und kein RAM belegt und auch noch schneller ist.

Der von mir verlinkte Sketch dient nun dazu, aus dem Original Bootloader den STM32duino Bootloader zu machen. Ich hab die kompilierte Version davon mal unten angehängt. Flashen kann man diesen dann mit dem dfu-util:

Code Auswählen Erweitern

dfu-util --verbose --device 1eaf:0003 --cfg 1 --alt 1 --download maple_mini_bootloaer_updater.bin

Nachdem nach einem Reset der Sketch ausgeführt wird muss man noch eine serielle Konsole zum Maple aufmachen, um die dann erscheinende Sicherheitsabfrage mit Y zu beantworten. Danach wird der STM32duino Bootloader installiert. Ein "dfu-util --list" liefert dann folgende Meldung:

Code Auswählen Erweitern

Found DFU: [1eaf:0003] ver=0201, devnum=19, cfg=1, intf=0, path="1-11.1", alt=2, name="STM32duino bootloader v1.0  Upload to Flash 0x8002000", serial="LLM 003"
Found DFU: [1eaf:0003] ver=0201, devnum=19, cfg=1, intf=0, path="1-11.1", alt=1, name="STM32duino bootloader v1.0  Upload to Flash 0x8005000", serial="LLM 003"
Found DFU: [1eaf:0003] ver=0201, devnum=19, cfg=1, intf=0, path="1-11.1", alt=0, name="STM32duino bootloader v1.0  ERROR. Upload to RAM not supported.", serial="LLM 003"

Siehe dazu auch http://wiki.stm32duino.com/index.php?title=Maple_Mini

[A.Harrenberg]

Hi,

Wie man den Bootloader umbiegen kann, kann ich dir nicht sagen. Das war mir den Aufwand nicht wert.

ok, dann werde ich wohl doch mal die entsprechenden Pins einlöten. Könnte da natürlich einzelne Pins einlöten, dann wird das entlöten noch einfacher.

Das Flashen per STM32-Bootloader mit den Tastern drücken hat bei mir nicht funktioniert (3 MAPLE, einer neu).

Hmm, das ist natürlich nicht so schön.

Ich werde das dann mal probieren, mal sehen wie weit ich heute abend komme, ansonsten geht es erst Do/Fr weiter. Muss auch erst noch einen zweiten USB-TTL zusammenlöten, der andere hängt momentan an einer anderen Bastelbaustelle...

PS: Ich stelle heute Abend Mal ein paar Fotos rein im anderen Thread. (In der Anlage V1.2 ist noch eine unnötige Nachverdrahtung zwischen GND der beiden UARTs)

Das sind ja nur ein paar GNDs...

Danke,
Andreas.