Precise timming?

General discussions about V-USB, our firmware-only implementation of a low speed USB device on Atmel's AVR microcontrollers
Post Reply
eslavko
Rank 1
Rank 1
Posts: 36
Joined: Sat Dec 18, 2010 6:37 pm

Precise timming?

Post by eslavko » Thu Jan 06, 2011 11:43 am

Hello...

I wan't to know if it's possible to make pulse of precise lengh't without to disturb USB interface.
Best to explain with example.
I had DS1820 thermometer and wan't to control it with VUSB. The timming is precise and longest pulse is 500uS logg (reset) and the data pulses are shorter than 120uS.
So if I wish to make precise 500uS pulse I should dissable interrupt to have precise timing. But dissabling interrupt fot that long is not good as just few cycles are alowed.
So I just think in other way.
If I understand usb correctly the transfer starts every milisecond and after packet is send then just wait another 1ms frame.
Is there a way to know when transaction is ended and how long was is.?
Ie If I know that last transaction was 300uS long and know that is ended 'right now' then I can make pulse with simple loop for 700us long as I know that no interrupt can be generated until next 1ms frame.
Is possible to got such information?

Thanks.

eslavko
Rank 1
Rank 1
Posts: 36
Joined: Sat Dec 18, 2010 6:37 pm

Re: Precise timming?

Post by eslavko » Thu Jan 06, 2011 12:57 pm

.. to describe idea in detail.

I observe pulses with osciloscope. When no data transfer is in place the D- line get's Low pulse every milisecond. The D+ is all time low. When transfer is in place the both lines are toogling.
So idea is like that.

in main loop.
Reset 'interupt' flag.
wait until 'interrupt' flag is set OR D- is read LOW
wait 3 bit time ' to get interrupt if SOF is received

if 'interrupt' flag is reset then
we have near 1ms time free (no interrupt's can occour in that time)
so do the job here
if 'interrupt' flag is set then our job take to long (it was disturbed with interrupt)
end if


and in USB_SOF_HOOK we just set 'interrupt' flag

Is that make sense?

ViSoft

Re: Precise timming?

Post by ViSoft » Thu Jun 07, 2012 1:19 pm

Hello, have You already solved this issue? Can U provide the code fragment?
I have the same problem, generating I2C packet S|ADDR|P which takes too long and is disturbed by USB (maybe because the device reacts any low-speed request no matter what device it targets?), so I tried to finish usbPoll() as soon as possible, disable USB by clearing the USB_INTR_ENABLE &=~ (1 << USB_INTR_ENABLE_BIT); and doing my transfer - then enabling the USB_INTR_ENABLE again. Then the main loop calls the usbPoll().
Timing was fine now but my nBytes=usb_control_msg() too often fails from nBytes<0 (STALL?). I have already spent two weeks on it, please help...

Post Reply