Multiple PWM output

scotta

Does anyone know how to generate 4 to 8 PWM signals with
a single cog ?


Scott

Mike Green

There's no "magic" way to do it. It depends on how fast the PWM signals need to be, whether they overlap, what the percentages of on vs. off time are, etc. Essentially it's "brute force" programming and, as such, depends highly on the details of the signals you need.

jazzed

Perhaps you should consider Beau's servo32 controller object: http://obex.parallax.com/objects/51/
It would generate 32 PWM in one COG.
There is also a 4 servo spin only object that I've used often: http://obex.parallax.com/objects/38/
Your milage may vary, but these are clear possibilities [noparse]:)[/noparse]

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

scotta

This is what my excel spread sheet is calculating, and it agrees with my scope.
It looks like it is a brute force problem and thats how I usually solve things, I
just wish there was a more efficient way of doing this.

 
IPS          Bits    States    PWM's    Inner Loop Instructions/Pass/PWM    Inner Loop instructions/Cycle    Outer Loop Instructions    Total Instructions    PWM Freq       
20000000    16    65536    4                   11                             720896                               9                        720905    27.74       
20000000    15    32768    4                   11                             360448                               9                        360457    55.48       
20000000    14    16384    4                   11                             180224                               9                        180233    110.96       
20000000    13    8192    4                   11                             90112                               9                        90121    221.92       
20000000    12    4096    4                   11                             45056                               9                        45065       443.80       
20000000    11    2048    4                   11                             22528                               9                        22537    887.42       
20000000    10    1024    4                   11                             11264                               9                        11273    1774.15       
20000000    9    512    4                   11                             5632                               9                        5641    3545.47       
20000000    8    256    4                   11                             2816                               9                        2825    7079.64     

Agent420

The Prop is a very interesting concept, but I wonder if things like this demonstrate the "right tool for the job" adage...

As I explore the capabilities of the Propeller, I get the impression that with the exception of some of the video timing, it seems a rather 'simple' i/o chip that makes use of software for most functions.· As opposed to other microcontroller platforms like pic, avr, arm etc where many more complicated functions like communication protocols and pwm are incorporated within the hardware.· Rather, the Propeller's strength seems to be within it's parallel architecture processing , which although useful in some circumstances may not be what you need in others like this.

Graham Stabler

I suspect there will be more to the finished application than a few PWMs else why would it be important to keep it in one cog. The parallel architecture will allow complete flexibility over the pwm while providing uninterrupted processing power for other applications.

It will depend on the application as to whether or not the prop is the right tool but I for one don't have time to learn all of the tools so it has that advantage as well.

Graham

Agent420

Graham Stabler said...
It will depend on the application as to whether or not the prop is the right tool but I for one don't have time to learn all of the tools so it has that advantage as well.

That is certainly true.· But I guess much of that may also lay in a user's previous experience.· At this point, I still see the Propeller as somewhat of a niche tool...· I think things like pics, avr's BS etc may be better common use foundations.· The availability of free cross platform high level compilers like C or Basic·certainly helps that as well;· Spin may be nice but it is proprietary and too slow for many uses.· So if you're going to only learn one architecture, I would look more at the common chips than the Prop.· Hopefully the Prop will take off and evolve, but with technology change is guarenteed and it would be nice to invest in training that can be as widely applied as possible.· Also, the Prop is not expensive, but there are many applications where a smaller single dollar chip may be preferrable.

I'm not knocking the Prop, because I think it has a lot of potential, but neither do I see it as a single solution.

Mike Green

I don't think anyone has claimed that the Propeller represents a single solution. Its main "selling points" are its multiple identical high speed processors and its strict determinism. Both are crucial for "soft hardware" applications. The PICs, AVRs etc. are excellent matches to an application where the hardware processors are a good fit for the application. If there's any mismatch or if the hardware is buggy (as happens), you're in trouble. As has happened with logic as with field programmable logic arrays and similar devices, we're beginning to move away from a myriad of variations on a processor and its peripherals to things like the Propeller and the XMOS processor which are completely software driven. These won't be used for everything, but you'll see them more and more as rapid development time, flexibility, and time to production become increasingly important.

