measuring pulsewidth

[brandonb]

i came up with this half cooked way of measureing pulsewidth 0-20m/s in 100u/s increments, it does work for the most part but it has issues in certain ranges, i wanted to make it with a 1K tmr2 interrupt but i cant seem to figure out the right crystal or setting combo to get 1k..... the way i really wanted to do it is when a positive port interrupt happens i want to turn on tmr2 at 1khz and count pulses until port interrupt goes low then command with decisions both interrupts off update display of count variable then re enable interrupts, display update 4 times a second.....then again if you guys have a better suggestion that would be awsome .... the odd numbers in the delay loop is to get exactly 50u/s on/off time as veiwed with scope,which compensates for loop losses to obtain 10khz

[Gary Freegard]

Hi Brandon

Have a look at this http://www.matrixmultimedia.com/mmforum ... =29&t=9088 , as Jan wanted to do the same.
May give you other options/ideas.

Gary

[brandonb]

exactly what is the interrupt priority, i've asked that question a few times with no results, or where do i find that info?..... i checked out your flowcode but i have a hard time following other peoples work.... the funny thing about this deal is it works spot on in most of the low ranges, then it errors 100u/s-200u/s on the higher pulse widths, but on certain values for some reason it shows the value on first pulse then it shows zero, if i go 100u/s in either direction the those values are correct and dont disappear to zero, whats going on to cause that to happen? sometimes things appear simple in theory but are more difficult to explain the abnormal phenomenia that sometimes occurs.... i only have one interrupt working in this which is port set to pin b4 by flowcode, does that make this a different problem than your example? thanks for responding on this

[kersing]

exactly what is the interrupt priority, i've asked that question a few times with no results, or where do i find that info?.....

Generally speaking: interrupt priority allows multiple interrupts to occur at the same time where the interrupt with the highest priority will be serviced first. Interrupts with a higher priority can occur and will be services even when an interrupt with a lower priority is being serviced. What is considered the lower and what the higher priority depends on the specific device being used. (Higher numbers are not by definition a higher priority, it depends on the definitions used by the manufacturer.)

The PIC16 series does not have interrupt priorities, the PIC18 series has. The datasheet of each device provides details on the features available.

Best regards,

Jac

[Gary Freegard]

Hi Brandon

After reading the datasheet http://ww1.microchip.com/downloads/en/d ... 41262a.pdf Chapter 14 figure 14-6, this shows that all the interrupts have the same priority, as Jac said, so its first come first serve.

I have made a few of changes to your program

• Using 16F877A at 19.6MHz
  Change LCD to Port B (Using a development board)
  Change INT to Port B 6
  Placed Interrupt Enable in a macro
  Placed the ‘count’ inside a do loop
  The update display is outside the above loop.
  The Interrupt is disabled on entry to update display and then enabled on exit, reason for this is that if an interrupt happened during the update display the count wouldn't start until after all the update display section was completed by which time you would have missed it any way
  I have added a float calculation to this section, as I found that the time was out (97.5%) , so the count is multiplied by 1.025, in my case, so that the displayed time is more accurate, you could play around with the delays a bit more to improve but using the float calculation is an easy way of calibrating.

The reading is within 100us.
If you want to measure 100uSec more accurately, I would recommend that you change the delays to say 10us total, and then compensate for this using the float calculation, but obviously this would limit your max pulsewidth to 0.32768 sec.

I have tried it with quite a few different pulsewidths and it appears to work very well, so if you are still having issues then you may need to change your crystal to something a bit faster.

Gary

[brandonb]

i figured out some crystal values that are nice to have 16.384Mhz and 20.48Mhz, both give many numbers including 1000 and 10000 as tmr prescaler numbers, most of the numbers donot have decimals, should be getting those in a couple days and i'll update progress

[brandonb]

alright, this thing works great, crystal that makes it all tick is 20.48Mhz.... sorry guys i decided to go uninfluenced on this one as i was determined it was gonna work, it measures 100u/s to 20m/s with up to 10 times a second display update rate depending on input frequency.... i have to put in a sring manipulation to put a decimal before the last number and all will be peachy