Hallo. Ich bin auf der Suche für die Steuerung eines Weichenstellpultes über Tasten für meine Gartenbahn die mit einer Lenz-Digital Plus Steuerung und Zimo Weichendecoder gesteuert wird. Problem ist die umständliche Bedienung über die Handsteuergeräte. Eine PC-Steuerung möchte ich grundsätzlich nicht verwenden. Mein Wunsch wäre eine Tastensteuerung auf die Eingängne eines Microcontrollers der über den X-Bus (RS485) die entsprechenden Schaltbefahle an die Zentrale weitergibt. Hat jemand so etwas bereits realisiert?. Mit freundlichen Grüssen J. Öttl
Hallo Josef, nein, realisiert habe ich soetwas noch nicht, aber es geistert mir bereits seit längerem im Kopf herum. Ich habe bereits einen eigenen Handregler "geplant" und prinzipiell ist ein Weichenkeyboard an einer Lenz-Zentrale da ja auch nicht viel anders. Grundlage für die Software müsste dabei das von Lenz recht ordentlich dokumentierte XPressNet-Protokoll sein. Dort kann man recht gut erkennen, mit welchen Befehlen die Zentrale die Handregler abfragt usw. Ist ein ganzes Stück Arbeit, aber keine Hexerei. Leider habe ich bisher noch keine Lenz-Zentrale zur Verfügung (die Dinger sind ja nicht gerade billig, auch nicht gebraucht) und so existiert das Ganze bisher nur auf dem Paier und in meinem Kopf. Ich habe auch schon daran gedacht, eine Zentrale für DCC selbst zu programmieren, aber das ist bisher auch ersteinmal nur eine Idee (wer eine "fertige" Lösung kennt...). Jörg
hallo Plitzi. Erstmal vielen dank für die Rückantwort. Grundsätzlich dürfte es keine allzu grossen Ürobleme geben so etwas zu realisieren, da ja nur in eine Richtung gesendet wird. wie du ja anmerkst, ist das x-bus Protokoll sehr gut dokumentiert. Man könnte die schaltbefehle ja auch mit einem oszi rausbekommen. sich ändernde Parameter sind ja letztendlich nur die Weichenadresse. Leider habe ich kein Oszilloskop und keine Ahnung, wie ich eine RS485 Busverbindung realisieren kann. Treiberbaustein usw. max485 ist klar. Mein Gedanke geht hier Richtung Atmel Atmega. Mit diesem MC kenne ich mich etwas aus. Wo aber der RS485 Bus angeschlossen wird (RXD/TXD) ist mir nicht klar, da diese Anschlüsse ja bereits zur Programmierung benötigt werden. oder sehe ich das falsch. Diesbezüglich sind meine Hardwarekenntnisse etwas dürftig. Gruss Josef
Ich habe mal meinen Entwurf für einen Handregler als XPressNet-Gerät angehängt (gibt es bisher nur auf Papier). Dort ist die Realisierung der RS485 zu erkennen. Als Weichenstellpult würde das Poti entfallen. Das Protokoll an sich braucht man aber nicht "abzulauschen" da es ja dokumentiert ist. Ich habe aber wie gesagt bisher noch keine Zeit und Gelegenheit gehabt, das Ganze ernsthaft anzugehen. Aber vielleicht hilft Dir ja der Schaltplan schon mal weiter;) Jörg
Hallo Jörg. Danke für die prompten Antworten und für Deinen Entwurf. Ich werde mir das mal in Ruhe anschauen. Josef
Eine andere Möglichkeit wäre die Verwendung des Lenz Interface LI100 (gebraucht preiswert, da bereits zwei Nachfolger existieren), welches die Umsetzung von RS-232 auf RS-485 schon erledigt. µC macht die Tastenabfragen und sendet an der seriellen Schnittstelle (und bekommt dann auch die Rückmeldung als Broadcast). Thomas
hallo topla, habe ich mir auch schon überlegt. Ich habe ein Interface. Modern wie ich bin, aber in der usb-Ausführung. Ich habe meinem Atmega32 deshalb einen max 485 spendiert und vesuche momentan in Bascom die paar Befehle zum Schalten meiner Weichen der Zentrale beizubringen. Eigenartigerweise funktioniert das Ganze an meiner Compact. Die Zentrale LVZ100 bringt mir jedoch immer die Fehlermeldung "Transfer Error" obwohl die Schaltbefehle am LS100 ankommen. Mir fällt nur auf, das die LED am LS100 nicht mehr ausgeht. Teste ich das ganze mit der Handsteuerung, sehe ich, dass die Bus-LED am LS100 solange brennt, bis ich die Taste wieder loslasse. Am Atmel-Display sehe ich, dass beim Loslassen sofort eine anderer Befehl kommt. Beispiel: Senden Weiche 1 - ein (Taste gedrückt) - Code 52 00 89 DB Taste losslassen: 52 00 81 D3 anschl. sehe ich eigentlich nur noch das Polling der RS485 Adressen. Offensichtlich ist es ein Timing-Problem zwischen Atmel und Lenz Zentrale. In der englische Beschreibung des Protokolles sehe ich nicht genau, wie das Handling zwischen Empfang und Senden ausschauen muss. Eventuell liegt es jedoch auch meinen beschränken Englischkennissen. Josef
Hmm, ich beschäftige mich gerade mit der Weiterentwicklung des LW100 und habe da gerade mal über den Code für den XBUS-Verkehr geschaut. Deine Fehlermeldung scheint die Ursache in einer fehlerhaften Prüfsumme zu haben, zumindest sagt das die Doku. Entzerre doch mal die Sendefolge, also beim Sendeinterrupt eine kleine Zeitschleife (NOP) einfügen und auch das Umschalten auf Sendebetrieb nicht zu schnell erledigen. Das LW100 ist da ziemlich umständlich programmiert und es geht gemütlich zu (DS80C320 mit 4MHz). Den zweiten Befehl, also das Ausschalten des LS100-Ausgangs beim Loslassen der Taste, sendest Du aber auch an die Zentrale? Sonst bleibt die LED an, da die Zentrale weitersendet (DCC-Seite). Thomas einen RS-485-Sniffer müsste ich auch mal bauen.... Da fällt mir noch ein: Siehst Du denn dann auch die Rückmeldung (Broadcast) von der Zentrale, mit der die Stellung der Weiche am LS100 rückgemeldet wird? Sollte keine Weiche am LS100 sein (bzw. der RS-Bus nicht angeschlossen sein), dann könnte eventuell auch das die Ursache der Fehlermeldung sein. Rückmeldung sollte auch bei Handbetätigung der Weiche kommen.
Hallo topla Hallo Josef welche Baudrate habt ist definiert ? Lenz sendet / verarbeitet normalerweise mit 19200 Baud ein gutes Selbstbau-Projekt (mit Lenz-xPresnet 3.0) gibt es hier http://www.macurb.de Günter
hallo guenter, laut Lenz xpressnet specification arbeitet der rs485 mit 62500 bps , 1 Startbit, 9 Datenbits, 1 Stopbit, kein Parity bit. Das neunte Bit wird von der Zentrale als Adressbit verwendet. Ist dieses Bit gesetzt, wissen die Slaves, das empfangene Byte ist eine Adresse. In Bascom ist der Initbefehl für den Uart: $baud = 62500 'UART-Baudrate: 62500 Baud Config Com1 = Dummy , Synchrone = 0 , Parity = None , Stopbits = 1 , Databits = 9 , Clockpol = 0 Mit dieser Einstellung kann ich den RS485 über den Uart auch einwandfrei abhorchen. Bascom Befehl: Inputbin T1 If T1 = &H52 Then Goto Call52 &H52 kommt als 1. Byte (Headerbyte) von einem Handsteuergerät wenn eine Weiche zu schalten ist. 19200 Baud verwendet Lenz zwischen Interface LI100 und PC Schnittstelle auf der RS232 Seite. Ich kennen die macurb Seite. Bisher habe ich jedoch kein Zugangspasswort für den geschützen Bereich um mir nähere Infos zu holen. Gruss Josef
hallo tobla, ich freue mich ja unheimlich, dass mein Thread jetzt doch noch mehrere freaks aufgeweckt hat. Dachte schon das meine Probleme keinen interessieren. Aber jetzt zu deiner Frage: Bei gedrückter Taste am LH30 oder LH100 sendet das Gerät für Weiche 1 den Befehl Code 52 00 89 DB Lasse ich die Taste los kommt: 52 00 81 D3 War die Weiche bereits in diese Richtung gestellt, kommen anschl. nur noch Adressbytes zwischen 0x41 und 0x5F (offensichtlich Pollbytes der Zentrale). War die Weiche noch nicht in diese Richtung gestellt, sendet offensichtlich die Zentrale sofort nach dem Befehl 52 00 89 DB die Bytefolge A0 42 00 01 oder ... 02 als Feedback zurück. Das Senden des Aus-Befehles habe ich auch schon versucht. Bringt vermutlich aber nichts, solange der Einbefehl nicht fehlerfrei (keine Meldung Übertragungsfehler) ankommt. Ich vermute, dass das Timing beim Senden meines Atmels nicht stimmt. Versuche mit verschiedenen Wartezeit nach dem Umschalten auf Senden sowie zurück auf Empfang brachten bisher keinen Erfolg. Gruss Josef
Nachtrag an Tabla: RS Rückmeldbus habe ich nicht verdrahtet. Weichenrückmeldungen über den RS-Bus kommen nicht bei Handschaltung der Weiche, da keine Endschalter montiert (LGB Weichen mit Zimo Weichendecoder).
Wenn ich richtig gelesen habe, programmierst Du das Ganze mit BASCOM und es gibt offensichtlich ein Problem am Ende des Telegramms, welches Du über RS485 aussendest. Dann würde ich mal "nachsehen", wann! BASCOM den RS485-Treiber wieder zurück auf Empfangen schaltet. Das darf natürlich erst passieren, wenn wirklich alle Bytes aus der UART rauß sind und nicht, wenn das letzte Byte in den UART-Puffer geschrieben wurde. Mit Assembler würde ich dazu den TX-Complete-Interrupt verwenden. Aber wie das in BASCOM gelöst ist, kann ich nicht sagen. Ist aber einen "Gucker" wert, oder? Ansosnten finde ich den Ansatz mit dem Zwischengeschalteten LI100 doch eher umständlich, wenn man es nicht schon liegen hat. Ein Befehlsprotokoll muß man so oder so implementieren. Jörg
An Timingfehler glaube ich dann nicht mehr. Hast Du für Deinen Controller eine eindeutige Adresse am XBUS vergeben? Nicht, daß es da Kollisionen mit dem Handregler gibt. Ist das Paritybit im Header richtig gesetzt (Bit 7)? Ist das Errorbyte richtig zusammengebaut (XOR ohne Headerbyte)? Antwortet Dein Controller auf das dem Fehler folgende Acknowledge-Request richtig? Thomas
Hallo Thomas und Jörg, danke für eure wirklich hilfreichen Infos. Ich habe gestern nochmals mit den Zeiten des Umschaltens zwischen senden und empfangen rumprobiert. Es funktioniert inzwischen. Meine Vermutung war schon richtig, dass es am Timing liegt. Bascom verhält sich hier offensichtlich etwas ungenau, was das Setzen von Wartezeiten mit den Befehlen waitus= mikrosek), waitms = (mSek bzw. wait = (sek) anbelangt. Ich habe jetzt nach Umschalten des Sendepins eine Wartezeit von 5 mikrosek und nach dem Senden meines Schaltbefehles eine Wartezeit von 100 ms eingefügt bevor ich wieder zurück auf Empfang schalte. Anschl. sende ich den Befehl für Taste losgelassen auf die gleiche Weise. Übrigens gibt es auf der Seite http://projects.jusme.com/cgi-bin/projects/index.pl eine sehr gute Dokumentation in Assembler. Leider aber nur für den PIC. Nochmals vielen Dank für Eure Hilfe Josef
Na dann herzlichen Glückwunschh! Das sind so die Gemeinheiten der Hochsprachen, ich bleibe lieber beim Assembler. Da ich persönlich Zeitschleifen als Rechenzeitvernichtung nicht so mag, war ich davon ausgegangen, daß Du eine Interruptsteuerung für die Umschaltung verwendest (also den Sendeinterrupt bzw. das entsprechende Flag auswertest). Thomas
Hallo josef >laut Lenz xpressnet specification arbeitet der rs485 mit >2500 bps , 1 Startbit, 9 Datenbits, 1 Stopbit, kein Parity bit. Das >neunte Bit wird von der Zentrale als Adressbit verwendet. Ist dieses >Bit gesetzt, wissen die Slaves, das empfangene Byte ist eine Adresse. >In Bascom ist der Initbefehl für den Uart: >$baud = 62500 'UART-Baudrate: 62500 Baud >Config Com1 = Dummy , Synchrone = 0 , Parity = None , Stopbits = 1 , >Databits = 9 , Clockpol = 0 >Mit dieser Einstellung kann ich den RS485 über den Uart auch >einwandfrei abhorchen. >Bascom Befehl: >Inputbin T1 >If T1 = &H52 Then Goto Call52 >&H52 kommt als 1. Byte (Headerbyte) von einem Handsteuergerät wenn >eine >Weiche zu schalten ist. >19200 Baud verwendet Lenz zwischen Interface LI100 und PC >Schnittstelle >auf der RS232 Seite. >Ich kennen die macurb Seite. Bisher habe ich jedoch kein >Zugangspasswort für den geschützen Bereich um mir nähere Infos zu >holen. >Gruss Josef Ja, du hast Recht; ich hab das verwechselt...:-( Aber eine andere Frage: in einem früherem Beitrag wurde von einem RS485-Sniffler gesprochen Gibt es da schon einen ('fertigen') Lösungsansatz zum Nachbauen ?? Gruß Günter
hi, hab mich grad mal reingelesen, hört sich interessant an das thema! jedoch ist mir eine kleinigkeit in dem schema von jörg (plitzi) noch unklar. der max481 wird doch mit 12V versorgt, oder? der eingezeichnete spannungsregler liefert doch aber keine 12V sonder die "typischen" 5V oder? Vielleicht hab ich ja auch etwas falsch verstanden, bin noch ziemlich neu auf dem gebiet... mfg david
Der MAX481 braucht 5V Betriebsspannung, siehe http://pdfserv.maxim-ic.com/en/ds/MAX1487-MAX491.pdf . Gruß Thomas
Hallo x-pressnet Gemeinde, es ist ja interessant, wir sich inzwischen alles hier beteiligt. Offensichtlich beschäftigen sich doch einige mit den Geheimnisses der Lenz-Digitalsteuerung. Normalerweise muss ich mein Programm nochmals umschreiben, da ich momentan die Auswertung des 9. Bits noch nicht berücksichtige. Ich horche hier nur auf das Byte P+0x40+GA und gehe davon aus, das es nicht nochmals in irgendeiner Bytefolge der Zentrale gesendet wird. Um das Adressbyte auswerten zu können, muss beim Atmel zuerst das 9. Bit gelesen werden (Ucsrb.rxb8) und anschl. das Register Udr ausgelesen werden. Ich lese momentan nur mit Inputbin var. Hier kann ich das 9. Bit nicht mehr auswerten, da es bereits gelöscht ist, wenn ich mit inputvar arbeite. Aber ich habe ja noch den ganzen Winter Zeit, das zu ändern. Josef
Hallo Günter, für meine Weichensteuerung war für mich damals nur die Bytefolge der Weichenschaltbefehle interessant. Diese beginnen immer mit 0x52 anschl. folgen ein Adressbyte, ein Datenbyte und ein x-Or Byte. ich habe in Bascom hierzu einfach in einer Schleife mit Inputbin V1 auf Hex(52) gewartet. Das Absetzen der Schaltbefehle habe ich mit meiner Handsteuerung LH30 vorgenommen. War es 0x52 habe ich anschl. mit Inputbin V2,V3,V4 die restlichen Bytes gelesen und mir das Ergebnis auf dem LCD für alle von mir verwendeten Weichen (1-16) angeschaut. Diese Befehlsfolge sende ich jetzt zum Schalten meiner Weichen. Byteweisen sniffen war nicht möglich, da die Zentrale dauernd sendet (z.B. Geräteadressen 1..31) und das LCD-Display hier zu langsam bzw. zu wenig Platz bietet. Hier müsste man einen Atmel mit 2 Uarts verwenden und die Ausgabe über RS232 an den PC sendet und dann im Terminalprogramm anschauen. Gruss Josef
Plitzi, Könntest du bitte deine Entwurf für einen Handregler auch als JPG oder PNG anhängen? Vielen dank Frysk
Sorry, ich war eine Weile "offline" (bin noch so ein altmodischer Modemnutzer). Aber siehe Anhang! Das Ganze ist eigentlich nichts weiter als ein Entwurf für eine Mikrocontroller (hier ATMega8) mit LCD, zahlreichen Tasten, einem Analogeingang für ein Schiebepoti und als kleine Besonderheit halt einen RS485-Treiber an der UART. @Josef: Das Sniffen der XPressNet-Kommunikation kann man (einen einfachen RS485->RS232 Adapter vorausgesetzt) doch gleich mit dem PC erledigen. Für den Adapter reicht eventuell auch ein einzelner OPV, der seine Versorgungsspannung aus der seriellen Schnittstelle bezieht. Jörg
Da geht aber immer das neunte Bit verschütt. Ich habe das mit einem Experimentierboard mit einem DS80C320 gemacht. Wird ein gesetztes 9. Bit erkannt, gibt es vor der Übertragung einen 0Dh 0Ah (Zeilenschaltung) an das Terminalprogramm.. Die PC-seitige Übertragungsrate muß aber etwas größer sein als 62.500. Die vorhandene PCI-RS485-Karte habe ich noch nicht zum Laufen bekommen. Thomas
hi, hatte mich neulich schonmal kurz zu dem thema geäußert und habe jetzt bald vor (spätestens nach weihnachten) mich mal intensiver mit dem hier besprochenen thema auseinanderzusetzen und mal erste erfahrungen zu sammeln. jörg (plitzi) hat damals geschrieben, das sein schema bisher nur auf dem papier existiert. gibt es denn inzwischen etwas neues, haben schon andere mitglieder die schaltung auf diese (oder auch ähnliche) art und weise aufgebaut? was ich bisher noch nirgends gefunden hab, wieviel strom kann eigentlich der X-Bus von der Lenz-Zentrale liefern, ich will sie nämlich nicht schrotten und lieber auf nummer sicher gehen... mfg david
Solange es keine Software (und das ist nicht trivial) dafür gibt, macht ein Nachbau einer auf dem Papier existierenden Schaltung wohl keinen Sinn und Erfahrungen sammeln sich auch schlecht.... Thomas
hi, habe mich jetzt auch mit meinem atmel (atmega8515) und einem max485 hingesetzt und versucht mit der zentrale (lz100, version 3.2) zu kommunizieren. doch seit ein paar tagen bin ich am verzweifeln, ich komme nicht weiter, ich schaffe es nicht befehle an die zentrale zu senden, dass diese die auch "annimmt". als beispiel wollte ich "0x80 0x80" (nothalt) senden. ich warte, bis der atmel als handregler mit der adresse 1 angesprochen wird. das funktioniert auch, dann ziehe ich einen pin am atmel auf high um dem max 485 in den senden-modus zu schalten. dann sende ich "0x80 0x80" und lege erst wenn die txcomplete -flag im UCSRA gesetzt ist, den pin der mit dem max 485 verbunden ist wieder auf low. hab mir das ganze mit einem digitalen 2-kanal oszi angeschaut. das timing scheint zu passen, der pin ist auf high, erst dann sened ich über das uart und dann erst geht der pin wieder auf low. einstellungen fürs uart: baudrate: 62500 1 startbit 9 datenbits 1 stopbit kein parity wenn jemand eine idee hat, wo das problem liegen könnte, würd ich mich über hilfe freuen. oder falls jemand einen codeschnipsel hat, dann wäre es such wenn, wenn den jemand posten könnte, ich arbeite mit assembler... danke schon einmal im voraus! david
1. Du hast keinen Handregler mit Adresse 1 angeschlossen. 2. Baue eine Verzögerung zwischen Empfangsinterrupt und Umschalten auf Senden von etwa 10 Microsekunden ein. Thomas
schonmal danke für die tipps, hat leider auch keine abilfe geschafft. hier mein sourcecode, der als beispiel 0x80 0x80 (Nothalt) senden soll. Mit dem Oszi geprüft, funktioniert auch alles im entsprechenden Zeitfenster, jedoch geht die Zentrale nicht in den Zustand "Notaus". Nach einmaligem Senden von 0x80 0x80 scheint die Zentrale den Handregler nicht mehr anzusprechen, er sendet nicht mehr, auch nicht nach Reset. Erst wenn ich die Lenz-Zentrale neu starte (Strom weg und wieder dran) kann ich wieder einmal mit dem Controller senden, erst dann scheint er also wieder angesprochen zu werden. Woran könnte das liegen? Lässt man die Zeile "ldi send, 0" in "transmit:" weg, sendet der Controller ununterbrochen 0x80 0x80. Dann geht die Zentrale komischerweise in den Modus "Notaus". Nocheinmal zum Verständnis: Die Zentrale eröffnet für jeden Handregler ein Transmission-Window, indem der Handregler etwas senden muss. Ich warte also, bis der Controller angesprochen wird, hat hier im Beispiel die Adresse "1" und sende dann etwas. Dannach gehe ich wieder in den Receive-Modus um wieder für den Empfang bereit zu sein. Habe ich noch etwas vergessen, war es das oder fehlt irgendwas??? Vielen Dank für eure Mühen, so langsam wird das Fehlersuchen nervig ;-). Frohe Weihnachten... David
hab ich vorhin vergessen, hier noch eine erläuterung: PORT A ist nur zu Debug-Zwecken da, er wird bei jedem Aufruf von "rx_complete" getoggelt. PORT C ist mit dem Max 485 verbunden und schaltet ihn auf Senden oder Empfangen. vielen danke...
Hallo, ich habe es zwar mehr mit dem 8051-Assembler und bin jetzt zu faul, Deinen Quelltext bis ins Detail zu ergründen, aber Folgendes ist mir aufgefallen: 1. "normal inquiry" kommt mit gesetztem 9. Bit, mir scheint, Du wertest das nie aus. Ev. interpretierst Du ein "normales" Datenbyte auf dem Bus als Adresse. Das daraufhin folgende Senden geht in die Hose. 2. entzerre das mal zeitlich, ich glaube, daß das Timing ganz schön sportlich ist (umschalten in Sendebetrieb nach Empfang Callbyte) 3. Ohne ldi send,0 ballerst Du ja ohne Punkt und Komma 80h auf den XBUS, irgendwann erwischt Du dann auch mal ein Window und die Zentrale reagiert. Kann eigentlich elektrisch was passieren, wenn die RS-485-Treiber gegeneinander antreten? Gut ist es bestimmt nicht. Thomas
Obwohl ich softwareseitig noch keine Erfahrungen am realen Gerät sammeln konnte (immer noch keine Zentrale und wenig Zeit :( ), lese ich hier weiter sehr interessiert mit. Ich habe mir auch einmal den Quellkode des Testprogramms angesehen und dazu die diversen Dokumentationen von Lenz überflogen. Die Umschaltung des RS485-Treibers scheint in Ordnung (erst nach dem TXC und nicht bereits nach dem UDRE!). Der Befehl für das Not-Aus ist auch korrekt (kein XOR-byte vergessen oder so). Was mir noch einfällt ist die Problematik 9-bit-UART. Bei Lenz steht, dass die Zentrale die Adresse des Hand-Reglers als solche markiert, indem sie das Adressbyte mit gesetztem Bit 9 sendet und die nachfolgenden Daten immer mit Bit 9 = 0 (damit lässt sich in den uCs mit Multiprozessorkommunikatios-UART, z.B. 8051 oder die neueren AVRs die Adresse schön filtern). Dieses 9.Bit wird aber im Programm gar nicht ausgewertet (wurde aber von Thomas schon moniert). Dieses 9.Bit wird aber natürlich empfangen und steht im UCSRB als RXB8 zur Verfügung und sollte auch ausgewertet werden. Dazu muss in der rc_complete-ISR das UCSRB und darin das RXB8-Bit gelesen werden, BEVOR man das UDR abholt und auf die eigentliche Adresse vergleicht. Ist RXB8=0 war es keine Adresse und man kann sich weiter Auswertungen und Aktionen sparen (aber nicht das lesen des UDR, sonst wird der IRQ nicht gelöscht!). Siehe auch Datenblatt des m8515 Seite 143/144. Einfacher geht es wie bereits erwähnt mit dem MPCM (Datenblatt Seite 150). Auch beim Senden sollte man sicherstellen, dass wie verlangt mit Bit9=0 gesendet wird (ist aber wohl in dem Testprogramm zufällig? gegeben, da TXB8 nie angefasst wird und nach einem RESET =0 ist). Ich hoffe, ich konnte einen neuen Denkanstoß geben. Jörg
>Die Umschaltung des RS485-Treibers scheint in Ordnung (erst nach dem
TXC und nicht bereits nach dem UDRE!).
Ist wohl wahr, aber es ist nicht gesagt, daß die Zentrale bei der
Umschaltung genau so schnell ist. Das LW100 z.B. legt eine Pause (u.a.
eine Zeitschleife!) von 10 µs ein und damit geht es. Ausschließen würde
ich diesen Punkt nicht so ohne Weiteres.
Thomas
Hallo Lenz-X-Bus Gemeinde, ich möchte mich mal wieder zu meinen alten Forumbeitrag melden. Hatte heuer wenig Zeit um mich mit meiner Selbstbau-Weichensteuerung zu beschäftigen. Inzwischen habe ich mir mein Stellpult fräsen lassen und die Verbindung zum Atmel fertiggestellt. Gab am Anfang einige Probleme mit der Ansteuerung des Displays (blau/weiss-20*4) mit Bascom und natürlich wieder Probleme mit dem Timing auf dem RS485-Bus. Inzwischen läuft aber alles wie ich mir das vorgestellt habe. David schrieb mal, dass er ebenfalls Probleme hatte, die Zentrale fehlerfrei zu adressieren. Ich hatte ebenfalls lange die gleichen Probleme. Hatte dann mit Lenz mal einen freundlichen, kurzen e-mail Kontakt und bekam dann eine recht aufschlußreiche Beschreibung, wie das Handling genau mit angeschlossenen Geräten ausschaut. Seit befolgenden der Hinweise bei Fehlerübertragungen, funktioniert der ganze Ablauf auch ohne Assambler- und Interrupt Programmierung. Sollte einer Interesse haben, kann ich inzwischen weiterhelfen. Gruss Josef
Hallo Josef, das interessiert mich sehr, könntest Du mir die Beschreibung von Lenz bitte zukommen lassen? Gruß Thomas
Guten Morgen, oben im Thread wurde der Selbstbau einer DCC-Zentrale angesprochen. Mich würd interessieren ob dies noch weiterverfolgt wurde. Reinhard
Hallo Thomas, Du muß dich zuerst im Forum anmelden. Als Gast funktioniert der direkte Kontakt nicht. Josef
@josef: Hab ich doch gleich gemacht... @carnival: War eigentlich nur ein Handregler im Gespräch und ist hier nicht über das Stadium Schaltplan hinausgekommen. Eine DCC-Zentrale selbst bauen ist angesichts des Angebots von gebrauchten Lenz LZ100 und Roco-Lokmäusen (für kleinere Ansprüche) im Sinne von Einsparungen kaum sinnvoll. Thomas
Hallo Lenz-Fans Hat denn schon jemand eine lauffähige Hardware mit Software (am liebsten auf Bascom-Basis) am Laufen? Oder hat ev. schon mal jamand von euch versucht einem LI100F über die serielle Schnittstelle Kommandos zu schicken? Eigentlich möchte ja auch ich nur ein paar Weichen vom AVR aus stellen, ob das nun direkt über RS485 oder über das LI100F geschieht, spielt mir keine Rolle. Das LI100F möchte aber scheinbar eine saubere CTS/RTS Signalisation, welche mir Schweirigkeiten macht. Hat da schon jemand mit Bascom Erfahrung? Schon mal vielen Dank und Grüsse aus der Schweiz Thomas
Ja und nein, ich habe einen Nachbau der Lenz-Module LW120 und LW130 mit einer Erweiterung durch Aufsatzmodule für meine Modellbahn entwickelt. Gedacht sind diese Module für den Anschluß an das Lenz-Stellwerk LW100, um daran ein Gleisbildstellpult zu betreiben. Diese Module funktionieren einwandfrei am GZIO-Bus des LW100. Da das auch nur ein RS-485-Bus ist (allerdings nur mit 9600 bps), habe ich eine Bestückungsvariante vorgesehen, die den Anschluß an den XBus ermöglicht. Die Modulbestückung ist fast identisch, lediglich der Quarz ist 4,000 MHz statt 3,6864 MHz und die Brücken werden durch Filter ersetzt. Ein lebendes Exemplar dieser Variante gibt es noch nicht. Software existiert im Ansatz, allerdings hat mich ein Totalverlust meines USB-Sticks da etwas zurückgeworfen. Prozessor ist allerdings ein AT89C4051 und programmiert wird in Assembler statt BASCOM. Viele Grüße Thomas
Hallo Bin neu hier, interessant. Habe das gleiche Problem(mir selbst gestellt). also: wie weit ist die Lösung den nun Fortgeschritten, oder kann man die erwähnten Daten (von Lenz) noch haben? Alex
1. fertig 2. Ist die XBus-Doku von Lenz. Wenn Du deine email-Adresse hier hinterlässt,schicke ich Dir das mal zu. Gruß Thomas
Hallo, könntest du mir die Doku vielleicht auch zukommen lassen? Das wäre sehr nett, ich bin da auch gerade am experimentieren und habe noch ein paar Problemchen.......... Viele Grüße Ilon
Hallo, Nach ein bisschen googeln fand ich das: http://www.lenz.com/manuals/xpressnet/xpressnet.pdf Gruß, Lars
hallo! ich habe eine frage: hat jemand die hex Datei von Fahrregler4_20040409.sch. gruß Thomas
Hallo Zusammen, ich weiß der Thread ist schon etwas älter und vielleicht macht hier niemand wer was, trotzdem probiere ich es, da das Thema sehr interessant ist. Ich möchte auch über Schalter meine DCC Decoder ansprechen, so wie es hier beschrieben ist. Ich verwende die Roco Mulitmaus mit Verstärker @Josef: Du hast weiter oben geschrieben, dass du diese Kommunikation mit AVR schon erreicht hast. Bist du gewillt den Code dafür preis zu geben? Ich bin selbst kein so guter C-Programmierer um das alles von 0 weg zu programmieren. Vielleicht gibt es ja noch jemanden der hier noch aktiv dabei ist. mfg Ralf
Hallo zusammen, hier mal ein Link mit C-source. https://sites.google.com/site/dcctrains/rs-bus-feed Ich selbst bin auf der suche nach den Code für Bascom. Ziel: Weichendecoder mit Belegtmelder (nicht die Weichstellung) für Modulanlage. Man braucht manchmal nur 1-2 Weichen und/oder 1-4 Belegtmelder pro Modul. Gruss Robokalle
Hallo zusammen Obwohl der Thread schon etwas Älter ist hoffe ich darauf das hier vielleicht noch jemand mit liest. Ich möchte auch mein Multimaus-System um ein eigenes Stellpult und die anbindung an einen Rechner erweitern. Ich Programmiere in Bascom und habe den Code fürs Empfangen und Senden auf dem Xpressnet mittlerweile fertig. Ich benutze einen Atmega162 da ich für die Rechneranbindung die zweite Uart benötige. Wie gesagt funktioniert die Kommunikation mit der Multimaus und dem PC mittlerweile problemlos, bin momentan jedoch noch auf der Suche nach einer geeigneten Tastenanbindung und Auswertung. Hat sich von euch vielleicht schon einmal jemand mit dem Thema Tastenerweiterung mit vielen externen Tasten beschäftigt damit ich einen Denkanstoss bekomme. Gruß Günter
Hallo Günter Wau, super, wenn du einen lauffähigen Code auf Bascom-Basis hingekriegt hast. Da blieb ich leider, auch wegen Zeitmangel, in den Anfängen stecken. Ich beschäftige mich aber recht viel mit LCD's und Touchscreens diverser Bauarten. Die lassen sich beide recht gut in Bascom bedienen. Hier mal ein Beispiel http://www.ebay.ch/itm/ws/eBayISAPI.dll?ViewItem&item=200401013928&ssPageName=ADME:B:EOIBSA:CH:1123 Ich wäre an deinem Code sehr interessiert, vielleicht können wir ja da beim User-Interface was sharen.... Viele Grüsse Thomas
AVR Amateur schrieb im Beitrag #2819250: > Hat sich von euch vielleicht schon einmal jemand mit dem Thema > Tastenerweiterung mit vielen externen Tasten > beschäftigt damit ich einen Denkanstoss bekomme. Beitrag "Re: RS 485 Lenz X-Bus" Mit Aufsatzboard können 32 Taster ausgewertet werden, der 74HC165 ist dafür gut geeignet. Eine andere Lösung wird dort verfolgt: http://usuaris.tinet.cat/fmco/download/XbusTCO_manual.pdf Gruß Thomas
Zu Topla Leider sind mir 32 Tasten etwas zu wenig und bei der Lösung der Spanier (soweit ich das sehe) pollt der AVR die Taster. Ich stelle mir eher eine Lösung auf Interrupt- Basis vor. Momentan bin mit mehreren 74HC147 am Basteln. Ich habe mir auch schon mal gedanken über eine Anbindung der Tasten über mehrer Attiny2313 gemacht, da ich von denen noch einige von der Entwicklung auf der DCC Seite herumliegen habe. Auf der DCC Seite habe ich mir auch eine modulare Lösung mit mehreren Tiny's2313 ausgedacht(Grundplatine DCC-Empfang dazu mehrere Aufsätze für verschiedene Aufgaben z.B. Servoaufsatz, Relaisaufsatz, reiner Schaltaufsatz im angehängten Bild als Beispiel mal zu sehen Links Servoaufsatz Mitte DCC-Decoder Rechts "stehend" Beide zusammengesteckt)so eine ähnliche Lösung nur zum anreiehen immer weiterer Tastenmodule hätte ich auch gerne für die Tasten. Zu Thomas Riesen Ich habe kein Problem dir mal meinen Code weiterzugeben, möchte ihn nur nicht hier öffentlich einstellen. Zum einen ist der Code momentan komplett unkommentiert zum anderen verbreite ich ungern noch nicht fertige Anwendungen. Ich könnte ihn dir mal mailen, Wie komme ich an deine Adresse? Gruß Günter
AVR Amateur schrieb im Beitrag #2820667: > Zu Topla > > Leider sind mir 32 Tasten etwas zu wenig und bei der Lösung der Spanier > (soweit ich das sehe) pollt der AVR die Taster. Das war nur ein Beispiel anhand einer fertigen Lösung. Von diesen Modulen können auch mehrere eingesetzt werden. Es hindert Dich auch niemand daran, noch mehr 74HC165 zusammen zu schalten, wird halt das Schieberegister länger oder es gibt mehrere parallele Stränge. > Ich stelle mir eher eine Lösung auf Interrupt- Basis vor. Tasten und Interrupt sind keine sehr gute Idee, aber dazu gibt es hier dutzende Beiträge. > Momentan bin mit mehreren 74HC147 am Basteln. Ich habe mir auch schon > mal gedanken über eine Anbindung der Tasten über mehrer Attiny2313 > gemacht, da ich von denen noch einige von der Entwicklung auf der DCC > Seite herumliegen habe. Müssen die 2313 unbedingt verbraucht werden? Da langweilt sich doch schon einer zu Tode, das bisschen Schieberegister einlesen und auswerten und bei Bedarf mal den XBus bedienen ist doch keine Herausforderung. Thomas
Hallo Topla Zuerstmal Danke für deine Antworten. So wie ich das sehe läuft es mit den 165en auf einen SPI Bus raus. Wie ist das mit den Leitungslängen? Und mit Schieberegistern könnte ich ja auch gleich einen S88 Bus implementieren welcher ja soweit ich das in verschiedenen Foren gelesen habe auch immer mal wieder probleme verursachen soll. Obwohl ein S88 Bus sowieso keine schlechte Idee wäre (Rückmeldung an den PC) sollte ich vielleicht mal überdenken. Bisher hatte ich mir nur eine einfache Lösung zum Schalten verschiendener Antriebe (z.B. Servos,Magnetartikel,LED's)von externem Stellpult oder vom PC aus vorgestellt. Die geschalteten Artikel werden ja als Rückantwort wieder auf dem Xpressnet ausgegeben. Ich dachte mir dann ähnlich dem Weichenstellungs - Symbol der Multimaus die Schaltstellungen wieder auf dem PC auszugeben (Ich weiß keine echte Rückmeldung). Gruß Günter
AVR Amateur schrieb im Beitrag #2823287: > So wie ich das sehe läuft es mit den 165en auf einen SPI Bus raus. > Wie ist das mit den Leitungslängen? Ja, ist SPI. Die Leitunglängen sollten keine Rolle spielen. Da Du ja ein Schaltpult (das wird ja nicht gerade mehrere Quadratmeter haben) bauen willst, sitzen die Schieberegister in der Nähe des Prozessors und die Leitungen von den Schaltern zu den Schieberegistern sind unkritisch. Entprellen macht man in Software. > Und mit Schieberegistern könnte ich ja auch gleich einen S88 Bus > implementieren welcher ja soweit ich das in verschiedenen Foren > gelesen habe auch immer mal wieder probleme verursachen soll. Und was hat das jetzt mit XBus-Eingabegeräten zu tun?? S88 kann Probleme machen, wenn die Module über die ganze Anlage verteilt sind und die SPI-Leitungen in der Nähe von stromführenden Leitungen liegen. Thomas
Hallo Topla Du hast natürlich recht mit "was hat das mit Xbus-Eingabegeräten zu tun" Ich dachte nur auch S88 ist im Grunde genommen ein SPI Bus welchen ich dann auch zur Tasteneingabe verwenden könnte. Natürlich ist mein Stellpult nicht enorm groß ist eher klein es gibt aber mehrere davon welche einen Abstand von 1-2 Meter haben. Muß dann halt mehrere "Nur Eingabegeräte Basis Tiny2313" bauen, sollte kein Problem sein da mir zur Platinenherstellung ein Fräsplotter zur Verfügung steht und für meine kleine Anlage die RS485 beschränkung auf 31 Geräte auch vollkommen ausreicht. Ich danke dir jedenfalls für deine schnelle Hilfe hat mir jetzt sehr weiter geholfen, manchmal ist man halt zu sehr auf seinen ersten Gedankengang eingefahren, und beginne direkt mal mit der Erweiterung mittels 74HC165. Gruß Günter
Hallo Günter Wie erwähnt, wäre ich an deinem Code sehr interessiert. Über die "Bedingungen" könnten wir ja noch diskutieren. Bei der Ansteuerung des X-Bus habe ich hauptsächlich noch Timing-Probleme, hier wäre ich für deine Hilfe in Form des Codes sehr dankbar. Ich selber verwende das TCO von Paco, dem Spanier. Hier kann man ja auch verschiedene Adressen verwenden, so dass mehrere TCO's eingesetzt werden können. Das TCO funktioniert wirklich sehr zuverlässig, auch die Rückmeldung in den Traincontroller klappt super. Etwas mehr dazu siehst du auf meiner Homepage www.riesens.ch Freundliche Grüsse Thomas
ich klink mich mal kurz dazwischen und frage: Habt Ihr ne Protokollspezifikation? hab mal gegoogelt, aber nix aufschlussreiches gefunden ... evtl. ein Link?
Er sucht nicht das DCC-Protokoll, sondern das vom XBus. Alles was man braucht, steht da drin: http://www.digital-plus.de/pdf/XpressNet%20und%20USB%20Interface.pdf und da: http://www.digital-plus.de/pdf/xpressnet_li101f.pdf Thomas
Thomas Riesen schrieb: > Bei der Ansteuerung > des X-Bus habe ich hauptsächlich noch Timing-Probleme, Da gibt es so gut wie nichts Zeitkritisches. Du darfst nur nach dem Token nicht zu lange warten, sonst spricht die Zentrale die nächste Busadresse an. Lenz-Equipment legt eine kleine Pause von 10µs vor dem Senden ein, wenn Du zu schnell bist, wird die Zentrale "überfahren" und das Telegramm verstümmelt. Thomas Edit: Bei Entwicklungen für den XBus hat sich bei mir dieses Gerät bewährt: http://www.opendcc.de/elektronik/dcc_sniffer/xp_sniffer_sw.html
Hallo Thomas (topla) Vielen Dank! Ja nun, ich werde mich da wieder mal dahinter machen. OpenDCC kenne ich gut, habe da die Zentrale und Weichendecoder nachgebaut. Wo hast du den Sniffer denn her? Platine selbst geätzt? Du hast da nicht ev. noch eine Platine übrig oder sogar ein Fertigteil? Arbeitest du auch mit Bascom? Grüsse aus der Schweiz Thomas
Thomas Riesen schrieb: > Wo hast du den Sniffer denn her? Platine selbst geätzt? > Du hast da nicht ev. noch eine Platine übrig oder sogar ein Fertigteil? Ist schon länger her; ich habe die Schaltung und das Programm von Wolfgang Kufer genommen und modifiziert. Die USB-Anbindung läuft wimre über einen FT245 und das Zeug für die XBus-Seite ist mit auf der Platine, die in ein Pactec-CNL-Gehäuse passt. Ob da noch was über ist, weiß ich nicht (bin 500km von zu Hause weg). edit: Die Platine ist industriell gefertigt, zweiseitig, durchkontaktiert mit Lötstopp. > Arbeitest du auch mit Bascom? Nein, bin in Assembler unterwegs. Gescheiterte Versuche mit C haben mich immer zum Assembler zurückgetrieben. Thomas
Hallo Zusammen Oben genannter Link zur Xpressnet Spezification ist für Xpressnet V3.6 soweit ich weiß unterstützt die Multimaus aber nur V3 deshalb arbeite ich mit dieser Spezification. http://www.lenzusa.com/1newsite1/Manuals/xpressnet.pdf Gruß Günter
hmmm ... hab mir das mal angeschaut ... ist ansich nicht so wild ... doof nur, die Übertragung 9n1 auf 62,5 kBaud. Ohne Gateaway geht da nix, aber das lässt sich recht human zusammenstricken. Hab gerade sowas ähnliches gemacht für Infrarotkommunikation, das Ardurinoboard ist ne Möglichkeit, geht aber auch problemlos n kleiner ATTiny2313. Auf der PC-seite würde sich n FTDI-chip anbieten, würde da zum Breakoutboard von Sparkfun greifen, schön kompakt, recht günstig. Dann einmal die Hardware-UART RX an den FTDI, TX an den RS485-Baustein, dazu ne Software-UART, da RX an den rs485, TX an den USB ... baudratenquarz an dem Ding und gut ist, kann man auf Punktraster zusammenlöten. Vom Programm her einfach die Hardware-Uart über Ringpuffer laufen lassen und die Protokollverarbeitung und Software-UART in der Mainloop. Interessantes Ding :)
Der Sniffer kann deutlich mehr und braucht für die Steuerung durch den PC sowieso einen µC mit entweder 2 seriellen Schnittstellen oder eben, wie ich das gelöst habe, PC-seitig einen FT245 (parallel angebunden). Weiß nicht, ob ein 2313 das reisst. Thomas
Hallo Thomas (gastrodus) Habe mich soeben mal im Forum angemeldet las mir doch mal eine Nachricht mit Mail adresse zukommen dann kann ich dir den Code schicken. Bin gerade mal dabei den Schaltplan zu Zeichnen und den Code etwas zu kommentieren kann aus Zeitmangel aber noch 1-2 Tage dauern. Gruß Günter
Hallo Leute, ich versuche auch in Bascom etwas zu bewegen. Allerdings passiert nicht das was ich möchte ^^ Controller ist ein Mega644. Ich lese mit dem UART-IRQ zuerst das 9. Bit aus und danach hole ich das Byte mit Inputbin ab. Soweit so gut ... Danach vergleich ich meine interne Adresse (0x40 + 1, also 0x41) und lasse mir die empfangene Adresse auf PortB ausgeben (STK500 LEDs). Die Ausgabe erfolg nur wenn das gelesene Byte gleich der Adresse ist. Aaaaber: Die Adresse : 0100 0001 (0x41) PortB LEDs : 0100 0010 (0x42) Waaaarum wenn's doch angeblich gleich ist? @AVR Amateur: Du schreibst oben dass Du lauffähigen Bascom Code hast. Könntest Du mir da vielleicht ein paar Teile davon schicken? Mir würde der Empfang des Callbytes und die Senderoutine (vereinfacht) reichen. Wäre echt super von Dir :) Danke schonmal!
Michael schrieb: > Waaaarum wenn's doch angeblich gleich ist? Weil Du einen Fehler in Zeile 42 Deines Codings hast. Thomas
Jetzt fängt das wieder an ... Muss man wirklich Code anhängen damit auch jeder versteht dass
1 | if Gelesen = &H41 then |
2 | PortB = not Gelesen 'STK500 LEDs invertiert |
etwas falsches anzeig obwohl es ja nicht sein kann?
Wenn Dein tolles Programm niemals nie nicht die Ursache für die Fehlfunktion sein kann, dann melde den Fehler im Prozessor oder im BASCOM an den jeweiligen Hersteller. Ich bin raus hier, such' Deine Fehler selber. Thomas
Michael schrieb: > Ich lese mit dem UART-IRQ zuerst das 9. Bit aus und danach hole ich das > Byte mit Inputbin ab. Inputbin? Wieso denn das? Du verdonnerst Deinen µC dazu Ewigkeiten in dem Interrupt zu hängen. wofür? Nee, ohne Code kann man Dir nicht helfen, leider.
Thomas P. schrieb: > Der Sniffer kann deutlich mehr und braucht für die Steuerung durch den > PC sowieso einen µC mit entweder 2 seriellen Schnittstellen oder eben, > wie ich das gelöst habe, PC-seitig einen FT245 (parallel angebunden). > Weiß nicht, ob ein 2313 das reisst. > > Thomas für 62,5 kBaud? Nee, PC-seitig wird auf 115,2 kBaud eingestellt und gut ist, doch, das sollte der 2313 locker schaffen.
Fhutdhb Ufzjjuz schrieb: > für 62,5 kBaud? Nee, PC-seitig wird auf 115,2 kBaud eingestellt und gut > ist, doch, das sollte der 2313 locker schaffen. Mag sein, aber sicher bin ich mir da nicht. 115,2kbd reichen aus, das stimmt. Auf dem Sniffer laufen ja auch zusätzlich noch Filterfunktionen, ein Zeitstempel wird hinzugesetzt und die Daten wahlweise auch in Klartext ausgegeben. Thomas
Thomas P. schrieb: > Fhutdhb Ufzjjuz schrieb: >> für 62,5 kBaud? Nee, PC-seitig wird auf 115,2 kBaud eingestellt und gut >> ist, doch, das sollte der 2313 locker schaffen. > > Auf dem Sniffer laufen ja auch zusätzlich noch Filterfunktionen, ein > Zeitstempel wird hinzugesetzt und die Daten wahlweise auch in Klartext > ausgegeben. Das kann man dann am PC stricken mit nem kleinen VB-Progrämmchen ... ob man die Protokolldekodierung im Sniffer macht oder sich n kleines Terminalprogramm zusammenklickt macht vom Aufwand her wenig unterschied.
So, es scheint nun alles zu funktionieren ... Das Ganze ist natürlich erstmal ganz vereinfacht und vielleicht auch etwas seltsam aber es geht. Ich erwische nun auch bei automatischen Senden das Callbyte und das dadurch gegebene Zeitfenster. Mein LED Problem an PortB konnte ich nur durch einen Controllertausch beheben. Habt ihr vielleicht Verbesserungsvorschläge für den Empfang oder kann man das so lassen? LG Michael
1 | $regfile = "m644def.dat" |
2 | $crystal = 8000000 |
3 | $hwstack = 64 |
4 | $swstack = 64 |
5 | $framesize = 64 |
6 | |
7 | |
8 | const Adresse = 1 |
9 | |
10 | 'UART für RS485 |
11 | $baud = 62500 |
12 | Config Com1 = Dummy , Synchrone = 0 , Parity = None , Stopbits = 1 , Databits = 9 , Clockpol = 0 |
13 | 'Verbindung zum PC |
14 | Open "Comd.7: 19200 , 8 , n , 1" For Output As #2 |
15 | |
16 | |
17 | 'Automatisches Senden/Empfangen Umschaltung für RS485 |
18 | Config Print0 = Portd.6 , Mode = Set |
19 | Config Portd.6 = Output |
20 | |
21 | |
22 | 'LEDs |
23 | Config Portb = Output |
24 | |
25 | 'Taster |
26 | Config Pind.2 = Input |
27 | Config Pind.3 = Input |
28 | Portd.2 = 1 |
29 | Portd.3 = 1 |
30 | |
31 | |
32 | 'IRQs |
33 | On Urxc Check |
34 | Enable Urxc |
35 | Enable Interrupts |
36 | |
37 | |
38 | |
39 | Dim Neun As Bit |
40 | Dim Gelesen As Byte |
41 | Dim Adressbyte As Byte |
42 | Dim Bytes(3) As Byte |
43 | |
44 | |
45 | |
46 | Adressbyte = &H40 + Adresse |
47 | Neun = 0 |
48 | |
49 | |
50 | 'LEDs aus |
51 | Portb = 255 |
52 | |
53 | |
54 | Do |
55 | |
56 | 'Weiche stellen |
57 | If Pind.2 = 0 and gelesen = Adressbyte and Neun = 1 Then |
58 | Waitus 10 |
59 | Printbin &H52 ; &H00 ; &H88 ; &HDA ; |
60 | End If |
61 | |
62 | 'Weiche stellen |
63 | If Pind.3 = 0 and gelesen = Adressbyte and Neun = 1 Then |
64 | Waitus 10 |
65 | Printbin &H52 ; &H00 ; &H89 ; &HDB ; |
66 | End If |
67 | |
68 | 'Weichenkommandos zum PC übertragen |
69 | If Gelesen = &H52 Then |
70 | Inputbin Bytes(1) 'restliche Bytes lesen |
71 | Print #2 , Hex(gelesen) ; " " ; Hex(bytes(1)) ; " " ; Hex(bytes(2)) ; " " ; Hex(bytes(3)) |
72 | Gelesen = 0 |
73 | End If |
74 | |
75 | Loop |
76 | |
77 | |
78 | |
79 | Check: |
80 | Neun = ucsr0b.rxb80 |
81 | Gelesen = UDR |
82 | Return |
83 | |
84 | |
85 | |
86 | End |
Hallo Michael Das sieht ja übersichtlich, fast einfach aus. Klappt das mit dem UART auch mit andern AVR's? Wie hast du den MAX485 angeschlossen? Dankende Grüsse Thomas
Ich mach dir einen Schaltplan wegen dem Max485. (bin noch am arbeiten) Ob es auch bei anderen Avr's geht, nunja, zumindest beim 1284p geht's auch. Etwas kleineres habe ich in Erwartung meines Grafikdisplays usw. garnicht erst versucht.
Hier noch der Schaltplan für den Max485. Die Leitung an PortD.6 kann natürlich an jeden anderen Pin gelegt werden. Muss dann nur in der Config von Print0 geändert werden. LG Michael
Hallo Michael Vielen Dank! Ich bin nun am Herausfinden, der UART auch bei einem ATmega8 oder ATmega328 geeignet ist. Grüsse aus der Schweiz Thomas
Thomas Riesen schrieb: > Vielen Dank! Ich bin nun am Herausfinden, der UART auch bei einem > ATmega8 oder ATmega328 geeignet ist. Warum nicht, alle 9-Bit-fähigen Uarts können eingesetzt werden. Ein AT89C4051 tut es auch seit langem. Thomas
Hallo zusammen Aus Zeitgründen habe ich es leider versäumt mich mal wieder im Forum umzusehen. Ich bin gerade dabei die Elektronik für meine Stellpulte fertigzustellen. Basis ist nun ein Atmega8 mit 2x "SPI In" 1x für die Tasteneingabe 1x für die Rückmeldung. Des weiteren 1x "SPI Out" für die LED's (Weichenstellung,Belegtmeldung) im Stellpult. Ein 16x2 Display zur Anzeige der Xpressnet-Codes ist auch schon eingebunden. Momentan läuft es nur im Elektronik Simulator. Was noch fehlt: Momantan fehlt mir noch die Fehlerauswertung des Ringpuffers bei evtuellem Überlauf. Die Xpressnet-Adresse muß auch noch manuell vergeben werden mit der automatischen Vergabe von Xpressnet-Adressen habe ich mich noch nicht befasst. Und weil ich die Pins am AVR gerade noch frei habe möchte ich zu Testzwecken noch einen I²C Bus einfügen. Da es nur ein Stellpult werden soll fehlt hier die Anbindung zum PC. Auch bin ich noch nicht ganz schlüssig ob ich zur Umschaltung der Weichen oder Signale nur eine Taste verwenden soll, da hierbei auf eine echte Rückmeldung zum Vergleich wohin geschaltet werden soll auf keinen Fall verzichtet werden kann. Hallo Thomas(Riesen) Schaltplan und Code geht dir sobald ich soweit bin per Mail zu. Hallo Michael Schick mir mal ne Mail dann bekommst du auch Post.
10nF alleine am 7805 sind zu wenig, da fehlt noch n fetter Elko, Abblockkondensatoren sind Fehlanzeige (an µC und Max), n ISP mach ich auch auf jede Leiterplatte, ist ätzend den µC für jede Änderung aushebeln zu müssen. Was machen D2 und D3?
Hallo Fhutdhb Ufzjjuz Der Schaltplan ist nur ein Auszug aus dem Simulationsprogramm und noch nicht für das Platinenlayout gedacht. Als Spannungsversorgung verwende ich ein ausgedientes PC - Netzteil, Glättung ist von daher normalerweise nicht notwendig. Bei Verwendung eines Modellbahntrafos muß natürlich noch ein Glättungselko rein. Die Dioden sind Freilaufdioden, hab ich wohl mal so gesehen. ISP Buchse wird in der entgültigen Version natürlich vorhanden sein. Abblockkondensatoren werden natürlich auch eingefügt aber wie du im Schaltplan erkennen kannst fehlen an den IC die Versorgungspins. Hab ich glatt vergessen U7 (4N28) ist für eine DCC implementation vorgesehen. Gruß Günter
Günter S. schrieb: > Glättung ist von daher normalerweise > nicht notwendig hinterm 7805? Doch, auf alle Fälle. Und ne Reversediode über den 7805er zudem.
Bitte 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.