Discussion:
[DCC] Protokollfrage
(zu alt für eine Antwort)
Jochen Dolze
2007-03-28 20:56:33 UTC
Permalink
Hallo NG,

ich hätte da mal eine Frage zur NEM671. In Abschnitt 5.1 steht etwas von
5 ms Distanzzeit. Was gibt eine Zentrale dabei aus? Eins-Bits?

Wenn das so ist, frage ich mich, warum nicht einfach mind. 43
Präambel-Bits gefordert werden, dann hat man immer 5 ms Abstand zwischen
zwei Paketen.

Gruß

Jochen
Arnold Huebsch
2007-03-29 10:04:40 UTC
Permalink
Post by Jochen Dolze
ich hätte da mal eine Frage zur NEM671. In Abschnitt 5.1 steht etwas von
5 ms Distanzzeit. Was gibt eine Zentrale dabei aus? Eins-Bits?
Im Grunde geht es nur darum, dass normalerweise nicht 2 Pakete
unmittelbar hintereinander an die gleiche Adresse gesendet werden
sollen. Der Grund dafür, schwache CPUs nützen die Zeit in der Daten an
andere Adressen gesendet werden um interne Dinge zu berechnen. Da der
prozessor zu dem Zeitpunkt weiß dass er nicht gemeint ist, kann er die
gesendeten Daten ja ignorieren und muss erst nach der nächsten Präambel
wieder aufpassen.
Post by Jochen Dolze
Wenn das so ist, frage ich mich, warum nicht einfach mind. 43
Präambel-Bits gefordert werden, dann hat man immer 5 ms Abstand zwischen
zwei Paketen.
Ja das kann man machen mehr Präambelbits zu senden, nur das wären weit
mehr an die 100 wenn ich das so im Kopf überschlagsmäßig rechne.
Alternativ kann man ein Idle Paket senden. Generell zu viele
Präambelbits zu senden will man nicht weil das Datenbandbreite kostet
und eben normalerweise weil ja mehrere Adressen refreshed werden so und
so nicht notwendig ist.
--
|[#]| . \=/ Arnold Hübsch
|[_]|--/^\--H<| http://www.huebsch.at/train
|_ _________ \ http://amw.huebsch.at
_o (x)-(x)-/oo\\___ http://www.waschzettel.at
Reinhard Mueller
2007-03-29 18:22:35 UTC
Permalink
Moin moin,
Post by Jochen Dolze
ich hätte da mal eine Frage zur NEM671. In Abschnitt 5.1 steht etwas
von > 5 ms Distanzzeit. Was gibt eine Zentrale dabei aus? Eins-Bits?
Nein, das sollte sie nicht!

In den meisten Fällen wird mehr als eine Lok gesteuert und dann
gibt es immer was zu senden. Bei zwei Loks eben alternierend.
Die Pause muss ja nur zwischen Paketen an die _selbe_ Adresse
eingelegt werden.

Wenn wirklich nur eine Adresse betrieben wird, kommen da Idle-
Packets rein, die gut 5 ms lang sind. Kürzere Pakete gibt es nicht,
es reicht also, immer ein Paket dazwischen zu haben. Es können
aber auch Daten in einem anderen Protokoll übertragen werden.
Deshalb steht dort nicht, dass ein anderes Paket dazwischen sein
soll.

Ein Senden von vielen Eins-Bits hat zwei Nachteile:
Erstens verschenk man in den meisten Fällen Datenrate, zweitens
kommt man mit langen Paketen und langen Lücken schnell in die
Situation, dass bei zwei gestörten Paketen die 30ms-Regel nicht
mehr eingehalten wird.

Zudem kann ein Decoder nach dem Erkennen einer fremden Adresse für
mindestens zwei Byte-Zeiten weghören und erst bei der nächsten
Präambel wieder einsynchronisieren. Das gibt ihm Zeit für
allgemeine Berechnungen. Kommen lauter Eins-Bits, muss er immer
mit dem Beginn eines Paketes rechnen.
Post by Jochen Dolze
Wenn das so ist, frage ich mich, warum nicht einfach mind. 43
Präambel-Bits gefordert werden, dann hat man immer 5 ms Abstand
zwischen zwei Paketen.
Das wäre wirklich Verschwendung von Datenrate!

Gruß,
Reinhard
Jochen Dolze
2007-03-29 19:25:38 UTC
Permalink
Hallo Reinhard,
Post by Reinhard Mueller
Erstens verschenk man in den meisten Fällen Datenrate, zweitens
kommt man mit langen Paketen und langen Lücken schnell in die
Situation, dass bei zwei gestörten Paketen die 30ms-Regel nicht
mehr eingehalten wird.
Zudem kann ein Decoder nach dem Erkennen einer fremden Adresse für
mindestens zwei Byte-Zeiten weghören und erst bei der nächsten
Präambel wieder einsynchronisieren. Das gibt ihm Zeit für
allgemeine Berechnungen. Kommen lauter Eins-Bits, muss er immer
mit dem Beginn eines Paketes rechnen.
Das macht wirklich Sinn. Leider wird es so [Adressauswertung und/oder
Idlepacketsenden] etwas schwerer, meinen DCC-Encoder umzusetzen ;)

Danke für die Infos.

Gruß

Jochen
Stefan Bormann
2007-04-01 09:41:59 UTC
Permalink
Post by Jochen Dolze
Das macht wirklich Sinn. Leider wird es so [Adressauswertung und/oder
Idlepacketsenden] etwas schwerer, meinen DCC-Encoder umzusetzen ;)
Kommt darauf an, was du erreichen moechtest.
Wenn du *viele* aktive Loks (ich sag mal >>10) gleichzeitig
unterstuetzen moechtest, musst du dir sowieso eine Strategie
ueberlegen, wie du die duenne Bandbreite gut nutzt. Z.B. kannst
du Aenderungen mit hoeherer Prioritaet und/oder Funktions-
Packete seltener senden. Dann ist die Einhaltung der Abstands-
Regel relativ simpel.
--
Stefan Bormann
eMail: ***@gmx.de
Homepage: http://www.nord-com.net/stefan.bormann
Jochen Dolze
2007-04-01 21:29:57 UTC
Permalink
Post by Stefan Bormann
Kommt darauf an, was du erreichen moechtest.
Bis jetzt habe ich einen Atmel ATTiny2313 der zyklisch über einen MAX232
ein Datenpaket ständig wiederholt. Leider hat der ATTiny2313 nur 128
Bytes Speicher, da wird ein Refresh-Algorithmus schwierig ;) Ich gedenke
gerade entweder einen Atmega8 zu nehmen oder 16kBit SPI-FRAM.

Ziel vom Ganzen wäre es, ein (USB2Serial-fähiges) serielles
Hardwareinterface für den srcpd zu schaffen, das sich nur mit der
Signalerzeugung beschäftigt. So wie der DCCSignaler, nur eben OpenSource.
Post by Stefan Bormann
Wenn du *viele* aktive Loks (ich sag mal >>10) gleichzeitig
unterstuetzen moechtest, musst du dir sowieso eine Strategie
ueberlegen, wie du die duenne Bandbreite gut nutzt.
Ob ich das Protokoll verstehe? Wenn ich eine Lok vorwärts fahren lassen
will und diese soll F3 angeschaltet haben, muss ich zyklisch "fahre
vorwärts" und "mach F3 an" schicken? Die 30ms-Regel funktioniert doch
rein theoretisch gar nicht bei mehr als 3 Loks, wenn ich Wolfgang Kufers
Ausführungen richtig verstanden habe und im Mittel eine DCC-Meldung ca.
10ms benötigt (eigene überschlägige Berechnungen ergaben ein Minimum von
6ms). Oder gilt die wirklich nur für Decoder die auf Analogbetrieb
eingestellt sind? Wenn ich also 10 Loks hintereinander refreshe, hat
jede Lok einen Zyklus von 100ms.

Gruß

Jochen
Peter Wagner
2007-04-01 22:42:30 UTC
Permalink
Post by Jochen Dolze
Signalerzeugung beschäftigt. So wie der DCCSignaler, nur eben OpenSource.
Wenn Du ein Open Project machst bitte designe es mit Hardware die man
halbwegs normal kaufen kann.

Wie viel Speicher braucht man für den gewünschten Zweck? Man muss ja
nicht 10000 Adressen cachen können.
Post by Jochen Dolze
Ob ich das Protokoll verstehe? Wenn ich eine Lok vorwärts fahren lassen
will und diese soll F3 angeschaltet haben, muss ich zyklisch "fahre
vorwärts" und "mach F3 an" schicken?
Ja. Du schickst alternieren das Fahrstufentelegramm und das Funktionen-
telegramm an die Adresse, unter Berücksichtigung des Mindestabstandes
zweier Pakete an dieselbe Adresse.

Daraus ergibt sich das Minimum Timing.
Post by Jochen Dolze
Die 30ms-Regel
Das verstehe ich auch nicht.

Das Maximum Timing ergibt sich aus der Anzahl der gleichzeitig aufgerufenen
Adressen.

Ein Decoder behält so lange die Fahrtrichtung, Geschwindigkeit und die
Funktionen bei, bis er andere Informationen erhält - jedenfalls so lange
er Spannung hat und ein für ihn gültiges Digitalformat erkennt.

Einige Produkte am Markt retten diese Information über den stromlosen
Zustand für eine gewisse Zeit (Brown-Out Schaltung, Geschwindigkeits-
speicher). Dadurch macht die Lok nach einer kurzen Spannungsunterbrechung
da weiter, wo sie vorher aufgehört hat bis ein anderweitiger gültiger
Befehl decodiert wurde.

Ist der Geschwindigkeitsspeicher nicht vorhanden, oder ausgeschaltet,
oder ist die Speicherzeit abgelaufen, steht die Lok nach einem Aussetzer
erst mal bis ein gültiges Fahrstufen-Telegramm decodiert wurde. Dann
erfolgt der Wiederanlauf mit der programmierten Geschwindkeitskennlinie.
Post by Jochen Dolze
6ms). Oder gilt die wirklich nur für Decoder die auf Analogbetrieb
eingestellt sind?
Das hat keinen Einfluss.
--
SchöNe Grüße aus WieN,
Peter Wagner. Spur N, DCC.
Technischer Referent des Modelleisenbahnclub "Die 160er"
Jochen Dolze
2007-04-02 23:02:47 UTC
Permalink
Post by Peter Wagner
Wenn Du ein Open Project machst bitte designe es mit Hardware die man
halbwegs normal kaufen kann.
Wie viel Speicher braucht man für den gewünschten Zweck? Man muss ja
nicht 10000 Adressen cachen können.
Ich denke mit 1024 Bytes müsste man auskommen. Hoffe ich ;)

