µ Timer

[Logh]

hi,

folgendes problem:

es geht um die Programmierung der seriellen Schnittstelle.
Wie kann man im µs Bereich einen Takt raus lassen, d.h. einen Takt x µs und danach ein Takt y µs. Bei der umschaltung von x auf y darf keine große Zeit verloren gehen (>2µs).
Wie könnte man dies realisieren (µTimer mit ISR).
Bitte um hilfe.


Logh

[Dax]

Eventuell mit QueryPerformanceCounter

[Sharky]

Hai Logh,

ersteinmal : "Herzlich Willkommen in der Delphi-PRAXIS".

Mal unabhängig von Delphi. Bist Du sicher das die serielle Schnisstelle mit so einem Tak klar kommte? :gruebel:

[mr47]

µ ist doch = Mikro also 1µs = 1 Millionstel Sekunde oder? Das geht afaik mit der Seriellen nicht.

[Logh]

Danke für den Herzlichen Empfang. (leider weiß ich nicht mich mit smilies auszudrücken)

ja µ heißt 1 millionstel sek.
die serielle Schinstelle kann, soweit ich das weis 19200 bit\s max. übertragen, d.h. 1 bit wird in 0,0000520833333 ~ 52µs übertragen.
Bei 9600 dauert es 1/9600 = 0.000104166667 ~ 104µs.
Also die serielle Schnittstelle kommt da schon mit.

[runger]

Hallo,

wir haben hier ein ähnliches Problem schonmal gelöst.
Abhängig davon was du mit deinem Signal machen willst, könntest du auch die Handshake-Leitungen benutzen.
Mit Asynch-Pro kann man diese Ausgänge einfach setzen oder rücksetzen.
Das geht relativ flott, allerdings weiss ich nicht wie flott, ich bin aber sicher, dass man damit die us Grenze erreichen kann.
Der Takt der mit Txd erreichbar ist kann nur einer der Standardbaudrates entsprechen, ist also für eine solche Aufgabe recht ungeeignet, es sei denn du benötigst eine entsprechende Frequenz.
Was willst du damit eigentlich erreichen? Taktgenerator oder ähnliches?

Rainer

[glkgereon]

Zitat:

Zitat von Logh

Danke für den Herzlichen Empfang. (leider weiß ich nicht mich mit smilies auszudrücken)

ja µ heißt 1 millionstel sek.
die serielle Schinstelle kann, soweit ich das weis 19200 bit\s max. übertragen, d.h. 1 bit wird in 0,0000520833333 ~ 52µs übertragen.
Bei 9600 dauert es 1/9600 = 0.000104166667 ~ 104µs.
Also die serielle Schnittstelle kommt da schon mit.

afaik werden immer mehrere bits auf eimal übertragen (16?)
daher braucht er 16(?)mal länger

[Logh]

ja,

er braucht 16 mal länger aber beim takt setzt man ein bit oder nicht.

Ich brauche das, damit ich mit einer bestimmten IC variante kommunizieren kann.

Folgendes liegt vor:

Als Schul projekt habe ich es mir zur Aufgabe gemacht, mit einem IButton ein Sicherheits System zu erstellen. Ein Ibutton ist ein IC, welches ein Identifikationsnummer in sich trägt, damit kann man Systeme vor unbefugten schützen.
Der Ibutton(sieht aus wie eine Knopfzelle) wird in eine auslese Vorrichtung gelegt- und nun kommt der Rechner ins Spiel- dort wird mit einem bestimmten Protokoll mit dem IButton kommuniziert. Der IButton sendet seine ID an den PC, der überprüft ob die ID richtig ist und schaltet z.B. den Rechner an.
Die Kommunikation:
Um mit dem IButton zu kommunizieren, muss eine Leitung, an die der IButton angeschlossen ist, auf High oder Low gelegt werden, und zwar in µs-Bereich, z.B. Leitung = 0 für 50 µs und danach Leitung = 1 für 100µs, interpretiert der IButton als ein empfangenes Bit. Nun muss man diese Signal folgen im µ-Bereich erzeugen. Die Übertragung ist seriell über eine Leitung (Es kommuniziert über die Versorgung).

So viel dazu.

[mr47]

Zitat:

Zitat von Logh

ja,

er braucht 16 mal länger aber beim takt setzt man ein bit oder nicht.

Er meint damit, dass deine Rechnung nicht stimmt, dass man für ein Bit 0,0000520833333 ~ 52µs braucht, weil 16 bit auf einmal übertragen werden. D.h. dass die Zeit in der ein Bit versendet wird 16x länger ist, weil ja noch 15 andere versendet werden. D.h. ~52*16 = ~832µs (oder denk ich jetzt auch falsch :gruebel: )

