Hallo zusammen, Atmega16 AVRStudio C-Code Es geht um die Kommunikation + Programmierung + Spannungsversorgung über insgesamt 2 Adern. Dabei lesen bereits eigene Modellbahndekoder das +-20V DCC-Signal vom Gleis aus und versorgen sich auch darüber. Nun war das bisherige Konzept so, dass die Informationen während des Betriebs zwar vom Gleis kommen, der uC aber immer über einen Stecker programmiert+upgedated werden muss. in meinem letzten Thread wurde ich dann auf das Thema "Bootloader" aufmerksam gemacht, weshalb ich nun das Tutorial auf dieser Seite durchgearbeitet habe. https://www.mikrocontroller.net/articles/AVR_Bootloader_in_C_-_eine_einfache_Anleitung Die Problemstellung ist: UART benötigt 2Adern + ein gemeinsames Bezugspotential, welches ich nicht habe. Anbei auch meine bisherige Schaltung der Signalanpassung+Versorgung zur weiteren Lösungsfindung. Fragen: Wie (Hardware+Software) würdet ihr eine Programmierung über die 2 Adern realisieren? Das ganze muss bidirektional laufen, damit der zum programmieren ausgewählte Dekoder sich auch zurückmelden kann. PS: Es hängen viele Dekoder (>50stk.) am Bus.. Mir fehlt dazu die Grundidee, da mir irgendwie eine Ader fehlt... Der Controller muss sich während der Rückmeldung ja auch noch selbst versorgen.. Das einzige was mir im "Programmiermodus" einfällt: Empfangen Das empfangen kann dann mit der aktuellen Signalanpassung erfolgen ? Dazu werden die beiden Adern zu: 1: TXD vom PC 2:GND Das angepasste DCC-Signal wird zusätzlich auf RXD gelegt ? Senden Da der Controller sich während des sendens noch versorgen muss, werden die Adern auf Dauerspannung geschaltet. Die Signalübertragung erfolgt dann mittels Stromänderung (uc schaltet Last im Signaltakt zu) Ich kenne mich zugegeben noch nicht mit UART aus. Wird "TXD" NUR beim senden und "RXD" NUR beim empfangen benötigt? Oder werden dauerhaft beide Leitungen für die Kommunikation benötigt. Über die genaue Schaltung und Umsetzbarkeit meiner Überlegung habe ich noch nicht nachgedacht.. Was wären eure Gedanken dazu? Danke!!!
Angehängte Dateien:
-
DCC-Anpassung.png
7,2 KB
Philipp L. schrieb: > Was wären eure Gedanken dazu? Wenn ich das vorhandene richtig verstehe, steckt die Information in der Polarität der Versorgungsspannung. Das ist so nicht auf Duplex umbaubar, weil ja die Versorgung vom Master kommt, also kann der Slave nicht die Polarität umschalten. Es wird ein ganz anderes Konzept benötigt. Da nur 2 Leitungen zur Verfügung stehen, muss die Information auf die Vcc-Leitung aufmoduliert werden, dafür gibt es verschiedene Möglichkeiten. Ältere werden sich noch an das Piepen von Fax und Modems erinnern, man kann solche Tonfrequenzen der Versorgungsspannung überlagern, und das kann auch der Slave. Bloss nicht beide gleichzeitig, also nur Halbduplex, aber das ist ja kein Problem. Übrigens gibt es Uralt-Technik, die so etwas kann: das gute alte Telefon stellt mit dem Schleifenstrom eine Versorgung zur Verfügung, und die Sprache wird in beide Richtungen übertragen. Georg
Mit dem Uart und fertigen bootlader wird das nichts. eher kann man mittels dcc und railcom das firmwareimage in einen extra flashbereich im decoder laden und dann von dort flashen.
Flip B. schrieb: > Mit dem Uart und fertigen bootlader wird das nichts. eher kann man > mittels dcc und railcom das firmwareimage in einen extra flashbereich im > decoder laden und dann von dort flashen. War auch mein erster Gedanke. Image mit z.B. POM übertragen und Rückkanal über RailCom. Ist beides Standard und dokumentiert. Die Frage ist nur, ob Du wirklich auf dem Hauptgleis FW-Update machen willst. Das hat viel Potential für Kollateralschaden
Übrigens zum Schaltplan: DCC sind keine 20V! Das können sie sein, aber der legale Bereich geht von irgendwo 12V bis irgendwo 28V. Genaue Grenzen weiß ich gerade nicht auswendig, mußt Du NMRA befragen. D.h. Du solltest unbedingt die Gate-Spannung vom FET begrenzen.
> Mit dem Uart und fertigen bootlader wird das nichts. eher kann man > mittels dcc und railcom das firmwareimage in einen extra flashbereich im > decoder laden und dann von dort flashen. Die Idee ist nicht schlecht, nur die HW+SW Umsetzung ist mir noch nicht klar. - Wie bekomme ich die hex-file auf das dcc-Signal und vom "raicom" wieder zurück in den PC? HW: Der "ESU-Lok-Programmer" läuft mit einem USB-Seriell Wandler. Ich schaue mal mit dem Oszi was dieser auf der dcc Seite macht, wenn ich ihm einfach ein Signal über "putty" sende. Dann sende ich eine railcom Rückmeldung und schaue mit putty drauf? Denn der lok-Programmer ist für mich ja aktuell eine "black-box" ich weiss nicht, in welcher Form die daten vom pc an den Programmer gesendet/empfangen werden müssen. Oder werde ich in jedem fall eine eigene Hardware als Bindeglied zwischen PC und DCC für die Programmierung benötigen? SW: Hier werde ich dann aber anstatt putty vermutlich eine komplett eigene software auf dem PC benötigen? > Image mit z.B. POM übertragen habe mich bisher noch nicht mit POM befasst. Können hier bereits mehrere Geräte dran hängen und die zu flashende Adresse ausgewählt werden? Oder muss ich dies mit einer eigenen Software auf uc+pc realisieren? denn beim programmieren von loks darf ich bisher nur DIE EINE zu programmierende lok auf dem programmiergleis haben. > Die Frage ist nur, ob Du wirklich auf dem Hauptgleis FW-Update machen > willst. Das hat viel Potential für Kollateralschaden Nein, nicht auf dem Hauptgleis. Alle unsere Zubehördekoder hängen auf einem eigenen dcc-bus. Aber ja.. ich möchte auf dem bus programmieren, auf dem alle zubehördekoder hängen. Daher muss sichergestellt sein, dass nur der "ausgewählte" dekoder geflasht wird...
:
Bearbeitet durch User
Von HEX auf DCC geht z.B. über POM. Bei POM sagst Du der Zentrale, daß die Lok Nr x in CV y den Wert z schreiben soll. Das ganze läuft auf dem Hauptgleis während des Betriebs. Über die CVs muß Dein Dekoder entscheiden, was er machen soll. Brauchst halt ein Konzept, wie Du die FW über CVs verschiebst. RailCom zurück an PC hängt stark von der Zentrale ab. Da kann ich Dir nicht helfen, da meine Zentralen alle Eigenbauten sind. Am ehesten könnte ich mir das Feature bei den Jungs von der Fichtelbahn vorstellen - die haben echt was auf dem Kasten! BiDiB definiert glaube ich zumindest die Möglichkeit. Ggf noch bei Tams nachfragen, der scheint da auch sehr aktiv zu sein (wenn seine Geräte laufen, sind die echt Klasse. Wenn nicht ... so bin ich bei Eigenbau gelandet ;) ) Wenn Du sowieso ein Programmiergleis hast, auf dem nur der eine Dekoder steht, dann kannst Du aber auch beliebig die Spannung modulieren. Mußt nur Leistung+Daten übertragen und zwischendurch ein Cutout für den Rückkanal a la RailCom. P.S. Du arbeitest nicht zufällig in der Moba-Firma gleichen Namens?
> Von HEX auf DCC geht z.B. über POM. Bei POM sagst Du der Zentrale, daß > die Lok Nr x in CV y den Wert z schreiben soll. Ich dachte, dass ein CV immer nur ein Wert (1Byte) und keine ganzes hex-File ist. Gibt es dazu irgendwo eine gute Beschreibung? -Wie sieht das Protokoll (DCC-Signal) genau aus, wenn ich auf Lokadr-1 bei CV-5 ein ganzes hex-File zum Firmwareupdate übertrage ? Diese Info benötige ich ja, um den uC passend zu programmieren. Da sage ich ihm doch, dass er beim empfang von cv-5 ein neues Programm erhält. > Wenn Du sowieso ein Programmiergleis hast, auf dem nur der eine Dekoder > steht, dann kannst Du aber auch beliebig die Spannung modulieren. Dieses Programmiergleis habe ich nur aktuell für die Tests und die Entwicklung. Später sind die ganzen Dekoder in der Anlage verbaut (Häuser,Kräne,usw..). Daher sollen diese ja im eingebauten Zustand programmiert werden können. > P.S. Du arbeitest nicht zufällig in der Moba-Firma gleichen Namens? Nein, ist alles rein privat. Mir gefallen nur die aktuellen dekoder (und preise) nicht, daher muss ein eigener her :-) Der funktioniert ja auch schon sehr gut, aber programmieren im eingebauten zustand wäre schon super..
Die Motivation kommt mir bekannt vor ;) Das Signal von DCC ist sehr gut von der NMRA beschrieben. Da mußt Du Dich einfach mal durch die Normen durcharbeiten. Ist am Anfang etwas erschlagend, aber eigentlich ganz logisch aufgebaut. Physikalische Schicht, Symboldarstellung und darauf aufbauend dann die einzelnen Pakete. CV ist tatsächlich immer nur 8bit. Dafür hast Du viele davon. :) Könntest ja z.B. eine CV zur Aktivierung des Update-Modus und dann eine weitere, in das die Daten reingestreamt werden. Absicherung mußt Du Dir entsprechend überlegen (CRC?) RailCom definiert da meines Wissens auch eine mögliche Bestätigung des Dekoders pro Schreibvorgang. Das könntest Du parallel zur Zentrale abgreifen.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.