need help with using counters for periodic waveform generation
pems
Posts: 70
Hi
here is a brief description of a problem that i currently solve using waitcnt, but would like to change to use counters, to run two instances per cog, plus have some time sliced to do other other things in same cog while waiting on counters
the idea is to create a periodic square waveform using a bitfield-encoded pattern. For example, a bitfield containing 10001011 would generate such square waveform that for every bit there will be high level for 1 and low level for 0, and just keep looping the pattern over and over.
Currently, i keep the bitfield in a variable and just rotating bits with carry to extract bits, then use the carry bit to set a pin to 1 or 0 after a waitcnt, adding a fixed amount of time each bit to the counter.
but, as i mentioned, i'd like to do this using counters (so, two different patterns output to two diff pins per cog). I have read the Appnotes on counters and understand the modes, but i am at a loss as to what counter strategy to use. I'd like to retain this rotating bit by bit implementation to determine the next level. With the counters available, they seem easy to use for alternating levels (i.e to generate pwm's or diff frequency square wave), but not for the situations where the next level in the sequence is not necessarily alternating (for instance 1100010 as opposed to 10101010 ).
Also, for simplicity's sake, i don't want to be looking ahead in the bitfield to see how many repeating bits are there and scaling the time added to counter by this number of repeating bits, as this complicates the lookup and gives up determinism
Is there any other way?
Cheers
here is a brief description of a problem that i currently solve using waitcnt, but would like to change to use counters, to run two instances per cog, plus have some time sliced to do other other things in same cog while waiting on counters
the idea is to create a periodic square waveform using a bitfield-encoded pattern. For example, a bitfield containing 10001011 would generate such square waveform that for every bit there will be high level for 1 and low level for 0, and just keep looping the pattern over and over.
Currently, i keep the bitfield in a variable and just rotating bits with carry to extract bits, then use the carry bit to set a pin to 1 or 0 after a waitcnt, adding a fixed amount of time each bit to the counter.
but, as i mentioned, i'd like to do this using counters (so, two different patterns output to two diff pins per cog). I have read the Appnotes on counters and understand the modes, but i am at a loss as to what counter strategy to use. I'd like to retain this rotating bit by bit implementation to determine the next level. With the counters available, they seem easy to use for alternating levels (i.e to generate pwm's or diff frequency square wave), but not for the situations where the next level in the sequence is not necessarily alternating (for instance 1100010 as opposed to 10101010 ).
Also, for simplicity's sake, i don't want to be looking ahead in the bitfield to see how many repeating bits are there and scaling the time added to counter by this number of repeating bits, as this complicates the lookup and gives up determinism
Is there any other way?
Cheers
Comments
Design 1 - simplest, periodic re-loading of shift register:
Design 1a - simplest, periodic re-load, less I/O's used:
Design 2 - complex, perhaps not possible·(due to lack of official documentation on the Video Hardware), periodic WAITVID command call, Pure software:
Note: Use the Video Hardware at your own risk, there is little documentation about it, but being a Video Serializer Unit (unofficial name), I believe all the data the VSU needs is determined by VCFG &·VSCL registers, and by the two LONGS (D, S) in the "WAITVID D, S" command
Hope this helped a "bit"...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
E3 = Thought
http://folding.stanford.edu/·- Donating some CPU/GPU downtime just might lead to a cure for cancer! My team stats.
could you post some more details of your project.
Possible ways to go depend on different things like
- minimum period time of a single pulse
- maximum of pins that should act this way
if we are talking about timeperiods of 100 mseconds this will be easy
to program in spin with an elapsed_time-function
if we are talking about timeperiods of 100 microseconds the same thing could be done
in Propellerassembler PASM
if the FREQUENCY can be constant for all output-PINs, another idea is
to create one big ASM-loop which has a compare-command for each bit of each PIN
this loop compares the bit from a bitpattern-value to be equal or unequal to one branching to set the bit high or low
As soon as you change the bitpattern-value within the next loop the signal is switched to the new level
In the FullDuplexSerialDriver the code jumps forward and back between receivung and sending after each bit.
By this way the deadtime between to bitstream-patterns of the same channel could be minimized
With one big loop there will be a dead-time
send PIN A bitpattern
send PIN B bitpattern (=some delaytime for PIN A before next send PIN A bitpattern)
or you have to change from PIN A to PIN B after each bit
In ASM this will be pretty fast. But without knowing your timing-requirements it's not possible to say if this
would be a way to realize it.
best regards
Stefan
some more details on my project:
this function is supposed to emulate a toothed wheel. Real toothed wheels are used for angular position/speed/etc measurements on various rotating shafts. This project will emulate signal from such wheels. One type of such toothed wheels are wheels with irregular patterns, with such arrangements that some teeth are "missing". For example, a wheel has 7 teeth arranged in a symmetrical pattern with 1 tooth missing (360/8 degrees spacing between teeth). Such wheel is to be represented by this binary pattern, which fits in 2 bytes: 01010101 01010100
As i mentioned, currently, the whole array (of size 2 bytes in example above) is shifted bit by bit and paced by waitcnt in one big loop.
What i would like to do, is to "schedule" the next level on a pin to be set to the next shifted bit, then use the cpu time for something else, while regularly checking whether or not this next level had been set yet (i.e if it's time to shift a bit again and set up the counter again). Of course, the rate of checking on the counter status will have to be higher than the quickest shifting speed.
This would be easy to do on other MCUs with more complex counters and interrupts. But apparently not so easy on prop.
I am only using PASM btw, as i need highest speed.
The major problem seems to be "scheduling" the next level while holding the current one. Let's say i use the mode where MSB (i.e PHS[noparse][[/noparse]31]) defines the output on pin A - I can set the PHS[noparse][[/noparse]0-30] to schedule the next event, but i cannot mess with the PHS[noparse][[/noparse]31] as it directly impacts the current level.
So in situation where level always alternates, i.e 101010101 , PHS[noparse][[/noparse]31] doesn't even have to be touched, but as soon as there are two of the same levels in a row, we have a problem
For VSCL, PixelClocks is set to the number of transitions of CTRA that are contained in the bit period (this depends on what frequency you have set up on CTRA), and FrameClocks is set to PixelClocks*number of bits to transmit in this frame.
When calling WAITVID, colors should be set to $0000FF00 (basically this will output a 1 when the data value is 1 and 0 when the data value is 0), pixels is the LSB first data representation of the bits you are shifting out.
WAITVID holds until it needs the next set of data and colors, so by computing the FrameClocks value and the speed of the counter then subtracting 5 clocks needed to perform the WAITVID, you have the number of·clock cycles to do whatever you want before entering into another WAITVID.
CTRA must be setup in PLL mode for the system to work properly.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer
Parallax, Inc.
Post Edited (Paul Baker (Parallax)) : 9/30/2008 5:19:23 PM GMT
Another proof that there is not (yet) enough info published on the video generator... [noparse]:([/noparse]
Sorry Paul, I could not resist to comment... [noparse];)[/noparse]
Christian
PS: I have a similar need outputting at least 4 parallel bistreams in the same fashion, and planned to use the RGB and sync "channels" for doing it with one video generator. However, I have no time to just experiment with this, so I stay put and wait for the AN-002 [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
The future does not exist - we must invent it!
Post Edited (godzich) : 10/1/2008 6:54:34 AM GMT
I blamed it on me not touching the video stuff yet, but now hearing that there is no proper documentation, is there a hope for me to understand it?
This is no slight towards anyone, but I really don't understand this throwing up the hands when it comes to the video generator. Granted it isn't described in the detail that many customers have come to expect from Parallax, but all the information is there for someone to use it especially when it comes to using it in VGA mode.
Let me try to recap how they work (VGA mode) and perhaps a few light bulbs will go off. The video genrator is nothing more than a fancy shifter, there's no real magic behind it. The heart beat (clock signal) of the shifter is the CTRA for that cog, and it must be operating in the video PLL mode (this mode is described in the Counter Application note and is identical to the normal PLL mode but does not push the counter's output to pins). The video shifter has two time periods it is concerned with, how many clocks per datum, PixelClocks (or in general shifter term, the bit period), and how many clock cycles for the entire packet of data, FrameClocks (in general shifter terms, this is the number of data bits·times the bit period). Both of these are measured in terms of the number of CTRA's cycles.·
VCFG sets up the mode the video shifter is operating in, for the purpose of using the video shifter as a general data shifter, VCFG's VMode field is always set to 01, or the VGA mode. CMode determines how many different values a datum (pixel) can be, for a general shifter, the ouput can only be one of two states, either a 0 or a 1. So the Cmode is always set to 0 or two color mode. Chroma is not applicable to using the video shifter as a general shifter, so they are always 0, and likewize we aren't encoding any audio information on the bit stream, so you point AuralSub to a cog which isn't operating the CTRA. VGroup and Vpins determines which set of I/O pins the data is placed. VGroup sets which group of 8 pins (so there are 4 possibilities with the current Propeller), then the Vpins is a mask of which of those 8 pins you are pushing the data out to. Since this is a serial stream, there is only one I/O line that will be used, so the Vpins field will have only a single bit set in it.
When you call WAITVID with colors, pixels; Pixels contains the bit stream, where the least significant bit is shifted out first. Since it has been set up 2 color mode, it pops off 1 bit at a time. If that bit is 0, the 8 bit quantity in Colors located at the least significant byte is pushed out to the group of 8 pins specified in VGroup, this value is masked by Vpins before placing into outa. Since we have set it up so that only one bit is affected, only that bit will be affected. Since the data we are pushing is 0 the 8 bit color should be $00, so that no matter what pin is selected, a data bit 0 pushes a 0 to that pin. The same thing happens when the data bit is 1, except this time the video shifter uses the next byte up in Colors to push out. Since we want to push out a 1 when the data is 1, we set the second color to $FF so that regardless which pin was chosen it will be set to 1.
I don't know how better to explain this, you do not need to understand exactly how everything works in order to make use of it. You can record a program on your VCR without understanding how it does it. Likewise you do not need to understand every mode of operation to use the video shifter either. Reusing the VCR analogy, you do not need to know how to set the clock in order to record a program you are currently watching. In regards to the video shifter, you do not need to know how the NTSC/PAL mode works in order to use it as a general shifter.
I hope this is helpful in cracking the nut,
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer
Parallax, Inc.
Post Edited (Paul Baker (Parallax)) : 10/1/2008 5:42:07 PM GMT
Is it possible that a set of examples starting with "really, really, simple" leading up to "somewhat complex" could
be created for demonstrating the video generator stuff? I would do it myself, but I'm just not up to that level. (yet)
I suspect the problem here (at least in my case) is that it is helpful to have something to compare this knowledge
against and the video generator is rather abstract. (I know it doesn't look that way to the well initiated)
For example it's pretty easy to understand the repeat command because the concept of loops is pretty
well established in every other language. Video generation is an animal unto itself.
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Getting started with a Propeller Protoboard?
Check out: Introduction to the Proboard & Propeller Cookbook 1.4
Updates to the Cookbook are now posted to: Propeller.warrantyvoid.us
Got an SD card connected? - PropDOS
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer
Parallax, Inc.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
E3 = Thought
http://folding.stanford.edu/·- Donating some CPU/GPU downtime just might lead to a cure for cancer! My team stats.