Reading Pulses

JCoon

··· Basically, I want to read pulses.· EX) The width of each pulse.· I have a system that operates on a fail-safe design using a 4.82Hz pulse.· Sometimes, a drop-out occurs during·the digital high, or the pulse is skipped completely. ·Because of this,·I want to read both the high and low to detect if an error occurs.· However, this is where my problem occurs.· Using the pulsin command, I can only get either or the 'highs' or all the low pulse widths.· This is becuase if I try to obtain both...I obtain a low, it then skips the high (because it doesn't see the low-to-high transaction??), skips the low, obtains the high, skips the low(doesn't see the high-to-low??), skips the high, and obtains the low.· My question is, how do I obtain both the high and low and write both vaules into eeprom??·

·· The only (pricey) way I can think of is using 2 stamps, 1 obtaining the low, the other the high, and writing to an external eeprom.· Anyway, here is a short example of my code used for obtaining the high pulse.· Thank you.
···
··


· PULSIN 0, 1, tcounterhigh
· tcounterhigh = tcounterhigh /500
··'DEBUG DEC tcounterhigh, CR
· WRITE xplot, tcounterhigh
· xplot = xplot + 1

Paul Baker

Im not sure if this is the best work around for your problem, but after you detect one pulse width (high or low), you can get a pseudo-pulsin for the other level by checking the state of the pin and incrementing a counter until it changes state. If you need to detect every single pulse width you should replace both pulsin's with the polling method described above. The problem with this method is that you cannot get as high of a resolution as with the PULSIN command, but since your pulses·are 4.82Hz this isn't really an issue. Here is a sample code portion.

Hcnt·· var·· word
Lcnt·· var·· word
Hcnt = 0
Lcnt = 0
DO
··· DO WHILE (PulsPort = 1)
······· Hcnt = Hcnt + 1
··· LOOP
··· DO·WHILE (PulsPort = 0)
······· Lcnt = Lcnt +1
··· LOOP
··· 'perform action based upon values
··· Lcnt = 0
··· Hcnt = ???··· 'set this variable to the equivalent count value required to execute the code after the last loop until the next loop
LOOP

Pulsport is the pin used for the signal, the Hcnt set to ??? is to account for the time required to execute the code after obtaining Lcnt and looping back to get the next Hcnt, since this execution time occurs during the next·high pulse, this is to·get as accurate of a value as possible for the next Hcnt.

JCoon

···· Thank you for your advice.· However, I found that way to be extremely inacurrate and to be an overall·headache.·

·Ex)When I tried it that way..
·1) I came up w/·a 2 factors, 1 for the high, 1 for the low.
·2) Multiplied·each factor (by using the */ command) by the answer I got from the loop.
·3) Thereby obtaining·an accurate·time in mS for both.· Good, right?! Not so fast...·
·4) The issues then started. For example when I would either change the code or use a different frequency pulse, my result in mS would be extremely inaccurate again.

KenM

SX?

Tracy Allen

maybe this:

findTimes:
stateBit = in0 ' what state is it in now?
RCTIME 0, stateBit, tcounterHigh ' wait for that state to end (came in in the middle)
RCTIME 0, ~stateBit, tcounterLow ' measure duration of opposite state
RCTIME 0, stateBit, tcounterHigh ' measure duration of original state
' *2 for microseconds, /500 for milliseconds.
RETURN

The time it takes for the Stamp to interpret the RCTIME command is about 220 microseconds <emesystems.com/BS2speed.htm>, so you might have to add that offset to your result. But it might drop out in the wash, because you were dividing by 500 anyway to convert Stamp 2us resolution to milliseconds.

The times you are measuring are about 104 milliseconds, and the BS2 can measure up to 131 milliseconds with RCTIME or PULSIN.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com

Paul Baker

Thanks Tracy, I forgot RCTIME uses only the trailing edge to obtain a value.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

Bruce Bates

KenM said...
SX?

Ken -

Here is the section of the Parallax web site which describes the Parallax SX processor offerings:····· ·http://www.parallax.com/sx/index.asp·.

All Parallax Basic Stamp Modules use an interpreter to drive the processor chip. The SX product uses assembler and/or·the SX/B·Basic macro language to drive the processor. This puts you in direct control of the hardware, and avoids all the overhead and possible limitations associated with an interpreter.

PBASIC, the high level Basic language of Parallax Basic Stamps is simplicity itself, yet it is still able to offer a high degree of flexibilty and power to the microcontroller user, which in turn provides fast prototyping, fast turn-around, and simple but adequate tools for debugging your progams. The lack of interrupts can sometimes be problematic, raw speed is often an issue, and there is no direct access to all the hardware features of the various chips on which the prorgams run. So too there are some limitations to the PBASIC language itself, but those are rarely a true hinderance. Those same limitations are seen in almost all interpretive languages. It's just the nature of·interpreters in general.

The SX/B Compiler offers many of the same higher level commands as PBASIC·to remove the burden of having to learn assembler for simple or un-complicated programs, or programs where·indirect control of the chip and the I/O ports·is adequate and timing restrictions aren't too severe. Yet, if the need arises, this platform permits you to drop immediately down into native assembly language·for one or many lines of code, which might otherwise be unavailable by remaining in the superset SX/B Macro language.

Through the assembly language the full power of the chip can be brought to bear on your project. SX/B Basic commands and assembler coding can be interspersed, as necessary,·throughout the user program as needed, so you can enjoy the best of both worlds on the fly. The SX/B Basic commands wind up in native assembler code, so there is no loss of speed or power in using them. Full speed, complete control and ease of use - a great combination. There is also an interactive debugging facility available, but I'm not all that familiar with it, so I won't comment beyond the fact that it exists.

There are hardware/firmware programming tools which·need to be purchased to use the SX/B platform, but they are quite reasonably priced, especially when compared to similar tools required for other languages and platforms ofered by others.

I'm not a Parallax employee just a very satisfied user, and that's just how I view the differences, advantages and disadvantages of each of the platforms. Both have their place and neither should be ignored. In tandem, they increase the size and breadth of the programmer's tool bag and in turn his/her capabilities, and flexibility.

Regards,

Bruce Bates

JCoon

RCTIME seemed to work.

Though, / 500 didn't work. I had to calculate another factor (roughly 282 for the low and 454 for a high).

Also, when I adjust the code, I have to re-calculate the factors ever so slightly.

However, when I change my input pulse (frequency), it accurately outputs the correct pulse widths. Thereby working exactly the way I wanted it to. Thank you all Mr. Baker and Mr. Allen.