How to count pulses per second ?

Sorry, I didn't mean to just criticize your code and run. I accidentally hit the send button (f*&&$*% touchpads on laptops). I like to see C snippets that show how the micro and compiler work with ints and SFRs. Thanks for posting that. Is that GCC? Looks like it would probably work ok for the OP unless pulse rates got too high and started overflowing the pulse counter. High int rates would make the delay routine take longer to execute too, but probably wouldn't really matter. I think he's measuring people passing by so you're probably pretty safe. :-)

Reply to
Anthony Fremont
Loading thread data ...

Like JF says, I'm an expert at nit-picking things. ;-) Actually, it really is a knack that I seem to have with software design. I may suck at electronics, but I'm pretty good at finding problems with program designs.

Reply to
Anthony Fremont

Yep, it's GCC. I wrote and built that code using WinAVR from

formatting link

Good point on overflowing the pulse counter. Of course, it would take

32,768 PPS (people per second) to do it! :)

Good point on the delay routine as well. A better way to do that would have been to put the 1 second timer on an interrupt as well and just have the main loop do nothing. That way the 1 second timing could only be effected, at max, by the length of time it takes to run the INT0 interrupt handler.

Jason

Reply to
Jason von Nieda

I was thinking (daydreaming?) that he might be measuring legs since they would tend to break the "beam" for a short period while they "swung" by, that's probably what I'd try anyway.

But your right, even with two legs, it'd be impossible for that many people to travel thru some practical sensor that would only need to worry about

10ppS.

Right, and there are even ways to make this absolutely perfect (outside clock accuracy) in terms of measuring off precise 1 second intervals and firing the ISR without so much as 1 clock cycle of "jitter". Sometimes you have no choice but to be that picky. This wouldn't be one of those times though. ;-)

Being an OCD kinda guy leads to tinkering with this stuff and then finding out why the most often uttered phrase during an epiphany isnt "Eureka!", it's more likely to be "hmm.....that sure is strange". I've found a couple of hardware bugs in PICs over the years like this, or were they really just "Obscure Undocumented Features".

Reply to
Anthony Fremont

Jason: Thanks for the example code. This looks (almost) simple. (I say almost because I'm sure there are a few things to figure out in terms of finding the necessary libraries and getting all the pieces together in the compiler/programmer).. pardon my lack of knowledge in these things... but to a total beginner in the microcontroller-programming field, what is the difference between the AVR and a PIC? only reason I ask is because it looks like Atmel is the only mfr of these things, and they are relatively pricey compared to the pic's ... are the libraries & code interchangeable between the pic programmers? I dont know much about this, but i'd like to pickup a starter kit and try this solution out... any guidance is appreciated.

MC

Reply to
Mike C

Hi Mike,

There's actually very little to figure out and collect to get that running. If you are using Windows you just download WinAVR from

formatting link
which includes the compiler, linker, assembler, libraries and programs for actually burning your code to the chips, along with a bunch of utility programs. If you are using Linux there are a few more steps... but then, there always are with Linux :)

The biggest difference between AVR and PIC, to me, is the availability of quality development tools for the AVR series. The chips themselves have similar functions throughout the different families and I'd be willing to say you can probably solve any problem with one equally as well as the other, but the quality and availability of free development tools for AVR is much higher in my experience. GCC, which most people are familiar with, is an excellent compiler and is the default toolchain for AVRs. When I was working with PICs there was no free C compiler and while I can program assembler when needed, I prefer not to.

Code and libraries are definitely not interchangeable. The IO is completely different on the two families.

Atmel is indeed the only mfr. for AVR; not much more I can say on that. Hopefully Atmel doesn't die on us :) One thing to note on price is that the AVR I am using (the ATmega8) is actually a pretty beefy chip. I use them because I don't like to keep a bunch of different parts around the house and they almost always meet my needs. In many cases you can use a much smaller (and cheaper) chip. Check out the ATTiny series on Digikey. They start around $0.54 each and you'll be using the same code, compiler and routines. The code I wrote would run on an ATTiny just fine just by changing a few of the IO register names I used.

For a starter kit check out the stuff at Sparkfun at

formatting link
If you want to use the Mega8 check out
formatting link
which is really nice. In the related components at the bottom of the page you can buy a few chips and a programmer. You can get started with the ATTiny series with
formatting link
but it looks like it's currently out of stock. I just do all my prototyping on a solderless breadboard but having a little board like the ones linked above that include a RS232 level converter and such would be great for getting started.

Jason

Reply to
Jason von Nieda

--
No, the issue is your attitude.
Reply to
John Fields

--
Hmmm... This may be nit-picking as well, but I can\'t recall ever
having said that. ;)
Reply to
John Fields

Ok John, I'll try to work on it for you. Good thing you set such a shining example for me to follow.

That, my dear friend, depends entirely upon how you define "right", doesn't it? For the OP here, maybe not. If it was for myself, of course. If it was for production, quite possibly. It will almost certainly use less parts, cost can be brought down to pittance, so it has those merits for someone looking in that direction.

