THEMA: Digital vom PC ohne Zentrale - gibts das?

Moin Dirk,

im Prinzip ist Dein Gedanke gut. Aber…
Mir ist kein aktuelles Betriebssystem bekannt, dass das Timing eines DCC- oder SX-Protokolls auf einem PC gewährleisten kann. Hierfür ist schon noch ein eigener Prozessor erforderlich. Weiterhin benötigst Du natürlich noch Treiber (Booster). Direkt über einen USB-Anschluss wirst Du keine Lok fahren können

LG Matthias

Hallo Dirk,

diese Schnittstellenleiste, wie du es nennst, muss ja auch noch die Befehle vom Computer in das DCC Signal übersetzen. Dein USB-Port gibt ja kein DCC Signal aus, dass du einfach von 5 V auf 16 V aufpeppeln kannst Und wenn du es per (W)Lan anschließt, werden die Informationen in Paketen übertragen, die erst wieder entpackt werden müssen. Ein bisschen Rechenarbeit ist da schon noch erforderlich. Ob es eine solche "Schnittstellenleiste" ohne Anschluss für eine Zentrale fertig auf dem Markt gibt, weiß ich nicht.

Grüße, Nok

Hallo Dirk,
doch, sowas gibts. Ich komm bloß grade nicht auf den Namen. Glaub DDL oder so... Hier wird nur ein Booster an den PC angeschlossen, der Rechner selber spielt Zentrale. Das Timing dürfte übrigens kein Problem sein, heutige Rechner sind bei weitem schnell genug dafür.

Edit: DDL war richtig, die Variante für Windows heißt DDW. Der PC erzeugt das Digitalsignal und schickt es an den Booster. Der wiederum verstärkt es und speist es in die Anlage ein.

Viele Grüße
Carsten von 1001-digital

Hallo zusammen,

also das mit dem Timing ist für einen Standard PC heute kein Thema. Die haben mehr als genug Rechenleistung und IO-Performance. Und DCC ist ja auch nicht so kompliziert.

Der Knackpunkt sind die Pegel der Schnittstelle. Dafür wurden "früher" Zusatzkarten wie RS232 (V.24), RS485, GPIB etc in den PC eingebaut. Es gibt Digital-I/O Karten die diese Signale schaffen, aber die sind teurer als eine Zentrale.

Wenn du dir eine Lenzzentrale oder die OpenDCC anschaust, da ist ja nicht viel Rechenleistung drin.

Grüße

Hallo Dirk,

es gibt durchaus die Möglichkeit mit Software Lösungen, wo der PC eine Zentrale simulieren kann.
Allerdings ist der zusätzliche Hardwareaufwand über eine I/O - Port Steuerung nicht unerheblich und vor allem nur starr - einmal Zusatzkomponenten gebaut, nix mit ändern und du musst die Zusatzkomponenten für das Bindeglied selbst bauen.

Mit einer getrennten Digitalzentrale bist du wesentlich flexibler und du bist weder bei der PC-Hardware noch beim Steuerprogramm an nur einen bestimmten Hersteller gebunden.

Und zu guter Letzt - wie hoch willst du den Aufwand treiben? Wie flexibel soll alles sein? Hast du das nötige Wissen für den Selbstbau und die Programmierung?

gruß
hajo

Hi,
meiner bescheidenen Meinung nach bringt es keinen wirklichen Vorteil, das DCC Signal komplett in den PC zu ziehen. Sinnvoller ist es, eine Zentrale wie die OpenDCC Z1 zu verwenden. Vorteil:

- Kurzschlusserkennung
- Boosterfunktionalität
- zusätzliche Schnittstellen z.B. für BiDIB
- die Möglichkeit, einen Handregler anzuschließen
- Box mit Knopf, um auch mal ein Not-Aus einleiten zu können, wenn der PC abgestürzt ist

