[Karsten42]

Hallo,

Dies ist ein Thread in dem die von Micha und mir mitgeschnittenen 0x1B (Bootloader CAN gebunden,Service ) sowie die 0x20 und 0x21 Sequenzen dokumentiert werden sollen.

Im Rahmen eines kleinen Projektes in dem es darum geht, die MS2 und Gleisbox mit neuer ( und alter! ) software zu versehen ohne im Besitz einer CS2 oder eines Freundes/Modellbahnladens zu sein, habe ich die 0x1B commands funktionstüchtig implementriert. Dabei sind einige undokumentierte Datagramme aufgetaucht die ich hier gern veröffentlichen und diskutieren möchte.
Die ist eine komplett unoffizielle Quelle zum Märklin CAN protokoll und sicher unvollständig!
Bei einem Einsatz dieser speziellen Kommandos ist höchste Vorsicht geboten da es unter Umständen zu einem kompletten Ausfalle des Zielgerätes kommen kann!

Ich würde mich freuen hierzu eine kleine Diskussion zu eröffnen um noch andere beobachtete Datagramme mit zu dokumentieren.

O.K. Jetzt ersteinmal 0x1B-Futter ( das Gute mit Jod-X-0xFF Körnern)

Kommentierte Sequenz um Daten in das Flasch eines Zieles ( MS2 / 60113 ) zu laden und dann zu starten:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
 

#
##	Example of Operating software via "CAN Bootloader Service"
## H:0xC32E  = CS2 / Updater
#
#
 
# System reset
# System booted immediatly after receive this message!
# Target 0xFF is not documented but seemed to mean "All".
# Wait aspprox 400ms after sending this command
# for startupt MS2 software bevore send next commands
C:0x00 R:0 H:0xC32E D:6 D:0x4d 0x54 0x5e 0x22 0x80 0xff 
 
# Invoke bootloader update sequence. Must be send after wait for
# start up
C:0x1B R:0 H:0xC32E D:0 
 
# Send highest block number first
# MS2 respond with empty hash
C:0x1B R:0 H:0xC32E D:6 D:0x4d 0x54 0x5e 0x22 0x44 0x55 
C:0x1B R:1 H:0x0000 D:6 D:0x4d 0x54 0x5e 0x22 0x44 0x55 
 
# Send data stream upt to 1024 byte in 8 byte per kommand. If
# less than 8 byte to be transfer padd empty bytes with 0xFF
# Hash contains the dataset number and begins with 0x300
# Build blocks of 1024 bytes and send Last bytes of file FIRST
# Attention: MS2 needs blocks = 1024 Bytes, 60113 need only 512 byte!
C:0x1B R:0 H:0x0300 D:8 D:0x29 0x1d 0x28 0x05 0x6c 0xe4 0x75 0x66
C:0x1B R:0 H:0x0301 D:8 D:0x61 0x1d 0xac 0x03 0x11 0xfd 0x2d 0xa9
C:0x1B R:0 H:0x0302 D:8 D:0x08 0x1d 0x1f 0x06 0x1d 0xc2 0x04 0x61
C:0x1B R:0 H:0x0303 D:8 D:0x71 0xd9 0x41 0x62 0x20 0x4a 0x5d 0x3e
C:0x1B R:0 H:0x0304 D:8 D:0x04 0x3e 0x2d 0x9d 0x05 0x1d 0x9c 0x04
C:0x1B R:0 H:0x0305 D:8 D:0x1d 0xb6 0x08 0x1d 0x47 0x04 0x20 0x08
C:0x1B R:0 H:0x0306 D:8 D:0x00 0x41 0x6c 0x6c 0x67 0x65 0x6d 0x2a
C:0x1B R:0 H:0x0307 D:8 D:0x5f 0x72 0x20 0x29 0x08 0x7d 0x3d 0x0a
C:0x1B R:0 H:0x0308 D:8 D:0xb9 0xfd 0x10 0x04 0x75 0x6d 0x66 0x94
C:0x1B R:0 H:0x0309 D:8 D:0x1c 0x04 0x74 0x00 0x6a 0x7f 0x07 0x16
C:0x1B R:0 H:0x030A D:8 D:0x74 0x03 0x2d 0x4b 0x08 0x4c 0x04 0x28
C:0x1B R:0 H:0x030B D:8 D:0x73 0x29 0xed 0x05 0x4d 0x6d 0x0a 0x2d
C:0x1B R:0 H:0x030C D:8 D:0xbe 0x0a 0x28 0x08 0x20 0x50 0x6c 0x61
C:0x1B R:0 H:0x030D D:8 D:0x74 0x7a 0x20 0x74 0x3f 0x00 0x69 0x2f
C:0x1B R:0 H:0x030E D:8 D:0x05 0x8d 0x1e 0x03 0x4d 0x2a 0x06 0x41
C:0x1B R:0 H:0x030F D:8 D:0x82 0x2d 0x01 0x06 0x52 0x2d 0x93 0x1e
C:0x1B R:0 H:0x0310 D:8 D:0x46 0x89 0x07 0xc0 0x04 0x00 0x47 0x42
C:0x1B R:0 H:0x0311 D:8 D:0x10 0x1c 0x05 0x41 0x6b 0x74 0x75 0xea
C:0x1B R:0 H:0x0312 D:8 D:0x06 0x3e 0x73 0x9e 0x05 0x3d 0xee 0x04
C:0x1B R:0 H:0x0313 D:8 D:0x3d 0xc1 0x08 0x41 0x3d 0x1a 0x5a 0xb5
C:0x1B R:0 H:0x0314 D:8 D:0x1e 0x5a 0xa7 0x08 0xc9 0x67 0x3e 0x21
C:0x1B R:0 H:0x0315 D:8 D:0x40 0x09 0x6e 0x41 0x77 0x04 0x45 0x2b
C:0x1B R:0 H:0x0316 D:8 D:0x41 0xa1 0x7d 0x2b 0x08 0x01 0xff 0x01
C:0x1B R:0 H:0x0317 D:8 D:0x01 0xff 0x01 0x01 0x3b 0x01 0x00 0x00
 
