Entwicklung SIGNALDuino Empfänger Firm- und Hardware V4 für Maple Mini und ESP32

[Ralf9]

Das ist ja auch nicht die Ethernet Lib für den Wizchip über SPI sondern für einen STM32 mit integriertem Ethernet MAC.

Danke, da hätte ich lange suchen können.

Mir ist aber nicht klar wo die Ethernet Lib für den Wizchip ist.
Hier habe ich sie bis jetzt nicht gefunden:
https://github.com/stm32duino/Arduino_Core_STM32

[Telekatz]

Ich vermute, es ist die Ethernet Lib aus den arduino-Libraries:
https://github.com/arduino-libraries/Ethernet

Schau mal in der Build Ausgabe nach, was da alles compiliert wird.

[Ralf9]

Ja die ist es.
https://github.com/arduino-libraries/Ethernet/blob/7b5ee58ba50ae28341111e4641d35076080b8597/src/utility/w5100.cpp#L104
man müsste dann wahrscheinlich diese Datei patchen
und vor
SPI.begin();
das hier eintragen:

Code Auswählen Erweitern

#define mosiPin 28
#define misoPin 29
#define sckPin  30
#define csPin 31
SPI.setMISO(misoPin);
SPI.setMOSI(mosiPin);
SPI.setSCLK(sckPin);
        SPI.setSSEL(csPin);


Mir wäre es lieber, wenn wir die SPI bei dieser Hardware vertauscht lassen können.
Ich finde es sauberer, wenn man in der Lib der Arduino nichts patchen muss.
Wenn ich es richtig überblicke hat die Vertauschung der SPI auch Vorteile beim Layout der Platine.

Vorschlag, wir lassen hier die Vertauschung (Ethernet SPI1).
Zum compilieren einer Binary für die Maple large und small kann dann eine gepatchte lib verwendet werden.

Gruß Ralf

[Ranseyer]

Vorschlag, wir lassen hier die Vertauschung (Ethernet SPI1).

Der Schaden ist bei einer ersten kleinen Serie m.E. gering...

Die LED sollte auch sichtbar sein, sonst wäre eine extra LED auf der Platine schön, evtl sogar 2 oder eine DUO LED.

Sag mir bitte noch zwei Pins und je eine LED Farbe dazu... Dann mach ich mir die Tage mal Gedanken wie man das machen kann (bedrahtete Teile wird wohl etwas schwierig in diesem Fall, würde ich das aber auch nicht als Prio sehen). Es wäre super wenn es keinen großen Konflikte gäbe zu den ersten 3 Transceivern und den UARTs: https://raw.githubusercontent.com/ranseyer/CUN-STM32/master/HW-MAPLE-Large/Archiv/V3.5/schematic.png

[Ralf9]

Sag mir bitte noch zwei Pins und je eine LED Farbe dazu... Dann mach ich mir die Tage mal Gedanken wie man das machen kann (bedrahtete Teile wird wohl etwas schwierig in diesem Fall, würde ich das aber auch nicht als Prio sehen). Es wäre super wenn es keinen großen Konflikte gäbe zu den ersten 3 Transceivern und den UARTs:

Es würde auch eine LED reichen, die zweite LED nur, wenn Platz dafür da ist und es vom Layout her ohne großen Aufwand machbar ist.
SMD LED sind ok, die Farbe ist erstmal egal, man kann ja später die Farbe bestücken die man will.

Bei den PINs ist es wahrscheinlich am Besten, wenn diese Telekatz raussucht, damit es keine Konflikte gibt.

[Telekatz]

Mir wäre es lieber, wenn wir die SPI bei dieser Hardware vertauscht lassen können.
Ich finde es sauberer, wenn man in der Lib der Arduino nichts patchen muss.
Wenn ich es richtig überblicke hat die Vertauschung der SPI auch Vorteile beim Layout der Platine.

Vorschlag, wir lassen hier die Vertauschung (Ethernet SPI1).
Zum compilieren einer Binary für die Maple large und small kann dann eine gepatchte lib verwendet werden.

