Hallo Gerd,
vielen Dank für deine Antwort.
Dann auch vielen Dank an Fantux. Vielleicht schaut er ja mal wieder rein.
Ich habe nochmal ein bisschen getestet - auch die Releases bis 1.4.
DCC wird mit jedem älteren Release wüster, bis hin zu unendlicher wirrer Zeichenflut auf der seriellen Schnittstelle.
Ich habe jetzt mit dem Release 1.6 nochmal systematischer gemessen:
| Schaltanforderung von | Format MS2 | Format 6021light | Message auf I2C | Kommentar | | MS2 | MM | MM2 | nur ACK | tut alles so wie es soll |
| MS2 | DCC | MM2 | nein | sollte auch passen |
| MS2 | DCC | DCC | nein | hier müsste eigentlich das ACK übertragen werden |
| MS2 | MM | DCC | nur ACK | Keyboard Anzeigen schalten um |
| Keyboard | DCC | MM2 | Request & ACK | MS2 ändert Anzeige Schaltzustand trotzdem |
| Keyboard | DCC | DCC | nur Request | MS2 ändert Anzeige Schaltzustand
Request und ACK sind auf dem CAN
ACK wird nicht auf I2C übersetzt
Keyboard sendet alle 1,5sec Requests
|
Interessant ist, dass die MS2 im DCC-Modus auch auf MM2-Befehle reagiert und die Statusanzeige umstellt. evtl. ein Kompatibilitäts-Ding?
Die Message-Flut auf dem Bus scheint vom Keyboard zu kommen, das die ACK auf dem CAN nicht erhält, da diese nicht auf dem I2C übertragen werden.
Einen Grund für das Fehlen auf dem I2C konnte ich nicht entdecken aber es erklärt weshalb das Keyboard dann keine Ruhe gibt.
Durch die fehlenden ACK schaltet die Keyboardanzeige auch nicht um, wenn der Request durch die MS2 erfolgt.
Habe mal ein bisschen im Quellcode gestöbert aber das ich nicht mein Steckenpferd...
Liegt das „P“ statt „DCC“ evtl hier in der Zeile 6: (consoleManager.cpp)
1
2
3
4
5
6
7
8
9
10
11
12
13
if (strncasecmp(protocolArgument, MM2Name, strlen(MM2Name)) == 0) {
dataModel_->accessoryRailProtocol = RR32Can::RailProtocol::MM2;
printf("%s%s'%s'.\n", appName, text, protocolArgument);
} else if (strncasecmp(protocolArgument, DCCName, strlen(DCCName)) == 0) {
dataModel_->accessoryRailProtocol = RR32Can::RailProtocol::DCC;
printf("%s%s'%s'.\n", appName, text, argv[argcMatched + 1]);
} else if (strncasecmp(protocolArgument, SX1Name, strlen(SX1Name)) == 0) {
dataModel_->accessoryRailProtocol = RR32Can::RailProtocol::SX1;
printf("%s%s'%s'.\n", appName, text, protocolArgument);
} else {
printf("%s: Unknown rail protocol '%s'.\n", appName, protocolArgument);
return -3;
}
Das wäre dann aber nur ein Print-Thema…
Und bricht der I2CForwarder hier in der Zeile 9 bei nicht MM Kommandos ab:
1
2
3
4
5
6
7
8
9
10
11
12
void I2CForwarder::forward(const RR32Can::CanFrame& frame) {
switch (frame.id.getCommand()) {
case RR32Can::Command::ACCESSORY_SWITCH: {
const RR32Can::TurnoutPacket turnoutPacket(const_cast<RR32Can::Data&>(frame.data));
if (frame.id.isResponse()) {
// Responses are forwarded to I2C
printf(" Got an Accessory packet!\n");
if (turnoutPacket.getRailProtocol() != RR32Can::RailProtocol::MM1) {
// Not an MM2 packet
return;
}
Aber wie gesagt, gefährliches Halbwissen… 
Update 25.05.:
Habe mit jetzt mal PlatformIO installiert und im ConsolenManager die Zeile angepasst.
Die Prüfung auf das RailProtocol habe ich jetzt einfach mal komplett auskommentiert.
Jetzt funktioniert auch der DCC Modus und die Antwort im Serial-Monitor ist auch korrekt. 
Was ich allerdings nicht überblicke ist, ob dadruch DCC Pakete irgendwo verarbeitet werden, wo sie es nicht sollten.
