[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [DDL-ML] Packetdefinition und Laengen der Packete
On Sat, Nov 04, 2000 at 08:36:42AM +0100, Torsten Vogt wrote:
> Thomas Reich wrote:
>
> > Doppelpaket: Paket + 1,525ms + Packet + 1,025ms
> >
> > Auf dem Oszi habe ich allerdings dies beobachtet:
> >
> > Doppelpaket: Packet + Packet
>
> Schau mal in die Datei cycles.c im Verzeichis DDL/erddcd. Dort findest
> Du die Funktion void send_packet(...). Die Doppelpakete werden durch
> folgenden Code verschickt:
>
> nanosleep(&rqtp_end19K, &rmtp);
> write(COM_DEVICE,packet,18);
Heisst das du schreibst 18 trits oder 18 bits?
> waitUARTempty();
> nanosleep(&rqtp_btw19K, &rmtp);
> write(COM_DEVICE,packet,18);
> waitUARTempty();
>
> durch das zweite nanosleep() sollte eigentlich zwischen den beiden
> Paketen
> die erforderliche Pause generiert werden. Ich habe kein Oszi, um das
> zu ueberpruefen, aber da meine Dekoder einwandfrei funktionieren und
> ich schon mal einen Ausdruck einer Oszi-Messung von Dieter Schaefer
> gesehen habe, bin ich davon ausgegangen, dass dies alles seine
> Richtigkeit
> hat.
static struct timespec rqtp_end19K = { 0, 1700000 }; /* ==> busy waiting */
Das waeren dann 1.7ms
static struct timespec rqtp_btw19K = { 0, 1250000 }; /* ==> busy waiting */
Das waeren dann 1.25ms
Daraus folgt: 1,7ms + Paket + 1,25ms + Paket falls ich das mit dem nanosleep
und write(COM richtig verstanden habe. (IANACP = I am not a C Programmer) :-)
Das deckt sich allerdings nicht mit der Beschreibung von Andrea Scorzoni, falls
diese korrekt waere, richtig? Falls ich mich irre, bitte um Berichtigung.
Aber selbst wenn die Pausen selbst 1,25ms waeren, auf dem Oszi sind sie einfach
nicht aufzufinden.
hmmm.... wenn der thread im realtime mode laeuft, ist es dann trotzdem moeglich
mit dem gdb den Code zu debuggen und mal auf dem Oszi nachzuschauen, was der
Code wann macht? Falls ja, werde ich das naemlich mal durchziehen.
> Welche Dekoder, welcher Booster, welches Linux (Kernel)?
Maerklin Decoder... uhhmmm.... 701.17 auf meiner BR55, falls ich das richtig
gesehen habe. Der Decoderchip meiner Maerklin California Zephyr ist gesandwiched
zwischen zwei Platinen, da muss ich erst das Teil auseindernehmen um den
Dekodertyp feststellen zu koennen.
Mein Booster ist der Selbstbau Booster von Dr. Koenig, welcher nachweisslich
auf dem Oszilloskop einwandfrei das Signal ohne Signalverzerrung darstellt.
RedHat Linux 2.2.16
>
> Torsten
Thomas
Oracle DBA & Unix Admin
Andersen Consulting
Chicago, IL, USA