OSDev.org

Hi,

Does anybody have ideas how to improve my code, I measure time between pulses fed to serial port CTS pin (on/off)..

I can get 5-10us accuracy at the moment, I would like to get 1us accuracy.

Here is code :

asm
db $0F,$A2
cli

mov edi,0
mov ecx,0

@sss2:

mov dx,$3f8
add dx,6
inc ecx

@sss:

in al,dx
shr al,5
jnc @sss

@sss0:

in al,dx
shl al,4
jc @sss0

dw 310fh
mov integer[timerlo][edi],eax
mov eax,0
add edi,4

in al,60h
cmp al,1b
je @ende

mov silmukka,ecx

jmp @sss2

@ende:

sti

serial port hardware is usually not that fast, they only need to do 115200 bps. You can expect the CTS hardware not to be any faster, and this translates to about 9 ms, so you are at the top.
PS: I don't see any RDTSC in your code.

PS2: this should not be in testing. This is normal development stuff.

dw 310fh = RDTSC

Note, this is not serial communication, my code only checks state of CTS pin on serial port.

Thanks.

hsimola wrote: dw 310fh = RDTSC

Note, this is not serial communication, my code only checks state of CTS pin on serial port.

Thanks.

If the CTS pin is only supposed to be used in serial communication at 115200 bps, why should it be able to operate any faster?

Ok, maybe you are right.

Any ideas to change for an example some other port where I can get faster on/off ?

Because RDTSC with command should get much better accuracy than 10us....

Hi,

hsimola wrote: Any ideas to change for an example some other port where I can get faster on/off ?

Because RDTSC with command should get much better accuracy than 10us....

The PIT timer channel 0 count is probably the highest frequency you'll find. The PIT timer chip uses a 1.193181666666 Mhz oscillator, so the timer count changes after about 0.8381 uS.

Of course the frequency of an IO port has nothing to do with the it's accuracy. You didn't mention what your code will be used for (I couldn't figure this out). If you are trying to calibrate RDTSC or measure the frequency of the CPU's clock you can do it with a much longer time delay. For e.g. you could use the real time clock for a 1 second delay:
Or even with a smaller time delay (100 mS):

Once RDTSC is calibrated it could be used for extremely small time delays - e.g. a CPU with a 1 Ghz clock would be able to measure time delays as small as 0.002 uS, with 0.001 uS resolution.


Cheers,

Brendan

Ok,

I am not trying to calibrate RDTSC or make small delays.

I just measure time between square wave pulses fed to serial port CTS pin. I use function generator (professional) to make square wave pulses.

Yes, 8253 timer chip is good also, but I think RDTSC is more accuarate. Problem with 8253 is that it can't be used measuring long times.

Frequencies I feed to serial port CTS pin are between 10-100Hz.

Thanks,

Harri

hsimola wrote: I just measure time between square wave pulses fed to serial port CTS pin. I use function generator (professional) to make square wave pulses.

Frequencies I feed to serial port CTS pin are between 10-100Hz.

You could try the parallel strobe pin? Parallel ports should make up to 8mbps with 8 channels, that's 1mbps per channel. Each time a byte is sent the strobe activates, and you can read it out. Or, in terms of hardware hacking the PC, you plug your device onto any of the input pins and you're set. If you use an awkward one make sure to have your port set to ECP

I have tried paraller port ACK pin. There was no difference.

I have to check this strobe issue, is it somehow different.

Does anybody have knowledge will there be difference between ACK pin compared to STROBE pin ?

hsimola wrote: Does anybody have knowledge will there be difference between ACK pin compared to STROBE pin ?

hm... thinking of it, the strobe only latches the other data... could be that it isn't passed on. You can of course use a data pin with strobe .

Could you please tell that in other wors, I didn't understood what you mean.

hsimola wrote: Could you please tell that in other wors, I didn't understood what you mean.

it could be that the strobe pin is a pin that is only used by the logic controlling the data pins, that is, it is not forwarded to the computer. Each time a normal device wants to send data, it puts the data on the data pins (raises/lowers them), waits for the charge to be forwarded, then raises the strobe pin. After a short while it lowers it again after which a byte of data has been passed. The byte is valid when strobe is high (or low, if inverted... not sure). If you thus load the bit, then raise the strobe, a byte will be sent. You can then mask out that bit to see when it's there.

An alternative would be to poll the parallel port status register for availability of a byte, which you then make available with the strobe. This might not work though, the X86 is not a realtime system and as such cannot guarantee those workaround devices to work perfectly.


The best idea would be to hijack some pin that always creates an interrupt. Try hijacking the INTB pin of the CPU or some pin of the ISA bus (assuming an old computer).

Data is first applied on the Parallel Port pins 2 to 7. The host then checks to see if the printer is busy. i.e. the busy line should be low. The program then asserts the strobe, waits a minimum of 1uS, and then de-asserts the strobe. Data is normally read by the printer/peripheral on the rising edge of the strobe. The printer will indicate that it is busy processing data via the Busy line. Once the printer has accepted data, it will acknowledge the byte by a negative pulse about 5uS on the nAck line.

That is what I found from http://www.beyondlogic.org/spp/parallel.htm

I think I try STROBE pin, just a test, I don't have enough knowledge.

Those other things you mentioned goes too diffcult for me.

I have PC's from Pentium II to Pentium 4, mostly laptops.

http://members.iweb.net.au/~pstorr/pcbo ... rallel.htm

On that site is comment about Strobe pin : a 1 usec pulse used to clock data into the printer

So, Rising time of pin should be enough for me.

But I don't know about other limits which may make things difficult to get my code accuracy to 1-5 us....