> I would like to use my ARMExpress to measure the voltage decay time,
> up until a logic low is reached, when power is removed from the RL
> circuit.
The RCTIME function will do it, or you can use the free running TIMER
to measure the time in microseconds.
Timing decay
-
YahooArchive
- Posts: 1462
- Joined: Fri Oct 19, 2012 5:11 am
Re: Timing decay
>from support line
>What are the differences between RCTIME and PULSIN ?
You can take a look at the source in /Program Files/Coridium/BASIClib
The only difference is RCTIME returns 1 if the pin is not in the
requested state.
With version 7 all calls take the form of functions
x = RCTIME (pin, state)
There may be some old links in the helpfiles to the version 6 (PBASIC
form) without the ()s
>I am measuring the duration that an asynchronous pulse stays in a
certain state. I use either ON EINT0 or ON EINT2 interrupt to detect
when the pulse arrives. Within that interrupt routine I call either
RCTIME or PULSEIN. For what I am doing, is there a difference between
those two functions ? I notice that RCTIME turns interrupts off and on
while PULSIN does not.
They probably should both turn off interrupts.
Interrupt routines should probably not do things like PULSEIN, though
there are no rules in programming (ie. always could be an exception).
It would probably be better for an interrupt to record the time of an
event and return to the main program. Its possible to switch an
interrupt from rising to falling edge, not sure how long it takes, but
might work for 10kHz maybe even 100 KHz.
How many EINT0 or EINT2 interrupts can be stacked up pending to be
processed ? i.e. if their interrupt routine takes longer to process its
code than the period they are firing at, will the ones that generated a
new interrupt still have their interrupt routine called when the
preceeding one finally finishes being processed ?
The interrupts don't stack, ie. if you want to stack up a bunch of
events, you should record the event and time and let the main program
sort out the event list. If an EINT2 occurs while an EINT0 is being
processed, the EINT2 will be serviced AFTER the EINT0 routine finishes.
The same would be true for multiple interrupts of the same type. If
they occur that close together, most likely your interrupt service
routine is too long.
>What are the differences between RCTIME and PULSIN ?
You can take a look at the source in /Program Files/Coridium/BASIClib
The only difference is RCTIME returns 1 if the pin is not in the
requested state.
With version 7 all calls take the form of functions
x = RCTIME (pin, state)
There may be some old links in the helpfiles to the version 6 (PBASIC
form) without the ()s
>I am measuring the duration that an asynchronous pulse stays in a
certain state. I use either ON EINT0 or ON EINT2 interrupt to detect
when the pulse arrives. Within that interrupt routine I call either
RCTIME or PULSEIN. For what I am doing, is there a difference between
those two functions ? I notice that RCTIME turns interrupts off and on
while PULSIN does not.
They probably should both turn off interrupts.
Interrupt routines should probably not do things like PULSEIN, though
there are no rules in programming (ie. always could be an exception).
It would probably be better for an interrupt to record the time of an
event and return to the main program. Its possible to switch an
interrupt from rising to falling edge, not sure how long it takes, but
might work for 10kHz maybe even 100 KHz.
How many EINT0 or EINT2 interrupts can be stacked up pending to be
processed ? i.e. if their interrupt routine takes longer to process its
code than the period they are firing at, will the ones that generated a
new interrupt still have their interrupt routine called when the
preceeding one finally finishes being processed ?
The interrupts don't stack, ie. if you want to stack up a bunch of
events, you should record the event and time and let the main program
sort out the event list. If an EINT2 occurs while an EINT0 is being
processed, the EINT2 will be serviced AFTER the EINT0 routine finishes.
The same would be true for multiple interrupts of the same type. If
they occur that close together, most likely your interrupt service
routine is too long.
-
YahooArchive
- Posts: 1462
- Joined: Fri Oct 19, 2012 5:11 am
Re: Timing decay
>
> as part of the Enterprise project, one aspect is the speed control
of
> 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
states
> 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
> system.
>
> Since a 1-2 rpm variation in inconsequential, I am thinking that
when
> I go to check the speed i can check for a state. Whatever the
current
> 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 ??
>
> Thanks
>
> Jim
>
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!
-t
> as part of the Enterprise project, one aspect is the speed control
of
> 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
states
> 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
> system.
>
> Since a 1-2 rpm variation in inconsequential, I am thinking that
when
> I go to check the speed i can check for a state. Whatever the
current
> 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 ??
>
> Thanks
>
> Jim
>
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!
-t