I am using the C51 compiler and have code for the silabs C8051F120.
I have built a wind speed sensor with a rotary encoder but it seems to top out at 42mph. I know there have been gusts greater than that since I started using it.
I have considered calibrating the unit with an automobile and think i may be missing edges of the encoder signal because of processing overhead. I think the encoder counter routine should be interrupt driven.
My coworker Frisky suggested the circuitry is not able to handle fast counting signals coming from sensor and said that the 2nd problem circuitry should be analyzed.
Does anyone have an idea why that might happen?
So change it to a calculation that will give an integer!
eg, if
the_speed = 1/pulse;
would give the speed in m/s, just change it to
the_speed = 1000/pulse;
to give the speed in mm/s - simple!
the "wind speed sensor" is the very same as a tachometer. Tachometer design is a well known excersize and there are basically two methods a) number of pulses in a given time b) time between two pulses
both are "basic timer coding"
Erik
But it is actually a bit innovative to get a digital processor to simulate the analog method of having an RC filter and reading the analog average of the pulsed signal :)
Frisky has told me that the hardware is good. but he thinks that the processor cant keep up with it so he thinks we need to upgrade to something faster# maybe an arm.
So i now need to know if i can move my code to the new one.
Anyone got any good ideas?
but he thinks that the processor cant keep up with it so he thinks we need to upgrade to something faster# maybe an arm.<p>
Well, I think you merely need to upgrade/debug your program.
Switching to an ARM won't help you if your program has fundamental flaws in it.
Frisky is a wise man. He wants more computing power to crunch numbers! I like that! yammi! But I am afraid that you'd have to apply the above recommendations first, and above all: to understand the source of your current difficulties!
As Per specificed, the limiting factor here is the width of your signal. I don't think your processor is the problem.
No. We do not think you are right about it. Frisky has looked at the signal and says that it does go up and down all the time so it must be working.
But he thinks that it go down for a short time and he says that an 8 bit processor cannot be fast enough to see it!
So we want to know if we go to the arm am I going to use the code I've done already?
the only thing "not fast enough" is your software! your software is broken, and worse: you don't believe it and do obviousely don't understand how to fix it (even though we told you how) because you probably don't know the specs. do as your told. fix your software. a new controller will have the same problems. I bet you 2 bottles of scotch!
Eh ... that's nonsense. The "bit-ness" of a processor has absolutely nothing to do with the width of pulses it can detect.
How "short" is the "short time" ?
You can use the code, but it will have exactly the same problems - because your code has some fundamental problems.
1. It uses heavyweight library functions (like printf) that gobble up CPU time like there's no tomorrow regardless of the processor architecture used.
2. It tries to poll a signal that should be acquired by some hardware mechanism (timer/counter, interrupt, whatever).
Fix these, and your program will run even on the cheapest '51.
Frisky is a wise man. He wants more computing power to crunch numbers! I like that! yammi!
It may be that Frisky is a wise man but he has no idea whatsoever about microcontrollers, in particular the '51.
If he did there would never have been a float in your code.
He wants more computing power to crunch numbers often a sign of incompetence. It is easy to fiddle soemthing together that will run if the resources are unlimited, making it work with limited resources takes skill.
A poor little 8-bit processor can handle many kHz if it is correctly programmed. In some situations, it may even be able to handle MHz signals.
Note that if using a hardware counter to count # of ticks in a fixed time interval, the max speed is limited by the counter hardware and not by the processor speed.
Issue one interrupt for each pulse. Check how many interrupts (pulses) you get in a second.
Or: connect signal to a timer and let it tick one step in hardware for each pulse.
If if you really do need to poll: Keep track of current and previous value. Only count when previous is zero and current is one. OR only count when previous is one and current is zero. That will give one count for every positive (or negative) flank of the tachometer signal.
And do make sure if your pulses has fixed or proportional pulse width. It does affect if the hardware has a limit on # of pulses that may be generated per second.
Why, you're trying to acquire a 1-bit signal ! Even an 8-bit processor has eight times more bits that required for your signal. That's way too much already, all the extra bits will get horrendously bored. If you add another 24 bits, there's no way to guess what all the poor, bored, underemployed bits might do inside the chip.
freyed,
You said earlier:
"I think the clock is going at 50MHZ and the pulses are going at about 18 to 22MS so i cannot see how the code can miss them."
You are right with that.
A basic 8051 running at 12MHz can easily do timing on 22ms pulses. But it assumes that the code is written in an appropriate fashion.
Just re-read the posts here, analyse your problem and fix your code.