scotta

Everyone has a few nice points here. I think software defined peripherals is
the key to this architecture, but with limited processors, you limit your ability
to have these to run in the background (as hardware does).

Having more processors and more speed would help the problem without
resorting to more hardware glue, as would having hardware on-bard.

I think I could justify my plans if I knew more about the next release (not
the chip, the release date).

Still in the dark

Scott

Mike Green

I'm afraid you'll still be in the dark along with the rest of us. Parallax doesn't provide release dates. They know full well that things happen and sometimes good things are worth waiting for, etc. There's no point in making promises based on guesses with little in the way of facts behind them because it's all new stuff. I'm sure that we'll start getting information once the chip is very close to being finished, like the prototypes work, there are some internal samples available, maybe the wafers are done and are in the process of being packaged and tested, etc. In the meantime, make plans on what's available and what's known about the features of the version II chip.

Do read Chip's essay on how the Propeller was developed. It's very different from how most other companies develop new microprocessors. It's very much an Engineering-driven development process as opposed to a Marketing-driven process. It has its advantages and disadvantages. Primarily, when it's done, it's very high quality, very robust. On the other hand, it gets done "in the fullness of time". Sometimes other people's products have serious bugs. There are often workarounds and, for some, it may be worthwhile to have a product on hand on a particular date even though there are messy workarounds. For the hobby, educational, and development worlds, it's more important to have something that works well and as expected. For high volume products, a lot can be dealt with.

scotta

I'm writing like the second chip is due tomorrow. Would like to get a sample as soon
as they are available. Its kind of like waiting for Scaled Composites new craft to fly,
you only know they are going to release information after you hear the sonic boom.

I did read the essay on the development of the Propeller. It looks like they wrote the
definition and documentation first, then used it to drive the development of the core,
most likely with custom software. One can only speculate.

Speaking of speculation, this is the third time I have asked. I'll byte my lip for a while...

Scott

Paul Baker

No, beyond the original design goals·the development of the hardware and software (the Spin interpreter) were developed in unison, where development of one helped to define the other further. This is counter to the industry standard of fully defining the chip before any work is done, great from a marketing perspective, but a nightmare for the engineer, because it binds them into a set path even when it is determined later it was not the best approach.

I understand your frustration on not knowing when it will come out, but at least you do know it's coming. Our preferred method of operation is to keep everything under wraps until it's ready for sale/use. The Propellent library is a prime example; besides Richard of ImageCraft and a design firm interested in using the chip in thier products but wanted a production programming tool, no one outside of Parallax was aware of Propellent. This is the way the Propeller was treated before it was released. We did it differently for Prop II because we were interested in user comments when we were in the initial definition of the next chip.·

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer

Parallax, Inc.

Post Edited (Paul Baker (Parallax)) : 5/29/2008 10:21:00 PM GMT

GreyBox Tim

Scott A,

There is a device called a DDS (direct digital synthesizer), which uses something called a "phase accumulator" to represent an angle around
a circle (from 0Degrees). By picking an "on phase" and an "off phase" you can chose a duty cycle. By adding a value to the accumulator at
a fixed period, you can set the frequency. By having a single "accumulator" (this will probably be a simple 16-bit register which you add a value
from 0 to 16-bit to each "cycle"), you can let each of your outputs have a separate pair of on and off phases. This will keep your outputs
synchronized in frequency (no harmonics). By adjusting the on and off phases relative to each other, you can change the channel-to-channel
phase relationship (even maintaining the duty cycle while doing so...).

I don't have a bunch of code I can pull from handy (I'm on my lunch break), but if you write a routine that does the following:

Variables (this is rough - not actual code...):