# Updater send CRC command to be confirmed by MS2
# MS2 need approx 37ms for positive CRC calculation and response
# DLC=5 command as ACK or NAC
# NAC example: C:0x1B R:1 H:0x0000 D:5 D:0x4d 0x54 0x0d 0x38 0xf2
#
C:0x1B R:0 H:0x3F17 D:7 D:0x4d 0x54 0x0d 0x38 0x88 0xb1 0x15 
C:0x1B R:1 H:0x0000 D:5 D:0x4d 0x54 0x0d 0x38 0x88
 

loop until all block are send
... send block number--
... send data
... send CRC
 

# ?? undocumented, may mark loaded SW as complete and correct to load
# Software is loaded and starte without this command ( Seen at MS2 V 1.83 )
C:0x1B R:0 H:0xC32E D:5 D:0x4d 0x54 0x5e 0x22 0xf5 
 
# Start loaded software ( reboot )
C:0x1B R:0 H:0xC32E D:5 D:0x4d 0x54 0x5e 0x22 0x11 
 

 

[st-oldie]

Hallo Karsten,

ich denke, unter "Software und Hardware" paßt der technische Thread auch besser. Ich wollte noch auf dein Setup mit CC-Schnitte und MCU antworten. Wenn du nichts dagegen hast, mache ich das auch hier.

Zitat von Karsten42

---

Nun, die CC-Schnitte hat einen USB Anschluss. In RocRail kann die CC-Schnitte als Interface (quasi als Interface der CS2 emulation ) genutzt werden. Vor laaanger Zeit hab ich da mal in den source code hineingesehen. Hier werden die rudimentären CAN Befehle erzeugt und zum Interface ( dann also die CC-Schnitte ) geschickt. Ob die CC-Schnitte die Daten "nur" auf den CAN-BUS durchreicht oder dieser verarbeitet weiß ich nicht. Die CC-Schnitte also für ein Softwareupdate zu nutzen kann in der Software der Schnitte selbst realisiert sein oder eben in z.B. Rocrail. Aus Timing-Gründen wäre eine Speicherung der Softwarefiles aber sicher auf der CC-Schnitte notwendig.

---

Die CC-Schnitte hat schon einen USB Anschluß. Aber das dürfte kein USB Host sein, da du die CC-Schnitte an einen Computer anschließt und keine Peripherie an die CC-Schnitte. Ich denke, du kannst keinen SD Card Reader ober ähnliches an die CC-Schnitte anschließen. Da dürfte auf der CC-Schnitte auch keine Software Unterstützung vorhanden sein.

Die CC-Schnitte reicht die Daten nur durch und hat keine weitere Intelligenz. Du mußt 13 Bytes (ohne Framing! und mit einer anschließenden Pause!) über USB an die CC-Schnitte senden und die sendet das als CAN Frame weiter. Die "CS2 Emulation" ergibt sich nur dadurch, daß die CAN Frames nicht über UDP bzw. TCP verschickt werden sondern über die pseudo-serielle Schnittstelle an die CC-Schnitte. Allein kann die CC-Schnitte keine komplette CS2 emulieren. Z.B. werden die *.cs2 Dateien nicht erzeugt. Bei mir macht das ein SBC (BBB), der diese Dateien erzeugt. Die lokomotive.cs2 wird aus den Loknamen und den zugehörigen Infos erzeugt. Die *.cs2 Dateien sind auch per http abrufbar, weil die Märklin APP (Android) diese Dateien über http und nicht über CAN Frames abfragen.

Das ganze Handling des Protokolls, also vom Erzeugen der richtigen CAN Befehle bis zum richtigen Ablauf, muß dann der Computer machen, an dem die CC-Schnitte angebunden ist. Du mußt also auf deiner MCU den entsprechenden Ablauf implementieren. Da Thorsten nur eher kleine Programme erstellt, vermute ich mal, daß weitere Intelligenz nicht in die CC-Schnitte einzieht.

Zitat von Karsten42

---

Mein Entwurf ist da eher minimalistisch. Eine MCU ( jetzt eine ATMEGA1294P ), ein CAN-Controller, ein Speicher für die Software-files ( Jetzt eine SD Karte ) und ein USB Anschluss; mehr benötigt es nicht. Grundsätzlich lässt sich mit etwas erweiteter Software auch daraus eine "CC-Schnitte" bauen oder überhaupt ein Interface zu Märklin-CAN. In diesem Falle wäre mir aber eine Abstraktionsschicht sehr lieb.

---

Wenn deine MCU einen CAN Controller hat, dann könnte das eine preiswertere Lösung als mit einer CC-Schnitte geben. Mein BBB mit CAN Controller ist auch billiger als die CC-Schnitte. Eine Kombination mit SBC und CC-Schnitte wäre deutlich teurer. Wenn du auch in C programmierst, wäre es von meiner Seite aus praktisch, wenn du als Abstraktionschicht CAN Sockets unterstützen würdest. Damit arbeiten die Linux Systeme, mit denen ein Bekannter und ich "rumspielen" und man kann dann Software leichter portieren.

Tschüß
Michael

[bertr2d2]

Hallo,

ich möchte zu Michaels Beitrag noch hinzufügen, das die API SocketCAN heisst. Durch die Abstraktion, beschränkt sich der
Portierungs-Aufwand auf ein Compilieren auf der Zielarchitektur unter Linux.

Karsten, solltest Du jemals daran denken, Dein CAN-Interface über PC anzubinden , würde ich die SLCAN-API (auch Lawicel Protokoll genannt)
in betracht ziehen. Der Vorteil ist, das dieses einfache Protokoll sowohl unter Windows als auch unter Linux unterstützt wird. Rocrail hat ein
z.B. SLCAN Modul. Unter Linux gibt es scland, das wiederum das Interface über SocketCAN ansprechbar macht.
Ein Beispiel Implementierung gibt es hier: http://www.fischl.de/usbtin/

