Speed of USB EasyHID and Time problem

[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,

[sjohansson]

Hi Darrel.

Thanks for verifying the problem. Now I know that it is not just my program messing with me..

But it's still confusing because when I use my Basic Stamp to simulate a signal, it works fine with 7ms High and 0ms low pulse. (BS code #3 in my first post.) This means that USBOut has enough time to execute even if the low pulse is only a few us. Can it be the vb app that is the bottleneck here?
Pic send it quick but next time it try to send the pc is still busy with the last one. What do you think about that?
If the pic is the bottleneck then I wonder how it can catch the next pulse without any problem? In that case it should be stuck in the DoUSBOut routine.

I will make a test to measure 16 pulses, save all values in buffer(0) to buffer(31) and then send all 32byte to the pc. Sending 32 bytes takes 22.4us according to my tests so that should be just fine from the pic point of view. It will be interesting to se how the pc handle it.

Unfortunatley I need to measure all pulses. I use the values in the vb app to calculate acceleration, rpm and total revs.

My next task is to simultaneously check the USBIn for new data.
This without halting the program. I have made some test with the code example from bruce at post:
http://www.picbasic.co.uk/forum/show...05&postcount=3
This seems to work but I have not test it at higher speed yet.
Do you have any other good solutions to do this? Maybe using USB interrupt USBIF or something else?

I'll let you know about my further test.

Thanks again.

Stefan.

[Darrel Taylor]

> Can it be the vb app that is the bottleneck here?

I was using a Delphi App, also created by EasyHID, and saw the same thing. So I doubt it's anything to do on the PC side.

> If the pic is the bottleneck then I wonder how it can catch the next pulse without any problem? In that case it should be stuck in the DoUSBOut routine.

As long as the frequency is less than 125hz, it never get's a BUSY response. But, once it goes above that, it does get "stuck in the DoUSBOut routine".
This becomes evident if you try the first example in Post#8.

> I will make a test to measure 16 pulses, save all values in buffer(0) to buffer(31) and then send all 32byte to the pc.

I guess it depends on the highest frequency you'll need to measure, but you may not need to go that high. For say 10,000 RPM, you'll only need about 166 samples per second (Unless there are multiple pulses per rev). So if you capture 2 samples per report, you'll only need 83 reports per second, which should be well within the limits, and give a faster "Update Rate".

> Do you have any other good solutions to do this? Maybe using USB interrupt USBIF or something else?

Well, there's this ...
Instant Interrupts - Revisited, post 148
http://www.picbasic.co.uk/forum/show...0682#post30682

Which works with this ...
USBDemo, something to learn USB a little bit
http://www.picbasic.co.uk/forum/showthread.php?t=5418

[sjohansson]

Thanks Darrel.

Fels like I'm on the right track again.
I made some tests with USBIn today and it seems to work.
I call DoUSBIn directly after the DoUSBOut so it has time enough to transmit before the next high pulse trig the ccp input.
And if the drum is not rotating DoUSBIn is called by interval using Timer3.

Regards

Stefan.