CounterA (the accumulator, 16-bits)
FreqVar (the amount to add to the accumulator each time, 16-bits)
Ch1On (the “phase” at which the “1” channel turns on)
Ch1Off (the “phase” at which the “1” channel turns off)
…
Ch8On (the “phase” at which the “8” channel turns on)
Ch8Off (the “phase” at which the “8” channel turns off)
PWMOut (8 PWM Output Byte, 8-bits)

Sub-Routine (this is rough - not actual code...):

:PWMLoop
CounterA = CounterA + FreqVar          \This adds the ammount of pase to increase every loop
CounterA = CounterA AND 65535        \This ensures that the counter does not excede 16-bits

On1 = Ch1On > CounterA                   \Checks if the "On" value is higher than the counter
Off1 = Ch1Off > CounterA                  \Checks if the "Off" value is higher than the counter
FGT1 = Ch1Off > Ch1On                    \Checks if the "Off" value is higer than the "On" value
XFT1 = On1 XOR Off1                        \An XOR of the On/Off/Counter comparison
PWMOut.Bit0 = FGT1 XOR XFT1          \An XOR of the On/Off/counter XOR and the On/Off <> comparison (gives signal out for this channel)

&#8230;

On8 = Ch8On > CounterA
Off8 = Ch8Off > CounterA
FGT8 = Ch8Off > Ch8On                    \Same as for Ch1
XFT8 = On8 XOR Off8
PWMOut.Bit8 = FGT8 XOR XFT8

Out0-7 = PWMOut                              \Writes all PWM out results to the output pins simultaneously to retain phase
Goto PWMLoop                                  \Continues loop (otherwise the output updates would stop...)

If you have a routine that pulls the variable values from the main memory, or gets written to directly from another Cog, you can leave this cog
in a continuous loop. By having the pin direction control set externally also, you can have an enable/disable for each PWM. One thing to note
about this method – the smaller the number you put in the accumulator, the less jitter you’ll get on the output, also you must have more on or
off time than the value you add to the counter each cycle or the output will be continuously on or off (which ever is most dominant), with a bit of
dither.

Also, the faster you run the Cog this is in, the higher the frequency you can output. The way to calculate the output frequency based on the routine
clock is (assuming a 16-bit counter):

(CLKIn / LoopsPerSecond) / (65535 / FreqVar) = Output Frequency

I would recommend doing this in assembly if you can – the faster the code runs the more granularity you get on the output frequency. Note that
each bit added to the accumulator equals:


360/accumulator = degrees per bit

or

360/65535 = about 0.0055 degrees per bit - which allows for very precise phase adjustments at the lower frequencies.

If you can use a larger accumulator size (>16-bits), you will get better results in granularity (and much lower frequencies possible).

-Tim


P.S. There are many applications for this type of function generation - If you were to say replace the rolling counter with a continuous rotary Hall-
effect sensor's position, you could "watch" a crank shaft on an engine, and trigger things like fuel injection (duty determines how much fuel gets
injected, while the on-time dictates "when"), spark timing - or even go into electronic valving . With a very large counter, you can get very
high accuracy (360/2^32 = 0.000 000 082 degrees per bit) - and at high speeds (>250MHz add function), you can still get very high speed signals
at a good - low jitter bit depth. If you took that code above and put in an error correction adjustment (add/subtract "once" - as oposed to each cycle),
you could do fast phase-keyed RF, and frequency/phase tracking on inputs. Lastly with more "accumulators", you could do independant frequencies
for each channel of PWM. This opens a whole realm of possibilites...

I should have also mentioned - that if you want a 50% duty with the above architechture, take the value at that bit depth, and XOR it to the maximum
amplitude for tha bit depth "0" (i.e.: 255 XOR 143 = 112) - you can ensure you don't pick up stray bit(s) by following that with an "AND"
(i.e.: 470 AND 255 = 214) -T

Post Edited (GreyBox Tim) : 6/4/2008 12:20:07 AM GMT

Phil Pilgrim (PhiPi)

Here is an object that can generate up to eight channels at high speed using a single cog. It takes advantage of the Propeller's video circuitry to do so.

-Phil