Meine Implementierung (Achtung Baustelle !) kann man hier finden: gb2-update.c

Mein Ziel ist es, das das Gleisbox Update mit jedem CAN-Interface, das von SocketCAN/Linux unterstützt wird (wie z.B. mit Michaels BBB),
gemacht werden kann. Zudem wird es auch möglich sein, das Update über das "CS2 Gateway Protokoll" zu machen.
Hier ein Beispiel für ein "CS2 Gateway Ersatz" - für Leute, die Herausforderungen mögen

Dank Karstens Hilfe (vielen Dank nochmals für den Trace und die Anmerkungen !) kann man sehr gut nachvollziehen, was notwendig ist.

Ein paar Anmerkungen zum Thema ansich (Gleisbox-Update):
Beim Trace ist aufgefallen, das die 512-Byte Blöcke beginnend Max-Blocknummer+2 bis runter auf 2 übertragen werden.
Es könnte sein, das die nicht gesendeten Blöcke 0 und 1 den CAN-Bootloader enthalten, der beim Update nicht überschrieben wird.
Nur 1024 Bytes scheinen mir aber sportlich für einen Bootloader zu sein.
Die einzelnen Blöcke werden ja mit CRC übertragen. Ich habe die Implementierung aus dem Linux-Kernel genommen, da
die Berechnung über den Algorithmus aus der M*rklins Doku bei mir nicht hingehauen hat. Zudem finde ich die Linux-Kernel
Implementierung über Lookup-Table eleganter; M*rklins iterativer Algorithmus hat was von CPU-Zyklen Verbrennung.

Gruß

Gerd

[Karsten42]

Hallo!

Danke für eure Rückmeldungen.

Gleisbox:
Auch ich tendiere dazu, die fehlenden Blöcke 0 und 1 als "freien" Raum oder als eine Art Position der gesendeten Daten im Flash anzusehen. Exaktes werden wir wohl nicht erfahren. In jedem Falle habe ich die niedrigste Blocknummer als "#define GFP_BIN_MAGIG 0x2" laufen

CC-Schnitte:
Ohhh, ich hatte nicht angenommen, das es sich um einen reinen Protokollumsetzer handelt. Dann müssen ja alle anderen "Chefs und Punkte usw " ebenfalls reines Märklin-CAN sprechen.

MS2 Updaten:
Der ATMEG1284P hat kein eigenes CAN interface. Daher der relativ einfache MCP2515 via ISP (8Mhz). Ein AT90CAN128 ist zu teuer und auch nur in TQFT und QFN zu bekommen. Das ist mir für Hobby zu klein
Ich würde schon gern die Abstraktion der Märklin-CAN Schicht viel weiter nach "oben" verschieben. So ganz sehe ich nicht den Vorteil einen kompletten Socket-Layer in eine MCU zu quetschen wenn denn nur eine Hand voll simpler Befehle für das Projekt notwendig ist.

Was benötigt die MCU minimal um mit der geladenen Software eine MS2/60113 mit Software zu betanken?

Senden der Softwarefiles in einen Speicher auf der MCU Hardware ( SD-Karte/FLASCH)
Abfrage des Softwarestandes und Hardware ( MS2 / 60113 )
Start des Update mit Vorganges
Empfangen etwaiger Fehler

Das Speichern von mehreren Versionen auf der MCU Hardware erfordet ein paar mehr Befehle, aber dass ist dann nur noch Fleißarbeit. Ich schreibe hier alles in "C" und noch sieht es einfach schrecklich aus aber funktioniert tadellos. Im Augenblick implementiere ich die notwendigen Automatismen für den Transfer der Daten zur MS2. Nach jedem Transfer von Daten an die MS2 muss diese neu gestartet werden ( System Reset->Reset-Ziel = 0xFF && wait 400ms for next cmd ) was ich ziemlich unschön finde. Es ist also egal ob eine Datei in das FS der MS2 geschrieben wird oder ob man das FLASH der MS2 neu beschreibt: reboot tut gut!


Gruß
Karsten

[st-oldie]

Hallo Karsten,

Zitat von Karsten42

---

CC-Schnitte:
Ohhh, ich hatte nicht angenommen, das es sich um einen reinen Protokollumsetzer handelt. Dann müssen ja alle anderen "Chefs und Punkte usw " ebenfalls reines Märklin-CAN sprechen.

---

Ja genau, das müssen sie. Ein Grund ist, daß jedes Gerät mit jedem kommunizieren soll bzw. die Befehle oder Statusrückmeldungen mitbekommen soll. Und das schließt auch die MS2 ein. Für ein eigenes Protokoll gäbe es noch das Problem, dieses Protokoll ohne Kollision zu den bestehenden einzubauen. Das wäre zum einen CS2/MS2 CAN und dann MS1 CAN. Beim MS1 Protokoll hat man das wohl noch nicht im Blick gehabt. Und das CS2/MS2 Protokoll benutzt im Hash für 3 Bits einen Wert, der im MS1 Protokoll nicht auftaucht, um eine Kollision zu vermeiden.

Zitat von Karsten42

---

MS2 Updaten:
Der ATMEG1284P hat kein eigenes CAN interface. Daher der relativ einfache MCP2515 via ISP (8Mhz). Ein AT90CAN128 ist zu teuer und auch nur in TQFT und QFN zu bekommen. Das ist mir für Hobby zu klein

---

Schade, das würde die Sache eigentllich vereinfachen. Und zum Thema Preis, du mußt bei einem Controller ohne CAN immer noch den Preis der CC-Schnitte hinzurechnen. Ist eine Controller mit CAN wirklich zu teuer im Vergleich zu einem Paket aus deiner Hardware und CC-Schnitte?