Gruß

Jochen
Roger Schwentker
2007-04-03 05:45:48 UTC
Permalink
Post by Jochen Dolze
Post by Peter Wagner
Wie viel Speicher braucht man für den gewünschten Zweck? Man muss ja
nicht 10000 Adressen cachen können.
Ich denke mit 1024 Bytes müsste man auskommen. Hoffe ich ;)
640 KB should be enough für everyone. [Bill Gates]

Gruß
Roger Schwentker
***@regioconnect.net
--
Wenn der Umsatz stimmt, ist Toleranz kein Problem. [Jürgen Becker]
Werner Falkenbach
2007-04-05 06:21:17 UTC
Permalink
Hallo Roger,
Post by Roger Schwentker
640 KB should be enough für everyone. [Bill Gates]
Ja. Und mehr als 80 Lokadressen braucht auch niemand, und die Erde ist
eine Scheibe.

Grüße
Werner
--
MODELLEISENBAHN FÜR KINDER ==> http://www.kinderbahn.de
THEMA SCHMALSPURBAHN ==> http://www.thema-schmalspurbahn.de

mailto:***@werner-falkenbach.de (das kommt schon an)
Matthias Trute
2007-04-02 07:29:29 UTC
Permalink
Post by Jochen Dolze
Post by Stefan Bormann
Kommt darauf an, was du erreichen moechtest.
Bis jetzt habe ich einen Atmel ATTiny2313 der zyklisch über einen MAX232
ein Datenpaket ständig wiederholt.
Das klingt wie locobuffer, nur mit Refresh/Wiederholung. Wo gibt's
das Projekt zu sehen? ;=)
Post by Jochen Dolze
Leider hat der ATTiny2313 nur 128
Bytes Speicher, da wird ein Refresh-Algorithmus schwierig ;) Ich gedenke
gerade entweder einen Atmega8 zu nehmen oder 16kBit SPI-FRAM.
Refresh kann auch der srcpd übernehmen. IMHO wäre der DDL Code
ein guter Einstieg. Der macht derzeit _alles_ da muß für dein
USB-Interface eigentlich nur abgespeckt werden (timing ist nicht
mehr ganz so kritisch).

Planst Du einen FTDI (oder ähnlich) zwischenzuschalten oder soll der
u-Controller auch das USB-Protokoll übernehmen? Dann würde ich
eher zum atmega(8+) raten.
Post by Jochen Dolze
Post by Stefan Bormann
Wenn du *viele* aktive Loks (ich sag mal >>10) gleichzeitig
unterstuetzen moechtest, musst du dir sowieso eine Strategie
ueberlegen, wie du die duenne Bandbreite gut nutzt.
Ein Grund mehr für eine Arbeitsteilung.


Gruß
Matthias

PS: Hat eigentlich schon mal jemand darüber nachgedacht, einen SRCP
Server in einen WLAN Router einzubauen? (open|free)wrt scheint da noch
Platz zu haben.
Reinhard Mueller
2007-04-02 16:45:46 UTC
Permalink
Moin moin,
Post by Matthias Trute
Post by Jochen Dolze
Bis jetzt habe ich einen Atmel ATTiny2313 der zyklisch über
einen MAX232 ein Datenpaket ständig wiederholt.
Das klingt wie locobuffer, nur mit Refresh/Wiederholung.
Was hat das bitte mit LocoNet zu tun?
Ich kenne den LocoBuffer bisher nur als Interface zwischen
LocoNet und einem PC - ohne jede Beziehung zum DCC-Protokoll.
Post by Matthias Trute
Refresh kann auch der srcpd übernehmen. IMHO wäre der DDL Code
ein guter Einstieg.
Die Frage ist, was das werden soll. Eine eigenständige Zentrale
oder nur eine Umsetzung der Daten von einem PC.

Gruß,
Reinhard
Matthias Trute
2007-04-02 18:00:33 UTC
Permalink
Post by Reinhard Mueller
Moin moin,
Post by Matthias Trute
Post by Jochen Dolze
Bis jetzt habe ich einen Atmel ATTiny2313 der zyklisch über
einen MAX232 ein Datenpaket ständig wiederholt.
Das klingt wie locobuffer, nur mit Refresh/Wiederholung.
Was hat das bitte mit LocoNet zu tun?
Außer der Idee, das das Zusatzgerät am PC sich
mit dem Timing von ansonsten unveränderten
Datenpaketen beschäftigt, nichts.
Post by Reinhard Mueller
Ich kenne den LocoBuffer bisher nur als Interface zwischen
LocoNet und einem PC - ohne jede Beziehung zum DCC-Protokoll.
Ich auch. Aber ein Loocbuffer ohne PC ist reichlich sinnfrei.
Jochens DCC Generator mit USB Anschluß habe ich als Gerät verstanden,
das (z.B. vom PC) vorgefertigte DCC Pakete über USB mehr oder
weniger "am Stück" empfängt und dann für einen Booster
timinggerecht aufbereitet.
Post by Reinhard Mueller
Post by Matthias Trute
Refresh kann auch der srcpd übernehmen. IMHO wäre der DDL Code
ein guter Einstieg.
Die Frage ist, was das werden soll. Eine eigenständige Zentrale
oder nur eine Umsetzung der Daten von einem PC.
Ich habe letzteres verstanden. Ersteres wäre eher was wie
opendcc

Gruß
Matthias
Jochen Dolze
2007-04-02 22:57:36 UTC
Permalink
Post by Reinhard Mueller
Die Frage ist, was das werden soll. Eine eigenständige Zentrale
oder nur eine Umsetzung der Daten von einem PC.
Ich baue doch nicht OpenDCC nach ;)

Das soll "nur" eine Umsetzung der Daten von einem PC werden. Mit
einem Modul für srcpd.Ohne den PC in die Knie zu zwingen.

Gruß

Jochen
Jochen Dolze
2007-04-02 22:47:07 UTC
Permalink
Post by Matthias Trute
Post by Jochen Dolze
Bis jetzt habe ich einen Atmel ATTiny2313 der zyklisch über einen MAX232
ein Datenpaket ständig wiederholt.
Das klingt wie locobuffer, nur mit Refresh/Wiederholung.
Ja so ähnlich. Als ich mir den srcpd anschaute dachte ich mir: Super,
endlich mal ein *richtig* modulares System. Nicht immer alles
(=Booster,Rückmelder,Handregler und Signalerzeugung) in eins
reingemurkst und als "Digitalsystem" mit Fußangel sondern schön modular
zum selberaussuchen.

Nur die Signalerzeugung mittels externer Zentrale oder DDL gefiel mir
nicht. Es sollte ein autarker Signalerzeuger werden.

Da ich Linux nur in einer VMWare laufen habe, sollte srcpd auch von dort
aus funktionieren. DDL hat da leider wenig Chance ;)
Post by Matthias Trute
Wo gibt's
das Projekt zu sehen? ;=)
Bis jetzt leider nur auf meiner Festplatte.
Post by Matthias Trute
Refresh kann auch der srcpd übernehmen. IMHO wäre der DDL Code
ein guter Einstieg. Der macht derzeit _alles_
Leider ;) - Ich möchte diesen so ziemlich entlasten. Bis jetzt ist der
RS232 Code noch nicht implementiert. Der Rest ist so aufgebaut, das der
Speicher sequentiell als Pakete ausgegeben wird, d.h. wenn im Speicher
folgendes steht:

0x02 [0x00 0xFF] 0x03 [0x03 0x65] 0x00

werden zwei Pakete (die in eckigen Klammern) gesendet.

Der Aufbau ist bis jetzt folgendermassen: Anzahl Bytes, Bytes. Das
Prüfbyte wird intern berechnet und dazugehängt. Die letzte Null beendet
die Ausgabe, danach werden nur noch Präambel-Bits gesendet (was aber
nicht gut ist und noch abgeändert werden muss).

Mit einem Atmega8 könnte man nun per RS232 1000 vorgefertigte Bytes
übergeben und dann werden 250 Pakete mit jeweils 4 Bytes ausgegeben.
Das dauert dann ca. 2,5 Sekunden bis alle draussen sind. Ist aber nicht
wirklich dynamisch und zu gebrauchen.

Hier muss ich noch was tun.
Post by Matthias Trute
da muß für dein
USB-Interface eigentlich nur abgespeckt werden (timing ist nicht
mehr ganz so kritisch).
Planst Du einen FTDI (oder ähnlich) zwischenzuschalten oder soll der
u-Controller auch das USB-Protokoll übernehmen?
Ich plane kein USB-Interface, da es USB2Serial-Adapter für 10 Euro inkl.
Versand gibt. Da kostet der FTDI 6,30 Euro und aufs Anlöten des LQFP-32
Package habe ich keine große Lust ;)
Post by Matthias Trute
Dann würde ich
eher zum atmega(8+) raten.
Ich denke der Atmega8 ist eine gute Wahl, 1024 Bytes SRAM und für 1,65
Euro auch wirklich günstig zu haben.

Gruß

Jochen
Martin Schoenbeck
2007-04-02 09:35:54 UTC
Permalink
Hallo Jochen,
Post by Jochen Dolze
Bis jetzt habe ich einen Atmel ATTiny2313 der zyklisch über einen MAX232
ein Datenpaket ständig wiederholt. Leider hat der ATTiny2313 nur 128
Bytes Speicher, da wird ein Refresh-Algorithmus schwierig ;) Ich gedenke
gerade entweder einen Atmega8 zu nehmen oder 16kBit SPI-FRAM.
Laß ihn einfach zwei Datenpakete im Wechsel wiederholen. Dann muß die
drüberliegende Schicht nur darauf achten, daß die nicht an dieselbe Adresse
gehen.

