> From: Scott Fisher <spam_OUTfisherscTakeThisOuT
MAILSERV1.FERRIS.EDU>
>
> I am new to using a pic so my experience is very limited. I was given
> a project to do that involves sensing four rotating shafts and
> determining the RPM. The RPM is then displayed on four sets of seven
> segment LED displays that are multiplexed to reduce I/O pins. I will
> also have in the program RPM set points for each shaft that will sound
> an alarm when a shaft speed is lower then the set point. The shaft
> speeds range from 50 to 950 RPM and I would like to update the
> displays at least every 10 seconds. I was thinking of using a timer to
> keep track of how long each shaft takes to rotate, but have not
> determined how I am going to convert this to RPM. What I am mainly
> looking for are some suggestions on how I should go about
> accomplishing this task and maybe some code on the frequency
> conversion or ideas.
Do you get one pulse per revolution? Would taking measurements in
round robin fashion be OK? How many digits for each display?
What percentage/absolute accuracy?
I will assume the answers to the above are yes, yes, 2 and +/- 1%.
{Quote hidden}>
> I was thinking I could use a 16c65 and use portb's interrupt on change
> feature as the four external interrupt inputs. The 16c65 also has
> enough I/O to allow me to do all my multiplexing. Am I asking too
> much from this chip? Or should I go to using four separate chips to
> determine RPM for each sensor and then send that data serial to
> another pic that multiplexes the displays and checks the set points.
> If I used four 16c84's this would allow me to use the external
> interrupt pin RB0 on each chip.
>
> All suggestions would be appreciated,
>
> Scott Fisher
>
The interrupt on change feature has a few quirks including the fact
that it may miss a change if the change happens just as the port is
being read (or written, for that matter). If the odd glitch is not
a problem then you could do everything however I would suggest using
a 4-1 multiplexor which routes the inputs into RB0 so you can use
interrupt on falling edge. The initial interrupt which might occur
when changing the mux should be suppressed by disabling that interrupt.
The interrupt service routine should get a 16-bit period count based
on TMR1 between successive interrupts from the same selected input.
Simultaneously, TMR0 overflow can be used to mux the LED display.
The mainline code would be responsible for converting the period
count into RPM via fixed point division, loading the registers
used for the LED display, checking the setpoints and handling the
keyboard (assuming a 3x4 matrix).
As I see it you would need pins assigned as:
RA0,1 Mux input selector
RA2-4 LED digit selector (1-of-8)
RB0 Muxed input
RB1-3 Kbd column selector
RB4-7 Keyboard rows (use int on change for keybd)
RC1-7 LED segments (a-g)
RC0 Alarm output
which would necessitate a 28-pin PIC.
If the PIC has a capture module you can use it to take away some of the
timing drudgery.
The division used for converting period to frequency has been covered
previously in the PICLIST. There are plenty of routines floating (no pun
intended) around.
Regards,
SJH
Canberra, Australia
