Speed of USB EasyHID and Time problem

[sjohansson]

Can someone please help me to find out why I'm not able to measure higher freq than 67Hz. Is it the speed of the USB transfer that takes too long time?

I would really apreciate if you can help me.

Thanks

Stefan.

[skimask]

Can someone please help me to find out why I'm not able to measure higher freq than 67Hz. Is it the speed of the USB transfer that takes too long time?

I would really apreciate if you can help me.

Thanks

Stefan.

Are you saying that you can only get samples from USB at 67hz or that the PIC can only count up to 67hz?

[sjohansson]

No not really. It should be 130Hz something. When the dutycycle is shorter than 7,5ms (130Hz) the pic send strange values to my vb application.
I'm sure the pic can count much higher frequences, especially as I use the CCP1 input. But my question is if there is some bugs in my pic program or if the USB is taking too long so the timer1 measure something else than only the high pulse.

Sorry for the bad English.

Regards
Stefan.

[skimask]

No not really. It should be 130Hz something. When the dutycycle is shorter than 7,5ms (130Hz) the pic send strange values to my vb application.
I'm sure the pic can count much higher frequences, especially as I use the CCP1 input. But my question is if there is some bugs in my pic program or if the USB is taking too long so the timer1 measure something else than only the high pulse.

Sorry for the bad English.

Regards
Stefan.

So, simulate some numbers. Plug in fake values into your registers (turn off the timers so they don't count up themselves), and see what the VB program displays. If it's good, you've probably got your CCP registers set up incorrectly. Also, make sure you're not trying to start counting in the middle of a pulse or something when the USB service RETURNs, wait for a solid high or low, then start counting.

[sjohansson]

So, simulate some numbers. Plug in fake values into your registers (turn off the timers so they don't count up themselves), and see what the VB program displays.

Good idea, I will try that.

Also, make sure you're not trying to start counting in the middle of a pulse or something when the USB service RETURNs, wait for a solid high or low, then start counting.

How can I do that? I thought that's what CCP1IF does. Just triggering if ccp pin rising or falling. Right?

Also another question; Is it best to turn On and Off the timer for each cycle or should it be On all the time and just reset the timer registers?

[skimask]

Good idea, I will try that.


How can I do that? I thought that's what CCP1IF does. Just triggering if ccp pin rising or falling. Right?

Also another question; Is it best to turn On and Off the timer for each cycle or should it be On all the time and just reset the timer registers?

Just a thought, and I know it's not the best thought...

Since the hardware is giving you a bit of a problem, have you thought about using PBP's built-in Count and/or Pulsin commands? At 48mhz, you should have plenty of resolution to work with.

Also, you might want to put an LCD of some sort on your PIC, so you can read the values before they get send over the USB to the PC. You might be sending bad numbers in the first place.

For the problem-How about a variable that's declared as a byte variable that you might actually want as a word variable? (overflowing where you don't want it to, something like that)

[Darrel Taylor]

Hi Stefan,

I've been looking at your program, and frankly I've got more questions than answers. But, I have found a few interesting things.

First off, I can verify that the program completely "Wigs Out" when the pulses are faster than 125pps. This also seems to be the Limit for the number of HID reports per second. I've been working on a couple other USB programs and have seen the same number.

An easy way to verify what's happening is to modify the DoUSBout like this...

' ************************************************************
' * wait for USB interface to attach                         *
' ************************************************************
DoUSBOut:
   USBBufferCount = USBBufferSizeTX              ' TX buffer size
   USBService                                    ' keep connection alive
   USBOut 1, USBBuffer, USBBufferCount, OutBusy  ' if bus available, transmit data
   return
     
OutBusy:
  toggle PORTB.0         ' toggle led to show when USB is busy
GOTO DoUSBOut

Change the PORTB.0 to an LED on your board.

Then you'll see that the "BAD" numbers received by the VB program, happen at the same time the LED starts blinking, due to a busy USB condition. (anything above 125hz)

At this point I still don't understand what's going wrong, but I have found a possible way around it. By changing the DoUSBOut to this...

' ************************************************************
' * don't wait for USB interface to attach, abort if busy    *
' ************************************************************
DoUSBOut:
   USBBufferCount = USBBufferSizeTX              ' TX buffer size
   USBService                                    ' keep connection alive
   USBOut 1, USBBuffer, USBBufferCount, OutBusy  ' if bus available, transmit data
   RETURN
     
OutBusy:
  toggle PORTB.0         ' toggle led to show when USB is busy
RETURN

This will discard the current reading if the USB is busy, and go back and measure another pulse, (rinse and repeat).

I've run it up to 500hz and it never "messes up".

Of course, this won't be able to report every pulse to the VB program, Hopefully you don't need them all.

HTH,