Gruß Martin
--
Bitte nicht an der E-Mail-Adresse fummeln, die paßt so.
Jens Schmidt
2007-04-02 11:21:08 UTC
Permalink
Post by Jochen Dolze
Ob ich das Protokoll verstehe? Wenn ich eine Lok vorwärts fahren lassen
will und diese soll F3 angeschaltet haben, muss ich zyklisch "fahre
vorwärts" und "mach F3 an" schicken?
Du *musst* nicht, aber es ist sinnvoll. Als extremer anderer Fall wäre auch
"fahre vorwärts", "mach F3 an" je einmal und dann nur noch Idle-Packets.
Allerdings genügt dann eine kleine Stromunterbrechung (oder eine mittlere,
je nach Decoder), damit alles steht.
Post by Jochen Dolze
Die 30ms-Regel funktioniert doch
rein theoretisch gar nicht bei mehr als 3 Loks, wenn ich Wolfgang Kufers
Ausführungen richtig verstanden habe und im Mittel eine DCC-Meldung ca.
10ms benötigt (eigene überschlägige Berechnungen ergaben ein Minimum von
6ms).
Es muss nicht jeder Decoder alle 30ms angesprochen werden. Es muss nur
zwischen zwei Startbits von DCC-Paketen maximal 30ms vergehen. Wenn Du also
ein DCC-Paket mit XXms gesendet hast, darfst Du maximal (30-XX)ms was
anderes (z.B. SX oder MM) senden, bis wieder ein DCC-Paket kommt. Ein
Multiprotokolldecoder im DCC-Modus könnte sonst auf die Idee kommen, nach
Paketen in anderen Formaten zu suchen.
Post by Jochen Dolze
Oder gilt die wirklich nur für Decoder die auf Analogbetrieb
eingestellt sind?
Die 30ms gelten für alle Decoder. Danach könnte auch ein DCC-only-Decoder
auf die Idee kommen, dass kein gültiges DCC-Signal vorhanden ist und stehen
bleiben.
Post by Jochen Dolze
Wenn ich also 10 Loks hintereinander refreshe, hat
jede Lok einen Zyklus von 100ms.
Ja. Aber. So einfach macht man sich das nur, wenn die Info konstant bleibt.
Sobald sich etwas ändert, wird diese Änderung schnell mal
dazwischengeschoben. Und die Funktionen werden sowieso meist seltener
aufgefrischt als die Geschwindigkeit, weil sie nicht so kritisch (sprich:
auffällig) sind.
--
Viele Grüße,
Jens Schmidt
Reinhard Mueller
2007-04-02 17:40:33 UTC
Permalink
Moin moin,
Post by Jens Schmidt
Post by Jochen Dolze
Wenn ich eine Lok vorwärts fahren lassen will und diese soll
F3 angeschaltet haben, muss ich zyklisch "fahre vorwärts"
und "mach F3 an" schicken?
Du *musst* nicht, aber es ist sinnvoll. Als extremer anderer
Fall wäre auch "fahre vorwärts", "mach F3 an" je einmal und
dann nur noch Idle-Packets.
Schon zwischen den beiden ersten Paketen braucht man ein Idle-
Packet.

Gruß,
Reinhard
Jochen Dolze
2007-04-02 23:00:58 UTC
Permalink
Post by Jens Schmidt
Es muss nicht jeder Decoder alle 30ms angesprochen werden. Es muss nur
zwischen zwei Startbits von DCC-Paketen maximal 30ms vergehen. Wenn Du also
ein DCC-Paket mit XXms gesendet hast, darfst Du maximal (30-XX)ms was
anderes (z.B. SX oder MM) senden, bis wieder ein DCC-Paket kommt. Ein
Multiprotokolldecoder im DCC-Modus könnte sonst auf die Idee kommen, nach
Paketen in anderen Formaten zu suchen.
Ah. Jetzt verstehe ich das. Na das ist für mich kein Problem, da ich nur
DCC implementieren werde.

Gruß

Jochen
Reinhard Mueller
2007-04-02 16:44:00 UTC
Permalink
Moin moin,
Post by Jochen Dolze
Bis jetzt habe ich einen Atmel ATTiny2313 der zyklisch über
einen MAX232 ein Datenpaket ständig wiederholt.
Das gleiche Datenpaket mehrfach hintereinander macht bei DCC
wenig Sinn. D.h. wenn man keine neuen Daten bekomt, sollte man
ein "festverdrahtetes" Idle-Packet zumindest als jedes zweite
Paket schicken.
Post by Jochen Dolze
Ob ich das Protokoll verstehe?
Ist nur eine Frage der Zeit. ;-)
Post by Jochen Dolze
Wenn ich eine Lok vorwärts fahren lassen will und diese soll
F3 angeschaltet haben, muss ich zyklisch "fahre vorwärts" und
"mach F3 an" schicken?
Sinnvoller weise ja. Dazwischen natürlich Pakete an andere
Adressen oder das Idle-Packet.
Post by Jochen Dolze
Die 30ms-Regel funktioniert doch rein theoretisch gar nicht bei
mehr als 3 Loks, ...
Doch, denn der Decoder soll innerhalb der 30ms irgend ein DCC-Paket
sehen, nicht eines an seine Adresse. D.h. es geht nicht um die Daten
in dem Paket, sondern dass er sich noch in einem DCC-Umfeld bewegt.

Dazu gibt es dann noch in RP-9.2.4, Abschnitt C den Packet Timeout.
Dieser legt fest, was ein Decoder machen soll, der keine Pakete an
seine Adresse erhällt. Für diese Zeit gilt aber ein *Minimum* von
20 Sekunden. D.h. jeder Decoder sollte innerhalb von 20 Sekunden
mindestens ein mal angesprochen werden.
Post by Jochen Dolze
... wenn ich Wolfgang Kufers Ausführungen richtig verstanden habe
und im Mittel eine DCC-Meldung ca. 10ms benötigt (eigene
überschlägige Berechnungen ergaben ein Minimum von 6ms).
Das Idle-Packet dauert nominell 6,15 ms (wenn die 0 doppelt so lang
ist, wie die 1). Das ist das kürzeste Paket. Im Mittel dauert ein
Paket mit drei Byte 7,1 ms. Ein Paket mit 5 Byte (lange Adresse und
128 Fahrstufen) 10,3 ms.
Post by Jochen Dolze
Oder gilt die wirklich nur für Decoder die auf Analogbetrieb
eingestellt sind?
Generell für Decoder, die auch etwas anderes als DCC können. Sei
es analoges DC oder AC oder eben ein anderes Protokoll.
Post by Jochen Dolze
Wenn ich also 10 Loks hintereinander refreshe, hat jede Lok einen
Zyklus von 100ms.
Wenn man sie stumpf der Reihe nach bedient.

Gruß,
Reinhard
Stefan Bormann
2007-04-02 19:03:11 UTC
Permalink
Post by Jochen Dolze
Post by Stefan Bormann
Kommt darauf an, was du erreichen moechtest.
Bis jetzt habe ich einen Atmel ATTiny2313 der zyklisch über einen MAX232
ein Datenpaket ständig wiederholt. Leider hat der ATTiny2313 nur 128
Bytes Speicher, da wird ein Refresh-Algorithmus schwierig ;) Ich gedenke
gerade entweder einen Atmega8 zu nehmen
Das sollte gerade so reichen. Aber ich verstehe nicht, warum du
unbedingt so kleine Prozessoren nehmen moechtest. Der Preis des
Prozessors ist irrelevant klein gegenueber der einer Platine
(bei kleinen Stueckzahlen).
Post by Jochen Dolze
oder 16kBit SPI-FRAM.
Soll das ein ueber SPI angebundenes RAM sein?
Nimm einen Prozessor mit genug RAM!!!!!
Post by Jochen Dolze
Ziel vom Ganzen wäre es, ein (USB2Serial-fähiges) serielles
Hardwareinterface für den srcpd zu schaffen, das sich nur mit der
Signalerzeugung beschäftigt. So wie der DCCSignaler, nur eben OpenSource.
Das heisst, es soll universell sein, also auch fuer grosse
Datenmengen funktionieren.
Dann muss da entweder ein schlaues Prioritaetssystem rein,
um Aenderungen sofort zu senden, oder du verlagerst gleich den Stack
wie von Matthias vorgeschlagen in den PC. Dann brauchst du natuerlich
irgend eine Art von Flow Control zwischen PC und dem Geraet.
Post by Jochen Dolze
Post by Stefan Bormann
Wenn du *viele* aktive Loks (ich sag mal >>10) gleichzeitig
unterstuetzen moechtest, musst du dir sowieso eine Strategie
ueberlegen, wie du die duenne Bandbreite gut nutzt.
Ob ich das Protokoll verstehe?
DCC? Ich glaube, es gibt hier viele Leute, die gerne Fragen
beantworten ;-)
--
Stefan Bormann
eMail: ***@gmx.de
Homepage: http://www.nord-com.net/stefan.bormann
Jochen Dolze
2007-04-02 23:28:14 UTC
Permalink
Post by Stefan Bormann
Ich gedenke gerade entweder einen Atmega8 zu nehmen
Das sollte gerade so reichen. Aber ich verstehe nicht, warum du
unbedingt so kleine Prozessoren nehmen moechtest. Der Preis des
Prozessors ist irrelevant klein gegenueber der einer Platine
(bei kleinen Stueckzahlen).
Eine einseitige Platine 80x100 mit 81 Bohrungen, Lötlack, chemische
Verzinnung und Versand kostet mich 10,39 Euro.

Der Atmega644 mit 4KB SRAM kostet z.B. 10 Euro. Hat dazu noch 40 Pins
und ist groß (52mm x 15mm), der Atmega32 mit 2KB SRAM ist genauso groß
wie der 644er und kostet noch 3,50 Euro. Der Atmega8 für 1,65 Euro
besitzt dahingehend nur 28 Pins und ist mit 34mm x 7mm beinahe halb so
groß. Da spare ich Platz und Bohrungen ;) Aber für eine Platine ist es
sowieso noch viel zu früh.

Mein Programm benötigt gerade mal 532 Bytes, dabei ist noch sehr viel
Debug- und/oder Testcode dabei. Der Atmega8 hat 8KByte Flash, da müsste
viel reinzupacken sein.
Post by Stefan Bormann
Das heisst, es soll universell sein, also auch fuer grosse
Datenmengen funktionieren.
Dann muss da entweder ein schlaues Prioritaetssystem rein,
um Aenderungen sofort zu senden, oder du verlagerst gleich den Stack
wie von Matthias vorgeschlagen in den PC. Dann brauchst du natuerlich
irgend eine Art von Flow Control zwischen PC und dem Geraet.
Ich bin mir da nicht sicher, wie sehr der PC dadurch (wieder) belastet
wird. Ich möchte ja eine möglichst hohe Entlastung des PCs.

Gruß

Jochen
Stefan Bormann
2007-04-03 16:47:18 UTC
Permalink
Post by Jochen Dolze
[..] Der Preis des
Prozessors ist irrelevant klein gegenueber der einer Platine
(bei kleinen Stueckzahlen).
Eine einseitige Platine 80x100 mit 81 Bohrungen, Lötlack, chemische
Verzinnung und Versand kostet mich 10,39 Euro.
Wo gibt's das?
Post by Jochen Dolze
Der Atmega644 mit 4KB SRAM kostet z.B. 10 Euro.
Bei Reichelt 7,45 Euro.
Post by Jochen Dolze
Hat dazu noch 40 Pins und ist groß (52mm x 15mm),
Einerseits: Was willst du ausser dem Prozessor und Treiber da
noch gross drauf packen???
Andererseits, wenn du es klein haben willst, nimm SMD.

