Currently using six flip flops. On this board I want to do the same thing yet I have limited board real estate so I would like to do it with lesser components. Whats the best route to take. This is dividing a frequency output of a PIC chip so 3.3v is all it needs to handle and its just going to drive a transistor. Thanks in advance.
Frequency divide by 64
- Thread starter Tobias
- Start date
If you have a PIC that is providing the signal, why don't you just change the software to divide that output by 64?
If, for some reason, that is not an option, then you could use a single 8-bit counter chip and let it free run using the PIC output as a clock (assuming it isn't glitchy) and use the 6th bit output.
If, for some reason, that is not an option, then you could use a single 8-bit counter chip and let it free run using the PIC output as a clock (assuming it isn't glitchy) and use the 6th bit output.
I use Pic Basic Pro. I have two options, one is to use the HPWM command and the other is to change the CCP settings on the fly. The HPWM command is pretty clean but both limit me to the frequency range. I need from 0-360HZ and I use an 8MHZ OCS. So thats why I use the flips flops. I will look into 8 bit counter, thank you.
You have a programmable microcontroller -- here's a third option: program it to do what you want; you can make the output toggle once every 3.2 days if you want to.
Set a timer to expire at some convenient period. Use that to test and decrement a counter. When the counter reaches zero, toggle your output and reset the counter to the number of expirations you want before the next toggle. You can do this on a micro that doesn't even have any timers or interrupts, but you have to resort to cycle counting and write all of the code with that in mind.
Set a timer to expire at some convenient period. Use that to test and decrement a counter. When the counter reaches zero, toggle your output and reset the counter to the number of expirations you want before the next toggle. You can do this on a micro that doesn't even have any timers or interrupts, but you have to resort to cycle counting and write all of the code with that in mind.
Ill give you an explanation of why I am needing this.
Basically I am fooling a hydraulic drive controller into thinking there is a hydraulic motor connected to it. The controller outputs a PWM and is expecting a feedback signal. So I measure the duty cycle and know that at 100% duty cycle, the feedback input to the controller is expecting 360 rpm. At 0% is 0 RPM. The PWM output is 150HZ. On the output shaft of the hydraulic motor normally is a 360ppr encoder. So I am simulating the encoders feedback. Max RPM of the drive is 360rpm
My circuitry works pretty good now but I have three dual flipflops on the board. I need to clean it up.
Basically I am fooling a hydraulic drive controller into thinking there is a hydraulic motor connected to it. The controller outputs a PWM and is expecting a feedback signal. So I measure the duty cycle and know that at 100% duty cycle, the feedback input to the controller is expecting 360 rpm. At 0% is 0 RPM. The PWM output is 150HZ. On the output shaft of the hydraulic motor normally is a 360ppr encoder. So I am simulating the encoders feedback. Max RPM of the drive is 360rpm
My circuitry works pretty good now but I have three dual flipflops on the board. I need to clean it up.
Last edited:
I think I follow what you are trying to do, but I think you may have slipped and used some words where you didn't mean to.
So the controller is outputing a fixed-frequency (150Hz) PWM signal with a variable duty cycle. You measure that duty cycle and want to generate a feedback signal that is a variable-frequency, fixed-duty cycle squarewave. Correct?
You say that the speed ranges from 0rpm to 360rpm. But you said that the signal you needed to generate was in the range of 0Hz to 360Hz. Does this mean that the motor puts out 60 pulses per revolution?
If that is all this PIC is doing, measuring the duty-cycle of the fixed-frequency signal on one pin and producing a variable frequency square wave on the other, then this would seem to be a simple task for even the most brain-dead 8-pin PIC.
The trickiest part is going to be getting good resolution at the fast end. If the fastest signal you want to output is 360Hz, what is the second fastest? Keep in mind that the difference in time between edges on a 360Hz square wave and a 359Hz square wave is less than 4µs; depending on the PIC, that might be only half an instruction cycle.
There are a number of ways to go about this, some easier then others depending on the answers to some questions. The biggest one is how accurate you need the feedback signal to match the ideal one.
So the controller is outputing a fixed-frequency (150Hz) PWM signal with a variable duty cycle. You measure that duty cycle and want to generate a feedback signal that is a variable-frequency, fixed-duty cycle squarewave. Correct?
You say that the speed ranges from 0rpm to 360rpm. But you said that the signal you needed to generate was in the range of 0Hz to 360Hz. Does this mean that the motor puts out 60 pulses per revolution?
If that is all this PIC is doing, measuring the duty-cycle of the fixed-frequency signal on one pin and producing a variable frequency square wave on the other, then this would seem to be a simple task for even the most brain-dead 8-pin PIC.
The trickiest part is going to be getting good resolution at the fast end. If the fastest signal you want to output is 360Hz, what is the second fastest? Keep in mind that the difference in time between edges on a 360Hz square wave and a 359Hz square wave is less than 4µs; depending on the PIC, that might be only half an instruction cycle.
There are a number of ways to go about this, some easier then others depending on the answers to some questions. The biggest one is how accurate you need the feedback signal to match the ideal one.
As near as I can tell, the encoder is 60 pulses per revolution because 360rpm equates to a 360Hz signal.
You missed the point, which was about resolution. Let's say that he can exactly produce a 360Hz signal. What is the next, slightly slower, signal that he can produce? What if he needs to be able to produce a 359Hz waveform.
Remember, he is using this to emulate the feedback from a hydraulic motor which can produce a continuously variable frequency. The controller is going to see motor speed changes that comes in jumps and if those jumps are too big, the controller might end up going unstable.
So let's say that he concludes that he needs to be able to produce changes in apparent speed of 1%. That means that the next slowest speed he would need to be able to produce would be 356.4rpm. The waveform for the 360Hz waveform has to switch every 1389µs. The corresponding time for a 356.4rpm signal would be 1403µs. So the code has to be able to function with a resolution of 14µs. (Note that the 4µs was for a next slower speed of 359Hz).
I did. however, mess up when I said that many PICs would have instruction clocks at barely twice that speed. The instruction clock would be 500ns for the ones I am referring to. That's what I get for doing math in my head.
You missed the point, which was about resolution. Let's say that he can exactly produce a 360Hz signal. What is the next, slightly slower, signal that he can produce? What if he needs to be able to produce a 359Hz waveform.
Remember, he is using this to emulate the feedback from a hydraulic motor which can produce a continuously variable frequency. The controller is going to see motor speed changes that comes in jumps and if those jumps are too big, the controller might end up going unstable.
So let's say that he concludes that he needs to be able to produce changes in apparent speed of 1%. That means that the next slowest speed he would need to be able to produce would be 356.4rpm. The waveform for the 360Hz waveform has to switch every 1389µs. The corresponding time for a 356.4rpm signal would be 1403µs. So the code has to be able to function with a resolution of 14µs. (Note that the 4µs was for a next slower speed of 359Hz).
I did. however, mess up when I said that many PICs would have instruction clocks at barely twice that speed. The instruction clock would be 500ns for the ones I am referring to. That's what I get for doing math in my head.
Last edited:
That sounds reasonable. Maybe Tobias can clarify the discrepancy?
I was about to ask, "What descrepancy? Why do you think it has a 360ppr encoder?" Then I went back to look it over and see where he stated that it has a 360ppr encoder. So, yes, he needs to clear it up. I'm not sure which one is more likely, since both could have been simple typos.
If it is a 360ppr encoder, then the time resolution problem becomes more pronounced. The time between edges at 360rpm and 356.4rpm (1% less) become 231.5µs and 233.8µs. So he would need a resolution of a couple microseconds. Using a PIC with a timer and an interrupt capability, that should be doable.
I think the CD4024 will work. It contains seven cascaded toggle flip flops and is designed to divide by powers of two up to 128, so you should be able to avoid code changes to your PIC.