Zitat von Karsten42

---

Ich würde schon gern die Abstraktion der Märklin-CAN Schicht viel weiter nach "oben" verschieben. So ganz sehe ich nicht den Vorteil einen kompletten Socket-Layer in eine MCU zu quetschen wenn denn nur eine Hand voll simpler Befehle für das Projekt notwendig ist.

---

Ich denke, es erwartet keiner, daß du jetzt als Abstraktion einen Socket-Layer implementierst. Aber du könntest eine Schicht definieren, die pro CAN Frame eine Struktur vom Typ "struct can_frame" benutzt.

Die Gründe hatten wir schon genannt. Wir erwarten weniger, daß sich dann für dich deine Software leichter schreiben läßt. Wir erwarten aber, daß sich dann Software zwischen unseren Systemen und deinem System leichter portieren läßt. Vielleicht findest du in unseren Projekten etwas, das du übernehmen kannst. Genauso, wie ich den Update Algorithmus in mein System übernehmen könnte. Mein Decoder, der eine CAN Nachricht dekodiert, setzt auf diese Struktur auf, evtl. kannst du da etwas übernehmen. Es sei denn, du möchtest das selbst machen, um das selbst zu verstehen.

Tschüß
Michael

[Karsten42]

Hallo MIchael,

Zitat von st-oldie

---

Für ein eigenes Protokoll gäbe es noch das Problem, dieses Protokoll ohne Kollision zu den bestehenden einzubauen. Das wäre zum einen CS2/MS2 CAN und dann MS1 CAN.

---

Jo, das ist ja im Protokoll beschrieben. Aber da gab es etwas Verwirrung bei einigen 0x1B commands die ich im Trace hatte. Da wurde ein Hash verwendet den ich zunächt nicht zuordnen konnte. Hier die etwas programmierer freundliche Beschreibung wie der Hash in "echt" errechnet wird.
Im Übrigen hast du als hash 4711 benutzt was ja netter Weise passt. Jedoch hast du keine UID genutzt und somit ist´s nicht Protokoll konform. Der Hash sollte aus der UID geformt werden.

1
2
3
4
5
6
7
8
9
10
11
12
13
 

// -----------------------------------------------------------------------------
// Calculation HASH:
// 16Bit High UID XOR 16Bit LOW UID
// 0x4347 XOR 0x5A6B = 0x192C
// Initial Hash for command 0x1B will be 0x192c
// For other commands swap HByte with LByte and add b110 at Bit 9,8,7
//    0x2C |  0x19
// 00101100|00011001
// 00101111|00011001 = 0x2F19
#define BRIDGE_HASH	0x2F19
#define INIT_HASH		0x192C
 
 

Zitat von st-oldie

---

Schade, das würde die Sache eigentllich vereinfachen. Und zum Thema Preis, du mußt bei einem Controller ohne CAN immer noch den Preis der CC-Schnitte hinzurechnen. Ist eine Controller mit CAN wirklich zu teuer im Vergleich zu einem Paket aus deiner Hardware und CC-Schnitte?

---

Ähh verstehe ich nicht ganz was das mit der CC-Schnitte zu tun hat. Ein AT90CAN128 kostet als Einzel so um die 8-9 EUR. Eine gleichartige Alternative mit ATMEGA und MCP kostet hingegen ca. 5 EUR. Wobei es mir in jetziger Phase auf die DIL Version ankommt, da ich diese am einfachsten handhaben kann ( Steckbrett ). Das CAN Interface des AT90CAN ist auch nicht gerade simpel und hat bei mir immer wieder Probleme gemacht. Für eine Entwicklung mag ich´s lieber stabiel als elegant. Schön machen kann ich später aber währen einer Entwicklung Grundlagenforschung betreiben ist sehr anstrengend...

Zitat von st-oldie

---

Ich denke, es erwartet keiner, daß du jetzt als Abstraktion einen Socket-Layer implementierst. Aber du könntest eine Schicht definieren, die pro CAN Frame eine Struktur vom Typ "struct can_frame" benutzt.

---

Ahh, das bezieht sich dann aber auf das Interface auf dem PC. Da die Hardware über USB/seriell eine Punkt-Punkt verbindung ist sehe ich nicht die Notwendigkeit/Vorteil ein CAN-Artiges Protokoll, also 29Bit extended msg, zu nutzen. Es gibt keine Kollision, keine Priorisierung, usw. Also wäre ein Command-> Data ähnliches Protokoll wesentlich einfacher zu implementieren. Kompatibilität ist aber wichtig! Ich denke darüber nach und sehen mir deinen freundlichst zur Ansicht gestellten Code genauer an. Im übrigen fehlt das include; wie sieht denn struct can_frame aus?

So stelle ich mir das als sequenz vor.
PC Software[]---->CAN_FRAME interface--->USB/Seriell--->MCU Software[]--->CAN

Beste Grüße
Karsten

[aftpriv]

Hallo Karsten

Du hast geschrieben:

Zitat

---

PC Software[]---->CAN_FRAME interface--->USB/Seriell--->MCU Software[]--->CAN

---

ginge es auch so:

Zitat

---

PC Software[]---->CAN_FRAME interface--->LAN/WLAN--->MCU Software[]--->CAN : ?

---

Gruß

Alf

PS: entschuldige jetzt schon meine Ignoranz ops:

[Karsten42]

Moin Alfre,

Ach.. je Nun...: für eine 8Bit CPU ist das eine ziemliche Herausvorderung. Wir haben hier zwei Hürden.

1) Die Hardware die für ein LAN bzw WLAN notwendig ist, ist recht aufwändig. Es gibt fertige Hardwaremodule die man nutzen könnte um dies zu umgehen. Keine Ahnung was diese kosten und was alles sonst nocht an Hardware dafür notwendig wäre.