Andererseits, lass mal abschaetzen:
Ein Array fuer, sagen wir 120 Loks mit
- Adresse (2 Byte)
- Speed & Direction (1 Byte)
- F0..F12 (2 Byte)
- Flags (Welche Formate werden gesendet, 1 Byte)
Braucht mindestens 6*120=720 Bytes, um den aktuellen Zustand
zu speichern. Dazu noch mindestens eine Queue fuer die
prior gesendeten Daten plus Stack. Also 2kB braeuchte man
wohl mindestens.
Post by Jochen Dolze
Mein Programm benötigt gerade mal 532 Bytes, dabei ist noch sehr viel
Debug- und/oder Testcode dabei.
Huch, schreibst du das in Assembler??? Masochist!
Post by Jochen Dolze
Ich bin mir da nicht sicher, wie sehr der PC dadurch (wieder) belastet
wird. Ich möchte ja eine möglichst hohe Entlastung des PCs.
Vergiss es ;-) Damit kannst du nichtmal einen 8086 ueberlasten ;-)
Wenn ein PC mit 100MBit LANs klar kommt, warum soll er dann mit
<10kBit DCC ein Problem haben???
Das einzige, womit du rechnen musst, ist dass der PC ab und zu mal
etwas nachdenkt. Die Hardware muss also von selber IDLE Packete
einschieben koennen, wenn der PC mal ein paar Festplatten-
gedenkmillisekunden einlegt.
--
Stefan Bormann
eMail: ***@gmx.de
Homepage: http://www.nord-com.net/stefan.bormann
Jochen Dolze
2007-04-03 23:32:43 UTC
Permalink
Post by Stefan Bormann
Post by Jochen Dolze
Eine einseitige Platine 80x100 mit 81 Bohrungen, Lötlack, chemische
Verzinnung und Versand kostet mich 10,39 Euro.
Wo gibt's das?
Bei http://www.platinendesign.de
Post by Stefan Bormann
Post by Jochen Dolze
Hat dazu noch 40 Pins und ist groß (52mm x 15mm),
Einerseits: Was willst du ausser dem Prozessor und Treiber da
noch gross drauf packen???
Andererseits, wenn du es klein haben willst, nimm SMD.
Nein. Der Preis und der Aufwand (Bauteile, Lötstellen) soll klein, die
Leistung der Aufgabe entsprechend sein.
Post by Stefan Bormann
Ein Array fuer, sagen wir 120 Loks mit
Ha! Das unterstützt ja nichtmal OpenDCC. Und Wolfgang verwendet einen
Atmega32. Ich gedenke auch mal bei 64 anzufangen.
Post by Stefan Bormann
- Adresse (2 Byte)
- Speed & Direction (1 Byte)
- F0..F12 (2 Byte)
- Flags (Welche Formate werden gesendet, 1 Byte)
Braucht mindestens 6*120=720 Bytes, um den aktuellen Zustand
zu speichern.
Ja, wenn man das so verschwenderisch macht schon ;) Heute Abend hatte
ich die Idee, die als Bytestream abgelegten Pakete einfach direkt zu
ändern. Das bedeutet, das Ausgabemodul verwaltet keine Loks, sondern
Telegramme. Und wenn sich ein Telegramm ändert, wird es im Bytestream
gesucht und abgeändert. Ein Bytestream für schnelle Ausgaben
(Fahrstufen) und einer für Langsame (Funktionen).

Wenn man den Mikroprozessor mit 14,7 MHz betreibt, hat man zwischen den
DCC-Takten ja "ewig" Zeit für anderes ;) Selbst bei meiner Version, die
gerade mit 3,686 MHz arbeitet sind es immerhin 200 Takte die bis zum
nächsten TimerInterrupt vergehen.
Post by Stefan Bormann
Post by Jochen Dolze
Mein Programm benötigt gerade mal 532 Bytes, dabei ist noch sehr viel
Debug- und/oder Testcode dabei.
Huch, schreibst du das in Assembler??? Masochist!
Ja bis jetzt. Die reine DCC-Ausgaberoutine war ja nicht so schwer zu
programmieren ;) Evtl. steige ich um, wenn ich mich an den intelligenten
Refresh herantraue.
Post by Stefan Bormann
Vergiss es ;-) Damit kannst du nichtmal einen 8086 ueberlasten ;-)
Wenn ein PC mit 100MBit LANs klar kommt,
Eine 100MBit-Lankarte ist über einen PCI-Bus angeschlossen, der
133MByte/s übertragen kann. Und selbst hier gibt es Karten, die die CPU
weniger und mehr belasten.
Post by Stefan Bormann
warum soll er dann mit
<10kBit DCC ein Problem haben???
Natürlich gibt es kein "Problem". Selbst mit DDL/DDW hat so ein Rechner
kein Problem. Trotzdem habe ich hier schon gelesen, das die Loks ruckeln
können sobald der PC noch anderweitig beschäftigt ist.

Wenn ich z.B. wirklich jedes Paket einzeln zum Konverter übertrage,
sollte alle 10ms ein neues Paket bereitstehen. So ein PC macht aber
Dinge am Liebsten asynchron ;) Und ob das mit den USB2Serial-Konvertern
so prima "nahtlos" funktionert? Ich möchte eben nicht wieder eine
Zeitabhänigkeit.
Post by Stefan Bormann
Das einzige, womit du rechnen musst, ist dass der PC ab und zu mal
etwas nachdenkt. Die Hardware muss also von selber IDLE Packete
einschieben koennen,
Nö, das finde ich eine schlechte Lösung: Bandbreite verschwenden, weil
kein Input kommt.
Post by Stefan Bormann
wenn der PC mal ein paar Festplatten-
gedenkmillisekunden einlegt.
Bei meinem PC kann das auch mal eine Sekunde sein.

Gruß

Jochen
Stefan Bormann
2007-04-04 16:35:03 UTC
Permalink
Post by Jochen Dolze
Bei http://www.platinendesign.de
Cool. Der kann aber scheinbar nicht drucken.
Post by Jochen Dolze
Post by Stefan Bormann
Ein Array fuer, sagen wir 120 Loks mit
Ha! Das unterstützt ja nichtmal OpenDCC. Und Wolfgang verwendet einen
Atmega32. Ich gedenke auch mal bei 64 anzufangen.
Ein Loconet-System kann 119 Loks verwalten, daher die Zahl.
Post by Jochen Dolze
Post by Stefan Bormann
- Adresse (2 Byte)
- Speed & Direction (1 Byte)
- F0..F12 (2 Byte)
- Flags (Welche Formate werden gesendet, 1 Byte)
Braucht mindestens 6*120=720 Bytes, um den aktuellen Zustand
zu speichern.
Ja, wenn man das so verschwenderisch macht schon ;) Heute Abend hatte
ich die Idee, die als Bytestream abgelegten Pakete einfach direkt zu
ändern.
Das bedeutet, dass du fuer eine Lok, zu der alles uebertragen wird,
sagen wir mit langer Adresse und 128 Fahrstufen mehr Speicher
brauchst (5+1)*4=24 - gegenueber meiner Schaetzung von 6 Byte
ist das viermal mehr.
Post by Jochen Dolze
Wenn man den Mikroprozessor mit 14,7 MHz betreibt, hat man zwischen den
DCC-Takten ja "ewig" Zeit für anderes ;) Selbst bei meiner Version, die
gerade mit 3,686 MHz arbeitet sind es immerhin 200 Takte die bis zum
nächsten TimerInterrupt vergehen.
Wie machst du die Ausgabe? Ein Timer-Output? Synchroner serieller
Output? Doch nicht etwa nur Interrupt-gesteuert in Software, oder?
Post by Jochen Dolze
Ja bis jetzt. Die reine DCC-Ausgaberoutine war ja nicht so schwer zu
programmieren ;) Evtl. steige ich um, wenn ich mich an den intelligenten
Refresh herantraue.
Besser ist das. ;-)
Post by Jochen Dolze
Post by Stefan Bormann
warum soll er dann mit
<10kBit DCC ein Problem haben???
Natürlich gibt es kein "Problem". Selbst mit DDL/DDW hat so ein Rechner
kein Problem. Trotzdem habe ich hier schon gelesen, das die Loks ruckeln
können sobald der PC noch anderweitig beschäftigt ist.
Ruckeln? Wie soll das gehen? Dann muessten sie ja ein Packet
mit anderer Geschwindigkeit bekommen.
Post by Jochen Dolze
Wenn ich z.B. wirklich jedes Paket einzeln zum Konverter übertrage,
sollte alle 10ms ein neues Paket bereitstehen. So ein PC macht aber
Dinge am Liebsten asynchron ;) Und ob das mit den USB2Serial-Konvertern
so prima "nahtlos" funktionert? Ich möchte eben nicht wieder eine
Zeitabhänigkeit.
Also Refresh im Atmel und nur Aenderungen vom PC.
Das finde ich auch besser, bedeutet aber, dass man dauernt Kompromisse
macht, oder nur etwas fuer kleine Anlagen taugliches, oder einen
richtigen (tm) Prozessor nimmt.
Post by Jochen Dolze
Post by Stefan Bormann
Das einzige, womit du rechnen musst, ist dass der PC ab und zu mal
etwas nachdenkt. Die Hardware muss also von selber IDLE Packete
einschieben koennen,
Nö, das finde ich eine schlechte Lösung: Bandbreite verschwenden, weil
kein Input kommt.
Soll ja nicht regelmaessig passieren.
Post by Jochen Dolze
Bei meinem PC kann das auch mal eine Sekunde sein.
Aber selten.
--
Stefan Bormann
eMail: ***@gmx.de
Homepage: http://www.nord-com.net/stefan.bormann
Wolfgang Kufer
2007-04-04 17:05:03 UTC
Permalink
Beihttp://www.platinendesign.de
Guter Preis, aber er macht offenbar keine Durchkontaktierungen.

