Hallo Stummis,
Zitat
Zu dem I2C Monitor gäbe es 2 Möglichkeiten:
* Bluepill sniffert über Port Pins (Interrupt on Change o.ä.)
* kleiner PIC oder ATTiny (für tiny gibt es einen Sniffer I2C -> seriell, Gerd hat Ihn schon auf GITHUB)
Wenn eine Lösung über z.B. SPI (besser, da ser. Ports ja belegt) gewünscht wird, kann ich gerne einen Sniffer für PIC(z.B 12F1822) shreiben...
Die I2C Kommunikation ist ja glaube ich <= 100kHz... (beim PIC 32MHz (8MHz instruction) ca. 80 Befehle pro Bit, das sollte machbar sein)
Ich würde mich sehr über eine Entwicklung in diese Rchtung mit 6021 freuen, da ich beim Bluepill noch gar keine Ahnung habe.
Immerhin ist gestern mein ST-Link gekommen, also werde ich da auch mal debuggen/helfen können.
wenn ein ATTiny das hinbekommt, hat der STM32 sicher auch genug Ressourcen, um I2C in Software zu machen. Falls sich jemand daran versuchen will: Man kann einfach die Datei src/hal/stm32I2C.cpp entfernen und durch eine Eigenimplementierung mit Software-I2C ersetzen. Dann kann man direkt den Betrieb mit einem Keyboard aufnehmen und testen, ob der SW-I2C grundlegend funktioniert. Ich vermute, dass dann ein Timerinterrupt notwendig ist, um den Bus zu samplen. Eine hälfte der Ressourcen von TIM2 ist für LocoNet verwendet, mit TIM3 bastelt bertr2d2 im MM-Sniffer. Man kann also entweder die zweite hälfte der Ressourcen von TIM2 oder einen der Timer TIM4+ verwenden.
Es gibt übrigens auch ein Projekt für einen I2C-Sniffer auf dem STM32. Ich habe den Sniffer ganz zu Beginn des Projekts benutzt, um ein Gefühl für die Kommunikation zu bekommen. Dr. König hat ein paar Details der I2C- und Märklin-Kommunikation durcheinandergeworfen, was mit das Verständnis erschwert hat. Der Sniffer funktioniert, verwendet im Unterbau allerdings CubeMX statt libopencm3 und arbeitet auch auf anderen Pins.
Zitat
Also die Reihenfolge am 6021 ist "ganz einfach" ??? zu ermitteln (wenn ich es richtig verstanden habe), da CU6021 eine Leitung hat, die von den in der Initialisierung angesprochenen Geräte "weitergeschaltet" wird. Wenn Connect21 light ganz rechts hängt, ist dies der letzte Teilnehmer und kann an der Init-I2C-Adresse (wenn Leitung weitegeschaltet und bei Connect angekommen ist) erkennen wie viele Control 80f dranhängen.
Der komplizierteste Teil der I2C-Kommunikation dürfte die Übergabe des "FOCUS" sein, also wer ist berechtigt, die Lok zu Steuern(Blinken/Leuchten der Lokaddresse 6021/Control 80f)...
Ein Multimaster-Protokoll ist wahscheinlich auch noch nötig: Falls der Bluepill das nicht hat(???), kann über den Sniffer auch eine Buskollision detektiert werden... (Sniffer muss gesendetes Paket zurückliefern)
Das Protokoll selbst ist wahrscheinlich nicht das Problem. In der Software wird es aufwändig, weil man eine Zusandsmaschine braucht, die man dann über die Zeit weiterschalten muss. Was die Übergabe des Fokus angeht, würde ich erstmal mit realen Control 80f testen. Soweit ich mich erinnere war es zumindest in der Kombination Control Unit/Control 80f überhaupt kein Problem, eine Lok von beiden Fahrpulten gleichzeitig zu steuern. Ich könnte mir gut vorstellen, das ein Großteil der Adressierung oder Lokbelegung einfach ignoriert wird.
Zitat
Zitat
Zitat
Meine Wünsche für Witerentwicklungen:
Sehr wünschenswert wäre, dass auch über die Einbindung einer Loksteuerung über die 6021 mit Control 80f nachgedacht wird. Das wäre der Königsweg. Ihr wertet ja den I2C Bus schon aus. Wenn der Prozessor einen Monitormodus hat (keine Ahnung, also auf Adressen hören, ohne ACK zu erzeugen), dann könnte man ähnlich wie das Interface 6050 agieren. Ich denke schon länger über einen solchen Ansatz nach.
Jetzt halt' dich fest: über die Anbindung von Control 80f denke ich auch schon seit Beginn des Projekts nach . Der STM32 hat aber meines Wissens keinen Monitor-Modus, d.h. die c6021light wird immer eine Control 6021 ersetzen müssen. Loksteuerung über I2C hat allerdings zwei Herausforderungen. Zunächst muss man die angeschlossenen Control 80f bestimmen, dann muss man die Steuerbefehle in beiden Richtungen übersetzen. Um die Menge der Herausforderungen klein zu halten, habe ich mit der Loksteuerung zwischen CAN und LocoNet angefangen. Die Probleme bei der Übersetzung der Steuerbefehle sind die gleichen, aber ich kann diese Probleme vom aufzählen der Control 80f trennen. Mal abgesehen davon, dass ich im Moment gar keine Control 80f habe.
Über genau das hab ich mir in den vergangenen Tagen auch Gedanken gemacht. Ich fände es absolut genial wenn man Control 80f einbinden könnte. Leider sind diese auf ebay für ihr Alter und Funktionalität noch ganz schön happig teuer Wie ich sehe habt ihr beim HW-Design bereits daran gedacht, indem die M_STOP/GO und M_INIT Leitungen am STM32 hängen. Ich denke es wäre absolut vertretbar dass das c6021l die 6021 ersetzt. Alle c80f kommen rechts ran, dann kann die c6021l wie bereits von [user]markra[/user] beschrieben den normalen Init-Prozess mit Erkennung der c80f durchlaufen. Die Stop/Go Funktionalität scheint ja als shared-Bus durchgeschleift zu sein, wo ausgelöst wird wenn ein Teilnehmer eine der Leitungen via Knopf nach 5V zieht (siehe Maerklin-schematics, gibt es irgendwo noch andere HW-Infos zum 60xx System?). Auch das sollte ja einfach zu realisieren sein. Für was habt ihr eigentlich die M_B10 Leitung zum STM32 verbunden? Ich habe nirgendwo Hinweise gefunden, dass die eine Funktion hat.
So war's gedacht. Mein persönlicher Plan war eine c6021light für die Keyboards und eine zweite für mögliche Control 80f's zu verwenden. Was M_B10 angeht: Das ist eine Angst-leitung. Wenn sich rausstellt, das man die Leitung für irgendwas braucht, kann man den Jumper setzen. Ansonsten kann man die auch Umfunktionieren. Wobei mir noch nicht bekannt wäre, das jemand die 6 freien GPIOs für irgendwas verbraucht hat. Ich benutze die immer nur, um beim Debuggen von Interruptroutinen Pins zu setzen, die ich mit Oszi oder Logikanalysator beobachten kann.
Zitat
Das connect6021 von Märklin lässt sich ja über den CAN konfigurieren, sodass man die 80 (bzw 99?) Adressen im 60xx-System virtuell auf Loks in der Datenbank im CAN-System mappen kann. Sowas wäre toll zu haben. Ich denke über kurz oder lang bräuchte die c6021l eine Art CVs um die Konfiguration unterbringen zu können. Wie man diese dann beschreibt/liest, ist eine andere Geschichte.
In einem früheren Projekt (LocoNet Eigenbau-Rückmelder/Bremsmodule) habe ich einem Arduino beigebracht, sich über Uhlenbrock LNCV's von einer Intellibox programmieren zu lassen. Das war nett, weil man sich sparen konnte, mit einem USB-Adapter unter der Anlage rumzukriechen, um die Rückmelderadressen einzustellen. Bei der c6021light sehe ich da bisher noch nicht den großen Vorteil - die steht ja tendentiell eher in Reichweite des Lokführers .
Dennoch: Gibt es eine Übersicht, wie die Konfiguration über CAN funktioniert und welche Geräte da als Controller fungieren können? Bei der MS2 kenne ich so eine Funktion nicht, bei einer CS2/CS3 würde ich erwarten, dass man der CS* erstmal beibringen muss, was eine c6021light eigentlich ist.
Ich habe auch schon darüber nachgedacht, einfach Bedienelemente an die c6021light anzuklemmen, wenn man komplexere Usecases hat. Dazu bietet sich der herausgeführte zweite I2C geradezu an Das Display aus dem WLAN-Fahr und -Weichenstellpult ist auch per I2C angebunden. Knöpfe kann man über einen I/O-Expander oder einen Atmega/ATTiny als Slave-Device anbinden.
Zitat
Was die ganze Adress-Übersetzerei anbelangt, habe ich ehrlich gesagt den Überblick verloren. Wir haben grundsätzlich 4 Busse: CAN, I2C, LN und XPN. Abgesehen von I2C, hat jeder dieser Busse einen Master? Die Frage ist: Muss es systemweit auch einen einzigen Master geben, und ist dann auch das Gerät welches für die Erzeugung vom Gleissignal zuständig ist? Je nachdem macht es Sinn diesen zu definieren. Du schreibst ja oben, dass LN Slots bei der LN-Zentrale angefragt werden müssen. Gibt es auch ein Szenario, bei dem über LN nur Handregler angeschlossen sind und die Zentrale an CAN oder XPN hängt?
Daran angeschlossen: Ist das c6021l der richtige Ort um Steuerungskollisionen von den verschiedenen Bussen zu erkennen? Unterztützt jeder der Busse eine Rückmeldung "Angeforderte Lok bereits belegt"?
da gibt es erstmal ein elektrisches Problem: Die Ausgänge verschiedener Zentralen miteinander zu verbinden sorgt üblicherweise für das vorzeitige ableben derselben. Man kann aber bei ordentlicher Trennung der Boosterkreise und beschränkung auf MM2/DCC (ohne MFX) theoretisch schon eine Intellibox an den einen Stromkreis und eine Gleisbox an den anderen hängen. Persönlich habe ich aber eher den Usecase, auch auf LocoNet "Zentrale" zu spielen. Ich habe eine Daisy und zwei FREDIs, die ich an meine Gleisbox anschließen möchte.
Um etwas auszuholen: Beim Modellbahnen mit Gästen hat sich bei der MS2 der Einsatz von Lokkarten als unschlagbar erwiesen. Wenn man z.B. die Intellibox benutzt, muss ich ständig herumspringen und den Leuten Adressen diktieren. Die Adressen lassen sich zwar fast immer logisch aus den Baureihennummern ablesen, aber manch ein Modellbahner hat ja auch nicht mehr perfektes Augenlicht und kann dann die Loknummer nur schwer entziffern. Bei FREDIs sind Adressen für den Benutzer komplett egal, weil sie ohnehin eine beliebige Lok von der Zentrale zugewiesen bekommen. Wie das Zuweisen von Loks geht, weiß ich inzwischen. Implementiert ist's aber noch nicht.
Bonus, wenn eine c6021light die LocoNet-Zentrale spielt: Man kann den FREDIs dann voraussichtlich auch MFX-Loks zuweisen, deren Adresse man ja selber gar nicht kennt
Zitat
Ich denke das Projekt hat gigantisches Potential zu einer Art Universal-Busknoten/Gateway mit dem man die Vorteile aller Bussysteme und erhältlicher Komponenten zusammen nutzen kann. Man denke nur an die echte Weichenrückmeldung über CAN-Weichendekoder, die dann wiederum an alle anderen Busse weitergeschickt werden.
Ich habe noch keine Informationen über XPressNet. Für alle anderen Busse kann ich aber sagen: Das Übersetzen von Stop/Go, Weichenstellen und Besetztmeldern ist ziemlich simpel, da jeder dieser Befehle in jedem System genau einer Nachricht entspricht. Die c6021light muss nichts denken und nur Nachrichtenformate konvertieren. Die Umsetzung zwischen CAN und LocoNet sollte dafür schon vollständig sein. Auf I2C gibt es keine Rückmeldung (hatten wir ja schonmal diskutiert) und es gibt noch keine Unterstützung für Geräte, die sich für Stop/Go aktiv interessieren. Ist also auch nahe dran.
Zum Ausgleich dafür ist die Loksteuerung überall gleichviel schwieriger. Auf jedem System muss man irgend welchen Zustand halten, auf einem anderen System nachfragen, Adressen umrechnen, etc.
Gruß,
fantux