Gruß Ralf

Du musst es ja nur einmal patchen. Und wenn du dann mal eine Binary für die Maple large und small Version erstellst, musst du es sowieso tun. Den Supportaufwand für zwei unterschiedliche Harwarevarianten würde ich vermeiden.

Es würde auch eine LED reichen, die zweite LED nur, wenn Platz dafür da ist und es vom Layout her ohne großen Aufwand machbar ist.
SMD LED sind ok, die Farbe ist erstmal egal, man kann ja später die Farbe bestücken die man will.

Bei den PINs ist es wahrscheinlich am Besten, wenn diese Telekatz raussucht, damit es keine Konflikte gibt.

LED ist beim Maple Mini auf dem nicht herausgeführten Pin PB1. Die restlichen Pins sind beim MapleCUN alle schon belegt.

[Ralf9]

Du musst es ja nur einmal patchen. Und wenn du dann mal eine Binary für die Maple large und small Version erstellst, musst du es sowieso tun. Den Supportaufwand für zwei unterschiedliche Harwarevarianten würde ich vermeiden.

Da auch andere in der Lage sein sollen den sketch mit der Arduino IDE zu compilieren, ist es mir lieber, wenn ich zumindest bei dieser Platine keinen Supportaufwand habe zum patchen der Datei. Den erhöhten Aufwand habe ich lieber bei mir, als beim user.

LED ist beim Maple Mini auf dem nicht herausgeführten Pin PB1. Die restlichen Pins sind beim MapleCUN alle schon belegt.

Wenn es so eng ist, reicht auch eine LED
Was ist mit 3(PB0) und 14(PC13)
Hier sieht es so aus als wären sie frei.
https://wiki.fhem.de/w/images/b/b3/MapleCUN.jpg

[Telekatz]

Da auch andere in der Lage sein sollen den sketch mit der Arduino IDE zu compilieren, ist es mir lieber, wenn ich zumindest bei dieser Platine keinen Supportaufwand habe zum patchen der Datei. Den erhöhten Aufwand habe ich lieber bei mir, als beim user.

Integriere den geänderten Code in dein Git Repo und verwende den, statt der Arduino Lib. Dann hat jeder schon die gepatchte Version, der das selber compiliert.

Was ist mit 3(PB0) und 14(PC13)
Hier sieht es so aus als wären sie frei.
https://wiki.fhem.de/w/images/b/b3/MapleCUN.jpg

Da hängt der vierte CC1101 dran:
https://forum.fhem.de/index.php?action=dlattach;topic=60458.0;attach=70504;image

[Ralf9]

Integriere den geänderten Code in dein Git Repo und verwende den, statt der Arduino Lib. Dann hat jeder schon die gepatchte Version, der das selber compiliert.

Dann müsste ich ja die komplette Ethernet Lib in das Git Repo integrieren.

Da hängt der vierte CC1101 dran:

Dann müsste es eigentlich gehen, wenn wir bei dieser Platine hier für die LED 14(PC13) CC IN3 nehmen.
Bei der Platine hier gibt es kein vierten cc1101 und bei der a-culw dürfte es eigentlich nicht stören, da die Prüfung ob der cc1101 vorhanden ist, wahrscheinlich über CC_CS3 geht.
Da ich wegen der LED für den Maple Cul large und small sowieso eigene Binarys brauche ist es auch kein Problem wenn die SPI getauscht sind.
Bei den sduino Binarys für den Maple Cul large und small würde ich dann die LED auf 33 legen.

Was meinen die anderen die hier mitlesen dazu?
Wird beim sduino eine LED benötigt?

Inzwischen habe ich das cc1101 und das LAN-Modul zum laufen bekommen. In der Anlage ist mein Testaufbau.

Gruß Ralf

[sash.sc]

Würde es nicht Sinn machen, den "maple Duino " über PoE zu versorgen, wenn der netz Port dran ist?

Gesendet von meinem MI 9 mit Tapatalk

[RaspiLED]