Servus Wolfgang
Jochen Dolze
2007-04-04 20:31:45 UTC
Permalink
Post by Stefan Bormann
Post by Jochen Dolze
Ja, wenn man das so verschwenderisch macht schon ;) Heute Abend hatte
ich die Idee, die als Bytestream abgelegten Pakete einfach direkt zu
ändern.
Das bedeutet, dass du fuer eine Lok, zu der alles uebertragen wird,
sagen wir mit langer Adresse und 128 Fahrstufen mehr Speicher
brauchst (5+1)*4=24 - gegenueber meiner Schaetzung von 6 Byte
ist das viermal mehr.
Die Rechnung verstehe ich nicht. Mein Idee war eben, wenn ein Fahrbefehl
mit langer Adresse (=3 Byte [ohne Prüfbyte]) geschickt werden soll,
brauche ich dafür 4 Byte Speicher. Kommt noch eine Funktion dazu, dann
eben nochmal N Byte. Im günstigsten Fall benötigt dann eine "Lok" 4 Byte
Speicher, wenn diese ohne angeschaltete Funktionen rumfährt. Und wenn
dann dieses Paket geändert wird (mit dieser Adresse) könnte man es a)
als nächsten Befehl gleich rausschicken und b) im Bytestream ablegen.
Post by Stefan Bormann
Post by Jochen Dolze
Wenn man den Mikroprozessor mit 14,7 MHz betreibt, hat man zwischen
den DCC-Takten ja "ewig" Zeit für anderes ;) Selbst bei meiner
Version, die gerade mit 3,686 MHz arbeitet sind es immerhin 200 Takte
die bis zum nächsten TimerInterrupt vergehen.
Wie machst du die Ausgabe? Ein Timer-Output? Synchroner serieller
Output? Doch nicht etwa nur Interrupt-gesteuert in Software, oder?
Timer1 im CTC-Modus (8 Bit) und CompareMatch-Interrupt. Für jede Hälfte
wird ein Interrupt ausgeführt. Ist der Ausgang Null wird die ISR sofort
verlassen. Ist der Ausgang Eins wird entschieden was das nächste Bit
sein soll und der Counter dementsprechend gesetzt. Damit der Interrupt
immer rechtzeitig kommen kann, wurde die UART-Interruptroutine selbst
unterbrechbar gemacht. Der Empfang von Daten bringt das Timing
(hoffentlich) nicht durcheinander. Ausgemessen habe ich das aber noch
nicht. Aber im Simulator funktioniert es so.
Post by Stefan Bormann
Also Refresh im Atmel und nur Aenderungen vom PC.
Das finde ich auch besser, bedeutet aber, dass man dauernt Kompromisse
macht, oder nur etwas fuer kleine Anlagen taugliches, oder einen
richtigen (tm) Prozessor nimmt.
Die Software läßt sich ja einfach skalieren. Mehr Speicher, mehr Loks.

Gruß

Jochen
Stefan Bormann
2007-04-09 18:57:32 UTC
Permalink
Post by Jochen Dolze
Post by Stefan Bormann
Das bedeutet, dass du fuer eine Lok, zu der alles uebertragen wird,
sagen wir mit langer Adresse und 128 Fahrstufen mehr Speicher
brauchst (5+1)*4=24 - gegenueber meiner Schaetzung von 6 Byte
ist das viermal mehr.
Die Rechnung verstehe ich nicht.
War auch falsch, haette heissen sollen (4+1)*4=20.
Post by Jochen Dolze
Mein Idee war eben, wenn ein Fahrbefehl
mit langer Adresse (=3 Byte [ohne Prüfbyte]) geschickt werden soll,
brauche ich dafür 4 Byte Speicher.
Wenn es 128 Fahrstufen sein sollen brauchst du zwei Byte fuer
Adresse, zwei Byte fuer den Befehl und ein Byte mit dem Wert
4 fuer die Laenge. (4+1)
Post by Jochen Dolze
Timer1 im CTC-Modus (8 Bit) und CompareMatch-Interrupt. Für jede Hälfte
wird ein Interrupt ausgeführt. Ist der Ausgang Null wird die ISR sofort
verlassen. Ist der Ausgang Eins wird entschieden was das nächste Bit
sein soll und der Counter dementsprechend gesetzt. Damit der Interrupt
immer rechtzeitig kommen kann, wurde die UART-Interruptroutine selbst
unterbrechbar gemacht. Der Empfang von Daten bringt das Timing
(hoffentlich) nicht durcheinander. Ausgemessen habe ich das aber noch
nicht. Aber im Simulator funktioniert es so.
Wenn die UART-ISR nicht laenger braucht als zwischen zwei CompareMatch-
Interrupts, braeuchtest du die auch nicht unterbrechbar zu machen,
oder? Das sollte doch hinhauen.
Post by Jochen Dolze
Die Software läßt sich ja einfach skalieren. Mehr Speicher, mehr Loks.
Auch wieder war.
--
Stefan Bormann
eMail: ***@gmx.de
Homepage: http://www.nord-com.net/stefan.bormann
Jochen Dolze
2007-04-10 19:42:12 UTC
Permalink
Post by Stefan Bormann
Post by Jochen Dolze
Die Rechnung verstehe ich nicht.
War auch falsch, haette heissen sollen (4+1)*4=20.
Post by Jochen Dolze
Mein Idee war eben, wenn ein Fahrbefehl mit langer Adresse (=3 Byte
[ohne Prüfbyte]) geschickt werden soll, brauche ich dafür 4 Byte
Speicher.
Wenn es 128 Fahrstufen sein sollen brauchst du zwei Byte fuer
Adresse, zwei Byte fuer den Befehl und ein Byte mit dem Wert
4 fuer die Laenge. (4+1)
Das sind dann aber auch nur 5 Byte pro Lok.
Post by Stefan Bormann
Wenn die UART-ISR nicht laenger braucht als zwischen zwei CompareMatch-
Interrupts, braeuchtest du die auch nicht unterbrechbar zu machen,
oder? Das sollte doch hinhauen.
Die UART-ISR kann ja immer kommen, auch z.B. gerade nur 5 Takte vor dem
nächsten DCC-Signal-Interrupt. Und wenn die UART-ISR nun 40 Takte
benötigt, bis diese wieder zurückspringt hat man schon einen Versatz von
35 Takte. Sind dann bei 3,686Mhz immerhin 9µs.

Gruß

Jochen
Stefan Bormann
2007-04-11 17:49:46 UTC
Permalink
Post by Jochen Dolze
Post by Stefan Bormann
Post by Jochen Dolze
Die Rechnung verstehe ich nicht.
War auch falsch, haette heissen sollen (4+1)*4=20.
Post by Jochen Dolze
Mein Idee war eben, wenn ein Fahrbefehl mit langer Adresse (=3 Byte
[ohne Prüfbyte]) geschickt werden soll, brauche ich dafür 4 Byte
Speicher.
Wenn es 128 Fahrstufen sein sollen brauchst du zwei Byte fuer
Adresse, zwei Byte fuer den Befehl und ein Byte mit dem Wert
4 fuer die Laenge. (4+1)
Das sind dann aber auch nur 5 Byte pro Lok.
Pro Lok und Packet. Wenn man aber zu der Geschwindigkeit noch
drei verschiedene Funktionspackete zu dem fahrenden Tannenbaum
zyklisch senden moechte, wird's mehr.
Post by Jochen Dolze
Post by Stefan Bormann
Wenn die UART-ISR nicht laenger braucht als zwischen zwei CompareMatch-
Interrupts, braeuchtest du die auch nicht unterbrechbar zu machen,
oder? Das sollte doch hinhauen.
Die UART-ISR kann ja immer kommen, auch z.B. gerade nur 5 Takte vor dem
nächsten DCC-Signal-Interrupt. Und wenn die UART-ISR nun 40 Takte
benötigt, bis diese wieder zurückspringt hat man schon einen Versatz von
35 Takte. Sind dann bei 3,686Mhz immerhin 9µs.
Igitt. Neeeee.
Die Hardware soll beim Compare-Match den Ausgang umschalten und
dann per Interrupt informieren, dass das passiert ist. Dann hat
die Software 50us Zeit, UART-Interrupts zu bearbeiten, zur OC-
ISR zu springen, den Zeitpunkt der naechsten Flanke zu berechnen
und das Compare-Register zu laden.
--
Stefan Bormann
eMail: ***@gmx.de
Homepage: http://www.nord-com.net/stefan.bormann
Jochen Dolze
2007-04-12 16:28:25 UTC
Permalink
Post by Stefan Bormann
Post by Jochen Dolze
Das sind dann aber auch nur 5 Byte pro Lok.
Pro Lok und Packet. Wenn man aber zu der Geschwindigkeit noch
drei verschiedene Funktionspackete zu dem fahrenden Tannenbaum
zyklisch senden moechte, wird's mehr.
Ja, das stimmt.
Post by Stefan Bormann
Die Hardware soll beim Compare-Match den Ausgang umschalten und
dann per Interrupt informieren, dass das passiert ist. Dann hat
die Software 50us Zeit, UART-Interrupts zu bearbeiten, zur OC-
ISR zu springen, den Zeitpunkt der naechsten Flanke zu berechnen
und das Compare-Register zu laden.
Muss ich mal im Simulator ausprobieren. Die Einstellung ist natürlich
PIN bei Compare-Match setzen.

Gruß

Jochen

Reinhard Mueller
2007-04-11 18:42:11 UTC
Permalink
Moin moin,
Post by Jochen Dolze
Post by Stefan Bormann
Wenn die UART-ISR nicht laenger braucht als zwischen zwei CompareMatch-
Interrupts, braeuchtest du die auch nicht unterbrechbar zu machen,
oder? Das sollte doch hinhauen.
Die UART-ISR kann ja immer kommen, auch z.B. gerade nur 5 Takte vor dem
nächsten DCC-Signal-Interrupt. Und wenn die UART-ISR nun 40 Takte
benötigt, bis diese wieder zurückspringt hat man schon einen Versatz von
35 Takte. Sind dann bei 3,686Mhz immerhin 9µs.
Ich hatte das jetzt so verstanden, dass der Pin direkt vom Compare-Timer
gesteuert wird, und nur bis zum nächsten Compare-Match das richtige Bit
nachgeladen werden muss. Dann kann der Interrupt auch für länger
gesperrt sein. Ansonsten bedeutet jeder andere Interrupt dass das Timing
unsauber wird.

Gruß,
Reinhard
Werner Falkenbach
2007-04-05 06:33:16 UTC
Permalink
Hallo Stefan,

hab zwar den Faden längst verloren, aber....
Post by Stefan Bormann
Ruckeln? Wie soll das gehen? Dann muessten sie ja ein Packet
mit anderer Geschwindigkeit bekommen.
Ja, ich hab da was im Gedächtnis daß es Steuerprogramme gibt die das
Bremsen nicht dem Decoder überlassen sondern runterregeln, indem sie
Pakete mit absteigender Geschwindigkeitsinformation senden.
Wenn die bei linearem Fallen in unterschiedlichen Intervallen kommen
sieht das komisch aus, oder?

Grüße
Werner
--
MODELLEISENBAHN FÜR KINDER ==> http://www.kinderbahn.de
THEMA SCHMALSPURBAHN ==> http://www.thema-schmalspurbahn.de

