Delay smaller then 1ms

[Wim S]

Hello

I am using two pins of my PC's parallel port to communicate with an I2C EEPROM device.  It works pretty well, but it's very slow. The reason is that the function Delay that I use to generate my SCL signal has a resolution of only 1ms. According to the EEPROM's datasheet, I can use an SCL with a low pulse with of 1.2µs, and a high pulse with of 0.6µs. Is there any way to get a smaller delay then 1ms. I am thinking about using a dummy for-loop for delay generation, but then the delay will be system dependant...

All suggestions are appreciated,

Wim 

[menchar]

Wim -

DirectX has a clock with resolution of 100 nanoseconds.   The IReferenceClock interface exposes the reference clock functionality of DirectX.

It's described in the Win32 SDK.  It's a base class (CBaseReferenceClock), so you wouldn't be able to use it from C, you'd have to use C++ I would think.

As you said, if you're not doing anything else with your system, why not do a busy wait?  You could Sleep() or Delay() a few times a second to allow the system to process other threads, and do a busy wait the rest of the time.   

Yup, the down side of a busy wait scheme, among other things, is that it's processor speed dependent.  Getting it calibrated / tuned is a hassle. 

You could also use a dedicated high priority or real time priority thread to do the writing, this would minimize the time the OS lets other threads run.

I don't think you're going to find any OS service with a time resolution of under a millisecond in WIn32 except for the maybe the media-related timers (e.g. DirectX).

Menchar

[GarthE]

Wim,

Look up the following functions in the windows SDK.

QueryPerformanceCounter

QueryPerformanceFrequency

To implement a delay use QueryPerformanceCounter to get the start time.  Then QueryPerformanceFrequency to get the number of clock ticks per second.  Calculate how many clock ticks you want to wait and use QueryPerformanceCounter in a loop to calculate your delta.  Once the time interval specified has been reached jump out.

Garth 

[menchar]

Garth -

Great info - shows you what I know 😉

Menchar

[MJF]

Given an ideal world and access to a hardware solution, I would recommend that over any sort of software means of doing this. Some sort of DAQ card with a built-in timer and GPIO capability would be a much better solution, there may also be a USB based solution or something similar out there. Actually... I just did a quick Google and the first two links on a search for "i2c programmer usb" give two programmers under $250 each (one of them was about $100). If I were in your shoes, I would get one of those goodies and forget about doing this the hard way.

Now having said that, have you tried just leaving the delay out altogether? It could well be that the time it takes to execute the writes to the parallel port is sufficient as is without any additional delay. To verify this for certain, you will need to get an oscilloscope or a logic analyzer to verify the pulse widths. Because this is an I/O port device, it may have sufficient wait-states built into the port access that it could be just fine writing to it without any additional software generated delays.

When you are getting down into such small time intervals, the processor in your PC is not going to be the best tool for implementing a delay. There is no dedicated hardware way of timing it and there are so many variables with processor speed and many other things that you simply can't predict how fast you can write to the port.

[Wim S]

Hello guys,

Thanks for your fast replies, it's really appreciated.

Unfortunately I don't have mucht time to spend on this issue, so I guess the USB to I2C convertor might be the best solution. Leaving out the Delays works fine on my PC, but I don'tknow if it will work on all systems...

Thanks,

Wim

[MJF]

Happy to help Wim. Sometimes the "easy" or "cheap" solution is neither. In a case like this, I would much rather spend the $100 to $250 to buy the hardware than expend a couple of days trying to get it to work on a parallel port. Especially since my labor for two days costs my employer a lot more than the price of the adapter.

[menchar]

GarthE -

How do you do any arithmetic with the __int64 data type? 

Or is there a way to do arithmetic on the LARGE_INTEGER values?  I tried assigning the LARGE_INTEGER.QuadPart to an __int64 variable (the assigment appears to work just fine) but when I try to subtract two __int64 types I get a GPF.

Thanks,

Menchar

[GarthE]

Here is an example piece of code.

//start timer
 QueryPerformanceCounter (&startDelayTimer);
 
 //get the number of counts per second
 QueryPerformanceFrequency (&ticksPerSecond);

 //get the number of ticks per microsecond
 ticksPerMicroSecond = ticksPerSecond.QuadPart / 1000000;
 
 //the delay is specified in microseconds
 ticksToWait = (LONGLONG) (delay * ticksPerMicroSecond);

    do
 {
  //get current tick count
  QueryPerformanceCounter(&currentTickCount);   

 }while( (currentTickCount.QuadPart - startDelayTimer.QuadPart) < ticksToWait);  

The QuadPart is a LONGLONG which is a __int64 so binary manipulation should work.

[menchar]

GarthE -

I get a GPF (general protection fault) when I try to subtract the QuadParts of the two values, the same as when I try to subtract any two __int64 values.

Or when I do any arithmetic on __int64 values for that matter.  All that I can seem to do is assignment and printing of __int64s.  Expressions with __int64 data types compile and build just fine in CVI, without error, but then fault at runtime.  

Seems like a compiler issue to me.

Do you know that the code you posted will compile and execute in CVI? 

Menchar