mfg

edit1+2: Schreibfehler

[dizzy]

Mal am Rande: Selbst wenn es die Serielle schaffen kann, so hat man aber noch immer keine Möglichkeit derart kurze Intervalle am PC vorzugeben, oder irre ich da? Sämtliche Timer bewegen sich doch im ms-Bereich bzw. geben sie Ticks wieder (dessen Geschwindigkeit dann wiederum von der CPU abhängt). Und selbst wenn man auf Basis eines Timers auf Ticks arbeitet, so werden etwaige Berechungen und Ein-/Ausgabe-Befehle eine Verarbeitungszeit hervorrufen, die a) in ihrer Dauer unter Windows nicht abschätzbar ist, und b) eventuell ohnehin zu lang wäre.

Oder bin ich grad völlig auf dem falschen Dampfer? (Will ich nicht aussließen :))

[glkgereon]

genau das mein ich.

es stimmt nicht das man bei einer angabe 9600b/sek ein bit in 1/9600s übertragen kann sondern lediglich 16/16*9600s.
macht rechnerich keinen unterschied, doch für den takt sehr wohl...

[mr47]

Bei 832µs sind wir dann schon fast wieder bei 1ms. Und dann bringst ja nicht mehr :gruebel: .

[freak4fun]

Ich dachte immer die 16 Bit werden gleichzeitig gesendet. :gruebel:

MfG
freak

[glkgereon]

ja eben!

darum gehts ja...der takt is dann nämlich langsamer als wenn er sie einzeln senden würde

[mr47]

Zitat:

Zitat von freak4fun

Ich dachte immer die 16 Bit werden gleichzeitig gesendet. :gruebel:

MfG
freak

Jemand isst 16 Gummibärchen PRO Sekunde. Wenn er 16 auf einmal in den Mund stopft hat er dafür 1 Sekunde Zeit. Er isst also nicht EINS in 1/16 (einer Sechzentel) Sekunde sondern 16 in einer ganzen Sekunde. Also ist der intervall nicht 1/16s sondern 1 Sekunde. That's the prob :-|

mfg

[freak4fun]

Das sehe ich nicht ein! Schickst du mir bitte genügend Gummibärchen zum Testen? :mrgreen:

Ne, Spaß bei Seite, ich habs verstanden, danke. :zwinker:

MfG
freak

[glkgereon]