mailto:***@werner-falkenbach.de (das kommt schon an)
Kurt Harders
2007-04-05 11:50:23 UTC
Permalink
Hallo Werner,
Post by Werner Falkenbach
Ja, ich hab da was im Gedächtnis daß es Steuerprogramme gibt die das
Bremsen nicht dem Decoder überlassen sondern runterregeln, indem sie
Pakete mit absteigender Geschwindigkeitsinformation senden. Wenn die
bei linearem Fallen in unterschiedlichen Intervallen kommen sieht das
komisch aus, oder?
Trotzdem gibt es dazu keine Alternative. Die Bremskurve des Dekoders
kann ja nur die Vollbremsung der Lok simulieren. Den Bremsvorgang oder
gar das Ausrollen eines ganzen Zuges kann nur die Software erledigen,
denn nur die kennt die Bremseigenschaften des Zuges.

Gruß, Kurt
--
Kurt Harders
PiN GITmbH http://www.pin-gmbh.com
Andreas Iwanowitsch
2007-04-05 16:16:25 UTC
Permalink
Post by Kurt Harders
Hallo Werner,
Post by Werner Falkenbach
Ja, ich hab da was im Gedächtnis daß es Steuerprogramme gibt die das
Bremsen nicht dem Decoder überlassen sondern runterregeln, indem sie
Pakete mit absteigender Geschwindigkeitsinformation senden. Wenn die
bei linearem Fallen in unterschiedlichen Intervallen kommen sieht das
komisch aus, oder?
So auffällig ist das nicht, wenn der Sprung zwischen den Fahrstufen
einigermaßen weich eingestellt ist.
Post by Kurt Harders
Trotzdem gibt es dazu keine Alternative. Die Bremskurve des Dekoders
kann ja nur die Vollbremsung der Lok simulieren. Den Bremsvorgang oder
gar das Ausrollen eines ganzen Zuges kann nur die Software erledigen,
denn nur die kennt die Bremseigenschaften des Zuges.
Die Alternative hieße schlicht und ergreifend "mehr Fahrstufen" bzw.
eigentlich sogar "viel mehr Fahrstufen".

Andreas
Kurt Harders
2007-04-06 06:35:05 UTC
Permalink
Hallo Andreas,
Post by Andreas Iwanowitsch
Post by Kurt Harders
Trotzdem gibt es dazu keine Alternative. Die Bremskurve des Dekoders
kann ja nur die Vollbremsung der Lok simulieren. Den Bremsvorgang
oder gar das Ausrollen eines ganzen Zuges kann nur die Software
erledigen, denn nur die kennt die Bremseigenschaften des Zuges.
Die Alternative hieße schlicht und ergreifend "mehr Fahrstufen" bzw.
eigentlich sogar "viel mehr Fahrstufen".
Missverständnis: Die Anzahl der Fahrstufen reicht mit 128 völlig aus,
um saubere Bremskurven zu fahren. Nur besteht IMO ein Missverständnis
bei der Massensimulation des Dekoders und auch der Schwungmasse. Ich
denke, dass eine Schwungmasse Dreck überbrücken soll, die
Massesimulation die Masse des Fahrzeugs (Lok, Triebwagen) beschreibt
und die Software das Verhalten eines ganzen Zuges evtl. unter Kenntnis
der Geländemerkmale abbildet.

Grüße, Kurt
--
Kurt Harders
PiN GITmbH http://www.pin-gmbh.com
Peter Wagner
2007-04-06 08:57:41 UTC
Permalink
Post by Kurt Harders
bei der Massensimulation des Dekoders und auch der Schwungmasse. Ich
denke, dass eine Schwungmasse Dreck überbrücken soll, die
Massesimulation die Masse des Fahrzeugs (Lok, Triebwagen) beschreibt
Wobei man das Bremsverhalten eines Fahrzeuges aus einer Kombination
der Wirkungen von Schwungmasse und elektronischer Verzögerung (CV4)
sehen muss. Je grösser die mechanische Verzögerung desto kleiner
kann die elektronische sein.
--
SchöNe Grüße aus WieN,
Peter Wagner. Spur N, DCC.
Technischer Referent des Modelleisenbahnclub "Die 160er"
Andreas Iwanowitsch
2007-04-06 09:30:14 UTC
Permalink
Post by Kurt Harders
Hallo Andreas,
Post by Andreas Iwanowitsch
Post by Kurt Harders
Trotzdem gibt es dazu keine Alternative. Die Bremskurve des Dekoders
kann ja nur die Vollbremsung der Lok simulieren. Den Bremsvorgang
oder gar das Ausrollen eines ganzen Zuges kann nur die Software
erledigen, denn nur die kennt die Bremseigenschaften des Zuges.
Die Alternative hieße schlicht und ergreifend "mehr Fahrstufen" bzw.
eigentlich sogar "viel mehr Fahrstufen".
Missverständnis: Die Anzahl der Fahrstufen reicht mit 128 völlig aus,
um saubere Bremskurven zu fahren. Nur besteht IMO ein Missverständnis
bei der Massensimulation des Dekoders und auch der Schwungmasse. Ich
denke, dass eine Schwungmasse Dreck überbrücken soll, die
Massesimulation die Masse des Fahrzeugs (Lok, Triebwagen) beschreibt
und die Software das Verhalten eines ganzen Zuges evtl. unter Kenntnis
der Geländemerkmale abbildet.
Was die Schwungmasse des Motors betrifft - ACK. Und mit 128 Fahrstufen
fällt das Problem natürlich schon nicht mehr so ins Gewicht, mit 28 kann
es aber u.U. augenfällig werden.

Hilfreich wäre, den Wert von CV3 und CV4 (Beschleunigungs- und
Bremszeit) dynamisch während des Anlageneinsatzes einfach ändern zu
können, um das Fahrverhalten realistisch darzustellen. Absinkende
Geschwindigkeit auf Steigungsstrecken lassen sich mit Software ja schon
hinreichend gut abbilden.

Andreas
Peter Wagner
2007-04-07 13:11:49 UTC
Permalink
Post by Andreas Iwanowitsch
können, um das Fahrverhalten realistisch darzustellen. Absinkende
Geschwindigkeit auf Steigungsstrecken lassen sich mit Software ja schon
hinreichend gut abbilden.
Das wäre mit Hilfe des PoM Verfahrens möglich - soferne vom Decoder
unterstützt, die neueren können das alle bis auf GFN und D&H.
--
SchöNe Grüße aus WieN,
Peter Wagner. Spur N, DCC.
Technischer Referent des Modelleisenbahnclub "Die 160er"
Reinhard Mueller
2007-04-04 16:50:18 UTC
Permalink
Moin moin,
Post by Jochen Dolze
Ja, wenn man das so verschwenderisch macht schon ;) Heute Abend hatte
ich die Idee, die als Bytestream abgelegten Pakete einfach direkt zu
ändern. Das bedeutet, das Ausgabemodul verwaltet keine Loks, sondern
Telegramme. Und wenn sich ein Telegramm ändert, wird es im Bytestream
gesucht und abgeändert. Ein Bytestream für schnelle Ausgaben
(Fahrstufen) und einer für Langsame (Funktionen).
Fahrstufen sind eilig, wenn sie sich ändern. Das gleiche gilt für
Funktionen. Es ist unschön, wenn man vor dem Bahnübergang auf den
Knopf für die Pfeife drückt, der Pfiff aber erst auf oder hinter dem
Bahnübergang kommt.
Post by Jochen Dolze
Wenn man den Mikroprozessor mit 14,7 MHz betreibt, hat man zwischen den
DCC-Takten ja "ewig" Zeit für anderes ;) Selbst bei meiner Version, die
gerade mit 3,686 MHz arbeitet sind es immerhin 200 Takte die bis zum
nächsten TimerInterrupt vergehen.
Also wirklich den Datenstrom von Hand. @Stefan: 200 / 3,686MHz =
54,3us, also ein halbes 1-Bit. (Das sollten aber 58us = 214 Takte
sein, aber die 200 waren wohl nur eine glatte Zahl). Damit das
Timing steht, darf es aber keine anderen Interrupts oder Zeiten
mit gesperrtem Interrupt im System geben, oder es wird leicht ein
Timing ausserhalb der Spec erzeugt. Nachdem ich gelernt habe, dass
man mit einen UART alle Pakete erzeugen kann, wenn man die Bits
über die UART-Byte-Grenzen gehen lässt, könnte das eine deutliche
Entlastung bringen.
Post by Jochen Dolze
Post by Stefan Bormann
Huch, schreibst du das in Assembler??? Masochist!
Na ja, wer die Daten bit-bannged schreibt, sollte vieleicht auf die
Laufzeiten achten. Und die C-Quellen so zu trimmen, dass der Compiler
die gewünschten Assemblerbefehle erzeugt, ist auch nicht effektiv.
Post by Jochen Dolze
Ja bis jetzt. Die reine DCC-Ausgaberoutine war ja nicht so schwer zu
programmieren ;) Evtl. steige ich um, wenn ich mich an den intelligenten
Refresh herantraue.
Den zeitkritischen Treiber würde ich in Assembler lassen, den Rest
aber in C oder was auch immer programmieren.
Post by Jochen Dolze
Post by Stefan Bormann
Vergiss es ;-) Damit kannst du nichtmal einen 8086 ueberlasten ;-)
Wenn ein PC mit 100MBit LANs klar kommt,
Da sitzt aber auch Hardwareunterstützung wie z.B. DMA hinter.
Problematisch sind immer Reaktionszeiten, die eingehalten werden
müssen. Und je kleiner der Datenpuffer in dem DCC-Generator, um
so zeitnäher muss der PC die Daten liefern. Ein großer Puffer im
DCC-Generator führt aber entweder zu langen Reaktionszeiten des
Systems, oder man verlagert die Priorisierung in den DCC-Generator.

Gruß,
Reinhard
Stefan Bormann
2007-04-04 18:48:23 UTC
Permalink
Post by Reinhard Mueller
Damit das
Timing steht, darf es aber keine anderen Interrupts oder Zeiten
mit gesperrtem Interrupt im System geben, oder es wird leicht ein
Timing ausserhalb der Spec erzeugt.
Das ist fuer mich keine Option, wenn man einen hinreichend
genialen Prozessor auswaehlt, kann man ein deutlich robusteres
SW-Design machen, bei dem man sich nicht fuer Timing verrenken
muss.
Post by Reinhard Mueller
Nachdem ich gelernt habe, dass
man mit einen UART alle Pakete erzeugen kann, wenn man die Bits
über die UART-Byte-Grenzen gehen lässt, könnte das eine deutliche
Entlastung bringen.
Das killt aber Bandbreite.
Der AVR hat aber andere Moeglichkeiten, exaktes Bittiming zu
erzeugen, ohne dass man bei Assembler tackte zaehlen muss.
Post by Reinhard Mueller
Post by Stefan Bormann
Huch, schreibst du das in Assembler??? Masochist!
Na ja, wer die Daten bit-bannged schreibt, sollte vieleicht auf die
Laufzeiten achten. Und die C-Quellen so zu trimmen, dass der Compiler
die gewünschten Assemblerbefehle erzeugt, ist auch nicht effektiv.
Effektiv ist es, das Timing von der Hardware zu machen.