2) Es müsste ein completter TCP/IP stack in eine 8Bit MCU implementiert werden.

Eine sehr kurze Recherche ergab ein paar interessante fertige Libraries ( avr-uip ). Ein guter und auch richtiger Gedanke! Jedoch stelle ich weitere Betrachtungen ganz nach hinten, denn ich möchte zunächst die nahe liegenden Dinge fertig bekommen:
State machine für autharkes handling aller update-sequencen.
Code bereinigung ( alles schön macht der Frühling )
PC-command I/O
....

Und... Ich finde Anregungen/Meinungen nicht als Ignoranz

Beste Grüße
Karsten

[bertr2d2]

Hallo,

Zitat von Karsten42

---

So stelle ich mir das als sequenz vor.
PC Software[]---->CAN_FRAME interface--->USB/Seriell--->MCU Software[]--->CAN

---

Meinst du ggf : PC Software[]--->USB/Seriell--->MCU Software[]--->CAN ?
Wenn Du als serielles Protokoll [Seriell<--->MCU Software] die SLCAN-API verwendest, kannst Du Deinen
Adapter universell einsetzen: Rocrail unterstützt dies z.B. Und eben auch Linux …

Aber Standalone Geräte (MCU ohne oder mit Display) haben natürlich auch Ihren Charme insbesondre für
Stummi-Stammtische

Zitat von aftpriv

---

PC Software[]---->CAN_FRAME interface--->LAN/WLAN--->MCU Software[]--->CAN : ?

---

Daran programmiere ich gerade. D.h. die Software wird sowohl direkt über das CAN-Interface (SocketCAN):

1
 

Linux PC Software[]--->CAN Interface --->Gleisbox
 

als auch über LAN/WLAN

1
 

Linux PC Software[]--->LAN/WLAN--->Router/CAN Interface --->Gleisbox
 

(CAN Frames eingepackt in Ethernet Frames) Updates machen können. Das Ethernet-Format entspricht dem M*rklin CAN in
Ethernet Format.
Aber ich muss erst noch ein paar CAN-Router zusammenschrauben

Zitat von Karsten42

---

2) Es müsste ein completter TCP/IP stack in eine 8Bit MCU implementiert werden.

---

Uiii, das ist aber für einen 8bitter mit 20MHz schon ein ziemlich dickes Brett zu bohren … Geht (gibt ja genug Beispiele wie z.B.
AVR-Netio), aber das is wirklich am Rande (oder drüber) der Performance für so eine MCU.

Gruß

Gerd

[Karsten42]

Moin Gerd,

Zitat von bertr2d2

---

Meinst du ggf : PC Software[]--->USB/Seriell--->MCU Software[]--->CAN ?
Wenn Du als serielles Protokoll [Seriell<--->MCU Software] die SLCAN-API verwendest, kannst Du Deinen
Adapter universell einsetzen: Rocrail unterstützt dies z.B. Und eben auch Linux …

---

Ja, ist aber das gleiche. Die Serielle/USB ist nur der Physikalische Layer.

Als Stand alone Gerät ist das vielleicht nicht zielführend? Wenn jemand eine MS2 hat kann er diese ja mitnehmen um anderen damit deren Software auf Stand bringen. Ich dachte dies eigentlich für die vielen vielen die ein single-Dasein fristen. Ein Vorteil ist aber unbestritten für ein Stand-Alone: Man kann auch ein downgrade machen um eventuellen "Verschlimmbesserungen" entgegenwirken zu können.

Die PC software muss ja auch noch mal in den M?rklin Updaterechner schauen und sich von dort die neuesten ( oder alte ) software holen und diese dann zur MCU laden. Das kommt aber später.

Hier mal ein kurzes Timing für das Update der 60113:

1
2
3
4
5
6
 

     13ms                    44us                               419ms            44us
|------------|----xx----|----------|----update window------|---------------|------------|
PWR        CAN        0x1B        0x1B                    0x1B            0x18         0x18
on        active     DLC=0        DLC=8                   DLC=5           DLC=0        DLC=8
 
 

Das mit dem Hash aus UID berechnen würde ich nicht unterschätzen. Bei MS2 <--> MS2 wird davon gebrauch gemacht.

Ich hoffe es hilft etwas

Gruß
Karsten

[bertr2d2]

Hallo Karsten,

Zitat von Karsten42

---

Moin Gerd,
....
Hier mal ein kurzes Timing für das Update der 60113:

1
2
3
4
5
6
 

     13ms                    44us                               419ms            44us
|------------|----xx----|----------|----update window------|---------------|------------|
PWR        CAN        0x1B        0x1B                    0x1B            0x18         0x18
on        active     DLC=0        DLC=8                   DLC=5           DLC=0        DLC=8
 
 

---

Aus der Skizze werde ich noch nicht so ganz schlau. Heisst das, das man ca. 420 ms Zeit hat,
um den Updateprozess anzustossen ?

Zitat

---

Das mit dem Hash aus UID berechnen würde ich nicht unterschätzen. Bei MS2 <--> MS2 wird davon gebrauch gemacht.

---

Die Hash-Betrachtung habe ich bisher gar nicht gemacht. Gibt es eine spezielle "Berechnung" abgesehen
von der aus der M*rklin Doku ?

Zitat

---

Ich hoffe es hilft etwas

Gruß
Karsten

---

Vielen Dank und Gruß

Gerd

[Karsten42]

Moin Moin Gerd,

Na, ich bin bei dem Wetter im Keller am hacken... wenn das meine Frau sieht...

1
2
3
4
5
6
 

     13ms                    44us                               419ms            44us
|------------|----xx----|----------|----update window------|---------------|------------|
PWR        CAN        0x1B        0x1B                    0x1B            0x18         0x18
on        active     DLC=0        DLC=8                   DLC=5           DLC=0        DLC=8
 
 

