> as part of the Enterprise project, one aspect is the speed control
> the processing drum. On the drive system there is a 5 segment wheel
> that passes through a HA1A photo dectector so there is 5 high
> and 5 low states per revolution. At the point on the fan the
> effective circumference is about 7" so at 50 rpm (Max speed) this
> translates to about 350 in /min = 5.8" per sec and the blade width
> through the sensor is about .7" so we get about 8.3 pulses per sec
> with each pulse having a duration of about 1200 ms.
> The main program on the slave processor with this speed control is
> handled by basically is comprised of 4 subroutine calls: it checks
> for commands from the serial port coming from the master processor
> and reacts to the commands, it checks temperatures and controls for
> two heater systems and it checks and controls the rpm of the drive
> Since a 1-2 rpm variation in inconsequential, I am thinking that
> I go to check the speed i can check for a state. Whatever the
> state is then I starting looping until I detect the opposite state
> and then use Pulsin for that state to eventually return the ms in
> that state. Knowning the time and since the portion of the
> circumference is fixed, I can back convert to RPM.
> Does this make sense ??
Yes, it makes sense, kinda...
I question the math a little, so I'll regurgitate what I understand
from the description above to see if the fog clears:
If the circumference where the photodetector is 7" and there are 5
blades, then each leading edge of the blade is 1.4" apart (7"/5).
With the blade width being ~.7", that should yeild a 50/50 duty cycle
of on/off for the photodetector running at an effective frequency of
~4.16hz. I see where you are citing ~8.3hz. I presume that you are
talking about state transitions vs. looking at it like a square wave
frequency. Either way, I think I now understand what your up against.
Yes, looping to detect a state change, and then doing a pulsein will
certainly work, but I know for a fact that a huge amount of work
could be done in that time that pulsein is sitting there and waiting
for a state change. If that time being out of the main control loop
is not a problem - ie. the slave-processor has pleanty of overhead to
play with - then that is by far the simplest solution. If, however,
you are wanting to accomplish work (not miss a comm event from the
master, etc.), then I offer the following for consideration:
I have faced a similar timing challenge with respect to receiving and
parsing NMEA sentence bursts from a GPS receiver, yet not wanting to
wait too long for the next sentences to come in. The way I
approached it was to do some timing studies (such as you have done
above) and then with the known periods, set a variable to the timer
when the initial detected event occured (state change in your case).
In the main control loop, I repeatedly called the various service
subs (4 in your case). The sentence capturing service sub (pulse
time capturing in your case) would check to see if it was close
enough to warrant waiting for a sentence burst (an incoming state
change in your case).
When it was within Xus of the expected event (again, state change in
your case), it would then sit and wait for the event. When the event
was detected a temp variable was set with the time of the event (from
the free running timer), the math was then done (temp var -
last_event_time) to determine periods (and ~RPM in your case). Once
the math was done, the last_event_timer was then set to the temp vars
contents which represents the most recent event and the pulse
servicing sub returned to the main control loop.
In my case, I was receiving sentence bursts at 1Hz intervals. Each
sentence burst was ~75ms long (quite a bit of data can be crammed
down the throats of the MCUs at 115K baud), which left 925ms for
servicing the other needs of the main control loop. I was able to
call the other service subs (depending on their content) for up to
~775 different iterations before I had to go back and start listening
for the next sentence bursts.
My point being this, if it is sitting there for 1200ms doing nothing
other than waiting for a state change, AND things are getting missed
due to this delay, there is a means to address it and still keep the
main control loop serviced very efficiently.
Another alternative, which I mention with some reservation (as I
don't know if you have v7 capabilities and/or the skillsets [no
offense intended]) is the use of a timer interrupt to affect
this 'listening' as predetermined iterations. Or, the way that I'd
probably implement it, ultimately, is via the use of an external
interrupt. <--- doing this turns the monitoring over to the interrupt
hardware in the ARM7 Core's accessories. All of this, while being
very efficient, may present you with learning curves that you might
not be comfortable with. If, conversly, you feel that you do want to
tackle it in that manner, I'd strongly encourage you to do so, as
price paid for gaining the knowledge will surely pay for itself many
times over, if you keep playing in the embedded world.
WOWzers - that was a heck of a lot more of a reply than I intended.
Sorry for that. Bruce can attest that I do get 'verbal' diarreah
once in a while...
Please reply with any further questions. I can't promise that I'll
be as timely in replying, but I do keep an eye on the traffic, even
if I am burried professionally. I know that Bruce and others do too,
and I suspect that they'll be able to help you out too...
Good luck with your exciting project!