PDA

View Full Version : Getting the first pulse every time with Pulsin ??



mr.sneezy
- 21st January 2013, 08:00
Question (trying to be generic here rather than post lots of code).
I want to confirm that the Pulsin statement MUST have both a leading and trailing edge to get a result. e.g. If my code loop does not jump back to running a Pulsin before the start of a new pulse (and catches it half way etc) will it ignore that pulse completely or will it measure a truncated pulse time ?

The scenario would be a case where the program loop, although it's very very short, still might happen during the start of the first pulse of a multi pulse frame, meaning the level on the pin is already at the logic level the Pulsin is looking for when it begins.

Do I have that understanding right ?

If so, then I guess if my program needs to do anything else while also waiting for a Pulse start, then I should really use an interrupt to catch the first one of the frame reliably.

Anyone ?

Thanks,
Martin

Chirpy
- 21st January 2013, 16:58
Ive used pulsin before on some tv remote learning projects, and even at 40Khz, it's fine. I think it's like 600Khz or higher that the chips start having issues at 20Mhz, and 200Khz at 400Khz, so for most things, it should be fine unless you have a lot going on in the loop which eats up alot of cpu cycles. if that's the case, you can have it run on an interrupt and store the pulsin value in a value to read after you get 8 or so bits (the size of the input string).

mr.sneezy
- 22nd January 2013, 08:43
True, I find the speed is fine too, just I seem to miss the first pulse occasionally. My 88 bit frame only come around every 48 seconds for about 100mS, so there is a long wait for a new frame and the PulsIn times out many many times while waiting.

I guess I'd best assume then that the remaining program loop could be overlapping the start of the first pulse occasionally and do some other methods to rectify it.
One thing I did think of is to actually increase the Pulsin timeout which will reduce the percentage of time spent in the rest of the loop, meaning the chances of a good first pulse leading edge go up I think.

Martin

HenrikOlsson
- 22nd January 2013, 11:11
Is it only the positive pulse width you're interested in or are you trying to grab the positive AND negative? How wide/narrow are these 88 pulses? 100ms/88=1360us per bit?

Idea: Connect the pulses to a pin capable of generating an interrupt. When the first pulse comes along the interrupt is fired. Grab the first pulse "manually" using a count loop or a hardware timer, compensate for the interrupt latency. After the first pulse is grabbed, still in the interrupt service routine, grab the rest of the pulses using the same method you're currently using. Alternatively grab the rest of the pulses using the same approach as the first one.

This way you can do whatever in your main loop, as soon the first pulse of a frame comes along an interrupt will be generated and you will be able to grab it.

/Henrik.