Hi,

@Sidey: Schön ist anders

Reicht es nicht, wenn man nur die Init der Ethernetlib übernimmt und mit anderem SPI anspricht und der Rest include bleibt? Oder Du/Wir dem Maintainer der Ethernetlib mal einen Patch (Default SPI1 aber über Parameter SPIx) anbieten!?

Naja, PoE haben wir ja schon mal diskutiert.
Zusammenfassung:
1) Es gibt keine günstigen fertigen Module für PoE Einspeisung
2) Es gibt keinen Standard für Ampere oder Volt, hängt auch von der ZuleitungslängebdesnEthermetkabels ab  w/ Spannungsabfall
3) Bis jetzt kenne ich keine positive Meldung über eine MapleCUL mit PoE

Ich würde mich mal auf den Core des SignalMAPLE konzentrieren

Just my 2ct.
Gruß Arnd


Signalduino (Nano, ESP, ...), CUL (Busware, Nano, Maple, ...), Homematic (HM-MOD-UART-RPI, ESP, Maple, ...), LaCrosseGateway (LGW, ESP, ...), 1-wire, ESPEasy, Bravia, Yamaha, ...

[Telekatz]

Probier mal die LED auf 32. Der währe noch frei, weil das der Pin an der Taste auf dem Maple Mini ist.

[Ranseyer]

Zum Thema LEDs darf ich nichts sagen...
LEDs die ich gut leiden kann, werden nur mit schwarzem Edding verbessert. Die LEDs vom Arduino Pro-Mini erhalten meistens die letzte Segnung mit der Weller Lötstation...
Aber das schöne an einer Platine finde ich, daß auch unnötige Teile schon berücksichtigt sind... (Also gerne LEDs vorsehen, wenn sie sonst nicht Schaden...)

[Ralf9]

Reicht es nicht, wenn man nur die Init der Ethernetlib übernimmt und mit anderem SPI anspricht und der Rest include bleibt? Oder Du/Wir dem Maintainer der Ethernetlib mal einen Patch (Default SPI1 aber über Parameter SPIx) anbieten!?

Nach meinem Verständnis reicht es nicht nur die eine zu patchende Datei zu übernehmen.

Oder Du/Wir dem Maintainer der Ethernetlib mal einen Patch (Default SPI1 aber über Parameter SPIx)

Hat schon jemand gemacht, aber da hat sich seit Oktober nichts mehr getan:
https://github.com/arduino-libraries/Ethernet/issues/116
Dabei ist aber das Problem, daß bei vielen Librarys jeder sein eigenes Süppchen kocht, z.B. ändern der SPI durch eine neue Instanz
so

Code Auswählen Erweitern

SPIClass(uint8_t mosi, uint8_t miso, uint8_t sclk, uint8_t ssel = (uint8_t)NC);
bei einem anderen package so:

Code Auswählen Erweitern

SPIClass::SPIClass(uint32 spi_num)

Dies ist einer der Gründe, warum ich es hier gerne bei der Ethernet lib sauber ohne patchen einer Datei hätte.
Bei der SPI Lib gibt es fast überall ohne patchen einer Datei die Möglichkeit den SPI Port zu ändern,
Bei der Ethernet ist mir keine Lib bekannt wo dies ohne Patchen einer Datei geht.

Gruß Ralf

[Ralf9]

Probier mal die LED auf 32. Der währe noch frei, weil das der Pin an der Taste auf dem Maple Mini ist.

Die 32 ist beim Maple Mini nicht rausgeführt.
Mein Vorschlag wäre, wenn sich keiner meldet, der ein LED braucht, dann kommt bei den Binarys die LED auf 33, die ist so hell, daß sie zwischen den Platinen etwas durchscheinen müsste,
wenn es für @Ranseyer ohne großen Aufwand machbar ist, dann SMD Pads für die LED und einen Widerstand auf 14(PC13) vorsehen.
Wer dann eine LED will muß es sich selber compilieren.
Beim sduino ist die LED per Befehl abschaltbar