Der Markt für eine reine PC Schnittstelle ist meines Erachtens sehr klein, nur wenige wollen nur über den PC fahren, einige lehnen PCs komplett ab. Auch vom Preis her wird man hier keinen wirklichen Vorteil erlangen können: z.B. kostet die OpenDCC Z1 ca. 60 Euro, bei Stärz gibt es eine SX-Seriell Schnittstelle, die auch 40 Euro kostet - und die hat keinerlei Booster-Funktionalitäten.

Gruss,
Thomas.

Hallo
Ich habe das mal versucht und es ging ganz gut, allerdings flackerte das Spitzensignal immer rum, also nicht wirklich schön anzusehen! Ist allerdings auch schon wieder fast 10 Jahre her. Dieses Programm hatte einen Regler den man auf dem Bildschirm bedienen konnte. Habe es aber damals mit dem Abriss meiner Anlage wieder aus den Augen verloren. Weis jemand von Euch vielleicht wie es heute funktioniert? Druckerschnittstellen sind ja nicht mehr so up to date! ;o)
Lg Peter

Hallo Dirk,

abgesehen von den Kompomenten auf der Anlage gibt es folgende Funktionsgruppen:

Booster (erzeugt das Gleissignal),
Programmieren und auslesen der Lokdekoder (können nur manche Booster),
"Rückmeldeübersetzer" / Bussteuerung (kontrolliert den Verbindungsbus der Rückmelder und z.T. der Weichen- und Signaldekoder bzw. der Handgeräte),
Handregler (zur Steuerung von Loks und / oder Weichen, Signale),
Interface zum Computer und
"Intelligenz" (im PC wie von dir gewünscht oder in einer Zentrale).

Ich hoffe, die Aufzählung ist vollständig.
Heutige "klassische" Zentralen vereinen alle diese Funktionen. Es gibt aber auch -wie von Dir gewünscht- PC-Zentralen die die meisten (alle ?) obigen Funktionen können, die aber kein Bedienteil haben (und [fast] keine Intelligenz). Mir fehlt allerdings der Überblick um Dir konkrete Geräte nennen zu können.

Viele Grüße, Joni

Hallo,

recht nahe an der Idee "Digital" nur mit PC, ohne "Zentrale" kommt dieses Produkt:

http://www.hornby.com/elink-and-railmaster-combination-pack.html

(War auch mal in einer deutschen Version von Arnold angekündigt)


Gruß
Thomas

Hallo Dirk,
Es gibt so etwas. Nennt sich Compulok und ist eine reine Zentrale für DCC. mit S88 Rückmeldebus. Hat entweder einen RS232 oder eine USB2.0 Schnittstelle . Einen engebauten  Booster und einen automatisch umschaltbaren Programmieranschluß. Schau mal unter Digitale Modelleisenbahn, www.digibahn.de. Das dazugehörende aber zum Steuern der Loks nicht notwendige Automatikprogramm heisst Digibahn. Dieses läuft aber nur unter Win7 32bit nicht unter 64bit.

Gruß Gerd

Hallo,

wie ja alle schon festgestellt haben, ganz ohne externe Elektrik geht es eh nicht. Mindestens einen Booster braucht es.

Sollte man rückmelden wollen, brauchts auch dafür eine "Übersetzung" für den PC.

Ob man wirklich definitiv für immer ganz auf Handregler verzichten will, will auch gut überlegt sein....

Von daher denke ich auch, dass eine günstige Zentrale ohne viel Schnick-Schnack vermutlich die flexiblere Lösung ist. Auch kann man sich dann frei nach entsprechenden Steuerprogrammen umschauen.

Hi Dirk,

in meinen MoBa-Anfängen vor 2 Jahren habe ich mal mit DDX experimentiert, da ich anfangs nicht soviel Geld ausgeben wollte, weil ich mir nicht sicher war, ob das mit dem Moba-Hobby was wird.
Steuerung erfolgte über Rocrail mit einem Booster von Roco (10764) und einem selbst zusammengestoppelten Kabel von der RS232 zum Booster.
Allerdings ist DDX nicht ganz NEM-konform und bekommt ab ca. 3 fahrenden Loks echte Performance-Probleme....
Inzwischen setze ich BiDiB-Komponenten ein und bin hochzufrieden.