Sorry, ich hab die Erklärung vergessen
Nach PWD-On und 13ms startzeit, antwortet die 60113 auf CAN Daten. Das xx zeigt eine beliebige Zeit an, in der gewartet werden kann. Ich nutze hier die M?rklin standard Wartezeit von 420ms. Die Zeit für das "update window" ist unbestimmt. Nach dem Response 0x1B DLC=8 wartet die 60113 auf das Start-Datagram 0x1B DLC=5. Ob es hier ein Timeout gibt weiß ich nicht. Es wäre unwahrscheinlich, da die 60113 erst mit dem folgenden 0x1B DLC=5 Kommando gestartet wird. Die MS2 wartet jedoch nach dem senden des Start-Datagram 420ms mit dem ersten "Betriebs Befehl" 0x18 DLC=0. Alle folgenden Befehle sind erst nach dem Response des 0x18 DLC=0 beobachtet. Ich denke das soll so eine Art Startzeit für das Betriebsprogramm sein. Zwar reichlich lang, aber es stört ja auch kaum.

Zitat

---

Die Hash-Betrachtung habe ich bisher gar nicht gemacht. Gibt es eine spezielle "Berechnung" abgesehen
von der aus der M*rklin Doku ?

---

Weiter "oben" im Thread ist eine Kurzanleitung zu finden ( ein Auszug aus einem include file ). Der "Kniff" ist das Byte-Swapping das nicht beschrieben ist. Es gibt aber eine "Systematik" bei den ersten beiden Bytes der UID der man vielleicht folgen sollte um Kollisionen mit M?rkling Hardware zu vermeiden.

MS2 ---> 0x4d 0x54
60113 ---> 0x47 0x43
60174/ CS2 ---> 0x43 0x53

Eigene Applikationen sollten also tunlichst weit außerhalb dieser Bereiche liegen.

Gruß
Karsten

[st-oldie]

Hallo Karsten,

Zitat von Karsten42

---

Jo, das ist ja im Protokoll beschrieben. Aber da gab es etwas Verwirrung bei einigen 0x1B commands die ich im Trace hatte. Da wurde ein Hash verwendet den ich zunächt nicht zuordnen konnte. Hier die etwas programmierer freundliche Beschreibung wie der Hash in "echt" errechnet wird.
Im Übrigen hast du als hash 4711 benutzt was ja netter Weise passt. Jedoch hast du keine UID genutzt und somit ist´s nicht Protokoll konform. Der Hash sollte aus der UID geformt werden.

---

Das ist mit klar und das findest du auch in meinem Code. Der Spaß mit der 4711 ist nur im "Magic Start" drin, den ich von einer anderen Software übernommen hatte. Und da leider der Befehl 0x1B nicht dokumentiert ist, hab ich da nichts geändert sondern das so übernommen.

Zitat von Karsten42

---

Zitat von st-oldie

---

Schade, das würde die Sache eigentllich vereinfachen. Und zum Thema Preis, du mußt bei einem Controller ohne CAN immer noch den Preis der CC-Schnitte hinzurechnen. Ist eine Controller mit CAN wirklich zu teuer im Vergleich zu einem Paket aus deiner Hardware und CC-Schnitte?

---

Ähh verstehe ich nicht ganz was das mit der CC-Schnitte zu tun hat. Ein AT90CAN128 kostet als Einzel so um die 8-9 EUR. Eine gleichartige Alternative mit ATMEGA und MCP kostet hingegen ca. 5 EUR. Wobei es mir in jetziger Phase auf die DIL Version ankommt, da ich diese am einfachsten handhaben kann ( Steckbrett ). Das CAN Interface des AT90CAN ist auch nicht gerade simpel und hat bei mir immer wieder Probleme gemacht. Für eine Entwicklung mag ich´s lieber stabiel als elegant. Schön machen kann ich später aber währen einer Entwicklung Grundlagenforschung betreiben ist sehr anstrengend...

---

Wenn ich das richtig verstanden habe, schließt du an deine MCU die CC-Schnitte an, die wiederum am CAN Bus (Gleisbox oder CDB-Projekt) angeschlossen ist. Wenn du einen Controller mit CAN Controller verwendest, schließt du deine MCU direkt an den CAN Bus an.

Zitat von Karsten42

---

Zitat von st-oldie

---

Ich denke, es erwartet keiner, daß du jetzt als Abstraktion einen Socket-Layer implementierst. Aber du könntest eine Schicht definieren, die pro CAN Frame eine Struktur vom Typ "struct can_frame" benutzt.

---

Ahh, das bezieht sich dann aber auf das Interface auf dem PC. Da die Hardware über USB/seriell eine Punkt-Punkt verbindung ist sehe ich nicht die Notwendigkeit/Vorteil ein CAN-Artiges Protokoll, also 29Bit extended msg, zu nutzen. Es gibt keine Kollision, keine Priorisierung, usw. Also wäre ein Command-> Data ähnliches Protokoll wesentlich einfacher zu implementieren. Kompatibilität ist aber wichtig! Ich denke darüber nach und sehen mir deinen freundlichst zur Ansicht gestellten Code genauer an. Im übrigen fehlt das include; wie sieht denn struct can_frame aus?

So stelle ich mir das als sequenz vor.
PC Software[]---->CAN_FRAME interface--->USB/Seriell--->MCU Software[]--->CAN

---

Dann hab ich deine Idee komplett missverstanden.

Die Kommunikation PC - CC-Schnitte dürfte mit dem Märklin Protokoll schneller in bestehende Software zu implementieren sein, die auch das CS2 Ethernet Protokoll sprechen. Und das sind auch nur die 13 Bytes eines CAN Frames. Damit muß man nur noch die 13 Bytes statt auf Ethernet auf die CC-Schnitte ausgeben. Ich denke, daß könnte ein Grund sein. Ein weiterer Grund dürfte sein, daß es die Firmware der CC-Schnitte deutlich vereinfacht.

