·You are referring to Sinewave dimming which happens to be a fairly new technology in the world of dimming. While the concept is pretty straight forward I don't know that it's something a hobbyist could do. Strand and ETC (www.silentdimming.com) both have sinewave dimming systems and have spent a lot of time, money, and effort creating them. While I love sinewave dimming I don't know how easy/economical it would be to implement.
I agree that it is probably harder than it looks, and that for most purposes a forward- or reverse-phase dimmer is sufficient. Having built both types previously I wanted to try something new. I drew up the diagram the other day, and that afternoon this thread popped up, so I decided to share it and get some feedback. As I said previously, it should work, but I haven't run it by my EE friend yet. The main thing I am unsure of is whether the high frequencies will cause the SCR to trigger prematurely (should be simply a matter of selecting a suitable SCR and inductor). This section could be omitted, but then you lose the overload protection.
Once I have a chance to try it I'll be sure to let you know.
I've run up against my first issue. When I sense a zero cross I enter a sub that sets each dimmer output based on a value between 0-255.
If the sub has just one output channel everything works great. However if I add in multiple outputs into my code the output timing is wrong (dramatically slow). I ran into a similar issue on a project a few months ago where multiple nested repeats were so slow that I had to put the timer part of the code on its own cog. I would hate to have to waste a cog like that but can if that’s what I need to do. It just seems to me that with a system clock at 80mHz the second example below should work just as well as the first. Thoughts?
Works (single):
· outa[noparse][[/noparse]0]~ · · repeat idx from 0 to 255 ····· if idx => ch[noparse][[/noparse]0] ······· outa[noparse][[/noparse]0]~~ ··· waitcnt(StepTime + cnt)· ' 32us wait
Doesn't work (multi):
· outa[noparse][[/noparse]0..15]~ · · repeat idx from 0 to 255 ··· repeat dim from 0 to 15 ····· if idx => ch[noparse][[/noparse]dim] ······· outa[noparse][[/noparse]dim]~~ ··· waitcnt(StepTime + cnt)· ' 32us wait
This is quite o.k.: The inner loop takes around 500 µs (so the additional 32µs are just a laugh). Doing this 256 times takes 128 ms
Have a look at my PWM Tutorial Thread; I gave some program variants for exactly your problem and explaine the constraints. But I think you cannot avoid the assembly version... http://forums.parallax.com/showthread.php?p=685997
PWM isn't really what I'm trying to do but I will take a peek.
*sigh* part of me wonders why spin exists since most of the time you have to move to assembly to get anything done. You would think that with a chip like this you would rarely need to move into assembly. In the end I use high level languges so I don't have to bother with the lower levels.
For the record I've done this sort of thing with a pic. What I normally do is setup an interrupt at 32us. When the interrupt occurs it increments a counter (0-255). My main code checks the counter and sets the outputs based on a comparison. I'm not sure how to do something similar to this with a prop. I spent some time looking at the counter modules but they seem to be geared toward outputs not just numerical references.
Post Edited (DynamoBen) : 12/22/2007 5:08:04 PM GMT
DynamoBen said...
PWM isn't really what I'm trying to do but I will take a peek.
Yes, it is what you are trying to do.. You just didn't know
said...
*sigh* part of me wonders why spin exists since most of the time you have to move to assembly to get anything done. You would think that with a chip like this you would rarely need to move into assembly. In the end I use high level languges so I don't have to bother with the lower levels.
A good remark! But this again is a misunderstanding. The Propeller is a assembly only machine! However a lot of functions has been pre-developed and is ready for many situations. SPIN is a "scripting language", allowing you to control those work horses in the COGs.
In rare situations, for educational code or when using the Propeller was tenfold overhead for you in the first place, you can also code your core algorithm in SPIN. This works because the Propeller is so terribly fast!
said...
For the record I've done this sort of thing with a pic. What I normally do is setup an interrupt at 32us. When the interrupt occurs it increments a counter (0-255). My main code checks the counter and sets the outputs based on a comparison. I'm not sure how to do something similar to this with a prop.
You do it similarly, waiting for the next 32µs tick. The problem is, that you then have time for about 4 SPIN lines
But you have time for 600 machine instructions!
DynamoBen said...
*sigh* part of me wonders why spin exists since most of the time you have to move to assembly to get anything done. You would think that with a chip like this you would rarely need to move into assembly. In the end I use high level languges so I don't have to bother with the lower levels.
Spin's really a convenience to allow code to be developed quickly and easily without the inconvenience of having to deal with assembly, and the cost of that is slower execution. Spin is suitable for many jobs, but not all. I'm frequently surprised at just how fast Spin can be, but as one needs faster execution it becomes less useful.
Even with compiled high level languages it sometimes becomes necessary to step down to assembler to get the performance required.
Yes, it is what you are trying to do.. You just didn't know
If I were doing DC dimming PWM would work great (I would be done by now). Normally when people refer to PWM they are controlling·both·duty cycle and frequency which repeat·over a span of time.·A "normal" PWM output doesn't rely on an external clock source for syncronization, it is controlled by the chips internal clock.
However in the case of AC dimming·I need to·sync my output pulse(s) to the AC zero cross point. That means there is one pulse each half cycle and the duration of that pulse is anywhere from 0-255·* 32.5us.
Post Edited (DynamoBen) : 12/22/2007 7:42:43 PM GMT
Ben,
my message was quite simple. What I showed in a comprehensive thread (later hijacked by Beau ) ist a method to work with half a hundred servos SYNCRONIZED to an extremely tight schedule. It came out what the isues are to do it in SPIN, and that most workarounds (except using half a dozen of COGs) tend to desync. In the end I gave a full working example of a machine code module with a simple interface.
I fully understand that you want to repaet all that for yourself, because this is the best way to learn, but don't say you do "something different". You dont, it is the same, absolutely the same..
Let me give some background, I’m trying to port an existing, functional PIC project to the prop. So I understand how to implement dimming with a microcontroller.·Because I’m new·here I thought I would ask for assistance instead of wasting hours on code that would never work (which as it turns out it wouldn't have ever worked). When I posted for assitance it·was a bit of a shock to see someone respond by telling me I·was·wrong about something I've done a dozen times. In the end this is turned out to be a·language issue which was worked out offline. [noparse];)[/noparse]· · Back to the topic at hand, while I agree that the PWM thread provides insight into what I’m doing it is by no means a perfect solution. I think there is room for more discussion on this matter. I would especially like to here from the folks who have done AC dimming with a prop before. While I'm fluent in PICBasic, PBasic, dimming, and high voltage I'm very new to the prop (this is my second project).
I may be "splitting hairs” but this is a technical forum and often “splitting hairs” is what is important. deSilva's comparison between spin and assembly has prompted me to begin an assembly version of my project. I guess we will see how that goes.···
Any other insights or code examples are welcomed especially from folks like deSilva who have vast assembly knowledge.
Comments
Once I have a chance to try it I'll be sure to let you know.
If the sub has just one output channel everything works great. However if I add in multiple outputs into my code the output timing is wrong (dramatically slow). I ran into a similar issue on a project a few months ago where multiple nested repeats were so slow that I had to put the timer part of the code on its own cog. I would hate to have to waste a cog like that but can if that’s what I need to do. It just seems to me that with a system clock at 80mHz the second example below should work just as well as the first. Thoughts?
Works (single):
· outa[noparse][[/noparse]0]~
·
· repeat idx from 0 to 255
····· if idx => ch[noparse][[/noparse]0]
······· outa[noparse][[/noparse]0]~~
··· waitcnt(StepTime + cnt)· ' 32us wait
Doesn't work (multi):
· outa[noparse][[/noparse]0..15]~
·
· repeat idx from 0 to 255
··· repeat dim from 0 to 15
····· if idx => ch[noparse][[/noparse]dim]
······· outa[noparse][[/noparse]dim]~~
··· waitcnt(StepTime + cnt)· ' 32us wait
Have a look at my PWM Tutorial Thread; I gave some program variants for exactly your problem and explaine the constraints. But I think you cannot avoid the assembly version...
http://forums.parallax.com/showthread.php?p=685997
Post Edited (deSilva) : 12/22/2007 4:48:59 PM GMT
*sigh* part of me wonders why spin exists since most of the time you have to move to assembly to get anything done. You would think that with a chip like this you would rarely need to move into assembly. In the end I use high level languges so I don't have to bother with the lower levels.
For the record I've done this sort of thing with a pic. What I normally do is setup an interrupt at 32us. When the interrupt occurs it increments a counter (0-255). My main code checks the counter and sets the outputs based on a comparison. I'm not sure how to do something similar to this with a prop. I spent some time looking at the counter modules but they seem to be geared toward outputs not just numerical references.
Post Edited (DynamoBen) : 12/22/2007 5:08:04 PM GMT
A good remark! But this again is a misunderstanding. The Propeller is a assembly only machine! However a lot of functions has been pre-developed and is ready for many situations. SPIN is a "scripting language", allowing you to control those work horses in the COGs.
In rare situations, for educational code or when using the Propeller was tenfold overhead for you in the first place, you can also code your core algorithm in SPIN. This works because the Propeller is so terribly fast!
You do it similarly, waiting for the next 32µs tick. The problem is, that you then have time for about 4 SPIN lines
But you have time for 600 machine instructions!
Spin's really a convenience to allow code to be developed quickly and easily without the inconvenience of having to deal with assembly, and the cost of that is slower execution. Spin is suitable for many jobs, but not all. I'm frequently surprised at just how fast Spin can be, but as one needs faster execution it becomes less useful.
Even with compiled high level languages it sometimes becomes necessary to step down to assembler to get the performance required.
However in the case of AC dimming·I need to·sync my output pulse(s) to the AC zero cross point. That means there is one pulse each half cycle and the duration of that pulse is anywhere from 0-255·* 32.5us.
Post Edited (DynamoBen) : 12/22/2007 7:42:43 PM GMT
I'm looking into an assembly routine.
my message was quite simple. What I showed in a comprehensive thread (later hijacked by Beau
I fully understand that you want to repaet all that for yourself, because this is the best way to learn, but don't say you do "something different". You dont, it is the same, absolutely the same..
·
Back to the topic at hand, while I agree that the PWM thread provides insight into what I’m doing it is by no means a perfect solution. I think there is room for more discussion on this matter. I would especially like to here from the folks who have done AC dimming with a prop before. While I'm fluent in PICBasic, PBasic, dimming, and high voltage I'm very new to the prop (this is my second project).
I may be "splitting hairs” but this is a technical forum and often “splitting hairs” is what is important. deSilva's comparison between spin and assembly has prompted me to begin an assembly version of my project. I guess we will see how that goes.·
Any other insights or code examples are welcomed especially from folks like deSilva who have vast assembly knowledge.