LG Alex

Hoi Freunde,

mit meiner Freeware CoNtrol geht das - aber wie u.a. hajo (#5) schreibt:
der Aufwand fängt dann mit den I/O-Ports an.

Die anzubinden ist auf verschiedene Arten möglich, auch mit USB.

Weiterhin ist es möglich, an einem alten PC (der reicht nämlich) die Hardwareports wie COM1-4, LPT1-3 usw. zu verwenden.

Ein "Kunde" von mir hat aktuell auf einer TT-Bahn 9 I/O-Platinen (RS485) mit jeweils 32 Ports im Betrieb damit, funktioniert prima:
http://i-robots.eu/sw/control/Control-Schalten-K1.png

Das Timing reicht alle Male, auch beim Schalten von Weichenstrassen mit Signalen, Stromlos... usw.

Einen Bericht darüber gibts ja schon lange, zur Info noch mal hier:
http://i-robots.eu/sw/control/

Doei
Trixi
________ ________     _<>__<>_
|_ www.i-robots.eu   _|__|------|-----|,,,,,,,,,._
-oo-----oo-''-oo-----oo-`'o"O-OO--OO-O"oo

Moin moin!

Bei Conrad wird dies hier angeboten:

http://www.conrad.de/ce/de/product/919211/Model...ueryFromSuggest=true

Ist ganz schön teuer. Kenne es selbst nicht.

Freundliche Grüße von
Hans-Jürgen.

Hoi Hans-Jürgen,

WinDigiPed braucht aber auch eine HW-Zentrale zum funktionieren soweit ich weiss.

Grüße
Alex

[quote nr=14 + 15 name= ]WinDigiPed braucht aber auch eine HW-Zentrale zum funktionieren soweit ich weiss.
[/quote]

Richtig - ohne Hardware ist dieses Produkt nicht verwendbar.
Und weiter unten im Text sind alle unterstützten Zentralen aufgelistet - das war dann wohl ein unpassender Beitrag zum Thema

gruß
hajo

Hallo Dirk,

hier kannst Du nachlesen, was für Nachteile eine Software-Zentrale hat:
http://wiki.rocrail.net/doku.php?id=ddx-de#nachteile

Wie Alex schon geschrieben hat, viel Sinn macht das nicht und viel sparen tust Du auch nicht. Du handelst Dir höchstens Probleme ein.

Grüße
Stephan

Ich habe seit einiger Jahren auf der N-Anlage und der G-Bahn RocRail mit DDX im einsatz (bis zu 10 loks gleichzeitig). Das ganze funktioniert einwandfrei wenn mann die von RocRail geprüften Decoder einsetzt. Die erwähnten Performance-Probleme kann ich nicht feststellen.

huk

Die Softwarezentrale hat das Problem,  dass das DCC Signal keine Lücken enthalten soll. Also muss man die RS232 Schnittstelle fragen wie viel denn in der Outqueue drin ist, so dass man immer genügend "nachfüllen " kann. Aber nicht zuviel. Über USB geht das oft nicht, da Treiber oder HW zu doof dazu. Bei einem "echten " IO Chip aber schon.

Ich hab auch schon versucht das DCC Signal aus einem FTDI im Bitbangmode zu generieren, ist aber an einem HW Bug den die meisten FTDIs haben gescheitert. Das hat aber mit RS232 nix zu tun, andere Baustelle.

Noch eine preiswerte fast-Zentrale ist der SPROG II.

Grüße,
Harald.

Hallo Dirk,
die Rechenleistung heutiger CPUs ist zwar recht hoch, aber jeder Interrupt kostet unheimlich Strafe (die hohe Rechenleistung wird bei den im Desktop-Bereich verbreiteten Architekturen letztlich durch sehr lange Pipelines erreicht, und die mögen Unterbrechungen im linearen Programmablauf so überhaupt nicht).

Weiterhin sind auch die verbreiteten Betriebssysteme nicht echtzeitauglich, Windows bietet z. B. eine Timerauflösung von min. 1ms (per Default 10ms), weniger geht über die Multimedia-Timer nicht. DCC braucht aber für die Darstellung von 0- und 1-Bits aber eine Zeitbasis von grob 50us.

Mit den High-Performance-Timern und Busy-Waiting (bei so hoher Task-Priorität, dass da keine Maus etc. mehr zuckt) kann man dann zwar was hinfrokeln, aber wer sich mit der Materie eingehend beschäftigt hat weiß, was es gerade mit diesen Timern für (Hardware-) Probleme gibt, und selbst die Umschalterei der Zeitbasis bei den Multimedia-Timern funktioniert nicht fehlerfrei und führt zu Sprüngen in der Systemzeit, was für einen reinen Steuerungsrechner aber vielleicht noch akzeptabel wäre.

Mit einem UART-Baustein wie weiter oben im Thread angesprochen kann man zwar ebenfalls was hinbasteln (das entschärft dann die Sache ein wenig, weil der UART-Chip dann das Bittiming macht), allerdings ist der klassische PC-UART 16550 auch nicht gerade der Weisheit letzter Schluss, was das Design angeht.

Ich habe mich bei der Entwicklung eines PC-basierten universellen Diagnose-Systems jahrelang mit diesen Problemen herumärgern müssen (ich spreche hier maßgeblich von Kommunikation per UART, bei anderen Bussen wie CAN oder VAN über eine passende Schnittstellenkarte war die Welt deutlich rosiger)...

Statt auf einer für den Zweck eigentlich untauglichen Hardware mit einem für den Zweck definitiv nicht brauchbaren Betriebssystem mit sehr viel Zeitaufwand zu versuchen, irgendwie etwas zustande zu bringen, das ein kleiner uC für 2..3€ aus dem ff kann, um am Ende etwas zu haben, das doch nicht zufriedenstellend funktioniert, halte ich persönlich für den falschen Ansatz.

Just my two Cents...

Gruß,
Torsten

Ich warte leider immer noch genau auf so ein Teil für 10 €. Mit einstellbarem Ackpulsdetektor auch für 30.

Grüße,
Harald.

Hallo zusammen,

und Danke für Eure Antworten.
Ich scheine also nicht der erste zu sein, der sich über so etwas Gedanken macht, man muss aber wohl auch mehr bedenken, als ich es getan hatte. Ich hatte mir selber über sie Datenmenge der Schnittstellen bei Echtzeitabfragen Gedanken gemacht, aber nicht über die Taktung.
Ich fand es nur in meinem vielleicht etwas naiven Gedankenwelt etwas unausgereift - bildlich gesprochen - mit einem Computer einen anderen "fernzusteuern" .Dann könnte man ja auch alles in einem lösen.

Nochmal Danke
Dirk

Hallo GemeiNde,

wäre es nicht denkbar das man den Spies einfach umdreht?
Ich meine damit das man eine Zentrale mit Merkmalen eines pc ausstatten könnte.

Ok ich hab von der technischen Seite nicht viel Ahnung aber ich könnte mir vorstellen das künftig immer mehr Hersteller drauf kommen das ihre Zentrale nen Internetanschluss braucht um update fähig zu bleiben. Erste Ansätze mit TCP/IP gibt es ja bereits.
Müsste dann noch ne Art Betriebssysten rein welches nen Browser versteht und ne Steuerungssoftware kann.
Dann noch Arbeitsspeicher und Festspeicher rein und nen HDMI Answchluss.

Das nur mal so in die Runde als Denkanstoss eines Ahnungslosen

Grüsst Toby

Hallo Toby,
also letztlich sowas wie die Ecos von ESU, den Commander von Viessmann, IB II von Uhlenbrock etc.? Klar, geht. Einem PC wird sowas aber immer unterlegen sein, sowohl was Bedienkomfort angeht als auch in der Leistung. Ich persönlich halte deswegen die Kombination von PC und normaler Blackbox-Zentrale für das beste Gespann. Aber mal sehen was die Zukunft so bringt :)

Viele Grüße
Carsten von 1001-digital

Wieso warten, wo's sowas längst gibt, z. B. http://hackaday.com/2013/08/07/a-5-arm-development-board/ . Bei Google übrigens gleich der zweite Treffer, wenn man mal die Begriffe ARM development board und cheap in den Raum wirft.

Das Ding brauchst Du nur noch passend mit dem Eingang eines Boosters zu verkabeln, schreibst dann zum einen eine einfache Software, mit der Du über USB die DCC-Pakete in eine kleine Queue (von ca. 20 Einträgen) reinreichst und tackerst das DCC-Signal am Booster-Ausgang raus. Dann denn passenden Treiber für das Betriebssystem aufsetzen und eine entsprechende Erweiterung für die Software Deiner Wahl schreiben (z. B. RocRail) und fertig ist die komplette Lösung.

Übrigens: Das Ding lässt sich auch gleich als Programmier- und Debugadapter verwenden (s. https://mchck.org/ ).

Ach ja: Solche Starter-Kits für wenig Geld gibt's wie Sand am Meer, z. B. http://de.rs-online.com/web/p/entwicklungskits...ocontroller/7458434/ . Ich hab' mir einfach mal die erstbeste Lösung raus gepickt.

Und andere, die auf die 10€ Billiglösung mit sauberem Timing warten machst Du damit ebenfalls eine große Freude...

Und nein, das ist keinesfalls sarkastisch gemeint - andere haben sicherlich einiges an Mann-Jahren in die Entwicklung von Software wie RocRail gesteckt, vom Himmel ist die auch nicht gefallen.

Warum also nicht mal der Gemeinde der Nutzer und Entwickler freier (im Sinne von frei verfügbaren Quellen und kostenfrei) etwas beisteuern, statt sich nur hinzustellen und zu fordern???

Und um gleich mal entsprechenden Kommentaren zuvorzukommen - ich habe meinen Beitrag an anderen Stellen durchaus schon geleistet, so sind z. B. im VDR schon ein paar Ideen von mir drin (auch wenn Klaus den endgültigen Code dann gerne nach seinen eigenen Vorstellungen schreibt), in einem der wichtigen ARM Programmiertools (lpcprog vo Martin Maurer) wirst Du meinen Namen mittlerweile ebenfalls mehrfach in der History finden, im Linux-Kernel hatte ich ebenfalls über einen längeren Zeitraum Atari-Netzwerktreiber drin etc. etc.

Viele Grüße,
Torsten

Hallo,

es muss nicht mal ein ARM sein. Das ist für Anfänger vielleicht zu schwierig. Einfache DCC Aufbereitung geht schon mit einem AVR, also z.B. Arduino Uno plus Motor Shield, und wenn man will, reduziert man das auf einen Tiny84 und einen L272. Da fällt der Booster auf gleich weg.
Bei der Minibox verwenden die IIRC sogar noch einen primitiven PIC zur reinen Gleissignalerzeugung (ok, das Queuing macht da ein zweiter, größerer PIC).


Oh ja, dem möchte ich mich vollinhaltlich anschließen.

Grüße, Peter W.

Hallo Carsten. und Alle
der Viessmann Commander geht sicher schon in die Richtung. Was dem noch fehlt ist halt ein Anschluss für nen Monitor und ne umfangreichere Software mit der auch ne Automatisierung möglich wäre.
Mein Grundgedanke war halt; wenn der PC nicht zur Zentrale werden kann so wird halt die Zentrale zum PC.
Was den heutigen Zentralen mMn fehlt ist halt ne komfortable Bedienung wie am PC und eine ausreichend grosse Softwarebasis die auch ne halb/vollautomatische Steuerung ermöglicht.
Da ist der Lösung Zentrale + PC sicher noch nichts entgegen zu setzen.

Grüsse Toby

hi,
wie wäre es damit http://yaasan.mints.ne.jp/gateway/index.html  

Gruß
Arne

Hi,

guckst Du hier http://www.sprog-dcc.co.uk/about_sprogII.shtml

In D bei Passmann zu beziehen.

Gruß
Dieter

Hi zusammen,

wenn ich da Viessmann Commander oder ESU Ecos lese und die dann vielleicht noch mit Internetanschluss und einem "PC"-Betriebssystem aufgepeppt - was werden die dann kosten? Der Commander liegt jetzt schon jenseits der 600,--.

Wenn ich da gegenrechne mit irgendeinem alten Rechner (ich hab meinen HP AMD64 um 25,-- erstanden + neue Tastatur, Keyboard, Maus nochmal 100,--), Linux drauf, dazu BiDiB GBMMaster um 85,--, gesteuert mit Rocrail ist um gut 200 Euronen alles beisammen.

Da meine Anlage im Endausbau etwa 15 GBMNodes mit ca. 400 Belegtmeldern umfassen wird, habe ich inzwischen auf einen QuadCore PC umgestellt (300,--), an dem der Master hängt und 2 ausrangierte PCs (geschenkt) als Clients.
Und da hab ich dann halt nebenbei im MoBa-Zimmer noch Musik und Internet und und und bei weitem noch immer günstiger als eine Komfort-Zentrale.
Die haben sicher auch Ihre Berechtigung, wenn sich jemand mit dem Thema PC-Steuerung überhaupt nicht auseinandersetzen will, sind aber für reine "Handfahrer" auch wieder over-Engineering.

Alex

Hallo Peter,
natürlich führen viele Wege ans Ziel. Ich kenne die Arduino-Plattform persönlich nicht, aber wenn da ein Basissystem geliefert wird, das im us-Bereich vernünftige Timings macht und komfortable Libraries dabei sind, warum nicht?

Gerade die ARMs ab der Cortex-Familie halte ich persönlich aber für extrem anwenderfreundlich. Für meinen Beleuchtungsdecoder habe ich das System aufs "nackte Metall" aufgesetzt, selbst die Initialisierung geht bei den "Cortex"en bereits vollständig in C, während man sich speziell auf den ganz kleinen Krüppeln wie den PICs dann doch eher in Assembler abplagt (auf einer sehr rudimentären Architektur).


Meine Überlegungen gehen derzeit ebenfalls in Richtung OpenDCC. Den Commander besitze ich derzeit noch, da die Software-Entwicklung aber stagniert und von der ehemals angekündigten Hardware bis heute nichts verfügbar ist, würde ich das Gerät niemandem ernsthaft empfehlen.

Viele Grüße,
Torsten

Eh, ich wollte nix fordern. Muss ich jetzt meinen Open-Source CV einstellen? So "Kleinzeugs" ohne OS ist allerdings nicht meine Spezialität.

Gruß,
Harald.

Hallo,


Das Timing bei DCC ist nicht sehr kritisch, es wurde ja dereinst mit einfachen MCUs codiert und decodiert. Diese alten Controller werden ja heute praktisch von jedem aktuellen PIC, AVR und natürlich ARM weit geschlagen. Wenn man das Gleissignal im Timer-Interrupt erzeugt, ist die Anforderung an die CPU für die reine Codierung nicht hoch.
Ein anderes Kapitel sind die Themen Priorisierung, Refreshing, Queuing und Purging - also wie man die einzelnen Befehle in der geeigneten Reihenfolge eintaktet (z.B. nicht unterschiedliche Befehle an gleiche Adressen unmittelbar hintereinander setzen), welche Kommandos zyklisch und mit welcher Frequenz wiederholt werden sollen (F-Tasten) und welche Befehle man wann wieder außen vor lassen kann. Diese Intelligenz macht eine gute DCC Zentrale aus. Da kann es schon sinn machen, dass man einen kleineren Controller das Signal aufbereiten und die "Business Logik" in einem leistungsfähigen Core berechnet lässt.

Grüße, Peter W.

Hallo Peter,
das habe ich auch nicht geschrieben.

Natürlich kann jeder schibbelige halbwegs aktuelle Controller das Gleissignal erzeugen (selbst auf einem nach heutigen Maßstäben lahmen C64 bekommt man das wohl hin).

Es ging mir an dieser Stelle ums Betriebssystem, das bei den Arduinos ja dazugehört (bei den größeren sogar ein Linux - da dürfte es wieder sehr aufwendig werden, weil man für die Erzeugung des Timings dann wohl Kernel-Treiber schreiben muss).

Wenn Du eben ein fertiges System hast, musst Du mit dem arbeiten, was das System kann oder anfangen das Betriebssystem zu umgehen (ich habe mal eben geschaut - bei den Arduino Beispielen habe ich keines gefunden, das Interrupt-Routinen implementiert und alle Timings in den Beispielen basierten auf 1ms-Ticks, für ein DCC-Signal um mehr als eine Größenordnung zu langsam). Um das System zu umgehen muss man es aber genau kennen und analysieren, ich persönlich finde das weit weniger anwenderfreundlich als gleich aufs nackte Metall mit ein paar Basis-Bibliotheken (bei ARM eben CMSIS) aufzusetzen.

Der blutige Laie hat natürlich ein schnelles Erfolgserlebnis, wenn er mit 5 Zeilen Code 'ne LED im Sekundentakt blinken lassen kann, weil alles andere schon da ist...

Viele Grüße,
Torsten

Die Starterkitlösung für 5 €, wie taucht die in meinem OS auf? Irgendeine standard USB device? Hab ja keine Lust einen Treiber zu schreiben.

Grüße,
Harald.

Moin Harald,
da das Ding auch als Programmieradapter genutzt wird, denke ich mal, dass da eine serielle Emulation verwendet wird (ein serieller Bootloader im ROM ist bei ARMs ja üblich). Die könnte man dann auch als Basis für die eigene Firmware verwenden. Im Zweifelsfalle: Selber nachlesen macht schlau...

Gruß,
Torsten

Hoi Harald,

es wird immer entweder ein COM (also serieller) oder LPT (also paralleler) Port installiert, z.B. COM 19 oder LPT2 oder so.

Jede Software verlangt in den Settings die EIngabe dieses Ports, damit es weiß, wie und wo die Daten gelesen/geschrieben werden sollen.

Einen Treiber zu coden ist daher nicht nötig

Doei
Trixi
________ ________     _<>__<>_
|_ www.i-robots.eu   _|__|------|-----|,,,,,,,,,._
-oo-----oo-''-oo-----oo-`'o"O-OO--OO-O"oo

Hallo Torsten,


Arduinos haben kein OS, nur ein gemeinsames IDE und ein gemeinsames C++ Framework basierend auf GCC plus verschiedene Libs - im Gegensatz zu Raspberry PI et al.


Ich schon

Bei ARMs gibt es verschiedene Bootloader. Bei manchen Boards kann man die auch auswechseln. Verbreitete Implementationen sind serielle (COM-Port) oder Flash Drive Emulationen. Der Prozessor (z.B. NXP über die native USB-Schnittstelle) selbst bzw. das jeweilige Board (meist über einen Co-Prozessor, der auch das Debuggen erlaubt) taucht dabei als Wechsellaufwerk im System auf, wie z.B. ein USB-Stick. Man kopiert einfach das compilierte Programm in einem speziellen Format auf das Laufwerk. Dazu benötigt man keine speziellen Treiber, womit das Verfahren völlig Betriebssystem unabhängig ist.
Um die Bootloader muss man sich für einfache Anwendungen erst mal gar nicht kümmern, da sie vom Hersteller fertig zur Verfügung gestellt werden. Nur bei speziellen Anforderungen (zeitkritischer Start, eigene Upload-Protokolle, CRC oder Verschlüsselung, etc.) muss man den Bootloader ändern und/oder in die eigene FW integrieren.

Grüße, Peter W.

Hallo Dirk,

nach langem Gedankenchaos zu genau diesem Thema möchte ich nun auch etwas zu dem Thema beitragen.
Vor dieser Frage stand ich auch, normal müsste man doch nur so einen seriellen Adapter mit ner Software brauchen und alles wäre gut.
Nach etwas Rumsuchen im Netz hab ich viele interessante Dinge gefunden wie DDL/DDW oder SRCP.
Meist waren es irgendsolche Basteleien von Freaks, die man als normaler Lötkolbenschwinger zwar nachbauen konnte, diese aber nie verstanden hat. Vom Support ganz zu schweigen.
Zu dem Punkt "Signal direkt im PC erzeugen" kann ich nur soviel sagen, dass wenn dies der Fall ist, du das Zeitkritisch (und das sind die digitalen Steuerungen nun mal) nur über die serielle/parallele Schnittstelle raus bekommst. Selbst USB-Adapter sind dort nicht mehr Zeitkritisch und sind nicht mehr das Optimum.
So habe ich halt mit Google und ein paar Suchworten  und der mir zur Verfügung stehenden Hardware (Raspberry/rudimentäre Linunxkenntnisse) doch schon einiges in Erfahrung bringen können.
SPROG wäre hier zu nennen, was preislich zwar recht günstig, nicht jedoch "fast um sonst" ist.
Trotzdem blieb immer das Problem mit dem Stromverbrauch. An den angebotenen Boostern orientiert, wirst du auch schnell feststellen, dass eine komplette Anlage niemals ohne Booster zu betreiben ist.
Bei mir war es letztendlich so, dass ich mich gedanklich in Richtung BiDiB und den GBM-Bausätzen bewegt habe.
Mir gefiel das Gesamtpaket aus ner "Zentrale" mit USB- und XPressNet-Schnittstelle und Anbindung an einen PC/Raspberry zu einem noch annehmbaren Preis.
S
Somit werde ich, Stand der jetzigen Planung, wohl auf einen GBM zurückgreifen, diesen dann per Raspberry in mein Netzwerk integrieren und dann mit Tablet und der in der von Fleischmann wieder mal verschobenen Starterpackung integrierten MultiMaus meine Digitalanlage aufbauen.

So, das war mein Senf zu diesem Thema.

Gruß
Jan

Was ich mir gedacht hab: Ein Paketloop den ich reinladen kann und der cyklisch rausretaktet wird. Wenn eine Geschwindigkeitsänderung vorgenommen wird, dann baut der Computer einen neuen Paketloop mit dem wichtigsten Paket am Anfang und bei der nächsten Paketgrenze wird der Paketloop mit dem Neuen ersetzt. Am Anfang, wenn kein Paketloop geladen ist, takten wir Idlepakete raus.

Nachteil: Der ganze Paketloop muss bei jeder Änderung neu reingereicht werden, sollte aber nix machen, da USB so viel schneller ist als DCC, sollte also auch mit einem Paketloop von 100 Einträgen zu machen sein.

Vorteil: Die ganze Purginglogik ist im Computer.

Das sollte zum Fahren reichen. Zum Programmieren und Schalten braucht man vieleicht noch einen Mechanismus nur einzelne Pakete einmal auszugeben (und dann den Loop wieder aufnehmen).

Gruß,
Harald.

Hallo Jan
Bei freebit.nl sind die Startset's Ende September eingetroffen. Habe ich mir in Locher (NL) angesehen und nicht gekauft, da ich das Geld bei einem Händler aus der Region lassen wollte. Da das ganze immer noch nicht in D verfügbar ist, habe ich mir vorige Woche das DR-Set mit BR115 und Multimaus von der Eurospoor in Utrecht mitgebracht. Der Ausflug hat sich gelohnt: 10% Messerabat und richtig viele Anlagen zu sehen.
Gruß
André