[ot] blödes beispiel! ich hab hunger :( [/ot]

aber ganz abgesehen davon: kann man mit windows auf ne ms genau takten?

[mr47]

Zitat:

Zitat von glkgereon

[ot] blödes beispiel! ich hab hunger :( [/ot]

aber ganz abgesehen davon: kann man mit windows auf ne ms genau takten?

1ms: jain. Also der TTimer kann schon einen Intervall von 1ms. Aber wenn's mal "Stau" im System gibt wird der glaub schnell ungenau. Und das wäre relativ unpraktisch. Ausserdem braucht er ja 1 Mikrosekunde und das ist 1/1000-stel von 1 ms. :?

mfg

[brechi]

wenn man wirklich machen will das kein thread etwas anderes machen kann (funktioniert nur mit einem prozessor)

Delphi-Quellcode:

procedure blaa;
asm
// (no other thread can do something, doesnt work in IDE)
// example, do not call sleep
  mov ecx, $FFFFFFFF
@@weiter:
  dec ecx
  test ecx, ecx
  jnz @@weiter
end;

procedure TForm1.FormCreate(Sender: TObject);
var tid: cardinal;
begin
  tid := CreateThread(nil,0,@blaa,nil,CREATE_SUSPENDED,tid);
  SetThreadPriority(tid,THREAD_PRIORITY_TIME_CRITICAL);
  SetPriorityClass(GetCurrentProcess,REALTIME_PRIORITY_CLASS);
  ResumeThread(tid);
  SetPriorityClass(GetCurrentProcess,NORMAL_PRIORITY_CLASS);
end;

mit __ asm { rdtsc } könnte man noch die tickcounts lesen und wirklich auf 1msek genau prüfen
obs aber sinnvoll is das so zu machen ist ne andere frage

[Logh]

Zitat:

es stimmt nicht das man bei einer angabe 9600b/sek ein bit in 1/9600s übertragen kann sondern lediglich 16/16*9600s.
macht rechnerich keinen unterschied, doch für den takt sehr wohl...

9600 bits pro sekunde heißt, dass in 1 sek. 9600 bits übertragen werden.
Das bedeutet ein bit braucht 1/9600, um übertragen zu werden.
Daher stimmt es nicht wenn man sagt in 1/9600 "s", denn 9600 sind keine Zeit, sondern bits.

Da die serielle Schnittstelle nur 9 pins hat können gar nicht 16 bit auf einmal gesendet werden. Das könnte aller höchstens bei der parallelen Schnittstelle gehen.

Ich habe mal bei meinem Rechner nachgeschaut-115200 bit/s schafft die serielle Schnittstelle, also 8,685...µs pro bit-das geht.

Eine wichtige Sache ist, das, wie schon erwähnt, die Software, also die Befehle zu lange brauchen um ein Ereignis auszulösen.
Daher die Frage:
kann man in Delphi Assembler programmieren?
Wenn ja, werden die Assembler Anweisungen sofort an die CPU geschickt oder gibt es da auch eine "Bremse".

Schade das es keinen µTimer gibt!

Noch ne Frage was ist dieses "Tick"?-kenn ich nicht.
Wie lange dauert dieses "Tick"?

Weiterhin danke für alle Antworten, sie sind alle willkommen.

[Logh]

Hab erst jetzt die 2. seite gesehen.

mov ecx, $FFFFFFFF

warum $FFFFFFFF, das ist doch zu lange.
Ich hab keine Ahnung von dem Code, den du hingeschreiben hast-d.h. ich weiß nicht wie man mit Delphi asm programmiert und Thread kenne ich auch nicht.
daher die Frage:
Wie lange dauert blaa.

[supermuckl]

eigentlich sollte dir "thread" geläufig sein, falls du ASM codest

http://de.wikipedia.org/wiki/Thread

[mr47]

Zitat:

Zitat von Logh

Daher stimmt es nicht wenn man sagt in 1/9600 "s", denn 9600 sind keine Zeit, sondern bits.

Das ist unsinn: 9600 Bits / Sekunde. Also braucht ein BIT 1/9600 SEKUNDE, da ja 9600 in einer Sekunde durchmüssen!! Es ist unsinn zu Sagen 1 bit braucht 1/9600 bits oder? :wall:
9600 sind Bits das ist klar. Aber 1/9600 ist eine Zeit.

Was überigens trotzdem nicht stimmt weil bei 9 Pins werden ja auch mehrere Bits gleichzeitig übertragen.

mfg

[supermuckl]

Zitat:

weil bei 9 Pins werden ja auch mehrere Bits gleichzeitig übertragen.

die meisten sind 1. nicht belegt und 2. nicht nur für die daten da, sondern für das "protokoll"

[mr47]

Zitat:

Zitat von supermuckl

Zitat:

weil bei 9 Pins werden ja auch mehrere Bits gleichzeitig übertragen.

die meisten sind 1. nicht belegt und 2. nicht nur für die daten da, sondern für das "protokoll"

heißt das es sind effektiv nur 1 (oder 2) Pins die wirklich Daten übertragen? Das ist ja verschwendung :roll: . Aber nagut, dann erfüllt es den Zweck von Logh ja umso mehr! :thumb: .

mfg

[supermuckl]

es heist ja nicht umsonst SERIELLE schnittstelle ;)

und weil da halt n ganzes protokoll dahinter steckt, kann man auch nicht sagen, das die bits die übertragen werden, nur daten sind.

da werden CRC checksummen und Stopbits übertragen ...

[Sharky]

Zitat:

Zitat von mr47

...heißt das es sind effektiv nur 1 (oder 2) Pins die wirklich Daten übertragen? ...

Es ist zwar OT aber ich denke an dieser Stelle sollte die Schnittstelle mal kurz erklärt werden.

Normalerweise sitzt in einem PC eine RS232 (V.24) Schnittstelle. Für die bidirektionale Übertragung sind genau drei Leitungen notwendig. Bei einem 9pol. Sub-D Anschluss sind dies:

Code:

[u]Pin  Bezeichnung    Beschreibung[/u]
2    Receive (RxD)  Empfangs-Daten
3    Transmit (TxD) Sende-Daten
5    GND            Null-Bezugspunkt

Eine logische '0' wird durch eine Spannung von +12 Volt, eine logische '1' durch -12 V dargestellt
Die Übertragung läuft nun so ab:

Vor jedem Zeichentransfer liegt auf der Übertragungsleitung das Signal auf High-Pegel (H). Soll nun ein Zeichen übertragen werden, so wird dies dem Empfänger vom Sender durch ein Startbit angezeigt, indem für einen Taktzyklus das Signal auf Low (L) gelegt wird. Damit sind Sender und Empfänger für dieses Zeichen synchronisiert. Danach folgen die einzelnen Bits des Zeichens, wahlweise 5 bis 8 Daten, Paritätsbit, sowie 1, 1½ oder 2 Stopbit(s). Anhand der Stopbits erkennt der Empfänger das Ende des Zeichens, damit dient das Stopbit ebenfalls der Zeichensynchronisation.

Um komunizieren zu können müssen beiden Geräte die selbe Einstellung für:

Code:

Anzahl der Datenbits
Art der Parität (Odd, Even)
Anzahl der Stopbits

Da man in der Regel das Startbit, das Paritäts und die Stopbits nicht auswerten kann, diese aber bei der Übertragungsgeschwindigkeit berücksichtigt werden bedeutet dies das in einem Frame zwar 8 Bit ausgewertet werden können aber bis zu 11 gesendet wurden (8 Daten, 1 Start, 2 Stopp).

Wenn die Schnittstelle nun maximal 115200 Bit/s senden/empfangen kann bedeutet dies.

115200 DIV 11 = 10472 Frames (1 Frame zu 8Bit)
10472 Frames * 8 = 83776 Bit (die ausgewertet werden können)

Es zeigt sich also das es nicht möglich ist Bits im µs Takt zu empfangen.

[Logh]

Zitat:

Das ist unsinn: 9600 Bits / Sekunde. Also braucht ein BIT 1/9600 SEKUNDE, da ja 9600 in einer Sekunde durchmüssen!! Es ist unsinn zu Sagen 1 bit braucht 1/9600 bits oder?
9600 sind Bits das ist klar. Aber 1/9600 ist eine Zeit.

Was überigens trotzdem nicht stimmt weil bei 9 Pins werden ja auch mehrere Bits gleichzeitig übertragen.

Wenn ein Auto für eine Strecke 100 Km 100h braucht, dann braucht er für 1Km/h = 100h/100Km.



Es stimmt, dass man bei 11bits ein solches Ergebnis bekommt aber es geht hier nur darum ein Pin (z.B. RST) auf high zu setzten, da ist es nicht mit Parität und Start/Stopbits.
Und die serielle Schnittstelle ist µ-Fähig.
Erst vor kuzem haben wir mit dem µC Daten an die serielle Schnittstelle geschickt und zwar 1 bit in 52µs, d.h. 19200 Baud, das ganze war mit Parität, Start/Stopbits.

In asm, habe ich nur mit dem Mikrocontroller Erfahrung, daher kenne ich keine Threads.

[Logh]

Da die Ansichten von einander abweichen, denke ich sollten wir nur eine Lösung für den Timer im µs-Bereich finden und die serielle Schnittstelle mal außer acht lassen.

[Phistev]

Benutzt der IButton eigentlich die COM-(serielle)Schnittstelle des PCs, oder hat er eine eigene Schnittstelle? Für einen Timer im µs-Bereich dürfte ein PC zu ungenau sein, selbst mit Realtime-Priorität wird's schwer, da man GENAU wissen muss, 1. welcher Takt der Prozessor hat und wie genau der Takt ist, und 2. wie lange (µs / Takte) eine Anweisung dauert. Am besten dürfte für so eine Aufgabe ein Hardware-Interface sein, dass nicht so zeitgenau angesteuert werden muss.

[mr47]

[Mein letztes OT]

Zitat:

Das ist unsinn: 9600 Bits / Sekunde. Also braucht ein BIT 1/9600 SEKUNDE, da ja 9600 in einer Sekunde durchmüssen!! Es ist unsinn zu Sagen 1 bit braucht 1/9600 bits oder?
9600 sind Bits das ist klar. Aber 1/9600 ist eine Zeit.

Was überigens trotzdem nicht stimmt weil bei 9 Pins werden ja auch mehrere Bits gleichzeitig übertragen.

Sorry ich hab was falsches geschrieben (aber ich habs richtig gemeint :wink: ). Du hattest recht, ich habs nur falsch verstanden!

Ich hab geschrieben

Aber 1/9600 ist eine Zeit.

Ist natürlich weder Zeit noch Datenmenge, sonder Zeit pro Datenmenge, also ne eingene Einheit! Aber nach wie vor ist es falsch zu sagen 1s /9600 bit wären bits! Es ist Zeit pro Datenmenge :wink:

so jetzt misch ich mich nicht mehr OT ein :roll:

mfg
[/Mein letztes OT]