Ich hatte angenommen, daß du nur die folgenden Sequenz hast:

CAN -- CC-Schnitte -- MCU

was du bei einer MCU mit CAN durch

CAN -- MCU

ersetzen kannst.

Ist bei deiner Skizze oben nicht die Schnittstelle MCU - CAN die CC-Schnitte? Ich bin gleich von einer Stand-Alone Lösung ausgegangen. Ich würde aber auch nicht den Sinn sehen, am PC nochmals Intelligenz anzuschließen. Mit einem entsprechenden Programm und einem CAN-USB Interface sollte man eigentlich auch eine Update Lösung erstellen könne. Eine weitere Intelligenz sollte nicht nötig sein.

Tschüß
Michael

[st-oldie]

Hallo Karsten,

Zitat von Karsten42

---

Es gibt aber eine "Systematik" bei den ersten beiden Bytes der UID der man vielleicht folgen sollte um Kollisionen mit M?rkling Hardware zu vermeiden.

MS2 ---> 0x4d 0x54
60113 ---> 0x47 0x43
60174/ CS2 ---> 0x43 0x53

Eigene Applikationen sollten also tunlichst weit außerhalb dieser Bereiche liegen.

---

Da definiert doch die Märklin Doku Bereiche, wenn ich das jetzt richtig im Kopf habe. Da gibt es auch einen Bereich, in dem z.B. Vereine o.ä. liegen. Und einen Bereich für PC Software.

Tschüß
Michael

[bertr2d2]

Hallo Karsten,

Zitat von Karsten42

---

Moin Moin Gerd,

Zitat

---

Die Hash-Betrachtung habe ich bisher gar nicht gemacht. Gibt es eine spezielle "Berechnung" abgesehen
von der aus der M*rklin Doku ?

---

Weiter "oben" im Thread ist eine Kurzanleitung zu finden ( ein Auszug aus einem include file ). Der "Kniff" ist das Byte-Swapping das nicht beschrieben ist. Es gibt aber eine "Systematik" bei den ersten beiden Bytes der UID der man vielleicht folgen sollte um Kollisionen mit M?rkling Hardware zu vermeiden.

---

Ups, sorry habe ich überlesen.

Zitat

---

MS2 ---> 0x4d 0x54
60113 ---> 0x47 0x43
60174/ CS2 ---> 0x43 0x53

Eigene Applikationen sollten also tunlichst weit außerhalb dieser Bereiche liegen.

Gruß
Karsten

---

Vielen Dank für den Hinweis. Michael hat auch drauf hingewiesen, das es Bereiche für andere Hersteller/eigene Erweiterungen
von Märklin vorgesehen sind. IMHO reicht es aber darauf zu achten, keine doppelten Hashes zu verwenden.
Ich glaube nicht, das eine Gleisbox/MS2 wirklich darauf achtetet, was ein Typ von Gerät auf der Gegenseite Anweisungen gibt.
Hauptsache beim Hash sind die Bits 0x0300 gesetzt und mit einer Maske 0xff7F Und verknüpft.

Gruß

Gerd

P.S.: Das "Mysterium" um die Blöcke 0 und 1 (1024 Bytes) beim Update der Gleisbox ist gelöst. Es handelt sich hier
aller Wahrscheinlichkeit um den (CAN-) Bootloader. Das Update-File wird ab Adresse 0x0400 abgelegt.

[Karsten42]

Moin Moin Michael und Gerd,

Schon wieder zu gutes Wetter für den keller... eigentlich

Zitat von st-oldie

---

Dann hab ich deine Idee komplett missverstanden.

---

Nee, ich habe mein Projekt ja noch gar nicht wirklich in Einzelheiten vorgestellt. Ganz simples Hardware modell:

PC--->USB--->MCU--->CAN

In der MCU wird der komplette Ablauf eines Updates für die MS2 und 60113(Gleisbox ) verarbeitet. Dies läuft im Augenblick automatisch ab sobald ein Gerät an den 10Poligen M?rklin CAN Anschluss angesteckt wird und mehr als 30mA Strom benötigt. Die Update-files sind in einer SD Karte gespeichert die die MCU ausliest.
Die "Intelligenz" sitzt also in der MCU. Der USB ist nur dafür gedacht später die update Sequenz über Abfragen startbar zu machen und die Update-Files auf einen Flasch-Speicher zu laden. Wie das Protokoll aussieht um diese simplen Funktionen an die MCU zu übertragen weiß ich noch nicht. Ich dacht ein ein SIS. Z.B. das Kommando "UP." für den start einer Updatesquenz oder "GS." für die Abfrage des Softwarestandes des angeschlossenen Gerätes um eine Auswahl zu treffen auf welchen Softwarestand das Gerät verändert werden soll.
Also keine CC-Schnitte oder ähnliches. Die Frage tauchte nur im anderen Thread auf mit der Idee die CC-Schnitte softwaremäßig mit den Updatefunktionen zu erweitern. Da die CC-Schnitte im Wesentlichen "nur" ein Umsetzer ist, wäre es duchaus möglich ein Softwareupdate über die CC-Schnitte an ein Gerät zu leiten.

Zum Thema Hash:
Solange wir keine weiteren Geräte von M?rklin am Bus haben ist´s wohl egal mit welcher UID/Hash kombination Daten übertragen werden ( UID = 0 ist ja Broadcast ). Ich gehe zunächst davon aus das alle möglichen und zukünftigen Geräte von M?rklin gleichzeitig und mehrfach am Bus hängern und gierig auf meine gesendeten Daten hören Daher meine kleine Paranoia bezüglich "korrektem" hash und UID.
In der Doku ist der Bereich für Firmen usw aber leider NICHT auf die UID gemünst sondern auf die Loc-ID ( Siehe Systembefehlt 0x00/Sub-CMD Lok Halt ) die ja Protokollabhängig ist.

Bemerkung zur Blocknummer für das flashupdate gelöscht. Gerd hat hier Visionäre Arbeit geleistet!