Wolfgang: Wie erzeugt eigentlich OpenDCC das DCC-Timing?
--
Stefan Bormann
eMail: ***@gmx.de
Homepage: http://www.nord-com.net/stefan.bormann
Wolfgang Kufer
2007-04-04 19:19:53 UTC
Permalink
Post by Stefan Bormann
Wolfgang: Wie erzeugt eigentlich OpenDCC das DCC-Timing?
OpenDCC zieht einen PWM-Timer auf (je nach 0 oder 1 halt 58us oder
116us), der Compareausgang dieses Timers ist das DCC Signals.

Mit dem Comparematch gibt es einen Interrupt, da wird dann der Compare
fürs nächste Mal geladen; In der ISR lade ich den bereits
vorbereiteten Comparewert in den Timer und berechne mir den Wert fürs
nächste Mal.

Das Ganze geht in C, verursacht wenig CPU-Last und ist absolut exakt.

Die ISR macht auch gleich "Layer 0" mit, d.h. die Präambel und
Checksum ist Sache der ISR, der Verwalter der Lokbefehle übergibt nur
die Nutzbits und ein Attribut (für lange Präambel oder
Feedbackabfrage)

Servus Wolfgang
Reinhard Mueller
2007-04-05 17:44:43 UTC
Permalink
Post by Stefan Bormann
Post by Reinhard Mueller
Damit das
Timing steht, darf es aber keine anderen Interrupts oder Zeiten
mit gesperrtem Interrupt im System geben, oder es wird leicht ein
Timing ausserhalb der Spec erzeugt.
Das ist fuer mich keine Option, wenn man einen hinreichend
genialen Prozessor auswaehlt, kann man ein deutlich robusteres
SW-Design machen, bei dem man sich nicht fuer Timing verrenken
muss.
Nachdem Jochen geschrieben hat, dass der Ausgang direkt vom Timer
gesteuert wird und der Interrupt nur die Vorbereitung macht, ist
das natürlich deutlich entspannter.
Post by Stefan Bormann
Post by Reinhard Mueller
Nachdem ich gelernt habe, dass
man mit einen UART alle Pakete erzeugen kann, wenn man die Bits
über die UART-Byte-Grenzen gehen lässt, könnte das eine deutliche
Entlastung bringen.
Das killt aber Bandbreite.
Ich muss mal sehen, wie sich das im einzelnen darstellt, d.h. wieviel
Bandbreite man wirklich verschenkt.
Post by Stefan Bormann
Der AVR hat aber andere Moeglichkeiten, exaktes Bittiming zu
erzeugen, ohne dass man bei Assembler tackte zaehlen muss.
Das macht ja keiner. Ich hatte die Befürchtung, dass er wirklich von
der Reaktionszeit auf den Interrupt lebt, aber da hat er ja noch
Hardware hinzugenommen.
Post by Stefan Bormann
Post by Reinhard Mueller
Na ja, wer die Daten bit-bannged schreibt, sollte vieleicht auf die
Laufzeiten achten. Und die C-Quellen so zu trimmen, dass der Compiler
die gewünschten Assemblerbefehle erzeugt, ist auch nicht effektiv.
Effektiv ist es, das Timing von der Hardware zu machen.
Klar. Aber auch dann kann es sinnvoll sein, den Treiber auf unterster
Ebene in Assembler zu schreiben. Das sind nur wenige Zeilen, die aber
viel ausmachen können. Wenn man ein paar Bits in den Ports manipuliert
ist das in Assembler genauso einfach geschrieben, wie in C. Es sei denn,
man vermeidet aus religiösen Gründen grundsätzlich den Assembler und
müsste den neu lernen.

Gruß,
Reinhard
Wolfgang Kufer
2007-04-04 17:18:16 UTC
Permalink
Hallo,

Zeit, auch mal mitzureden :-)
Post by Jochen Dolze
Post by Stefan Bormann
Ein Array fuer, sagen wir 120 Loks mit
Ha! Das unterstützt ja nichtmal OpenDCC. Und Wolfgang verwendet einen
Atmega32. Ich gedenke auch mal bei 64 anzufangen.
OpenDCC ist eigentlich nicht beschränkt - erst der Prozessor (speziell
der Speicher) und was alles so drauf laufen soll macht die
Einschränkung. Und DCC ist ja auch nicht gerade durchsatzstark, so
dass 64 aktiv fahrende Loks durchaus eine sinnvolle Obergrenze sind.

Jochen, ehrlich gesagt ist mir nicht ganz klar, warum Du nicht einfach
OpenDCC nimmst, die Sachen die Du nicht magst, wegläßt (und auch die
entsprechenden Compileswitches setzt: also z.B. S88_ENABLED =
FALSE :-) und dann einfach im Intelliboxmode mit srcpd damit redest.

Du bekommst die ganze Verwalterei, Refresh und intelligente
Abarbeitung der Befehle fertig serviert. Auch die Abstandsregel wird
eingehalten ...

Servus Wolfgang
Guido Scholz
2007-04-04 18:34:23 UTC
Permalink
Post by Wolfgang Kufer
Jochen, ehrlich gesagt ist mir nicht ganz klar, warum Du nicht einfach
OpenDCC nimmst, die Sachen die Du nicht magst, wegläßt (und auch die
entsprechenden Compileswitches setzt: also z.B. S88_ENABLED =
FALSE :-) und dann einfach im Intelliboxmode mit srcpd damit redest.
Du bekommst die ganze Verwalterei, Refresh und intelligente
Abarbeitung der Befehle fertig serviert. Auch die Abstandsregel wird
eingehalten ...
das habe ich mich auch schon gefragt, aber vermutlich möchte Jochen
einfach was Eigenes haben (wenn die Kinder mal aus dem Haus sind ... ;-)

Gruß
Guido
--
http://www.bayernline.de/~gscholz/
http://www.lug-burghausen.org/
Andre Schenk
2007-04-04 19:29:43 UTC
Permalink
Post by Wolfgang Kufer
Jochen, ehrlich gesagt ist mir nicht ganz klar, warum Du nicht
einfach OpenDCC nimmst, die Sachen die Du nicht magst, wegläßt
(und auch die entsprechenden Compileswitches setzt: also z.B.
S88_ENABLED = FALSE :-) und dann einfach im Intelliboxmode mit
srcpd damit redest.
Geht das nur über RS232 oder auch über USB? Dann wäre das ja eine Lösung
für alle, die keine RS232 mehr an ihrem PC haben.

Tschüß André
Wolfgang Kufer
2007-04-04 19:35:09 UTC
Permalink
Post by Andre Schenk
Geht das nur über RS232 oder auch über USB? Dann wäre das ja eine Lösung
für alle, die keine RS232 mehr an ihrem PC haben.
Der Test mit srcpd und OpenDCC mit USB ist wegen Zeitmangel und einer
fehlerhaften Hardware noch nicht durchgeführt - aber ich werde mich
nochmal mit Guido treffen und dann testen wir weiter. Mit TC geht es
per USB, zuerst mal spricht also nichts dagegen.

Servus Wolfgang
Alexander Bolz
2007-04-04 20:07:43 UTC
Permalink
Hallo,
Post by Wolfgang Kufer
Post by Andre Schenk
Geht das nur über RS232 oder auch über USB? Dann wäre das ja eine Lösung
für alle, die keine RS232 mehr an ihrem PC haben.
Der Test mit srcpd und OpenDCC mit USB ist wegen Zeitmangel und einer
fehlerhaften Hardware noch nicht durchgeführt - aber ich werde mich
nochmal mit Guido treffen und dann testen wir weiter. Mit TC geht es
per USB, zuerst mal spricht also nichts dagegen.
Und mit Railware auch, wie Wolfgang ja auch auf der Webpage zu OpenDCC
stehen hat. Mein Rechner hat zwar noch 2 serielle Schnittstellen, ich
wollte mir aber was für die ISP-Schnittstelle freihalten (und an der
anderen hängt die IB).

Viele Grüße,
Alexander
Jochen Dolze
2007-04-04 20:45:50 UTC
Permalink
Hallo Wolfgang,
Post by Wolfgang Kufer
Jochen, ehrlich gesagt ist mir nicht ganz klar, warum Du nicht einfach
OpenDCC nimmst,
Es soll einfach eine sinnvolle Erweiterung zum srcpd sein. Klein,
handlich günstig. Das ganze sollte in ein LDT-Gehäuse passen (sind recht
schnuckelig und ich habe viele davon) und mit sagen wir mal 25 Bauteilen
aufzubauen sein.

Ich bin da ja nun schon seit 2005 dran (mit laaangen Pausen):
<438f50f8$0$20852$***@newsread2.arcor-online.net>

Damals dachte ich noch, ich bekomme das in so eine Art Zwischenstecker
ohne eigene Spannungsversorgung rein und zapfe den USB-Bus direkt an.
Das habe ich aber verworfen.
Post by Wolfgang Kufer
die Sachen die Du nicht magst, wegläßt (und auch die
entsprechenden Compileswitches setzt: also z.B. S88_ENABLED =
FALSE :-) und dann einfach im Intelliboxmode mit srcpd damit redest.
Die "Blackbox" soll nicht alles machen, der srcpd darf die ganze
Verwalterei übernehmen, Änderungen aussenden und nur der Refresh soll
dann über dieses Ausgabemodul abgehandelt.
Post by Wolfgang Kufer
Du bekommst die ganze Verwalterei, Refresh und intelligente
Abarbeitung der Befehle fertig serviert. Auch die Abstandsregel wird
eingehalten ...
Natürlich lasse ich mich von Dir inspirieren!

Gruß

