Hi Benoit,
@Alle: Eine Deutsche Übersetzung findet ihr unten…
I am very pleased that MobaLedLib has also arrived in France. It also answers one of my questions that have not been asked yet: "Should I continue to translate the documentation into the English language?"
@All:
If there are two more friendly model railroaders reporting that they would like a translation, then I will translate the extensions to the documentary. Currently the description is at the editors for the correction ...
=> If you want an English description, then post it here!
Now for your questions:
At the moment I see no need to use bidirectional communication. The communication to the LEDs is only one way.
In addition, the RS232 protocol has the advantage that it is supported by hardware from the Arduino. I had to use two processors because the FastLED library locks the interrupts for a long time. During this time, DCC commands have been lost. Now the DCC Arduino translates the commands, stores them temporary and sends them via RS232 to the LED Arduino. Via line A1 between the two Arduinos, the sending of the characters is interrupted before the interrupts are disabled. It can happen that there is still a character on the way. That does not matter, because this character is received by hardware even if the interrupts are locked.
What advantages would other communication methods have?
Modularization is certainly important from a reliability point of view. If you think about software maintenance, it may be better to have a centralized system.
There are different approaches.
The easiest way is to use a dedicated controller for each area. Thanks to the low prices for the Arduinos, this is not a financial problem. The space for the hardware and the software maintenance may speak against it.
Simple 4-wire cabling allows each module to be connected separately. This can be done via an additional distributor board. Unfortunately, the addresses of the LEDs shift, if not all modules are used or changes have to be made to a module. In the not yet published documentation, I showed a way how to improve it.
The FastLED library can also control several separate LED strings. Each stripe is controlled by its own pin. Then one module can be omitted without affecting the other modules.
In the example "14.Switches_80_and_more" I used two LED stripes. One for the LEDs on the railway system and one for the illumination of the buttons.
Therefore, there are two initializations in the "setup ()" function:
1
2
3
4
FastLED.addLeds <NEOPIXEL, LED_DO_PIN_1> (leds, NUM_LEDS_1);
FastLED.addLeds <NEOPIXEL, LED_DO_PIN_2> (leds + NUM_LEDS_1, NUM_LEDS_2);
Saving the configuration as CV data would certainly be possible, but a very time-consuming job. In addition, one is limited by the low EEPROM memory of the Arduino.
It would certainly be possible to create a user-friendly interface with which you can click the configuration together with the mouse. This program would then generate a configuration which one could send to the Arduino with the normal Arduino upload program (AVRDrude). Everything from an IDE.
But we could also think further and develop our own boot loader that transmits the data via DCC.
But that is an endless amount of work.
The project is not meant for people who do not want to do it themselves. The people have to have a certain willingness to get involved in the matter. If they have done that, they will be rewarded by a very nice result and can say: "I programmed this myself".
I will gladly support everyone. In the meantime, I have also found some colleagues so that we can create a really great project together. You are cordially invited.
I've never heard of the decoder by Geoff Bunza. What I see here at first sight
https://model-railroad-hobbyist.com/node/24316 looks promising. I have to read carefully. Also, the thread in the Stummi forum: https://stummiforum.de/viewtopic.php?t=156451
I am very happy, if you join the MobaLedLib users.
Hardi
----------------------------------------------------------------------------------------------------------------------------------
Hier ist die deutsche Übersetzung des Posts von Benoit und meine Antwort darauf. Ich hoffe Google und ich haben es einigermaßen richtig Übersetzt:
Zitat
Vielen Dank für diesen tollen Job Hardi!
Ich habe eine Weile nach einer Möglichkeit gesucht, alle Zubehörteile meiner Dioramen zu betreiben und zu automatisieren. Deine Arbeit hat mir sehr geholfen.
Meine typische Verwendung der MobaLebLib eine vollständige Automatisierung über DCC mit JMRI-Software und / oder manuelle Steuerung von Lichtern (Anmerkung von Hardi: JMRI = Java Model Railroad Interface http://jmri.org/).
Daher habe ich einige Gedanken / Fragen:
Mein erster Gedanke ist die Kommunikation zwischen Arduinos. Denkst Du nicht, dass wir ein anderes Übertragungsprotokoll wie i2C, RS485, ... verwenden könnten, um bidirektionale, Hochgeschwindigkeits- und Master / Slaves-Kommunikation zu erhalten?
Bei der zweiten geht es um die Dimensionierung und Komplexität von Wartungsarbeiten. Ich habe es vorgezogen, mein Zubehör (Lampen, Servos, Stepper ...) zur besseren Wartung auf kleinstem Raum aufzuteilen. Beispiel: Sägewerksbereich, Fabrikbereich, Warenhalle, Bahnhofsbereich, kleiner Dorfbereich, ... Die Lösung wäre also, mehr Arduinos mit einem für einen bestimmten Bereich bestimmten Arduino zu verwenden und / oder mehr Datenpins auf einem Arduino zu verwenden. Wie denkst du darüber?
In der dritten geht es um Wartungs- und Neulinge, die Dein System nutzen möchten. Denkst Du, dass es möglich sein könnte, Moba-Konfiguration im Arduino DCC-Decoder als CV-Paare / Werte zu speichern? (Ich studiere die großartige Arbeit von Geoff Bunza an einem auf Arduino Pro Mini basierenden DCC-Decoder.)
bin gespannt auf Dein Feedback zu diesen Fragen.
Freundliche Grüße,
Benoit
------------------------------------------------------------
Meine Antwort:
Es freut mich sehr, dass die MobaLedLib jetzt auch in Frankreich angekommen ist.
Es beantwortet auch eine meiner noch nicht gestellten Fragen: "Soll ich die Dokumentation weiterhin ins Englische übersetzen".
@An Alle:
Wenn sich jetzt noch zwei weitere Englisch sprechende Modellbahner melden, dass sie gerne eine Übersetzung hätten, dann werde ich die Erweiterungen zur Doku übersetzen. Momentan ist die Beschreibung bei den Lektoren zur Korrektur...
[b]=> Wenn ihr eine englische Beschreibung wollt, dann postet das hier![/]
Jetzt zu Deinen Fragen:
Ich sehe momentan keine Notwendigkeit eine bidirektionale Kommunikation zu verwenden. Die Kommunikation zu den LEDs geht ja auch nur in einer Richtung.
Außerdem hat das RS232 Protokoll den Vorteil, dass es per Hardware vom Arduino unterstützt wird. Ich musste zwei Prozessoren verwenden, weil die FastLED Bibliothek die Interrupts längere Zeit sperrt. In dieser Zeit sind DCC Befehle verloren gegangen. Jetzt Übersetzt der DCC-Arduino die Befehle, speichert sie zwischen und schickt sie per RS232 zum LED Arduino. Über Leitung an Pin A1 zwischen den beiden Arduinos wird das senden der Zeichen unterbrochen bevor die Interrupts gesperrt werden. Dabei kann es passieren, dass noch ein Zeichen unterwegs ist. Das macht aber nichts, weil dieses Zeichen per Hardware empfangen wird auch wenn die Interrupts gesperrt sind.
Welche Vorteile hätten andere Kommunikationsmethoden?
Das Modularisieren ist aus der Sicht der Zuverlässigkeit sicherlich wichtig. Wenn man an die Software Pflege denkt ist es vielleicht besser, wenn man ein zentrales System hat.
Es gibt verschiedene Ansätze.
Der einfachste Weg ist die Verwendung einer eignen Steuerung für jeden Bereich. Dank der niedrigen Preise für die Arduinos ist das kein finanzielles Problem. Der Platz für die Hardware und die Software Pflege spricht eventuell dagegen.
Durch die einfache 4-Draht Verkabelung kann man jedes Modul separat anschließen. Das kann man über einen zusätzlichen Verteiler manchen. Dabei verschieben sich dummerweise die Adressen der LEDs wenn nicht alle Module benutzt werden oder Änderungen an einem Modul gemacht werden müssen. In der noch nicht veröffentlichten Dokumentation habe ich eine Möglichkeit aufgezeigt wie man das verbessern kann.
Mit der FastLED Bibliothek können aber auch mehrere separate LED Stränge angesteuert werden. Jeder Strang wird über einen eigenen Pin angesteuert. Dann kann ein Modul weggelassen werden ohne dass es die anderen Module beeinflusst.
Im Beispiel „14.Switches_80_and_more“ habe ich zwei LED Stränge benutzt. Einen für die LEDs auf der Anlage und einen für die Beleuchtung der Taster.
In der “setup()” Funktion gibt es darum zwei Initialisierungen:
1
2
3
4
FastLED.addLeds<NEOPIXEL, LED_DO_PIN_1>(leds, NUM_LEDS_1);
FastLED.addLeds<NEOPIXEL, LED_DO_PIN_2>(leds+NUM_LEDS_1, NUM_LEDS_2);
Das Speichern der Konfiguration als CV Daten währe sicherlich möglich, aber sehr aufwändig. Außerdem ist man durch den geringen EEPROM Speicher des Arduinos eingeschränkt.
Es wäre aber sicherlich möglich eine benutzerfreundliche Oberfläche zu erstellen mit der man die Konfiguration per Maus zusammen klicken kann. Dieses Programm würde dann eine Konfiguration generieren welche man mit dem normalen Arduino Upload Programm (AVRDrude) zum Arduino schicken könnte. Alles aus einer IDE heraus.
Man könnte aber auch weiter Denken und einen eigen Bootloader entwickeln der die Daten per DCC überträgt.
Aber das ist unendlich viel Arbeit.
Das Projekt ist nicht für Leute gedacht die nichts selber machen wollen. Man muss eine gewisse Bereitschaft dazu haben sich in die Sache einzuarbeiten. Wenn man das geschafft hat, dann wird man von einem sehr schönen Ergebnis belohnt und kann sagen: „Ich habe das selber programmiert“.
Dabei werde ich alle gerne unterstützen. Inzwischen habe ich ja auch einige Mitstreiter gefunden so dass wir gemeinsam ein ganz tolles Projekt erschaffen. Du bist herzlich dazu eingeladen.
Von dem Decoder von Geoff Bunza habe ich noch nichts gehört. Das was ich auf den ersten Blick hier
https://model-railroad-hobbyist.com/node/24316 gesehen habe sieht vielversprechend aus. Ich muss es mal in ruhe Durchlesen. Ebenso den Thread im Stummi Forum: https://stummiforum.de/viewtopic.php?t=156451
Es freut mich sehr, wenn Du dabei bist.
Hardi