I'm not even in disagreement with that.

gawd this is good.......

LOL. That is probably the most self-serving emission you've put forth yet. The truth is that you are just pissed again and now you've got to start blaming me for wasting your time.

Now that I've offered code, I'm a jerk because I didn't offer to burn a PIC and mail it to him? If I do that, then what will you find wrong? Man John, I didn't reply to the OP originally because I didn't really have time to write him some code. I'm going to do it though, if I ever get done answering to you. BTW, where exactly do you get off in telling me what I should do "with my life"? PKB

Microcontrollers ARE the greatest thing since sliced bread IMO (cuz I don't know FPGAs), but it never upsets that someone chooses not to use one. What upsets me (for the ten millionth time) is people who go off over the mere mention of the word, why can't you understand that. Oh I know, you don't really have a problem with that per se, you just don't like me.

Actually it was to make a joke, I really don't understand why you went ballistic over it. You got lucky, they solved your problem quickly, they're not gods. I've dealt with them far too many times to count. They're not any different than any other support line. Their first level support blows, just like everyones. Once you get past them, you can usually find the people that know what's going on. It's par for the course.

You make it sound like I said all that in one post, but of course it was another volley just like this that escalated to that point. It is true that I said that it is STUPID for ANYONE to connect a PC directly to the internet with a public IP. I also briefly covered the implications of the "yellow disk". I can't call people stupid for installing that, because they think they have to. They don't know any better, so they get bent over by your heros at SBC/Yahoo right off the bat, before even getting on the internet the first time. I was just trying to educate you on that, but you know it all already, right?

As far as making friends, I already showed you the thread where we met. Is that the proper way to do it?

Just show one post where I "tell everyone just exactly how they should live their lives" liar. I liked the "argumentative troll with an unwarentdly high opinion" part though, even if you did spell it wrong. ;-)

Always plenty of time to dish out more of your own though, isn't there?

Reply to
Anthony Fremont

Mike, if your frequency rate limit is fairly sloppy and you just want simple, you might cobble up something with a frequency to voltage converter, an RC low pass filter and a comparator.

Take a look at the data sheet for the LM2907:

formatting link

There may be a version that includes the comparator, but I can't remember the part number.

Reply to
John Popelish

Well, you likely didn't use the word expert, but you said something about my nit-picking things. It's a skill, why waste it? ;-)

Reply to
Anthony Fremont
** Groper fool alert.

** So - do actually you want a pulse counter or a frequency detector ??

Your first para asks for a pulse counter which totals over successive 1 second increments and reacts to a count of 10 or more.

Your second para asks for a pulse RATE detector that recognises a rate greater than 10 Hz.

So which is it?

....... Phil

Reply to
Phil Allison

Plonk.

--
Service to my country? Been there, Done that, and I\'ve got my DD214 to
prove it.
Member of DAV #85.

Michael A. Terrell
Central Florida
Reply to
Michael A. Terrell

Good job Terrell, you just killfiled someone that stuck up for you in the past.

Reply to
Anthony Fremont

Hi, Mr. Fields. All this for a homework assignment! The OP should be as pleased as a clam.

The idea above was that the pulses the OP is counting are going into the 4518, which is trying to count to ten before the first (left) half of the 556 briefly resets once every second. The second half of the

556 is just responsible for outputting an indication (say, 1/2 second to drive an LED) if the count ever gets to 10. Retriggering shouldn't be an issue -- if the pulse rate is less than 10, the second timer should never go off.

It is sloppy, but it should do most of what the OP asked for, I'd guess.

Cheers Chris

Reply to
Chris

--
I\'m not telling you what to do, I\'m offering you an alternative
which would more closely conform to your -position.
Reply to
John Fields

--
It wasn\'t about it being a skill, it was about inaccurate reporting.
Reply to
John Fields

--
Funny!!! :-)
Reply to
John Fields

--
In other words he\'s done something that you think he shouldn\'t have?

That is, he\'s acted in a way which isn\'t in accordance with your
wishes?

That is, you want him to do things the way you want him to?
Reply to
John Fields

Hi, Mr. Foley,

I think he wants the LED to stay on continuously as long as there are ten or more pulses occurring every second. That means that for no gaps to occur in the illumination of the LED the period of the timer must be longer than the time it takes for the counter to accumulate ten input pulses. However, since the 555 is normally not retriggerable, the "10" decode will occur while the timer is still timing out. This won't extend the timing at all, so the timer will time out and the LED will go out even though 10 pulses were counted.

If you change the counter, though, and make it retriggerable it should work perfectly. I'm currently working on simulating a similar scheme but I'm having trouble with chattering around the switching point and low sensitivity, which I think your circuit will eliminate by making the LED timer retriggerable.

So, what I'll do is take your circuit, (which is almost like mine) make the LED timer retriggerable, switch some parts around, and run it since I've got almost all of it done anyway.

I'll post the LTSPICE circuit list when I'm done. (Whether it works or not... ;))

--
JF
Reply to
John Fields

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.