Jochen
Wolfgang Kufer
2007-04-05 05:59:29 UTC
Permalink
Post by Jochen Dolze
Es soll einfach eine sinnvolle Erweiterung zum srcpd sein. Klein,
handlich günstig. Das ganze sollte in ein LDT-Gehäuse passen
(sind recht schnuckelig und ich habe viele davon) und mit sagen wir mal > 25 Bauteilen aufzubauen sein.
Das geht auch mit OpenDCC - der einzige Unterschied zu Deiner Lösung
ist doch eigentlich die Leistungsfähigkeit des Prozessors und die
logische Schnittstellenebene. Ich habe mit da halt an die übliche
Trennung wie z.B. bei Intellibox oder Lenz gehalten. Gut finde ich
auch das neue Protokoll von Zimo - wär fast mal eine Sünde wert :-)
Post by Jochen Dolze
[..] eigene Spannungsversorgung rein und zapfe den USB-Bus direkt an.
Das habe ich aber verworfen.
Ohne Booster müßte das doch leicht gehen - Du hast da 2,5W zur
Verfügung.

Servus Wolfgang
Matthias Trute
2007-04-05 07:15:32 UTC
Permalink
Post by Jochen Dolze
Damals dachte ich noch, ich bekomme das in so eine Art Zwischenstecker
ohne eigene Spannungsversorgung rein und zapfe den USB-Bus direkt an.
Das habe ich aber verworfen.
http://www.obdev.at/products/avrusb/index.html

zeigt eine kleine Schaltung für einen bus-powered Attiny
(USB, paar R/C und der Quartz).

Auf der "anderen" Seite einen simplen Treiber für
den Booster (falls nötig) und die Hardware wäre
komplett. Firmware für USB ohne Hardware unter GPL
habe ich auch irgendwo schon gesehen.


Gruß
Matthias
Matthias Kordell
2007-04-05 10:18:04 UTC
Permalink
Post by Matthias Trute
Post by Jochen Dolze
Damals dachte ich noch, ich bekomme das in so eine Art
Zwischenstecker ohne eigene Spannungsversorgung rein und zapfe
den USB-Bus direkt an. Das habe ich aber verworfen.
http://www.obdev.at/products/avrusb/index.html
zeigt eine kleine Schaltung für einen bus-powered Attiny
(USB, paar R/C und der Quartz).
Sowas hab ich mir auch schon überlegt, nur um die 500mA
freizuschalten. Dazu sollte das Gerät sich sich als etwas allgemein
bekanntes (z.B. USB-Tastatur) anmelden. Dass keine Tasten vorhanden
sind obwohl es vorgibt, eine Tastatur zu sein, stört ja nicht,
solange eine weitere Tastatur vorhanden ist.
Post by Matthias Trute
Auf der "anderen" Seite einen simplen Treiber für
den Booster (falls nötig) und die Hardware wäre
komplett. Firmware für USB ohne Hardware unter GPL
habe ich auch irgendwo schon gesehen.
In der März-Elektor war etwas mit AVR an USB drin. Der Artikel nennt
sich "AVR steuert USB", die Firmware stammt aus der oben angegebenen
Seite und steht unter GPL.

Matthias
Martin Schoenbeck
2007-04-05 11:36:09 UTC
Permalink
Hallo Matthias,
Post by Matthias Kordell
Sowas hab ich mir auch schon überlegt, nur um die 500mA
freizuschalten. Dazu sollte das Gerät sich sich als etwas allgemein
bekanntes (z.B. USB-Tastatur) anmelden. Dass keine Tasten vorhanden
sind obwohl es vorgibt, eine Tastatur zu sein, stört ja nicht,
solange eine weitere Tastatur vorhanden ist.
Nachdem da ja in erster Linie Ausgabe eines Datenstroms stattfinden soll,
wäre da eine Anmeldung als Communication Device doch wohl sinnvoller. Auch
deshalb, daß dann ein Betriebssystem nicht meint, selbst schon mit dem
Gerät arbeiten zu sollen.

Gruß Martin
--
Bitte nicht an der E-Mail-Adresse fummeln, die paßt so.
Matthias Kordell
2007-04-05 12:27:16 UTC
Permalink
Post by Martin Schoenbeck
Post by Matthias Kordell
Sowas hab ich mir auch schon überlegt, nur um die 500mA
freizuschalten. Dazu sollte das Gerät sich sich als etwas
allgemein bekanntes (z.B. USB-Tastatur) anmelden. Dass keine
Tasten vorhanden sind obwohl es vorgibt, eine Tastatur zu sein,
stört ja nicht, solange eine weitere Tastatur vorhanden ist.
Nachdem da ja in erster Linie Ausgabe eines Datenstroms stattfinden
soll, wäre da eine Anmeldung als Communication Device doch wohl
sinnvoller. Auch deshalb, daß dann ein Betriebssystem nicht meint,
selbst schon mit dem Gerät arbeiten zu sollen.
Für den speziellen Einsatzzweck bei meinem Gerät wäre eine
Eintastenmaus (ohne Kugel/Sensor) vielleicht sogar noch besser:

Es ist eine spezielle Taschenlampe, die genau in der
Empfindlichkeitslücke des Films zur Platinenherstellung leuchtet.
Damit sie immer aufgeräumt ist => Laden am Steuer-PC des
Photoplotters. Dummerweise muss man den Plottvorgang mit einem
Mausklick bei ausgeschaltetem Monitor (belichtet sonst den Film)
starten. Wenn die Taschenlampe eine Maustaste hat, kann man sie nach
dem einlegen (oder besser -kleben) des Films wieder anschließen und
auf den Knopf drücken. Die richtige Maus liegt dabei die ganze Zeit
auf dem Rücken, damit sich die Kugel nicht bewegt.

Als was sich das Ladegerät anmeldet, ist also ziemlich egal,
hauptsache es stehen 500mA zur Verfügung und Windoof will keinen
Treiber. Als Maus hätte es nur *etwas* Vorteile.

Matthias
Peter Wagner
2007-04-05 22:52:57 UTC
Permalink
Post by Matthias Kordell
Photoplotters. Dummerweise muss man den Plottvorgang mit einem
Mausklick bei ausgeschaltetem Monitor (belichtet sonst den Film)
Gibt es keinen Shortcut auf der Tastatur?

Warum verwendest Du nicht die Tastaturmaus?
--
SchöNe Grüße aus WieN,
Peter Wagner. Spur N, DCC.
Technischer Referent des Modelleisenbahnclub "Die 160er"
Matthias Kordell
2007-04-06 10:04:55 UTC
Permalink
Post by Peter Wagner
Post by Matthias Kordell
Photoplotters. Dummerweise muss man den Plottvorgang mit einem
Mausklick bei ausgeschaltetem Monitor (belichtet sonst den Film)
Gibt es keinen Shortcut auf der Tastatur?
AFAIK nein.
Post by Peter Wagner
Warum verwendest Du nicht die Tastaturmaus?
Ist nicht mein Plotter/Rechner. Sonst hätte ich mir dafür schon
einen TFT-Monitor auf LED-Beleuchtung umgebaut und eine optische
Maus mit grüner LED angeschlossen.

Matthias
Stefan Bormann
2007-04-09 18:50:03 UTC
Permalink
Post by Martin Schoenbeck
Nachdem da ja in erster Linie Ausgabe eines Datenstroms stattfinden soll,
wäre da eine Anmeldung als Communication Device doch wohl sinnvoller.
Natuerlich. Wenn man das richtig (tm) angehen moechte, waere ein
Prozessor, der schon USB-Hardware on chip hat auch angemessener.
Dann geht das auch wieder locker in einen Adapterstecker.

Das eigentliche Problem bei USB sehe ich eher darin, dass man
immer mit der Manufacturer-ID rumferkeln muss, weil die sonst
Kiloeuros kostet. Oder gibt es da mittlerweile eine Bastler-ID,
wie bei DCC?
--
Stefan Bormann
eMail: ***@gmx.de
Homepage: http://www.nord-com.net/stefan.bormann
Martin Schoenbeck
2007-04-10 08:13:33 UTC
Permalink
Hallo Stefan,
Post by Stefan Bormann
Post by Martin Schoenbeck
Nachdem da ja in erster Linie Ausgabe eines Datenstroms stattfinden soll,
wäre da eine Anmeldung als Communication Device doch wohl sinnvoller.
Natuerlich. Wenn man das richtig (tm) angehen moechte, waere ein
Prozessor, der schon USB-Hardware on chip hat auch angemessener.
Dann geht das auch wieder locker in einen Adapterstecker.
Genau. USB-Stecker und zwei Drähte zum Booster. ;-)
Post by Stefan Bormann
Das eigentliche Problem bei USB sehe ich eher darin, dass man
immer mit der Manufacturer-ID rumferkeln muss, weil die sonst
Kiloeuros kostet. Oder gibt es da mittlerweile eine Bastler-ID,
wie bei DCC?
Nee, unter 2000 $ ist da wohl noch nichts zu machen. Aber normalerweise
kann man ja die ID des Herstellers des Kits nehmen, oder? Oder für den
Eigenbedarf einfach frech irgendeine.

Gruß Martin
--
Bitte nicht an der E-Mail-Adresse fummeln, die paßt so.
Matthias Trute
2007-04-03 17:20:21 UTC
Permalink
Jochen,
Post by Jochen Dolze
Ich bin mir da nicht sicher, wie sehr der PC dadurch (wieder) belastet
wird. Ich möchte ja eine möglichst hohe Entlastung des PCs.
DCC kannst Du da glatt vernachlässigen. Der srcpd verursacht im
DCC-only Modus keinerlei merkbare Last, auch auf schon etwas
älteren CPU nicht.

Bleibt Dein Ziel, mit USB Wandlern zurechtzukommen. Das ist
eine sehr praktische Ergänzung. Planst Du eigentlich die
BiDi Hardware mit ein? IMHO sollte ein simpler Sniffer mit
rudimentären Protokollüberprüfungen ausreichen. Das eigentliche
Decodieren des DCC Signals kann ja wieder der PC übernehmen.

Gruß
Matthias
Jochen Dolze
2007-04-03 22:51:49 UTC
Permalink
Post by Matthias Trute
DCC kannst Du da glatt vernachlässigen. Der srcpd verursacht im
DCC-only Modus keinerlei merkbare Last, auch auf schon etwas
älteren CPU nicht.
Gut.
Post by Matthias Trute
Bleibt Dein Ziel, mit USB Wandlern zurechtzukommen. Das ist
eine sehr praktische Ergänzung. Planst Du eigentlich die
BiDi Hardware mit ein?
Theoretisch ;) - Ich habe keinerlei konkrete Informationen darüber. Und
bisher auch nur allgemeine Diskussionen darüber verfolgt.
Post by Matthias Trute
IMHO sollte ein simpler Sniffer mit
rudimentären Protokollüberprüfungen ausreichen. Das eigentliche
Decodieren des DCC Signals kann ja wieder der PC übernehmen.
Ja, auf jeden Fall.

Gruß

Jochen
Lesen Sie weiter auf narkive:
Loading...