Beste Grüße
Karsten

[st-oldie]

Hallo Karsten,

Zitat von Karsten42

---

Zitat von st-oldie

---

Dann hab ich deine Idee komplett missverstanden.

---

Nee, ich habe mein Projekt ja noch gar nicht wirklich in Einzelheiten vorgestellt. Ganz simples Hardware modell:

---

naja, ich hab (meisten) für Technik eine gute Auffassungsgabe. Und interpretiere die Anfänge einer Erklärung (meistens) richtig fort.

Zitat von Karsten42

---

PC--->USB--->MCU--->CAN

In der MCU wird der komplette Ablauf eines Updates für die MS2 und 60113(Gleisbox ) verarbeitet. Dies läuft im Augenblick automatisch ab sobald ein Gerät an den 10Poligen M?rklin CAN Anschluss angesteckt wird und mehr als 30mA Strom benötigt. Die Update-files sind in einer SD Karte gespeichert die die MCU ausliest. ...

---

Ja, das wäre das, was ich dir ansonsten auch geraten hätte. Intelligenz in der MCU. Und dann ist der PC nur zum "Betanken" mit updates files und zu Start. Für das Protokoll zum PC bist du da natürlich komplett frei. Da sehe ich auch nichts sinnvolles, das man übernehmen müßte.

Die CC-Schnitte wird wahrscheinlich nie eine solche Update Funktion bekommen. Kann aber verwendet werden, wenn USB und kein CAN zur Verfügung steht und an den CAN Bus angeschlossen werden soll.

Zitat von Karsten42

---

Solange wir keine weiteren Geräte von M?rklin am Bus haben ist´s wohl egal mit welcher UID/Hash kombination Daten übertragen werden ( UID = 0 ist ja Broadcast ). Ich gehe zunächst davon aus das alle möglichen und zukünftigen Geräte von M?rklin gleichzeitig und mehrfach am Bus hängern und gierig auf meine gesendeten Daten hören Daher meine kleine Paranoia bezüglich "korrektem" hash und UID.
In der Doku ist der Bereich für Firmen usw aber leider NICHT auf die UID gemünst sondern auf die Loc-ID ( Siehe Systembefehlt 0x00/Sub-CMD Lok Halt ) die ja Protokollabhängig ist.

---

Ich hab jetzt auch nochmals in der Doku gelesen. Stimmt, die local ID ist für Protokolle und deckt dne Wertebereich von 0x0001 bis 0x3fff ab, darüber liegen MFX, SX2 und DCC und die Geräte haben einen Wertebereich von größer 0xffff. Da hatte ich mir das wohl falsch gemerkt. Aber es steht ja auch in der Erklärung des Hash, daß bei einer Kollision ein anderer Hash zu verwenden ist. Was eigentlich bedeutet, eine andere UID gewählt werden muß. (wegen kleinerem Wertebereich eines Hashs können auch unterschiedliche UIDs zum gleiche Hash führen).

Zitat von Karsten42

---

Bemerkung zur Blocknummer für das flashupdate gelöscht. Gerd hat hier Visionäre Arbeit geleistet!

---

Ja, den solltest du dir für solche Themen warm halten. Da bastelt er gern und hat auch etwas Wissen.

Tschüß
Michael

[bertr2d2]

Hallo,

ich habe zum ersten Mal erfolgreich meine Gleisbox mit einem CAN-Adpater upgedated. Das ging recht flott in knapp 13 Sekunden. Ich werde den Code noch etwas bereinigen und dann können Mutige es versuchen. Zur Beruhigung: ist gibt noch einen Fallback sollte wider Erwarten das Update nicht funktioniert haben.

Voraussetung für das normale Update ist ein von Linux unterstütztes CAN-Interface (Stichwort SocketCAN).

Nach dem Update ist mir aufgefallen, das es einen Unterschied des Flashes gibt:
(links original - rechts nach Update)

der aber IMHO nicht bedeutend ist. Die Änderungen befinden sich überwiegend im verschobenen Interrupt Vektor Bereich und betreffen Zellen,
die nicht angesprochen bzw. angesprungen werden. Zumindest bemerke ich von der Funktion der Gleisbox keinen Unterschied.

Gruß

Gerd

[bertr2d2]

Hallo,

kleines Update um zu zeigen, das die Sache nicht eingeschlafen ist. Die Gleisbox-Update Funktion ist nun soweit,
das man sie benutzen kann. Ich habe ein paar Fehler-Szenarien durchgespielt; der Mechanismus ist so robust, das ein
Update nur ein geringes Risiko darstellt. Zudem gibt es mit c2tool einen funktionierenden Fallback, sollte das
Gleisbox-Update in die Hose gehen.

Voraussetzung zu Nutzung von gb2-update ist ein Linux System mit einem von SocketCAN unterstütztem CAN Interface
(z.B. BBB, CAN-Router etc).

Aus meiner Sicht ist das Update der MS2 noch nicht robust genug bzw. zu wackelig und der Fallback zu aufwändig.

Karstens Standalone Lösung geht einen anderen Weg. Soweit ich wess, arbeitet er aber auch noch kräftig an seiner Lösung

Gruß

Gerd

[bertr2d2]

Hallo,

ich habe vorgestern mit Erstaunen festgestellt, das M*rklins PC-Software sogar ein Software-Update meiner
MS2(war Version 1.81) vorgeschlagen hat Hier mein Aufbau:

1
 

MS2 - Gleisbox - CAN-Router (mit can2lan) - PC (M*rklin PC-Software als CS2 Master)
 

Das Update hat einwandfrei funktioniert (jetzt V2.5). Ich bin immer mehr von M*rklins PC-Software überzeugt
BTW: can2lan läuft auf jedem Linux Rechner mit CAN-Interface (SocketCAN) wie z.B Beaglebone Black.

Gruß

Gerd